Amazon DOP-C02: Arquiteturas Orientadas a Eventos e Automação — Guia de estudos

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Faz parte do AWS DevOps Engineer Professional DOP-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Arquiteturas orientadas a eventos desacoplam produtores de consumidores, enfatizam a comunicação assíncrona e tornam os sistemas resilientes a picos e falhas. Os princípios fundamentais são o acoplamento fraco por meio de eventos/mensagens, escalabilidade orientada pelo consumidor, handlers idempotentes e tratamento explícito de falhas e observabilidade. A AWS fornece blocos de construção para filas duráveis, pub/sub, barramentos de eventos, processamento de streams, orquestração e automação operacional. Dominar a interação entre Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Step Functions, mapeamentos de fontes de eventos do Lambda, AWS Systems Manager Automation e OpsCenter, além do Kinesis Data Streams e Firehose, permite que você construa automação e pipelines de dados escaláveis, tolerantes a falhas e auditáveis.

Mensageria e Ingestão: SQS, SNS, Kinesis e Firehose

O Amazon SQS fornece filas duráveis e escaláveis para desacoplamento. As filas Standard oferecem entrega pelo menos uma vez (at-least-once) e ordenação de melhor esforço (best-effort) com throughput virtualmente ilimitado; elas são adequadas para workers paralelos que toleram mensagens duplicadas e fora de ordem por meio de chaves de idempotência e escritas condicionais. As filas FIFO garantem a entrega ordenada por grupo de mensagens e semântica de processamento exatamente uma vez (exactly-once) com desduplicação (dentro de uma janela de cinco minutos). Elas garantem a ordem e o processamento único, mas comprometem o throughput absoluto: use múltiplos grupos de mensagens para paralelizar dentro do FIFO, ou habilite o FIFO de alto throughput para milhares de mensagens por segundo. Configure o timeout de visibilidade por fila ou por mensagem para exceder o tempo máximo de processamento; com consumidores Lambda, defina o timeout de visibilidade para pelo menos seis vezes o timeout da sua função para permitir novas tentativas (retries) antes que uma mensagem reapareça. Use long polling para reduzir recebimentos vazios. As filas de dead-letter (DLQs) capturam mensagens “poison” quando uma mensagem excede o maxReceiveCount; posteriormente, faça o redrive da DLQ para uma fila de origem para reprocessamento com correções. Monitore a métrica ApproximateAgeOfOldestMessage para detectar acúmulos (backlogs) e orientar alterações de concorrência/autoscaling.

O Amazon SNS fornece um serviço gerenciado de pub/sub de alto throughput. Publicadores enviam uma vez para um tópico; o SNS faz o fan-out para múltiplas assinaturas (SQS, Lambda, HTTP/S, e-mail, mobile). As políticas de filtro de assinatura (subscription filter policies) usam atributos de mensagem para rotear apenas notificações relevantes por assinante, reduzindo o custo e a carga downstream; expresse predicados como correspondência exata, prefixo, intervalos numéricos, “anything-but” (qualquer coisa exceto) e “exists” (existe). Use o SNS para fan-out, notificações desacopladas e push para dispositivos móveis. Habilite as novas tentativas (retries) e considere o uso de DLQs por assinatura para entregas que não puderem ser concluídas. Para requisitos de fan-out ordenado, os tópicos FIFO do SNS com assinaturas de filas SQS FIFO garantem a ordenação e a desduplicação.

O Kinesis Data Streams fornece streams ordenados de baixa latência com paralelismo em nível de shard para análise em tempo real e processamento de eventos. Produtores escrevem registros com chaves de partição (partition keys) nos shards; consumidores (Lambda, KCL, consumidores Enhanced Fan-Out, Kinesis Data Analytics) leem em ordem por shard com checkpointing. Use a capacidade on-demand para cargas imprevisíveis ou shards provisionados com resharding para throughput previsível. Ajuste as chaves de partição para balancear shards sobrecarregados (hot shards) e monitore a métrica IteratorAge para verificar o atraso do consumidor (consumer lag). O Enhanced Fan-Out oferece 2 MB/s de throughput dedicado por stream de consumidor com push de baixa latência sobre HTTP/2.

O Kinesis Data Firehose é um serviço de entrega totalmente gerenciado para ingestão em tempo quase real no S3, Amazon OpenSearch Service, Splunk ou endpoints HTTP, com transformação opcional via Lambda, buffering (por tamanho/tempo), compressão e criptografia. Ele pode receber dados diretamente de chamadas PutRecord/PutRecordBatch, do Kinesis Data Streams ou de assinaturas do CloudWatch Logs/Events. Use o Firehose quando precisar de entrega gerenciada com transformação e agrupamento em lotes (batching) e não quiser construir e operar o código do consumidor. O particionamento dinâmico (Dynamic partitioning) permite rotear registros para prefixos do S3 com base em chaves, para um processamento downstream eficiente.

Roteamento, Orquestração e Agendamento: EventBridge e Step Functions

O Amazon EventBridge é o barramento de eventos central para roteamento, governança e integração entre contas/domínios de eventos. Use o barramento padrão para eventos de serviços da AWS, barramentos personalizados para segmentar domínios e aplicar permissões, e barramentos de parceiros para integrações SaaS. As regras correspondem a eventos por meio de padrões baseados em conteúdo e têm como alvo mais de 200 serviços da AWS. Use transformadores de entrada (input transformers) para modelar payloads e o arquivamento/reprodução (archive/replay) para reprocessar eventos históricos durante a recuperação ou na integração de novos consumidores. Políticas de recursos (resource policies) permitem o roteamento de eventos entre contas para consolidar a governança em uma conta de plataforma. O EventBridge Pipes fornece fluxos ponto a ponto configuráveis de fontes de eventos (SQS, Kinesis, DynamoDB Streams, Apache Kafka autogerenciado no Amazon MSK e outros) para alvos, com filtragem, processamento em lote (batching), transformação e enriquecimento integrados por meio do Lambda ou Step Functions — ideal para quando você não quer gerenciar uma aplicação consumidora completa, mas precisa de uma mediação leve. O EventBridge Scheduler fornece agendamentos únicos (one-time) e cron para invocar alvos com uma função de execução (execution role), suporte a fuso horário e janelas de tempo flexíveis opcionais para reduzir o efeito “thundering herd” (manada trovejante).

O AWS Step Functions orquestra fluxos de trabalho (workflows) distribuídos definidos na Amazon States Language com estados para Task, Choice, Parallel, Map (incluindo Map distribuído), Wait, Pass, Succeed/Fail e padrões robustos de Retry/Catch. Integrações profundas com serviços eliminam a necessidade de “glue code” (código de cola) para chamar APIs da AWS, incluindo padrões síncronos (.sync) e de callback com tokens de tarefa (task tokens). Escolha Standard Workflows para orquestrações de longa duração e com uso intensivo de auditoria, com progressão de estado “exactly-once” (exatamente uma vez), duração de até um ano e preço por transição de estado; o histórico de execução é retido, com alta visibilidade e traces do X-Ray integrados. Escolha Express Workflows para orquestrações de alta taxa de transferência (throughput) e curta duração (segundos a minutos), onde você pode trocar a semântica de execução “at-least-once” (pelo menos uma vez) e o preço por requisição+duração por uma escala massiva; use para enriquecimentos de ingestão de streaming, roteadores de eventos e micro-orquestrações onde você pode tornar as tarefas idempotentes. Aplique padrões como saga com tarefas de compensação e tratamento de erros centralizado; externalize as tentativas (retries) e timeouts na máquina de estados para simplificar o código da tarefa.

Gatilhos de Computação e Contrapressão (Backpressure): Mapeamentos de Fontes de Eventos do Lambda

Os mapeamentos de fontes de eventos (ESMs) do Lambda conectam fontes baseadas em sondagem (poll-based) ao Lambda e controlam a concorrência, o processamento em lote (batching) e o tratamento de erros.

• SQS: O Lambda escala horizontalmente ao sondar (polling) a fila e invocar sua função com lotes (batches) de até 10 mensagens; janela de lote máxima de até 300 segundos. Com filas Standard, o escalonamento é agressivo com base na profundidade e na taxa de transferência de mensagens; com FIFO, o Lambda preserva a ordem por grupo de mensagens e processa um lote por grupo de cada vez. Configure a concorrência máxima no ESM para limitar a escala dos workers e proteger os sistemas downstream; combine com a concorrência reservada/provisionada para garantir a capacidade. Use a resposta de lote parcial (partial batch response) para confirmar (acknowledge) apenas os registros bem-sucedidos e reenfileirar os que falharam, evitando a reexecução do lote inteiro. Defina o tempo limite de visibilidade (visibility timeout) da fila para exceder o total de tentativas no pior cenário. DLQs e políticas de “redrive” isolam mensagens “poison” (venenosas).

• Kinesis Data Streams: Uma invocação simultânea do Lambda por shard, por padrão, garante a ordenação por shard. Aumente o ParallelizationFactor em até 10 para processar múltiplos lotes por shard simultaneamente, onde a ordenação entre subsequências é aceitável. O tamanho do lote (batch size) de até 10.000 registros (6 MB) e a janela de lote máxima de até 5 minutos permitem amortizar custos e aumentar a taxa de transferência (throughput). Use a bisseção em caso de erro da função (bisect on function error) para fazer uma busca binária por registros problemáticos dentro de um lote e use destinos em caso de falha (on-failure destinations) ou o número máximo de tentativas/idade do registro para descartar ou rotear registros não processáveis. Monitore o IteratorAge para detectar atraso no consumidor (consumer lag) e faça o resharding ou aumente a paralelização conforme necessário.

• DynamoDB Streams: Semelhante ao Kinesis em semântica; tamanho do lote de até 1.000 registros (6 MB) e modelo de shard por chave de partição. Os consumidores recebem mutações ordenadas no nível do item (INSERT, MODIFY, REMOVE). Aplique o mesmo tratamento de falhas (bisseção em erro, número máximo de tentativas, idade do registro) e filtragem. Use o tipo de visualização do stream (stream view type) que inclui os atributos que seu consumidor precisa (NewImage, OldImage, NewAndOldImages ou KeysOnly) para otimizar o tamanho do payload.

A filtragem de eventos nos ESMs reduz as invocações ao descartar eventos não relevantes no “poller” (sondador). Use a agregação em janelas de tempo fixas (tumbling window) em streams com o Lambda para agregar registros ao longo do tempo para padrões de processamento em mini-lotes.

Automação e Remediação de Operações: Systems Manager Automation e OpsCenter

O AWS Systems Manager Automation fornece runbooks (documentos do tipo Automation) escritos em JSON/YAML com etapas como aws:runCommand, aws:executeScript, aws:invokeLambda, aws:approve, aws:createStack e aws:executeAutomation. As automações aceitam parâmetros, emitem saídas, são versionadas com histórico de alterações e executam com uma AutomationAssumeRole dedicada para o princípio de privilégio mínimo e operações entre contas/Regiões. Controle a simultaneidade e os limites de erro em frotas, exija aprovações e janelas do Change Calendar e integre com notificações via SNS. Invoque automações de forma agendada, a partir de regras do EventBridge (para remediação quase em tempo real em eventos do AWS Health, CloudWatch ou de API), a partir de remediações do AWS Config para aplicar políticas (por exemplo, aplicando tags padrão a volumes EBS ou anexando um instance profile padrão a instâncias EC2) e a partir do OpsCenter.

O OpsCenter agrega problemas operacionais em OpsItems a partir de alarmes do CloudWatch, do AWS Config, de eventos do Health ou de fontes personalizadas. Cada OpsItem rastreia status, prioridade, desduplicação, recursos relacionados e links para runbooks. Associe runbooks de um clique para correções padrão e habilite a remediação automática conectando regras do EventBridge ou do Config para iniciar uma Automação específica quando um OpsItem é criado ou atualizado para uma condição correspondente (por exemplo, um security group permitindo 0.0.0.0/0 em SSH, conformidade de patches divergente ou backups com falha). Use o Systems Manager Explorer para visualizar a saúde da frota e os OpsItems abertos entre contas e Regiões. Essa combinação — OpsItems como registros duráveis e runbooks de Automação como correções codificadas — permite operações auditáveis e consistentes em escala.

Orientações de Design e Operacionais

Projete para idempotência em todos os consumidores, pois a entrega do tipo “pelo menos uma vez” (at-least-once) é comum. Prefira o fan-out orientado a eventos via SNS ou regras do EventBridge para reações paralelas de baixa latência; prefira o SQS para armazenar cargas de trabalho em buffer e proteger os produtores da lentidão dos consumidores; prefira o Kinesis quando for necessária uma ordenação estrita por shard e streams reproduzíveis (replayable) para análise de dados. Use o EventBridge Pipes para uma integração gerenciada e leve entre fontes e destinos quando um consumidor personalizado for excessivo (overkill), e o EventBridge Scheduler para gatilhos baseados em tempo sem a necessidade de manter uma infraestrutura de cron.

Dimensione corretamente os timeouts e as novas tentativas (retries). Para o SQS, o timeout de visibilidade deve exceder o tempo máximo de processamento mais as novas tentativas; para streams, limite as novas tentativas e defina o MaximumRecordAgeInSeconds para evitar a reprodução infinita de registros problemáticos. Use DLQs ou destinos “on-failure” (em caso de falha) sistematicamente e adicione dashboards e alarmes para as métricas SQS ApproximateAgeOfOldestMessage, Lambda ConcurrentExecutions/Throttles/Errors, IteratorAge, Step Functions ExecutionFailed/TimedOut e EventBridge FailedInvocations. Quando picos de tráfego são inevitáveis e os SLAs de latência são rigorosos, use a concorrência provisionada do Lambda para pré-aquecer a capacidade. Para governança, prefira o EventBridge com políticas de recursos para roteamento entre contas (cross-account) e arquivamento/reprodução (archive/replay) para dar suporte à evolução dos consumidores e à recuperação de incidentes.

Cenário de Problema Prático

A Shopify precisa modernizar o processamento de pedidos para eventos de vendas relâmpago (flash-sale), adicionando análise de dados em tempo real e remediação automatizada quando os serviços downstream ficam lentos ou falham.

1. Ingerir e distribuir (fan-out) eventos de pedido

• Use um tópico SNS FIFO para publicar eventos OrderPlaced a partir do checkout, garantindo notificações ordenadas e sem duplicatas por OrderId. As inscrições (subscriptions) incluem:
  • Fila SQS FIFO (Order-Workers) para o processamento do pedido (fulfillment), preservando a ordem.
  • Barramento de eventos personalizado do EventBridge (CommerceBus) para governança e roteamento adicional.
  • Stream de entrega do Kinesis Data Firehose para entrega quase em tempo real (near-real-time) de Pedidos ao S3 com compressão GZIP para análise de dados. Por que SNS FIFO: Ele fornece semântica de entrega ordenada e exatamente uma vez (exactly-once) com fan-out escalável para múltiplos assinantes, sem acoplar os publicadores (publishers) aos consumidores.

2. Armazenar em buffer e processar o fulfillment

• O Lambda consome da fila SQS FIFO por meio de um mapeamento de origem de evento (event source mapping) com tamanho de lote (batch size) de 10, resposta de lote parcial (partial batch response) habilitada e concorrência máxima limitada para proteger as APIs do armazém (warehouse) downstream. O timeout de visibilidade da fila é definido como seis vezes o timeout do Lambda para acomodar as novas tentativas. Uma DLQ captura mensagens “poison” (problemáticas) com maxReceiveCount=3; um fluxo de trabalho de “redrive” reprocessa posteriormente as mensagens corrigidas. Por que SQS FIFO + Lambda ESM: Impõe o sequenciamento por pedido, isola a lentidão downstream com o uso de buffer e oferece tratamento de erros de granularidade fina.

3. Orquestrar uma saga de múltiplos passos

• Um fluxo de trabalho (workflow) do tipo Standard do Step Functions orquestra a captura do pagamento, a reserva de inventário, a verificação de fraude e o agendamento do envio com novas tentativas, timeouts e tarefas de compensação (reembolso, reabastecimento) em caso de falha. A primeira Tarefa (Task) é acionada por um Lambda invocado a partir do consumidor SQS. Por que Standard: Progressão de estado de longa duração, auditável e exatamente uma vez (exactly-once) entre sistemas externos, com tratamento de erros robusto.

4. Rotear eventos de domínio para as capacidades de negócio

• O CommerceBus recebe eventos Order* via PutEvents dos serviços produtores e da inscrição SNS. Regras do EventBridge:
  • Correspondem a OrderPlaced para notificar o Marketing (Lambda) e criar um caso de suporte (integração com a API do AWS Support) quando clientes de alto valor fazem um pedido.
  • Encaminham OrderFailed para o barramento de eventos de uma conta de operações central usando uma política de recursos para governança entre contas. Por que EventBridge: Roteamento centralizado, filtragem, entrega entre contas e a capacidade de adicionar novos consumidores sem alterar os produtores.

5. Conectar (Pipe) o feed de um parceiro para enriquecimento

• O EventBridge Pipes conecta uma fila SQS Standard de um parceiro (SKUs com pedidos em espera) a um fluxo de trabalho Step Functions Express que enriquece os itens por meio de uma função Lambda e envia os resultados para uma fila SQS interna para reabastecimento. Por que Pipes + Express: Integração gerenciada de baixo overhead com enriquecimento leve, alta taxa de transferência (throughput) e baixo custo.

6. Análise de dados e busca em tempo real

• Um Kinesis Data Stream coleta eventos de clickstream e operacionais. O Lambda (consumidor com Enhanced Fan-Out) realiza a sessionalização, e o Kinesis Data Analytics agrega os KPIs. O Firehose entrega os pedidos transformados e os dados de análise para um data lake no S3 e para o Amazon OpenSearch Service com particionamento dinâmico por data/mercado para consultas eficientes. Por que Streams + Firehose: Processamento ordenado e de baixa latência para análise de dados, com entrega e transformação gerenciadas para armazenamento e busca.

7. Automação baseada em tempo

• O EventBridge Scheduler executa um cron a cada minuto para publicar InventorySnapshotRequested no CommerceBus, acionando um fluxo de trabalho Step Functions Express que compila snapshots de todos os armazéns para uma precisão de estoque quase em tempo real. Por que Scheduler: Cron nativo e resiliente sem infraestrutura personalizada.

8. Remediação e operações automatizadas

• Regras do AWS Config detectam SSH aberto ou ACLs públicas no S3 nas VPCs de fulfillment. Remediações gerenciadas invocam runbooks do Systems Manager Automation para corrigir o desvio (drift). Alarmes do CloudWatch nas métricas SQS ApproximateAgeOfOldestMessage e Lambda IteratorAge criam OpsItems no OpsCenter; runbooks associados escalam a concorrência provisionada em Lambdas específicos, aumentam a capacidade reservada do Step Functions ou ampliam temporariamente as janelas de lote (batch windows). Uma regra do EventBridge para eventos de manutenção do EC2 no AWS Health tem como alvo um documento do SSM Automation para reiniciar graciosamente as instâncias impactadas durante as janelas de manutenção. Por que OpsCenter + Automation: Rastreamento de problemas centralizado e auditável com remediações de um clique ou automáticas, com o mínimo de privilégios, que são executadas com segurança entre contas/Regiões.

Este design sustenta picos de vendas relâmpago através de buffer e fan-out, preserva invariantes de negócio via orquestração, entrega dados de análise em segundos e fecha o ciclo com remediação automatizada e orientada por políticas.

← Alta Disponibilidade · Todos os domínios · Armazenamento →

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

Navegar Amazon →