Amazon SOA-C02: Serverless e Integración de Aplicaciones — Guía de estudio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Forma parte de la AWS SysOps Administrator Associate SOA-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

La computación sin servidor y la integración de aplicaciones abarcan la ejecución de aplicaciones orientadas a eventos sin gestionar servidores y la conexión fiable de servicios. La importancia operativa radica en gestionar la escala, la latencia, los modos de fallo y el acceso con privilegios mínimos, manteniendo al mismo tiempo los costos predecibles. Este dominio se centra en el comportamiento de Lambda (arranques en frío, concurrencia), la entrega fiable de eventos (EventBridge, SNS, SQS), los controles de seguridad (roles de ejecución y permisos) y la observabilidad para flujos asíncronos.

Aspectos operativos y concurrencia de AWS Lambda

El rendimiento y la disponibilidad de Lambda dependen de los arranques en frío, los límites de concurrencia y los controles de throttling (limitación de velocidad). Los arranques en frío ocurren cuando Lambda debe inicializar un nuevo entorno de ejecución; reduzca el impacto utilizando concurrencia aprovisionada (aws lambda put-provisioned-concurrency-config --function-name MyFn --qualifier 1 --provisioned-concurrent-executions 10) para rutas críticas en cuanto a latencia, y prefiera runtimes más ligeros o un trabajo de inicialización menor. Reserve y limite la concurrencia con la concurrencia reservada (aws lambda put-function-concurrency --function-name MyFn --reserved-concurrent-executions 50) para proteger los servicios dependientes (downstream) y aplicar cuotas por función; supervise las métricas de CloudWatch ConcurrentExecutions y Throttles.

Los modelos de reintento e invocación difieren según el modo: las invocaciones síncronas (API Gateway, Invoke directo) devuelven errores inmediatamente; las invocaciones asíncronas (EventBridge, SNS, notificaciones asíncronas de S3) utilizan la política de reintentos asíncronos de Lambda (dos reintentos con backoff) y pueden usar DLQs o destinos. Para los mapeos de origen de eventos (SQS, Kinesis, DynamoDB streams), el poller de Lambda reintenta hasta que el mensaje expira o la política de reenvío (redrive policy) del origen de eventos activa una carta muerta (dead-letter). Configure el tiempo de espera (timeout) y la memoria de forma conservadora (aws lambda update-function-configuration --function-name MyFn --timeout 30 --memory-size 1024) y establezca el tiempo de espera de visibilidad de SQS > tiempo de espera de la función (se recomienda visibilidad >= tiempo de espera de la función * 2) para reducir el procesamiento duplicado.

Arquitecturas orientadas a eventos con EventBridge

EventBridge proporciona un bus de eventos gestionado con enrutamiento flexible, registro de esquemas, entrega entre cuentas y configuraciones de reintento/DLQ. Utilice buses de eventos personalizados para la separación de dominios y buses de eventos de socios para integraciones SaaS; cree reglas con patrones (aws events put-rule --name orderEvents --event-pattern file://order-pattern.json --event-bus-name customBus) y adjunte destinos (targets) con configuración de carta muerta (dead-letter) y reintentos (el JSON de los destinos admite DeadLetterConfig y RetryPolicy). Utilice el registro de esquemas para descubrir y aplicar las formas de los eventos; registre esquemas cuando los productores estén bien definidos y use Code Bindings para generar modelos tipados donde sea útil.

Elija EventBridge cuando necesite:

• Enrutamiento y filtrado complejos con patrones de eventos enriquecidos o aislamiento entre cuentas/buses de eventos
• Soporte nativo para múltiples destinos (targets) (Lambda, Step Functions, Kinesis, SQS, SNS)
• Descubrimiento de esquemas y gobernanza entre equipos

Elija SNS/SQS directamente cuando necesite un fan-out más simple o semántica de cola garantizada:

• SNS para fan-out a muchos suscriptores y semántica push
• SQS para procesamiento duradero basado en pull con tiempo de espera de visibilidad y políticas de reenvío (redrive policies)

Mensajería con SNS y SQS (DLQs, tiempo de espera de visibilidad)

SNS es un servicio pub/sub de tipo push; SQS es una cola duradera con semántica pull. Para un procesamiento de alta fiabilidad, prefiera los patrones SNS -> SQS -> Lambda para desacoplar la ingesta del procesamiento y obtener control sobre los reintentos y la visibilidad. Configure la política de reenvío (redrive policy) de SQS (aws sqs set-queue-attributes --queue-url URL --attributes file://redrive.json) para mover mensajes a una DLQ después de maxReceiveCount, y asegúrese de que el tiempo de espera de visibilidad sea lo suficientemente largo para evitar una nueva entrega prematura (se recomienda visibilidad >= tiempo de espera de la función * 2). Para necesidades FIFO, use SQS FIFO o SNS FIFO con ID de grupo de mensajes para preservar el orden y ID de deduplicación para evitar duplicados.

Opciones de manejo de cartas muertas (dead-letter) y dónde usarlas:

• Invocaciones asíncronas de Lambda: configure DeadLetterConfig o Destinos (AsyncEventInvokeConfig) para enviar fallos a SQS/SNS o invocar otra Lambda.
• SQS: configure la política de reenvío (redrive policy) a una DLQ de SQS para mensajes corruptos (poison messages) y establezca un maxReceiveCount apropiado.
• EventBridge: establezca DeadLetterConfig y RetryPolicy en los destinos (targets) de la regla para capturar eventos que no se pueden entregar.

La idempotencia es esencial: implemente manejadores (handlers) idempotentes usando escrituras condicionales de DynamoDB (PutItem con ConditionExpression attribute_not_exists(pk)), tokens de idempotencia almacenados con TTL, o la deduplicación de SQS FIFO para una semántica de procesamiento único (exactly-once).

Permisos de función, roles y privilegio mínimo

Aplique el principio de privilegio mínimo a los roles de ejecución de Lambda y a las políticas de recursos de la función. Comience con AWSLambdaBasicExecutionRole para los logs de CloudWatch, luego otorgue ARNs de recursos explícitos para los servicios (p. ej., dynamodb:PutItem en arn:aws:dynamodb:region:acct:table/MyTable). Evite comodines como Resource: "*" cuando sea posible usar ARNs específicos. Use políticas gestionadas o personalizadas acotadas por acción y recurso, e incluya condiciones (aws:SourceAccount, aws:SourceArn) al agregar permisos de invocación para los servicios:

• Añadir permiso de invocación para EventBridge: aws lambda add-permission --function-name MyFn --principal events.amazonaws.com --statement-id ev1 --action lambda:InvokeFunction --source-arn arn:aws:events:region:acct:rule/MyRule
• Para SNS: use la condición source-arn para limitar qué topic puede invocar la función

Criterios de decisión:

• Use políticas basadas en recursos de la función para permitir invocaciones de servicios (EventBridge, SNS, CloudWatch Events)
• Use el rol de ejecución de IAM para permisos en tiempo de ejecución (runtime) (DynamoDB, S3, Secrets Manager)
• Prefiera permisos a nivel de recurso y restricciones condicionales para reducir el radio de impacto (blast radius)

Observabilidad y resolución de problemas para serverless

La observabilidad debe cubrir métricas, logs, trazas y el estado de la entrega asíncrona. Métricas clave de CloudWatch: Invocations, Duration, Errors, Throttles, ConcurrentExecutions, IteratorAge (para disparadores de streams y SQS). Para la visibilidad de fallos asíncronos, monitoriza las métricas “AsyncEventInvoke” y configura alarmas de CloudWatch sobre DeadLetterErrors y Throttles. Habilita el trazado con X-Ray (aws lambda update-function-configuration –function-name MyFn –tracing-config Mode=Active) para obtener trazas de extremo a extremo a través de los servicios y visualizar los arranques en frío (cold starts), las latencias de los servicios posteriores y las excepciones.

Usa logs estructurados en JSON y consultas de CloudWatch Logs Insights para encontrar rápidamente patrones de error; instrumenta comprobaciones de idempotencia y registra los IDs de correlación en los logs. Para el trazado distribuido, propaga los IDs de traza explícitamente en los payloads de los eventos para flujos de EventBridge/SNS si se pierde el contexto automático. Para los mapeos de origen de eventos de SQS, monitoriza ApproximateAgeOfOldestMessage y establece alarmas si crece, lo que indica contrapresión o throttling. Captura y alerta sobre la métrica Throttles de Lambda, y haz un seguimiento de los compromisos entre el uso y el coste de la concurrencia provisionada.

Errores Comunes y Criterios de Decisión

• No configurar DLQs o depender solo de los reintentos por defecto: configura DLQs o Destinos para Lambdas asíncronas y políticas de reenvío (redrive) de SQS para las colas, con el fin de capturar mensajes envenenados para su inspección manual.
• Tiempo de espera de visibilidad (visibility timeout) incorrecto en SQS que lleva a procesamiento duplicado: establece el tiempo de espera de visibilidad >= tiempo de espera de la función * 2 y ten en cuenta los reintentos y las llamadas a servicios posteriores para evitar duplicados.
• Roles de ejecución de Lambda demasiado permisivos: evita Resource: "*" y añade condiciones de servicio/origen (aws:SourceArn, aws:SourceAccount) a las políticas de invocación y de recursos.
• Ignorar los límites de concurrencia, causando throttling: usa concurrencia reservada para limitar funciones, concurrencia provisionada para funciones sensibles a la latencia, y monitoriza ConcurrentExecutions/Throttles.
• Falta de trazado a través de los límites asíncronos: añade IDs de correlación a los eventos y habilita X-Ray o propaga las cabeceras de traza para reconstruir los flujos.
• Usar incorrectamente la integración directa de SNS a Lambda para necesidades de durabilidad: prefiere SNS->SQS->Lambda cuando necesites un búfer duradero, control de visibilidad y un manejo más fácil de las DLQ.

Problema Práctico: Escenario de Caso de Uso

AcmePayments recibe eventos de pago de alto volumen a través de EventBridge y experimenta throttling intermitente en Lambda y procesamiento duplicado durante los picos de carga. Necesitan un procesamiento fiable, sin pérdida de datos y una carga acotada en el servicio posterior, DynamoDB.

1. Crea un bus de eventos personalizado en EventBridge y una regla para que coincida con los eventos de pago; añade una cola SQS FIFO como destino duradero con DeadLetterConfig y RetryPolicy en la configuración del destino.
2. Configura Lambda para que consulte la cola SQS (mapeo de origen de eventos) con un tamaño de lote (batch size) ajustado a la capacidad del servicio posterior y un tiempo de espera de visibilidad establecido en >= tiempo de espera de la función * 2.
3. Reserva concurrencia para la función Lambda (aws lambda put-function-concurrency …) para limitar las ráfagas de escritura en DynamoDB; implementa concurrencia provisionada para un pequeño grupo si se requiere baja latencia.
4. Implementa la idempotencia usando escrituras condicionales en DynamoDB basadas en el payment-id y almacena registros de idempotencia con un TTL para su limpieza.
5. Habilita el trazado con X-Ray y los logs estructurados con un ID de correlación en el evento para trazar el procesamiento; establece alarmas de CloudWatch sobre las métricas ApproximateAgeOfOldestMessage, Throttles y de la DLQ.

Justificación: Desacoplar EventBridge a SQS proporciona un búfer duradero y semántica de reintentos; la concurrencia reservada protege a DynamoDB de ráfagas, la idempotencia previene duplicados, y el trazado/alarmas proporcionan visibilidad operativa sobre los modos de fallo.

← Bases de Datos y Almacenamiento en Caché · Todos los dominios · Gestión de Costos y Etiquetado de Recursos →

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

Explorar Amazon →