Amazon SOA-C02: Serverless e Integração de Aplicações — Guia de estudos

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

Faz parte do AWS SysOps Administrator Associate SOA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Serverless e integração de aplicações abrangem a execução de aplicações orientadas a eventos sem gerenciar servidores e a conexão de serviços de forma confiável. A importância operacional reside em gerenciar escala, latência, modos de falha e acesso de menor privilégio, mantendo os custos previsíveis. Este domínio foca no comportamento do Lambda (cold starts, concorrência), entrega confiável de eventos (EventBridge, SNS, SQS), controles de segurança (roles de execução e permissões) e observabilidade para fluxos assíncronos.

Aspectos operacionais e concorrência do AWS Lambda

O desempenho e a disponibilidade do Lambda dependem de cold starts, limites de concorrência e controles de throttling. Cold starts ocorrem quando o Lambda precisa inicializar um novo ambiente de execução; reduza o impacto usando concorrência provisionada (

undefined

) para caminhos críticos de latência, e prefira runtimes mais leves ou um trabalho de inicialização menor. Reserve e limite a concorrência com a concorrência reservada (

undefined

) para proteger serviços downstream e aplicar cotas por função; monitore as métricas ConcurrentExecutions e Throttles do CloudWatch.

Os modelos de retry e invocação diferem por modo: invocações síncronas (API Gateway, Invoke direto) retornam erros imediatamente; invocações assíncronas (EventBridge, SNS, notificações assíncronas do S3) usam a política de retry assíncrono do Lambda (duas novas tentativas com backoff) e podem usar DLQs ou destinos. Para mapeamentos de origem de eventos (SQS, Kinesis, DynamoDB streams), o poller do Lambda tenta novamente até que a mensagem expire ou a política de redrive da origem do evento acione uma dead-letter. Configure o timeout e a memória de forma conservadora (

undefined

) e defina o timeout de visibilidade do SQS > timeout da função (recomendado: visibilidade >= timeout da função * 2) para reduzir o processamento duplicado.

Arquiteturas orientadas a eventos com o EventBridge

O EventBridge fornece um barramento de eventos gerenciado com roteamento flexível, registro de esquemas, entrega entre contas e configurações de retry/DLQ. Use barramentos de eventos personalizados para separação de domínios e barramentos de eventos de parceiros para integrações SaaS; crie regras com padrões (

undefined

) e anexe alvos com configuração de dead-letter e retry (o JSON dos alvos suporta DeadLetterConfig e RetryPolicy). Use o registro de esquemas para descobrir e impor os formatos dos eventos; registre esquemas quando os produtores estiverem bem definidos, e use Code Bindings para gerar modelos tipados onde for útil.

Escolha o EventBridge quando você precisar de:

• Roteamento e filtragem complexos com padrões de eventos ricos ou isolamento entre contas/barramentos de eventos
• Suporte nativo para múltiplos alvos (Lambda, Step Functions, Kinesis, SQS, SNS)
• Descoberta e governança de esquemas entre equipes

Escolha SNS/SQS direto quando precisar de um fan-out mais simples ou semântica de fila garantida:

• SNS para fan-out para muitos assinantes e semântica de push
• SQS para processamento durável e baseado em pull com timeout de visibilidade e políticas de redrive

Mensageria com SNS e SQS (DLQs, timeout de visibilidade)

O SNS é um serviço pub/sub de push; o SQS é uma fila durável com semântica de pull. Para processamento de alta confiabilidade, prefira os padrões SNS -> SQS -> Lambda para desacoplar a ingestão do processamento e ganhar controle sobre retries e visibilidade. Configure a política de redrive do SQS (

undefined

) para mover mensagens para uma DLQ após o maxReceiveCount, e garanta que o timeout de visibilidade seja longo o suficiente para evitar uma nova entrega prematura (recomendado: visibilidade >= timeout da função * 2). Para necessidades FIFO, use SQS FIFO ou SNS FIFO com IDs de grupo de mensagens para preservar a ordem e IDs de desduplicação para evitar duplicatas.

Opções de tratamento de dead-letter e onde usá-las:

• Invocações assíncronas do Lambda: configure DeadLetterConfig ou Destinations (AsyncEventInvokeConfig) para enviar falhas para SQS/SNS ou invocar outra Lambda.
• SQS: configure a política de redrive para uma SQS DLQ para mensagens ‘poison’ e defina um maxReceiveCount apropriado.
• EventBridge: defina DeadLetterConfig e RetryPolicy nos alvos da regra para capturar eventos que não puderam ser entregues.

A idempotência é essencial: implemente handlers idempotentes usando escritas condicionais do DynamoDB (PutItem com ConditionExpression attribute_not_exists(pk)), tokens de idempotência armazenados com TTL ou a desduplicação do SQS FIFO para semântica exactly-once.

Permissões de função, roles e menor privilégio

Aplique o princípio de menor privilégio às roles de execução do Lambda e às políticas de recurso da função. Comece com a AWSLambdaBasicExecutionRole para os logs do CloudWatch e, em seguida, conceda ARNs de recursos explícitos para os serviços (ex: dynamodb:PutItem em arn:aws:dynamodb:region:acct:table/MyTable). Evite curingas como Resource: “*” quando ARNs específicos forem possíveis. Use políticas gerenciadas ou personalizadas com escopo por ação e recurso, e inclua condições (aws:SourceAccount, aws:SourceArn) ao adicionar permissões de invocação para serviços:

