🏠Inicio 📚Certificaciones 📱Aplicaciones Móviles

🎓Información del examen

✍️Blog 📊Progreso 📅Calendario 💬Soporte

Política de Privacidad Términos de Uso Contáctenos Política de Cookies Aviso Legal Accesibilidad DMCA / Derechos de Autor

Ir al contenido

SAP-C02Guía

Guía

AWS Certified Solutions Architect Professional

Última revisión: mayo de 2026

Una referencia escaneable de patrones arquitectónicos que evalúa el examen SAP-C02. Lee de arriba a abajo o salta a una sección.

Secciones

Diseñar Soluciones para la Complejidad Organizativa38 entradas
Diseño para Nuevas Soluciones41 entradas
Mejora Continua de Soluciones Existentes35 entradas
Acelerar la Migración y Modernización de Cargas de Trabajo26 entradas

Diseñar Soluciones para la Complejidad Organizativa

Establecer un entorno AWS de más de 100 cuentas con barreras de seguridad, registro e identidad consistentes desde el primer día.

AWS Control Tower como zona de aterrizaje. Account Factory aprovisiona cuentas; las barreras de seguridad obligatorias + fuertemente recomendadas imponen líneas base; el archivo de registros centralizado + las cuentas de auditoría se crean automáticamente.

Por qué: Control Tower codifica el patrón de múltiples cuentas bien arquitectado. Construir desde cero solo con Organizations reproduce la misma infraestructura manualmente.

Necesidad de añadir barreras de seguridad y recursos personalizados más allá de los valores predeterminados de Control Tower en todas las cuentas.

Customizations for AWS Control Tower (CfCT). Pipeline de plantillas CloudFormation + SCPs desplegados mediante StackSets a las OUs.

Por qué: CfCT extiende Control Tower sin romper su ciclo de vida. Reglas de Config personalizadas, líneas base de seguridad, redes, todo versionado y reproducible.

Aplicar el cifrado S3 KMS + remediar automáticamente los buckets no conformes en 300 cuentas en <15 minutos.

Paquete de conformidad de AWS Config a nivel de organización a través de un administrador delegado. Regla de Config + documento de automatización SSM para la remediación automática.

Por qué: Los paquetes de conformidad despliegan reglas de Config + remediación en toda la organización desde una cuenta. Los enfoques de Lambda por cuenta o solo SCPs omiten la detección en tiempo real o la remediación.

Registros de CloudTrail a prueba de manipulaciones en todas las cuentas retenidos durante 7 años; solo el equipo de seguridad puede leerlos.

Ruta de organización entregando a un bucket S3 de una cuenta de registro dedicada. Object Lock en modo de cumplimiento con retención de 7 años. SCP que restringe el acceso al bucket a los roles IAM de seguridad.

Por qué: Object Lock en modo de cumplimiento bloquea la eliminación incluso por el usuario root. La ruta de organización recopila automáticamente de todas las cuentas. La cuenta de registro dedicada aísla el radio de impacto.

Federar 150 cuentas a un AD corporativo a través de SAML; asignar permisos por grupo de AD.

IAM Identity Center con IdP externo SAML 2.0. Conjuntos de permisos mapeados a grupos de AD mediante aprovisionamiento SCIM. Asignaciones de cuenta mediante grupos.

Por qué: Identity Center centraliza la federación en todas las cuentas de la organización. Los conjuntos de permisos son reutilizables entre cuentas; SCIM mantiene el estado de usuario/grupo sincronizado.

Conceder acceso a recursos etiquetados con el centro de costos del usuario, escalando a miles de usuarios.

Control de acceso basado en atributos (ABAC) en Identity Center. Pasar atributos de AD vía SAML; los conjuntos de permisos referencian `aws:PrincipalTag/CostCenter` contra `aws:ResourceTag/CostCenter`.

Por qué: ABAC escala sin cambios de política por usuario. Añadir un nuevo centro de costos es solo una etiqueta, sin reescritura de IAM.

La cuenta de CI/CD asume un rol de despliegue en 50 cuentas de carga de trabajo para ejecutar CloudFormation.

Rol de IAM por cuenta de carga de trabajo con política de confianza que permite el principal de la cuenta de CI/CD. CI/CD asume vía STS AssumeRole. Usar external ID si una herramienta de terceros inicia.

Por qué: External ID previene el problema del "confused deputy". El encadenamiento de roles limita la sesión a 1 hora incluso si el rol permite más tiempo.

El equipo de red central posee la VPC; 30 cuentas "spoke" despliegan cargas de trabajo en subredes compartidas.

AWS RAM comparte subredes con cuentas participantes. Los participantes lanzan recursos sin poseer la VPC; el equipo central mantiene el control de la tabla de rutas + NAT.

Por qué: Las VPCs compartidas eliminan la proliferación de VPCs por cuenta + la duplicación de IPAM. Los participantes no pueden eliminar la VPC ni cambiar el enrutamiento.

Conectar VPCs en 5 regiones + en local con enrutamiento determinista e inspección central.

Transit Gateway en cada región. Peering de TGW para inter-regiones. VPC de inspección con dispositivos accesibles a través de tablas de rutas de TGW.

Por qué: El peering de TGW evita la malla completa de VPN/peering inter-regiones. Las tablas de rutas por adjunto permiten a seguridad inspeccionar flujos específicos sin romper otros.

Construir una red privada global en regiones + sucursales con enrutamiento basado en políticas — más allá del peering de TGW.

AWS Cloud WAN. La política de red central en JSON define declarativamente segmentos, regiones, adjuntos, compartición.

Por qué: Cloud WAN reemplaza el diseño de TGW "hub-of-hubs" con un único backbone global gestionado. Los segmentos proporcionan aislamiento lógico entre regiones.

Un centro de datos local necesita un enlace de 10 Gbps a AWS con resiliencia ante fallos de enlace y sin exposición a internet.

Dos conexiones Direct Connect en ubicaciones DX separadas. Cada una con un VIF privado que termina en un Direct Connect Gateway → TGW. Conmutación por error BGP entre conexiones.

Por qué: Un solo DX es un único punto de fallo. Diferentes ubicaciones de DX protegen contra interrupciones en todo el sitio. DX Gateway permite que un VIF alcance múltiples regiones/VPCs.

Enlace Direct Connect como principal; se necesita conmutación por error VPN automática.

VPN de sitio a sitio adjunta al mismo TGW que el DX gateway. AWS prefiere las rutas BGP de DX; la VPN toma el control cuando DX BGP se retira.

Por qué: La preferencia de ruta BGP hace que la conmutación por error sea automática. La VPN pre-aprovisionada evita el retraso de aprovisionamiento durante la interrupción.

El regulador exige cifrado de capa 2 entre el entorno local y AWS a través de Direct Connect.

Direct Connect con MACsec en una conexión dedicada de 10 Gbps o 100 Gbps. Clave precompartida configurada en ambos extremos.

Por qué: IPsec funciona en la capa 3; MACsec cifra en la capa 2 a velocidad de línea, satisfaciendo a los reguladores que exigen cifrado de enlace físico.

