Amazon DOP-C02: Arquitecturas Orientadas a Eventos y Automatización — Guía de estudio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Forma parte de la AWS DevOps Engineer Professional DOP-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Enrutamiento, orquestación y programación: EventBridge y Step Functions

Amazon EventBridge es el bus de eventos central para el enrutamiento, la gobernanza y la integración entre cuentas y dominios de eventos. Usa el bus predeterminado para eventos de servicios de AWS, buses personalizados para segmentar dominios y aplicar permisos, y buses de socios para integraciones con SaaS. Las reglas coinciden con los eventos mediante patrones basados en contenido y pueden tener como destino más de 200 servicios de AWS. Usa transformadores de entrada para dar forma a los payloads y la función de archivar/reproducir para reprocesar eventos históricos durante una recuperación o la incorporación de nuevos consumidores. Las políticas de recursos permiten el enrutamiento de eventos entre cuentas para consolidar la gobernanza en una cuenta de plataforma. EventBridge Pipes proporciona flujos punto a punto configurables desde orígenes de eventos (SQS, Kinesis, DynamoDB Streams, Apache Kafka autogestionado en Amazon MSK y otros) hacia destinos, con filtrado, procesamiento por lotes, transformación y enriquecimiento integrados a través de Lambda o Step Functions. Es ideal cuando no quieres gestionar una aplicación de consumidor completa pero necesitas una mediación ligera. EventBridge Scheduler ofrece programaciones de una sola vez y tipo cron para invocar destinos con un rol de ejecución, soporte para zonas horarias y ventanas de tiempo flexibles opcionales para reducir el efecto de estampida (thundering herds).

AWS Step Functions orquesta flujos de trabajo distribuidos definidos en Amazon States Language con estados como Task, Choice, Parallel, Map (incluido Map distribuido), Wait, Pass, Succeed/Fail, y patrones robustos de reintento (Retry) y captura de errores (Catch). Las integraciones profundas con servicios eliminan la necesidad de código de acoplamiento (glue code) para llamar a las API de AWS, incluyendo patrones síncronos (.sync) y de callback con tokens de tarea. Elige flujos de trabajo estándar (Standard Workflows) para orquestaciones de larga duración y con mucha auditoría, con una progresión de estado de tipo exactly-once, una duración de hasta un año y un precio por transición de estado; el historial de ejecución se conserva, con una gran visibilidad y trazas de X-Ray integradas. Elige flujos de trabajo rápidos (Express Workflows) para orquestaciones de alto rendimiento y corta duración (de segundos a minutos) donde puedes optar por un precio por solicitud + duración y una semántica de ejecución at-least-once a cambio de una escala masiva; úsalos para enriquecimientos en la ingesta de streams, enrutadores de eventos y microorquestaciones donde puedes hacer que las tareas sean idempotentes. Aplica patrones como el patrón saga con tareas de compensación y un manejo de errores centralizado; externaliza los reintentos y los tiempos de espera (timeouts) en la máquina de estados para simplificar el código de las tareas.

Disparadores de cómputo y contrapresión (backpressure): Mapeos de orígenes de eventos de Lambda

Los mapeos de orígenes de eventos de Lambda (ESM) conectan orígenes basados en sondeo (poll-based) con Lambda y controlan la concurrencia, el procesamiento por lotes y el manejo de errores.

• SQS: Lambda escala horizontalmente sondeando la cola e invocando tu función con lotes (hasta 10 mensajes; ventana máxima de procesamiento por lotes de hasta 300 segundos). Con colas estándar, el escalado es agresivo según la profundidad y el rendimiento de los mensajes; con FIFO, Lambda preserva el orden por grupo de mensajes y procesa un lote por grupo a la vez. Configura la concurrencia máxima en el ESM para limitar la escala de los workers y proteger los sistemas posteriores; combínalo con concurrencia reservada/aprovisionada para garantizar la capacidad. Usa la respuesta parcial de lote para confirmar solo los registros exitosos y volver a encolar los fallidos, evitando la reproducción de todo el lote. Establece el tiempo de espera de visibilidad de la cola para que exceda el total de reintentos en el peor de los casos. Las DLQ y las políticas de reenvío (redrive policies) aíslan los mensajes corruptos (poison messages).

