Amazon SAA-C03: Integración de aplicaciones, mensajería y streaming — Guía de estudio

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Forma parte de la AWS SAA-C03 — Guía de estudio completa. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Amazon SQS: Desacoplamiento, orden y semántica de entrega

Amazon SQS es una cola de mensajes totalmente gestionada y basada en pull cuyo rol arquitectónico principal es desacoplar a los productores de los consumidores. Una cadena de llamadas síncrona vincula la latencia y la disponibilidad del productor a cada dependencia descendente; insertar una cola SQS convierte eso en una transferencia asíncrona. Los productores ponen mensajes en cola al ritmo que llega el tráfico, y los consumidores sacan mensajes de la cola al ritmo que pueden procesar de forma segura. Esta es la solución canónica para las ráfagas de escritura que de otro modo saturarían una instancia de RDS: la cola absorbe la ráfaga, y una flota limitada de consumidores la vacía con una concurrencia controlada, manteniendo bajo control el número de conexiones a la base de datos.

Existen dos tipos de colas, y la elección determina tanto el rendimiento (throughput) como las garantías de entrega.

Las colas estándar entregan al menos una vez (at-least-once) con solo un ordenamiento basado en el mejor esfuerzo. Pueden aparecer duplicados cuando un consumidor no elimina un mensaje antes de que expire el tiempo de espera de visibilidad, o cuando el backend distribuido reproduce un mensaje entre particiones (shards). Incluso si nunca ves un duplicado en las pruebas, el servicio está arquitectónicamente autorizado a volver a entregar, especialmente durante una conmutación por error (failover) del intermediario (broker). Asumir que las colas estándar “normalmente” entregarán una vez es un defecto de diseño, no un riesgo operativo; se garantiza que los duplicados ocurrirán eventualmente a escala. Por lo tanto, la lógica del consumidor debe ser idempotente: rastrear un MessageId o una clave de negocio en DynamoDB con una escritura condicional, usar una clave de idempotencia en las llamadas a API posteriores, o confiar en la semántica de upsert.

Las colas FIFO proporcionan un orden estricto dentro de un MessageGroupId y un procesamiento de tipo exactamente una vez (exactly-once) a través de un MessageDeduplicationId (ya sea explícito o un SHA-256 del cuerpo) que suprime los duplicados durante una ventana de 5 minutos. El MessageGroupId es el concepto fundamental: todos los mensajes que comparten un ID de grupo se entregan estrictamente en orden a un único consumidor a la vez, mientras que los diferentes ID de grupo pueden procesarse en paralelo. Para un sistema de procesamiento de pedidos donde los eventos de cada cliente deben ser secuenciales pero los diferentes clientes son independientes, usa MessageGroupId = customerId. Usar un único ID de grupo para todo serializa la carga de trabajo completa y destruye el rendimiento. Los ID de deduplicación son la primitiva correcta para evitar la creación de pedidos duplicados cuando un usuario reenvía un pago que se quedó colgado: el cliente genera un token de idempotencia determinista (un UUID vinculado a la sesión de pago) y SQS descarta cualquier envío duplicado que llegue dentro de la ventana.

PaymentsQueue:
  Type: AWS::SQS::Queue
  Properties:
    QueueName: payments.fifo
    FifoQueue: true
    ContentBasedDeduplication: true
    DeduplicationScope: messageGroup
    FifoThroughputLimit: perMessageGroupId
    VisibilityTimeout: 60
    RedrivePolicy:
      deadLetterTargetArn: !GetAtt PaymentsDLQ.Arn
      maxReceiveCount: 5

Seleccionar una cola estándar cuando el requisito indica “orden” o “sin duplicados” es el error clásico. Ninguna cantidad de lógica de aplicación puede restaurar un orden que la cola nunca conservó, porque los mensajes de diferentes hosts del backend llegan intercalados. Elige FIFO siempre que la carga de trabajo exija orden (registros de transacciones, transiciones de máquinas de estado) o semántica de entrega única (captura de pagos, decremento de inventario).

Tiempo de espera de visibilidad, mensajes fallidos y límites de carga útil

