DEV Community: Laura Bolaños

Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 2

Laura Bolaños — Thu, 04 Jun 2026 13:41:05 +0000

Segunda parte de las notas de examen. La idea es que identifiques los principales temas para el examen de certificación y conocer algunos tips de estudio para alcanzar con éxito tu meta 🎓

⬅ Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 1

Temas que son claves conocer para el examen - Segunda Parte

AWS Config

Es prioritario revisar todas sus casos de uso y su integración con acciones de remediación con SSM y sus runbook. La remediación puede ser manual o automática.

La integración importante es con EventBridge para realizar una acción. Algo a saber es que los avisos a un equipo de soporte se hacen a través de SNS.
Data Aggregation for AWS Config (Multi-Account - Multi-Region) ➡ recopila datos de configuración y cumplimiento de varias cuentas y varias regiones de AWS. Una organización en AWS Organizations y todas las cuentas de esa organización que tengan AWS Config habilitado.
Reglas de configuración comunes en AWS Config:

Rule	Qué chequea
`cloudtrail-enabled`	CloudTrail habilitado en la cuenta
`mfa-enabled-for-iam-console-access`	Los usuarios de IAM con acceso a la consola tienen MFA habilitado
`s3-bucket-public-read-prohibited`	Los buckets de S3 no permiten acceso de lectura pública
`encrypted-volumes`	Los volúmenes de EBS están encriptados
`rds-storage-encrypted`	Las instancias RDS tienen encriptación del storage habilitada
`iam-password-policy`	La política de contraseñas cumple con los requisitos especificados
`restricted-ssh`	Los Security Groups no permiten acceso SSH sin restricciones (puerto 22)
`root-account-mfa-enabled`	La cuenta root tiene MFA habilitado
`vpc-flow-logs-enabled`	VPC Flow Logs está activado
`cloud-trail-encryption-enabled`	Los logs de CloudTrail están encriptados con KMS
`s3-bucket-ssl-requests-only`	S3 solo acepta requests HTTPS
`ec2-instances-in-vpc`	Las instancias EC2 están dentro de una VPC
`access-keys-rotated`	Las access keys de IAM se rotan dentro de N días

Control Tower

Relacionado con casos de uso de Organization ➡ Proporciona una landing zone para múltiples cuentas. Automatiza la configuración de AWS Organizations, la venta de cuentas, las medidas de seguridad (controles preventivos y de detección) y un registro de auditoría centralizado.

Security Hub - WAF - Detective - Inspector - GuardDuty

Es útil realizar cuadro comparativo con los servicios Detective, Inspector y GuardDuty para visualizar sus diferencias y en qué casos de uso son más adecuados. La mayoría se utilizan para controles de detección.

Security Hub: gestiona la postura o posición de seguridad de una Organización. Automatiza las comprobaciones de mejores prácticas y agrega alertas de Seguridad.
WAF: los casos de uso referidos son sencillos de identificar, detección de ataques sql injection - bloqueo de ip de países-rate limiting por IP, etc. Se gestiona mediante Web ACLs con reglas propias o AWS Managed Rules (reglas preconfiguradas por AWS)
Inspector: Evalúa automáticamente vulnerabilidades en EC2, ECR y funciones Lambda ➡ prevención y detección proactiva.
Detective: simplifica el proceso de analizar, investigar e identificar la causa raíz de los hallazgos de seguridad o actividades sospechosas en las cuentas de AWS. Recopila registros de CloudTrail (frase clave es log de APIs), VPC Flows, GuardDuty, entre otros ➡ Actúa en el post-incidente.
GuardDuty: Detección de amenazas continua mediante análisis de CloudTrail, VPC Flow Logs y DNS logs. Usa ML para identificar comportamiento anómalo (ej: instancia EC2 haciendo crypto mining, credenciales filtradas usadas desde IP sospechosa). Es el detector en tiempo real, genera findings que pueden disparar acciones en EventBridge → Lambda/SNS.

Conceptos básicos de Networking

NACL: Actúan a nivel de subnet y no tienen estado. Hay que agregar reglas de entrada y de salida. Las reglas se evalúan de manera ascendente. Es el primer mecanismo de defensa a nivel subred, útil para bloquear IPs específicas. Ejemplo de resolución de problema: una instancia EC2 (en una private subnet) no tiene salida a internet? ➡ Las reglas de entrada y salida deben permitir el tráfico (incluidos los puertos de retorno efímeros 1024–65535).
Security groups: Actúan a nivel de instancia o servicio. Tienen estado, todo lo que se permite entrar- se permite salir (salvo que indiques lo contrario en las reglas de salida).
- Resolución de conexiones vía SSH o RDP a instancias EC2. Qué revisar? En principio las reglas de entrada del Security Group a los puertos correspondientes.
Nat Gateway: es escalable mejor que Instance Nat Gateway. Asociada a una subnet pública. Solo para IPV4. Asegurar que la Private subnet route table debe tener
Egress-Only Internet Gateway (EIGW): permite que los recursos en una subred privada se comuniquen con el exterior a través de IPv6

VPC FlowLogs

VPC > Your VPCs > Flow logs > Create Flow Logs (se necesita un rol para escribir en CloudWatch). Monitorea todo el trafico de la VPC determinada aparece en CloudWatch > Logs > Log Management .
Otros destinos de logs son S3 y Kinesis Data Firehose. Se puede realizar consultas sql mediante Athena tomando como fuente S3.
Conocer el formato de los registros Default VPC Flow Logs y Custom VPC Flow Log Format. Cómo configurar y qué soportes permite resolver.

Ejemplo cuando falta una regla en Nacl o Security Group para permitir una conexión:

2 123456789012 eni-abc123 10.0.1.4 10.0.2.5 43234 443 6 12 1400 1624387215 1624387275 ACCEPT OK

2 123456789012 eni-abc123 172.31.16.139 172.31.16.21 80 42333 6 24 2456 1624387215 1624387275 REJECT OK

Route 53

Hosted zone ➡ pública y privada. Comprender el concepto de casos de uso: El cliente externo consulta la zona pública de Route 53 y llega a la versión pública de la app y el cliente interno dentro de la VPC consulta la zona privada de Route 53 y llega a la versión interna de la app ➡ ambos pueden tener el mismo nombre laub.com pero devuelven destinos diferentes de acuerdo de donde se lo consulte.
Es primordial conocer los tipos de registros y casos de usos:

Tipo	Qué contiene	Uso
`A`	IPv4	www.laub.com → 52.10.1.100
`AAAA`	IPv6	www.laub.com → 2001:db8::1
`CNAME`	Otro hostname	www → otro.dominio.com
`Alias`	Recurso AWS	laub.com → mi-alb.us-east-1.elb.amazonaws.com
`NS`	Name servers de la zona	Delegación de subdominios
`SOA`	Metadatos de la zona	Se crea automático
`MX`	Servidor de correo	laub.com → mail.empresa.com
`TXT`	Texto libre	Verificación de dominio, SPF
`SRV`	Servicio + puerto	Usado por algunos protocolos
`PTR`	DNS inverso	IP → hostname

Route 53 Resolver: define cómo y hacia dónde se hacen las consultas DNS.
- En esta feature se da la relación de entornos híbridos, DNS de on-premises resuelto por Route 53 (Outbound endpoint) o un DNS en AWS (en VPC) que lo resuelve on-premises (Inbound endpoint).
Route 53 routing policies, hay preguntas de examen sobre estas features relacionados con estrategias de deployment o failover:

Política	Descripción	Health Checks	Caso de Uso
Simple	Un único servidor. Sin lógica ni failover.	No soporta	Un solo recurso sin redundancia
Weighted	Distribución de tráfico por pesos.	Soportado — si falla un destino su peso es ignorado	Deployment canary, A/B testing
Latency	Dirige el tráfico al recurso con menor latencia.	Soportado	Usuarios globales que necesitan baja latencia
Geolocation	Enruta según la ubicación geográfica del origen de la consulta DNS (continente, país o estado).	Soportado	Contenido regionalizado, cumplimiento normativo
Geoproximity	Enruta según ubicación geográfica de los recursos con valor de sesgo opcional. Requiere Route 53 Traffic Flow.	Soportado	Balanceo geográfico con control fino de fronteras
Failover	Enruta a recurso principal; si falla va al secundario. Recursos en VPC privada requieren CloudWatch Alarm como intermediario.	Requerido	Alta disponibilidad activo-pasivo
IP-Based	Enruta según la IP del remitente de la consulta DNS.	Soportado	Segmentación por ISP o rango de IPs corporativas
Multivalue Answer	Devuelve hasta 8 registros saludables al azar.	Soportado	Distribución simple sin necesidad de ELB
Cross Account	La zona padre delega un subdominio creando registros NS que apuntan a la zona hija en otra cuenta.	—	Gestión de DNS entre múltiples cuentas AWS

Query Logging: Registra todas las consultas DNS está disponible para zonas públicas., con esto podemos resolver problemas. Auditar consultas DNS de una zona privada ➡ no es Route 53 query logging, es Route 53 Resolver Query Logs (servicio diferente).
Tipos de Health checks: Es un concepto básico a retener ➡Endpoint health check, Calculated health check y CloudWatch alarm health check.

Cálculo de CIDR para un Subnet

En una VPC no se puede superponer el bloque de direcciones cidr de sus subnet ➡ ejemplo encontrar el tamaño mínimo de la subred que tenga 30 direcciones IP disponibles.

Total de direcciones IP disponibles = 2^(32-X) – 5 (Reservadas por AWS)

Donde X es la notación CIDR.

Para el bloque CIDR 192.168.1.0/26.

Total de direcciones IP disponibles = 2^(32-26) – 5 = 59 direcciones IP.

AWS Global Accelerator

Si enfrentas alguna pregunta que necesitas tiempos de milisegundos con direcciones IP anycast estáticas ➡ la respuesta seguramente es Global Accelerator.

Frases claves para este servicio: aceleración del tráfico TCP/UDP.

VPC Peering - Transit Gateway

VPC peering: Conocer las limitaciones de ➡ hasta 10 interconexiones de VPC es potable. No hay transitividad en las conexiones. Es conveniente realizar laboratorio para entender cómo se configuran las Route Tables. Tener presente que se puede realizar conexiones entre diferentes regiones y cuentas.
- Solucionar conexion de VPC Peering entre dos instancias de EC2 en dos VPC diferentes. Se configuró correctamente el VPC peering entre ambas. Una instancia A puede hacer ping a instancia B. Pero la instancia B no puede hacer ping a la instancia A ➡ Posiblemente para solucionar este problema es necesario actualizar el grupo de seguridad de la instancia A para permitir el tráfico ICMP entrante.
Transit Gateway: actúa como una hub de redes eliminando la necesidad de complejas redes de interconexión. A diferencia de VPC peering tiene ruteo transitivo. Importante! conocer el concepto de adjuntar una VPC (Attach a VPC).
- Soporta multicast.
- Se puede usar con VPN y Direct Connect como hub central, simplificando arquitecturas híbridas.
- TGW Route Tables permiten segmentar el tráfico entre VPCs conectadas.Ejemplo ➡ aislar producción de desarrollo.

Cloudfront

Comprender cómo configurar los diferentes orígenes. El más sencillo y natural que conocemos, si has rendido alguna certificación, es S3. Pero vas a tener que preparar ELB y el caso especial de EC2:

Origin Type	Description	Clave para el examen
Amazon S3	Contenido estático	OAC reemplaza OAI (legacy). Sin OAC, el bucket puede quedar público
Application Load Balancer	Contenido dinámico	El ELB debe ser público. CloudFront no puede llegar a un ALB interno. Usá security group del ALB restringido a los IPs de CloudFront para que el tráfico solo entre por CloudFront
EC2 instance	Servidores web custom	La instancia debe ser pública y con security group que permita IPs de CloudFront
API Gateway	REST o HTTP APIs	Podés deshabilitar el endpoint público de APIGW y forzar acceso solo vía CloudFront
Custom HTTP origin	Servidores on-premise u otros	Requiere HTTPS con certificado válido si usás HTTPS entre CloudFront y el origen

Qué pasa cuando hay pocos cache hit (Cache Hit bajo)?
- Revisar el TTL , si es muy bajo, los objetos expiran rápido y van al origen frecuentemente.
- Revisar la Cache Key , si incluye headers, cookies o query strings innecesarios, fragmenta el caché y baja el hit rate. La solución es usar Cache Policies para controlar qué forma parte de la cache key.
Qué hacer cuando lo cacheado quedó antiguo, cómo resolver inmediatamente sin esperar que expire el TTL?
- Invalidación de caché (CreateInvalidation) hace que CloudFront descarte el objeto antes del TTL.
- Alternativa más eficiente para el examen: versionado de archivos en el nombre (app.v2.js), evita invalidaciones y es la práctica recomendada por AWS.
Behavior (comportamiento): analizar las variantes. Es útil realizar laboratorios.
- Permiten definir reglas distintas por path pattern (/api/*, /images/*, /static/*).
- Cada behavior puede tener su propio origen, TTL, política de caché y restricciones de acceso.
- Caso de uso común: /api/* apunta a ALB (dinámico, sin caché) y /* apunta a S3 (estático, con caché larga).

VPC Endpoints

Es clave conocer los tipos de punto final para aplicar seguridad a la conexión de servicios aws (sin pasar por internet).

Gateway Endpoint : Es sin costo, solo para conectar con S3, DynamoDB. Importante para sortear preguntas, solo tiene utilidad dentro de una VPC, no tiene la capacidad de acceso externo. También admite políticas de punto final para controlar el acceso.
Interface Endpoint (PrivateLink): Tiene costo. Crea una ENI con IP privada en tu VPC para conectarse a servicios de AWS (y servicios de terceros). Permite el acceso desde on-premise si existe conectividad previa (VPN/Direct Connect). Admite políticas de punto final para controlar qué entidades principales pueden usarlo.
- Al crearlo AWS genera DNS privados para el servicio, si Enable Private DNS está activado, las llamadas al endpoint público se resuelven automáticamente a la ENI privada. Resolución de problemas: si el tráfico sigue saliendo a internet a pesar de tener un Interface Endpoint → verificar que Enable Private DNS esté activado.

⬅ Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 1

Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 1

Laura Bolaños — Thu, 04 Jun 2026 03:00:00 +0000

Primera parte de los apuntes del examen. La idea es que identifiques los principales temas para el examen de certificación y conocer algunos tips de estudio para alcanzar con éxito tu meta 🎓

Características generales

La complejidad es de nivel medio. A mi criterio lo más complejo son las diferentes formas de soporte vía SSM.

Consta de 5 dominios y toda la información detallada la podemos encontrar aquí.

Solo se puede rendir en inglés, con lo cual es prioritario estudiar con apuntes, entrenamiento de preguntas y laboratorios en este idioma. Se aprueba con 720 puntos.

Es una certificación que te invita a conocer en profundidad las arquitecturas mas tradicionales de AWS , la resolución de problemas en producción y el mantenimiento evolutivo al momento de actualizar infraestructura para la continuidad del negocio.

⭐ Se superponen varios temas con Solutions Architect Associate y Developer Associate. Si ya rendiste alguna, te va a resultar familiar un % del contenido.

Método de estudio

Estudiar para una certificación no tiene fórmulas mágicas, se necesita apartar tiempo de nuestro dia y constancia. Tener en claro que nos permite profundizar en conceptos o prácticas que tal vez no vemos en el trabajo diario...esa será nuestras motivación.

Tu punto de partida debe ser la guia de examen siempre.
Conviene hacer la preparación de examen de SkillBuilder, te da un paneo general de temas y asi podes identificar las brechas de conocimientos en las que debes profundizar.
Mi forma favorita de estudiar es hacer una especie de RAG con NotebookLM con la documentación oficial de AWS pertinente (aws permite bajar los pdf).
La novedad es que hay mcp de AWS disponibles referidos a la documentación. Por ejemplo, utilizando los temas de la guia de examen como contexto, se puede generar apuntes. Utilice este mcp , pero tambien hay uno que no he probado que es mucho más amplio y contiene temas de arquitectura aquí

⭐ Resumen de los Dominios de examen generado por kiro con el mcp de la documentación de AWS.

⭐ Utilicé Tutorials Dojo como banco de preguntas para practicar, pero mi percepción es que las preguntas en el examen eran más difíciles.

Arquitecturas importantes

Te invito a pensar en sus variantes para lograr alta disponibilidad, escalabilidad y resiliencia. Los temas de networking son importantes en el examen: configuración de VPC, subnet, tablas de ruteo, Security Groups entre otros, especialmente troubleshooting de conectividad.

High Available (Route53)

High Available and Scalable Web App (Cloudfront - ALB)

Worker Fleet - SQS

VPC Peering

Transit Gateway

Cloudfront - OAC

Config

Temas que son claves conocer para el examen

Las preguntas de examen se centran en la resolución de problemas con menos carga operativa y la elección de arquitecturas más lógica.

CloudWatch

Familiarizarse con las features de la consola de CloudWatch porque vas a enfrentarte a varias preguntas sobre la administración de logs.

Cómo visualizó los logs comunes? **CloudWatch > Logs > Log Management. Aquí se encuentran todos los "Logs Groups" como aws/lambda/..., aws/apigateway/...,ecs/..., ec2..
Cómo creo un Log Group? Desde la CLI de AWS. Cómo inserto Log en CloudWatch? Desde la Api con Create
CloudWatch metrics, tener en claro las diferentes tipos y circunstancias a utilizar. Cada métrica tiene un nombre, namespace y dimensiones (opcional).
- Basic Monitoring (5 min, default).
- Detailed Monitoring (1 min, se habilita manualmente)
- High Resolution para métricas custom (hasta 1 segundo).
Metric Filters ➡ Definís un patrón de búsqueda sobre un Log Group y CloudWatch genera una métrica custom a partir de las coincidencias.
- El caso de uso típico a resolver: detectar cantidad de errores 500 en logs de una aplicación. Metric Filter sobre el Log Group (métrica custom) → alarma de CloudWatch sobre esa métrica y acción de remediación automática.
CloudWatch Agent ➡ es uno de las features más importantes que nos va a permitir enviar Logs a CloudWatch desde las instancias de EC2, server onprem, EKS cluster (recopilar métricas y registros a nivel de nodo de los contenedores).
- Comprender cómo se configura y se modifica el archivo de configuración del agente (sin reiniciar las instancias de EC2): amazon-cloudwatch-agent-ctl command with the fetch-config
CloudWatch Logs Insights: sintaxis y comandos para el análisis de logs ➡ fields , display , filter , stats , sort , limit ...

Escalabilidad y Elasticidad

Administración de Fleet de EC2: Estrategias para continuar procesamiento de trabajos minimizando las interrupciones de form costo-efectiva ➡ capacity-optimized para minimizar interrupciones o price-capacity-optimized para balance entre costo y disponibilidad. (Combinando instancias Spot y On-Demand con el parámetro OnDemandBaseCapacity se especifica cuántas instancias base On-Demand y el resto se cubre con Spot).
EC2 Auto Scaling Group: puede aparecer pregunta puntual sobre administrar ASG, pero por lo general no aparece como concepto aislado sino asociado a un balanceador de carga (ALB/NLB) y en arquitecturas multi-región con Route 53.
- Capacidad mínima, máxima y deseada.
- Definición de Launch template, cómo aplicar una nueva configuración a todas las instancias del ASG sin downtime? ➡ Cuando se actualiza un Launch Template, las instancias existentes no se reemplazan automáticamente, siguen ejecutando la versión anterior. Las nuevas instancias que escalen usarán la versión nueva. Para forzar el reemplazo se usa Instance Refresh.
- Distribución en AZ.
- Health Checks de EC2 o si health checks desde un ELB determina que las instancias que no están en buen estado se reemplazan automáticamente. Profundizar en este punto
- Es clave entender las siguientes políticas de escalamiento para responder sobre mejora de performance.

Tipo de Política	Cómo Funciona	Caso de Uso
Target Tracking	Mantiene una métrica en un valor objetivo (ej: CPU al 50%). AWS gestiona las alarmas de CloudWatch automáticamente.	Aplicaciones web generales donde querés simplicidad sin configuración compleja.
Step Scaling	Ajusta la capacidad en pasos según cuánto se desvía una métrica del umbral. Permite diferentes tamaños de paso según la magnitud.	Workloads con picos abruptos donde necesitás agregar más instancias cuanto mayor es el desvío.
Simple Scaling	Agrega o quita una cantidad fija de instancias cuando se dispara una alarma. Incluye período de cooldown antes de la siguiente acción.	Legacy, no recomendada. Target Tracking la reemplaza en casi todos los casos.
Scheduled Scaling	Escala la capacidad en un horario específico usando expresiones cron.	Cargas predecibles: horario comercial, cierre de mes, campañas programadas.
Predictive Scaling	Usa ML para predecir la carga futura y ajusta la capacidad de forma proactiva.	E-commerce con patrones cíclicos (ej: picos semanales o estacionales recurrentes).

LifeCycle Hooks: En Auto Scaling Group para analizar errores de las instancias antes de que se finalicen para ser reemplazadas se puede pausar la finalización de la instancia. También, este mecanismo, al inicio permite acciones como instalación de software. La instancia permanece en estado Pendiente
Conocer el término Warmup, define un tiempo de calentamiento de la instancia. Es el período posterior al lanzamiento de una nueva instancia antes de que sus métricas contribuyan a la métrica de escalado. Evita el escalado por falsas métricas hasta que la instancia se estabilice.
Application AutoScaling (no confundir con ASG):
- ECS, cantidad de task.
- Lambda. Entender la diferencia entre Provisioned Concurrency y Reserved Concurrency. La primera es la que permite "autoescalar" ➡ muy probable que te planteen una situación con Lambda para resolver temas de concurrencia.
- Aurora réplicas. Permite liberar la instancia del cluster, teniendo réplicas de lectura (no de escrituras).
- DynamoDB, puede crear una política de AutoScaling. Luego DynamoDB pública métricas de capacidad consumida CloudWatch ➡ La alarma de CloudWatch invoca a AutoScaling de aplicaciones para evaluar la política de escalado, emite una solicitud UpdateTable para ajustar el rendimiento aprovisionado de la tabla.

ELB - High availability

Con el siguiente cuadro podés responder varios casos de uso:

Load Balancer	Capa	Protocolos	Características Clave
Application Load Balancer (ALB)	Layer 7 (HTTP/HTTPS)	HTTP, HTTPS, gRPC, WebSocket	Enrutamiento basado en contenido (path, host, headers, query strings), targets Lambda, integración con WAF, sticky sessions.
Network Load Balancer (NLB)	Layer 4 (TCP/UDP)	TCP, UDP, TLS	Ultra-baja latencia, IP estática por AZ, soporte Elastic IP, preserva la IP de origen, maneja millones de requests/segundo.
Gateway Load Balancer (GWLB)	Layer 3 (IP)	IP	Despliega, escala y gestiona appliances virtuales de terceros (firewalls, IDS/IPS). Usa protocolo GENEVE.
Classic Load Balancer (CLB)	Layer 4 y 7	HTTP, HTTPS, TCP, SSL	Legacy; no recomendado para nuevos despliegues.

Dónde encontrar información detallada como la dirección IP del cliente, latencias, rutas de solicitud y respuestas del servidor? ➡ La respuesta es habilitar los ELB Access Logs y almacenarlos en un bucket de S3.
Problemas de conectividad. Una web inalcanzable con grupos de seguridad correctos ➡ La solución es permitir puertos efímeros (1024-65535) en la Network ACL (NACL), porque ELB utiliza este rango para comunicarse con los clientes.
Sticky Sessions: Caso de uso donde una sola instancia EC2 tiene un uso de CPU del 95% mientras las otras están al 10% ➡ ajustar la expiración de las cookies de la aplicación para rebalancear la carga.
Conocer Cross-Zone Load Balancing para asegurar una distribución uniforme del tráfico en todas las zonas de disponibilidad habilitadas.
Integración de ALB con WAF pero no así con NLB.

Placement Group

Cluster: Agrupa las instancias muy cerca unas de otras en una única zona de disponibilidad. Proporciona una red de baja latencia y alto ancho de banda (hasta 100 Gbps con EFA). Casos de uso ➡ HPC, Machine Learning,

Partition: Divide las instancias en particiones lógicas, cada una en racks separados con alimentación y red independientes. Hasta 7 particiones por zona de disponibilidad. Caso de uso ➡ base de datos Distribuidas: Cassandra,HDFS, Kafka

Spread: Cada instancia se ubica en un hardware distinto (racks separados). Máximo 7 instancias por zona de disponibilidad por grupo. Caso de Uso ➡ grupos de instancias que deben aislarse entre sí en hardware separado.

Estrategias de Disaster Recovery

Conceptos principales RTO (Recovery Time Objective), RPO (Recovery Point Objective) ➡ mientras mas pequeños mas costosos. Este enlace tiene información detallada que vale la pena revisar de las siguientes estrategias:

Estrategia	RTO	RPO	Costo	Caso de Uso
Backup and Restore	Horas	Horas	$	Dev/test, no-crítico
Pilot Light	Varios minutos	Minutos	$$	Apps internas, criticidad moderada
Warm Standby	Minutos	Segundos–minutos	$$$	Apps de negocio críticas
Multi-Site Active/Active	Segundos	Segundos	$$$$	Crítico, zero-downtime

Clases de S3 - Versiones - Eventos

Hacer un pequeño cuadro comparativo de versiones de S3 y que casos de uso se utiliza para cada uno. Ejemplo ➡ cuando los patrones de acceso son impredecibles o cambiantes y no querés gestionar manualmente las políticas de ciclo de vida: S3 Intelligent-Tiering
S3 Object Lock ➡ cuando se usa Governance mode o Compliance mode.
Activación de versionado. Relación con CRR (Cross Region Replication) y SRR (replicación en misma región pero diferentes cuentas).
- Resolución de problemas de latencia o errores cuando el S3 es origen de CloudFront: Si hay millones de versiones y las operaciones de listado o ciclo de vida se vuelven pesadas ➡ Configurar S3 Lifecycle Policies para expirar versiones antiguas automáticamente, usando NoncurrentVersionExpiration para eliminar versiones no actuales después de cierta cantidad de días.
Event notifications para creación, eliminación, update de objetos. Integración con Lambda, SNS y Eventbridge. EventBridge permite filtrar eventos por prefijo, sufijo, tamaño, etc. y enrutarlos a más de 20 destinos distintos.
Conocer las políticas de bucket para responder preguntas sobre que habilita o deniega una policy. Su alcance. Entender que un Deny explícito siempre gana, incluso si hay un Allow en otra política.

ElastiCache

Conocer las llamadas básicas de la API es básico ➡ saber como crear un cluster CreateCacheCluster, parámetros importantes como CacheNodeType

ElastiCache - Memcached: caso de uso que recibe alertas relacionadas con un alto uso de CPU en un clúster de Amazon ElastiCache Memcached, cómo solucionarlo? ➡ Agregar nodos adicionales proporcionará mayor capacidad al clúster o bien según la versión de Memcached se puede escalar verticalmente cambiando el tipo de nodo sin necesidad de crear un nuevo cluster. No tiene replicación, ni persistencia.
ElastiCache - Redis: El concepto más importante de esta opción es permitir Alta Disponibilidad a través de sus réplicas: Multi-AZ con failover automático. División en sharding. Compatible con PUB/SUB. Adecuado para conservar sesiones. El soporte más común a resolver por performance es cambiar el tipo de nodo.

SSM (Simple Service Manager)

Si no trabajas todos los días con este servicio, es necesario que no solo estudies teoría en cuanto a sus features, sino que también hagas laboratorios.

Las preguntas que aparecen en el examen son muy variadas en cuanto a la administración de EC2, aplicación de parches, auto aprobaciones de releases y algunas que involucran webhooks con github.

Recomiendo mirar la sintaxis de los documentos en JSON o Yaml que definen acciones y flujos de trabajo automatizados ➡ hay preguntas sencillas sobre este punto en el examen.

Enumero algunas situaciones o casos de uso:

Un concepto sencillo útil: todas las ejecuciones se puede trackear su estatus y log de salidas desde la consola de System Manager.
Se quiere automatizar la creación de Amazon Machine Images (AMIs) personalizadas. Se detecta errores timeout sobre el pipeline de EC2 Image Builder ➡ El agente de AWS Systems Manager (agente SSM) en la instancia de compilación no se está ejecutando o no está accesible.
¿Cómo dividimos los parches entre servidores de diferentes cuentas/entornos y SO? ➡ La solución combina Patch Baselines (definen qué parches aplicar, con aprobaciones automáticas y listas de rechazo, por SO) + Patch Groups (agrupan nodos mediante tags y los asocian a una Baseline específica).

Runbook: Tipo específico de documento de Systems Manager (SSM) que define las acciones exactas que realiza el servicio Automation. Define yaml o json para orquestar un workflow de ejecución.

Por lo general, se usa para la remediación asociado con AWS Config.
Usando AWS Organizations se necesita automatizar el proceso de stopping de instancias EC2 no productivas fuera del horario de negocio de todos las cuentas miembro ➡ Crear roles de IAM en cada cuenta con los permisos adecuados, utilizar Systems Manager Automation con una cuenta de administrador delegado para ejecutar un runbook que dirija los recursos de toda la organización según los tags.
Patch Policies: se utiliza para Organizations. Tener en claro que centraliza el control para definir patching schedules y baselines para múltiples cuentas y regiones
Revisar los documentos de ejecuciones más importantes en SSM.
Integraciones por eventos externos, tener claro cómo trabaja en los diferentes casos webhooks (con avisos de software de terceros). Que flujos podemos tener:
- Webhook → API GW → Lambda → SSM
- GitHub Actions → SSM (puedes filtrar exactamente por eventos RELEASED o PRERELEASED).
- Amazon EventBridge Partner Events → GitHub como fuente nativa de eventos → SSM Automation o Lambda como destino.
- EventBridge Scheduler → Lambda consulta GitHub API → escribe versión en SSM Parameter Store (como fuente de verdad para actualizaciones)
AWS RunRemoteScript: Documento SSM que permite ejecutar scripts alojados en S3 o GitHub directamente en los nodos, sin necesidad de copiarlos previamente.

Servicios y estrategias de Deployment

Casos de uso de AWS Code Pipeline, y los otros servicios que involucra ➡ Code Commit o GitHUb, Code Build, Code Deploy o CloudFormation. Entender donde se integran los test y tener en cuenta que se puede agregar una aprobación vía sns antes de realizar deploy.
CodePipeline puede implementar CloudFormation StackSets, lo que permite implementaciones en múltiples cuentas y regiones como parte de una canalización de CI/CD.
Estrategias de deployment:
- In-place (All-at-once): Implementa en todas las instancias simultáneamente. Downtime Posible. Es Lento (redeploy versión antigua). Se usa en entornos de desarrollo, cuando el downtime es aceptable
- Rolling: Reemplazar instancias en lotes. Downtime Mínimo. Se usa cuando querés ahorrar costos sin aprovisionar nueva infraestructura.
- Rolling with additional batch: Agrega nuevas instancias antes de eliminar las antiguas. Downtime mejor que el anterior. Se usa cuando necesitas mantener capacidad completa durante el deploy
- Immutable: Inicia instancias completamente nuevas; intercambia cuando estén en buen estado. Se usa en producción donde el rollback rápido es crítico.
- Blue/Green: Ejecuta dos entornos idénticos; cambia el tráfico. Downtime mínimo. Se usa cuando necesitás rollback instantáneo y podés asumir el costo de doble infraestructura.
- Canary: Desvía primero un pequeño % del tráfico; lo va ampliando si todo está OK. Es rápido. Se usa para validar un release con un subconjunto de usuarios antes de rollout completo.

Cloudformation

Es un servicio fundamental en el examen. Conocer las secciones principales de la plantilla (JSON o YAmL) : Metadata, Parameters, Mappings (caso de uso de parametrización de Amazon Machine Images (AMIs) ), Conditions, Transform (SAM), Resources.

Una buena práctica para familiarizarse con la sintaxis de los templates es construir arquitecturas clásicas que utilicen EC2, ASG, ALB, RDS con Secret Manager, entre otras.
Comandos CLI importantes:
- aws cloudformation create-stack ➡ crea un stack nuevo
- aws cloudformation deploy ➡ crea o actualiza un stack usando un template empaquetado (más usado en CI/CD)
- aws cloudformation detect-drift ➡ inicia la detección de drift en un stack
- aws cloudformation describe-stack-drift-detection-status ➡ consulta el resultado de la detección
- aws cloudformation cancel-update-stack ➡ cancela una actualización en curso
StackSet ➡ caso de uso importante de cuentas asociadas en Organizations. Gestiona de manera centralizada para implementar cambios en las stack en varias cuentas. Se puede usar StackSets para crear, actualizar o eliminar stacks en varias cuentas y regiones de AWS con una sola operación.
Intrinsic functions: comandos que se utilizan dentro de las plantillas para asignar valores a propiedades que no están disponibles hasta el momento de la implementación (en tiempo de ejecución) ➡ revisar implementaciones de las mas importantes: Ref , Fn::GetAtt, Fn::ImportValue, Fn::FindInMap, Fn::ForEach, Fn::Transform ...
NestedStack: AWS::CloudFormation::Stack ➡ mecanismo para crear infraestructura modular, reutilizable y gestionable mediante la integración de una pila dentro de otra. En lugar de crear una plantilla única y masiva que resulta difícil de mantener, se puede dividir la arquitectura en componentes lógicos (por ejemplo, VPC, base de datos, capa de aplicación) y referenciarlos como pilas separadas dentro de una plantilla "raíz" o "padre".
Mecanismos de protección en CloudFormation:
- Stack Policy: documento JSON que restringe qué recursos pueden ser actualizados. Ideal para proteger RDS de producción de cambios accidentales.
- Termination Protection: protección a nivel stack contra eliminación accidental. Se hereda a los nested stacks.
- DeletionPolicy: Retain conserva el recurso, Snapshot genera snapshot antes de eliminar (soportado en RDS, EBS). La situación típica que se plantea, como conservar una RDS si se elimina el stack de cloudformation?
- UpdateReplacePolicy: igual que DeletionPolicy pero aplica cuando un update requiere reemplazar el recurso físico.
- Drift Detection: detecta recursos cuya configuración real difiere del template, útil para identificar cambios manuales que bypasearon el pipeline.
Profundizar en los Script Auxiliares más importantes, mecanismos para sincronizar la creación o actualización de recursos, para que el stack espere hasta que la configuración esté lista antes de continuar.
- cfn-init → lee y ejecuta la sección AWS::CloudFormation::Init del template (instala paquetes, archivos, servicios). Se ejecuta durante el User Data.
- cfn-signal ➡ Generalmente se implementa al final de un script de User Data. Un patrón común es ejecutarlo después de cfn-init
- Tener en cuenta los atributos que requieren señales como CreationPolicy (puede estar asociados con AWS::EC2::Instance o AWS::AutoScaling::AutoScalingGroup ) y los tipos de UpdatePolicy (con WaitOnResourceSignals).
CloudFormation Traffic Shifting ➡ se implementa definiendo DeploymentPreference en el template. CodeDeploy ejecuta el shifting según la estrategia elegida (Canary, Linear, AllAtOnce).

Storage

Evaluar y seleccionar que tipo de Storage es adecuado a un caso de uso. Si estudiaste para la certificación de SAA son preguntas similares.

Storage en entornos híbridos ➡ Storage Gateway y todas sus variantes
- S3 File Gateway: Acceso NFS/SMB a objetos en S3. Los archivos se almacenan como objetos nativos. Caso de uso: migración de archivos on-premise a S3.
- Volume Gateway:
- Cached mode: datos principales en S3, caché local de los más accedidos.
- Stored mode: datos principales on-premise, backup asíncrono a S3 como EBS snapshots.
- Tape Gateway: Reemplaza cintas físicas. Importante es que se expande automáticamente, esta última característica puede ser un caso de uso que aparezca en el examen.
- FSx File Gateway: Caché local de FSx for Windows File Server para acceso de baja latencia desde on-premise.
FSx for Windows FileServer y su otras variantes, cuando usarlo?
- Es MultiAZ, es una feature importante.
- Shadow Copies: los usuarios finales puedan ver y restaurar por sí mismos versiones anteriores de archivos o carpetas individuales sin depender de otro mecanismo.
- Usado con Windows SMB, Active Directory.
FSx for Lustre ➡ HPC, ML, high throughput
EFS (Elastic File System) comprender el caso de uso que puede compartir storage entre varias EC2, Linux NFS.
- Multi-AZ
- Performance modes: general Purpose y MaxIO
- Throughput Modes: Elastic (recomendado), Provisioned, Bursting.
- Conocer qué EFS tiene Storage Class y Lifecycle Policies ➡ aunque suele no aparecer en el examen.
EBS ➡ siempre en el contexto de EC2 y la elección del disco para optimizar las cargas de trabajo: gp3 sobre gp2 sin incrementar los costos, gp3 permite configurar IOPS y throughput independientemente del tamaño del volumen. Para transacciones, persistencia y durabilidad es io2
- Amazon Data Lifecycle Manager (DLM): Automatiza la creación, retención y eliminación de instantáneas de EBS y AMI respaldadas por EBS mediante políticas de ciclo de vida.
- EBS Snapshot: Una copia de seguridad puntual de un volumen EBS almacenado en S3 (gestionado por AWS). Los snapshot son incrementales.

RDS y Aurora

Los accesos se deben guardar en Secrets Manager y luego las aplicaciones acceden a eso. Característica importante Cross-Region backup replication. Tanto RDS como Aurora tienen PITR (Point-in-Time Restore).

RDS Multi-AZ ➡ standby síncrono en otra AZ, failover automático pero más lento que Aurora.
Se puede asociar con el servicio RDS Proxy para el manejo de conexiones.
Aurora ➡ Almacenamiento distribuido que se replica automáticamente en 3 AZs, hasta 15 réplicas de lectura, failover automático en segundos.
Aurora Serverless v2 ➡ la característica importante es que escala a "cero" y no genera costo.

DynamoDB

Las preguntas se centran en resolver problemas de performance; cómo volver a un recovery point. Ejemplo: La tabla experimenta picos de tráfico incrementales durante el horario laboral, con patrones predecibles, cuando se producen millones de lecturas y escrituras. Hay que configurar una solución para aumentar la capacidad de procesamiento ➡ Habilitar el escalado automático en la tabla de DynamoDB. Configurar una política de escalado automático para ajustar el tamaño en función de las unidades de capacidad de lectura y escritura.

Point-in-Time Recovery (PITR) ➡ backup continuo, permite restaurar a cualquier segundo de los últimos 35 días.
Para esto debemos conocer los tipos de Lectura Eventually Consistent Read (por defecto) y Strongly Consistent Read
Los diferentes modos de capacidad On-Demand y Provisioned (profundizar en estos dos conceptos).
DynamoDB Global Tables ➡ replicación multirregional y multiactiva. Cada región puede aceptar lecturas y escrituras, y los cambios se replican de forma asíncrona. Esto permite la escalabilidad global y la recuperación ante desastres.

Encriptación en reposo, tránsito y uso de KMS

Encriptación con S3 de KMS: SSE-S3 (clave gestionada por AWS), SSE-KMS (usás una KMS key propia, permite auditoría via CloudTrail y control de acceso granular) y SSE-C (el cliente provee la clave, AWS no la almacena). Si la pregunta menciona auditoría de uso de claves o control granular ➡ SSE-KMS.
Clave simetrica y asimetrica son básicos. Aunque en el examen no hay preguntas profundas sobre este punto.
Key Policies: Cada clave KMS tiene una política de claves. Una política basada en recursos que controla quién puede usar y administrar la clave. A diferencia de las políticas de IAM, la política de claves es el principal mecanismo de control de acceso para las claves KMS.
Rotación de Key, hay 3 variantes:
- automática, para customer managed keys puede habilitar la rotación automática
- manual u On-demand por medio de trigger.
Importación de material de clave de un cliente en KMS, pero no rota automáticamente.
Replicación AWS KMS Multi-Region Keys: Una clave KMS que existe en una región diferente, pero comparte el mismo ID de clave y material de clave que su clave principal.

AWS Certificate Manager (ACM)

Las preguntas son sencillas, si se habla que servicio proporciona certificados SSL/TLS la respuesta es ACM.

Revisar los casos de uso de como integrar ACM con ELB, CloudFront, ApiGateway, Elastic Beanstalk, Cognito.
Tipos de certificados ➡ públicos, privados e importación de terceros. Identificar los casos de uso para poder resolver situaciones.
Mecanismo de renovación e importación de certificados de terceros.

Seguridad IAM

Pensar que todo servicio para ejecutar algo debe tener un rol de IAM asociado. En ciertas ocasiones para permitir que usuarios utilicen servicios o listen ciertas features de manera temporal podemos agregar inline policies y luego eliminarlas.
Casos de uso de iam:PassRole. Entender por qué es una capa de seguridad importante para proteger el entorno de AWS de actividades no deseadas y de la escalada de privilegios.
Caso de uso de credenciales temporalesiam:AssumeRole. Ejemplo ➡ la entidad en la Cuenta A utiliza para ejecutar servicios en la Cuenta B como si fuera un usuario local en esa cuenta.
Federación de Identidades: Permite a los usuarios autenticados por un proveedor de identidad externo (IdP) acceder a AWS sin crear usuarios de IAM individuales. Conocer los casos de uso:
- SAML 2.0: se integra con Microsoft Active Directory Federation Services (ADFS) u Okta. Los usuarios se autentican con sus credenciales corporativas y reciben credenciales temporales de AWS.

OpenID Connect (OIDC):

para aplicaciones web y móviles. Admite proveedores de identidad como Google, Facebook o cualquier proveedor compatible con OIDC. Solución de error "Not authorized to perform sts:AssumeRoleWithWebIdentity" ➡ agregar el ARN del proveedor de identidad en el elemento principal de la política de confianza (trust policy).

AWS Organizations

OU (Organizational Units): las cuentas se agrupan en OUs y los SCPs se aplican a nivel OU o cuenta individual, heredando hacia abajo en la jerarquía.
Delegated Administrator: permite que una cuenta miembro (no la cuenta de administración) gestione servicios específicos como Security Hub, GuardDuty o Config para toda la organización.
Relaciona el concepto de administrar muchas cuentas con Service control policies (SCPs). Recordar que afectan únicamente a los usuarios y roles de IAM gestionados por las cuentas que forman parte de la organización. SCPs no afectan directamente a las políticas basadas en recursos.
Políticas de tagging. Se puede asegurar que los usuarios no puedan crear recursos sin una etiqueta específica.
Integración con CloudFormation StackSet. Definir un StackSet que implementa una plantilla base (almacenada en S3) en toda una Unidad Organizativa (OU) en varias regiones utilizando Service-Managed permission model.
Consolidated Billing: todas las cuentas miembro consolidan el pago en la cuenta de administración, permite aprovechar descuentos por volumen y Reserved Instances compartidas entre cuentas.

AWS Artifact

Su caso de uso es acceder a informes de auditoría. Se puede descargar bajo demanda certificaciones de cumplimiento normativo (como SOC 1/2/3, ISO/IEC, y PCI DSS).

Este apunte continua en ➡ Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 2

Patrones de acceso seguro a S3 🌐

Laura Bolaños — Mon, 27 Apr 2026 14:09:23 +0000

Este análisis se propone clarificar algunos casos de uso donde se requiere servir contenido de S3 de manera segura, identificando las brechas de seguridad a las que debemos enfrentarnos y explorar posibles mejoras. El desafío real no está en analizar cada servicio por separado, sino en combinarlos correctamente.

1. CloudFront + OAC con presigned url

Caso de uso frecuente: Un sitio web que muestra imágenes/vídeos de una temática determinada. Una parte de los objetos multimedia puede restringirse a que solo lo vean usuarios que iniciaron sesión vía Cognito. Aquí la solución más sencilla:

Upload de Multimedia (escritura)
El frontend solicita una Presigned URL a un endpoint protegido por Cognito (una api). La api se integra con una función Lambda que genera una URL temporal (válida por x minutos) firmada con permisos de "s3:PutObject" para el bucket privado de imágenes.

Visualización de Multimedia (lectura)
El bucket de S3 tiene el bloqueo de acceso público activado.
Los elementos multimedia se sirven a través de CloudFront, utilizando OAC (Origin Access Control) para firmar internamente la petición (usando el protocolo SigV4) y solicitar el objeto a S3 de forma segura.
La política (Bucket Policy) del bucket S3 solo permite la acción "s3:GetObject" si la petición proviene específicamente del ARN de la distribución de CloudFront ("Condition: AWS:SourceArn").

Conceptualmente una Presigned URL se puede utilizar tanto para cargar como para leer objetos, en el ejemplo anterior notar que solo se usa para cargar los objetos a S3*.* Una presigned URL es simplemente una URL con la firma embebida ➡ cualquiera que la tenga puede usarla hasta que expire, sin autenticación. Por eso debemos aplicar diferentes técnicas de seguridad.

La url puede tener una duración desde 1 minuto hasta 12 horas, si alguien no autorizado consigue la url y ya caduco ➡ NO la puede utilizar.
Con el uso de Cognito, el token JWT tiene una duración y se puede aplicar este control con Cognito JWT Authorizer (nativo de API Gateway). La otra posibilidad es tener Lambda Authorizer en API Gateway. Esta última tiene lógica de autorización custom.
Cuando generamos una presigned url para upload, se puede controlar que tipos de objetos cargar y su peso máximo. Algunos ejemplos:

# Generate presigned URL for PUT
# ContentType specifies the types of objects and controls their size on the frontend
upload_url = s3_client.generate_presigned_url(
            "put_object",
            Params={
                "Bucket":      IMAGES_BUCKET,
                "Key":         imagen_key,
                "ContentType": expected_content_type,
            },
            ExpiresIn=PRESIGNED_URL_TTL,
)

# the frontend makes a multipart POST request
response = s3_client.generate_presigned_post(
    Bucket=IMAGES_BUCKET,
    Key=imagen_key,
    Fields={
        "Content-Type": expected_content_type,
    },
    Conditions=[
        {"Content-Type": expected_content_type},
        ["content-length-range", 1, 5242880],  # máx 5MB
    ],
    ExpiresIn=PRESIGNED_URL_TTL,
)

1.2 Caso de uso complementario - Validación de acceso en el edge (Lambda@Edge)

Podemos enfrentarnos a dos requerimientos no funcionales: minimizar la latencia y asegurar quién puede hacer request a Cloudfront.
El caso anterior asegura que solo CloudFront puede acceder a S3, pero no controla quién puede hacer requests a CloudFront. Con Lambda@Edge es posible agregar lógica de autorización en los nodos de la CDN, antes de que el request llegue al origen. La secuencia es la siguiente:

Cuando un usuario solicita un objeto de un bucket, CloudFront invoca una función Lambda@Edge en el nodo más cercano geográficamente.
La función valida el JWT de Cognito (o cualquier token de sesión) sin necesidad de redirigir el request al backend.
Si el token es válido, el request continúa hacia S3 a través de OAC normalmente.
Si no es válido, Lambda@Edge retorna un 401 o redirige al login desde el edge.

⭐ La ventaja es la baja latencia, la validación ocurre en el edge node más cercano al usuario, sin necesidad de viajar hasta la región de AWS donde vive el backend. Cada request de contenido protegido se resuelve en milisegundos en lugar de sumar el tiempo de ida y vuelta a tu servidor.

2. Descarga temporal de un archivo privado - S3 Presigned URLs

Para esta opción el casos de uso típico: Un usuario necesita descargar un reporte generado, una factura o un documento legal guardado en bucket S3. No se utiliza Cloudfront porque no necesitamos cachear contenido de la petición.

Se produce la petición del usuario, el backend valida que ese usuario tiene permiso sobre ese archivo específico.
Lambda genera una presigned URL con GetObject que expire entre 5-15 min. La lógica de validación de lambda es idéntica del caso de uso 1 de Upload.
El browser descarga directamente desde S3 usando esa URL.

🔐 Brechas de seguridad detectadas

Riesgos de seguridad	Mitigación posible
El usuario la copia y la comparte intencionalmente o no.	TTL muy corto (1-2 minutos si es descarga inmediata)
Queda en logs del browser, proxies o herramientas de red	Generar la URL y redirigir directamente (`302`) en lugar de devolverla al frontend (nunca queda expuesta en el browser)
Se filtra por un `Referer` header en un redirect	Incluir el `userId` en la key del objeto (`uploads/{userId}/{filename}`) para que aunque alguien obtenga la URL, solo pueda acceder al archivo de ese usuario específico.

3. Distribución segura con cookies por sesión - CloudFront Signed Cookies

Caso de uso típico: Una plataforma web con contenido que se accede por suscripción, los usuarios se loguean pero cada sesión debe tener acceso acotado en el tiempo. En lugar de firmar URL por URL, el backend emite una Signed Cookie de CloudFront al momento del login, que el browser envía automáticamente en cada request de objetos multimedia.

El backend verifica la sesión y envía tres headers Set-Cookie al browser (CloudFront requiere exactamente tres pares clave-valor para una Signed Cookie). Estos headers deben enviarse antes de que el usuario solicite el contenido privado.
Si se configura un tiempo de expiración corto, el backend puede reenviar tres nuevos headers Set-Cookie en requests posteriores para mantener el acceso activo.
CloudFront valida las cookies en cada request antes de servir los objetos multimedia. La distribución debe tener al menos dos comportamientos de cache: uno público y uno que requiere autenticación. La sección privada redirige al login si no hay cookie válida.
Al cerrar sesión o expirar las cookies, el acceso se revoca sin cambiar las URLs.

⭐ Esta opción es Ideal cuando un usuario accede a múltiples objetos multimedia de una misma sección sin generar una firma por cada archivo.
⭐ Si CloudFront se configura para cachear basándose en cookies, NO generará entradas de caché separadas por los atributos de las Signed Cookies. Es decir, todos los usuarios autorizados compartirán la misma entrada de caché para un objeto determinado— CloudFront valida la cookie para permitir o denegar el acceso, pero la ignora al construir la cache key.

Aspectos generales a tener en cuenta

➡ Diseño
Considerar Patrón BFF (Backend for Frontend). Para el caso de descarga privada, se puede interponer una capa BFF entre el frontend y API Gateway. Esta capa maneja la sesión del usuario y puede ejecutar un redirect 302 directo hacia S3, evitando que la presigned URL quede expuesta en el browser.

➡ Performance/Costo
Invalidaciones de CloudFront (incurre costo después de 1000/mes). Además del costo analizar tiempo de cacheo de datos.

S3 request rates (3500 PUT/5500 GET por segundo por prefix, si el volumen es alto distribuir con prefijos).

Costo de Lambda por invocación para generar presigned URLs a escala.

➡ Seguridad
Rotación de claves KMS si el bucket usa SSE-KMS.

Versionado de objetos en S3 para evitar sobreescritura accidental.

➡ Operacional
TTL de presigned URLs vs tiempo de expiración del JWT — si el JWT expira antes que la URL, tenemos un problema!

Estrategia de nombres de objetos (userId/filename) para evitar colisiones y facilitar políticas IAM por prefijo.

Pensar en Serverless para crear bellos sueños 🦋

Laura Bolaños — Fri, 10 Apr 2026 12:56:18 +0000

En estas líneas te explico una sencilla arquitectura para desplegar un sitio web íntegramente utilizando servicios Serverless que podría servir, como en mi caso, para mostrarle al mundo mi interés por la ecología (con repositorio github incluido)

En un mundo digital donde se crean productos financieros, web que muestran dashboard de eficiencias, p&L y todo tipo de temáticas asociada al dinero ...y que está muy bien! olvidamos que nuestro hábitat natural necesita ayuda.
Hace unos años me percate de esto y comencé a leer/hablar de árboles, arbustos y plantas mal llamadas malezas - nativas de mi región que son fuente de alimento de mariposas e insectos que son fundamentales para la biodiversidad - que están desapareciendo con el avance de las especies exóticas, los agroquímicos y la destrucción de humedales.
La mayoría de las personas cuando comentas la problemática te dice "OK estoy de acuerdo contigo" pero no activan en tener un pequeño jardín de nativas o a la hora de elegir un árbol para su vereda priorizan especies exóticas solo por estetica, sin saber que muchas nativas son igual de hermosas y además sostienen la fauna local (hablo especialmente de la Provincia de Buenos Aires, Argentina).

....Y qué pasaría si cambio mi discurso en mi afán de convencer y digo: "si no ayudamos plantando nativas en nuestros hogares las mariposas pueden desaparecer" ¿Suena drástico? pero en gran parte es cierto. Estudios afirman que la población ha disminuido muy rápido, especialmente la mariposa Bandera Argentina debido a que no encuentra su planta nutricia (Coronillo) donde desovar sus huevos 💔 Cabe aclarar que la disminución de mariposas afecta directamente a la polinización y con esto atenta contra la seguridad alimentaria.
Por todo lo anterior y para bajar un poco el dramatismo decidí hacer algo: crear un proyecto web que muestre mariposas e indique la planta nativa nutricia que alimenta sus orugas! Y que los usuarios registrados puedan cargar avistamientos de mariposas en la región. Para acompañar esta idea pensé en una arquitectura Serverless, que reduce la huella de carbono y acompaña mi pensamiento ecológico 🌱.

Comencemos analizando la arquitectura

Como podés observar el laboratorio es de un nivel entre 100 y 200 (si necesitas ayuda me comentas).
Implementa una arquitectura Serverless de 3 capas:

Web Tier:
S3-Sitio Web + CloudFront ➡ contiene todo el sitio web creado con react. El código está preparado para integrar con los servicios Apigateway y Cognito. Cloudfront servicio para servir el sitio web de S3. Este s3 no es público, solo se accede a través de Cloudfront.

App Tier:
Cognito + API Gateway + Lambda ➡ Cognito realiza la autenticación del usuario que se inicia sesión. Se aclara que los usuarios se deben crear manualmente por la Consola de AWS o por cli (explicado en el Readme de repositorio). Las Lambdas de crear imagen, get imagen, presigned_URL y delete imagen(funcionalidad no desarrollada aún desde el frontend) se invocan via Apigateway. Solo los usuarios autorizados por Cognito pueden acceder a estas funcionalidades.
Las lambdas están codificadas en Python.

Data Tier:
DynamoDB + S3 - imágenes ➡ Toda la información de la fichas de las imágenes de mariposas se guarda en DynamoDB incluyendo la presigned-URL de S3-imagenes. En este último bucket se guardarán las imágenes de mariposas subidas por el usuario.
Aunque Route53 aparece en el diagrama, en el repo no lo vas a ver codificado en la IaC. Por qué? porque para el entorno educativo del laboratorio no es necesario, con la url de cloudfront el sitio web queda totalmente funcional.

⭐ El objetivo es construir una aplicación real con autenticación, subida de archivos y CRUD completo utilizando solo servicios serverless de AWS, con la opción de deployar en CloudFormation o Terraform. Porque también es muy importante aprender las diferentes formas de desplegar sin tocar el Console Home.

Como utilizar el repositorio de código

✅ Ten en cuenta que como requisito para comenzar con este ejercicio necesitas instalado Python, Terraform, AWS Cli (todo explicadisimo en el repo 🤓)

El código se encuentra en una url de un repositorio padre labs-aws-llb donde hay otros laboratorios, pero el que nos interesa es: webAppServerles.

Comenzar leyendo Arquitectura.md que explica un poco la secuencia de las acciones en los componentes y las decisiones de Arquitectura, como por ejemplo por qué no pasar las imagenes por el payload de Lambda.
Leer el Readme.md principal: contiene el paso a paso que debes hacer y si decides hacer el deploy con terraform o cloudformation te indicará ir a su correspondiente directorio. Cada directorio también contiene su Readme.md.
Leer Integration.md : te vas a encontrar que una vez deployada la IaC en AWS, solo necesitarás tomar los outputs de terraform o el descripción del stack de cloudformation y configurar el archivo aws-config.ts . Luego volverás al Readme principal para seguir el paso a paso ➡ volver a subir la web buildeada a S3 y crear una invalidación de CloudFront para actualizar la web integrada con el backend.
El laboratorio tiene un costo mínimo (si estás en la capa gratuita cero) Como siempre recomiendo limpiar todo lo desplegado. Si estas pensando en crear una web funcional estable ten en cuenta los costos. Información detallada en Readme principal.

Funcionalidades

Una vez deployado el sitio web siguiendo las indicaciones, tenemos las siguientes funcionalidades.

Feature	Usuario anónimo	Usuario logueado
Ver catálogo de mariposas precargadas	🦋	🦋
Ver galería de avistamientos de usuarios	❌	🦋
Subir foto + metadata de avistamiento	❌	🦋
Filtrar por ecorregión	🦋	🦋
Ver ficha detallada de mariposa	🦋	🦋

Después de todo el trabajo... con la url de Cloudfront descubrirás esta hermosa web funcional de mariposas bonaerenses 💗 sustentada íntegramente con servicios serverless.

En el título hablo de sueños porque realmente lo es, sueño que mis vecinos tengan aunque sea solo un ejemplar nativo. No hay estadística clara sobre la vegetación nativa, pero sabemos que las especies van retrocediendo y con esto también las mariposas.
La foto principal es una Monarca del Sur recién nacida en mi jardín, ya que generé las condiciones para que eso pasara.
Este laboratorio sirve para mostrar que casi sin costo podemos difundir información sobre temas que nos favorecen a todos y a todas. Y en tu región, ¿qué mariposas habitan?

Claves para lograr la certificación AWS Data Engineer Associate

Laura Bolaños — Fri, 20 Mar 2026 03:33:59 +0000

En este artículo encontrarás una guía para descubrir qué conocimientos necesitás antes de rendir el examen, identificar tus brechas y entender en qué temas profundizar. 🤓

Información general del examen

La certificación esta orientada los Ingenieros de datos pero también a todos aquellos que están construyendo su perfil de Arquitecto Cloud.
Aquí podes encontrar datos generales del examen, intuyo que ya conoces esta información.
La guia de examen consta de 4 dominios, es super necesario leer y revisar continuamente mientras estudias para la certificación: link
El dato importante: el examen no esta disponible en español. Para todos los que tenemos dificultad con el idioma puede parecer un impedimento pero no te preocupes! estudiando y armando apuntes en ingles lo puedes lograr 🏆 Las preguntas se pueden comprender perfectamente porque se alcanza un nivel de familiaridad con frases claves del examen.
⭐ Tip: lengua no nativa ingles ➡ pedir los 30 minutos adicionales (Exam acommodations) en la plataforma Training And Certificacion antes de agendar el examen.

Complejidad

Si no trabajas como Data Engineer pero contas con un background en bases de datos, consultas sql complejas y performance tuning los contenidos te van a resultar familiares y sencillos de incorporar. Además, si contás con la certificación Solutions Architect Associate una parte del contenido ya lo habrás estudiado.

⭐ Es una certificación importante y muy amena para estudiar, de complejidad media.

Cursos de preparación y laboratorios básicos

➡ Curso en Skillbuilder de Data Engineer Foundations . Es gratis y básico para esta certificación.
➡ Curso en SkillBuilder de preparación del examen. Es esencial ya que explica en que consiste el examen y lo que debemos estudiar. Si no contas con la suscripción haz todo el contenido libre, basicamente es la explicación de los 4 dominios.
➡ Es necesario hacer laboratorios de diferentes casos de uso, tanto de Data Lakes como de DataWarehouse. Los laboratorios los encontras en SkillBuilder (ejemplo CloudQuest Data Analytics) o invertir unos dolares en la consola. Comparto laboratorio básico de mi github

Método de estudio sugerido

Armar un NotebookLM con tus apuntes y links a pdf de la documentación oficial de AWS. Particularmente recomiendo Developer Guide y/o User Guide de servicios como Glue, Redshift, Kinesis, Athena, QuickSigth, OpenSearch, Amazon MSK, LakeFormation, DataSync y todas las url que consideres. De esta manera construyes una especie de RAG para tener precisión a la hora de preguntar dudas conceptuales o de casos de uso.
En el momento de practicar preguntas no te fies ciegamente de las respuestas de las IA, el último tiempo noté que algunos modelos tienen dificultades con temas de elección de arquitecturas. Verificar siempre con la documentación oficial, por eso es importante el punto anterior.
Buscar un banco de preguntas para entrenar y conocer el estilo de examen. En mi caso utilicé Tutoriales Dojo
Recursos útiles (lo utilicé en la preparación) :

video banco de preguntas

video casos de uso

github llb

Conocimientos fundamentales para presentar el examen

Durante el examen prestar atención a palabras claves, pensar cual solución es mas lógica, más costo- efectiva, con menor esfuerzo operacional y con performance aceptable.
El listado a continuación no cubre todo el temario, pero dominar estos temas es fundamental para aprobar:

Generales

Datalake ➡ S3: raw, curation, consumption.
DataWarehouse : Redshift. Siempre relacionado con queries complejas.
Data Lakehouse.
Patrones de ingesta de datos: Streaming y Batch.
Atención en las preguntas donde se haga alusión a data lake o datawarehouse porque puede ser la clave para elegir el almacenamiento.
Formatos de archivos para alimentar un Data Lake en S3: Json, Parquet, Avro, ORC, Csv. Sus casos de uso. Comprender mecanismo de construcción de su metadata. Formatos de Compresión gzip (ratio), snappy (rápidez), zlib.
Elección de servicio para migrar archivos/datos desde el onprem. Probablemente la elección es DataSync.
Data Skew: referido a una distribución desigual de los datos entre las diferentes unidades de procesamiento provocando un desequilibrio de carga.
Métodos principales de orquestación de pipeline de datos: Step Functions, Glue Workflows (nativo para job de glue) y MWAA (dependencias complejas, portabilidad). Se pueden crear flujos y orquestarlos con Event Bridge.
DynamoDb Stream. DynamoDB TTL.
Conexion a RDS, Aurora, Redshift via api desde Lambda. Revisar ejemplos.
Comprender el concepto DAGs (Directed Acyclic Graphs) y con qué servicios esta relacionado. Amazon MWAA
Visualizacion-Dashboard ➡ QuickSigth . QuickSigth SPICE (relacion con Athena). Analizar diferentes casos de uso.
QuickSigth librerias built-in functions and operators: utilidad en casos de uso que necesitamos Rolling Averages, Pivoting and Grouping y Machine Learning (ML) Insights.
Opensearch: Creación de indices, monitorización de logs en tiempo real. UltraWarm en OpenSearch ➡ Conocer su caso de uso.
Secrets Manager es nuestro servicio estrella para guardar accesos a base de dados de manera segura.
Casos de uso de MSK (Kafka). Se asocia con Glue para transformar.

Amazon S3

S3 Storage Lens: Si tengo que hacer una auditoría de bucket, identificar versiones antiguas de objetos, partes incompletas, etc ➡ cuento con un dashboard para clarificar estas falencias.
Tener claro todos los tipos o layers de S3, su tiempo de recuperación de datos y costos: S3 Standar, IA, Glacier Flexible, Glacier Deep Archive, Intelligent tearing y los otros que no son de alta disponibilidad. Ciclo de vida. Versionamiento. Dependiendo el caso de uso hay que optar.
Cómo aplico encriptación en reposo en S3, DynamoDB. Siempre pensar en KMS pero NO con una clave proporcionada por el cliente porque es MÁS carga operacional (es lo que debemos evitar): en S3 ➡ SSE-KMS (claves gestionadas por AWS KMS con auditoría)
Cifrado doble en S3 ➡ SE-KMS (cifrado de doble capa del lado del servidor con AWS KMS).
VPC Endpoint GATEWAY . No tiene costo en S3 y otorga seguridad sin pasar por internet. Desde Glue se puede crear una conexión de red, especificar vpc/subnet. Mismo caso para conectar una lambda de manera segura a S3.
Si tengo varias aplicaciones que consumen diferentes prefix de S3 cual es la mejor manera de brindar seguridad para que una aplicación no pueda ver los datos de otra? Probablemente la solución sea S3 Access Point
Casos de uso de EDA (Event-Driven Architecture). Especialmente de S3, reconocer cuando conviene registrar un EventBridge y cuando reaccionar a una lambda (sin intermediarios).
Modificación de objetos (datos) en S3 al momento de la recuperación, ejemplo: un caso de uso que deba enmascarar información ➡ Por medio de S3 Object Lambda.
Técnicas de Performance en datos almacenados en S3: Bucketing y Partition (ver cardinalidades). Entender las diferencias y cuando se usa según el caso para poder responder con seguridad.
Amazon Macie: tener claro que hace escaneo, descubrimiento y clasificacion de información sensible cuando los datos ya están alojados en S3. Puede integrarse con EventBridge para realizar acciones sobre los hallazgos.
SQL S3 ➡ solo puede consultar un unico archivo. Util para consultas adhoc de un dato en particular.

Amazon Glue

Glue Engine: Spark, Ray (computación paralela/intensiva) y Python Shell (ejecuciones sencillas).
Glue ETLs. Glue Crawler (identificación de metadata en varios origenes). Programación de cron. DynamicFrames.
Glue Dynamic Schema (Schema Evolution). Relacion con AVRO.
Glue Data Catalog (recordar que no solo se usa en el scope de Glue sino que también se integra con EMR). Schema version history.
Glue DataBrew - relacionado con Data Quality pero es herramienta visual no-code. Conocer la sintaxis de rules. Conviene hacer laboratorios o al menos revisar la consola de AWS. En qué casos de uso podemos arreglar los datos. Recordar que está vinculado con SageMaker AI en la preparación de datos para entrenar modelos.
Permite hacer Custom rules.
AWS Glue Data Quality. Es una capacidad diferentes al punto anterior. Utiliza DQDL para definir reglas de validación.
Glue Workflows (usar cuando orquestamos solo job de Glue, si vemos que tenemos que orquestar Lambdas la opción correcta probablemente sea Step Functions).
Glue Bookmark. Si lo tengo activado y el job vuelve a procesar los datos nuevamente...que puede estar pasando? falta job.commit().
Desde un bucket policy se puede denegar ejecuciones de glue que no esten desde un rango horario determinado, ejemplo: "StringNotEquals":{},"NumericGreaterThan":{"aws:CurrentTime":"11:00:00Z"},"NumericLessThan":{"aws:CurrentTime":"09:00:00Z"}} . Ver casos de policy en S3, es la parte de seguridad mas importante del examen.
Comprender permisos de ejecucion en Glue mediante roles y politica de confianza (Trust Policy): AWSServiceRole (tiene las politicas básicas).
Si tengo que monitorear job de Glue, a donde voy? lo hago en Glue Studio ➡Job monitoring dashboard (no desde Cloudwatch). Hacer laboratorio con Glue y revisar las métricas, ejecuciones anteriores. Este analisis sirve para ajustar dpu o workers.
Glue transformación de datos JSON a Tabular : Relationalize Transform.
Feature Transformación Detect PII (o Detect Sensitive Data): Accion de enmascarar, redactar o eliminar.
Glue Interactive Sessions.
Glue Flex. Usa capacidad de computación ociosa por lo tanto es menos costoso.

Amazon Redshift

Redshift sintaxis sql: practicar select, agrupaciones, rank() y funciones más comunes. Sintaxis UDF (se invocan en la proyeccción). Entender que las búsquedas con expresiones regulares son más lentas.
Redshift comandos: COPY (se usa para traer rápidamente datos desde S3) ➡Option: PARALLEL y COMPUPDATE. Unload (se usa para descargar datos a S3, generalmente históricos).
Redshift leader nodes y compute nodes. Entender cómo trabaja para tener la capacidad de responder preguntas de performance.
Redshift Spectrum, está pensando para consultar S3 Y Redshift. No confundir con consultas federadas. Por lo general se usa Spectrum cuando redshift descarga registros antiguos en s3 para abaratar costos y se requiere algún informe que cruce con datos históricos.
Redshift consultas federadas vs Athena federated queries. Se puede presentar una pregunta con estas dos opciones. Leer el caso de uso y tener en claro que soporta cada una. Ejemplo, Redshift queries federadas no soportas consultas en TimeStream.
Redshift Distribution Style : entender que es Auto Distribution, ALL, Even, Key. Esto se aplica para hacer performantes las querys. Relacionar con Star Schemas.
Redshift: Ingesta de datos en formato JSON, cómo se almacena/consulta de forma performante? Con el tipo de dato SUPER, se crea una tabla con una única columna y se puede realizar consultas anidadas (se usa PARTITION BY y funciones como like json_extract_path_text).
Data Sharing: Redshift comparte información entre cluster. Ver casos de uso.
Vistas materializadas. Como las construye. En qué casos de uso se utilizan. Cómo se refrescan.
Redshift troubleshooting: Tabla de sistema STL_ALERT_EVENT_LOG. Maximum Transmission Unit (MTU). VACCUM, VACCUM FULL, VACCUM DELETE ONLY y VACCUM REINDEX.
Redshift Workload Management. Determina como se ejecutan las consultas en el cluster (query queues and route queries).
MPP (Massively Parallel Processing) y Windows Functions.
Dynamic Data Masking - DDM (CREATE MASKING POLICY) ➡ Permite ocultar, ofuscar o seudonimizar datos. Se pueden restringir a usuarios o a roles específicos.

Kinesis Data Stream - Kinesis Firehose - Amazon Managed Service for Apache Flink (Ex Kinesis Data Analytics)

Tener claro conceptualmente los 3 servicios del título. Real time y Near real time.
Amazon Managed Service for Apache Flink: Detectar anomalias o casos de uso de Fraude. Windows Operations (defining time-based or row-based windows to manage data streams)
Mirar todos los casos de ingesta Kinesis Data Stream (pensar que siempre es real time). Puede ingestar a Redshift directamente con Redshift Streaming (es zero etl).
Analizar Casos de Uso de streaming de IoT. Velocidad de Transmisión de datos- Registros por segundo.
Performance en streaming de datos: Kinesis Producer Library (KPL) y Kinesis Client Library (KCL). Shared Fan-out
Partition key de alta cardinalidad para distribuir la carga de forma equitativa en los diferentes shard.
Resolución de problemas en Kinesis Data Stream ➡ si la velocidad de los datos supera la capacidad de los fragmentos actuales: ProvisionedThroughput - Exceeded Exception.
Caso de uso Kinesis Firehose + Lambda para transformación de datos.
Integración Kinesis Firehose con CloudTrail.

Lake Formation

Lake Formation, si hay preguntas sobre permisos granulares considerar que la respuesta es esta. Tener en cuenta todo lo que puede gobernar Lake Formation (qué fuentes de datos).
Fine-Grained Access Control (FGAC). Tag-Based Access Control (LF-TBAC). Credential Vending.
Blueprints and Workflows: Templates que ayudan a ingestar datos desde varias fuentes para crear automaticamente AWS Glue crawlers, jobs, and triggers.
Auditoría via CloudTrail.
CloudTrail Lake: observalidad de como interactúa el ecosistema de AWS. Centralidad de logs. SQL Engine. Seguridad Granular.

EMR

Comprender los casos de uso EMR. Es la opcion de procesamiento de datos mas costosa para mantener (para que viva la metadata hay que tener prendido el cluster). Puede ser la elección adecuado si se requiere control profundo sobre la infraestructura, configuraciones personalizadas (flexibilidad) o el uso del ecosistema completo de Hadoop para migraciones de datos.
Relación con BigData. Procesamiento Distribuido.
EMR puede usar Glue Catalog.
Mirar la combinación de cómputo recomendada para brindar alta disponibilidad y cost effective. Instancias Spot y Procesadores Graviton.
EMR: feature security configuration para setear encriptación tanto en reposo como en tránsito.
EMR Serverless. Casos de uso. Entender en cual caso conviene utilizar en lugar de EMR Standard.

Amazon Athena

"Analizar datos con sql" la respuesta es Athena.
Tablas en Athena que se pueden modificar : Apache Iceberg.
Athena predicate pushdown*.*
Athena Parallel Execution.
Consultas anidadas en Athena (nested), como hacer performante y fácil. View por cada consulta.
Athena federated Query.
Athena ➡ queries lentas, están mal las particiones que estoy tomando para filtrar. Uso Partition Projection en base a los accesos.
Glue Notebooks y Athena Notebooks: cuando se usa cada uno?
CTAS (Create Table as Select)
Athena Federated Query por medio de Lambda.
Athena Workgroups

DMS - STC -CDC

Migrar a una base de datos en la nube o desde onprem, la mejor elección es DMS. Si no hay homogeneidad en la base de datos origen con la de destino se debe usar STC (AWS Schema Conversion tool). Para replicar datos evitando downtime en la base de datos se replica con CDC (change data capture). Este último se realiza con los logs full de transacciones activado en la base de datos origen.
En los casos de uso de migración de bases de datos homogéneas solo se usa DMS + DMS Schema Conversion y cdc (change data capture) para los cambios.
Cuando tengo dos regiones y se quiere migrar una base de datos en la región A con destino en la región B, DMS debe ubicarse idealmente en la región donde está la base de datos de destino o en una región cercana para minimizar la latencia de escritura.

Cloudwatch - CloudTrail

Comprender cuándo utilizar CloudWatch, ejemplo ➡ si necesito analizar/buscar con lenguaje sql uso Amazon CloudWatch Logs Insights. Metrics Filters y Subscription Filter.
Creación de Train en CloudTrail. Mecanismo de envío de datos (a S3) y consultas.
En CloudTrail puedo direccionar el logueo de la actividad de cuentas y/o servicios a un S3 y analizar los datos mediante Athena.
CloudTrail caso de uso testigo: a. CloudTrail capta eventos de Redshift, b. por medio de Reglas de EventBridge guarda esos logs en DynamoDB. También EventBridge Pipes puede filtrar contenido de eventos.

Camino a lograr AWS Certified Developer - Associate (DVA-C02)

Laura Bolaños — Tue, 17 Mar 2026 14:23:20 +0000

Estas notas no intentan ser una guía detallada, sino un recorrido por temas importantes y tips que debemos tener en cuenta si nos aventuramos a estudiar esta certificación. También es importante aclarar que se trata de una visión subjetiva acerca de la complejidad del examen, basada en mi experiencia después de haber obtenido 3 certificaciones previas de AWS.

Información general del examen

No me voy a detener en esta descripción porque está claramente escrito en este enlace que debes leer.

⭐ Tip: si tu lengua no es ingles nativa, pedir 30 minutos adicionales (Exam acommodations) en la plataforma Training And Certificacion antes de agendar el examen, sin importar si se rinde en ingles o español.
Esta selección se realiza en la opción de menú marcada y queda seleccionada por default para todas las futuras certificaciones de AWS.

Complejidad

AWS Developer Associate < AWS Solutions Architect Associate
AWS Developer Associate > AWS Cloud Practtioner
AWS Developer Associate < AWS AI Practitioner

Relación con certificaciones anteriores

Cuál es tu punto de partida?

Leer la guía de examen para tener una visión general del contenido que debemos abordar de los 4 dominios, cada dominio tiene un % diferente de cobertura en la certificación. No te desanimes si a priori pensas que tu perfil no es el del candidato que se describe en la guía, yo tampoco lo soy 100%, pero con ganas y entusiasmo para aprender → llegarás a la meta!!.
guía del examen
Learning plan de preparación de AWS SkillBuilder. No importa si no contas con la suscripción, haz lo que este sin costo. Es una forma de nivelar tus conocimientos.
Lo bueno de la suscripción es que accedes a varios laboratorios útiles pero no es un impedimento. Si haces practicas de laboratorios por cuenta propia necesitarás una inversión mínima en la consola de AWS de 1 a 3 usd.
Exam Prep Plan: AWS Certified Developer — Associate

⭐ Cuando comiences el punto 2, recomiendo armar planilla de calculo de “brechas de conocimiento” e indicar como vas a cubrir ese gap (con laboratorios, documentación de AWS o practicando preguntas de examen).

Claves fundamentales para presentar el examen

En esta sección se listan los conocimientos clave que debemos profundizar para alcanzar la certificación. Como siempre, es fundamental tener una perspectiva de seguridad para los diferentes servicios de AWS: quién puede invocar cada servicio y qué acciones puede realizar una vez invocado → aplicando el Principio del Mínimo Privilegio.

☁ Desarrollo con Lambda: si crees que por lanzar una lambda via consola o cloudformation ya tenes todo el conocimiento…pues no es así. Hay que profundizar y tener practica de laboratorios pasando por la mayoría de sus features:

Versiones Lambda — Alias Lambda-Integraciones (como se usan?). Pruebas de dev y prod con alias. Alias ponderados (como usar?).
Tiempo de Espera Lambda.
Variables de Entorno (se cifran? ).
Concurrencia Aprovisionada y Concurrencia Reservada. (diferencia y sus casos de uso).
DLQ (cuando se usa).
Triggers. Lambda Source Events (EventSourceMaping).
Logueo en CloudWatch
Limites y quotas Lambda
Lambda layers (para que se usan).
Lambda VPC (cuando y como se usa).
Eficiencia Lambda (memoria? codigo?)
Almacenamiento interno /tmp (limites y en que casos es util).
Manejo de errores. Retroceso exponencial.
Payload de entrada y de salida.

⭐ Tip: para cubrir la mayoría de teoría de lambda con demostraciones, ver video Joan Amengual.
⭐ No dejes de hacer laboratorios o pequeñas pruebas tomando un lenguaje de programación soportado, en mi caso elegí Python.

☁ DynamoDB: Conocimiento profundo del servicio.

Clave sencilla (único atributo) y compuesta (2 atributos).
Importancia de cardinalidad en claves de partición. Índices de ordenación.
Índices LSI y GSI. Qué índice se puede crear en una tabla ya activa y con datos. Limites de índices. *Recuperar items y en qué casos de uso se utilizan: GetItem, Scan (no performante), Query y BatchGetItem. Consultas condicionales.
Lecturas eventualmente consistentes y fuertemente consistentes. Transacciones en DynamoDB. Consumo de RCU y WCU de cada una. Tra
Conocimiento para calcular RCU-WCU en un caso de uso de lecturas/escrituras por segundo de acuerdo al tipo de requerimiento de consistencia.
Capacidad aprovisionada o a demanda. En qué casos de uso conviene utilizar cada una.
TTL. Configuración para eliminación de ítem por medio de atributo marca de tiempo.

⭐Tip: Hacer laboratorios de Lambda invocando programáticamente a DynamoDB, con diferentes funcionalidades de recupero de ítems utilizando el SDK de AWS.

☁ DynamoDB Stream: Cómo integramos los avisos de cambios de DynamoDB (insert, modify, delete ) con los diferentes servicios .

FilterCriteria. Revisar ejemplos.
Cómo evito publicar información sensible por medio de StreamViewType (KEYS_ONLY).

⭐Tip: Recomiendo revisar diferentes casos de uso Lambda, Amazon Kinesis Data Stream, Step Functions.

☁ Desarrollo Api Gateway: Contar con conocimiento profundo del servicio.

Tipos de APIs. Correspondencia con casos de uso.
Integración con lambda, alias-versiones.
Stages. Ambientes dev-prod. Variables de stage.
Integraciones simuladas. Mocks.
Validación de headers, request y body. Por ejemplo, podemos validar antes de llamar a un backend Lambda.
Autenticación y Autorización. Roles de IAM. Api key. Cognito (app web y mobile). Lambda Authotizer.

⭐ Este servicio es de los mas importantes junto con Lambda. Es necesario hacer diferentes laboratorios por medio de la Consola de AWS y también por SAM (Serverless Application Model).

☁ Autenticación y Autorización Cognito:

User Pools e Identity Pools. Comprender el flujo básico de autenticación.
Casos en que solo con User Pools podemos tener autenticación. Adicionando Identity Pool para implemetar Roles de IAM acceder a servicios aws (credenciales temporales).
Acceso a usuarios autenticados y no autenticados. Casos de uso y diferencias.
IAM roles y Trust relationships. Su relación con la configuración en Cognito.
Grupos de usuarios de Cognito (dentro de User Pools). Asignación de Roles de IAM.
Federación de identidades (Facebook, google, etc). Identity Provider. Protocolos SAML o OpenID Connect (OIDC).
Flujos de autenticación personalizados con Lambda (Custom authentication challenge Lambda trigger). *Amazon Cognito Sync para sincronización de perfiles en todos los dispositos mobile y web.

⭐ Es importante repasar ejemplos y si es posible hacer pequeños laboratorios de: app web con ALB-Cognito, flujos de autorizaciones personalizadas Lambda, Autenticación Cognito en Apigateway.
⭐Ayuda revisar las diferentes configuraciones en la consola de AWS.

☁ ALB-ASG-EC2: Conocer los casos de uso típicos de aplicaciones web con esta arquitectura de alta disponibilidad y cómo aplicar seguridad y certificados (ACM).

Perfiles de instancia de EC2 y asunción de roles. Casos de uso que necesito acceder a una RDS a escribir.
Cómo aplico Seguridad por VPC, Security groups, ACL.

☁ Contenedores ECS, EKS: Componentes fundamentales, como aplicar monitoreo y observabilidad en los dos casos para solucionar problemas (Cloudwtach y X-Ray).

☁ Cloudfront: Además de conocer frente a que servicios puede estar (ALB, S3, lambdaEdge..) centrarse en la seguridad. Ver casos de uso para aplicar seguridad entre el lector-cloudfront y cloudfront-origen.

☁ SAM (Serveless Application Model): Conocer los comandos básicos de la Cli de SAM. Hacer pequeños laboratorios con Lambda-ApiGateway- DynamoDB (caso de uso CRUD), comandos para testear localmente e implementar.

☁ CI/CD: Conocer comandos básicos y cómo se integran CodeBuild, CodeDeploy, CodePipeline.

Archivos necesarios en la raiz local de cada proyecto: buildspec.yml y appspec.yml (gestiona los hooks necesarios para la implementación).
Verificación con Hooks de CodeDeploy: PreTraffic y PostTraffic.
En cual podemos agregar pruebas automatizadas. En dónde podemos agregar aprobación manual.
Cómo lo integro con SAM? Para separar ambientes de dev-staging-prod que opciones tengo para guardar esa parametría (configuración local, ParameterStore).
Importancia de las implementaciones Canary y el desvío de tráfico por porcentaje entre producción actual y la nueva implementación .

☁ EventBridge: Revisar casos de uso de Arquitecturas orientadas a eventos donde intervenga este servicio.

Comprender la diferencia de utilizar Amazon Eventbridge o SNS. Revisar diferentes casos de uso.
Capacidad de transformación de el payload para cada destino.
Filtrado de eventos. Reglas complejas basadas en el payload del evento.
Casos de uso de avisos relacionados a cumplimiento, seguridad o controles generales. Relación con Security Hub, avisos de Vencimientos de certificados (ACM).

⭐ Recomiendo hacer laboratorio de un ejemplo similar a: venta/pedidos de producto, donde tengo un bus de eventos y diferentes reglas que ejecutan Lambdas: “registrar pedido”, “preparar pedido” y “entregar pedido”. Cada lambda con un evento posterior avisa para el siguiente paso al bus de eventos.

☁ SQS: Elemental entender sus casos de uso con Lambda, SNS y EventBridge.

Tipos Standard y FIFO. Performance de cada uno.
DLQ (dead letter queue).
Visibilidad de mensajes. Máximos.
Retardos de entrega de mensajes: Delay. No confundir con visbilidad de mensajes.
Reintentos de entrega de mensajes. Permanencia de mensajes.
Borrado automático de mensajes cuando se realiza sondeo o pooling y cuando es necesario eliminar programáticamente.

☁ SNS: Comprender sus casos de uso con Lambda, SQS y EventBridge.

Filtrado de eventos para diferentes consumidores. Uso de atributos para el filtrado.
Diferencias con SQS. SNS tiene la capacidad de entregar el mismo mensaje a diferentes consumidores.
Reintentos de entrega de mensaje. Protocolos y Políticas de entrega.

☁ S3: Conocimiento general de todos los tipos y el tiempo de recuperación de información.

Casos de uso comunes de carga de objetos y que eventos puede disparar, ya sea en una SQS, SNS o simplemente la ejecución de una Lambda.
Conocimientos de manejo de políticas de bucket (políticas basadas en recursos) no solo para permitir qué hacer a nivel bucket sino también a nivel objeto.
Políticas de recursos para forzar conexiones cifradas (https), forzar realizar put ítem donde elemento ya venga encriptado. Cómo hacer para que un usuario determinado solo vea sus objetos en un bucket general.
URL pre-firmadas. Duración máxima y seteo de expiración time.
Sitios web estaticos. Como hacer para que sólo se puede invocar desde Cloudfront (OAC-Origin Access Control).

⭐ Es muy útil la practica de comandos/acciones sobre S3 con AWS CLI.

☁ ElasticBeanstalk: que tipos de casos de uso puedo desarrollar. Comandos ClI EB. Por qué se Beanstalk (ventajas) ? En qué casos nos ayuda?

Tipos de deployment, (hacer cuadro comparativo de All at once, Rolling, Immutable, Traffic splitting, Blue/green).
Componentes centrales Enviroments y Applications-Application versions.

☁ StepFunctions: Conocer los estados y condiciones.

Cómo hace los reintentos. Revisar ejemplos del tipo sistema de pagos.
Comprender que no siempre utilizar SF es la solución mas sencilla.
Relación con Lambda, SQS y Eventbridge.

☁ CDK: No confundir con SDK.

Uso de AWS CDK Construct Library y AWS CDK Tookit.
El modelo de Programación de Constructs. Clase CDK Aspects.
Aserciones de CDK . Pruebas unitarias.
Traducción a plantillas Cloudformation.

☁ CloudFormation: Estructura básica. Parametría. Rollback. Diferencias entre Ref o GetAtt. Pilas anidadas. La importancia de los Outputs. Fn::ImportValue.

☁ CloudWatch:

Métricas personalizas. Grupos de logs. Logueo personalizado.
Query en los logs.
Uso Formato de Métrica Integrada (EMF, Embedded Metric Format).
Agente cloudwatch. Su relacion con ECS, EKS y servidores on-prem. Qué recopila.
Filtros Cloudwatch. Contadores. Avisos. Desde qué momento tiene vigencia.

☁ CloudTrail — XRay Diferencias conceptuales entre ambos. Particularmente para el caso de AWS Developer tiene mas utilidad X-Ray, entender el por qué.

Consultas en CloudTrail, relación con Amazon Athena.
Auditoria de KMS en CloudTrail.
Analisis/Solución cuellos de botella. Latencia.
Cómo integrar X-Ray en ECS o EKS. Sidecar X-Ray.

☁ Seguridad de datos y secretos:

Claves simétricas y asimétricas. Cifrado en transito y reposo.
Cómo puedo usar KMS (claves administrados, material de clave importados, etc).
Casos de uso en los que un desarrollador necesita rotar secretos de password de base de datos usando Secret Manager.
Casos de uso que podemos utilizar Parameter Store - Secure String. Cifrado en transito y reposo.

☁ STS: Comprender los mecanismos de obtención de credenciales: AssumeRole, AssumeRoleWebIndentity, AssumeRoleWithSAML, GetFederationToken, GetSessionToken..

Cómo hacer para probar asumir un rol desde AWS CLI y solucionar un problema.
STS en Cognito. Relaciones de Confianza.
Invocaciones AssumeRoleWithWebIdentity por qué no requieren el uso de credenciales de seguridad de AWS.
Etiquetas de Sesión (Tags).
Endpoint STS Global y Regional. Su relación con la latencia.

Alguna manera útil de estudiar teoría y buscar apoyo de colegas?

⭐ En casos de uso de servicios que mas dudas tengas, lo recomendable siempre es hacer pequeños laboratorios..seguro ya lo dije pero es muy importante!!

⭐ Cuidado con las IA y la explicación profunda de los servicios o casos de uso, tienen alucinaciones!
Recomiendo estudiar de las documentación oficial de Aws. En mi caso usé: Developer Guide y API Reference en pdf/html de los servicios para CHATEAR con ellas por medio de un cuaderno de Google NotebookLM (te permite agregar hasta 50 fuentes con usuario sin suscripción, adición de notas y +…es espectacular!).

⭐ Practicar muchas preguntas de examen es lo que te asegura el éxito.
En AWS SkillBuilder hay un set gratuito y uno con suscripción.
Exam Topics (10 gratuitas).
Tutoriales Dojo (gratuitas).
Revisar algún set de Practica de Udemy. En mi caso utilice set de un instructor muy poco conocido.

⭐ Todo proceso de certificación conviene transitarlo con apoyo de las comunidades con intereses parecidos a los nuestros. Te invito a unirte:
📚 AWS Women In Cloud Buenos Aires → donde ayudamos a cerrar la brecha de género en aws.
📚 La comunidad de MaxCloud — El Capitan
📚 AWS Women Colombia