El dominio de respuesta a incidentes y eventos representa el 14% del examen DOP-C02. Las preguntas van mas alla del conocimiento basico de herramientas y exigen que disenies cadenas completas de automatizacion basadas en eventos e identifiques la fuente de evento correcta para cada escenario.
Fuentes de eventos y patrones de procesamiento
Comprender las fuentes de eventos con precision es critico para un ingeniero DevOps. AWS proporciona multiples servicios que generan eventos, cada uno con un proposito especifico.
Patron AWS Health + EventBridge
AWS Health publica eventos en tiempo real sobre interrupciones de servicio, mantenimiento programado y retiro de instancias que afectan a tu cuenta. Usando en las reglas de EventBridge, puedes capturar inmediatamente los eventos de Health.
Considera este escenario real: una empresa que opera miles de instancias EC2 recibe avisos de retiro de AWS. El monitoreo manual de la consola produce respuestas tardias y degradacion del servicio. La solucion es una regla de EventBridge que detecta y activa un runbook de SSM Automation para detener y reiniciar automaticamente las instancias afectadas.
| Fuente de evento | Valor source | Tipos de eventos representativos | |-----------------|-------------|----------------------------------| | AWS Health | aws.health | Retiro de EC2, interrupcion de servicio, mantenimiento | | CloudTrail | (integrado nativamente) | Todas las llamadas API de AWS | | EC2 Auto Scaling | aws.autoscaling | Eventos de ciclo de vida de inicio/terminacion | | CodePipeline | aws.codepipeline | Cambios de estado del pipeline |
No confundas Health con CloudTrail. Los cambios de estado de la infraestructura de AWS provienen de Health; las llamadas API realizadas por usuarios provienen de CloudTrail.
CloudTrail + EventBridge — Vigilancia de eventos API en tiempo real
Cuando necesitas detectar en tiempo casi real llamadas API sensibles como la creacion de usuarios IAM o modificaciones de grupos de seguridad, aprovecha la integracion nativa entre CloudTrail y EventBridge.
Escenario de institucion financiera: la politica IAM prohibe la creacion directa de usuarios IAM, pero algunos desarrolladores la evaden. La arquitectura de respuesta funciona de la siguiente manera.
Configurar el patron de regla de EventBridge: Registrar Lambda como destino Lambda llama + para deshabilitar inmediatamente al usuario SNS envia notificacion al equipo de seguridad
Esta arquitectura completa detectar→deshabilitar→notificar en segundos desde la llamada API. Las consultas periodicas de logs de CloudTrail con Athena introducen decenas de minutos de retraso y son inadecuadas para la respuesta en tiempo real.
Para el puerto SSH 22 abierto a 0.0.0.0/0 en un grupo de seguridad, se aplica el mismo patron: detectar eventos con condiciones de EventBridge que filtren , luego activar Lambda para llamar .
SQS Dead Letter Queue — Aislar mensajes envenenados
En sistemas de procesamiento de eventos a gran escala, ciertos mensajes que fallan repetidamente y bloquean el flujo normal de mensajes se denominan mensajes "poison pill".
SQS Dead Letter Queue (DLQ) mueve automaticamente los mensajes que superan desde la cola origen a una DLQ separada. El beneficio clave es aislar los mensajes toxicos para proteger el flujo normal, mientras que los mensajes aislados en la DLQ se preservan en su forma original para un analisis posterior de causa raiz y reprocesamiento.
Cuando Lambda procesa mensajes a traves del mapeo de origen de eventos SQS, todos los mensajes de un lote deben tener exito antes de que se envie un ACK. En caso de fallo, se reintenta todo el lote. Al alcanzar , el mensaje se mueve a la DLQ. La funcion DLQ Redrive de la consola SQS permite enviar mensajes de vuelta a la cola origen despues del analisis.
Kinesis Data Streams Enhanced Fan-Out — Escalado de consumidores
Cuando multiples consumidores Lambda intentan leer simultaneamente del mismo shard de DynamoDB Streams, se producen errores . DynamoDB Streams permite como maximo 2 consumidores concurrentes por shard.
Cambiar a Kinesis Data Streams con Enhanced Fan-Out da a cada consumidor un rendimiento dedicado de 2 MB/s por shard. Los consumidores operan de forma independiente sin contention. DynamoDB tambien admite integracion directa con Kinesis, permitiendo una transicion fluida sin cambios de codigo. Compara esto con el patron fan-out de SNS + SQS, que anade una capa de broker de mensajes, mientras que Kinesis Enhanced Fan-Out escala directamente los consumidores del stream.
Cambios de configuracion basados en eventos y auto-recuperacion
CloudWatch Alarm + SSM Run Command — Auto-recuperacion de procesos
Imagina una aplicacion de servidor de juegos donde la instancia en si es saludable pero el proceso del servidor de juegos falla intermitentemente. Las comprobaciones de estado de Auto Scaling solo detectan fallos a nivel de instancia y no pueden detectar fallos de procesos de aplicacion.
La solucion es usar el plugin del CloudWatch Agent para recopilar el estado de ejecucion de un proceso especifico como metrica personalizada. Cuando el recuento de procesos cae a cero, se activa una alarma de CloudWatch, y la accion de alarma activa SSM Run Command para reiniciar solo el proceso en la instancia afectada.
La ventaja de este enfoque: ninguna reemplazo de instancia significa ninguna desconexion de sesion de jugadores. La DesiredCapacity de Auto Scaling permanece sin cambios. Los comandos se ejecutan de forma remota a traves de SSM Agent sin SSH.
ASG Lifecycle Hook — Recopilacion de logs antes de la terminacion
Cuando una instancia de Auto Scaling se termina, los logs en esa instancia desaparecen con ella. Los ASG Lifecycle Hooks son la herramienta clave cuando necesitas preservar logs para el analisis de causa raiz de fallos.
Un Lifecycle Hook inserta una etapa cuando una instancia hace la transicion de a . Durante este periodo de espera (predeterminado 3600 segundos, maximo 48 horas), la instancia no se termina realmente y permanece accesible.
Dos patrones de uso criticos aparecen en el examen.
Patron 1, recopilacion de logs: EventBridge detecta el evento , activa Lambda para enviar logs a S3, luego llama para permitir la terminacion final. La terminacion solo procede despues de que la transferencia de logs se completa.
Patron 2, sincronizacion de descubrimiento de servicios: Hooks en lanzamiento () y terminacion () activan Lambda para sincronizar automaticamente registros externos.
Trampa comun: EventBridge + Run Command parece conceptualmente similar, pero los comandos SSM no pueden llegar a una instancia que ya esta terminando. Debes pausar la terminacion con un Lifecycle Hook para hacer posible la ejecucion de comandos.
Solucion de problemas de pipelines CI/CD
Cuando el disparador automatico CodeCommit a CodePipeline no se activa
Un desarrollador hace push de codigo a la rama main pero el pipeline no se inicia automaticamente. La ejecucion manual funciona bien. Que debes verificar primero?
La respuesta es verificar el estado de la regla de EventBridge. Cuando CodePipeline configura una fuente de CodeCommit, crea automaticamente una regla de EventBridge que detecta eventos . Si esta regla esta DESACTIVADA o apunta al ARN de pipeline incorrecto, el disparador automatico falla. El hecho de que la ejecucion manual funcione demuestra que no hay problema de permisos IAM, apuntando al mecanismo de disparo mismo.
Cuando todos los eventos de despliegue de CodeDeploy muestran estado Skipped
El despliegue no falla; nunca comienza y muestra el estado Skipped. CodeDeploy Agent opera en modo pull. El agente sondea periodicamente el endpoint del servicio CodeDeploy para verificar si hay comandos de despliegue.
En una subred privada sin NAT Gateway ni endpoints de VPC, el agente no puede alcanzar y el sondeo falla. Todos los eventos mostrando Skipped significa que el agente nunca recibio el comando. Distingue entre Skipped y Failed: Failed significa que el agente recibio y ejecuto el comando pero fallo. Skipped significa que el agente nunca recibio el comando.
Solucion: crear un endpoint de interfaz VPC , o proporcionar acceso a internet a traves de NAT Gateway.
X-Ray y Step Functions para rastrear flujos de trabajo complejos
Implementar un flujo de trabajo de automatizacion de incidentes de seguridad de multiples pasos (desactivar clave de acceso expuesta → resumir actividad de CloudTrail → notificar al equipo) con encadenamiento de Lambda hace que sea muy dificil rastrear fallos en pasos individuales. AWS Step Functions Standard Workflow preserva la entrada/salida de cada estado y el historial de transiciones durante 90 dias. Retry/Catch permite definir de forma declarativa la logica de reintento por paso. El patron de EventBridge detectando un evento de AWS Health y activando un flujo de trabajo de Step Functions es la arquitectura estandar de AWS para la automatizacion de incidentes de seguridad.
Puntos clave del examen
"Auto-detectar retiro de EC2 + reinicio automatico" -- EventBridge(source: aws.health, AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED) + SSM Automation
"Detectar creacion de usuario IAM instantaneamente + auto-deshabilitar" -- CloudTrail + EventBridge(source: aws.iam, CreateUser) + Lambda
"Aislar mensajes que fallan repetidamente + proteger flujo normal" -- SQS Dead Letter Queue(maxReceiveCount)
"Escalar consumidores de DynamoDB Streams + sin throttling" -- Kinesis Data Streams Enhanced Fan-Out
"Detectar crash de proceso + recuperar sin reemplazo de instancia" -- CloudWatch Agent procstat + CloudWatch Alarm + SSM Run Command
"Preservar logs antes de la terminacion de instancia" -- ASG Lifecycle Hook(Terminating:Wait) + Lambda + complete-lifecycle-action
"Push de CodeCommit no dispara pipeline" -- Verificar estado ENABLED/DISABLED de regla EventBridge
"Todos los eventos de CodeDeploy Skipped" -- Subred privada sin endpoin