Amazon SAA-C03: Integración de Aplicaciones, Mensajería y Streaming — Guía de estudio

By Laurynas Brazys · 15 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, Ordenamiento y Semántica de Entrega

Amazon SQS es una cola de mensajes completamente administrada y basada en el modelo pull, cuyo rol arquitectónico principal es desacoplar a los productores de los consumidores. Una cadena de llamadas síncronas vincula la latencia y la disponibilidad del productor a cada dependencia posterior; insertar una cola SQS convierte eso en una entrega asíncrona. Los productores encolan a la velocidad a la que llega el tráfico, y los consumidores desencolan a la velocidad a la que pueden procesar de forma segura. Esta es la solución canónica para las ráfagas de escritura que de otro modo abrumarían una instancia de RDS: la cola absorbe la ráfaga y una flota limitada de consumidores la drena a una concurrencia controlada, manteniendo el número de conexiones a la base de datos bajo control.

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

Las colas estándar entregan al menos una vez con un ordenamiento de 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 shards. Incluso si nunca ve un duplicado en las pruebas, el servicio está arquitectónicamente permitido para volver a entregar, especialmente durante la conmutación por error del broker. Asumir que las colas estándar “usualmente” entregarán una vez es un defecto de diseño, no un riesgo operativo; los duplicados están garantizados a ocurrir 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 la API posteriores, o depender de la semántica de upsert.

Las colas FIFO proporcionan un ordenamiento estricto dentro de un MessageGroupId y un procesamiento exactamente una vez 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 solo consumidor a la vez, mientras que diferentes ID de grupo se pueden procesar en paralelo. Para un sistema de procesamiento de pedidos donde los eventos de cada cliente deben ser secuenciales pero los diferentes clientes son independientes, use MessageGroupId = customerId. Usar un solo ID de grupo para todo serializa toda la carga de trabajo y destruye el rendimiento. Los ID de deduplicación son la primitiva correcta para evitar la creación de pedidos duplicados cuando un usuario vuelve a enviar un pago atascado: 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 estándar cuando el requisito establece “ordenamiento” o “sin duplicados” es el error clásico. Ninguna cantidad de lógica de aplicación puede restaurar el orden que la cola nunca preservó, porque los mensajes de diferentes hosts de backend llegan intercalados. Elija FIFO siempre que la carga de trabajo exija ordenamiento (libros de contabilidad de transacciones, transiciones de máquinas de estado) o semántica de exactamente una vez (captura de pagos, decremento de inventario).

Tiempo de Espera de Visibilidad, Mensajes Venenosos 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 30 segundos, máximo 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 tomó demasiado tiempo, 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 causa principal de procesamiento duplicado: una Lambda que tarda 45 segundos en una cola con el tiempo de espera predeterminado de 30 segundos reprocesará cada mensaje al menos dos veces. Establezca el tiempo de espera en al menos el tiempo de procesamiento p99 (la guía de AWS para colas impulsadas por Lambda es al menos 6 veces el tiempo de espera de la función), y para trabajos de duración impredecible, extienda 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 (DLQ) capturan mensajes venenosos. Una RedrivePolicy en la cola de origen especifica un maxReceiveCount (típicamente 3-5); una vez excedido, SQS mueve el mensaje a la DLQ para inspección fuera de línea. La DLQ debe coincidir con el tipo de cola de origen (FIFO ↔ FIFO). Sin una DLQ, los mensajes mal formados se repiten indefinidamente, y en FIFO esto es especialmente perjudicial: el ordenamiento evita que los mensajes posteriores en el mismo grupo se entreguen hasta que se resuelva el problema, por lo que un mensaje defectuoso detiene a todo un grupo.

Los mensajes de SQS están limitados a 256 KB. Para cargas útiles más grandes, por ejemplo, un trabajo que lleva un documento renderizado, use la Biblioteca de Cliente Extendida de SQS, que escribe la carga útil en S3 y encola solo una referencia de bucket/clave. La biblioteca del consumidor recupera de forma transparente al recibir. No divida las cargas útiles en varios mensajes (pierde atomicidad y ordenamiento) y no codifique en base64 un blob de 2 MB esperando que quepa.

Autoescalado Impulsado por Colas

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 backlog de la cola. La CPU se retrasa con respecto a la tasa de llegada y malinterpreta a un consumidor saturado como “ocupado pero manejando”. La métrica de escalado canónica es ApproximateNumberOfMessagesVisible, pero escalar directamente en la profundidad de la cola bruta es tosco. El enfoque recomendado es la métrica personalizada de backlog por instancia:

backlogPerInstance = ApproximateNumberOfMessagesVisible / RunningInstances

Publique esto en CloudWatch y use una política de seguimiento de objetivos en un grupo de Auto Scaling o servicio de ECS para que cada trabajador mantenga un backlog limitado (por ejemplo, 10 mensajes). Esto produce un escalado horizontal 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, combínelo con ApproximateAgeOfOldestMessage para evitar terminar la capacidad mientras los mensajes antiguos persisten.

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

