Curso AWS Cloud Practitioner CLF-C02

Los servicios de integración de aplicaciones permiten que diferentes componentes de una solución se comuniquen sin depender demasiado unos de otros. En AWS, esto es muy importante porque muchas arquitecturas modernas se construyen con varios servicios pequeños: una API, una función Lambda, una cola, una base de datos, un evento, un proceso de aprobación o una notificación.

Para el examen AWS Certified Cloud Practitioner CLF-C02 no necesitas diseñar una arquitectura distribuida avanzada, pero sí debes reconocer qué servicio encaja mejor según el caso de uso: SQS para colas, SNS para publicación y suscripción, EventBridge para eventos, API Gateway para exponer APIs y Step Functions para coordinar workflows.

1. Por qué integrar aplicaciones

Imagina una tienda online. Cuando un cliente realiza un pedido, pueden ocurrir muchas acciones: validar pago, guardar el pedido, enviar un correo, actualizar inventario, generar una factura, avisar a logística y registrar métricas. Podrías hacer que una sola aplicación lo hiciera todo en una única operación, pero eso genera dependencia fuerte: si una parte falla, puede afectar al proceso completo.

Los servicios de integración ayudan a separar responsabilidades:

• Un componente puede enviar un mensaje y continuar sin esperar a que todo se procese.
• Varios sistemas pueden reaccionar al mismo evento.
• Una API puede exponer un backend de forma controlada.
• Un flujo puede coordinar pasos con reintentos, ramas y errores.
• Los sistemas pueden absorber picos de tráfico sin romperse.

2. Concepto clave: desacoplamiento

El desacoplamiento significa reducir la dependencia directa entre componentes. Si el componente A depende demasiado del componente B, cualquier lentitud o fallo en B puede afectar directamente a A. Con una cola, un evento o un sistema de notificaciones, A puede enviar información y B puede procesarla después.

En CLF-C02, cuando una pregunta mencione desacoplar, procesamiento asíncrono, buffering o absorber picos, debes pensar rápidamente en servicios como Amazon SQS.

3. Comunicación síncrona y asíncrona

Hay dos formas de comunicación muy importantes:

• Síncrona: un sistema llama a otro y espera respuesta. Por ejemplo, una app llama a una API HTTP.
• Asíncrona: un sistema envía un mensaje o evento y no necesita esperar a que todo termine en ese momento.

API Gateway suele aparecer en escenarios síncronos, porque expone endpoints para que clientes o aplicaciones llamen a una API. SQS, SNS y EventBridge suelen aparecer en escenarios asíncronos, donde los componentes se comunican mediante mensajes o eventos.

4. Amazon SQS

Amazon Simple Queue Service, o SQS, es un servicio de colas de mensajes totalmente gestionado. Una cola permite que un productor envíe mensajes y que uno o varios consumidores los procesen después.

SQS es especialmente útil para:

• Desacoplar componentes.
• Absorber picos de tráfico.
• Procesar tareas en segundo plano.
• Evitar que un consumidor lento bloquee al productor.
• Crear arquitecturas más resilientes.

5. SQS Standard y SQS FIFO

En CLF-C02 puede aparecer una distinción básica entre colas Standard y FIFO:

• SQS Standard: alta escala y entrega al menos una vez. El orden exacto no está garantizado.
• SQS FIFO: conserva el orden de los mensajes y ayuda a evitar duplicados en escenarios donde el orden importa.

No necesitas entrar en configuración avanzada. La regla mental es sencilla: si la pregunta menciona que el orden de procesamiento es crítico, puede aparecer FIFO.

6. Visibilidad y mensajes no procesados

Un concepto útil para entender SQS es el visibility timeout. Cuando un consumidor lee un mensaje, el mensaje queda temporalmente invisible para otros consumidores. Si el consumidor lo procesa correctamente, lo elimina. Si no lo elimina, el mensaje puede volver a estar disponible para reintento.

