Una guía compacta organizada por los cuatro dominios del examen. Cada tema trae un resumen, los servicios clave, criterios para decidir entre opciones y enlaces a la documentación oficial que respalda cada afirmación.
Dominio 1: Arquitecturas seguras (30%)
1.1 Acceso seguro a los recursos
Aquí se evalúa quién puede hacer qué en tus cuentas. La base es dar permisos mínimos, usar roles con credenciales temporales en lugar de claves fijas y separar cuentas con una organización. Para personas, personal de la empresa o usuarios de una app, cada caso tiene su servicio de identidad.
Servicios clave: IAM, IAM Identity Center, AWS Organizations, Amazon Cognito, AWS STS.
Cómo decidir
- Cuando una aplicación en EC2 o Lambda deba usar otros servicios de AWS, asígnale un rol de IAM: recibe credenciales temporales y evitas dejar claves permanentes en el código o en archivos. Fuente
- Para dar acceso a empleados a varias cuentas con un único inicio de sesión, usa IAM Identity Center; no crees un usuario IAM por persona y por cuenta. Fuente
- Para los usuarios finales de tu aplicación web o móvil, elige Amazon Cognito, no IAM: IAM está pensado para identidades de tu equipo y tus cargas de trabajo. Fuente
- Una SCP actúa como techo de permisos para las cuentas de una organización, pero por sí sola no autoriza nada: la acción debe estar permitida además en una política de IAM. Fuente
Documentación oficial
1.2 Cargas de trabajo y aplicaciones seguras
Se trata de proteger la red y la aplicación en capas: subredes públicas y privadas, reglas de tráfico, filtrado de ataques web y manejo de secretos. El examen suele plantear un escenario con requisitos de aislamiento y pide la combinación de controles más simple que los cumpla.
Servicios clave: Amazon VPC, Security groups, Network ACL, AWS WAF, AWS Shield, Secrets Manager, VPC endpoints.
Cómo decidir
- Un security group es con estado y solo tiene reglas de permiso; una network ACL no tiene estado y admite reglas de permiso y de denegación. Si necesitas bloquear una IP concreta, piensa en la ACL. Fuente
- Para que instancias en una subred privada salgan a internet sin ser accesibles desde fuera, usa una NAT gateway en una subred pública. Fuente
- Para detectar y bloquear peticiones web con SQL malicioso o scripts inyectados (XSS), define reglas en AWS WAF y asócialas a tu balanceador, CloudFront o API Gateway. Fuente
- Para llegar a un servicio de AWS desde una VPC sin pasar por internet, usa un VPC endpoint (PrivateLink o de tipo gateway) en vez de una NAT. Fuente
- Si las contraseñas de base de datos deben rotarse de forma automática, guárdalas en Secrets Manager en lugar de variables de entorno o archivos de configuración. Fuente
Documentación oficial
1.3 Controles de seguridad de los datos
Aquí importa cómo se cifran, se protegen y se retienen los datos, tanto en reposo como en tránsito. Debes saber elegir entre claves administradas por AWS y claves propias, y cuándo exigir inmutabilidad o copias de seguridad centralizadas.
Servicios clave: AWS KMS, Amazon S3, AWS Certificate Manager, S3 Object Lock, AWS Backup, Amazon Macie.
Cómo decidir
- Si necesitas decidir tú la política de la clave y gestionar su rotación, crea una clave administrada por el cliente en KMS en lugar de depender de una clave administrada por AWS. Fuente
- Los objetos nuevos de S3 se cifran en reposo por defecto; la decisión de examen suele ser qué tipo de clave usar (SSE-S3, SSE-KMS o claves del cliente), no si se cifra. Fuente
- Para cifrar en tránsito con HTTPS en un balanceador o CloudFront, solicita el certificado a AWS Certificate Manager, que se integra con esos servicios y gestiona la renovación. Fuente
- Si una norma exige que los objetos no puedan borrarse ni modificarse durante un plazo, usa S3 Object Lock, que aplica un modelo de escribir una vez y leer muchas. Fuente
- Para localizar datos personales almacenados en buckets de S3, el servicio indicado es Amazon Macie. Fuente
Documentación oficial
Dominio 2: Arquitecturas resilientes (26%)
2.1 Arquitecturas escalables y desacopladas
El objetivo es que los componentes no dependan unos de otros para funcionar ni para escalar. Se logra con colas, notificaciones, eventos y servicios sin servidor, de modo que un pico en un lado no tumbe al otro. Hay que distinguir qué mensajería corresponde a cada patrón.
Servicios clave: Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Lambda, AWS Step Functions, Amazon API Gateway, EC2 Auto Scaling.
Cómo decidir
- Si un productor debe entregar trabajo a consumidores que lo procesan a su ritmo, usa SQS; si un mensaje debe llegar a muchos suscriptores a la vez, usa SNS. Fuente
- Para repartir un mismo evento a varias colas, combina SNS con varias colas SQS suscritas (abanico); cada cola procesa su copia por separado. Fuente
- Si el orden de los mensajes y evitar duplicados importan, elige una cola FIFO en lugar de una estándar. Fuente
- Para reaccionar a eventos de servicios de AWS o de aplicaciones SaaS mediante reglas de enrutamiento, usa EventBridge. Fuente
- Si un proceso tiene varios pasos con reintentos y ramas, coordínalo con Step Functions en lugar de encadenar funciones Lambda a mano. Fuente
Documentación oficial
2.2 Alta disponibilidad y tolerancia a fallos
Se evalúa cómo mantener un servicio en pie ante la caída de una instancia, una zona de disponibilidad o una región. Cada nivel de protección cuesta más, así que la respuesta correcta depende del tiempo de recuperación y de la pérdida de datos que tolera el negocio.
Servicios clave: Elastic Load Balancing, Amazon Route 53, RDS Multi-AZ, Amazon Aurora, S3 replication, AWS Backup.
Cómo decidir
- Distribuye las instancias en varias zonas de disponibilidad detrás de un balanceador de carga: así una zona caída no detiene el servicio. Fuente
- Multi-AZ con una instancia en espera sirve para la conmutación por error, pero esa instancia no atiende lecturas; un clúster Multi-AZ tiene dos instancias en espera que sí pueden leer. Para escalar lecturas, usa réplicas de lectura. Fuente
- Para dirigir el tráfico a una región de respaldo cuando la principal falla, usa una política de enrutamiento de conmutación por error en Route 53 con comprobaciones de estado. Fuente
- Ordena las estrategias de recuperación ante desastres de menor a mayor costo y rapidez: copia y restauración, luz piloto, espera activa y multisitio activo-activo. Fuente
- Si la base de datos debe sobrevivir a la caída de una región completa con recuperación rápida, considera Aurora Global Database. Fuente
Documentación oficial
Dominio 3: Arquitecturas de alto rendimiento (24%)
3.1 Almacenamiento de alto rendimiento
Cada tipo de almacenamiento encaja con un patrón de acceso: bloque para una instancia, archivos compartidos para muchas, objetos para datos masivos. En el examen eliges el servicio por el protocolo, la latencia y el nivel de rendimiento que pide el escenario.
Servicios clave: Amazon EBS, Amazon EFS, Amazon FSx, Amazon S3, Instance store.
Cómo decidir
- Para un disco de arranque o una base de datos en una sola instancia, usa EBS; para cargas con muchas operaciones por segundo y baja latencia, elige volúmenes de IOPS aprovisionadas. Fuente
- Si varias instancias Linux deben compartir un sistema de archivos que crece solo, usa EFS. Fuente
- Para cómputo de alto rendimiento o aprendizaje automático con lectura masiva de datos de S3, FSx for Lustre es la opción pensada para ello. Fuente
- Si necesitas almacenamiento temporal de latencia muy baja y los datos pueden perderse al detener la instancia, el instance store es suficiente. Fuente
Documentación oficial
3.2 Cómputo de alto rendimiento y elástico
Se trata de escoger el modelo de cómputo adecuado y hacerlo crecer o encogerse con la demanda. Instancias, contenedores y funciones tienen distintos compromisos entre control, esfuerzo operativo y tiempo de arranque.
Servicios clave: Amazon EC2, EC2 Auto Scaling, AWS Lambda, AWS Fargate, Amazon ECS, Amazon EKS.
Cómo decidir
- Para correr contenedores sin gestionar los servidores que los alojan, elige Fargate; si necesitas controlar las instancias donde corren, usa ECS o EKS sobre EC2. Fuente
- Para evitar arranques en frío en una función con latencia exigente, configura concurrencia aprovisionada. Fuente
- Para mantener una métrica como el uso de CPU cerca de un valor objetivo, usa una política de escalado de seguimiento de destino en el grupo de Auto Scaling. Fuente
- Para instancias que se comunican con latencia mínima entre sí, un grupo de ubicación de tipo clúster; para reducir el riesgo de fallos simultáneos, uno de tipo dispersión. Fuente
- Elige la familia de instancia según el cuello de botella: optimizadas para cómputo, memoria o almacenamiento, o con GPU para aprendizaje automático. Fuente
Documentación oficial
3.3 Bases de datos de alto rendimiento
Debes emparejar el tipo de dato y el patrón de acceso con el motor correcto: relacional, clave-valor, caché o análisis. También entran las técnicas para escalar lecturas y proteger la base ante muchas conexiones.
Servicios clave: Amazon Aurora, Amazon RDS, Amazon DynamoDB, DAX, Amazon ElastiCache, RDS Proxy, Amazon Redshift.
Cómo decidir
- Para repartir lecturas, añade réplicas; en Aurora hasta 15 réplicas comparten el mismo volumen del clúster que el escritor, y por eso su desfase es mínimo. Fuente
- Si el acceso es por clave con latencia de milisegundos a gran escala y sin esquema rígido, DynamoDB suele encajar mejor que una base relacional. Fuente
- Para bajar las lecturas de DynamoDB a microsegundos sin reescribir la aplicación, añade DAX como caché. Fuente
- Para aliviar consultas repetidas contra cualquier base, pon ElastiCache delante como caché en memoria. Fuente
- Si muchas funciones Lambda abren conexiones simultáneas y saturan RDS, interpón RDS Proxy: mantiene un grupo de conexiones que se reutilizan. Fuente
Documentación oficial
3.4 Redes de alto rendimiento y escalables
Cubre cómo acercar el contenido al usuario, balancear el tráfico y conectar VPC y centros de datos. Cada servicio de red resuelve un problema distinto de latencia, ancho de banda o topología.
Servicios clave: Amazon CloudFront, AWS Global Accelerator, Elastic Load Balancing, AWS Direct Connect, Site-to-Site VPN, Transit Gateway, VPC peering, Network Load Balancer.
Cómo decidir
- Para servir contenido estático o dinámico con baja latencia a usuarios dispersos, usa CloudFront, que lo guarda en ubicaciones de borde. Fuente
- Si necesitas direcciones IP estáticas de entrada y que el tráfico viaje por la red global de AWS hacia el endpoint más cercano, usa Global Accelerator. Fuente
- Para enrutar peticiones según su contenido (ruta, host o cabeceras) usa un Application Load Balancer, que trabaja en la capa de aplicación. Fuente
- Direct Connect ofrece un enlace dedicado entre tu red y AWS con un rendimiento más estable que el de una conexión por internet. Fuente
- El emparejamiento de VPC no es transitivo: si A se empareja con B y con C, B y C no se comunican a través de A; hace falta otro emparejamiento o una alternativa como Transit Gateway. Fuente
Documentación oficial
3.5 Ingesta y transformación de datos
Aquí se decide cómo entran los datos a AWS, cómo se transforman y cómo se consultan. Hay que distinguir entre flujos en tiempo real y cargas por lotes.
Servicios clave: Kinesis Data Streams, Amazon Data Firehose, AWS Glue, Amazon Athena, AWS Lake Formation, AWS DataSync.
Cómo decidir
- Si varias aplicaciones deben leer en paralelo el mismo flujo de datos en tiempo real (por ejemplo, archivar y analizar), usa Kinesis Data Streams. Fuente
- Para consultar con SQL datos que ya están en S3 sin montar servidores, usa Athena. Fuente
- Para transformar y catalogar datos con un servicio ETL sin servidores, usa AWS Glue. Fuente
- Para copiar grandes volúmenes entre un almacenamiento local y AWS por la red, de forma programada y automatizada, usa DataSync. Fuente
- Cuando tus socios suban archivos mediante SFTP o FTPS, AWS Transfer Family los recibe y los deja directamente en S3 o EFS. Fuente
Documentación oficial
Dominio 4: Arquitecturas optimizadas en costos (20%)
4.1 Almacenamiento optimizado en costos
La clave es pagar por el nivel de acceso que realmente necesitas. Mover datos fríos a clases más baratas, borrar lo que caduca y no sobredimensionar discos reduce la factura sin cambiar la aplicación.
Servicios clave: Clases de almacenamiento de S3, S3 Lifecycle, S3 Intelligent-Tiering, Amazon EBS, Data Lifecycle Manager, AWS Backup.
Cómo decidir
- Si el patrón de acceso es desconocido o cambia, S3 Intelligent-Tiering mueve los objetos entre niveles automáticamente. Fuente
- Si el patrón es conocido y los datos se enfrían con el tiempo, define reglas de ciclo de vida que los transfieran a clases más económicas o los expiren. Fuente
- Para archivos que casi nunca se leen y pueden tardar en recuperarse, las clases de archivo de S3 Glacier cuestan menos que S3 Standard. Fuente
- Para automatizar la creación y retención de instantáneas de EBS y evitar acumularlas, usa Data Lifecycle Manager. Fuente
Documentación oficial
4.2 Cómputo optimizado en costos
Se evalúa cómo comprar y dimensionar cómputo. Los descuentos por compromiso sirven para carga estable, Spot para carga tolerante a interrupciones y el dimensionamiento correcto evita pagar capacidad ociosa.
Servicios clave: Savings Plans, Instancias reservadas, Instancias Spot, AWS Compute Optimizer, AWS Lambda, EC2 Auto Scaling.
Cómo decidir
- Para una carga estable y continua durante uno o tres años, un Savings Plan o instancias reservadas rebajan el precio frente a bajo demanda. Fuente
- Para trabajos por lotes o tareas que toleran interrupciones, las instancias Spot ofrecen el mayor descuento, a cambio de que AWS pueda recuperarlas. Fuente
- Para una carga impredecible o de baja frecuencia, el modelo de pago por uso de Lambda evita pagar capacidad inactiva. Fuente
- Para saber si una instancia está sobredimensionada, consulta las recomendaciones de AWS Compute Optimizer. Fuente
Documentación oficial
4.3 Bases de datos optimizadas en costos
El ahorro viene de ajustar el motor, el modo de capacidad y el compromiso al uso real. Una base que apenas se usa o que varía mucho no debería facturarse como una de carga constante.
Servicios clave: Amazon RDS, Amazon Aurora Serverless, Amazon DynamoDB, Instancias reservadas de RDS.
Cómo decidir
- Para una base relacional con carga variable o impredecible, Aurora Serverless ajusta la capacidad a la demanda y cobra solo lo que se consume. Fuente
- Para una base RDS de uso estable y duradero, las instancias reservadas reducen el costo frente a bajo demanda. Fuente
- En DynamoDB, el modo bajo demanda conviene con tráfico impredecible; el modo aprovisionado, con tráfico predecible. Fuente
- Para tablas de DynamoDB con datos poco consultados, la clase de tabla Standard-IA reduce el costo de almacenamiento. Fuente
Documentación oficial
4.4 Redes optimizadas en costos
En redes el costo escondido suele ser la transferencia de datos y los componentes siempre activos. Aprende a evitar salidas innecesarias por la NAT y a acercar el contenido al usuario.
Servicios clave: NAT gateway, VPC endpoints, Amazon CloudFront, AWS Direct Connect, Transit Gateway.
Cómo decidir
- Si tu VPC consulta S3 o DynamoDB, un endpoint de tipo gateway evita que ese tráfico pase por la NAT gateway y no añade ningún cobro propio. Fuente
- La NAT gateway cobra por hora y por GB procesado; si la mayor parte del tráfico va hacia servicios que admiten endpoints, crearlos reduce ese cargo. Fuente
- Servir contenido desde CloudFront puede reducir la carga y la transferencia desde el origen frente a servirlo siempre desde él. Fuente
- Para grandes volúmenes de transferencia hacia tu red local, Direct Connect puede reducir los costos de red frente a hacerlo por internet. Fuente
Documentación oficial