Cuando un consumidor recibe un mensaje, SQS lo hace invisible para otros consumidores durante el tiempo de espera de visibilidad (predeterminado de 30 segundos, máximo de 12 horas). Si el consumidor elimina el mensaje antes de que expire el tiempo de espera, este desaparece; si no —porque el consumidor falló o el procesamiento simplemente tardó demasiado— el mensaje reaparece y se entrega de nuevo. Establecer el tiempo de espera de visibilidad más corto que el tiempo de procesamiento real es una de las principales causas del procesamiento duplicado: una Lambda que tarda 45 segundos contra una cola con el tiempo de espera predeterminado de 30 segundos reprocesará cada mensaje al menos dos veces. Establece el tiempo de espera como mínimo al tiempo de procesamiento p99 (la recomendación de AWS para colas controladas por Lambda es de al menos 6 veces el tiempo de espera de la función), y para trabajos de duración impredecible, extiende el tiempo de espera dinámicamente:

sqs.change_message_visibility(
    QueueUrl=queue_url,
    ReceiptHandle=handle,
    VisibilityTimeout=300  # extend by 5 minutes
)

Las colas de mensajes fallidos (dead-letter queues, DLQ) capturan los mensajes que no se pueden procesar (poison-pill messages). Una RedrivePolicy en la cola de origen especifica un maxReceiveCount (típicamente de 3 a 5); una vez superado, SQS mueve el mensaje a la DLQ para su inspección fuera de línea. La DLQ debe ser del mismo tipo que la cola de origen (FIFO ↔ FIFO). Sin una DLQ, los mensajes con formato incorrecto entran en un bucle indefinido, y en las colas FIFO esto es especialmente perjudicial: el orden impide que los mensajes posteriores del mismo grupo se entreguen hasta que se solucione el problema con el mensaje infractor, por lo que un solo mensaje erróneo detiene a todo un grupo.

Los mensajes de SQS tienen un límite de 256 KB. Para cargas útiles más grandes —por ejemplo, un trabajo que transporta un documento renderizado— utiliza la SQS Extended Client Library, que escribe la carga útil en S3 y solo pone en cola una referencia al bucket y la clave. La librería del consumidor la recupera de forma transparente al recibir el mensaje. No dividas las cargas útiles en varios mensajes (pierdes atomicidad y orden) y no codifiques en base64 un blob de 2 MB con la esperanza de que quepa.

Autoescalado impulsado por la cola

Para una flota de consumidores en EC2 o ECS detrás de una cola SQS, la señal de escalado correcta no es la CPU, sino el trabajo pendiente en la cola (backlog). La CPU va por detrás de la tasa de llegada y malinterpreta a un consumidor saturado como “ocupado pero aguantando”. La métrica de escalado canónica es ApproximateNumberOfMessagesVisible, pero escalar directamente sobre la profundidad bruta de la cola es poco preciso. El enfoque recomendado es la métrica personalizada de trabajo pendiente por instancia (backlog-per-instance):

backlogPerInstance = ApproximateNumberOfMessagesVisible / RunningInstances

Publica esto en CloudWatch y úsalo para una política de seguimiento de destino en un Auto Scaling Group o un servicio de ECS para que cada trabajador mantenga un backlog acotado (por ejemplo, 10 mensajes). Esto produce un escalado horizontal (scale-out) suave durante las ráfagas y evita la oscilación cuando la profundidad de la cola es pequeña pero los consumidores ya están saturados. Para el escalado vertical hacia dentro (scale-in), combínalo con ApproximateAgeOfOldestMessage para evitar terminar capacidad mientras queden mensajes antiguos.

Amazon SNS: Fan-Out, Filtrado y Entrega entre Cuentas

SNS es un servicio de publicación/suscripción (pub/sub) basado en push. Los publicadores escriben en un tema (topic); SNS envía (hace push) a cada suscripción: colas SQS, funciones Lambda, puntos de conexión (endpoints) HTTP(S), correo electrónico, SMS, Kinesis Data Firehose o notificaciones push a móviles. El patrón de durabilidad dominante es el fan-out de SNS → SQS: un tema con múltiples colas SQS suscritas, de modo que cada servicio descendente tiene su propio búfer duradero, política de reintentos y DLQ, mientras que el publicador solo conoce el tema. Si un servicio consumidor se cae durante horas, su cola acumula mensajes y los procesa al recuperarse; SNS por sí solo carece de ese búfer y agotará su política de reintentos.