El tráfico este-oeste entre VPCs debe pasar por una inspección con estado.

VPC de inspección centralizada con AWS Network Firewall. Las tablas de rutas de TGW dirigen el tráfico entre VPCs a través de la VPC del firewall antes de llegar al destino.

Por qué: Network Firewall es el motor de reglas Suricata gestionado para la inspección con estado. La centralización evita la proliferación de firewalls por VPC.

Aplicar automáticamente una configuración base de WAF + Network Firewall en cada cuenta de la organización.

AWS Firewall Manager con administrador delegado. Las políticas para WAF, Shield Advanced, Network Firewall, grupos de seguridad se aplican en toda la organización.

Por qué: Firewall Manager adjunta automáticamente políticas a los nuevos recursos. Sin él, cada cuenta se desvía de la línea base a medida que se añaden cuentas.

Centralizar los hallazgos de Security Hub de más de 100 cuentas en un solo panel.

Administrador delegado de Security Hub. La región de agregación recopila los hallazgos de todas las cuentas miembro + todas las regiones habilitadas en una sola consola.

Por qué: Sin agregación, los hallazgos permanecen por cuenta/región. El administrador delegado evita usar la cuenta de gestión para operaciones de seguridad.

Habilitar GuardDuty en toda la organización con monitoreo centralizado y visibilidad de facturación por cuenta.

GuardDuty con administrador delegado. Habilitación automática en nuevas cuentas a través de la integración de la organización. Hallazgos agregados a la cuenta de administrador.

Por qué: La habilitación automática cierra la brecha en las cuentas recién creadas que de otro modo no serían monitoreadas.

Descubrimiento continuo de PII en todos los buckets de S3 en 200 cuentas.

Macie con administrador delegado. Habilitación automática a nivel de organización. Los hallazgos fluyen a Security Hub para una revisión unificada.

Por qué: Macie no puede leer entre cuentas sin una configuración explícita. La configuración a nivel de organización garantiza que cada bucket esté dentro del alcance.

Investigar un hallazgo de GuardDuty correlacionando CloudTrail + VPC Flow Logs entre cuentas.

Administrador delegado de Amazon Detective en una cuenta de seguridad dedicada. Las cuentas miembro contribuyen al grafo de comportamiento.

Por qué: Detective construye automáticamente el grafo de comportamiento a partir de VPC Flow Logs, CloudTrail, GuardDuty. El administrador delegado (no de gestión) sigue las mejores prácticas de AWS.

Detectar cuándo cualquier recurso de la organización se comparte con una cuenta externa.

IAM Access Analyzer con la organización como zona de confianza, delegada a la cuenta de seguridad. Hallazgos sobre el acceso entre cuentas en S3, roles de IAM, claves KMS, Lambda, SQS, Secrets.

Por qué: Access Analyzer utiliza verificación formal, no coincidencia de patrones. La zona de confianza a nivel de organización trata a las cuentas hermanas como confiables.

Maximizar la utilización de Savings Plan en 50 cuentas con patrones de carga de trabajo dispares.

Facturación consolidada en Organizations con Savings Plans + compartición de RI habilitada. Los planes comprados en la cuenta pagadora se comparten en toda la organización.

Por qué: Compartir agrupa el uso para que la capacidad no utilizada en una cuenta compense la demanda en otra. Desactivar la compartición solo para el aislamiento de la asignación de costos.

Permitir que los equipos de aplicaciones se autoabastezcan de infraestructura aprobada (VPCs, RDS) sin derechos de administrador de IAM.

Portafolios de AWS Service Catalog. Productos CloudFormation pre-aprobados con restricciones. Compartir portafolios entre cuentas a través de Organizations.

Por qué: Proporciona autoservicio con barreras de seguridad. Las políticas de restricción ocultan la complejidad (tipos de instancia, etiquetas) mientras que los productos llevan el alcance de IAM para el lanzamiento.

Aplicar etiquetas obligatorias `CostCenter` y `Environment` de manera consistente en toda la organización.

Políticas de etiquetas de Organizations adjuntas a las OUs. Definir valores permitidos + capitalización. Combinar con la regla de Config `required-tags` para su aplicación.

Por qué: Las políticas de etiquetas validan; las reglas de Config detectan el incumplimiento. Los SCPs pueden denegar la creación de recursos que carecen de etiquetas.

Prevenir acciones de usuario root en cuentas miembro (requisito de cumplimiento).

SCP denegando cualquier acción cuando `aws:PrincipalArn` coincide con `arn:aws:iam::*:root`.

Por qué: Los SCPs se aplican incluso al usuario root. IAM no puede denegar el acceso root. Las acciones root nunca deberían ser necesarias excepto para la recuperación de cuentas.

Exigir planes de AWS Backup en todas las cuentas con retención consistente.

Políticas de copia de seguridad de Organizations adjuntas a las OUs. Definir planes + criterios de selección; aplicar automáticamente a los recursos en el ámbito.

Por qué: La duplicación del plan de Backup por cuenta lleva a la deriva. Las políticas de la organización imponen una única fuente de verdad.

Más de 100 VPCs, cada una con NAT Gateway, está inflando los costos. Se desea un único punto de salida.

VPC de salida centralizada con NAT Gateway. Las VPCs "spoke" enrutan 0.0.0.0/0 → TGW → VPC de salida → NAT.

Por qué: Un NAT en lugar de 100 reduce drásticamente el costo. Se aplican las reglas de transferencia de datos entre regiones de TGW, por lo que el diseño debe ser cuidadoso para el tráfico inter-regiones.

Las instancias EC2 en VPC necesitan resolver nombres de host locales; el entorno local debe resolver el DNS privado de la VPC.

Puntos de conexión entrantes + salientes de Route 53 Resolver. Las reglas de reenvío envían `corp.local` consultas al entorno local; el DNS local reenvía `*.compute.internal` al punto de conexión entrante.

Por qué: Los puntos de conexión de Resolver son ENIs de alta disponibilidad en dos AZs. El reenvío condicional proporciona resolución bidireccional sin exponer el DNS a internet.

Los servicios internos necesitan DNS resoluble desde múltiples VPCs en diferentes cuentas.

Zona alojada privada de Route 53 asociada con VPCs de múltiples cuentas a través de una asociación de VPCs entre cuentas.

Por qué: Una sola PHZ compartida a través de asociación entre cuentas supera a las duplicadas por VPC que se desvían.

Las cargas de trabajo de Windows necesitan un AD completo con confianza en el bosque local.

AWS Managed Microsoft AD. Establecer confianza bidireccional de bosque con el AD local a través de DX/VPN.

Por qué: Managed AD es un Microsoft AD real (DCs en dos AZs, esquema extensible). AD Connector solo actúa como proxy; Simple AD carece de soporte de confianza.

Las aplicaciones en AWS necesitan autenticarse contra un AD local existente sin replicar identidades.

AD Connector. Actúa como proxy desde la VPC hacia el AD local a través de DX/VPN.

Por qué: Ningún dato de directorio sale del entorno local; las solicitudes de autenticación pasan a través. La latencia depende del enlace.

