Guía - SAP-C02 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.