Amazon SAA-C03: Arquitecturas Serverless y Basadas en Eventos / Integración de API — 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.

AWS Lambda: Modelo de ejecución, ciclo de vida del tiempo de ejecución e inicios en frío

Lambda ejecuta código en micro-VMs aisladas de Firecracker que siguen un ciclo de vida de dos fases. La fase INIT aprovisiona el contenedor, arranca el tiempo de ejecución, descarga y descomprime el paquete de despliegue, y ejecuta cualquier inicialización a nivel de módulo — construcción de clientes SDK, carga de secretos descifrados por KMS, configuración de grupos de conexiones de bases de datos, carga de clases JVM y calentamiento JIT. La fase INVOKE ejecuta el manejador. Un inicio en frío incurre en el costo total de INIT; una invocación en caliente reutiliza el entorno, por lo que cualquier cosa almacenada en caché fuera del manejador (grupos HTTP keep-alive, secretos descifrados, clientes de DB) persiste a través de las invocaciones en ese contenedor. Por eso 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 inicio en frío varía según el tiempo de ejecución. Node.js y Python son de decenas a unos pocos cientos de milisegundos; JVM y .NET pueden superar el segundo. Para funciones conectadas a VPC, las ENI de Hyperplane han amortizado en gran medida la penalización histórica de la conexión ENI, pero el tamaño del paquete y el código INIT pesado siguen siendo dominantes.

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

SnapStart es el punto óptimo y rentable para cargas de trabajo Java sin contratos de latencia estrictos — los inicios en frío se reducen aproximadamente en un orden de magnitud sin recargo por invocación. La concurrencia aprovisionada es la respuesta correcta cuando una API síncrona debe mantener un p99 por debajo, digamos, de 100 ms durante las ráfagas; dimensionarla al p95 de la ráfaga cierra la brecha de latencia de cola. Subdimensionarla es un fallo clásico: bajo demanda solo activa 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 aprovisionada se puede escalar a través de Application Auto Scaling — una acción programada que aumenta de 10 a 200 a las 07:45 y vuelve a las 10:00 evita pagar por capacidad en caliente durante la noche, eliminando los inicios en frío de la mañana.

El dimensionamiento de la memoria es simultáneamente un dial 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 general que una en 1,024 MB porque el tiempo de ejecución duplicado a menudo excede el precio duplicado por ms. No adivine — use AWS Lambda Power Tuning para probar configuraciones con cargas útiles representativas.

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

Hay tres controles de concurrencia importantes y cada uno tiene una función diferente:

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

Asumir que Lambda “escala infinitamente” pasa por alto dos límites. Primero, el límite de ejecución concurrente a nivel de cuenta es real, y los límites de ráfaga (inicial de 500–3,000 dependiendo de la Región, luego +500/min) rigen la tasa de aumento. Una vez excedido, los llamadores síncronos reciben 429 TooManyRequestsException, que API Gateway muestra como 5xx. Segundo, los sistemas descendentes tienen sus propios límites: una db.t3.micro con max_connections=85 no puede sobrevivir a mil Lambdas concurrentes, cada una abriendo una conexión. PostgreSQL bifurca un proceso de backend por conexión consumiendo ~10 MB de RAM; incluso con CPU de sobra, la configuración y el cierre de la conexión por sí solos pueden 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 persistentes de backend, 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 controlador y la cadena de conexión apenas cambian — lo que la convierte en la respuesta correcta siempre que el requisito sea “el menor cambio en la aplicación” más el agotamiento de las conexiones. DynamoDB no tiene este problema: su API HTTPS es sin estado, por lo que DynamoDB se empareja naturalmente con cargas de trabajo Lambda de alta dispersión.

Lambda IAM, variables de entorno y redes

Cada función asume un rol de ejecución al ser invocada. 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 tiempo de ejecución inyecta automáticamente credenciales STS de corta duración en AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY y AWS_SESSION_TOKEN. Nunca incruste claves de acceso de usuario de IAM en variables de entorno o código: son estáticas, detectables en código fuente filtrado o exportaciones de CloudTrail, deben rotarse manualmente y omiten todo 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 configuraciones sensibles deben cifrarse con una clave KMS administrada por el cliente, utilizando “ayudas para el cifrado en tránsito” para que la consola cifre del lado del cliente. Descifre una vez en INIT y almacene el texto sin cifrar 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 internet saliente sin restricciones. Conéctela a su propia VPC solo cuando deba acceder a recursos residentes en la VPC (RDS en subredes privadas, ElastiCache, on-premise a través de Direct Connect). Lambda adjunta entonces ENI de Hyperplane a las subredes que especifique y hereda su enrutamiento.

La trampa clásica es colocar una Lambda en una subred privada sin 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 en una sola NIC, son un SPOF y se 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:

• VPC endpoints de Gateway para S3 y DynamoDB (gratuitos)
• VPC endpoints de Interfaz (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 de NAT y evita facturas de egreso inesperadas. Tenga en cuenta que las ENI de Lambda nunca obtienen una IP pública; colocar la función en una subred “pública” no le da acceso a internet; aún necesita un NAT Gateway en una subred pública separada con una ruta adecuada.

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

API Gateway ofrece tres tipos de API:

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

Los tipos de endpoint rigen dónde se encuentra la API:

• Edge-optimized: con CloudFront administrado por Gateway; TLS termina en el POP más cercano. Ideal para clientes distribuidos globalmente.
• Regional: expuesto desde una sola región sin CloudFront. Ideal cuando los clientes están en la región, cuando desea su propio CloudFront delante o cuando usa enrutamiento basado en latencia de Route 53 en varias regiones.
• Private: accesible solo a través de un endpoint de VPC de interfaz. Ideal para microservicios internos que no deben atravesar la internet pública.

Seleccionar “edge-optimized” para una API interna de una sola región agrega un salto innecesario de CloudFront y una propagación de implementación más lenta. Seleccionar “regional” para una API pública consumida globalmente obliga a cada solicitud a través de la internet pública a una región.

Los dominios personalizados requieren certificados ACM con una ubicación que depende del tipo de endpoint: us-east-1 para “edge-optimized” (CloudFront es global y termina TLS allí); la propia región de la API para endpoints regionales. Confundir esto es una mala configuración rutinaria. Los mapeos de rutas base permiten que un dominio multiplexe múltiples API (/orders → API de pedidos, /users → API de usuarios).

La autorización tiene cuatro modelos, y ir más allá de los incorporados es un antipatrón clásico:

Un autorizador de Lambda personalizado agrega una invocación adicional por solicitud (o por TTL de caché), otra función para parchear y monitorear, y una ruta de código donde los errores de validación de firma pueden permitir el acceso silenciosamente. Úselo solo cuando los incorporados realmente no puedan expresar el requisito.

La integración de proxy de Lambda es el patrón predeterminado: la solicitud completa se pasa como un evento y la función debe devolver la forma del sobre de respuesta:

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

Para la ingesta “fire-and-forget” a TPS muy altos, use la integración directa de servicios de AWS de Gateway para enviar directamente a SQS o Kinesis, omitiendo por completo el salto de 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 implementaciones seguras, use implementaciones canary en una etapa: un porcentaje del tráfico va a la nueva implementación mientras la mayoría permanece en la versión estable, las métricas de CloudWatch por canary informan la promoción o la reversión.

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 (callback de Slack de un solo inquilino, manejador de push de GitHub), las URL de función de Lambda proporcionan un endpoint HTTPS dedicado directamente en la función. Asegúrelas con AuthType: AWS_IAM cuando los llamadores sean principales de AWS; si NONE, debe 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 (por ejemplo, events.amazonaws.com) y 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 rige lo que la función puede hacer, no quién puede llamarlo.

Las fuentes basadas en sondeo (SQS, Kinesis, DynamoDB Streams, MSK) son leídas por el servicio Lambda a través de un mapeo de origen 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 reintento:

• Síncrono (API Gateway, ALB, SDK RequestResponse): los errores se devuelven inmediatamente; el llamador es el responsable de los reintentos.
• Asíncrono (S3, SNS, EventBridge): Lambda almacena en búfer en una cola interna y reintenta dos veces con retrasos en caso de fallo, luego envía a una DLQ o destino en caso de fallo.
• Mapeo de origen de eventos de SQS: SQS sigue reenviando hasta que maxReceiveCount activa un movimiento a la DLQ de la cola de origen.
• Kinesis / DynamoDB Streams: reintenta un único lote de 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 de SQS que expira durante una escritura lenta o un reintento asíncrono después de un 5xx 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 el respaldo de DynamoDB.

Desacoplamiento con SQS y SNS

Conectar fuentes push de alta dispersión 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 en ráfaga (una campaña de marketing que suelta miles de documentos en segundos), la ventana de reintento de S3 es corta y los eventos pueden perderse 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 principal es la dispersión de SNS → SQS, lo que le da a cada consumidor su propia cola en búfer para una escalabilidad y reproducción independientes.

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

El patrón de ingesta desacoplada canónico utiliza la integración directa de SQS de Gateway para absorber ráfagas y un procesador con límite de velocidad:

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 velocidad con la que la base de datos ve las escrituras, por lo que la cola (no RDS) absorbe la ráfaga. Los mensajes fallidos se enrutan a una DLQ después de maxReceiveCount para su inspección fuera de línea.

EventBridge: Reglas, Transformación de Entrada y Destinos de API

EventBridge es un bus de eventos con reconocimiento de esquemas con un rico patrón de coincidencia JSON, fuentes de socios SaaS, registro de esquemas y archivo/reproducción. Las reglas coinciden con patrones de eventos y se dispersan a más de 30 tipos de destino (Lambda, Step Functions, SQS, Kinesis, ECS, Firehose), con filtrado basado en contenido en el cuerpo del mensaje, no solo atributos como en SNS:

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

Una regla puede tener hasta cinco destinos, cada uno de los cuales recibe el evento sin procesar o un subconjunto transformado. Los transformadores de entrada imponen un acoplamiento flexible: un InputPathsMap extrae rutas JSON del evento y un InputTemplate las remodela exactamente como espera el destino:

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 rol debe tener todos los permisos posteriores), infla el radio de explosión de un error, acopla la cadencia de implementación, evita el ajuste de memoria/tiempo de espera por responsabilidad y obliga a toda la función a escalar a la velocidad de la rama más ruidosa.

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

Las reglas programadas (expresiones cron/rate) o el nuevo EventBridge Scheduler reemplazan las instancias EC2 de latido para tareas periódicas: informes nocturnos, actualización de caché por hora.

Elija EventBridge sobre SNS cuando el filtrado se base en el contenido del cuerpo del mensaje (no solo en los atributos), cuando los nuevos consumidores deban conectarse más tarde sin cambios en el productor, o cuando el enrutamiento abarque cuentas o fuentes SaaS. Elija SNS cuando la dispersión sea una notificación simple 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, incrustar esa lógica en Lambdas encadenadas se vuelve inmanejable. Step Functions externaliza la máquina de estados en Amazon States Language.

• Flujos de trabajo estándar: hasta un año, semántica de “exactamente una vez”, historial de ejecución completo, .waitForTaskToken para puertas humanas/externas. Cumplimiento de pedidos, ETL, flujos de aprobación.
• Flujos de trabajo Express: hasta cinco minutos, “al menos una vez”, alto volumen, barato por ejecución. Orquestaciones síncronas cortas detrás de API Gateway; IoT y transformaciones de streaming.

Cada tarea debe declarar Retry y Catch explícitos:

"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 concurrentemente y agregan resultados, un ajuste limpio 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 cualquier 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; la respuesta canónica cuando un flujo de trabajo abarca Lambdas, EC2, contenedores, sistemas locales 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 paralelas y puede iterar directamente sobre objetos en un bucket de S3 o filas en un archivo CSV/JSONL, con procesamiento por lotes automático, puntos de control y tolerancia a fallos. Para miles de objetos S3 semiestructurados, es la opción más eficiente operativamente: apúntelo a un prefijo, defina la tarea por elemento y Step Functions maneja la distribución, MaxConcurrency, reintentos y 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 contabilidad personalizada para la finalización, los reintentos y el ensamblaje de resultados.

Step Functions vs. EventBridge: Step Functions es adecuado cuando usted es el propietario de la secuencia y el resultado: estado, ramas, reintentos, aprobaciones. EventBridge es adecuado cuando los productores no saben ni les importa quién consume, y los consumidores se conectan de forma independiente.

Notificaciones de eventos de S3

Para el procesamiento casi en tiempo real de las cargas, configure las 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 de ráfaga anteriores. Medidas de seguridad:

• Establezca la concurrencia reservada para proteger una base de datos posterior.
• Habilite una DLQ o destino en caso de fallo para mensajes venenosos.
• Enrute los eventos de S3 a través de EventBridge cuando varios consumidores necesiten los mismos eventos. Las configuraciones directas de notificación de S3 tienen un número y una expresividad limitados; la distribución de EventBridge con transformadores de entrada por destino escala mucho mejor.

Streaming: Kinesis Data Streams vs. Firehose

Kinesis Data Streams (KDS) es un registro fragmentado, ordenado y reproducible con una retención de 24 horas a 365 días. El orden se conserva por fragmento, con clave de partición, lo que es fundamental para la agregación por dispositivo o por inquilino. Múltiples consumidores leen de forma independiente (distribución mejorada para un rendimiento aislado por consumidor). Elija KDS cuando necesite reproducción ordenada, múltiples consumidores independientes o un alto rendimiento por fragmento.

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

La canalización de análisis canónica casi en tiempo real es productores → KDS → Firehose → S3 (Parquet) → Athena/QuickSight, con enriquecimiento Lambda opcional en Firehose.

AWS Transfer Family para SFTP administrado

Cuando los socios requieren SFTP, FTPS o FTP hacia o desde S3 o EFS, AWS Transfer Family proporciona un punto final administrado y multi-AZ que habla el protocolo que los clientes ya usan. La autenticación admite usuarios administrados por el servicio, claves SSH o IdP 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 alcance de IAM restringen a cada usuario a un prefijo específico.

Construir esto usted mismo en EC2 requiere el endurecimiento de OpenSSH, parches, HA en AZs, rotación de claves y envío de registros, todo lo cual Transfer Family absorbe. Elíjalo siempre que el requisito sea “los socios nos envían archivos por SFTP” y desee los archivos en S3 con una sobrecarga operativa mínima.

Componiendo un patrón sin servidor canónico

Un diseño de ingesta de baja sobrecarga para métricas horarias por inquilino: los sensores POST a API Gateway (HTTP API, regional) → Lambda valida y publica en EventBridge → las reglas enrutan a una Lambda de escritura de DynamoDB (ID de inquilino como clave de partición, cubo de hora como clave de clasificación) y, en paralelo, a Firehose → S3 (Parquet) para análisis. Los nuevos consumidores se conectan como reglas adicionales de EventBridge sin tocar a los productores; el requisito de extensibilidad que solo SNS no satisfaría tan limpiamente. Cuando el rendimiento sostenido y el orden son importantes (conciliación de facturación, flujos de eventos financieros), reemplace EventBridge con Kinesis Data Streams y use la distribución mejorada para consumidores independientes.

Catálogo de trampas: Por qué fallan los patrones comunes erróneos

Instancia/gateway NAT para el tráfico de servicios de AWS desde Lambdas de subred privada. Las instancias NAT vinculan el rendimiento a una NIC de EC2 y son un SPOF; los gateways NAT facturan por GB. Ambos son innecesarios para destinos de servicios de AWS. Use los endpoints de gateway para S3/DynamoDB, los endpoints de interfaz para todo lo demás.

Ignorar los arranques en frío en las API críticas para la latencia. El modo bajo demanda solo aprovisiona contenedores cuando llega una solicitud, por lo que las ráfagas no cumplen con los SLA. Ajuste la concurrencia aprovisionada a la ráfaga p95; use SnapStart para cargas de trabajo Java sin SLA estrictos.

Lambda monolítica que recibe un evento completo y se ramifica internamente. Viola el principio de privilegio mínimo (un rol tiene todos los permisos de los servicios posteriores), acopla la cadencia de implementación, impide el ajuste por responsabilidad y escala toda la función a la tasa de la rama más ruidosa. Divida por responsabilidad; una 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. Solucione con RDS Proxy (pooling), concurrencia reservada (límite de tasa) o SQS (buffering).

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

URLs de funciones Lambda públicas con AuthType: NONE y sin validación de firma en la función. Computación anónima en la internet pública. Use AWS_IAM para llamadores de AWS o valide firmas para webhooks de terceros.

Autorizador Lambda personalizado cuando uno incorporado funciona. Agrega latencia, otra función parcheable y una ruta de código donde los errores de verificación de firma permiten el acceso silenciosamente. Prefiera la autorización de IAM para principales de AWS; el autorizador de Cognito para grupos de usuarios.

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

Falta AWS::Lambda::Permission para fuentes push (EventBridge, S3, SNS). Los eventos coinciden con las reglas, pero las invocaciones se deniegan silenciosamente. 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 reintenta: 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, las duplicaciones son inevitables.

← Contenedores y Orquestación · Todos los dominios · Almacenamiento y Ciclo de Vida de Datos →

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

Explorar Amazon →