La carga de trabajo sensible a la latencia debe ejecutarse en un centro de datos específico pero ser gestionada a través de las APIs de AWS.

Rack/servidor AWS Outposts. Las mismas APIs de AWS (EC2, EBS, ECS, EKS, un subconjunto de RDS) se ejecutan en el entorno local. Se conecta a una región padre.

Por qué: Para latencia local de sub-milisegundos a sistemas locales o residencia de datos donde las Zonas Locales no cubren. Una sola AZ — emparejar dos Outposts para alta disponibilidad.

Reducir la latencia para los usuarios finales en un área metropolitana que está lejos de la región padre.

AWS Local Zones. Desplegar cómputo y almacenamiento cerca de los centros de población; el plano de datos se enruta de vuelta a la región padre para el plano de control.

Por qué: Las Local Zones alojan EC2/EBS/RDS/ELB cerca de las principales ciudades. Más barato que Outposts cuando no se necesita la propiedad completa del centro de datos.

La aplicación requiere una latencia de un solo dígito de milisegundos para usuarios móviles en 5G.

AWS Wavelength Zones en redes 5G de operadores. Desplegar EC2/EBS en el borde del operador; el tráfico permanece en la red del proveedor móvil.

Por qué: Elimina por completo el salto a internet público para casos de uso 5G como AR/VR, inferencia en tiempo real, juegos.

El auditor de cumplimiento necesita la configuración actual de cada recurso en toda la organización.

Agregador de AWS Config en la cuenta de auditoría, con alcance a toda la organización en todas las regiones.

Por qué: El agregador de Config es la vista de solo lectura de toda la organización. Los agregadores no habilitan Config en las cuentas miembro — eso es aparte.

Los registros de CloudWatch de 50 cuentas deben llegar a un archivo S3 para la ingesta de SIEM.

Filtros de suscripción en cada cuenta → Kinesis Data Stream / Firehose entre cuentas → S3 en la cuenta de registro.

Por qué: Los filtros de suscripción permiten que los grupos de registros se envíen en tiempo real. Firehose maneja el procesamiento por lotes, la compresión y el particionamiento de S3.

Generar informes de evidencia para SOC 2, PCI, HIPAA continuamente en toda la organización.

AWS Audit Manager. Marcos predefinidos mapean controles a evidencia de AWS (Config, CloudTrail, Security Hub). Administrador delegado en cuenta de seguridad.

Por qué: Audit Manager recopila automáticamente evidencia por control. Ahorra cientos de horas de recolección manual de capturas de pantalla por ciclo de auditoría.

Desplegar un rol de IAM base en cada cuenta existente + futura de la organización.

CloudFormation StackSets con permisos gestionados por el servicio + auto-despliegue en nuevas cuentas. Dirigir a toda la organización o a OUs específicas.

Por qué: Los StackSets autogestionados requieren IAM en cada cuenta. Los gestionados por el servicio aprovechan los permisos de la organización y son el valor predeterminado para Organizations.

Después de meses ejecutando StackSets, se sospecha que los cambios manuales han causado "drift" (desviación).

Iniciar la detección de "drift" en el StackSet. Revisar los resultados por instancia de pila sin modificar recursos.

Por qué: La detección de "drift" compara la configuración de los recursos en vivo con la plantilla. Volver a desplegar StackSets para "arreglar" el "drift" puede causar cambios no deseados.

Diseño para Nuevas Soluciones

Carga de trabajo de base de datos variable y en ráfagas — las necesidades de capacidad fluctúan 10 veces en minutos.

Aurora Serverless v2. Establecer ACU mínimo/máximo; Aurora escala en segundos sin caídas de conexión.

Por qué: v2 escala añadiendo capacidad a la instancia existente — sin conmutación por error. Aurora Provisioned no puede escalar tan rápido; Serverless v1 escala más lento y pausa las conexiones.

Aplicación global con RPO <1s y RTO <1min para conmutación por error de DB entre regiones.

Aurora Global Database. Replicación basada en almacenamiento, retraso de replicación típico <1s. Promover secundaria en segundos.

Por qué: Global DB envía páginas, no transacciones — sub-segundo entre regiones. Las réplicas de lectura entre regiones mediante replicación lógica no pueden igualar esto.

Reproducir una base de datos de producción para pruebas sin pagar por una copia completa.

Clonación de Aurora. Copy-on-write — el clon inicial es gratuito; solo se facturan las páginas modificadas.

Por qué: Los clones son puntuales, instantáneos, aislados. Snapshot+restore tarda horas y factura el almacenamiento completo inmediatamente.

Recuperarse de un error lógico (DROP TABLE en producción) en minutos, no en horas.

Aurora MySQL Backtrack. Retrocede el clúster en su lugar a un punto anterior en el tiempo sin restaurar desde la copia de seguridad.

Por qué: Backtrack es in-place y rápido. Las restauraciones PITR crean un nuevo clúster, más lento y requiere un "cutover" de la aplicación.

Enrutar consultas de informes a instancias de lectura específicas con mayor memoria.

Puntos de conexión personalizados de Aurora. Definir un punto de conexión que apunte a un subconjunto de lectores (los más grandes).

Por qué: El punto de conexión de lectura predeterminado distribuye las solicitudes entre todos los lectores. Los puntos de conexión personalizados particionan el clúster por tipo de carga de trabajo.

Tabla de DynamoDB experimenta picos de partición "calientes" que limitan algunas lecturas/escrituras.

Aprovisionado con autoescalado + capacidad adaptativa (automática). Rediseñar la clave de partición si una sola clave es el "hotspot".

Por qué: La capacidad adaptativa reasigna el rendimiento entre particiones sin acción. Pero si una clave está "caliente", solo un rediseño del esquema (clave compuesta, sharding de escritura) ayuda.

Efecto secundario en cada escritura de DynamoDB — enviar a OpenSearch para indexación de búsqueda.

DynamoDB Streams + disparador Lambda. Lambda agrupa registros del stream y escribe en OpenSearch.

Por qué: Streams captura cambios a nivel de ítem durante 24h. Modelo de disparador nativo — existe un adaptador de Kinesis Data Streams para retención/análisis más largos.

La escritura en dos fases a través de múltiples ítems de DynamoDB debe ser atómica.

TransactWriteItems / TransactGetItems. Semántica ACID en hasta 100 ítems.

Por qué: Las transacciones nativas evitan la complejidad de la saga distribuida. El costo es 2 veces la capacidad normal por ítem — usar solo cuando se requiere atomicidad.

Migrar un clúster de MongoDB autoalojado a un servicio gestionado conservando la API.

Amazon DocumentDB. API compatible con MongoDB. Usar mongodump/mongorestore o DMS para la migración.

Por qué: DocumentDB es compatible con la API de MongoDB 4.0/5.0 (la mayoría de los operadores, no todos). Verificar la compatibilidad del controlador/característica antes de confirmar.

El motor de recomendaciones necesita recorrer un grafo social de 100 millones de nodos.

Amazon Neptune. Grafo de propiedades (Gremlin) o RDF (SPARQL).

