← Volver al catálogo

Amazon SQS

Amazon Simple Queue Service (Amazon SQS)

En una frase: Cola de mensajes que desacopla productores y consumidores y guarda lo pendiente
Categoría: Integración de aplicaciones (Application Integration)
Certificaciones: SAA-C03 SAP-C02 CLF-C02 DVA-C02
Documentación oficial: Documentación de Amazon SQS ↗

Qué es

Amazon SQS (Simple Queue Service) es un servicio de colas de mensajes sin servidores que gestionar. Un componente (el productor) envía mensajes a la cola y otro (el consumidor) los recoge cuando puede, los procesa y los borra. Así las dos partes quedan desacopladas: si el consumidor va lento o se cae, los mensajes esperan en la cola en lugar de perderse, y cada parte escala por su cuenta. Es uno de los servicios más antiguos de AWS y la pieza básica de las arquitecturas asíncronas.

Conceptos clave

  • Modelo pull: los consumidores preguntan a la cola (ReceiveMessage); SQS no empuja los mensajes. Cada mensaje lo procesa un solo consumidor (a diferencia de SNS (Simple Notification Service), que reparte a todos).
  • Cola estándar: rendimiento casi ilimitado, entrega al menos una vez (puede llegar algún duplicado) y orden aproximado. La aplicación debe ser idempotente, es decir, procesar dos veces el mismo mensaje sin efectos indeseados.
  • Cola FIFO (First In, First Out, el nombre acaba en .fifo): orden estricto dentro de cada grupo de mensajes (MessageGroupId) y procesamiento exactamente una vez con deduplicación durante 5 minutos. Rendimiento más limitado, ampliable con el modo de alto rendimiento.
  • Tiempo de visibilidad: cuando un consumidor recibe un mensaje, este se oculta al resto durante ese tiempo (30 s por defecto, hasta 12 horas). Si no se borra antes de que venza, vuelve a la cola y otro consumidor lo recibe.
  • Long polling: la llamada espera hasta 20 segundos a que llegue algo, en vez de volver vacía al instante. Reduce respuestas vacías y coste.
  • Cola de mensajes fallidos (DLQ): tras un número máximo de intentos (maxReceiveCount), el mensaje pasa a otra cola para analizarlo sin bloquear al resto. Se puede devolver a la cola original con redrive.
  • Límites: mensajes de hasta 1 MiB; para cargas mayores (hasta 2 GB) se guarda el contenido en S3 (Simple Storage Service) y en la cola solo la referencia, con la biblioteca Extended Client. Retención de 1 minuto a 14 días (4 días por defecto). Retraso de entrega de hasta 15 minutos (delay queues).
  • Integración con Lambda: un event source mapping lee la cola por lotes, invoca la función y borra los mensajes procesados; con respuestas parciales de lote solo se reintentan los mensajes que fallaron.

Casos de uso típicos

  • Absorber picos: el frontal acepta pedidos al instante y los trabajadores los procesan a su ritmo.
  • Repartir trabajo entre una flota de instancias o contenedores que escala según los mensajes pendientes.
  • Procesamiento asíncrono con Lambda (miniaturas, correos, integraciones).
  • Pedidos o transacciones que deben procesarse en orden por cliente (FIFO con MessageGroupId por cliente).
  • Patrón fan-out junto a SNS: un tema reparte cada mensaje a varias colas.

Cuándo NO usarlo

  • Si varios consumidores deben recibir el mismo mensaje: SNS o EventBridge (o SNS delante de varias colas).
  • Si hay que releer los datos o mantener un flujo ordenado para varios lectores: Kinesis Data Streams o MSK (Managed Streaming for Apache Kafka).
  • Si migras una aplicación que usa JMS (Java Message Service: API estándar de mensajería de Java), AMQP (Advanced Message Queuing Protocol: protocolo estándar de mensajería) o MQTT (Message Queuing Telemetry Transport: protocolo ligero de mensajería para dispositivos) sin reescribirla: Amazon MQ.
  • Para orquestar pasos con estado, esperas y ramas: Step Functions.

Comparativa de mensajería

NecesidadServicio adecuado
Cola: un consumidor por mensaje, desacoplarSQS
Publicar y que lo reciban muchos suscriptoresSNS
Enrutar eventos por su contenido entre servicios y SaaS (software como servicio)EventBridge
Streaming con varios lectores y relecturaKinesis Data Streams
Protocolos estándar (JMS, AMQP, MQTT) en una migraciónAmazon MQ
Flujos de varios pasos con estadoStep Functions

Modelo de precios

Se paga por petición a la API (enviar, recibir, borrar…), contando cada bloque de 64 KB de la carga como una petición, con un nivel gratuito mensual. FIFO cuesta algo más que estándar. Se suma la transferencia de datos de salida. Recibir por lotes (hasta 10 mensajes) y usar long polling reduce mucho el número de peticiones.

Seguridad y alta disponibilidad

Trampas de examen

  • "Desacoplar" o "absorber picos" entre componentes: SQS.
  • "Orden estricto" o "sin duplicados": cola FIFO.
  • "Un mensaje se procesa dos veces": el tiempo de visibilidad es menor que lo que tarda el procesamiento; auméntalo (o amplíalo con ChangeMessageVisibility).
  • "Muchas respuestas vacías y coste alto": long polling.
  • "Un mensaje erróneo bloquea o se reintenta sin fin": cola de mensajes fallidos (DLQ).
  • "Mensajes de varios MB": guardar en S3 y enviar la referencia (Extended Client).
  • "Escalar los trabajadores según la cola": Auto Scaling con la métrica de mensajes pendientes por instancia.
  • "Un evento debe llegar a varios sistemas": SNS con varias colas suscritas (fan-out), no una sola cola.

Preguntas de práctica

Preguntas originales escritas para estos apuntes. No son preguntas reales de examen.

Fuentes