• Kinesis Data Streams: Una invocación concurrente de Lambda por shard por defecto asegura el orden dentro de cada shard. Aumenta el ParallelizationFactor hasta 10 para procesar múltiples lotes por shard de forma concurrente cuando el orden entre subsecuencias es aceptable. Un tamaño de lote de hasta 10,000 registros (6 MB) y una ventana máxima de procesamiento por lotes de hasta 5 minutos te permiten amortizar costos y aumentar el rendimiento. Usa la bisección en caso de error de la función (bisect on function error) para buscar mediante búsqueda binaria los registros defectuosos dentro de un lote, y usa destinos en caso de fallo o un número máximo de reintentos/antigüedad del registro para descartar o enrutar registros no procesables. Monitorea el IteratorAge para detectar retrasos en el consumidor y reajustar los shards o aumentar la paralelización según sea necesario.

• DynamoDB Streams: Similar a Kinesis en semántica; tamaño de lote de hasta 1,000 registros (6 MB) y un modelo de un shard por clave de partición. Los consumidores reciben mutaciones ordenadas a nivel de ítem (INSERT, MODIFY, REMOVE). Aplica el mismo manejo de fallos (bisección en caso de error, intentos máximos de reintento, antigüedad del registro) y filtrado. Usa el tipo de vista del stream que incluya los atributos que tu consumidor necesita (NewImage, OldImage, NewAndOldImages o KeysOnly) para optimizar el tamaño del payload.

El filtrado de eventos en los ESM reduce las invocaciones al descartar eventos no relevantes en el propio sondeador (poller). Usa la agregación en ventanas de saltos temporales (tumbling window) en los streams con Lambda para agregar registros a lo largo del tiempo para patrones de procesamiento de minilotes.

Automatización de operaciones y remediación: Systems Manager Automation y OpsCenter

AWS Systems Manager Automation proporciona runbooks (documentos de tipo Automation) escritos en JSON/YAML con pasos como

undefined

,

undefined

,

undefined

,

undefined

,

undefined

y

undefined

. Las automatizaciones (Automations) aceptan parámetros, emiten salidas, se versionan con un historial de cambios y se ejecutan con un rol dedicado AutomationAssumeRole para operaciones con privilegio mínimo y entre cuentas y regiones. Controle la concurrencia y los umbrales de error en todas las flotas, requiera aprobaciones y ventanas de Change Calendar, e intégrese con notificaciones a través de SNS. Invoque las automatizaciones según una programación, desde reglas de EventBridge (para la remediación casi en tiempo real de eventos de AWS Health, CloudWatch o API), desde remediaciones de AWS Config para hacer cumplir las políticas (por ejemplo, aplicando etiquetas predeterminadas a los volúmenes de EBS o adjuntando un perfil de instancia predeterminado a las instancias de EC2) y desde OpsCenter.

OpsCenter agrega los problemas operativos en OpsItems a partir de alarmas de CloudWatch, AWS Config, eventos de Health o fuentes personalizadas. Cada OpsItem realiza un seguimiento del estado, la prioridad, la deduplicación, los recursos relacionados y los enlaces a runbooks. Asocie runbooks de un solo clic para soluciones estándar y habilite la remediación automática conectando reglas de EventBridge o Config para iniciar una Automation específica cuando se cree o actualice un OpsItem a una condición coincidente (por ejemplo, un grupo de seguridad que permita 0.0.0.0/0 en SSH, una desviación en el cumplimiento de parches o copias de seguridad fallidas). Use Systems Manager Explorer para visualizar el estado de la flota y los OpsItems abiertos entre cuentas y regiones. Esta combinación —OpsItems como registros duraderos más runbooks de Automation como soluciones codificadas— permite operaciones auditables y consistentes a escala.

