El dominio D2 (29%) cubre el diseño de nuevas soluciones cloud-native. Las arquitecturas orientadas a eventos son el patrón central para sistemas desacoplados y escalables en AWS a nivel profesional.
Contenido
Fan-out
Un evento desencadena múltiples consumidores independientes en paralelo. SNS → múltiples SQS queues o Lambda functions.
Orden creada → notificar inventario + facturación + email al cliente
Event Choreography
Cada servicio reacciona a eventos y emite nuevos eventos. Sin orquestador central. Más desacoplado pero más difícil de observar.
Microservicios que publican y consumen de EventBridge sin conocerse entre sí
Event Orchestration
Un orquestador central (Step Functions) dirige el flujo llamando a servicios en secuencia. Mejor visibilidad pero mayor acoplamiento.
Step Functions ejecuta Lambda → DynamoDB → SES → notifica al usuario
EventBridge es el event bus serverless de AWS. Recibe eventos de servicios AWS, SaaS partners y aplicaciones propias, los filtra con reglas basadas en patrones, y los enruta a targets. Anteriormente llamado CloudWatch Events.
Event Bus
Canal donde fluyen los eventos. Por defecto existe el "default" bus (eventos de servicios AWS). Se pueden crear custom buses para apps propias y SaaS.
Rules
Filtros con patrones JSON que determinan qué eventos se envían a qué targets. Soporta content-based filtering avanzado.
Targets
20+ targets: Lambda, SQS, SNS, Step Functions, Kinesis, ECS Task, SSM, CodePipeline, cross-account event bus y más.
Schema Registry
Registra y versiona el esquema (formato) de los eventos. Genera código de binding automáticamente.
Pipes
Integración punto a punto con transformación y enriquecimiento: source → filter → enrich → target.
| EventBridge | SNS |
|---|---|
| Filtrado basado en contenido del evento | Filtrado por message attributes (limitado) |
| Routing a 20+ tipos de targets | Targets: Lambda, SQS, HTTP, email, SMS |
| Schema Registry con generación de código | Sin schema registry |
| Eventos de 200+ SaaS partners | Solo eventos de producción AWS |
| Cross-account y cross-region nativamente | Cross-account con resource policy |
| Latencia ~1s (más lento) | Latencia sub-segundo (más rápido) |
EventBridge Scheduler
EventBridge Scheduler (no confundir con Rules de tipo cron) permite crear schedules one-time o recurrentes para invocar targets. Soporta millions de schedules por cuenta con ventanas flexibles de ejecución. Reemplaza el uso de CloudWatch Events + Lambda para scheduling.
Step Functions es el servicio de orquestación de AWS. Define flujos de trabajo (state machines) en Amazon States Language (ASL/JSON) que coordinan múltiples servicios AWS con lógica de retry, branching, error handling y paralelismo.
| Característica | Standard Workflows | Express Workflows |
|---|---|---|
| Duración máxima | Hasta 1 año | Hasta 5 minutos |
| Ejecuciones simultáneas | 2,000 (por defecto) | Más de 100,000/seg |
| Semántica de ejecución | Exactly-once | At-least-once |
| Modelo de costo | Por transición de estado | Por duración + número de ejecuciones |
| Historial auditable | Sí — CloudWatch y Step Functions console | Solo CloudWatch Logs |
| Mejor para | Órdenes, aprobaciones, flujos críticos | IoT, streaming, alta concurrencia |
Task
Invoca un servicio AWS (Lambda, ECS, DynamoDB, etc.) o ejecuta actividades.
Choice
Branching condicional basado en variables de estado.
Parallel
Ejecuta múltiples ramas en paralelo y espera a que todas completen.
Map
Itera sobre un array procesando cada ítem en paralelo.
Wait
Pausa el workflow hasta una fecha/tiempo o señal externa.
Pass/Fail/Succeed
Manipulación de estado, manejo de errores y finalización.
SDK Integrations (Optimized) vs Lambda Invoke
Step Functions tiene integraciones nativas con 200+ APIs de servicios AWS sin necesidad de Lambda como intermediario. Por ejemplo, invocar DynamoDB:PutItem directamente desde un Task state. Esto reduce latencia y costo vs usar Lambda solo para llamar a otro servicio.
| Servicio | Modelo | Retención | Consumo | Mejor para |
|---|---|---|---|---|
| Kinesis Data Streams | Pub/Sub de streams | 24h–365 días | KCL, Lambda, SDK — tú gestionas los consumers | Procesamiento en tiempo real con control total del consumer. Múltiples consumidores del mismo stream. |
| Kinesis Data Firehose | ETL gestionado | No guarda (delivery directo) | Automático — entrega a S3, Redshift, OpenSearch, Splunk | Ingesta y entrega automática a destinos de analytics sin código. |
| Kinesis Data Analytics | Queries en streaming | Procesa en tiempo real | Flink o SQL sobre streams de KDS/Firehose | Análisis y transformación de streams con SQL o Apache Flink. |
| Kinesis Video Streams | Streaming de video | Configurable | SDK, HLS, DASH, WebRTC | Ingestar y procesar video de cámaras/dispositivos IoT. |
Kinesis Data Streams — conceptos de capacidad
Kinesis vs SQS — decisión de diseño
¿Múltiples consumidores leen el mismo dato?
→ Kinesis (fan-out nativo)
¿Necesitas orden garantizado dentro de una clave?
→ Kinesis (mismo shard)
¿Necesitas replay de datos históricos?
→ Kinesis (retención hasta 365 días)
¿Cada mensaje debe ser procesado exactamente una vez?
→ SQS (exactly-once con deduplication)
¿Desacoplamiento simple punto a punto?
→ SQS (más simple de gestionar)
¿Análisis de series temporales en tiempo real?
→ Kinesis Data Analytics + KDS
SNS — patrones avanzados para el SAP-C02
SNS Message Filtering
Cada subscripción SQS/Lambda puede tener un filter policy JSON. Solo recibe mensajes que coinciden con los attributes del mensaje. Evita enrutar todos los mensajes a todos los consumers.
SNS FIFO + SQS FIFO
Para fan-out con orden garantizado y exactly-once delivery. SNS FIFO → múltiples SQS FIFO queues. Cada queue recibe los mensajes en el mismo orden.
SNS + DLQ
Subscripciones SQS pueden tener Dead Letter Queue para mensajes que no se pueden entregar después de múltiples intentos.
SQS — características de alto nivel
| Escenario | Servicio recomendado | Razón |
|---|---|---|
| Desacoplar microservicios con workers independientes | SQS | Cola simple, at-least-once, fácil de escalar con Lambda o ASG |
| Fan-out: un evento → múltiples procesadores en paralelo | SNS + SQS (fan-out pattern) | SNS distribuye el mismo mensaje a múltiples queues SQS |
| Reaccionar a eventos de servicios AWS (EC2 stop, S3 upload) | EventBridge (default bus) | Default bus recibe eventos nativos de 200+ servicios AWS |
| Integrar con Salesforce, Zendesk, Datadog | EventBridge (SaaS bus) | EventBridge tiene integraciones nativas con 200+ SaaS partners |
| Orquestar un proceso multi-paso con retry y compensación | Step Functions | Visualización del flujo, retry automático, exactly-once con Standard |
| Procesar stream de clickstream/IoT en tiempo real | Kinesis Data Streams | Retención, replay, múltiples consumers, orden por partition key |
| Entregar logs/eventos a S3 o Redshift sin código | Kinesis Firehose | Entrega gestionada con transformación Lambda opcional |
| Analizar stream en tiempo real con SQL | Kinesis Data Analytics | Flink managed para queries sobre KDS o Firehose |
Trampa: "EventBridge y CloudWatch Events son servicios diferentes"
Realidad: Son el mismo servicio. EventBridge es la evolución de CloudWatch Events. Los conceptos son idénticos; EventBridge tiene más funcionalidades.
Trampa: "Step Functions Standard garantiza exactly-once siempre"
Realidad: Standard garantiza exactly-once para invocaciones de actividades y lambdas. Express es at-least-once. Ambos tienen retries configurables.
Trampa: "Kinesis Firehose permite múltiples consumidores como Kinesis Streams"
Realidad: FALSO. Firehose entrega a un solo destino (S3, Redshift, OpenSearch, etc.). Para múltiples consumidores del mismo stream, usa Kinesis Data Streams.
Trampa: "SQS FIFO garantiza exactamente-una-vez siempre"
Realidad: FIFO garantiza exactly-once dentro de la ventana de deduplicación de 5 minutos usando MessageDeduplicationId. Sin ese ID configurado, puede haber duplicados.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa de e-commerce procesa 50,000 órdenes por hora. Cuando se crea una orden, necesitan: (1) actualizar el inventario, (2) generar la factura, (3) enviar email de confirmación, y (4) publicar el evento en el Data Warehouse. Todos en paralelo. Las operaciones deben ser idempotentes. ¿Cuál es la arquitectura más apropiada?
Inicia sesión para llevar tu progreso.