Amazon SAA-C03: Integração de Aplicações, Mensageria e Streaming — Guia de estudos

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Faz parte do AWS SAA-C03 — Guia de estudos completo. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Amazon SQS: Desacoplamento, Ordenação e Semântica de Entrega

O Amazon SQS é uma fila de mensagens totalmente gerenciada e baseada em pull, cujo principal papel arquitetural é desacoplar produtores de consumidores. Uma cadeia de chamadas síncronas vincula a latência e a disponibilidade do produtor a cada dependência downstream; inserir uma fila SQS converte isso em uma transferência assíncrona. Os produtores enfileiram na taxa em que o tráfego chega, e os consumidores desenfileiram na taxa que conseguem processar com segurança. Esta é a solução canônica para picos de escrita que, de outra forma, sobrecarregariam uma instância RDS — a fila absorve o pico, e uma frota limitada de consumidores a esvazia com uma concorrência controlada, mantendo o número de conexões com o banco de dados sob controle.

Existem dois tipos de fila, e a escolha rege tanto a taxa de transferência (throughput) quanto as garantias de entrega.

Filas Standard entregam pelo menos uma vez (at-least-once) com ordenação de melhor esforço (best-effort). Duplicatas podem aparecer quando um consumidor falha em apagar uma mensagem antes que o tempo limite de visibilidade (visibility timeout) expire, ou quando o backend distribuído reproduz uma mensagem entre seus shards. Mesmo que você nunca veja uma duplicata em testes, o serviço é arquiteturalmente projetado para permitir reentregas, especialmente durante um failover de broker. Assumir que filas standard “geralmente” entregarão apenas uma vez é um defeito de design, não um risco operacional — é garantido que duplicatas ocorrerão eventualmente em grande escala. A lógica do consumidor deve, portanto, ser idempotente: rastrear um MessageId ou uma chave de negócio no DynamoDB com uma escrita condicional, usar uma chave de idempotência em chamadas de API downstream ou confiar na semântica de upsert.

Filas FIFO fornecem ordenação estrita dentro de um MessageGroupId e processamento exatamente uma vez (exactly-once) por meio de um MessageDeduplicationId (explícito ou um SHA-256 do corpo da mensagem) que suprime duplicatas por uma janela de 5 minutos. O MessageGroupId é o conceito central: todas as mensagens que compartilham um ID de grupo são entregues estritamente em ordem para um único consumidor por vez, enquanto diferentes IDs de grupo podem ser processados em paralelo. Para um sistema de processamento de pedidos onde os eventos de cada cliente devem ser sequenciais, mas clientes diferentes são independentes, use MessageGroupId = customerId. Usar um único ID de grupo para tudo serializa toda a carga de trabalho e destrói a taxa de transferência. IDs de desduplicação são o primitivo correto para evitar a criação de pedidos duplicados quando um usuário reenvia um checkout que travou: o cliente gera um token de idempotência determinístico (um UUID vinculado à sessão de checkout) e o SQS descarta quaisquer envios duplicados que cheguem dentro da janela.

PaymentsQueue:
  Type: AWS::SQS::Queue
  Properties:
    QueueName: payments.fifo
    FifoQueue: true
    ContentBasedDeduplication: true
    DeduplicationScope: messageGroup
    FifoThroughputLimit: perMessageGroupId
    VisibilityTimeout: 60
    RedrivePolicy:
      deadLetterTargetArn: !GetAtt PaymentsDLQ.Arn
      maxReceiveCount: 5

Selecionar o tipo standard quando o requisito especifica “ordenação” ou “sem duplicatas” é o erro clássico. Nenhuma lógica de aplicação pode restaurar uma ordenação que a fila nunca preservou, porque mensagens de diferentes hosts do backend chegam de forma intercalada. Escolha FIFO sempre que a carga de trabalho exigir ordenação (registros de transações, transições de máquinas de estado) ou semântica de processamento exatamente uma vez (captura de pagamento, decremento de inventário).

Tempo Limite de Visibilidade, Mensagens “Poison” e Limites de Payload

Quando um consumidor recebe uma mensagem, o SQS a torna invisível para outros consumidores durante o tempo limite de visibilidade (visibility timeout) (padrão de 30 segundos, máximo de 12 horas). Se o consumidor apagar a mensagem antes que o tempo limite expire, ela é removida; caso contrário — porque o consumidor travou ou o processamento simplesmente demorou demais — a mensagem reaparece e é entregue novamente. Definir o tempo limite de visibilidade menor que o tempo de processamento real é uma das principais causas de processamento duplicado: uma função Lambda que leva 45 segundos para processar uma mensagem de uma fila com o tempo limite padrão de 30 segundos reprocessará cada mensagem pelo menos duas vezes. Defina o tempo limite para pelo menos o tempo de processamento p99 (a orientação da AWS para filas processadas por Lambda é de pelo menos 6 vezes o timeout da função), e para tarefas de duração imprevisível, estenda o tempo limite dinamicamente:

sqs.change_message_visibility(
    QueueUrl=queue_url,
    ReceiptHandle=handle,
    VisibilityTimeout=300  # extend by 5 minutes
)

Filas de mensagens mortas (DLQs) capturam mensagens “poison-pill”. Uma RedrivePolicy na fila de origem especifica um maxReceiveCount (normalmente de 3 a 5); uma vez excedido, o SQS move a mensagem para a DLQ para inspeção offline. A DLQ deve ser do mesmo tipo da fila de origem (FIFO ↔ FIFO). Sem uma DLQ, mensagens malformadas entram em loop indefinidamente, e em filas FIFO isso é especialmente prejudicial — a ordenação impede que mensagens subsequentes no mesmo grupo sejam entregues até que a mensagem problemática seja tratada, de modo que uma única mensagem ruim paralisa um grupo inteiro.

As mensagens do SQS são limitadas a 256 KB. Para payloads maiores — por exemplo, um job que carrega um documento renderizado — use a SQS Extended Client Library, que escreve o payload no S3 e enfileira apenas uma referência ao bucket/chave. A biblioteca do consumidor busca o conteúdo de forma transparente ao receber a mensagem. Não divida payloads em várias mensagens (você perde atomicidade e ordenação) e não codifique um blob de 2 MB em base64 na esperança de que ele caiba.

Autoscaling Orientado por Fila

Para uma frota de consumidores em EC2 ou ECS por trás de uma fila SQS, o sinal correto para scaling não é o uso de CPU — é o backlog da fila. O uso de CPU fica atrás da taxa de chegada e interpreta erroneamente um consumidor saturado como “ocupado, mas dando conta”. A métrica de scaling canônica é ApproximateNumberOfMessagesVisible, mas escalar diretamente com base no tamanho bruto da fila é impreciso. A abordagem recomendada é a métrica personalizada de backlog por instância:

backlogPerInstance = ApproximateNumberOfMessagesVisible / RunningInstances

Publique isso no CloudWatch e use para guiar uma política de target tracking em um Auto Scaling group ou serviço ECS, para que cada worker mantenha um backlog limitado (por exemplo, 10 mensagens). Isso resulta em um scale-out suave durante picos e evita oscilações quando o tamanho da fila é pequeno, mas os consumidores já estão saturados. Para o scale-in, combine com a métrica ApproximateAgeOfOldestMessage para evitar a remoção de capacidade enquanto mensagens antigas ainda permanecem na fila.

Amazon SNS: Distribuição Fan-Out, Filtragem e Entrega Entre Contas

O SNS é um serviço de publicação/inscrição (publish/subscribe) baseado em push. Publicadores (publishers) escrevem em um tópico; o SNS envia (faz push) para cada inscrição (subscription): filas SQS, funções Lambda, endpoints HTTP(S), e-mail, SMS, Kinesis Data Firehose ou push para dispositivos móveis. O padrão de durabilidade dominante é o fan-out de SNS → SQS: um tópico com várias filas SQS inscritas, para que cada serviço downstream tenha seu próprio buffer durável, política de nova tentativa (retry policy) e DLQ, enquanto o publicador conhece apenas o tópico. Se um serviço consumidor ficar fora do ar por horas, sua fila acumula mensagens e as processa na recuperação — o SNS por si só não possui esse buffer e esgotará sua política de nova tentativa.

Producer ──▶ SNS topic ──┬──▶ SQS Queue A ──▶ Service A
                         ├──▶ SQS Queue B ──▶ Service B
                         └──▶ SQS Queue C ──▶ Service C

A filtragem de mensagens permite que cada inscrição declare uma política de filtro (filter policy) JSON para que o SNS entregue apenas as mensagens correspondentes, evitando o antipadrão em que cada consumidor recebe todas as mensagens e as filtra do lado do cliente (client-side):

{
  "eventType": ["order_placed", "order_cancelled"],
  "region": ["us-east-1", "us-west-2"]
}

Duas propriedades de comportamento são importantes. Primeiro, tópicos SNS padrão não garantem a ordenação entre as mensagens — temporizadores de nova tentativa por assinante e caminhos de rede independentes tornam a reordenação rotineira. Se a ordem for importante, use um tópico SNS FIFO com filas SQS FIFO inscritas; o ID do grupo de mensagens (message group ID) se propaga de ponta a ponta. Caso contrário, os assinantes devem ser idempotentes e tolerantes à reordenação. Segundo, inscrições HTTP(S) tentam novamente de acordo com uma política de entrega (delivery policy) (padrão: três novas tentativas imediatas, depois um backoff exponencial de até uma hora, e então o descarte). Os assinantes devem responder com 2xx em até 15 segundos, validar a assinatura x-amz-sns-message-type e — para endpoints não confiáveis — sempre ter uma DLQ no SNS (redirecionada para o SQS) para que as mensagens não entregues sejam capturadas em vez de descartadas silenciosamente.

A invocação entre contas é uma armadilha frequente. Quando a Conta A publica em um tópico que faz fan-out para uma função Lambda na Conta B, duas políticas são necessárias: a política do tópico SNS (ou a direção da inscrição) deve permitir a inscrição, e a política baseada em recursos (resource-based policy) do Lambda deve permitir lambda:InvokeFunction de sns.amazonaws.com com uma condição SourceArn que corresponda ao tópico. A ausência da política de recursos do Lambda é o modo de falha mais comum — a inscrição parece saudável, mas as invocações são rejeitadas com 403. Se o tópico for criptografado com uma chave KMS gerenciada pelo cliente (customer-managed key), a política da chave (key policy) também deve conceder kms:Decrypt e kms:GenerateDataKey para o principal (principal) que está publicando e para sns.amazonaws.com.

{
  "Effect": "Allow",
  "Principal": {"Service": "sns.amazonaws.com"},
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-1:222222222222:function:ProcessOrder",
  "Condition": {"ArnLike": {"AWS:SourceArn": "arn:aws:sns:us-east-1:111111111111:orders"}}
}

Amazon EventBridge: Barramentos de Eventos Roteados

O EventBridge (anteriormente CloudWatch Events) estende o pub/sub com roteamento baseado em conteúdo, descoberta de esquemas (schema discovery), fontes de eventos de parceiros SaaS e arquivamento/reprodução (archive/replay). Os eventos fluem através de barramentos de eventos (padrão, personalizado ou de parceiro) e são comparados com regras (rules) cujos padrões de evento (event patterns) filtram pela estrutura JSON. As regras podem transformar os payloads por meio de caminhos de entrada (input paths) e modelos de entrada (input templates), anexar destinos de dead-letter e entregar para mais de 20 destinos nativos, incluindo Lambda, Step Functions, tarefas ECS, SQS, SNS, Kinesis e destinos de API.

{
  "source": ["com.acme.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": {"amount": [{"numeric": [">", 500]}]}
}

A distinção do SNS é arquitetônica. O SNS é otimizado para broadcast de alta taxa de transferência (high-throughput) para assinantes homogêneos com filtragem de atributos simples e menor latência. O EventBridge é otimizado para arquiteturas heterogêneas orientadas a eventos: muitos produtores emitem esquemas de eventos diferentes, e os consumidores se inscrevem por padrão (pattern) em vez de por tópico. Para um monólito sendo decomposto em microsserviços — especialmente quando os produtores incluem parceiros SaaS ou serviços da AWS (Config, GuardDuty, CodePipeline, CloudTrail) que emitem eventos nativamente — o EventBridge é geralmente a escolha correta. Para fan-out de volume extremamente alto e baixa latência para assinantes idênticos, o SNS ainda é a melhor opção, porque o EventBridge tem uma latência por evento um pouco maior e um teto de taxa de transferência padrão mais baixo.

Amazon MQ: Mensageria com Broker para Protocolos Existentes

O Amazon MQ é um broker gerenciado que executa o ActiveMQ ou o RabbitMQ. Ele existe para migrar cargas de trabalho on-premises que dependem de AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, OpenWire ou JMS sem reescrever a aplicação. Se um sistema de pagamento usa um broker JMS de terceiros com semântica transacional de entrega única (exactly-once), migrá-lo (lift) para o Amazon MQ preserva o protocolo de comunicação (wire protocol) e as garantias de entrega, eliminando o gerenciamento da infraestrutura. Escolha SQS/SNS/EventBridge para novos projetos nativos da AWS (greenfield); escolha o Amazon MQ apenas quando a compatibilidade de protocolo for a restrição.

Kinesis Data Streams

Kinesis Data Streams (KDS) é um log durável, ordenado e particionado para ingestão de streaming de alta taxa de transferência (high-throughput) — clickstreams, telemetria de IoT, agregação de logs. Os registros são colocados em shards pela PartitionKey; a ordenação é garantida dentro de um shard, não em todo o stream. Cada shard suporta 1 MB/s ou 1.000 registros/s para escrita e 2 MB/s para leitura (ou mais com o Enhanced Fan-Out). Os registros são retidos por 24 horas por padrão, extensível para 365 dias, para que múltiplos consumidores independentes possam reproduzir o mesmo histórico — algo que o SQS não pode fazer, pois o SQS exclui após o ack (confirmação).

O modo sob demanda (On-demand) elimina os cálculos de shards, escalando automaticamente até 200 MiB/s de escrita por stream, ideal para tráfego imprevisível. O modo provisionado é mais barato em estado estável (steady state), onde a capacidade é conhecida.

Escolha o KDS em vez do SQS FIFO quando a carga de trabalho exigir ingestão ordenada e reproduzível (replayable) com taxas de transferência que o FIFO não consegue atender (o FIFO atinge seu limite bem abaixo dos milhões de registros/segundo que o KDS suporta), quando múltiplos consumidores independentes precisam ler o mesmo stream, ou quando a frase “preservar a ordem original durante todo o processamento” é combinada com alto volume.

Kinesis Data Firehose

O Kinesis Data Firehose é um serviço de entrega totalmente gerenciado. Ele lê de um stream Kinesis ou por PUT direto, armazena em buffer por tamanho (1–128 MB) ou tempo (60–900 segundos, o que ocorrer primeiro), opcionalmente invoca uma função Lambda para transformação por registro (limpeza de PII, normalização de formato), pode converter JSON para Parquet ou ORC dinamicamente usando um esquema do Glue, criptografa com o KMS e entrega para o S3, Redshift, OpenSearch ou Splunk. Ele não tem shards, nem consumidores para executar, e sua cobrança é por GB.

O padrão canônico para ingestão escalável em um data lake combina o Data Streams (on-demand) como o buffer durável com o Firehose para entrega no S3:

Producers → Kinesis Data Streams (on-demand) → Firehose (60s buffer, Parquet) → S3 → Athena/Glue

Para ingerir milhões de eventos de dispositivos móveis, criptografá-los e armazená-los no S3 como Parquet, a resposta correta é o Firehose com conversão para Parquet e uma chave KMS — e não o KDS mais um consumidor personalizado mais um gravador Parquet escrito manualmente, o que representa drasticamente mais código e infraestrutura. O Firehose é quase em tempo real e não suporta replay do lado do consumidor; quando o replay é necessário, mantenha o KDS no caminho.

O Kinesis Data Analytics (agora Managed Service for Apache Flink) executa trabalhos SQL ou Flink em um stream para agregações em janela.

Integração com Lambda e Semântica de Tentativas

O Lambda se integra a esses serviços com comportamentos de tentativa materialmente diferentes:

Para o SQS, mantenha o tempo limite da função Lambda ≤ tempo limite de visibilidade da fila, e defina o tempo limite de visibilidade para pelo menos 6× o tempo limite da função. Para o Kinesis, habilite BisectBatchOnFunctionError e configure um destino OnFailure (SQS ou SNS) para que um único registro “poison” não paralise o shard inteiro indefinidamente.

Tabela de Decisão de Seleção

← Analytics · Todos os domínios · Segurança →

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

Navegar Amazon →