• Adicionar permissão de invocação para o EventBridge:

undefined

• Para o SNS: use a condição source-arn para limitar qual tópico pode invocar a função

Critérios de decisão:

• Use políticas baseadas em recursos da função para permitir invocações de serviços (EventBridge, SNS, CloudWatch Events)
• Use a role de execução do IAM para permissões de tempo de execução (DynamoDB, S3, Secrets Manager)
• Prefira permissões em nível de recurso e restrições condicionais para reduzir o raio de alcance (blast radius)

Observabilidade e solução de problemas para serverless

A observabilidade deve cobrir métricas, logs, traces e o status de entregas assíncronas. Métricas chave do CloudWatch: Invocations, Duration, Errors, Throttles, ConcurrentExecutions, IteratorAge (para gatilhos de stream e SQS). Para visibilidade de falhas assíncronas, monitore as métricas “AsyncEventInvoke” e configure Alarmes do CloudWatch em DeadLetterErrors e Throttles. Habilite o rastreamento com X-Ray (aws lambda update-function-configuration –function-name MyFn –tracing-config Mode=Active) para obter traces de ponta a ponta entre serviços e visualizar cold-starts, latências de serviços downstream e exceções.

Use logs JSON estruturados e consultas do CloudWatch Logs Insights para encontrar rapidamente padrões de erro; instrumente verificações de idempotência e registre IDs de correlação nos logs. Para rastreamento distribuído, propague os IDs de trace explicitamente nos payloads dos eventos para fluxos com EventBridge/SNS se o contexto automático for perdido. Para mapeamentos de fonte de eventos do SQS, monitore a métrica ApproximateAgeOfOldestMessage e configure alarmes caso ela aumente, indicando contrapressão (backpressure) ou throttling. Capture e alerte sobre a métrica Throttles do Lambda, e acompanhe os trade-offs de uso/custo da concorrência provisionada.

Armadilhas Comuns e Critérios de Decisão

• Não configurar DLQs ou depender apenas das tentativas padrão: configure DLQs ou Destinations para Lambdas assíncronos e redrive do SQS para filas a fim de capturar “poison messages” (mensagens venenosas) para inspeção manual.
• Timeout de visibilidade incorreto no SQS levando a processamento duplicado: defina o timeout de visibilidade como >= timeout da função * 2 e leve em conta as tentativas e chamadas downstream para evitar duplicatas.
• Roles de execução do Lambda superpermissivas: evite Resource: "*" e adicione condições de serviço/origem (aws:SourceArn, aws:SourceAccount) às políticas de invocação e de recurso.
• Ignorar limites de concorrência causando throttling: use concorrência reservada para limitar funções, concorrência provisionada para funções sensíveis à latência e monitore ConcurrentExecutions/Throttles.
• Falta de rastreamento através de fronteiras assíncronas: adicione IDs de correlação aos eventos e habilite o X-Ray ou propague cabeçalhos de trace para reconstruir os fluxos.
• Uso indevido do padrão SNS direto para Lambda para necessidades de durabilidade: prefira SNS->SQS->Lambda quando precisar de buffer durável, controle de visibilidade e um tratamento de DLQ mais fácil.

Problema Prático: Cenário de Caso de Uso

A AcmePayments recebe eventos de pagamento de alto volume via EventBridge e enfrenta throttling intermitente do Lambda e processamento duplicado durante os picos. Eles precisam de um processamento confiável, sem perda de dados e com uma carga limitada no DynamoDB downstream.

1. Crie um barramento de eventos (bus) personalizado no EventBridge e uma regra para corresponder aos eventos de pagamento; adicione uma fila SQS FIFO como um destino (target) durável com DeadLetterConfig e RetryPolicy na configuração do destino.
2. Configure o Lambda para consumir (poll) a fila SQS (mapeamento de fonte de evento) com um tamanho de lote (batch size) ajustado à capacidade downstream e um timeout de visibilidade definido como >= timeout da função * 2.
3. Reserve concorrência para o Lambda (aws lambda put-function-concurrency …) para limitar picos de escrita no DynamoDB; implemente concorrência provisionada para um pequeno pool se baixa latência for necessária.
4. Implemente idempotência usando escritas condicionais do DynamoDB com chave no payment-id e armazene os registros de idempotência com TTL para limpeza.
5. Habilite o rastreamento com X-Ray e logs estruturados com um ID de correlação no evento para rastrear o processamento; configure alarmes do CloudWatch nas métricas ApproximateAgeOfOldestMessage, Throttles e de DLQ.

Justificativa: O desacoplamento do EventBridge para o SQS fornece buffer durável e semântica de novas tentativas; a concorrência reservada protege o DynamoDB downstream contra picos de carga, a idempotência previne duplicatas, e o rastreamento/alarmes fornecem visibilidade operacional sobre os modos de falha.

← Bancos de Dados e Cache · Todos os domínios · Gerenciamento de Custos e Marcação de Recursos →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →