Semana 8 · Módulo 8 de 11

Desacoplamiento, serverless y contenedores

Cómo romper un monolito en piezas que escalan y fallan por separado: colas (SQS), publicación/suscripción (SNS), eventos (EventBridge), orquestación (Step Functions), cómputo sin servidores (Lambda, Fargate), APIs (API Gateway) y contenedores (ECS, EKS, ECR). Es el corazón de las tareas 2.1 y 3.2 y aparece en decenas de preguntas con la palabra «decouple».

Reparto de la semana

Por qué importa

La tarea 2.1 (Design scalable and loosely coupled architectures) es la más larga de toda la guía, y el dominio 2 pesa un 26 %. La 3.2 (Design high-performing and elastic compute solutions) pide literalmente Decoupling workloads so that components can scale independently. Traducido: el examen presenta un sistema que se cae en los picos, que pierde pedidos cuando un componente falla o que tarda demasiado, y te pide la pieza que lo arregla.

Palabras clave que verás: decouple, loosely coupled, asynchronous, buffer, spiky traffic, fan-out, exactly-once processing, order must be preserved, event-driven, serverless, LEAST operational overhead, containerize, without managing servers.

Patrones de desacoplamiento

Acoplamiento fuerte: el servicio A llama directamente y de forma síncrona a B. Si B va lento, A va lento; si B se cae, A falla; si A recibe un pico, B recibe el mismo pico. Acoplamiento débil: entre A y B hay un intermediario que absorbe picos, guarda los mensajes mientras B no está y permite que cada lado escale por separado.

Los cuatro patrones básicos

1. Cola punto a punto (SQS). El productor deja mensajes; uno o varios consumidores los sacan y procesan. Cada mensaje lo procesa un consumidor. La cola hace de amortiguador (buffer).

flowchart LR
    W["Web (productor)"] --> Q["Cola SQS"]
    Q --> C1["Consumidor 1"]
    Q --> C2["Consumidor 2"]
    Q --> C3["Consumidor N (ASG o Lambda)"]

2. Publicación/suscripción y fan-out (SNS + SQS). Un mensaje publicado en un tema (topic) llega a todos los suscriptores. Si cada suscriptor es una cola SQS, cada sistema procesa el mensaje a su ritmo y con reintentos propios.

flowchart LR
    P["Servicio de pedidos"] --> T["Tema SNS: pedido-creado"]
    T --> Q1["SQS: facturación"]
    T --> Q2["SQS: almacén"]
    T --> Q3["SQS: analítica"]
    Q1 --> F["Lambda facturación"]
    Q2 --> A["Servicio almacén (ECS)"]
    Q3 --> K["Proceso batch"]

3. Bus de eventos (EventBridge). Los productores emiten eventos («pedido creado») sin saber quién los consume. Reglas con patrones deciden a qué destinos va cada evento. Es enrutado muchos a muchos basado en el contenido.

4. Orquestación de flujos (Step Functions). Un coordinador central define los pasos, el orden, las decisiones, los reintentos y la compensación de errores.

Orquestación frente a coreografía

flowchart TB
    subgraph Orquestacion["Orquestación (Step Functions)"]
        SF["Máquina de estados"] --> V["Validar pago"]
        SF --> R["Reservar stock"]
        SF --> E["Enviar pedido"]
    end
    subgraph Coreografia["Coreografía (EventBridge)"]
        O["Pedidos"] -- "PedidoCreado" --> BUS["Bus de eventos"]
        BUS --> PG["Pagos"]
        PG -- "PagoAceptado" --> BUS
        BUS --> ST["Stock"]
    end

Microservicios: con estado y sin estado

La guía pide Design principles for microservices (for example, stateless workloads compared with stateful workloads).

• Un servicio sin estado (stateless) no guarda nada de la sesión en su memoria o disco local entre peticiones: cualquier instancia puede atender cualquier petición. Por eso escala horizontalmente sin problemas y se puede reemplazar en cualquier momento (Auto Scaling, Spot, Lambda, Fargate).
• El estado se saca a servicios gestionados: sesiones en ElastiCache o DynamoDB, ficheros en S3 o EFS, datos en RDS/Aurora/DynamoDB.
• Evita las sesiones pegajosas (sticky sessions) del balanceador como solución de escalado: atan al usuario a una instancia y rompen el reparto de carga.
• Cada microservicio tiene su propio almacén de datos y se comunica por API o por eventos; se despliega y escala por separado.

Escalado horizontal frente a vertical: horizontal (scale out) = más instancias iguales detrás de un balanceador o consumiendo de una cola; vertical (scale up) = una instancia más grande. El horizontal es el preferido en la nube porque no tiene techo práctico y mejora la disponibilidad; el vertical tiene límite y suele implicar parada.

Amazon SQS a fondo

Amazon Simple Queue Service (SQS) es un servicio de colas totalmente gestionado, sin servidores que administrar, con almacenamiento redundante en varias AZ. Los consumidores sondean la cola (pull): SQS no empuja mensajes.

Standard frente a FIFO