Por qué: Base de datos de grafo diseñada específicamente. Modelar relaciones en DynamoDB o RDS es posible, pero el rendimiento de las consultas se degrada con la profundidad de los saltos.

Una flota de IoT emite 10 millones de puntos de datos de series de tiempo por segundo con retención de frecuencia mixta.

Amazon Timestream. Almacén en memoria (recientes), almacén magnético (históricos) — clasificación automática por niveles.

Por qué: Series de tiempo diseñadas específicamente — el escalado de DynamoDB/RDS sería prohibitivo a esta tasa. La clasificación de retención por niveles incorporada reduce el costo de almacenamiento.

Un libro mayor bancario necesita verificación criptográfica de cada cambio de registro.

Amazon QLDB. Diario inmutable, criptográficamente verificable. Usar la exportación de digest SHA-256 para pruebas.

Por qué: QLDB es un libro mayor diseñado específicamente. DynamoDB Streams proporciona historial de cambios pero no encadenamiento criptográfico incorporado.

Carga de trabajo de análisis de registros con picos impredecibles y operaciones sin intervención manual.

Amazon OpenSearch Serverless. Cómputo/almacenamiento desacoplado; autoescala OCUs.

Por qué: Sin dimensionamiento de clúster ni gestión de shards. Para cargas de trabajo predecibles y sostenidas, los dominios aprovisionados son más baratos.

Análisis a escala de petabytes con cómputo elástico y compartición de datos entre equipos.

Nodos Redshift RA3 con almacenamiento gestionado. Compartición de datos entre clústeres (sin copia).

Por qué: RA3 separa el cómputo del almacenamiento — escalar cada uno independientemente. La compartición de datos elimina ETL entre los clústeres de los equipos.

Clúster Redshift existente + data lake en S3 — ¿consultar S3 desde Redshift o usar Athena?

Redshift Spectrum cuando se necesitan uniones entre tablas del clúster y datos de S3. Athena cuando es completamente serverless ad-hoc solo en S3.

Por qué: Spectrum ejecuta consultas S3 a través del cómputo de Redshift. Athena paga por TB escaneado. Elegir según dónde reside la mayoría de los datos.

Diferentes equipos necesitan diferente visibilidad a nivel de fila/columna en las mismas tablas de Glue Catalog.

AWS Lake Formation con filtros a nivel de fila + nivel de columna + nivel de celda. Conceder vía etiquetas LF.

Por qué: Las políticas de IAM/S3 no pueden operar a nivel de fila. Lake Formation aplica acceso granular mediante metadatos de Glue Catalog + consumidores de Athena/Redshift Spectrum/EMR.

El trabajo diario de Glue procesa datos incrementales; no debe reprocesar los archivos de ayer.

Marcadores de trabajo de Glue. Rastrear claves S3 / filas de DB procesadas; reanudar desde el último punto de control exitoso.

Por qué: Los marcadores evitan el procesamiento duplicado sin seguimiento de estado manual. Deshabilitar para ejecuciones de reprocesamiento completo.

Elegir entre Kafka gestionado vs Kinesis Data Streams para la transmisión de eventos.

MSK cuando existen clientes/ecosistema Kafka. Kinesis para una integración estrecha con AWS (disparadores Lambda, Firehose, KCL) y opción serverless.

Por qué: Ambos transmiten de forma duradera con repetición. MSK conserva la API y el ecosistema de Kafka; Kinesis cuesta menos para streams pequeños y se integra de forma nativa.

Rendimiento variable de Kafka; se desea una gestión de clúster sin intervención manual.

MSK Serverless. Autoescala particiones y rendimiento; pagar por partición + datos.

Por qué: Sin dimensionamiento de brokers. Para un alto rendimiento sostenido, MSK aprovisionado es más barato.

Conectar SQS → filtrar → Step Functions sin escribir una Lambda de "pegamento".

EventBridge Pipes. Origen → filtro opcional → enriquecimiento opcional → destino.

Por qué: Reemplaza una típica Lambda como "pegamento". Reduce código, costo y superficie operativa.

Reproducir los eventos de la semana pasada a través de un nuevo consumidor sin reemitir desde el origen.

Archivo + reproducción de EventBridge. El archivo captura eventos coincidentes; los reproduce en un destino más tarde.

Por qué: La reproducción incorporada evita la necesidad de un almacén de eventos separado. Útil para la recuperación de incidentes y la incorporación de nuevos consumidores.

Cientos de productores emiten eventos; los consumidores necesitan enlaces tipados.

EventBridge Schema Registry con auto-descubrimiento. Generar enlaces de código fuertemente tipados (Java, Python, TypeScript).

Por qué: El descubrimiento aprende esquemas de los eventos observados. Los enlaces proporcionan seguridad en tiempo de compilación.

Orquestación de alto volumen de flujos de trabajo cortos (>100k/seg) facturada en sub-segundos.

Flujos de trabajo Express de Step Functions. Facturación por ms de ejecución; máximo de 5 minutos.

Por qué: Los flujos de trabajo estándar son duraderos + con historial, facturados por transición de estado. Express sacrifica el registro de auditoría por costo en flujos de corta duración.

Procesar 10 millones de objetos S3 en paralelo a través de una Step Function.

Estado Distributed Map. Ejecuciones hijas concurrentes de hasta 10,000 en paralelo; lee el origen directamente desde S3.

Por qué: Inline Map tiene un límite de 40 en paralelo. Distributed Map escala a trabajos del tamaño de un bucket S3 sin alcanzar las cuotas de servicio.

La cola FIFO requiere >300 mensajes/seg.

SQS FIFO con modo de alto rendimiento habilitado. Hasta 70k mensajes/seg por API por región; particionar por `MessageGroupId`.

Por qué: FIFO estándar tiene un límite de 300 mensajes/seg sin procesamiento por lotes. El modo de alto rendimiento particiona el ordenamiento por ID de grupo.

Múltiples consumidores necesitan cada uno el rendimiento de lectura completo en el mismo stream de Kinesis.

Enhanced Fan-Out (EFO). Cada consumidor obtiene una tubería dedicada de 2 MB/s/shard vía push HTTP/2.

Por qué: El sondeo predeterminado comparte el límite de 2 MB/s/shard entre los consumidores. EFO elimina la contención a un costo mayor.

Firehose a S3; las consultas del data lake escanean demasiado porque la partición es por tiempo de ingesta, no por tiempo de evento.

Particionamiento dinámico de Firehose. Extraer el tiempo del evento / ID de inquilino de JSON; escribir en el prefijo S3 `year=YYYY/month=MM/tenant=X/`.

Por qué: La poda de particiones de Athena/Spectrum en el tiempo del evento reduce drásticamente el costo y la latencia del escaneo.

El cliente móvil/web necesita actualizaciones en tiempo real y recuperación selectiva de campos.

AWS AppSync (GraphQL) con suscripciones. Basado en WebSocket.

Por qué: Los clientes GraphQL obtienen solo los campos solicitados y se suscriben a los deltas. REST/HTTP API Gateway fuerza el exceso de obtención y el sondeo.

La API interna no debe ser accesible desde internet público.

Punto de conexión privado de API Gateway a través de un punto de conexión de interfaz de VPC. La política de recursos restringe a VPCs específicas.

Por qué: Las APIs privadas son accesibles solo desde la VPC + redes conectadas. Las APIs públicas requieren WAF + autenticación para ser seguras.

Bloquear el origen de S3 para que solo CloudFront pueda leerlo.

Origin Access Control (OAC). Reemplaza al OAI legado; soporta SSE-KMS y todas las características de S3.

Por qué: OAI no soporta objetos SSE-KMS. AWS recomienda OAC para todas las nuevas distribuciones.

Limitar el tiempo de acceso a videos pagados específicos en S3.

URLs firmadas de CloudFront (por URL) o cookies firmadas (múltiples URLs). Un grupo de claves de confianza firma las solicitudes.

Por qué: Las URLs pre-firmadas de S3 omiten el almacenamiento en caché de CloudFront. Las URLs firmadas de CloudFront almacenan en caché en el borde Y restringen el acceso.

Transformación ligera de solicitudes de espectadores: reescritura de encabezados, redirección, enrutamiento A/B.

CloudFront Functions. JS, sub-milisegundo, todos los POPs de borde.

Por qué: Lambda@Edge es Node/Python completo en el borde regional — más pesado y caro. Las Functions son 10 veces más baratas para manipulaciones simples.

Ejecutar cargas de trabajo multi-inquilino no confiables en EKS con fuerte aislamiento.

Aislamiento por pod de EKS Fargate. Cada pod se ejecuta en una micro-VM dedicada.

Por qué: Los grupos de nodos gestionados comparten el kernel — la escalada de privilegios cruza a los inquilinos. El aislamiento del kernel de Fargate es el más fuerte en EKS.

La latencia de autoescalado del clúster EKS es demasiado lenta; la proliferación de tipos de instancia de los grupos de nodos.

Karpenter. El aprovisionador elige tipos de instancia justo a tiempo basándose en los requisitos de los pods pendientes.

Por qué: Cluster Autoscaler escala ASGs predefinidas, lento y limitado. Karpenter escala EC2 arbitrario en segundos con diversificación.

El pod de EKS necesita IAM de menor privilegio (evitar compartir el rol de instancia del nodo).

Roles de IAM para Cuentas de Servicio (IRSA) vía proveedor OIDC. Anotar ServiceAccount con el ARN del rol.

Por qué: EKS Pod Identity es la alternativa más reciente — modelo de confianza más simple. IRSA es maduro y funciona en todas las regiones.

El inicio de tareas de ECS-on-EC2 tarda de 5 a 7 minutos durante el escalado horizontal — se necesita <60s.

Proveedor de Capacidad de ECS con objetivo de escalado gestionado ~80% en `CapacityProviderReservation`. Mantener un búfer inactivo.

Por qué: Un búfer reservado significa que las nuevas tareas aterrizan en la capacidad existente instantáneamente mientras el ASG lanza reemplazos.

Lambda disparada por SQS pero solo el 5% de los mensajes coinciden — invocaciones desperdiciadas.

Mapeo de origen de eventos con criterios de filtro. Lambda solo invocada para mensajes coincidentes.

Por qué: El filtro pre-Lambda evita el costo por invocación en mensajes irrelevantes. Filtrado soportado en SQS, Kinesis, DynamoDB, MQ, Kafka.

Una aplicación de producción necesita un endpoint de LLM con baja sobrecarga operativa.

Amazon Bedrock para modelos fundacionales gestionados (Claude, Llama, Titan). SageMaker solo cuando necesites alojar modelos personalizados o pesos abiertos finamente ajustados.

Por qué: Bedrock es solo API — sin infraestructura. SageMaker es una plataforma de ML completa — elegir cuando se posee el ciclo de vida de entrenamiento/ajuste fino.

Elegir IA gestionada para visión / PNL sin entrenar un modelo.

Rekognition (etiquetas de imagen/video, caras, moderación de contenido). Comprehend (sentimiento, entidades, idiomas, detección de PII). Translate. Polly. Transcribe.

Por qué: Los servicios de IA preentrenados de AWS omiten todo el ciclo de vida de ML para tareas comunes. Usar SageMaker solo cuando las soluciones preexistentes no encajan.

La aplicación web soporta email/contraseña + Google + Apple + SSO empresarial SAML.

Cognito User Pool con interfaz de usuario alojada. Configurar OIDC + IdPs SAML. La aplicación recibe el JWT de Cognito.

Por qué: User Pool agrega IdPs en un solo token. Identity Pool solo intercambia tokens por credenciales de AWS — para acceso a la API de AWS, no para autenticación.

DynamoDB Global Tables con escrituras simultáneas a la misma clave en dos regiones.

El último escritor gana por marca de tiempo. La aplicación diseña escrituras idempotentes o particiona escrituras por región.

Por qué: La replicación de Global Tables es asíncrona multi-maestro. La resolución de conflictos se basa en marcas de tiempo — las aplicaciones deben tolerar la consistencia eventual.

Mejora Continua de Soluciones Existentes

La flota de EC2 está sobreaprovisionada en toda la organización; se necesitan recomendaciones automatizadas de dimensionamiento correcto.

AWS Compute Optimizer habilitado a nivel de organización. Revisar las recomendaciones frente a las ventanas de utilización; exportar a S3 para seguimiento.

Por qué: Compute Optimizer utiliza ML en métricas de CloudWatch. El dimensionamiento manual ignora las señales de forma de la carga de trabajo.

Detectar picos de costos inesperados en horas, no a fin de mes.

Detección de Anomalías de Costos de AWS. El ML monitorea el gasto por servicio / por cuenta; alerta vía SNS / email cuando se supera el umbral.

Por qué: Los presupuestos se activan en umbrales planificados. La detección de anomalías detecta sorpresas (clave comprometida, trabajo de entrenamiento descontrolado) días/semanas antes.

Cuando la cuenta alcanza el 100% del presupuesto mensual, detener automáticamente los recursos no esenciales.

Acciones de Presupuesto de AWS. Aplicar política IAM restrictiva + disparar Lambda vía SNS para detener EC2/RDS no esenciales.

Por qué: Las acciones de Presupuestos pasan de "solo alerta" a "aplicar". Combinar con Detección de Anomalías de Costos para detectar gastos no presupuestados.

Visibilidad a nivel de organización de las oportunidades de optimización de costos de S3.

S3 Storage Lens con métricas avanzadas + alcance a nivel de organización. Identifica candidatos para el nivel frío, oportunidades para el nivel IT, cargas multipartes abandonadas.

Por qué: El nivel gratuito cubre métricas básicas; el nivel avanzado muestra replicación, actividad, recomendaciones de optimización. Centralizado en la cuenta de auditoría/seguridad.

La factura de S3 sigue creciendo a pesar de las operaciones de eliminación.

Regla de ciclo de vida para abortar `incomplete multipart uploads` después de 7 días. Inspeccionar con `s3api list-multipart-uploads`.

Por qué: Las cargas fallidas dejan partes que se facturan como almacenamiento pero son invisibles en la lista de la consola. Fuga de costos común.

Datos de archivo frío accedidos como máximo una vez por trimestre.

S3 Glacier Flexible Retrieval (restauración de 1 a 12 horas). Para "nunca accedido" usar Deep Archive (recuperación de 12 horas, costo más bajo).

Por qué: Standard-IA mantiene el acceso en milisegundos; los niveles de Glacier intercambian el tiempo de acceso por una reducción de costo de ~80–95%.

Reducir el costo de salida de NAT Gateway para el tráfico de S3 + DynamoDB.

Puntos de conexión de VPC Gateway para S3 + DynamoDB (gratis). Enrutar el tráfico a través del punto de conexión, omitir NAT.

Por qué: NAT cobra por GB; los puntos de conexión de gateway son gratuitos. Para otros servicios de AWS, los puntos de conexión de interfaz reducen pero no eliminan el costo.

Carga de trabajo "charlatana" entre AZs; el costo de transferencia de datos domina la factura.

Co-ubicar microservicios en la misma AZ donde sea posible. Usar VPC Lattice o service mesh con enrutamiento de afinidad de AZ.

Por qué: El tráfico entre AZs cuesta $0.01/GB en cada dirección. La comunicación entre microservicios a escala se acumula. Intercambiar algo de alta disponibilidad por costo donde un 99.95% es suficiente.

El tráfico de salida a internet es el mayor elemento de la factura.

Poner CloudFront delante de todo. La salida de CloudFront a internet es más barata que la salida directa de EC2/ALB.

Por qué: El precio de salida de CloudFront está escalonado y es significativamente más bajo que la salida regional. El almacenamiento en caché reduce aún más la salida del origen.

Elegir entre Compute Savings Plan vs EC2 Instance Savings Plan vs Instancias Reservadas.

Compute SP: el más flexible (cualquier región, familia, SO) — descuento ligeramente menor. EC2 Instance SP: bloqueado por familia/región — descuento mayor. RI: casos raros que necesitan reserva de capacidad.

Por qué: Compute SP cubre Lambda + Fargate + EC2. Las RIs solo superan a los SPs cuando la reserva de capacidad es crucial; en la mayoría de los casos los SPs ganan.

Flota de procesamiento por lotes sin estado se ejecuta en Spot — tasa de interrupción demasiado alta.

Spot Fleet con estrategia optimizada por capacidad en muchos tipos de instancia + AZs.

Por qué: La estrategia de precio más bajo se concentra en un único grupo — alta interrupción. La optimizada por capacidad elige grupos con la mayor capacidad disponible.

Reducir el costo de cómputo en la capa web sin estado en ~20% sin reescribir.

Migrar a Graviton (ARM) — `c7g`, `m7g`, Lambda ARM, Aurora Graviton. Prueba de compatibilidad para binarios compilados.

Por qué: Graviton ofrece un rendimiento de precio ~20% mejor para la mayoría de las cargas de trabajo. Java/Python/Node "simplemente funcionan"; el código nativo puede necesitar recompilación.

Reducir el costo de un servicio Fargate de larga duración pero tolerante a interrupciones.

Fargate Spot a través de estrategia de proveedor de capacidad. Mezclar Spot + on-demand para tareas de alta disponibilidad.

Por qué: Fargate Spot es ~70% más barato. Las tareas reciben una advertencia de 2 minutos antes de la terminación — combinar con un drenaje elegante.

El costo de almacenamiento de CloudWatch Logs crece mes a mes.

Establecer retención por grupo de registros (el valor predeterminado es para siempre). Para almacenamiento a largo plazo, exportar a S3 + eliminar en CW. Usar la clase Logs Infrequent Access.

Por qué: Los registros de CW cuestan $0.03/GB de ingesta + almacenamiento para siempre. S3 Standard-IA a $0.0125/GB es más barato para acceso de archivo.

Reemplazar el monitoreo fragmentado con observabilidad unificada en todos los servicios.

CloudWatch ServiceLens para mapa de servicios; X-Ray para rastreos; CloudWatch Logs Insights para ad-hoc; Container Insights para ECS/EKS; RUM para navegador; Synthetics para canaries.

Por qué: La pila nativa de AWS evita agentes por host. Combinar con OpenTelemetry SDK para portabilidad.

Rastrear una solicitud a través de servicios en 5 cuentas.

Observabilidad entre cuentas de X-Ray. Las cuentas de origen comparten rastreos con la cuenta de monitoreo central a través de OAM.

Por qué: Sin OAM, los rastreos se fragmentan por cuenta. La agregación entre cuentas centraliza la vista de la ruta de la solicitud.

Ver métricas + registros + rastreos de múltiples cuentas en una consola de CloudWatch.

CloudWatch Observability Access Manager (OAM). Las cuentas de origen se vinculan a una cuenta de monitoreo a través de "sink" + "link".

Por qué: OAM es el tejido canónico de observabilidad multi-cuenta. Elimina el salto de consola por cuenta.

Lentitud del clúster de Aurora — identificar el SQL principal por evento de espera.

Performance Insights habilitado en el clúster. SQL principal por carga + análisis de espera sin volcado del registro de consultas.

Por qué: PI muestra eventos de espera con baja sobrecarga. Las métricas de CloudWatch te dicen que algo está lento, PI te dice qué.

Detectar automáticamente anomalías en DynamoDB / RDS / Lambda / ECS sin escribir umbrales de alarma.

Amazon DevOps Guru. Detección de anomalías basada en ML en métricas operacionales + eventos correlacionados.

Por qué: Los umbrales estáticos omiten modos raros. DevOps Guru aprende las líneas base y alerta sobre desviaciones de lo normal.

Parchear 5,000 instancias EC2 en un horario sin scripts por instancia.

SSM Patch Manager con líneas base de parches + ventanas de mantenimiento. Segmentación basada en etiquetas; aprobación automática de parches de seguridad después de N días.

Por qué: Patch Manager centraliza todo el ciclo de vida de los parches. Los scripts autogestionados se desvían y omiten nuevas instancias.

Remediar automáticamente fallos de reglas de Config (ej., SG abierto) sin aprobación humana.

Acción de remediación de Config invocando un documento de automatización de SSM. Preconstruido `AWS-DisablePublicAccessForSecurityGroup` etc.

Por qué: Config detecta; SSM Automation actúa. Bucle más ajustado que SNS → humano → ticket.

El pipeline "golden" de AMI/imagen de contenedor debe ser reproducible y estar al día con los parches.

Pipeline de EC2 Image Builder. AMI de origen → receta (componentes) → prueba → distribuir a regiones/cuentas.

Por qué: Reemplaza los scripts ad-hoc de Packer con un ciclo de vida gestionado. Programar reconstrucciones para la actualización mensual de parches.

Escaneo continuo de CVE en EC2 + imágenes ECR + Lambda.

Amazon Inspector v2 con habilitación a nivel de organización. Los hallazgos fluyen a Security Hub.

Por qué: Inspector v2 cubre EC2 + imágenes de contenedor + dependencias de Lambda en un solo servicio. La coincidencia manual de CVE es imposible a escala.

Validar que una aplicación de múltiples niveles puede cumplir con un RTO de 1 hora / RPO de 15 minutos.

AWS Resilience Hub. Definir política → evaluar aplicación → recomendaciones + runbooks automatizados.

Por qué: Resilience Hub formaliza las afirmaciones de RTO/RPO con pruebas concretas. Los runbooks manuales de DR se desvían.

Probar que el autoescalado y la conmutación por error funcionan bajo fallos reales, no los asumidos.

AWS Fault Injection Service (FIS). Experimentos basados en plantillas — eliminar instancias, limitar APIs, inyectar latencia. Ejecutar durante "Game Days".

Por qué: Ingeniería del caos como servicio. Un fallo real expone suposiciones frágiles; la lectura de runbooks no lo hace.

Conmutación por error multirregión — comprobación de preparación automatizada + evacuación zonal.

Route 53 Application Recovery Controller. Comprobaciones de preparación + controles de enrutamiento para la conmutación por error basada en celdas.

Por qué: Las comprobaciones de salud de Route 53 evalúan los endpoints. ARC añade planos de control activo/en espera para una conmutación por error explícita y auditada.

Actualizar la versión principal de RDS con capacidad de rollback.

Despliegues Blue/Green de RDS. Levantar un clon verde con la nueva versión; reproducir binlog; cambiar en <1 minuto.

Por qué: Una actualización mayor in-place es irreversible. Blue/Green mantiene la base de datos antigua activa hasta que el "cutover" se realiza con éxito.

Reducir el radio de impacto de despliegues defectuosos con auto-rollback.

CodeDeploy con configuración Canary (ej., `CodeDeployDefault.ECSCanary10Percent5Minutes`). Una alarma de CloudWatch dispara el rollback.

Por qué: Canary contiene el fallo al 10% durante 5 minutos. "All-at-once" es el máximo impacto; "rolling" distribuye pero sin puerta basada en tráfico.

Funciones Lambda sobreaprovisionadas en memoria.

Compute Optimizer para Lambda. Recomendaciones de ajuste de memoria a partir de perfiles de invocación.

Por qué: La máquina de estados AWS Lambda Power Tuning es la alternativa — Compute Optimizer es sin intervención manual.

Generar una política de IAM de menor privilegio a partir de la actividad observada en CloudTrail.

Generación de políticas de IAM Access Analyzer. Analiza CloudTrail para el rol; emite una política solo con las acciones utilizadas.

Por qué: Supera la tediosa tarea manual de `iam:Get*`, etc. Usar la política generada como punto de partida y luego revisar.

Fallo de conexión de EC2 a RDS — averiguar por qué sin capturas de paquetes.

VPC Reachability Analyzer. Análisis estático de tablas de rutas, SGs, NACLs, NAT, peering. Devuelve el bloqueador.

Por qué: Más rápido que tcpdump. Identifica la configuración específica (qué regla de SG, qué denegación de NACL).

Auditar qué rutas desde internet pueden alcanzar recursos internos.

VPC Network Access Analyzer. Las expresiones de alcance describen rutas prohibidas (ej., internet → capa de DB). Devuelve las rutas coincidentes.

Por qué: Reachability Analyzer es punto a punto; Network Access Analyzer es cumplimiento a nivel de alcance.

Ganancias rápidas en costos en toda la organización.

Chequeos de optimización de costos de Trusted Advisor (requiere soporte Business/Enterprise). ELBs inactivos, EC2 de baja utilización, EIPs no utilizados, utilización de RI.

Por qué: El nivel gratuito de TA es limitado; Business+ desbloquea todas las comprobaciones. La vista de la organización con administrador delegado muestra los hallazgos agregados.

Las "tormentas" de conexión de Lambda → RDS agotan las conexiones de la base de datos.

RDS Proxy. Agrupación de conexiones entre Lambda y RDS/Aurora. Conmutación por error más rápida (~66% de reducción).

Por qué: La concurrencia de Lambda crea una conexión por invocación en el peor de los casos. Proxy multiplexa en un pequeño pool.

La tasa de "cache miss" de contenido de cola larga en el origen es demasiado alta — el origen está bajo carga.

CloudFront Origin Shield en una región cerca del origen. Deduplica solicitudes en los bordes antes de llegar al origen.

Por qué: Sin Origin Shield, cada POP falla independientemente al origen. Shield reduce la tasa de aciertos al origen en un ~70%.

Acelerar la Migración y Modernización de Cargas de Trabajo

Trasladar (lift-and-shift) 200 servidores locales a EC2 con tiempo de inactividad mínimo.

AWS Application Migration Service (MGN). Replicación continua a nivel de bloque; "cut over" por servidor en minutos.

Por qué: MGN es la herramienta de rehost recomendada por AWS (reemplazó a SMS + CloudEndure). El "cut over" por servidor permite la migración basada en olas.

Migrar Oracle local a Aurora PostgreSQL con tiempo de inactividad mínimo.

Schema Conversion Tool (SCT) para reescritura de esquema + procedimientos. AWS DMS para carga completa + CDC.

Por qué: SCT aborda el código; DMS aborda los datos. CDC mantiene la fuente sincronizada hasta el "cutover".

Descubrir todas las bases de datos locales y evaluar la complejidad de la migración.

AWS DMS Fleet Advisor. Inventario + evaluación de flotas heterogéneas a escala.

Por qué: Fleet Advisor consolida el descubrimiento + dimensionamiento en un solo flujo de trabajo antes de lanzar trabajos de DMS.

Categorizar 500 aplicaciones para estrategia de migración.

Marco de las Siete Erres: Retirar (descomisionar), Retener (mantener en local), Reubicar (traslado a VMware Cloud), Rehost (MGN), Replatform (RDS en lugar de DB autogestionada), Recomprar (eliminar y SaaS), Refactorizar (microservicios).

Por qué: Portafolios más grandes mezclan las 7. El mapeo por aplicación temprano evita la deuda de migración de "talla única".

Construir el inventario de migración con dependencias antes de iniciar las olas.

AWS Application Discovery Service. Sin agente (escaneo de vCenter) o basado en agente (por servidor). Genera mapa de dependencias.

Por qué: Sin el mapeo de dependencias, la planificación por olas omite acoplamientos estrechos. Discovery los detecta automáticamente.

Rastrear cientos de migraciones de servidores + DB en curso a través de MGN, DMS, manual.

AWS Migration Hub como panel único. Agrega el estado de MGN, DMS, Refactor Spaces.

Por qué: Las consolas por herramienta fragmentan el estado. Migration Hub consolida y soporta la elaboración de informes de portafolio.

Mover 100 TB desde un sitio remoto sin ancho de banda WAN utilizable.

AWS Snowball Edge Storage Optimized. Enviar el dispositivo, copiar localmente, devolver a AWS. Múltiples dispositivos en paralelo para >80 TB.

Por qué: Snowmobile (45 PB) es para exabytes; Snowcone (8 TB) para pequeños. Edge es el caballo de batalla a escala de petabytes.

Replicación continua de datos de NFS local → S3 con límites de ancho de banda.

Agente de AWS DataSync. Tareas programadas; limitación de ancho de banda por tarea; modo de verificación de integridad.

Por qué: DataSync está diseñado específicamente y es 10 veces más rápido que rsync autogestionado sobre WAN. Snowball es offline; DataSync es online.

La aplicación local espera NFS/SMB pero los datos deben aterrizar en S3.

File Gateway en Storage Gateway. Caché local + backend S3; objetos accesibles también vía API de S3.

Por qué: Volume Gateway expone iSCSI; Tape Gateway emula VTL. File Gateway es el puente de NAS a S3.

Una empresa con gran uso de VMware desea capacidad en AWS sin reajustar vSphere/NSX.

VMware Cloud on AWS. La misma pila vSphere en hosts bare-metal de AWS. Usar HCX para migración en vivo.

Por qué: Preserva las herramientas operativas. Puente antes de refactorizar. Después, replataformar gradualmente a servicios nativos de AWS.

Contenerizar monolitos legacy de Java/.NET sin reescribir.

CLI de AWS App2Container. Inspecciona la aplicación en ejecución, genera artefactos de contenedor + manifiestos ECS/EKS.

Por qué: A2C captura la configuración en tiempo de ejecución (entorno, puertos, dependencias) en una imagen funcional. La contenerización manual omite dependencias no obvias.

Modernización de mainframe COBOL — convertir a microservicios Java.

Servicio AWS Mainframe Modernization con Blu Age (refactorización) o Micro Focus (replataformización). Elegir en función de la tolerancia a la emulación en tiempo de ejecución.

Por qué: Refactorizar desbloquea patrones nativos de la nube; Replataformar es más rápido pero emula el mainframe. Ambos reducen el costo de la licencia del mainframe.

Descomponer un monolito durante 18 meses sin congelar el desarrollo.

Patrón Strangler Fig. Colocar API Gateway/ALB delante del monolito; enrutar endpoints específicos a nuevos microservicios a medida que se extraen.

Por qué: Las reescrituras de "big-bang" suelen fallar. Strangler desacopla la transición por ruta, manteniendo el monolito funcional durante la transición.

Quiero extraer microservicios incrementalmente sin ser dueño del plano de enrutamiento.

AWS Migration Hub Refactor Spaces. Abstracción gestionada de aplicación/ruta/servicio sobre API Gateway + VPCs.

Por qué: Ahorra escribir la infraestructura del "strangler fig". Enrutamiento preconstruido + conectividad VPC para extracción incremental.

PostgreSQL autogestionado en EC2 → RDS para operaciones gestionadas.

DMS para "cutover" con CDC. Usar RDS Custom solo si necesitas acceso al SO o extensiones específicas del proveedor.

Por qué: RDS maneja copias de seguridad/parches/HA. RDS Custom es una salida de emergencia para necesidades heredadas pero reintroduce la carga operativa.

Mover de RDS MySQL a Aurora MySQL para rendimiento + costo.

Réplica de lectura de Aurora desde RDS, luego promover. O DMS para tiempo de inactividad cero cuando las diferencias de versión importan.

Por qué: La ruta de réplica de lectura es la más simple en el motor. DMS maneja las diferencias de versión y los movimientos heterogéneos.

La empresa desea financiación para la migración a AWS + un marco de mejores prácticas.

Programa de Aceleración de Migraciones de AWS (MAP). Fases: Evaluar (MRA), Movilizar (socio MAP + herramientas), Migrar y Modernizar.

Por qué: MAP desbloquea financiación y una metodología estructurada. Omitir MAP significa perder ambos.

Estimación de costos previa a la migración para el patrocinador ejecutivo.

Calculadora de Precios de AWS (configuración diseñada) + Migration Evaluator (basado en datos del inventario local).

Por qué: La Calculadora de Precios ofrece precios "what-if". Migration Evaluator ingiere datos de vSphere/Hyper-V para proyectar ahorros reales.

Desmantelar servidores SFTP autoalojados; los socios proveedores necesitan seguir usando SFTP.

AWS Transfer Family (SFTP/FTPS/FTP) respaldado por S3 o EFS.

Por qué: Servicio de protocolo gestionado. Usuarios mapeados en IAM; puntos de conexión solo de VPC. Evita ejecutar daemons SSH en EC2.

Trasladar (lift-and-shift) recursos compartidos de archivos de Windows con integración de AD.

Amazon FSx para Windows File Server. Unido a AD; SMB; DataSync para sincronización online desde el entorno local; Snowball para grandes volúmenes.

Por qué: FSx para Windows es la zona de aterrizaje nativa de AD. EFS es solo para Linux; S3 carece de semántica SMB.

Migrar cargas de trabajo de NetApp ONTAP manteniendo todas las características de NetApp (snapshots, FlexClone).

Amazon FSx para NetApp ONTAP. APIs nativas de ONTAP; multi-protocolo NFS+SMB; replicación SnapMirror desde el entorno local.

Por qué: Otras variantes de FSx no exponen características específicas de ONTAP. Trasladar (lift-and-shift) NetApp sin re-arquitectar copias de seguridad/replicación.

La transición basada en DNS corre el riesgo de tener elementos residuales en la caché de DNS.

Transicionar detrás de CloudFront / ALB / Global Accelerator. Cambiar el backend sin modificar el DNS público.

Por qué: Las cachés respetan el TTL, pero los clientes/firewalls almacenan en caché agresivamente. Una dirección pública estable aísla de los "stragglers" de DNS.

Migración gradual de tráfico de local a AWS para control de riesgo.

Enrutamiento ponderado de Route 53. Iniciar 1% → AWS, aumentar gradualmente. Comprobaciones de salud para "failback" automático.

Por qué: El enrutamiento ponderado permite la migración tipo "canary" en la capa DNS. ARC añade puertas explícitas para transiciones de mayor riesgo.

Rastrear licencias BYOL de Windows / Oracle / SQL Server en cargas de trabajo migradas.

AWS License Manager. Definir reglas; aplicar en el lanzamiento; compartir vía RAM en toda la organización.

Por qué: El incumplimiento de BYOL es costoso. License Manager previene el sobredespliegue accidental.

Después de la migración, las instancias de RDS de desarrollo/prueba están sobreaprovisionadas durante la noche.

Migrar desarrollo/prueba a Aurora Serverless v2 con ACU mínimo bajo. Autoescalar hacia abajo cuando está inactivo.

Por qué: Ahorra costos nocturnos por inactividad sin la complejidad de un programador de instancias.

Ejecutar Kubernetes en el entorno local con las mismas herramientas que EKS durante la migración.

EKS Anywhere en hardware local. Mismas versiones de Kubernetes + ECR + integración con AWS Outposts.

Por qué: Un plano de control consistente reduce la deriva de habilidades del operador. La migración posterior a EKS es un movimiento de carga de trabajo, no una reescritura de herramientas.