Amazon SAA-C03: Arquitecturas serverless y basadas en eventos / Integración de API — 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.

AWS Lambda: Modelo de ejecución, ciclo de vida del runtime y arranques en frío

Lambda ejecuta código en micro-VMs Firecracker aisladas que siguen un ciclo de vida de dos fases. La fase INIT aprovisiona el contenedor, arranca el runtime, descarga y descomprime el paquete de despliegue, y ejecuta cualquier inicialización a nivel de módulo — construcción de clientes de SDK, carga de secretos descifrados con KMS, configuración del pool de conexiones de la base de datos, carga de clases de la JVM y calentamiento del JIT. La fase INVOKE ejecuta el handler. Un arranque en frío (cold start) incurre en el costo completo de INIT; una invocación en caliente (warm invocation) reutiliza el entorno, por lo que cualquier cosa almacenada en caché fuera del handler (pools de keep-alive de HTTP, secretos descifrados, clientes de BD) persiste entre invocaciones en ese contenedor. Esta es la razón por la que el patrón canónico es construir objetos costosos en el ámbito del módulo y reutilizarlos:

import boto3, os
ddb = boto3.client('dynamodb')          # reused across warm invokes
_secret = None
def _load_secret():
    global _secret
    if _secret is None:
        _secret = kms.decrypt(...)      # KMS call once per container, not per invoke
    return _secret

def handler(event, ctx):
    ...

La magnitud del arranque en frío varía según el runtime. Node.js y Python tardan de decenas a unos pocos cientos de milisegundos; la JVM y .NET pueden superar el segundo. Para funciones conectadas a una VPC, las ENI de Hyperplane han amortizado en gran medida la penalización histórica por adjuntar una ENI, pero el tamaño del paquete y el código pesado en la fase INIT siguen siendo los factores dominantes.

Tres herramientas abordan los arranques en frío de manera diferente:

SnapStart es la solución óptima y rentable para cargas de trabajo Java sin contratos de latencia estrictos — los arranques en frío se reducen aproximadamente en un orden de magnitud sin recargo por invocación. La concurrencia provisionada es la respuesta correcta cuando una API síncrona debe mantener un p99 por debajo de, digamos, 100 ms durante las ráfagas; dimensionarla para el p95 de las ráfagas cierra la brecha de la latencia de cola (tail-latency). Subdimensionarla es un fallo clásico: el modo bajo demanda solo levanta nuevos contenedores cuando llega una solicitud, por lo que un pico produce esperas de varios segundos para los usuarios reales.

# SAM: SnapStart on a Java 17 function
MyJavaFn:
  Type: AWS::Serverless::Function
  Properties:
    Runtime: java17
    SnapStart: { ApplyOn: PublishedVersions }
    AutoPublishAlias: live

La concurrencia provisionada en sí misma puede escalarse mediante Application Auto Scaling — una acción programada que aumenta de 10 a 200 a las 07:45 y vuelve a bajar a las 10:00 evita pagar por capacidad caliente durante la noche, al tiempo que elimina los arranques en frío de la oleada matutina.

El dimensionamiento de la memoria es a la vez un ajuste de CPU: la vCPU escala linealmente con la memoria hasta ~1,769 MB por vCPU. Una función fijada en 128 MB puede costar más en total que una en 1,024 MB porque el doble de tiempo de ejecución a menudo supera el doble del precio por ms. No adivine — use AWS Lambda Power Tuning para barrer configuraciones con cargas de trabajo representativas.

Controles de concurrencia de Lambda y protección de sistemas posteriores

Tres controles de concurrencia son importantes y cada uno cumple una función diferente:

• La concurrencia reservada limita y reserva cuántas ejecuciones concurrentes puede consumir una función. Aparta capacidad del pool de la cuenta y protege los sistemas posteriores (una instancia RDS pequeña, una API de un socio con límites de tasa) para que no se saturen.
• La concurrencia provisionada pre-inicializa entornos — es la palanca para la latencia, no para el escalado.
• La concurrencia de cuenta no reservada es el pool compartido, con un valor por defecto de 1,000 por Región.