Deduplicación en FIFO: por ID de deduplicación explícito o por deduplicación basada en contenido (hash SHA-256 del cuerpo). Los mensajes con distinto MessageGroupId se procesan en paralelo; dentro de un grupo, en orden. Para escalar una FIFO, reparte los mensajes entre muchos grupos (p. ej., un grupo por cliente).

Novedad: las colas standard admiten ahora fair queues (colas «justas») usando MessageGroupId para que un inquilino ruidoso no retrase a los demás. No es materia de examen, pero lo verás en la consola.

Parámetros que tienes que dominar

El ciclo de vida de un mensaje

1. El productor envía (SendMessage).
2. Un consumidor recibe (ReceiveMessage); el mensaje se vuelve invisible durante el visibility timeout.
3. Si lo procesa bien, lo borra (DeleteMessage) con su receipt handle.
4. Si falla o tarda más que el visibility timeout, el mensaje vuelve a ser visible y otro consumidor lo recibe. Si el proceso necesita más tiempo, el consumidor puede ampliarlo con ChangeMessageVisibility.

Regla práctica: el visibility timeout debe ser mayor que el tiempo máximo de procesamiento. Con Lambda como consumidor, AWS recomienda como mínimo 6 veces el timeout de la función. Un visibility timeout demasiado corto provoca procesamiento duplicado.

Short polling frente a long polling

• Short polling (por defecto, WaitTimeSeconds = 0): responde al instante consultando un subconjunto de servidores; puede devolver vacío aunque haya mensajes. Muchas llamadas vacías = más coste.
• Long polling (WaitTimeSeconds de 1 a 20): espera hasta que llega un mensaje o se agota el tiempo, y consulta todos los servidores. Es casi siempre la respuesta correcta para reducir coste y llamadas vacías. Se activa en la cola (ReceiveMessageWaitTimeSeconds) o en cada petición.

Dead-letter queues (DLQ)

Una DLQ es otra cola a la que SQS mueve los mensajes que han fallado demasiadas veces. Se configura en la cola origen con una redrive policy: deadLetterTargetArn y maxReceiveCount (cuántas recepciones sin borrar antes de mover el mensaje). Sirve para aislar mensajes venenosos (poison messages) que bloquearían o harían reintentar sin fin, analizarlos y devolverlos a la cola origen (DLQ redrive) cuando corrijas el error.

• La DLQ de una cola FIFO debe ser FIFO; la de una standard, standard.
• Pon a la DLQ una retención mayor que la de la cola origen: en colas standard, la caducidad del mensaje sigue contando desde que entró en la cola original.
• Crea una alarma de CloudWatch sobre ApproximateNumberOfMessagesVisible de la DLQ.

Seguridad de SQS

• Cifrado en reposo con SSE-SQS o SSE-KMS; en tránsito, HTTPS.
• Política de acceso de la cola (política de recurso): imprescindible para que SNS, EventBridge o S3 puedan escribir en ella, o para acceso entre cuentas.
• VPC endpoint de interfaz para que consumidores en subredes privadas usen SQS sin NAT.

Escalar los consumidores

• Con EC2 Auto Scaling: escala el grupo según la cola acumulada por instancia (backlog per instance). La métrica ApproximateNumberOfMessagesVisible dividida entre el número de instancias en servicio, con una política de target tracking sobre esa métrica personalizada. Ejemplo: si cada instancia procesa 10 mensajes/s y quieres que ningún mensaje espere más de 20 s, el objetivo es 200 mensajes por instancia.
• Con Lambda (event source mapping): Lambda sondea la cola por ti, lee lotes (por defecto 10 mensajes; más en standard con ventana de lote de hasta 5 minutos) e invoca la función de forma síncrona. Escala automáticamente el número de sondeadores; puedes limitarla con maximum concurrency del mapeo o con concurrencia reservada. Usa informes de fallos parciales (ReportBatchItemFailures) para no reprocesar los mensajes buenos de un lote. Existe un modo aprovisionado (provisioned mode) de sondeadores dedicados para cargas muy exigentes.
• Con ECS: service auto scaling con una métrica de la cola.

Amazon SNS: publicación/suscripción

Amazon Simple Notification Service (SNS) es pub/sub gestionado y push: SNS entrega el mensaje a cada suscriptor.

• Suscriptores de temas standard: SQS, Lambda, HTTP/HTTPS, email, SMS, notificaciones push móviles y Amazon Data Firehose.
• Tamaño máximo del mensaje: 256 KiB por defecto. Desde el 18/09/2026, un tema (estándar o FIFO) puede aceptar hasta 1 MiB si se configura su atributo MaximumMessageSize; esos mensajes grandes solo se entregan a suscripciones de SQS, Lambda y Firehose. Para cargas mayores, las Extended Client Libraries guardan el cuerpo en S3 (hasta 2 GB). Como es una novedad muy reciente, el material de examen puede seguir diciendo «256 KiB».
• Filtrado de mensajes (subscription filter policy): cada suscripción recibe solo los mensajes que cumplen su filtro, evaluado sobre los atributos del mensaje o sobre el cuerpo (JSON). Así evitas crear un tema por tipo de mensaje o filtrar en cada consumidor.
• Raw message delivery: entrega a SQS/HTTP el cuerpo tal cual, sin el sobre JSON de SNS.
• Reintentos y DLQ por suscripción: si un destino falla tras la política de reintentos, el mensaje puede ir a una DLQ (cola SQS) asociada a esa suscripción.
• Cifrado con KMS y política de acceso del tema.

Temas FIFO

SNS FIFO garantiza orden (por grupo de mensajes) y deduplicación, igual que SQS FIFO. Solo entrega a colas SQS (FIFO o standard): no a email, SMS, HTTP ni directamente a Lambda (para Lambda, pon una cola SQS en medio). Admite archivo y reproducción de mensajes (archiving and replay). Rendimiento: hasta 300 mensajes/s por grupo y, por defecto, 3.000 mensajes/s por tema.

Fan-out: por qué SNS + SQS y no SNS directo a los consumidores

• Cada cola conserva los mensajes si su consumidor está caído: SNS solo reintenta durante un tiempo limitado.
• Cada consumidor procesa a su ritmo y con su propia DLQ.
• Añadir un sistema nuevo = suscribir una cola más; el productor no cambia.
• Caso clásico: un evento de S3 (objeto subido) solo admite una configuración de destino por prefijo y tipo de evento; publicándolo en SNS y haciendo fan-out a varias colas, varios procesos reaccionan al mismo fichero.

Amazon EventBridge

Amazon EventBridge es un servicio serverless de bus de eventos: recibe eventos (JSON) y los enruta a destinos según reglas. Evolucionó de CloudWatch Events.

Buses y reglas

• Default event bus: recibe automáticamente eventos de servicios de AWS (una instancia EC2 cambia de estado, un hallazgo de GuardDuty, una llamada a la API registrada en CloudTrail…).
• Custom event buses: para los eventos de tus aplicaciones (PutEvents).
• Partner event buses: eventos de SaaS integrados (Salesforce vía AppFlow, Zendesk, Datadog…).
• Reglas: un patrón de evento (filtra por source, detail-type o cualquier campo del detail) o una programación; cada regla puede tener hasta 5 destinos (Lambda, SQS, SNS, Step Functions, Kinesis, ECS, API destinations, otro bus, otra cuenta…).
• Transformación de entrada: adaptar el evento al formato que espera el destino.
• Archive and replay: guardar eventos y reproducirlos (tras un fallo o para probar).
• Schema registry: descubre y documenta el esquema de los eventos; genera código.
• API destinations: invocar APIs HTTP externas con autenticación y límite de tasa.
• Buses entre cuentas y regiones y global endpoints para conmutación por error regional.
• Tamaño máximo del evento: 1 MB (antes 256 KB; AWS lo amplió a la vez que en SQS y en las invocaciones asíncronas de Lambda). Material antiguo dirá 256 KB.
• Reintentos hacia destinos por defecto durante hasta 24 horas y 185 intentos, con DLQ opcional (cola SQS) para lo que no se entregue.

Ejemplo de patrón de evento: pedidos de más de 100 € creados por la tienda.

{
  "source": ["tienda.pedidos"],
  "detail-type": ["PedidoCreado"],
  "detail": {
    "importe": [{ "numeric": [">", 100] }]
  }
}

EventBridge Scheduler

Amazon EventBridge Scheduler es un programador serverless para millones de tareas: programaciones puntuales (at(...)), recurrentes con rate(...) o cron(...), con zona horaria, ventanas flexibles para repartir la carga y reintentos. Invoca más de 270 servicios y más de 6.000 operaciones de API. Sustituye con ventaja a las reglas programadas de EventBridge y al «cron en una EC2».

Casos: «enviar un recordatorio 24 h después de cada reserva» (una programación puntual por reserva), «parar las instancias de desarrollo a las 20:00 hora de Madrid», «lanzar un informe cada lunes».

EventBridge Pipes

EventBridge Pipes conecta un origen con un destino (punto a punto) con filtrado, enriquecimiento opcional y transformación, sin escribir código de integración:

origen → filtro → enriquecimiento → destino

• Orígenes: SQS, Kinesis Data Streams, DynamoDB Streams, Amazon MSK y Kafka propio, Amazon MQ.
• Enriquecimiento: Lambda, Step Functions Express, API Gateway, API destinations.
• Destinos: más de una decena de servicios (Step Functions, EventBridge, SQS, Lambda…).
• Solo pagas los eventos que pasan el filtro.

Ejemplo: cambios en una tabla DynamoDB (Streams) → filtrar solo INSERT → enriquecer con datos del cliente vía API → iniciar una máquina de Step Functions.

SNS frente a EventBridge

AWS Step Functions

AWS Step Functions orquesta flujos de trabajo como máquinas de estados definidas en JSON (Amazon States Language) y visualizadas como un diagrama. Estados principales: Task (hacer algo: invocar Lambda, llamar a una API de AWS), Choice (bifurcar), Parallel, Map (iterar sobre una lista; el Distributed Map procesa millones de elementos, p. ej. objetos de S3), Wait, Pass, Succeed y Fail. Cada estado puede declarar Retry (con backoff) y Catch (gestión de errores y compensación).

• Integra directamente con más de 200 servicios de AWS (llamar a DynamoDB, SQS, ECS, Glue, SageMaker AI… sin una Lambda intermedia).
• Patrones de integración: Request Response (llamar y seguir), Run a Job (.sync: esperar a que termine, p. ej. una tarea ECS) y Wait for Callback (.waitForTaskToken: pausar hasta que un humano o un sistema externo devuelva el token; ideal para aprobaciones manuales).

Standard frente a Express

El tipo no se puede cambiar después de crear la máquina de estados.

Amazon MQ y Amazon AppFlow

Amazon MQ es un message broker gestionado para Apache ActiveMQ y RabbitMQ. Existe para una razón: compatibilidad con protocolos estándar (JMS, NMS, AMQP 0-9-1 y 1.0, MQTT, STOMP, OpenWire, WebSocket) cuando migras aplicaciones que ya usan un broker y no puedes reescribirlas para las API de SQS/SNS. Se despliega dentro de tu VPC como instancia única, par activo/en espera Multi-AZ (ActiveMQ) o clúster de tres nodos (RabbitMQ). Escala menos y requiere más gestión que SQS/SNS (eliges tamaño de broker, ventanas de mantenimiento).

Amazon AppFlow es un servicio de integración de datos entre aplicaciones SaaS y AWS sin código: flujos de Salesforce, SAP, Zendesk, Slack, ServiceNow, Marketo, Google Analytics… hacia S3, Redshift (o de vuelta a SaaS), a demanda, programados o disparados por eventos. Permite mapear, filtrar, validar y enmascarar campos, cifra en reposo y en tránsito y puede transferir por AWS PrivateLink sin pasar por Internet. Pista del enunciado: «sincronizar datos de Salesforce con S3 cada hora sin escribir código».

AWS Lambda a fondo

AWS Lambda ejecuta tu código en respuesta a eventos sin gestionar servidores. Pagas por número de invocaciones y por duración × memoria (GB-segundo), redondeando al milisegundo. Escala de cero a miles de ejecuciones en paralelo.

Límites verificados (30/09/2026)

Fuente: Lambda quotas. Si el trabajo dura más de 15 minutos, no es para Lambda: usa Fargate/ECS, AWS Batch, Step Functions para trocearlo o EC2.

Cómo se invoca una función

Destinos y DLQ

Para invocaciones asíncronas puedes configurar destinos (destinations) separados para éxito y fallo: SQS, SNS, Lambda, EventBridge y S3 (este último solo para fallos). El registro incluye la petición, la respuesta y el motivo del fallo. La alternativa antigua es la DLQ de la función (SQS o SNS standard), que solo guarda el evento. Recomendación actual: destinos, porque dan más contexto y más tipos de destino. (Para colas SQS como origen, la DLQ se configura en la cola, no en la función.)

Concurrencia: reservada y aprovisionada

Concurrencia = número de peticiones que la función atiende a la vez ≈ peticiones por segundo × duración media en segundos.

Siempre quedan al menos 100 unidades sin reservar en la cuenta para el resto de funciones. Si la función supera su concurrencia disponible, las invocaciones síncronas reciben throttling (error 429) y las asíncronas se reintentan.

Cold starts y SnapStart

Un cold start ocurre cuando Lambda tiene que crear un entorno nuevo: descargar el código, arrancar el runtime y ejecutar la inicialización (fuera del handler). Cómo reducirlo:

• Paquetes pequeños, menos dependencias, inicializar clientes fuera del handler para reutilizarlos en invocaciones calientes.
• Más memoria (más CPU) acelera la inicialización.
• Provisioned concurrency para latencias estrictas (decenas de milisegundos).
• Lambda SnapStart: al publicar una versión, Lambda inicializa la función, toma una instantánea (Firecracker microVM) de memoria y disco y reanuda los entornos nuevos desde ella. Admite Java 11+, Python 3.12+ y .NET 8+ (no Node.js). Solo funciona en versiones publicadas (no en $LATEST) y no es compatible con provisioned concurrency, EFS ni /tmp de más de 512 MB. En Java no tiene coste adicional; en Python y .NET se paga caché y restauración. Cuidado con la unicidad: lo que generes en la inicialización (IDs, semillas aleatorias) se clona en todos los entornos.

Lambda en una VPC

Por defecto, una función se ejecuta en una VPC gestionada por AWS con acceso a Internet y a las API públicas de AWS, pero sin acceso a tus recursos privados. Si necesita llegar a una base de datos RDS en una subred privada, la conectas a tu VPC (subredes y security groups): Lambda crea interfaces de red compartidas (Hyperplane ENI) en tus subredes.

Consecuencias que pregunta el examen:

• Una función conectada a la VPC pierde el acceso a Internet salvo que salga por un NAT gateway (asignarle IP pública no sirve).
• Para llamar a servicios de AWS desde subredes privadas sin NAT, usa VPC endpoints (gateway para S3 y DynamoDB; de interfaz para SQS, Secrets Manager, KMS…).
• Con muchas invocaciones concurrentes contra RDS, usa RDS Proxy para agrupar conexiones y no agotar la base de datos.

flowchart LR
    subgraph VPC["Tu VPC"]
        subgraph Priv["Subredes privadas"]
            L["Lambda (ENI)"] --> P["RDS Proxy"] --> DB[("RDS")]
        end
        subgraph Pub["Subred pública"]
            NAT["NAT gateway"]
        end
        L --> NAT
        L --> EP["VPC endpoint (Secrets Manager)"]
    end
    NAT --> INET["Internet / APIs externas"]

Capas, versiones, alias y otras piezas

• Capas (layers): paquetes .zip con bibliotecas, runtimes personalizados o datos compartidos entre funciones (hasta 5 por función). Reducen el tamaño de cada despliegue.
• Versiones (inmutables) y alias (punteros, p. ej. prod): un alias puede repartir tráfico entre dos versiones con pesos para despliegues canary.
• Function URLs: endpoint HTTPS dedicado para una función, sin API Gateway (sin throttling por cliente, caché ni autorizadores ricos).
• Imágenes de contenedor de hasta 10 GB almacenadas en ECR.
• Arquitectura arm64 (Graviton): mejor relación precio/rendimiento para la mayoría de cargas.
• Dimensionar memoria (Selecting the appropriate resource type and size (for example, the amount of Lambda memory)): más memoria = más CPU y red; a menudo más memoria cuesta menos porque la función termina antes. Mide con CloudWatch (Duration, Max Memory Used), usa AWS Compute Optimizer (recomienda memoria para Lambda) o la herramienta de código abierto Lambda Power Tuning.

Amazon API Gateway

Amazon API Gateway crea, publica, protege y monitoriza APIs a cualquier escala. Es la «puerta principal» de un backend serverless: recibe la petición HTTP, la autentica, la limita y la pasa a Lambda, a un servicio HTTP, a un balanceador privado o directamente a un servicio de AWS (por ejemplo, escribir en SQS o en DynamoDB sin Lambda).

REST API, HTTP API y WebSocket API

Regla del examen: HTTP API si solo necesitas un proxy barato hacia Lambda o HTTP con JWT; REST API si aparece cualquiera de: API keys / usage plans / cuotas por cliente, caché, WAF, endpoint privado, validación de peticiones, transformación del cuerpo, X-Ray, canary. WebSocket si el servidor debe empujar mensajes al cliente.

Tipos de endpoint (REST)

• Edge-optimized: las peticiones entran por la red de CloudFront más cercana. Para clientes repartidos por el mundo.
• Regional: para clientes en la misma región o si pones tu propia distribución de CloudFront delante.
• Private: solo accesible desde tu VPC a través de un VPC endpoint de interfaz (execute-api), con política de recurso. Para APIs internas.

Throttling

• Cuota por cuenta y región: 10.000 peticiones/s con ráfaga (burst) de 5.000 (algoritmo token bucket), compartida por todas las APIs. En algunas regiones más nuevas, incluida eu-south-2 (España), el valor por defecto es 2.500 peticiones/s con ráfaga de 1.250. Ampliable.
• Límites por etapa (stage) y por método.
• Usage plans (REST): límites de tasa y cuotas diarias/mensuales por cliente identificado con API key. Las API keys no son un mecanismo de autenticación: identifican al cliente para medir y limitar.
• Al superarse, el cliente recibe 429 Too Many Requests; el cliente debe reintentar con backoff.
• Estrategia completa de throttling: API Gateway limita la entrada, la concurrencia reservada de Lambda protege la base de datos, y una cola SQS absorbe lo que no requiera respuesta inmediata.

Caché (REST)

Cachea respuestas por etapa para reducir llamadas al backend y latencia. TTL por defecto de 300 s, configurable de 0 a 3.600 s; tamaño de la caché configurable (se paga por hora según el tamaño); se puede cifrar e invalidar (el cliente puede pedirlo con Cache-Control: max-age=0 si tiene permiso). Es una de las respuestas a caching strategies de la tarea 2.1.

Autorizadores

Errores que conviene reconocer: 401/403 (autorización), 429 (throttling), 502 (respuesta mal formada del backend), 504 (timeout de integración: el backend tardó más de 29 s).

Contenedores en AWS

La guía pide The orchestration of containers (for example, Amazon ECS, Amazon EKS), How to migrate applications into containers y Determining when to use containers.

Cuándo usar contenedores (y cuándo no)

• Sí: microservicios con varios lenguajes, procesos de larga duración o que superan los 15 minutos de Lambda, necesidades de runtime o dependencias muy concretas, portabilidad entre on-premises y nube, modernizar una aplicación existente con pocos cambios (replatform), cargas estables donde el coste por hora sale mejor que Lambda.
• Lambda es mejor cuando: cargas muy esporádicas o impredecibles, orientadas a eventos, de corta duración, con mínima operación.
• Migrar a contenedores: empaquetar la aplicación y sus dependencias en una imagen (Dockerfile), subirla a ECR, externalizar la configuración (variables de entorno, Parameter Store, Secrets Manager) y el estado (EFS, S3, bases de datos), y desplegarla en ECS o EKS detrás de un ALB. Aplicaciones sin estado y con configuración externa se contenerizan con facilidad; las que escriben en disco local o dependen de un nombre de host fijo requieren cambios.

Amazon ECS

Amazon Elastic Container Service (ECS) es el orquestador de contenedores propio de AWS, más sencillo que Kubernetes y sin coste por el plano de control.

• Task definition: plantilla JSON con la imagen, CPU, memoria, puertos, variables, secretos, logs, roles.
• Task: instancia en ejecución de una task definition.
• Service: mantiene N tareas en marcha, las reemplaza si fallan, las registra en un ALB/NLB y aplica service auto scaling (target tracking por CPU, memoria, peticiones por destino o métricas de SQS).
• Cluster: agrupación lógica donde corren tareas y servicios.
• Dos roles IAM distintos (trampa frecuente): el task execution role lo usa el agente de ECS para descargar la imagen de ECR, enviar logs a CloudWatch y leer secretos al arrancar; el task role lo usa tu aplicación dentro del contenedor para llamar a S3, DynamoDB, etc.
• Capacity providers: estrategias de capacidad, p. ej. mezclar Fargate y Fargate Spot, o Auto Scaling groups de EC2.

Tipo de lanzamiento: EC2 frente a Fargate

Fargate incluye 20 GB de almacenamiento efímero sin coste (ampliable pagando) y admite volúmenes EFS y EBS para persistencia. También puede ejecutar tareas de EKS.

Amazon EKS

Amazon Elastic Kubernetes Service (EKS) ejecuta Kubernetes con el plano de control gestionado por AWS en varias AZ. Se paga el plano de control: 0,10 USD por clúster y hora en soporte estándar (14 meses por versión de Kubernetes) y 0,60 USD/h en soporte extendido; más los nodos. Opciones de cómputo: managed node groups (EC2 que AWS ayuda a gestionar), nodos autogestionados, Fargate y EKS Auto Mode (AWS gestiona también los nodos, con un recargo sobre EC2).

Elige EKS cuando el enunciado mencione Kubernetes, manifiestos o Helm existentes, portabilidad multicloud o un equipo que ya opera Kubernetes. Si no aparece Kubernetes y se pide simplicidad, ECS suele ser la respuesta.

Amazon ECR

Amazon Elastic Container Registry (ECR): registro de imágenes OCI/Docker privado (y ECR Public) integrado con IAM. Funciones: escaneo de imágenes (básico, o mejorado con Amazon Inspector), políticas de ciclo de vida para borrar imágenes antiguas y ahorrar almacenamiento, replicación entre regiones y cuentas, etiquetas inmutables y cifrado con KMS. Para que tareas en subredes privadas descarguen imágenes sin NAT: VPC endpoints de interfaz de ECR (ecr.api, ecr.dkr) y el endpoint gateway de S3 (las capas se sirven desde S3).

Contenedores fuera de AWS: Anywhere y Distro

Tabla de elección de cómputo para aplicaciones desacopladas

Entregar componentes sin cortes: estrategias de despliegue

La lista Technologies and Concepts de la guía incluye Microservices and component delivery. Con microservicios despliegas muchas veces y por separado, así que el examen espera que sepas sacar una versión nueva de un componente sin cortar el servicio y pudiendo volver atrás. Las estrategias son las mismas en todas las plataformas:

Dónde se configura cada una en los servicios del temario:

• Amazon ECS: el despliegue por defecto es rolling, controlado por minimumHealthyPercent (cuántas tareas deben seguir sanas) y maximumPercent (cuántas puede haber a la vez). El deployment circuit breaker detecta que las tareas nuevas no arrancan y hace rollback automático a la revisión anterior; también puedes asociar alarmas de CloudWatch para revertir por métricas de la aplicación. ECS admite además de forma nativa blue/green, canary y linear con un ALB (dos target groups y reglas ponderadas del listener), un bake time en el que conviven ambas versiones antes de apagar la antigua y lifecycle hooks con Lambda para validar.
• AWS Lambda: versiones inmutables y alias con weighted routing (p. ej. 90 % a la versión 7 y 10 % a la 8) para canary; el rollback es mover el alias.
• Amazon API Gateway (REST): canary release en una etapa, que envía un porcentaje del tráfico a la nueva implementación antes de promoverla.
• EC2 y Elastic Beanstalk (módulo 02): instance refresh del Auto Scaling group, políticas rolling, immutable, traffic splitting (canary) y blue/green con intercambio de CNAME.
• DNS y borde (módulo 06): pesos de Route 53 weighted o traffic dials de Global Accelerator para mover tráfico entre dos entornos completos, incluso entre regiones.
• Infraestructura como código (módulo 10): CloudFormation con change sets y rollback automático, para que cada componente se despliegue igual en todos los entornos.

Otros servicios del bloque: Amplify, Device Farm, Serverless Application Repository y X-Ray

AWS Amplify: conjunto de herramientas para desarrolladores front-end y móviles. Amplify Hosting despliega aplicaciones web (SSR como Next.js o Nuxt, SPA como React, Angular o Vue, y sitios estáticos) con un flujo basado en Git: cada push construye y despliega; ramas por entorno, previsualizaciones de pull requests, dominios propios y distribución por la CDN de AWS. Amplify Gen 2 define el backend en TypeScript (autenticación con Cognito, datos, almacenamiento en S3, funciones). Pista: «equipo de front-end que quiere CI/CD y hosting full-stack con el mínimo esfuerzo».

AWS Device Farm: pruebas de aplicaciones Android, iOS y web en dispositivos físicos reales alojados por AWS, de forma automatizada (Appium y otros frameworks, en paralelo en muchos dispositivos) o interactiva desde el navegador. Solo está disponible en us-west-2 (Oregón). Pista: «probar la app en cientos de modelos de móvil reales sin comprar dispositivos».

AWS Serverless Application Repository (SAR): catálogo para publicar y desplegar aplicaciones serverless empaquetadas con plantillas AWS SAM, de forma pública o privada (equipo u organización). Integrado con la consola de Lambda. Pista: «reutilizar componentes serverless entre equipos» o «desplegar una aplicación serverless ya hecha con unos clics».

AWS X-Ray: trazado distribuido. Sigue cada petición a través de API Gateway, Lambda, contenedores y las llamadas a DynamoDB, SQS o APIs externas; muestra un mapa de trazas (trace map) con latencias y errores por componente y permite encontrar cuellos de botella. Se activa en Lambda (active tracing), API Gateway REST, Elastic Beanstalk, y en ECS/EKS con el daemon o el colector de OpenTelemetry. Es la respuesta a Workload visibility (for example, AWS X-Ray) de la tarea 2.2.

Piezas de la tarea 2.1 y la 3.2 que se estudian en otros módulos

La tarea 2.1 incluye conocimientos que se tratan a fondo en otros módulos. Aquí tienes la versión corta, conectada con el desacoplamiento:

• Estrategias de caché (Caching strategies): en el borde con CloudFront (módulo 6); de respuestas de API con la caché de API Gateway; de datos con ElastiCache (lazy loading, write-through, TTL) o DAX para DynamoDB (módulo 4). La caché reduce la carga de los componentes de detrás y permite escalar sin tocarlos.
• Aceleradores en el borde / CDN: CloudFront para contenido estático y dinámico; Global Accelerator para TCP/UDP con IP estáticas (módulo 6).
• Balanceo de carga (ALB): reparte peticiones entre instancias o tareas sin estado; es el desacoplamiento síncrono clásico de una arquitectura multicapa (módulo 2).
• Arquitecturas multicapa (multi-tier): presentación (CloudFront + ALB), lógica (EC2/ECS/Lambda en subredes privadas) y datos (RDS/DynamoDB), cada capa escalando por separado, con colas entre capas para trabajo asíncrono.
• Réplicas de lectura (read replicas): escalar lecturas de RDS/Aurora (módulo 4).
• Tipos de almacenamiento (objeto, fichero, bloque): S3, EFS/FSx y EBS (módulo 3). Para servicios sin estado: estado compartido en S3 o EFS, nunca en el disco local.
• Servicios gestionados con casos de uso: SQS (este módulo), AWS Transfer Family (SFTP/FTPS gestionado hacia S3 o EFS, módulo 3), Secrets Manager (módulo 7).
• De la tarea 3.2: AWS Batch, Amazon EMR y el cómputo distribuido en el borde (Lambda@Edge, Outposts, Wavelength, Local Zones) están en los módulos 1, 2, 6 y 9; EC2 Auto Scaling, AWS Auto Scaling, métricas de escalado y elección de tipos de instancia, en el módulo 2.
• Métricas y condiciones de escalado (3.2): CPU media del ASG, peticiones por destino del ALB, backlog por instancia de una cola SQS (este módulo), concurrencia de Lambda, CPU/memoria de servicios ECS.

Trampas típicas del examen

• SQS standard puede duplicar y desordenar. Si el enunciado exige orden y sin duplicados → FIFO (y comprueba que el rendimiento pedido cabe en FIFO).
• FIFO no escala como standard. «Decenas de miles de mensajes por segundo sin requisitos de orden» → standard.
• Mensajes procesados dos veces → visibility timeout más corto que el procesamiento. Solución: aumentar el visibility timeout (o ChangeMessageVisibility), no crear otra cola.
• Muchas llamadas vacías y coste alto → long polling.
• Mensaje que siempre falla y bloquea → DLQ con maxReceiveCount.
• Mensajes de más de 1 MiB en SQS (o de más de 256 KiB en un tema de SNS no configurado para mensajes grandes; como máximo 1 MiB) → guardar el cuerpo en S3 y enviar el puntero (Extended Client Library).
• SNS no guarda mensajes para consumidores caídos. Para garantizar el procesamiento por varios sistemas → SNS + SQS.
• SNS FIFO no entrega a Lambda, email ni HTTP: solo a colas SQS.
• Lambda tiene 15 minutos como máximo. Procesos más largos → Fargate, Batch, Step Functions o EC2.
• Provisioned concurrency ≠ reserved concurrency: la primera quita cold starts (y cuesta); la segunda garantiza y limita (gratis).
• Lambda en una VPC no tiene Internet sin NAT gateway; para servicios de AWS, mejor VPC endpoints.
• Demasiadas conexiones de Lambda a RDS → RDS Proxy.
• API Gateway: 504 tras 29 s → el backend es demasiado lento para una API síncrona: devuelve 202 y procesa de forma asíncrona (SQS/Step Functions).
• Caché, API keys, usage plans, WAF o endpoint privado → REST API, no HTTP API.
• API keys no autentican: para autenticar, IAM, Cognito, JWT o Lambda authorizer.
• Task role ≠ task execution role en ECS.
• Fargate no admite GPU ni modo privilegiado; si el enunciado lo exige, ECS sobre EC2.
• Kubernetes en el enunciado → EKS; si no, ECS suele ser más simple.
• Amazon MQ solo si hay protocolos estándar o un broker existente; para aplicaciones nuevas, SQS/SNS.
• Encadenar Lambdas llamándose entre sí → mejor Step Functions.
• Tareas programadas «en una EC2 con cron» → EventBridge Scheduler + Lambda o ECS.
• Blue/green ≠ canary: blue/green cambia todo el tráfico de golpe a un entorno ya probado; canary manda primero una parte pequeña. Si el enunciado pide «un 10 % de los usuarios primero», no es blue/green puro.
• Device Farm solo en us-west-2.

Palabras clave → respuesta:

Resumen

• Desacoplar = poner un intermediario que absorba picos, guarde mensajes y deje escalar cada parte por separado: SQS (colas), SNS (pub/sub), EventBridge (eventos), Step Functions (orquestación).
• SQS standard: rendimiento casi ilimitado, al menos una vez, orden no garantizado. FIFO: orden por grupo y exactly-once, con límites de rendimiento. Mensajes hasta 1 MiB, retención de 1 minuto a 14 días, visibility timeout hasta 12 h, long polling hasta 20 s, DLQ con maxReceiveCount.
• SNS + SQS es el patrón de fan-out; los filtros de suscripción evitan temas duplicados. SNS FIFO solo entrega a SQS.
• EventBridge: buses y reglas por contenido (hasta 5 destinos), archive/replay, Scheduler para programar y Pipes para integraciones punto a punto.
• Step Functions Standard (hasta 1 año, exactly-once) frente a Express (5 minutos, alto volumen).
• Lambda: 15 minutos, hasta 10 GB de memoria, 1.000 de concurrencia por defecto; reservada limita y garantiza, aprovisionada elimina cold starts; SnapStart para Java, Python y .NET; en VPC necesita NAT o endpoints; destinos para resultados asíncronos.
• API Gateway: REST (completa: caché, API keys, WAF, privada), HTTP (barata y simple, JWT) y WebSocket (bidireccional); throttling con 429 y timeout de integración de 29 s.
• Contenedores: ECS (sencillo, propio de AWS) sobre EC2 (control) o Fargate (sin servidores); EKS para Kubernetes; ECR como registro; ECS/EKS Anywhere y EKS Distro para on-premises.
• Amplify (hosting front-end con CI/CD), Device Farm (dispositivos reales), SAR (catálogo de aplicaciones SAM) y X-Ray (trazado distribuido).

Cobertura del temario

Task 2.1: Design scalable and loosely coupled architectures

Task 3.2: Design high-performing and elastic compute solutions

Servicios in-scope de los que este módulo es dueño

Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Step Functions, Amazon MQ, Amazon AppFlow, AWS Lambda, Amazon API Gateway, Amazon ECS, AWS Fargate, Amazon ECS Anywhere, Amazon EKS, Amazon EKS Anywhere, Amazon EKS Distro, Amazon ECR, AWS Amplify, AWS Device Farm, AWS Serverless Application Repository y AWS X-Ray: todos tratados en las secciones anteriores y practicados en los labs 15, 16 y 17.

Practica lo aprendido

Documentación oficial para ampliar

• Amazon SQS message quotas
• Amazon SNS endpoints and quotas
• Amazon EventBridge Pipes
• What is Amazon EventBridge Scheduler?
• Choosing workflow type in Step Functions
• Lambda quotas
• Choose between REST APIs and HTTP APIs
• Amazon API Gateway quotas
• Amazon ECS task definition differences for Fargate
• Implementing Microservices on AWS (whitepaper)
• Serverless Applications Lens