AWS na Prática · 07 — Observabilidade

Logs, métricas, alarmes e tracing para enxergar o sistema rodando.

Sobre este módulo

O sistema está construído. Falta a parte que separa um projeto de estudo de algo que dá pra confiar: enxergar o que está acontecendo em tempo real. CloudWatch Logs, métricas, alarmes, X-Ray, e o encerramento do curso com próximos passos para continuar evoluindo.

Nível: Intermediário · Duração estimada: 3-4 horas

Sumário

1. Por que observabilidade importa
2. CloudWatch: o sistema nervoso da AWS
3. CloudWatch Logs
4. Logs estruturados em JSON
5. Métricas: as duas categorias
6. Métricas customizadas via EMF
7. Alarmes que importam
8. Dashboards
9. X-Ray: tracing distribuído
10. Custos de observabilidade
11. Destruindo a infraestrutura
12. Exercícios de fixação
13. Encerramento e próximos passos

01. Por que observabilidade importa

Você terminou o módulo 06 com várias Lambdas, microserviços no Beanstalk, filas SQS, tópicos SNS e tabelas DynamoDB. Tudo isso conversando entre si. Mas como você sabe que está funcionando? E quando alguma coisa quebra — porque vai quebrar — como você descobre onde?

A diferença entre logging e observabilidade

Logging é registrar eventos. Você joga uma string num arquivo (ou num CloudWatch Log) e segue a vida. É necessário, mas insuficiente — se você precisa saber a latência média da sua API por endpoint nas últimas 24 horas, logs sozinhos não respondem isso bem.

Observabilidade é a capacidade de fazer perguntas novas ao sistema sem precisar mudar o código. Você instrumenta o sistema com três tipos de sinal — logs, métricas e traces — e depois usa ferramentas para correlacionar esses sinais e investigar problemas que você ainda não sabia que existiam.

Os três pilares

• Logs — Registros textuais ou estruturados de eventos. Bons para entender o que aconteceu em uma execução específica. Volume alto, custo de armazenamento.
• Métricas — Números agregados ao longo do tempo (latência, taxa de erro, uso de CPU). Bons para responder “como o sistema está se comportando?”. Baixo volume, baratos.
• Traces — Visão da jornada de uma requisição passando por vários serviços. Bons para responder “onde, exatamente, está o gargalo?”. Volume médio, custo médio.

Na AWS, esses três pilares são oferecidos respectivamente por CloudWatch Logs, CloudWatch Metrics e X-Ray — todos integrados ao console e cobráveis sob demanda.

Por que não basta olhar o console

Uma armadilha comum: confiar no console da AWS para diagnosticar problemas. O console mostra estado atual: quantas mensagens estão na fila agora, qual o status do environment agora. Quando algo quebra, o que você precisa é a história — o que aconteceu nos últimos 5 minutos antes do alarme disparar. Sem instrumentação prévia, essa história não existe.

02. CloudWatch: o sistema nervoso da AWS

CloudWatch é o serviço guarda-chuva da AWS para monitoramento. Quase tudo que você criou nos módulos anteriores já está sendo monitorado por ele passivamente — logs sendo coletados, métricas básicas registradas. Mas para extrair valor, você precisa entender suas peças.

Os componentes principais

• Logs — Coleta, armazena e indexa logs textuais. Cobra por GB ingerido + GB armazenado.
• Metrics — Armazena séries temporais numéricas. AWS publica automaticamente; você pode publicar suas próprias.
• Alarms — Dispara ações (e-mail, Lambda, SNS) quando uma métrica passa de um limite por X períodos consecutivos.
• Dashboards — Painéis visuais combinando métricas e logs. Útil para visão geral do sistema.
• Logs Insights — Linguagem de query para fazer perguntas em cima dos logs (similar a SQL).
• Synthetics — Testes que rodam continuamente simulando usuários (não vamos usar, mas vale conhecer).

O que já está sendo coletado

Sem você fazer nada, AWS já coleta:

• Lambda publica métricas de invocações, erros, duração e throttles. Logs vão para um log group /aws/lambda/<nome-funcao>.
• SQS publica número de mensagens visíveis, mensagens em flight, idade da mensagem mais antiga.
• SNS publica número de mensagens publicadas e entregues.
• DynamoDB publica RCU/WCU consumidas, latência, throttles.
• Beanstalk publica métricas de saúde do ambiente; instâncias EC2 publicam CPU, rede, disco.

Tudo isso fica em CloudWatch durante 15 meses por padrão (com granularidade decrescente ao longo do tempo). É bastante coisa de graça — o desafio não é ter dados, é saber quais perguntas fazer e quais alarmes criar.

Logs gerados pelo seu código

Tudo que sua aplicação escrever no stdout ou stderr vai parar em CloudWatch Logs automaticamente, em ambos os casos: Lambda (via runtime) e Beanstalk (via agente CloudWatch que vem instalado). Você não precisa configurar SDK do CloudWatch — basta usar console.log em Node.js.

03. CloudWatch Logs

Logs são a forma mais flexível e mais cara de monitoramento. Vale entender a hierarquia, as features e — principalmente — como controlar o custo.

Hierarquia: log group, log stream, event

CloudWatch Logs organiza dados em três níveis:

• Log Group — agrupa logs relacionados, geralmente por aplicação ou função. Exemplo: /aws/lambda/order-event-consumer. As configurações de retenção e KMS ficam aqui.
• Log Stream — uma sequência de eventos vindos da mesma origem. Para Lambdas, é normalmente um por instância de execução. Para EC2, um por instância.
• Log Event — uma linha de log: timestamp + mensagem. É a unidade mínima.

Configure retenção em todo log group

Por padrão, CloudWatch Logs retém logs indefinidamente. Em curso, isso vira o seu maior custo silencioso. Configure retenção em todo log group:

# Listar todos os log groups
aws logs describe-log-groups \
  --query 'logGroups[*].[logGroupName,retentionInDays]' \
  --output table
 
# Definir retenção de 7 dias para um log group específico
aws logs put-retention-policy \
  --log-group-name /aws/lambda/order-event-consumer \
  --retention-in-days 7
 
# Aplicar 7 dias em TODOS os log groups (script bash)
aws logs describe-log-groups \
  --query 'logGroups[*].logGroupName' --output text | \
  tr '\t' '\n' | while read group; do
    aws logs put-retention-policy \
      --log-group-name "$group" --retention-in-days 7
  done

Buscando logs no console

Para inspeção manual rápida, CloudWatch Logs tem busca de texto no próprio console: vá em Log groups > <seu group>, clique em Search log group e use a sintaxe de filtros:

# Filtrar por palavra simples
ERROR
 
# Combinar palavras (todos devem aparecer)
ERROR Inventory
 
# Excluir uma palavra
ERROR -Connection
 
# JSON: campo igual
{ $.level = "error" }
 
# JSON: campo numérico
{ $.duration > 1000 }
 
# JSON: combinação
{ $.level = "error" && $.service = "orders" }

Para análises mais ricas — agrupamento, agregação, ordenação — use CloudWatch Logs Insights, com sintaxe própria parecida com SQL:

# Top 10 erros nas últimas 24 horas
fields @timestamp, @message
| filter level = "error"
| stats count() by error_code
| sort count desc
| limit 10
 
# Latência p99 por endpoint na última hora
fields @timestamp, route, duration
| filter ispresent(duration)
| stats pct(duration, 99) by route
| sort `pct(duration, 99)` desc

04. Logs estruturados em JSON

Esta é a única decisão de logging que realmente importa nesse projeto: logar em JSON estruturado em vez de texto livre. A diferença é abismal na hora de debugar.

Por que estruturado, não livre

Compare estes dois logs do mesmo evento:

# Log de texto livre (RUIM)
[INFO] Order order-123 processed in 234ms by user user-456
 
# Log estruturado em JSON (BOM)
{"timestamp":"2026-05-07T14:23:11Z","level":"info",
 "service":"orders","event":"order.processed",
 "orderId":"order-123","userId":"user-456",
 "duration_ms":234,"region":"us-east-1"}

O texto livre força você a escrever regex toda vez que quiser fazer uma pergunta. JSON é parseado automaticamente pelo CloudWatch Logs Insights — você consulta os campos diretamente.

Padrão de logging para o projeto

Adote estes campos como base em todos os serviços do projeto. Não é uma lista exaustiva, mas é o mínimo viável para correlação:

• timestamp — ISO 8601 em UTC. CloudWatch já adiciona, mas ter no payload ajuda em sistemas externos.
• level — info, warn, error, debug. Sempre minúsculo.
• service — nome do microserviço: orders, inventory, payments.
• event — nome do evento de domínio: order.created, payment.failed.
• requestId — ID único da requisição. Permite seguir uma operação por todos os serviços.
• userId / orderId / etc. — IDs de domínio relevantes para o evento.
• duration_ms — para operações timed: latência em milissegundos.
• error — objeto com code, message, stack quando aplicável.

Use uma biblioteca, não console.log

Para Node.js, use pino ou winston. Ambos suportam saída JSON nativa, são performáticos e plugam fácil com CloudWatch:

// pino: minimal e rápido
import pino from 'pino';
 
const log = pino({
  level: process.env.LOG_LEVEL || 'info',
  base: {
    service: 'orders',
    region: process.env.AWS_REGION,
  },
});
 
log.info({ orderId, userId, duration_ms: 234 }, 'order.processed');
log.error({ err, orderId }, 'order.failed');

Propagação de requestId

Para conseguir rastrear uma requisição pelos serviços, propague o requestId em headers HTTP e em atributos de mensagens SQS/SNS. Quando Orders publica um evento, ele coloca o requestId nos message attributes. Quando o consumer Lambda processa, ele extrai e loga com o mesmo ID. Resultado: uma busca por requestId = X retorna toda a jornada.

05. Métricas: as duas categorias

Métricas são números agregados ao longo do tempo. Dividem-se em duas categorias importantes: nativas, publicadas pela AWS automaticamente, e customizadas, que você publica do seu código.

Métricas nativas (de graça)

Cada serviço da AWS publica seu próprio conjunto. Vale conhecer as principais para os serviços que você usa:

Dimensões: como filtrar

Cada métrica vem com dimensões — chaves que permitem filtrar. Por exemplo, Lambda Duration vem com a dimensão FunctionName, permitindo ver a duração separada por função.

Saber as dimensões disponíveis é crítico para criar gráficos e alarmes úteis. No console, ao escolher uma métrica, as dimensões aparecem como abas. Na CLI:

# Listar métricas e dimensões para um namespace
aws cloudwatch list-metrics --namespace AWS/Lambda \
  --metric-name Duration

Estatísticas e períodos

Toda métrica é consultada com uma estatística (Average, Sum, Min, Max, p95, p99) e um período (em segundos). Detalhe importante:

• Average tende a esconder problemas. Se 99 requisições retornam em 50ms e 1 retorna em 5s, a média é ~100ms — parece OK, mas tem usuários frustrados.
• p99 ou p95 são quase sempre melhores que Average para latência. Mostram a experiência do pior caso, que é o que o usuário sente.
• Sum só faz sentido para contadores cumulativos: requisições, erros, bytes.
• Min / Max são úteis para detectar valores fora da curva.

06. Métricas customizadas via EMF

As métricas nativas cobrem infraestrutura: latência da Lambda, tamanho da fila. Mas você também quer métricas de domínio: pedidos criados por minuto, valor total processado, taxa de aprovação de pagamento. Essas você publica.

Duas formas de publicar

A forma direta é chamar o SDK do CloudWatch: PutMetricData. Funciona, mas tem dois problemas: cada chamada é uma API call separada (custo + latência) e bloqueia o fluxo principal. A forma moderna é usar EMF (Embedded Metric Format).

EMF: métrica embutida no log

EMF é um formato JSON especial que, quando aparece em CloudWatch Logs, é automaticamente extraído e publicado como métrica. Ou seja, você só precisa logar — o CloudWatch faz o resto. Sem chamada extra.

{
  "_aws": {
    "Timestamp": 1715089391000,
    "CloudWatchMetrics": [{
      "Namespace": "OrderSystem/Orders",
      "Dimensions": [["Service", "Region"]],
      "Metrics": [
        { "Name": "OrderCreated", "Unit": "Count" },
        { "Name": "OrderValue", "Unit": "None" }
      ]
    }]
  },
  "Service": "orders",
  "Region": "us-east-1",
  "OrderCreated": 1,
  "OrderValue": 234.50
}

Em código real, ninguém escreve isso à mão. Use a biblioteca aws-embedded-metrics oficial:

import { metricScope, Unit } from 'aws-embedded-metrics';
 
export const handler = metricScope(metrics => async (event) => {
  metrics.setNamespace('OrderSystem/Orders');
  metrics.setDimensions({ Service: 'orders', Region: 'us-east-1' });
 
  const order = await processOrder(event);
 
  metrics.putMetric('OrderCreated', 1, Unit.Count);
  metrics.putMetric('OrderValue', order.total, Unit.None);
  metrics.putMetric('ProcessingTime', order.duration_ms,
    Unit.Milliseconds);
 
  return { statusCode: 200 };
});

Métricas que valem a pena no projeto

Não publique tudo — cada dimensão vira combinação custosa. Foque no que realmente importa para tomar decisão:

• OrderCreated em OrderSystem/Orders, dimensão Service. Conta pedidos criados por unidade de tempo.
• OrderValue em OrderSystem/Orders. Soma do valor dos pedidos — útil para correlacionar com volume.
• InventoryLow em OrderSystem/Inventory, dimensão ProductId. Conta vezes em que estoque ficou abaixo do mínimo.
• PaymentFailed em OrderSystem/Payments, dimensão Reason. Conta falhas separadas por motivo.
• EventProcessingTime em todas as Lambdas consumer, dimensão EventType. Latência por tipo de evento.

07. Alarmes que importam

Alarme é uma máquina de estado: ele observa uma métrica e dispara uma ação quando passa de um limite. Bem configurado, ele te acorda às 3 da manhã para problemas reais. Mal configurado, ele te ignora porque você se acostumou.

Anatomia de um alarme

• Métrica — qual número observar.
• Estatística + Período — como agregar (Average, Sum) e em que janela (1min, 5min).
• Threshold + Comparison — qual valor é “ruim”. Exemplo: > 5, < 0.99.
• Datapoints to alarm — quantos períodos consecutivos precisam violar para disparar. Evita falso positivo de 1 pico.
• Action — o que fazer ao disparar. Tipicamente: publicar em um SNS topic que tem você como assinante.
• Treat missing data — o que fazer quando não chega dado: ignorar, considerar OK, considerar ruim.

Alarmes essenciais para o projeto

Esses são os alarmes que você deveria ter rodando nesse sistema. Não são os únicos possíveis — são os que mais provavelmente vão te poupar de uma noite ruim.

Notificações via SNS + e-mail

A forma mais simples de receber alertas: um tópico SNS chamado alarms-prod com seu e-mail como assinante. Todos os alarmes publicam nele. Você confirma a inscrição uma vez e pronto.

# Criar o tópico
aws sns create-topic --name alarms-prod
 
# Inscrever seu e-mail (vai chegar um e-mail de confirmação)
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:alarms-prod \
  --protocol email \
  --notification-endpoint seu@email.com
 
# Criar um alarme apontando para esse tópico
aws cloudwatch put-metric-alarm \
  --alarm-name lambda-orders-errors \
  --metric-name Errors --namespace AWS/Lambda \
  --dimensions Name=FunctionName,Value=order-event-consumer \
  --statistic Sum --period 300 --threshold 5 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:alarms-prod

08. Dashboards

Dashboards são painéis visuais que combinam métricas e logs. Servem para três coisas: visão geral diária, investigação quando algo está estranho, e compartilhamento com o time.

Anti-padrão: o dashboard que ninguém olha

É tentador encher um dashboard com 30 widgets coloridos. Não funciona — ninguém abre dashboard cheio. Pense em duas categorias:

• Operations Dashboard — visão geral, 5-8 widgets, uma tela só. Latência p99 de cada serviço, taxa de erro, tamanho de fila. É o que você abre toda manhã.
• Service Dashboard — um por microserviço, mais detalhado. Tudo sobre Orders num lugar: latência, erros, capacidade DynamoDB, métricas de domínio. Você só abre quando algo está estranho com aquele serviço.

Dashboard sugerido para o projeto

Comece com um dashboard OrderSystem-Operations contendo:

• Linha 1 — OrderCreated e PaymentFailed nas últimas 24h (linhas).
• Linha 2 — p95 de latência de cada microserviço (3 linhas no mesmo gráfico).
• Linha 3 — ApproximateNumberOfMessagesVisible em todas as filas (linhas).
• Linha 4 — Lambda Errors por função (gauge de cada função).
• Linha 5 — Top 10 mensagens de erro recentes via Logs Insights.

Criando via CloudFormation

Como tudo o mais no projeto, dashboards devem ser código. O recurso é AWS::CloudWatch::Dashboard, com o body em JSON:

OperationsDashboard:
  Type: AWS::CloudWatch::Dashboard
  Properties:
    DashboardName: OrderSystem-Operations
    DashboardBody: !Sub |
      {
        "widgets": [{
          "type": "metric",
          "properties": {
            "metrics": [
              ["OrderSystem/Orders", "OrderCreated"],
              ["OrderSystem/Payments", "PaymentFailed"]
            ],
            "period": 300,
            "stat": "Sum",
            "title": "Throughput"
          }
        }]
      }

09. X-Ray: tracing distribuído

X-Ray responde uma pergunta que logs e métricas não respondem bem: “o que aconteceu nessa requisição específica, passo a passo, em todos os serviços?”. É a peça que falta para depurar latência em sistemas distribuídos.

O que X-Ray entrega

Você ativa X-Ray nos serviços, e cada requisição produz um trace. Um trace é uma árvore de segments (cada serviço) e subsegments (operações dentro dele: chamada DynamoDB, chamada SNS, etc.). Resultado:

• Service map: visão dos serviços e como eles conversam, com latência média e taxa de erro em cada conexão.
• Trace timeline: para uma requisição específica, gráfico em cascata mostrando quanto tempo cada operação levou.
• Annotations e metadata: você adiciona campos no trace (orderId, userId) que viram filtros nas buscas.
• Sampling: para não traçar 100% das requisições, X-Ray amostra. Padrão: 1 req/seg + 5% das demais.

Habilitando em Lambda

Em Lambda, é literalmente uma flag. Em CloudFormation:

OrderEventConsumer:
  Type: AWS::Lambda::Function
  Properties:
    FunctionName: order-event-consumer
    # ... outras props
    TracingConfig:
      Mode: Active   # X-Ray ligado
 
# E garante que a role tem permissão
LambdaRole:
  Type: AWS::IAM::Role
  Properties:
    ManagedPolicyArns:
      - arn:aws:iam::aws:policy/service-role/
        AWSLambdaBasicExecutionRole
      - arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess

Habilitando em Beanstalk (Node.js)

Em Beanstalk você precisa instrumentar manualmente o app. Felizmente, o SDK do X-Ray cobre patches automáticos para Express e AWS SDK:

import express from 'express';
import AWSXRay from 'aws-xray-sdk-core';
import xrayExpress from 'aws-xray-sdk-express';
 
// patcheia o AWS SDK automaticamente
AWSXRay.captureAWS(require('aws-sdk'));
 
const app = express();
 
// middleware: abre o segment no início da requisição
app.use(xrayExpress.openSegment('orders-service'));
 
app.post('/orders', handler);
 
// middleware: fecha o segment ao final
app.use(xrayExpress.closeSegment());

Anotações úteis

Annotations são campos indexados — você pode filtrar traces por elas. Metadata é só leitura:

const segment = AWSXRay.getSegment();
 
// Annotations (indexadas, filtráveis)
segment.addAnnotation('orderId', order.id);
segment.addAnnotation('region', 'us-east-1');
 
// Metadata (visível, mas não filtrável)
segment.addMetadata('order', { 
  total: order.total, 
  itemCount: order.items.length
});

10. Custos de observabilidade

CloudWatch é o serviço mais traiçoeiro da AWS em termos de custo. Você raramente recebe surpresa de Lambda ou DynamoDB sob uso normal — mas pode levar susto bonito de Logs se não tomar cuidado.

Onde o dinheiro vai

• Logs Ingestion — ~US$ 0,50/GB ingerido. É o item dominante para apps verbosos.
• Logs Storage — ~US$ 0,03/GB/mês. Pequeno, mas cresce se retenção for infinita.
• Logs Insights — ~US$ 0,005/GB escaneado por query. Cuidado com queries em janelas grandes.
• Custom Metrics — US$ 0,30 por métrica/mês. Cardinalidade alta (muitas dimensões) explode aqui.
• API requests — US$ 0,01 por 1k chamadas a PutMetricData. EMF evita esse custo.
• Alarms — US$ 0,10 por alarme/mês (standard); composite alarms são US$ 0,50.
• X-Ray — US$ 5 por milhão de traces gravados; US$ 0,50 por milhão de scans.

Hábitos que mantêm custo controlado

• Retenção curta em todo log group — 7 dias para dev, 30 para prod, mais que isso só com motivo.
• Não logue payloads inteiros. Payloads grandes (especialmente em JSON) inflam ingestion sem agregar valor. Logue IDs e contadores.
• Log level configurável via env var. Em prod, rode em info. debug só para troubleshooting pontual.
• Cardinalidade baixa em dimensões de métrica customizada — nada de UserId como dimensão.
• Sampling em X-Ray. Não trace 100%, especialmente em alto volume.
• Revise alarmes periodicamente. Alarme inútil é US$ 0,10/mês de pura burocracia.

Estimativa para o projeto do curso

Com o setup recomendado (logs estruturados, retenção de 7 dias, ~10 alarmes, métricas EMF, X-Ray ligado), o custo mensal de observabilidade fica entre US$ 1 e US$ 3 em uso de estudo. Se você ver mais que isso, é sinal de algum runaway — geralmente um log group em modo debug que ficou ligado ou uma métrica com cardinalidade alta.

11. Destruindo a infraestrutura

Você chegou no fim. O sistema funciona, está observado, está documentado. Hora da última lição importante: derrubar tudo sem deixar resíduo.

Por que destruir é parte do aprendizado

Boa parte das contas inchadas que você vai ouvir falar não são de gente rodando sistema em produção — são de recursos esquecidos em ambientes de estudo. Um environment Beanstalk com ALB pode custar US$ 16/mês ligado fazendo nada. Você não vê, não usa, não quer, mas a fatura chega.

Como você fez tudo via CloudFormation, derrubar é um comando:

# Liste suas stacks
aws cloudformation list-stacks \
  --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE
 
# Delete uma stack
aws cloudformation delete-stack --stack-name order-system-prod
 
# Acompanhe a deleção
aws cloudformation describe-stacks --stack-name order-system-prod \
  --query 'Stacks[0].StackStatus'
 
# Espere terminar (bloqueia até DELETE_COMPLETE ou DELETE_FAILED)
aws cloudformation wait stack-delete-complete \
  --stack-name order-system-prod

Ordem importa em stacks aninhadas

Se você tem stacks aninhadas (uma stack pai com stacks filhas), delete a pai — CloudFormation cuida de derrubar as filhas na ordem correta. Se deletou só a filha por engano e a pai ficou referenciando, você cai num estado meio quebrado e provavelmente vai precisar deletar a pai também.

O que CloudFormation NÃO deleta

• Buckets S3 com objetos. Se a stack criou um bucket e depois você (ou app) jogou objetos dentro, CloudFormation falha ao deletar. Esvazie antes: aws s3 rm s3://bucket --recursive.
• Tabelas DynamoDB com DeletionProtection. Se você ligou proteção, desligue antes via console ou CLI.
• Recursos com DeletionPolicy: Retain. Você marcou explicitamente para não apagar — então o recurso fica, e você precisa deletar manualmente depois.
• Recursos criados manualmente fora da stack. Sempre. Se você foi no console e criou um security group à mão, ele não é gerenciado pela stack e fica.

Checklist final de limpeza

1. Delete todas as stacks CloudFormation do projeto.
2. Liste e delete buckets S3 que sobrarem (esvazie primeiro).
3. Verifique no Beanstalk: nenhum environment ativo.
4. Verifique CloudWatch Logs: log groups antigos podem ficar — delete os que não vai mais usar.
5. Verifique DynamoDB: nenhuma tabela ativa.
6. Verifique SQS e SNS: nada listado.
7. Verifique IAM: roles e policies criadas pela stack devem ter sumido. Users criados manualmente, você decide.
8. Verifique billing dashboard: confirme que o uso voltou para zero nos próximos dias.

12. Exercícios de fixação

Os exercícios deste módulo final misturam observabilidade prática com reflexão sobre o que você aprendeu no curso inteiro.

13. Encerramento e próximos passos

Você chegou ao fim. Não em sentido figurado — chegou ao fim mesmo, com um sistema funcional construído, executado, observado e desfeito. Vale uma pausa rápida para olhar o que aconteceu.

O que você sabe agora que não sabia antes

• Microserviços não são mágica. São uma decisão de arquitetura com trade-offs concretos: independência operacional vs complexidade de coordenação. Você sentiu os dois lados na pele.
• NoSQL exige modelagem diferente. Você modelou DynamoDB pelos access patterns, escolheu partition keys, criou GSIs. Não é pior nem melhor que SQL — é diferente.
• PaaS e FaaS resolvem coisas diferentes. Beanstalk para serviços sempre-ligados de baixa latência, Lambda para tarefas event-driven. Você usou os dois e entendeu quando cada um faz sentido.
• Mensageria desacopla. Orders não conhece Inventory. Você pode trocar Inventory inteiro amanhã que Orders nem percebe — porque tudo passa por SNS+SQS.
• Infraestrutura é código. Tudo que você criou pode ser recriado por create-stack. Isso muda a relação com a infra: ela vira um artefato, não um patrimônio.
• Observabilidade não é luxo. Sem logs estruturados, métricas e alarmes, o sistema é uma caixa preta. Com eles, ele se explica.

Para onde ir agora

Você está num ponto interessante: tem base sólida para escolher direções específicas. Algumas sugestões organizadas por interesse:

Aprofundamento técnico

• API Gateway + Cognito — autenticação real, rate limiting, planos de uso. Pega o sistema atual e bota um gateway com auth na frente.
• Step Functions — orquestração de workflows. Útil quando você tem fluxos de várias etapas com retentativa, branching, paralelismo. Sagas distribuídas viram pão com manteiga.
• EventBridge — sucessor moderno do SNS para eventos. Suporta schemas, regras complexas, integração nativa com SaaS. Vale migrar Orders→Inventory pra ver a diferença.
• ECS / Fargate — containers gerenciados. Quando Beanstalk começa a apertar, este é o próximo degrau.

Práticas e cultura

• The Twelve-Factor App — ler e aplicar. Você já usa boa parte sem saber.
• Designing Data-Intensive Applications (Kleppmann) — o livro de cabeceira para quem trabalha com sistemas distribuídos.
• Well-Architected Framework da AWS — 6 pilares que organizam pensamento sobre projetos AWS. Faça o review do seu projeto.
• Chaos Engineering — quando você confiar no sistema, comece a quebrá-lo de propósito (FIS na AWS) para validar a resiliência.

Certificações (se você quiser)

Esse projeto cobre boa parte de duas certificações AWS. Se você está pensando em prova:

• AWS Certified Developer — Associate — 100% alinhada com o que você fez. Você cobriu Lambda, DynamoDB, SQS, SNS, IAM, CloudWatch e CloudFormation. Falta um pouco de Cognito, API Gateway, Kinesis.
• AWS Certified Solutions Architect — Associate — Cobre tudo isso e mais arquitetura: VPC, EC2 em profundidade, RDS, S3 avançado, Route 53. É a certificação mais comum como “primeira AWS”.

E quando der errado

Em algum momento você vai estar trabalhando em algo, vai dar errado de um jeito que você não consegue explicar, e vai sentir que está perdendo tempo. Lembre-se: esse momento é o aprendizado. Tudo que você sentiu nesse curso — frustração com permissões, susto com timeout, demora pra entender por que o evento não estava chegando — é exatamente o que constrói intuição. Os engenheiros que você admira passaram por isso milhares de vezes e simplesmente lembram do padrão na próxima vez.

FIM DO CURSO

Obrigado por ter chegado até aqui.

Você sabe AWS na prática agora. Use bem.