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

Temas que son claves conocer para el examen - Segunda Parte

AWS Config

• 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:

Control Tower

Security Hub - WAF - Detective - Inspector - GuardDuty

• 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.

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:

• 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:

• 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

AWS Global Accelerator

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

• 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

• 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.