Asumir que Lambda “escala infinitamente” pasa por alto dos techos. Primero, el límite de ejecuciones concurrentes a nivel de cuenta es real, y los límites de ráfaga (burst) (inicial de 500–3,000 según la Región, luego +500/min) gobiernan la tasa de aumento. Una vez superado, las llamadas síncronas reciben un 429 TooManyRequestsException, que API Gateway expone como un error 5xx. Segundo, los sistemas posteriores tienen sus propios límites: una instancia db.t3.micro con max_connections=85 no puede sobrevivir a mil Lambdas concurrentes abriendo cada una una conexión. PostgreSQL bifurca un proceso de backend por conexión que consume ~10 MB de RAM; incluso con CPU de sobra, solo el establecimiento y cierre de conexiones puede saturar la instancia.

Las dos mitigaciones son (1) RDS Proxy, que agrupa y multiplexa muchas conexiones del lado del cliente en un pequeño conjunto de conexiones de backend persistentes, y (2) insertar una cola para que la tasa de procesamiento se desacople de la tasa de llegada:

import psycopg2, os
conn = psycopg2.connect(
    host=os.environ['PROXY_ENDPOINT'],   # RDS Proxy, not the DB directly
    dbname='orders', user='app', password=get_secret())

RDS Proxy es una solución de cambio mínimo — el driver y la cadena de conexión apenas cambian — lo que la convierte en la respuesta correcta siempre que el requisito sea “el menor cambio posible en la aplicación” además de evitar el agotamiento de conexiones. DynamoDB no tiene este problema: su API HTTPS no tiene estado (stateless), razón por la cual DynamoDB se combina naturalmente con cargas de trabajo de Lambda de alta distribución (high-fanout).

IAM, variables de entorno y redes en Lambda

Cada función asume un rol de ejecución en su invocación. La política de confianza del rol otorga sts:AssumeRole a lambda.amazonaws.com; su política de permisos define lo que la función puede hacer. El runtime inyecta automáticamente credenciales de STS de corta duración en AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY y AWS_SESSION_TOKEN. Nunca incrustes claves de acceso de usuario de IAM en variables de entorno o en el código: son estáticas, se pueden descubrir en filtraciones de código fuente o exportaciones de CloudTrail, deben rotarse manualmente y eluden por completo el modelo de credenciales temporales.

FnRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
      - Effect: Allow
        Principal: { Service: lambda.amazonaws.com }
        Action: sts:AssumeRole
    Policies:
      - PolicyName: ReadOrders
        PolicyDocument:
          Statement:
          - Effect: Allow
            Action: ["dynamodb:GetItem", "dynamodb:Query"]
            Resource: !GetAtt OrdersTable.Arn

Las variables de entorno que contienen configuración sensible deben cifrarse con una clave de KMS administrada por el cliente, utilizando los «ayudantes para el cifrado en tránsito» para que la consola cifre del lado del cliente. Descifra una vez en la fase de INIT y guarda el texto plano en una variable a nivel de módulo; de lo contrario, cada invocación pagará una llamada a la API de KMS.

Por defecto, una función se ejecuta en una VPC administrada por AWS con salida a internet sin restricciones. Conéctala a tu propia VPC solo cuando necesite alcanzar recursos residentes en la VPC (RDS en subredes privadas, ElastiCache, on-prem a través de Direct Connect). Lambda entonces adjunta ENIs de Hyperplane en las subredes que especifiques y hereda sus tablas de enrutamiento.

La trampa clásica es colocar una Lambda en una subred privada sin una ruta para el tráfico de servicios de AWS, excepto a través de un NAT gateway, o peor aún, una instancia NAT autoadministrada. Las instancias NAT se saturan con una sola NIC, son un punto único de fallo (SPOF) y facturan por GB. Incluso los NAT gateways cobran por GB y son innecesarios para el tráfico de servicios de AWS. El patrón correcto es:

• Endpoints de VPC de tipo gateway para S3 y DynamoDB (gratuitos)
• Endpoints de tipo interface (PrivateLink) para KMS, Secrets Manager, SQS, SNS, STS y similares

Esto mantiene el tráfico en la red troncal de AWS, elimina los límites de rendimiento del NAT y previene facturas sorpresa por egreso de datos. Ten en cuenta que las ENIs de Lambda nunca obtienen una IP pública; colocar la función en una subred «pública» no le da acceso a internet; todavía necesitas un NAT gateway en una subred pública separada con una ruta apropiada.

Amazon API Gateway: tipos de endpoint, autorización y entrega

API Gateway ofrece tres tipos de API:

Elige REST cuando necesites claves de API y planes de uso, validación de solicitudes con JSON Schema, plantillas de mapeo VTL, autorizadores de Cognito con ámbitos por método, o WAF; elige HTTP para patrones de proxy ligeros autenticados con JWT donde el costo y la latencia importan más.

Los tipos de endpoint gobiernan dónde se expone la API:

• Optimizado para la periferia (edge-optimized): expuesto a través de una distribución de CloudFront administrada por Gateway; el TLS termina en el POP más cercano. Ideal para clientes distribuidos globalmente.
• Regional: expuesto desde una única región sin CloudFront. Ideal cuando los clientes están en la misma región, cuando quieres poner tu propio CloudFront por delante, o cuando usas enrutamiento basado en latencia de Route 53 entre múltiples regiones.
• Privado: accesible solo a través de un endpoint de VPC de tipo interface. Ideal para microservicios internos que no deben atravesar la internet pública.

Seleccionar edge-optimized para una API interna de una sola región añade un salto de CloudFront innecesario y una propagación de despliegues más lenta. Seleccionar regional para una API pública de consumo global fuerza a que cada solicitud atraviese la internet pública hasta una única región.

Los dominios personalizados requieren certificados de ACM con una ubicación que depende del tipo de endpoint: us-east-1 para los edge-optimized (CloudFront es global y termina el TLS allí); la propia región de la API para los endpoints regionales. Confundir esto es un error de configuración habitual. Los mapeos de ruta base (base path mappings) permiten que un solo dominio multiplexe varias APIs (/orders → API de pedidos, /users → API de usuarios).

La autorización tiene cuatro modelos, y recurrir a soluciones personalizadas cuando existen las integradas es un antipatrón clásico:

Un autorizador de Lambda personalizado añade una invocación extra por solicitud (o por TTL de la caché), otra función que parchear y monitorear, y una ruta de código donde los errores de validación de firmas pueden permitir el acceso silenciosamente. Úsalo solo cuando las opciones integradas realmente no puedan expresar el requisito.

La integración de proxy con Lambda es el patrón por defecto: la solicitud completa se pasa como un evento y la función debe devolver la estructura de la envolvente de respuesta:

{
  "statusCode": 200,
  "headers": {"Content-Type": "application/json"},
  "body": "{\"orderId\":\"abc123\"}",
  "isBase64Encoded": false
}

Para una ingesta de tipo fire-and-forget con un TPS muy alto, usa la integración directa con servicios de AWS de Gateway para enviar datos directamente a SQS o Kinesis, saltándose por completo el paso por Lambda. Esto elimina los arranques en frío en la ruta de escritura y desacopla la tasa de ingesta de la capacidad de procesamiento.

Para despliegues seguros, usa despliegues canary en una etapa (stage): un porcentaje del tráfico va al nuevo despliegue mientras que la mayoría permanece en la versión estable; las métricas de CloudWatch por cada canary informan si se debe promover o revertir.

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations \
    op=replace,path=/canarySettings/percentTraffic,value=10 \
    op=replace,path=/canarySettings/deploymentId,value=xyz789

Para un webhook simple donde la ceremonia de API Gateway es excesiva (un callback de Slack para un solo tenant, un handler de push de GitHub), las URL de función de Lambda proporcionan un endpoint HTTPS dedicado directamente en la función. Asegúralas con AuthType: AWS_IAM cuando los llamadores son principales de AWS; si es NONE, debes validar la firma de la solicitud dentro de la función. Una URL de función con AuthType: NONE y sin verificación dentro de la función es un endpoint de cómputo anónimo en la internet pública.

Tipos de invocación, reintentos e idempotencia

Las fuentes de eventos se dividen en dos categorías con comportamientos muy diferentes. Las fuentes basadas en push (API Gateway, ALB, S3, SNS, EventBridge, Cognito) invocan a Lambda directamente y requieren una política basada en recursos AWS::Lambda::Permission que otorgue lambda:InvokeFunction con el Principal correcto (p. ej., events.amazonaws.com) y el SourceArn. Sin ella, la regla coincide con los eventos, pero cada invocación es denegada silenciosamente: la función nunca se ejecuta y los fallos solo aparecen en CloudTrail. Esto es distinto del rol de ejecución, que gobierna lo que la función puede hacer, no quién puede invocarla.

Las fuentes basadas en sondeo (poll) (SQS, Kinesis, DynamoDB Streams, MSK) son leídas por el servicio de Lambda a través de un mapeo de fuente de eventos; no se necesita una política basada en recursos, pero el rol de ejecución debe otorgar permisos de lectura.

Los tipos de invocación ramifican aún más el comportamiento de los reintentos:

• Síncrona (API Gateway, ALB, SDK RequestResponse): los errores se devuelven inmediatamente; el invocador es responsable de los reintentos.
• Asíncrona (S3, SNS, EventBridge): Lambda almacena en búfer en una cola interna y reintenta dos veces con demoras en caso de fallo, luego envía a una DLQ o a un destino en caso de fallo (on-failure destination).
• Mapeo de fuente de eventos de SQS: SQS sigue reentregando hasta que maxReceiveCount activa un movimiento a la DLQ de la cola de origen.
• Kinesis / DynamoDB Streams: reintenta un único lote (batch) de un shard hasta que tenga éxito o expire, bloqueando el shard mientras tanto; un lote atascado detiene todo el procesamiento posterior para esa partición.

Debido a que los reintentos están integrados en cada capa, la idempotencia es obligatoria, no opcional. Un tiempo de espera de visibilidad (visibility timeout) de SQS que expira durante una escritura lenta o un reintento asíncrono después de un 5xx en un servicio posterior producirá duplicados. El patrón canónico utiliza una clave determinista y una escritura condicional de DynamoDB:

def handler(event, context):
    msg_id = event['Records'][0]['messageId']
    try:
        ddb.put_item(
            TableName='processed',
            Item={'id': {'S': msg_id}, 'ttl': {'N': str(ttl)}},
            ConditionExpression='attribute_not_exists(id)')
    except ddb.exceptions.ConditionalCheckFailedException:
        return  # already processed
    process(event)

El decorador @idempotent de AWS Lambda Powertools implementa exactamente este patrón con DynamoDB como respaldo.

Desacoplamiento con SQS y SNS

Conectar fuentes de push con alto fan-out directamente a Lambda es frágil. Las notificaciones de eventos de S3, por ejemplo, son síncronas por evento y están sujetas al límite de concurrencia de Lambda; si las invocaciones exceden la concurrencia disponible durante una carga masiva (una campaña de marketing que sube miles de documentos en segundos), la ventana de reintentos de S3 es corta y los eventos pueden ser descartados (dropped) efectivamente. El remedio es un búfer:

SNS es pub/sub: una publicación, muchos suscriptores (SQS, Lambda, HTTPS, correo electrónico). El filtrado de mensajes se basa en atributos. SQS es una cola duradera punto a punto que retiene mensajes hasta 14 días. La combinación de batalla es el fan-out de SNS → SQS, que le da a cada consumidor su propia cola con búfer para escalado y reproducción independientes.

Para un ordenamiento estricto (p. ej., pedidos por cliente procesados secuencialmente), usa una cola SQS FIFO con el MessageGroupId establecido en la clave de ordenamiento. Los mensajes dentro de un grupo se entregan en orden; diferentes grupos se procesan en paralelo. SQS estándar solo ofrece un ordenamiento de mejor esfuerzo (best-effort).

El patrón canónico de ingesta desacoplada utiliza la integración directa de API Gateway con SQS para absorber picos de carga y un procesador con tasa limitada:

Resources:
  OrdersQueue:
    Type: AWS::SQS::Queue
    Properties:
      FifoQueue: true
      ContentBasedDeduplication: true
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt OrdersDLQ.Arn
        maxReceiveCount: 5

  ProcessorFunction:
    Type: AWS::Lambda::Function
    Properties:
      ReservedConcurrentExecutions: 20   # cap the DB write rate

  Mapping:
    Type: AWS::Lambda::EventSourceMapping
    Properties:
      EventSourceArn: !GetAtt OrdersQueue.Arn
      FunctionName: !Ref ProcessorFunction
      BatchSize: 10

La concurrencia reservada es deliberada: limita la rapidez con la que la base de datos ve las escrituras, de modo que la cola (no RDS) absorbe el pico de carga. Los mensajes fallidos se enrutan a una DLQ después de maxReceiveCount para una inspección fuera de línea.

EventBridge: Reglas, transformación de entrada y destinos de API

EventBridge es un bus de eventos consciente de esquemas con un potente emparejamiento de patrones JSON, fuentes de socios SaaS, registro de esquemas y archivo/reproducción. Las reglas coinciden con patrones de eventos y se distribuyen (fan-out) a más de 30 tipos de destinos (Lambda, Step Functions, SQS, Kinesis, ECS, Firehose), con filtrado basado en el contenido del cuerpo del mensaje, no solo en atributos como en SNS:

{
  "source": ["tenant.energy"],
  "detail-type": ["UsageReported"],
  "detail": { "kWh": [{ "numeric": [">", 100] }] }
}

Una regla puede tener hasta cinco destinos, y cada uno recibe el evento sin procesar o un subconjunto transformado. Los transformadores de entrada (Input transformers) imponen un acoplamiento débil: un InputPathsMap extrae rutas JSON del evento, y un InputTemplate les da la forma exacta que el destino espera:

EventPattern:
  source: ["com.acme.orders"]
  detail-type: ["OrderPlaced"]
Targets:
  - Arn: !GetAtt PaymentValidator.Arn
    InputTransformer:
      InputPathsMap:
        orderId: "$.detail.orderId"
        amount: "$.detail.total"
        card: "$.detail.payment.cardToken"
      InputTemplate: |
        {"orderId": <orderId>, "amount": <amount>, "cardToken": <card>}

Cada Lambda de validación recibe solo lo que necesita; el validador de direcciones nunca ve el token de la tarjeta. Esto es decididamente superior a una Lambda monolítica que recibe el evento completo y se ramifica internamente: un monolito concentra los permisos de IAM (un solo rol debe tener todos los permisos posteriores), infla el radio de impacto de un error, acopla la cadencia de despliegue, impide el ajuste de memoria/timeout por responsabilidad y obliga a toda la función a escalar a la tasa de la rama más ruidosa.

Los destinos de API (API destinations) invierten la dirección: EventBridge llama a un endpoint HTTPS externo. Junto con una conexión que almacena credenciales de tipo Basic, clave de API u OAuth en Secrets Manager, esta es la forma serverless de notificar a un SaaS de terceros cuando, por ejemplo, un trabajo de AWS Batch tiene éxito, sin necesidad de una Lambda. EventBridge captura el evento de cambio de estado, una regla coincide con JobSucceeded, y el destino de API realiza un POST al proveedor con las credenciales inyectadas desde la conexión.

Las reglas programadas (expresiones cron/rate) o el más reciente EventBridge Scheduler reemplazan a las instancias EC2 de “heartbeat” para tareas periódicas, como informes nocturnos o la actualización de caché cada hora.

Elige EventBridge sobre SNS cuando el filtrado se basa en el contenido del cuerpo del mensaje (no solo en atributos), cuando nuevos consumidores deban conectarse más tarde sin cambios en el productor, o cuando el enrutamiento abarca varias cuentas o fuentes SaaS. Elige SNS cuando el fan-out es una simple notificación filtrada por atributos a un conjunto estable de suscriptores.

Step Functions: Orquestación y Mapa Distribuido

Cuando un flujo de trabajo tiene más de un par de pasos, ramificaciones, reintentos, aprobación humana o esperas largas, integrar esa lógica en Lambdas encadenadas se vuelve inmantenible. Step Functions externaliza la máquina de estados en Amazon States Language.

• Flujos de trabajo estándar: hasta un año, semántica de ejecución única (exactly-once), historial de ejecución completo, .waitForTaskToken para puertas de enlace humanas/externas. Procesamiento de pedidos, ETL, flujos de aprobación.
• Flujos de trabajo exprés: hasta cinco minutos, al menos una vez (at-least-once), alto volumen, económico por ejecución. Orquestaciones síncronas cortas detrás de API Gateway; transformaciones de IoT y streaming.

Cada tarea debe declarar Retry y Catch explícitamente:

"ValidatePayment": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Parameters": {"FunctionName": "PaymentValidator", "Payload.$": "$"},
  "Retry": [{
    "ErrorEquals": ["Lambda.ServiceException", "Lambda.TooManyRequestsException"],
    "IntervalSeconds": 2, "MaxAttempts": 4, "BackoffRate": 2.0
  }],
  "Catch": [{"ErrorEquals": ["PaymentDeclined"], "Next": "RefundStep"}],
  "Next": "ShipOrder"
}

Los estados Parallel y Map ejecutan ramas en concurrencia y agregan los resultados; un ajuste perfecto para sistemas de pedidos con validadores independientes (dirección, inventario, pago). El estado entre pasos fluye a través del documento JSON de la ejecución, eliminando la necesidad de una base de datos compartida utilizada únicamente para la coordinación del flujo de trabajo.

El patrón .waitForTaskToken pausa la ejecución hasta que un actor externo llama a SendTaskSuccess con el token; es la respuesta canónica cuando un flujo de trabajo abarca Lambdas, EC2, contenedores, sistemas on-premise y requiere aprobación manual con una sobrecarga operativa mínima:

"ManagerApproval": {
  "Type": "Task",
  "Resource": "arn:aws:states:::sns:publish.waitForTaskToken",
  "Parameters": {
    "TopicArn": "arn:aws:sns:us-east-1:111:approvals",
    "Message": { "TaskToken.$": "$$.Task.Token", "OrderId.$": "$.orderId" }
  },
  "Next": "Fulfill"
}

Distributed Map extiende el estado Map estándar para procesar hasta 10,000 ejecuciones secundarias en paralelo y puede iterar directamente sobre objetos en un bucket de S3 o filas en un archivo CSV/JSONL, con procesamiento por lotes, puntos de control y tolerancia a fallos automáticos. Para miles de objetos semiestructurados de S3, es la opción más eficiente operacionalmente: apúntalo a un prefijo, define la tarea por elemento y Step Functions se encarga del fan-out, MaxConcurrency, los reintentos y la agregación de resultados:

{
  "Type": "Map",
  "ItemReader": {
    "Resource": "arn:aws:states:::s3:listObjectsV2",
    "Parameters": { "Bucket": "raw-events", "Prefix": "2024/" }
  },
  "MaxConcurrency": 1000,
  "ItemProcessor": {
    "ProcessorConfig": { "Mode": "DISTRIBUTED", "ExecutionType": "STANDARD" },
    "StartAt": "ProcessObject",
    "States": { "ProcessObject": { "Type": "Task", "Resource": "arn:aws:lambda:...:function:ProcessOne", "End": true } }
  }
}

Reconstruir lo mismo en SQS o EventBridge requiere una gestión personalizada para el seguimiento de la finalización, los reintentos y la recopilación de resultados.

Step Functions vs. EventBridge: Step Functions es la opción correcta cuando tú eres el dueño de la secuencia y el resultado: estado, ramificaciones, reintentos, aprobaciones. EventBridge es la opción correcta cuando los productores no saben ni les importa quién consume, y los consumidores se acoplan de forma independiente.

Notificaciones de eventos de S3

Para el procesamiento casi en tiempo real de las subidas de archivos, configura notificaciones de eventos de S3 en s3:ObjectCreated:* (o una variante específica como Put, Post, CompleteMultipartUpload) con un destino Lambda, sujeto a las advertencias sobre ráfagas mencionadas anteriormente. Medidas de protección:

• Establece concurrencia reservada para proteger una base de datos downstream.
• Habilita una DLQ o un destino en caso de fallo para mensajes fallidos (poison messages).
• Enruta los eventos de S3 a través de EventBridge cuando múltiples consumidores necesiten los mismos eventos. Las configuraciones de notificación directa de S3 son limitadas en cantidad y expresividad; el fan-out de EventBridge con transformadores de entrada por destino escala mucho mejor.

Streaming: Kinesis Data Streams vs. Firehose

Kinesis Data Streams (KDS) es un registro (log) particionado (sharded), ordenado y reproducible con una retención de 24 horas a 365 días. El orden se preserva por shard, basado en la clave de partición, lo cual es crítico para la agregación por dispositivo o por tenant. Múltiples consumidores leen de forma independiente (enhanced fan-out para un throughput aislado por consumidor). Elige KDS cuando necesites reproducción ordenada, múltiples consumidores independientes o un alto throughput por shard.

Kinesis Data Firehose es un stream de entrega totalmente gestionado a S3, Redshift, OpenSearch o Splunk con búfer incorporado (60 s o 1–128 MB), transformación opcional con Lambda, compresión (GZIP, Snappy) y conversión a Parquet/ORC. No hay shards que gestionar. Firehose es la opción de baja sobrecarga operativa cuando no se necesitan consumidores personalizados ni reproducción, solo depositar datos casi en tiempo real.

El pipeline canónico de analítica casi en tiempo real es productores → KDS → Firehose → S3 (Parquet) → Athena/QuickSight, con enriquecimiento opcional mediante Lambda en Firehose.

AWS Transfer Family para SFTP gestionado

Cuando los socios requieren SFTP, FTPS o FTP para transferir archivos hacia o desde S3 o EFS, AWS Transfer Family proporciona un endpoint gestionado y multi-AZ que habla el protocolo que los clientes ya utilizan. La autenticación admite usuarios gestionados por el servicio, claves SSH o IdPs personalizados a través de API Gateway/Lambda. Los archivos llegan directamente a S3 con SSE y políticas de ciclo de vida aplicadas; las políticas de IAM de alcance reducido (scope-down) restringen a cada usuario a un prefijo específico.

Construir esto por tu cuenta en EC2 requiere el hardening de OpenSSH, aplicación de parches, alta disponibilidad (HA) entre AZs, rotación de claves y envío de logs; todo lo cual es absorbido por Transfer Family. Elígelo siempre que el requisito sea “los socios nos envían archivos por SFTP” y quieras los archivos en S3 con una sobrecarga operativa mínima.

Componiendo un patrón Serverless canónico

Un diseño de ingesta de baja sobrecarga para métricas horarias por tenant: los sensores hacen POST a API Gateway (HTTP API, regional) → Lambda valida y publica en EventBridge → las reglas enrutan a una Lambda escritora de DynamoDB (ID del tenant como clave de partición, bloque horario como clave de ordenación) y, en paralelo, a Firehose → S3 (Parquet) para analítica. Nuevos consumidores se acoplan como reglas adicionales de EventBridge sin tocar a los productores; el requisito de extensibilidad que solo con SNS no se cumpliría tan limpiamente. Donde el throughput sostenido y el orden importan (conciliación de facturación, flujos de eventos financieros), reemplaza EventBridge con Kinesis Data Streams y usa enhanced fan-out para consumidores independientes.

Catálogo de trampas: Por qué fallan los patrones incorrectos comunes

Instancia/gateway NAT para el tráfico de servicios de AWS desde Lambdas en subredes privadas. Las instancias NAT atan el rendimiento a una única NIC de EC2 y son un punto único de fallo (SPOF); los gateways NAT facturan por GB. Ambos son innecesarios para destinos de servicios de AWS. Usa endpoints de gateway para S3/DynamoDB y endpoints de interfaz para todo lo demás.

Ignorar los arranques en frío en APIs críticas por su latencia. El modo bajo demanda solo aprovisiona contenedores cuando llega una solicitud, por lo que las ráfagas de tráfico incumplen los SLAs. Dimensiona la concurrencia aprovisionada para la ráfaga p95; usa SnapStart para cargas de trabajo en Java sin SLAs estrictos.

Lambda monolítica que recibe un evento completo y se ramifica internamente. Viola el principio de privilegio mínimo (un solo rol tiene todos los permisos posteriores), acopla la cadencia de despliegue, impide el ajuste por responsabilidad y escala toda la función al ritmo de la rama con más tráfico. Divide por responsabilidad; únelas con EventBridge o Step Functions.

Conexiones directas a la base de datos desde muchas Lambdas. El total de conexiones es igual a las invocaciones concurrentes porque los contenedores no comparten pools. Soluciónalo con RDS Proxy (pooling), concurrencia reservada (límite de tasa) o SQS (buffering).

Lambda síncrona para ingesta con ráfagas de tráfico. Exceder la concurrencia devuelve un 429 a API Gateway y un 5xx a los clientes; las notificaciones directas de S3 durante las ráfagas descartan eventos silenciosamente. Inserta SQS, o usa la integración directa de Gateway → SQS.

URLs de función Lambda públicas con AuthType: NONE y sin validación de firma dentro de la función. Cómputo anónimo en la internet pública. Usa AWS_IAM para llamadores de AWS o valida las firmas para webhooks de terceros.

Autorizador Lambda personalizado donde uno integrado funcionaría. Añade latencia, otra función que necesita parches y una ruta de código donde los errores en la verificación de firmas permiten el acceso silenciosamente. Prefiere la autorización de IAM para principales de AWS; el autorizador de Cognito para pools de usuarios.

Región incorrecta del certificado de ACM para dominios personalizados. Los endpoints optimizados para el borde (edge-optimized) requieren el certificado en us-east-1; los endpoints regionales en la propia región de la API.

Falta de AWS::Lambda::Permission para fuentes de eventos push (EventBridge, S3, SNS). Los eventos coinciden con las reglas, pero las invocaciones se deniegan silenciosamente. Es distinto del rol de ejecución: esto gobierna quién puede llamar a la función, no lo que la función puede hacer.

Falta de idempotencia. Cada capa realiza reintentos: invocaciones asíncronas, reentrega de SQS al expirar el tiempo de espera de visibilidad, reintentos de lotes de Kinesis. Sin una clave de deduplicación determinista y una escritura condicional, los duplicados son inevitables.

← Contenedores y orquestación · Todos los dominios · Almacenamiento y ciclo de vida de los datos →

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

Explorar Amazon →