SNS es un servicio de publicación/suscripción basado en push. Los publicadores escriben en un tema; SNS envía a cada suscripción: colas SQS, funciones Lambda, puntos finales HTTP(S), correo electrónico, SMS, Kinesis Data Firehose o push móvil. 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 se vacía al recuperarse; SNS por sí solo carece de ese almacenamiento en 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 coincidentes, evitando el antipatrón en el que cada consumidor recibe cada mensaje 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, use un tema SNS FIFO suscrito a colas SQS FIFO; 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) se reintentan según una política de entrega (predeterminado: tres reintentos inmediatos, luego retroceso exponencial hasta una hora, luego descarte). Los suscriptores deben responder 2xx en 15 segundos, validar la firma x-amz-sns-message-type y, para puntos finales no confiables, siempre tener una DLQ de SNS (redireccionada a SQS) para que los mensajes no entregados sean capturados en lugar de ser descartados silenciosamente.

La invocación entre cuentas es una trampa frecuente. Cuando la Cuenta A publica en un tema que se distribuye a una Lambda en la Cuenta B, se requieren dos políticas: la política del tema SNS (o la dirección de la suscripción) debe permitir la suscripción, y la política basada en recursos de Lambda debe permitir lambda:InvokeFunction desde sns.amazonaws.com con una condición SourceArn que coincida con el tema. La falta de la política de recursos de Lambda es el modo de falla más común: la suscripción parece saludable, pero las invocaciones se rechazan con 403. Si el tema está cifrado con una clave KMS administrada por el cliente, la política de clave también debe otorgar kms:Decrypt y kms:GenerateDataKey al principal publicador 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) extiende pub/sub con enrutamiento basado en contenido, descubrimiento de esquemas, fuentes de eventos de socios SaaS y archivo/reproducción. Los eventos fluyen a través de buses de eventos (predeterminados, personalizados o de socios) y coinciden con reglas cuyos patrones de eventos filtran la estructura JSON. Las reglas pueden transformar cargas útiles a través de rutas de entrada y plantillas de entrada, adjuntar destinos de mensajes fallidos y entregar a más de 20 destinos nativos, incluidos Lambda, Step Functions, tareas 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 transmisión de alto rendimiento a suscriptores homogéneos con filtrado de atributos simple y menor latencia. EventBridge está optimizado para arquitecturas impulsadas por eventos heterogéneas: 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 descompone 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 una distribución de muy alto volumen y baja latencia a suscriptores idénticos, SNS sigue siendo superior porque EventBridge tiene una latencia ligeramente mayor por evento y un límite de rendimiento predeterminado más bajo.

Amazon MQ: Mensajería Intermediada para Protocolos Existentes

Amazon MQ es un intermediario administrado que ejecuta ActiveMQ o RabbitMQ. Existe para migrar cargas de trabajo locales que dependen de AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, OpenWire o JMS sin reescribir la aplicación. Si un sistema de pago utiliza un intermediario JMS de terceros con semántica transaccional de “exactamente una vez”, trasladarlo a Amazon MQ conserva el protocolo de conexión y las garantías de entrega, al tiempo que elimina la administración de la infraestructura. Elija SQS/SNS/EventBridge para diseños AWS-nativos nuevos; elija Amazon MQ solo cuando la compatibilidad del protocolo sea la restricción.

Kinesis Data Streams

Kinesis Data Streams (KDS) es un registro duradero, ordenado y particionado para la ingesta de streaming de alto rendimiento: clickstreams, telemetría de IoT, agregación de registros. Los registros se colocan en fragmentos por PartitionKey; el orden está garantizado dentro de un fragmento, no en todo el flujo. Cada fragmento admite 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, ampliables 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 al confirmar.

El modo bajo demanda elimina el cálculo de fragmentos al escalar automáticamente hasta 200 MiB/s de escritura por flujo, ideal para tráfico impredecible. El modo aprovisionado es más económico en estado estable donde se conoce la capacidad.

Elija KDS en lugar de SQS FIFO cuando la carga de trabajo demande una ingesta ordenada y reproducible a través de rendimientos que FIFO no puede manejar (FIFO alcanza un máximo muy por debajo de los millones de registros por segundo que maneja KDS), cuando múltiples consumidores independientes deben leer el mismo flujo, 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 completamente gestionado. Lee desde un stream de Kinesis o PUT directo, almacena en búfer por tamaño (1-128 MB) o tiempo (60-900 segundos, lo que ocurra primero), opcionalmente invoca una función Lambda para la transformación por registro (eliminación 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 tiene consumidores que ejecutar y su precio es por GB.

El patrón canónico para la ingesta escalable en un data lake combina Data Streams (bajo demanda) como 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 almacenarlos en S3 como Parquet, la respuesta correcta es Firehose con conversión a Parquet y una clave KMS, no KDS más un consumidor personalizado más un escritor de Parquet hecho a mano, lo que implica una cantidad de código e infraestructura dramáticamente mayor. Firehose es casi en tiempo real y no admite la repetición del lado del consumidor; cuando se requiere la repetición, mantenga KDS en la ruta.

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

Integración de Lambda y semántica de reintentos

Lambda se integra con estos servicios con un comportamiento de reintentos materialmente diferente:

Para SQS, mantenga el tiempo de espera de la función Lambda ≤ tiempo de espera de visibilidad de la cola, y establezca el tiempo de espera de visibilidad en al menos 6 veces el tiempo de espera de la función. Para Kinesis, habilite BisectBatchOnFunctionError y configure un destino OnFailure (SQS o SNS) para que un solo registro “venenoso” no detenga el shard completo indefinidamente.

Tabla de decisión de selección

← Análisis · Todos los dominios · Seguridad →

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

Explorar Amazon →