Producer ──▶ SNS topic ──┬──▶ SQS Queue A ──▶ Service A
                         ├──▶ SQS Queue B ──▶ Service B
                         └──▶ SQS Queue C ──▶ Service C

El filtrado de mensajes permite que cada suscripción declare una política de filtro JSON para que SNS entregue solo los mensajes que coincidan, evitando el antipatrón en el que cada consumidor recibe todos los mensajes y filtra del lado del cliente:

{
  "eventType": ["order_placed", "order_cancelled"],
  "region": ["us-east-1", "us-west-2"]
}

Dos propiedades de comportamiento son importantes. Primero, los temas estándar de SNS no garantizan el orden entre los mensajes; los temporizadores de reintento por suscriptor y las rutas de red independientes hacen que el reordenamiento sea rutinario. Si el orden importa, utiliza un tema FIFO de SNS suscrito a colas FIFO de SQS; el ID del grupo de mensajes se propaga de extremo a extremo. De lo contrario, los suscriptores deben ser idempotentes y tolerantes al reordenamiento. Segundo, las suscripciones HTTP(S) reintentan según una política de entrega (por defecto: tres reintentos inmediatos, luego un retroceso exponencial —exponential backoff— de hasta una hora, y después se descartan). Los suscriptores deben responder con un código 2xx en 15 segundos, validar la firma x-amz-sns-message-type y, para puntos de conexión poco fiables, tener siempre una DLQ de SNS (redirigida a SQS) para que los mensajes no entregados se capturen en lugar de descartarse silenciosamente.

La invocación entre cuentas es una trampa frecuente. Cuando la Cuenta A publica en un tema que se distribuye (fan-out) a una Lambda en la Cuenta B, se requieren dos políticas: la política del tema de SNS (o la dirección de la suscripción) debe permitir la suscripción, y la política basada en recursos de la Lambda debe permitir lambda:InvokeFunction desde sns.amazonaws.com con una condición SourceArn que coincida con el tema. Omitir la política de recursos de Lambda es el modo de fallo más común: la suscripción parece estar en buen estado, pero las invocaciones son rechazadas con un error 403. Si el tema está cifrado con una clave de KMS administrada por el cliente, la política de la clave también debe otorgar kms:Decrypt y kms:GenerateDataKey a la entidad principal que publica y a sns.amazonaws.com.

{
  "Effect": "Allow",
  "Principal": {"Service": "sns.amazonaws.com"},
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-1:222222222222:function:ProcessOrder",
  "Condition": {"ArnLike": {"AWS:SourceArn": "arn:aws:sns:us-east-1:111111111111:orders"}}
}

Amazon EventBridge: Buses de Eventos Enrutados

EventBridge (anteriormente CloudWatch Events) amplía el modelo pub/sub con enrutamiento basado en contenido, descubrimiento de esquemas, fuentes de eventos de socios SaaS y archivado/reproducción (archive/replay). Los eventos fluyen a través de buses de eventos (predeterminado, personalizado o de socio) y se comparan con reglas cuyos patrones de eventos filtran por la estructura JSON. Las reglas pueden transformar las cargas útiles (payloads) mediante rutas de entrada y plantillas de entrada, adjuntar destinos de mensajes fallidos (dead-letter targets) y entregar a más de 20 destinos nativos, incluyendo Lambda, Step Functions, tareas de ECS, SQS, SNS, Kinesis y destinos de API.