Guía de diseño y operativa

Diseñe para la idempotencia en todos los consumidores, ya que la entrega de tipo at-least-once (al menos una vez) es común. Prefiera el fan-out basado en eventos a través de SNS o reglas de EventBridge para reacciones paralelas de baja latencia; prefiera SQS para amortiguar (buffer) las cargas de trabajo y proteger a los productores de la lentitud de los consumidores; prefiera Kinesis cuando se requiera un orden estricto por shard y flujos de datos (streams) reproducibles para analítica. Use EventBridge Pipes para una integración ligera y gestionada entre orígenes y destinos cuando un consumidor a medida es excesivo, y EventBridge Scheduler para disparadores (triggers) basados en tiempo sin mantener una infraestructura de cron.

Dimensione correctamente los tiempos de espera (timeouts) y los reintentos. Para SQS, el tiempo de espera de visibilidad (visibility timeout) debe exceder el procesamiento máximo más los reintentos; para los flujos de datos, limite los reintentos y establezca MaximumRecordAgeInSeconds para evitar reproducir indefinidamente registros erróneos. Use DLQs o destinos on-failure (en caso de fallo) sistemáticamente y agregue paneles (dashboards) y alarmas sobre SQS ApproximateAgeOfOldestMessage, Lambda ConcurrentExecutions/Throttles/Errors, IteratorAge, Step Functions ExecutionFailed/TimedOut y EventBridge FailedInvocations. Cuando el tráfico con picos (spiky) es inevitable pero los SLAs de latencia son estrictos, use la concurrencia aprovisionada de Lambda para precalentar (pre-warm) la capacidad. Para la gobernanza, prefiera EventBridge con políticas de recursos para el enrutamiento entre cuentas (cross-account) y el archivado/reproducción (archive/replay) para soportar la evolución de los consumidores y la recuperación de incidentes.

Escenario de problema práctico

Shopify necesita modernizar el procesamiento de pedidos para eventos de ventas relámpago (flash-sale) mientras añade analítica en tiempo real y remediación automatizada cuando los servicios dependientes (downstream) se ralentizan o fallan.

1. Ingerir y distribuir eventos de pedido (fan-out)

• Usar un tema FIFO de SNS para publicar eventos OrderPlaced desde el checkout, garantizando notificaciones ordenadas y sin duplicados por OrderId. Las suscripciones incluyen:
  • Una cola FIFO de SQS (Order-Workers) para el cumplimiento de pedidos (fulfillment), preservando el orden.
  • Un bus de eventos personalizado de EventBridge (CommerceBus) para gobernanza y enrutamiento adicional.
  • Un flujo de entrega (delivery stream) de Kinesis Data Firehose para la entrega casi en tiempo real de Pedidos a S3 con compresión GZIP para analítica. Por qué SNS FIFO: Proporciona semántica ordenada y exactly-once (exactamente una vez) con un fan-out escalable a múltiples suscriptores sin acoplar a los publicadores con los consumidores.

2. Amortiguar y procesar el cumplimiento de pedidos

• Lambda consume desde la cola FIFO de SQS a través de un mapeo de origen de eventos (event source mapping) con un tamaño de lote (batch size) de 10, respuesta de lote parcial habilitada, y una concurrencia máxima limitada para proteger las APIs del almacén dependientes. El tiempo de espera de visibilidad de la cola se establece en seis veces el timeout de Lambda para acomodar los reintentos. Una DLQ captura mensajes fallidos (poison messages) con maxReceiveCount=3; un flujo de trabajo de reenvío (redrive) reprocesa posteriormente los mensajes corregidos. Por qué SQS FIFO + Lambda ESM: Impone la secuenciación por pedido, aísla la lentitud de los servicios dependientes mediante el búfer y proporciona un manejo de errores de grano fino.

3. Orquestar una saga de múltiples pasos