Para CLF-C02 no necesitas configurar valores, pero sí entender que SQS ayuda a procesar mensajes de forma fiable y que puede soportar reintentos cuando algo falla.

7. Dead-letter queue

Una dead-letter queue, o DLQ, es una cola donde se envían mensajes que no han podido procesarse correctamente después de varios intentos. Sirve para investigar errores sin bloquear el flujo principal.

En preguntas de examen, si ves mensajes que fallan repetidamente y se necesita aislarlos para análisis, una DLQ puede formar parte de la solución.

8. Amazon SNS

Amazon Simple Notification Service, o SNS, es un servicio de publicación y suscripción. Un productor publica un mensaje en un tema, y SNS entrega ese mensaje a los suscriptores.

Los suscriptores pueden ser, entre otros:

• Colas SQS.
• Funciones Lambda.
• Endpoints HTTP/S.
• Correos electrónicos.
• SMS, según disponibilidad y caso de uso.

9. Patrón fanout con SNS y SQS

El patrón fanout aparece mucho en integración. Consiste en enviar un mismo mensaje a varios destinos. Un ejemplo típico es publicar un evento de pedido en SNS y que varias colas SQS lo reciban: una para inventario, otra para facturación y otra para logística.

10. SQS frente a SNS

Esta diferencia es clave para aprobar:

• SQS: cola. Un mensaje espera hasta que un consumidor lo procese.
• SNS: pub/sub. Un mensaje se publica a uno o varios suscriptores.

SQS se centra en desacoplar y guardar mensajes para procesamiento. SNS se centra en notificar o distribuir mensajes a varios destinos.

11. Amazon EventBridge

Amazon EventBridge es un bus de eventos serverless. Permite recibir eventos de servicios AWS, aplicaciones propias y aplicaciones SaaS, y enrutar esos eventos hacia destinos mediante reglas.

EventBridge aparece cuando el escenario habla de:

• Arquitecturas orientadas a eventos.
• Reaccionar a cambios en servicios AWS.
• Integrar aplicaciones SaaS.
• Crear reglas que envían eventos a distintos destinos.
• Programar eventos o tareas basadas en tiempo.

12. EventBridge no es simplemente una cola

Un error común es pensar que EventBridge es lo mismo que SQS. No lo es. SQS almacena mensajes en una cola hasta que un consumidor los procesa. EventBridge enruta eventos desde fuentes hacia destinos usando reglas.

Si la pregunta dice “cola”, “buffer”, “consumidor”, “procesamiento posterior” o “mensajes esperando”, SQS suele encajar. Si dice “eventos”, “reglas”, “bus de eventos”, “servicios AWS” o “SaaS”, EventBridge suele encajar.

13. Amazon API Gateway

Amazon API Gateway permite crear, publicar, proteger, monitorizar y gestionar APIs. Es muy común junto con AWS Lambda en arquitecturas serverless, pero también puede integrarse con otros backends.

API Gateway aparece en CLF-C02 cuando el escenario habla de:

• Exponer endpoints HTTP/REST.
• Crear una API para una aplicación web o móvil.
• Gestionar acceso a una API.
• Integrar clientes con funciones Lambda.
• Controlar tráfico, autenticación, throttling o versiones de API a alto nivel.

14. API Gateway y Lambda

Un patrón muy habitual es API Gateway + Lambda. API Gateway recibe una petición HTTP desde un cliente, como una web o app móvil, y llama a una función Lambda que ejecuta la lógica.

Para CLF-C02, lo importante no es programar la API, sino reconocer la arquitectura: clientes llaman a una API gestionada; API Gateway controla la entrada; Lambda ejecuta código sin servidores.

15. AWS Step Functions

AWS Step Functions permite coordinar procesos de varios pasos mediante workflows. Un workflow puede llamar a funciones Lambda, servicios AWS, tareas humanas o integraciones, y controlar estados, reintentos, errores y ramas de decisión.

Step Functions aparece cuando el escenario menciona:

• Orquestar varios pasos.
• Coordinar un proceso de negocio.
• Gestionar reintentos y errores.
• Crear flujos visuales.
• Ejecutar una secuencia de tareas dependientes.

16. Orquestación frente a coreografía

Esta diferencia ayuda a razonar muchas preguntas:

• Orquestación: hay un flujo central que coordina pasos. Step Functions encaja muy bien aquí.
• Coreografía basada en eventos: los servicios reaccionan a eventos sin un coordinador central fuerte. EventBridge, SNS y SQS pueden participar.

Para el examen, si la pregunta habla de un proceso con pasos definidos, estados y reintentos, piensa en Step Functions. Si habla de sistemas que reaccionan a eventos, piensa en EventBridge o SNS según el caso.

17. Comparativa principal para CLF-C02

18. Tabla de decisión rápida

19. SQS, SNS y EventBridge juntos

Estos servicios no son excluyentes. En arquitecturas reales se combinan. Por ejemplo:

• SNS puede enviar el mismo mensaje a varias colas SQS.
• EventBridge puede recibir eventos y enviarlos a Lambda o Step Functions.
• SQS puede proteger a un consumidor ante picos de eventos.
• Step Functions puede coordinar llamadas a varios servicios.

Para CLF-C02, no te compliques demasiado. Primero identifica el requisito principal. Luego elige el servicio que mejor encaja con esa palabra clave.

20. Patrones habituales de integración

Estos patrones aparecen con frecuencia en preguntas y explicaciones:

• Queue-based load leveling: usar una cola para absorber picos y procesar a ritmo controlado.
• Fanout: publicar un mensaje y entregarlo a varios destinos.
• Event-driven architecture: servicios que reaccionan a eventos.
• API façade: exponer una API gestionada delante de backends.
• Workflow orchestration: coordinar un proceso completo con estados y errores.

21. Servicios que se confunden

22. Errores típicos

• Elegir SNS cuando la pregunta pide una cola donde los mensajes esperen a ser procesados.
• Elegir SQS cuando el requisito principal es enviar una notificación a muchos suscriptores.
• Pensar que EventBridge es solo otra cola.
• Usar API Gateway para coordinar procesos largos con muchos pasos, cuando Step Functions encaja mejor.
• Olvidar el patrón SNS + SQS para fanout desacoplado.
• Confundir orquestación de workflows con simple ejecución de código.
• No reconocer que SQS ayuda a absorber picos y evitar presión directa sobre consumidores.
• No asociar API Gateway con APIs HTTP/REST/WebSocket gestionadas.
• Olvidar que una DLQ ayuda con mensajes fallidos.
• Elegir Step Functions para simple notificación masiva.

23. Cómo razonar preguntas tipo examen

Cuando una pregunta mencione integración, busca primero la palabra clave:

• Si ves cola, buffer, consumidor o procesamiento asíncrono, piensa en SQS.
• Si ves notificar a varios, pub/sub o fanout, piensa en SNS.
• Si ves eventos, reglas, SaaS o arquitectura event-driven, piensa en EventBridge.
• Si ves API, endpoint HTTP, REST o WebSocket, piensa en API Gateway.
• Si ves workflow, pasos, estado, reintentos o orquestación, piensa en Step Functions.

Resumen final

Los servicios de integración de aplicaciones ayudan a construir soluciones desacopladas y más resilientes. SQS se usa para colas y procesamiento asíncrono. SNS se usa para pub/sub y fanout. EventBridge se usa para eventos y reglas de enrutamiento. API Gateway expone APIs gestionadas. Step Functions coordina workflows con pasos, estados y reintentos.

Para aprobar CLF-C02, céntrate en reconocer escenarios. Si una pregunta habla de una cola, no te vayas a SNS. Si habla de notificar a muchos, no elijas SQS como primera opción. Si habla de eventos y reglas, piensa en EventBridge. Si habla de endpoints HTTP, piensa en API Gateway. Si habla de pasos coordinados, piensa en Step Functions.