{
  "source": ["com.acme.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": {"amount": [{"numeric": [">", 500]}]}
}

La distinción con SNS es arquitectónica. SNS está optimizado para la difusión (broadcast) de alto rendimiento a suscriptores homogéneos con filtrado de atributos simple y menor latencia. EventBridge está optimizado para arquitecturas heterogéneas orientadas a eventos: muchos productores emiten diferentes esquemas de eventos y los consumidores se suscriben por patrón en lugar de por tema. Para un monolito que se está descomponiendo en microservicios, especialmente cuando los productores incluyen socios SaaS o servicios de AWS (Config, GuardDuty, CodePipeline, CloudTrail) que emiten eventos de forma nativa, EventBridge suele ser la opción correcta. Para un fan-out de volumen extremadamente alto y baja latencia a suscriptores idénticos, SNS sigue siendo superior porque EventBridge tiene una latencia por evento ligeramente mayor y un límite de rendimiento (throughput) predeterminado más bajo.

Amazon MQ: Mensajería con Bróker para Protocolos Existentes

Amazon MQ es un bróker administrado que ejecuta ActiveMQ o RabbitMQ. Existe para migrar cargas de trabajo on-premises que dependen de AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, OpenWire o JMS sin reescribir la aplicación. Si un sistema de pagos utiliza un bróker JMS de terceros con semántica transaccional de entrega única (exactly-once), migrarlo a Amazon MQ preserva el protocolo de comunicación (wire protocol) y las garantías de entrega, al tiempo que elimina la gestión de la infraestructura. Elige SQS/SNS/EventBridge para diseños nuevos y nativos de AWS (greenfield); elige Amazon MQ solo cuando la compatibilidad de protocolo es la restricción.

Kinesis Data Streams

Kinesis Data Streams (KDS) es un registro (log) duradero, ordenado y particionado para la ingesta de datos en streaming de alto rendimiento: clickstreams, telemetría de IoT, agregación de logs. Los registros se colocan en fragmentos (shards) según la PartitionKey; el orden se garantiza dentro de un shard, no en todo el stream. Cada shard soporta 1 MB/s o 1,000 registros/s de escritura y 2 MB/s de lectura (o más con Enhanced Fan-Out). Los registros se retienen 24 horas por defecto, extensible a 365 días, por lo que múltiples consumidores independientes pueden reproducir el mismo historial, algo que SQS no puede hacer porque SQS elimina los mensajes tras la confirmación (ack).

El modo bajo demanda (On-demand) elimina los cálculos de shards al escalar automáticamente hasta 200 MiB/s de escritura por stream, ideal para tráfico impredecible. El modo aprovisionado es más económico en un estado estable donde la capacidad es conocida.

Elige KDS sobre SQS FIFO cuando la carga de trabajo exija una ingesta ordenada y reproducible a rendimientos que FIFO no puede soportar (FIFO tiene un límite muy por debajo de los millones de registros/segundo que KDS maneja), cuando múltiples consumidores independientes deben leer el mismo stream, o cuando la frase “preservar el orden original durante todo el procesamiento” se combina con un alto volumen.

Kinesis Data Firehose

Kinesis Data Firehose es un servicio de entrega totalmente gestionado. Lee desde un stream de Kinesis o mediante PUT directo, almacena en búfer por tamaño (1–128 MB) o por tiempo (60–900 segundos, lo que ocurra primero), opcionalmente invoca una Lambda para la transformación por registro (limpieza de PII, normalización de formato), puede convertir JSON a Parquet u ORC sobre la marcha usando un esquema de Glue, cifra con KMS y entrega a S3, Redshift, OpenSearch o Splunk. No tiene shards, no hay consumidores que ejecutar y su precio es de pago por GB.

El patrón canónico para la ingesta escalable en un data lake combina Data Streams (on-demand) como el búfer duradero con Firehose para la entrega a S3:

Producers → Kinesis Data Streams (on-demand) → Firehose (60s buffer, Parquet) → S3 → Athena/Glue

Para ingerir millones de eventos móviles, cifrarlos y depositarlos en S3 como Parquet, la respuesta correcta es Firehose con conversión a Parquet y una clave de KMS, y no KDS más un consumidor personalizado más un escritor de Parquet hecho a mano, lo que supone muchísimo más código e infraestructura. Firehose es casi en tiempo real y no admite la reproducción (replay) del lado del consumidor; cuando se requiere la reproducción, mantén KDS en la ruta.

Kinesis Data Analytics (ahora Managed Service for Apache Flink) ejecuta trabajos SQL o Flink contra un stream para agregaciones en ventana.

Integración de Lambda y Semántica de Reintentos

Lambda se integra con estos servicios con comportamientos de reintento sustancialmente diferentes:

Para SQS, mantén el tiempo de espera de la función Lambda ≤ al tiempo de espera de visibilidad de la cola, y establece el tiempo de espera de visibilidad en al menos 6 veces el tiempo de espera de la función. Para Kinesis, habilita BisectBatchOnFunctionError y configura un destino OnFailure (SQS o SNS) para que un único registro malicioso (poison record) no bloquee todo el shard indefinidamente.

Tabla de Decisión de Selección

← Analítica · Todos los dominios · Seguridad →

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

Explorar Amazon →