• Un flujo de trabajo Standard de Step Functions orquesta la captura de pagos, la reserva de inventario, la detección de fraudes y la reserva de envíos con reintentos, timeouts y tareas de compensación (reembolso, reabastecimiento) en las rutas de fallo. La primera Tarea es disparada por una función Lambda invocada desde el consumidor de SQS. Por qué Standard: Progresión de estado de larga duración, auditable y exactly-once a través de sistemas externos con un manejo de errores robusto.

4. Enrutar eventos de dominio a capacidades

• El CommerceBus recibe eventos Order* a través de PutEvents desde los servicios productores y desde la suscripción de SNS. Reglas de EventBridge:
  • Hacer coincidir (match) OrderPlaced para notificar a Marketing (Lambda) y crear un caso de soporte (integración con la API de AWS Support) cuando clientes de alto valor realizan un pedido.
  • Reenviar OrderFailed al bus de eventos de una cuenta central de operaciones usando una política de recursos para la gobernanza entre cuentas. Por qué EventBridge: Enrutamiento centralizado, filtrado, entrega entre cuentas y la capacidad de añadir nuevos consumidores sin cambiar los productores.

5. Conectar (pipe) el feed de un socio para enriquecimiento

• EventBridge Pipes conecta la cola Standard de SQS de un socio (SKUs con pedidos pendientes) a un flujo de trabajo Express de Step Functions que enriquece los elementos a través de una función Lambda y envía los resultados a una cola SQS interna para reabastecimiento. Por qué Pipes + Express: Integración gestionada y de baja sobrecarga (low-overhead) con enriquecimiento ligero a alto rendimiento (throughput) y bajo costo.

6. Analítica y búsqueda en tiempo real

• Un Kinesis Data Stream recopila eventos de clickstream y operativos. Lambda (consumidor con Enhanced Fan-Out) realiza la sesionización, y Kinesis Data Analytics agrega los KPIs. Firehose entrega los pedidos transformados y la analítica a un data lake en S3 y a Amazon OpenSearch Service con particionamiento dinámico por fecha/mercado para consultas eficientes. Por qué Streams + Firehose: Procesamiento ordenado y de baja latencia para analítica, con entrega y transformación gestionadas hacia el almacenamiento y la búsqueda.

7. Automatización basada en tiempo

• EventBridge Scheduler ejecuta un cron cada minuto para publicar InventorySnapshotRequested en CommerceBus, disparando un flujo de trabajo Express de Step Functions que compila instantáneas (snapshots) de todos los almacenes para una precisión del stock casi en tiempo real. Por qué Scheduler: Cron nativo y resiliente sin infraestructura personalizada.

8. Remediación y operaciones automatizadas

• Las reglas de AWS Config detectan SSH abierto o ACLs públicas de S3 en las VPCs de cumplimiento de pedidos. Las remediaciones gestionadas invocan runbooks de Systems Manager Automation para corregir la desviación de configuración (drift). Las alarmas de CloudWatch sobre SQS ApproximateAgeOfOldestMessage y Lambda IteratorAge crean OpsItems en OpsCenter; los runbooks asociados escalan la concurrencia aprovisionada en Lambdas específicas, aumentan la capacidad reservada de Step Functions o amplían temporalmente las ventanas de lote (batch windows). Una regla de EventBridge sobre eventos de mantenimiento de EC2 de AWS Health apunta a un documento de SSM Automation para reiniciar de forma controlada (gracefully) las instancias afectadas durante las ventanas de mantenimiento. Por qué OpsCenter + Automation: Seguimiento de problemas centralizado y auditable con remediaciones de un solo clic o automáticas, con el mínimo privilegio, que se ejecutan de forma segura entre cuentas/regiones.

Este diseño soporta los picos de las ventas relámpago a través del buffering y el fan-out, preserva las invariantes del negocio mediante la orquestación, entrega analítica en segundos y cierra el ciclo con una remediación automatizada y dirigida por políticas.

← Alta Disponibilidad · Todos los dominios · Almacenamiento →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Amazon →