AWS é dominante em cloud enterprise e tem 200+ serviços. A maioria dos devs sabe usar 5: EC2 manualmente, 04-03 pra blob, RDS pra DB, Lambda pra "serverless", e por aí. Falta o modelo mental, IAM como espinha dorsal, VPC como rede, custo por bom uso vs custo por preguiça, decisões entre Lambda/Fargate/EKS, replicação multi-AZ, security groups, NAT gateways. Sem isso, você commit em arquitetura cara e frágil.
Este módulo cobre os primitives core. Não é "tutorial AWS", é mapa pra navegar 90% das decisões de cloud em projetos médios. Foco em decisões e princípios. Hands-on no desafio.
2. Teoria Hard
2.1 Modelo geral
AWS organizado em regions (geo) e availability zones (data centers isolados em uma região). High availability = multi-AZ. Disaster recovery = multi-region.
Recursos são por região (com exceções: IAM, Route 53, CloudFront, são globais).
Conta AWS é unidade de billing e isolation. Em organizações sérias, AWS Organizations com múltiplas contas (dev, staging, prod, security) e Control Tower pra governance.
2.2 IAM, espinha dorsal
IAM controla quem pode fazer o quê. Conceitos:
Users: humanos (raramente recomendado em 2026; prefer SSO).
Groups: agregam users.
Roles: identidade assumível por serviços ou cross-account. Default em prod.
Policies: JSON com permissions (Action, Resource, Effect, Condition).
Identity Center (SSO): federação centralizada.
Princípios:
Least privilege: começa restrito; libera o necessário.
Roles, não users: app rodando em EC2 assume IAM role; não armazena access keys.
OIDC pra CI: GH Actions assume role via OIDC, sem keys long-lived.
MFA pra root: e nunca usa root pra operação dia-a-dia.
VPC peering: conexão 1-pra-1, sem transitive routing. Bom pra 2-3 VPCs. Não escala, N² pares.
Transit Gateway (TGW): hub-and-spoke. 1 TGW conecta N VPCs + on-prem (via VPN/Direct Connect) + outras regiões. Custo: $0.05/hora por VPC attach + processing fees. Em multi-account real, TGW resolve. Suporta route tables segmentadas (prod isolada de dev mesmo no mesmo TGW).
Cloud WAN (2024+): camada acima de TGW pra global multi-region. Mais cara, melhor pra dezenas de VPCs cross-region.
PrivateLink, o que Pleno raramente domina:
VPC Endpoints clássicos: Gateway (04-03, DynamoDB) usam route table; Interface usam ENI dentro da sua VPC com IP privado.
PrivateLink avançado: você expõe um NLB como serviço VPC. Outros VPCs (até de outras contas) consomem como Interface Endpoint. Pattern padrão pra B2B SaaS: cliente acessa seu serviço sem expor à internet.
Custo: $0.01/hora por Endpoint + $0.01/GB processed. Usado bem, economiza muito vs NAT egress.
Outras VPCs roteiam internet via TGW → egress VPC. Centraliza custo, controle, e logging.
Reduz NAT GW de N (uma por VPC) pra ~3 (uma por AZ centralizada).
IPv6 em 2026:
AWS cobra $0.005/hora por IPv4 público. IPv6 é grátis. Em 2026 vale dual-stack ou IPv6-only quando possível pra cortar custo significativo em fleets grandes.
ALB, NLB, EC2 suportam IPv6 nativo. Lambda em VPC com IPv6 desde 2024.
Security Groups vs NACLs, pegadinha:
SG é stateful: response automática. NACL é stateless: regra explícita pra response port (ephemeral 1024-65535).
Accounts por env (dev, staging, prod) e/ou por team.
SSO (Identity Center) federa users em todas contas com roles específicas.
2.19 FinOps e cost engineering
Pleno conhece "monitorar fatura". Senior pratica FinOps: disciplina de unit economics em cloud. Em 2025-2026 virou skill obrigatória pra quem opera infra.
Conceitos centrais:
Unit cost: $ por unidade de business (per request, per active user, per GB processed). Métrica que importa, não fatura absoluta.
Cost allocation tags: tag tudo (team, service, env). AWS Cost Explorer + tags = breakdown real. Sem tags, fatura é black box.
Budgets + alerts (AWS Budgets): alarmes em $X% do mês esperado. Catch surge antes do CFO catch.
Reserved Instances vs Savings Plans: SP é mais flexível (cobre EC2/Fargate/Lambda em qualquer região). 1-year ou 3-year, no/partial/all upfront. Tipicamente 30-60% off on-demand.
Spot: instâncias interruptíveis, ~70-90% off. Use pra workloads tolerantes (batch, CI, stateless web com graceful drain).
Em 2025-2026 virou signal de maturidade técnica em diversos contextos (consumer-facing brands, EU GDPR + sustainability reporting, talent attraction). Não é só "marketing", tem decisões técnicas reais.
Princípios (Green Software Foundation):
Carbon efficiency: minimizar emissões por unit work.
Energy efficiency: minimizar energia consumida.
Carbon awareness: rodar quando grid está mais limpo.
AWS Lambda Power Tuning (Step Function open-source): roda função em N memory configs, plota cost × latência → sweet spot.
Provisioned Concurrency: instâncias pre-warmed; elimina cold start; ~$0.0000041/GB-second provisionado + execução normal. Use só em high-traffic previsível.
SnapStart (Java 21+, Python 3.12+): snapshot do init state; cold start 10x mais rápido; gratuito.
Pattern Logística: provisioned_concurrency = 3 em /api/orders (tráfego constante); on-demand em /webhooks/* (irregular, custo provisionado não compensa).
Lambda Function URL vs API Gateway:
Function URL: HTTPS endpoint direto na Lambda; sem overhead API Gateway; pricing simples (só Lambda).
API Gateway HTTP API v2: $1/1M requests; custom domains, JWT auth, throttling, WAF, CORS managed. Default 2026.
API Gateway REST API: legado; $3.50/1M requests (3.5x); raramente justificado sobre HTTP API v2 em 2026 (só se precisa request validation avançada ou usage plans).
App Runner / ECS Fargate: alternativa para serviços long-running além do limite Lambda 15min ou que precisam websocket persistente.
Registre schema em EventBridge Schema Registry → CI gera bindings TypeScript → consumers importam type. Toda mudança breaking incrementa version; consumers validam antes de processar. Sem schema registry, qualquer mudança em provider quebra consumers silenciosamente em produção.
Elimina dezenas de "lambdas-conectoras" que só roteiam eventos. Menos código = menos bugs = menos cost.
Step Functions vs Lambda choreography:
Lambda choreography (event-driven): cada Lambda emite evento; consumers reagem. Loose coupling. Hard de visualizar fluxo end-to-end. Debugging via correlation-id em logs distribuídos.
Step Functions (orchestration): state machine ASL JSON; visual workflow no console; retry + catch + parallel + map + wait built-in; histórico de execução por instância.
Use Step Functions quando: workflow multi-step com branches/retries (saga), execução > 15min, visibilidade de estado crítica (compliance/audit), human approval steps.
Compensações rodam em ordem reversa (saga pattern, cruza com 04-02 §2.18 e 04-04). Retry antes de Catch; backoff exponencial built-in; sem código de orquestração custom.
Cost Step Functions:
Express (< 5min, high-volume): $1/1M state transitions equivalente; sem histórico de execução retido (logs via CloudWatch). Default para sub-fluxos chamados por API.
Standard (long-running, audit): $25/M state transitions; histórico completo retido 90 dias; visualização console por execução. Default para sagas auditáveis.
Logística applied serverless stack:
API Gateway HTTP API v2 + Lambda (Node.js 22, 1024MB tuned via Power Tuning) para /api/*.
EventBridge custom buslogistica-events para eventos cross-service; schemas versionados no Schema Registry.
Step Functions Standard para order-saga (multi-step transacional auditável).
EventBridge Pipes para SQS → enrichment → Step Functions trigger.
Lambda Powertools em todas as funções (logs estruturados + idempotency DynamoDB + metrics EMF).
Provisioned Concurrency = 3 em orders-api; on-demand em webhook handlers.
Cost típico: $50-200/mês para 10k orders/dia (Lambda + Step Functions Standard + EventBridge + DynamoDB idempotency).
Anti-patterns observados:
Lambda 256MB em CPU-bound work: lento, custa mais (mais tempo × menos CPU); bump pra 1769MB sweet spot via Power Tuning.
Provisioned Concurrency em low-traffic Lambda: custo fixo > economia cold start; on-demand fine.
REST API Gateway em vez de HTTP API v2: 3.5x cost para mesma feature em 95% dos casos.
Lambda choreography em workflow com 5+ steps: debugging nightmare distribuído; migra para Step Functions.
Step Functions Standard em simple 2-step flow: over-engineered; use Express ou direct Lambda chain.
EventBridge sem Schema Registry: consumers quebram silenciosamente em provider change; sem governança.
Lambda sem Powertools structured logs: CloudWatch unstructured = grep manual = unsearchable em scale.
Lambda Layer com 50+ deps inflado: cold start penalty; tree-shake ESBuild bundle por função.
DynamoDB stream → Lambda → DynamoDB write: write amp 2x; use EventBridge Pipes com filter para evitar.
SnapStart desabilitado em Java/Python Lambda: cold start 10x maior evitável; flag gratuita.
Cruza com 03-05 §2.21 (cost optimization compute layer), 04-08 §2.22 (Strangler Fig migration usa EventBridge para coexistência), 04-04 (Step Functions resilience, retry/catch states), 04-02 §2.18 (idempotent consumer DynamoDB-backed em Lambda Powertools), 02-08 (frameworks backend, Lambda Powertools como middleware pattern).
Portfólio AWS reorganizou-se 2023-2026 em torno de cinco eixos: GenAI gerenciada via Bedrock (foundation models multi-vendor sem GPU ops), event mesh serverless via EventBridge Pipes (source→filter→enrichment→target substitui ~80% das glue Lambdas), storage tier sub-ms via S3 Express One Zone (single-AZ, latência consistente <10ms p99, hot data ML/cache), economia ARM dominante via Graviton 4 (R8g GA Q4 2024, 40% melhor perf/$ vs x86), sharding transacional via Aurora Limitless Database (GA Q4 2024, single endpoint sobre múltiplos shards Postgres). Quem opera AWS legado (EC2 + RDS single-writer + glue Lambda + Python x86) perde 30-50% de custo e 5-10x latência vs stack 2026 equivalente. Não é refactor opcional — é a baseline competitiva.
Bedrock GenAI stack — foundation models como managed service. Bedrock GA Q3 2023, Bedrock Agents + Knowledge Bases GA Q4 2023, Guardrails GA Q2 2024. Claude 3.7 Sonnet on Bedrock Q1 2025, Claude 4 family 2025. Quatro pilares:
Foundation models multi-vendor: Claude (Anthropic), Llama (Meta), Titan (AWS), Mistral, Cohere, Stability — sem provisionar GPU, billed por token.
S3 Express One Zone + Mountpoint. S3 Express GA Q4 2023 — single-AZ, sub-ms latência consistente, 50% menor custo de request, 5x mais caro por GB-month ($0.16 vs $0.023 S3 Standard). Use case: ML training shuffle, hot temp scratch, checkpoint frequente. Não é durável cross-AZ — perde dados em AZ outage. Mountpoint for S3 (GA Q3 2023) expõe bucket como filesystem POSIX read-optimized — read-heavy ML datasets sem sync manual.
Graviton 4 (R8g) economics. R8g GA Q4 2024 — 40% melhor perf/$ vs x86 (m7i) e 30% vs Graviton 3. Compatibilidade ARM resolvida 2023-2024 (Node, Python, Java, Go: zero-cost; binários nativos: rebuild multi-arch via Docker buildx). Lambda em Graviton 3+ economiza ~20% por invocação. Managed services preço idêntico arch-agnostic — só vale para EC2/EKS/Lambda. Stack típica logística: EKS node group m8g.xlarge substituiu m7i.xlarge → 30% menor bill compute.
# Multi-arch Docker (Graviton + x86)
# docker buildx build --platform linux/arm64,linux/amd64 -t app:latest --push .
FROM --platform=$BUILDPLATFORM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]
dockerfile
Aurora Limitless Database — sharded Postgres single-endpoint. GA Q4 2024. Cluster com shard group (multiple writers) + routers (single endpoint, query routing). Distribution key define sharding (e.g., tenant_id). Cross-shard transactions via 2PC com overhead — design para single-shard ops como hot path. Target 100M+ TPS. Aurora I/O-Optimized (GA 2023) corta 40% custo em workloads I/O-pesados (>25% bill é I/O). Combine: Limitless + I/O-Optimized para multi-tenant SaaS scale-out.
-- Aurora Limitless: criar shard group + sharded table
CALL rds_aurora.limitless_create_shard_group('logistics_shards', shard_count := 8);
CREATE TABLE orders (
order_id UUID PRIMARY KEY,
tenant_id UUID NOT NULL,
payload JSONB
) WITH (mode = 'sharded', distribution_key = 'tenant_id');
CREATE TABLE tenants ( tenant_id UUID PRIMARY KEY, name TEXT )
WITH (mode = 'reference'); -- replicada em todos os shards
sql
Step Functions Distributed Map — paralelismo S3 escala Spark-like. Itera sobre dataset S3 (CSV, JSONL, Manifest) com até 10000 execuções concorrentes. Substitui Spark/EMR para batches moderados (GBs, não TBs). ItemBatcher agrupa N itens por execução (controla custo + downstream load). MaximumConcurrency limita pressão.
Stack logística aplicada. Bedrock Claude 3.7 Sonnet + Knowledge Base (S3 com 200 PDFs help docs, OpenSearch Serverless backend) para customer support agent — responde "como cancelar?" com citation à doc fonte; Guardrails redact CPF/cartão. EventBridge Pipes: SQS courier_assignment → filter severity in [SEV1,SEV2] → Lambda enrich (busca courier metadata DynamoDB) → EventBridge bus → 4 targets (Slack alert, Datadog metric, audit S3, dispatch retry). S3 Express bucket --x-s3 para hot inventory cache (1ms p99 vs 30ms S3 Standard) — TTL 24h, fallback Standard. EKS migrado m7i → m8g (Graviton 4) → 30% menos compute bill, zero code change (Node + Java OpenJDK ARM-native). Step Functions Distributed Map noturno: itera CSV 5M shipments S3, ItemBatcher 200, MaxConcurrency 1000, gera relatório Athena.
10 anti-patterns:
Bedrock sem Guardrails em customer-facing: PII leak (CPF, cartão) + jailbreak amplificado por marca. Guardrail é compliance, não opcional.
Knowledge Base sem chunking strategy explícita: default fixed 300 tokens quebra contexto semântico → retrieval ruim → hallucination. Use semantic ou hierarchical para docs longos.
EventBridge Pipes para source→target trivial sem filter/enrichment: use Lambda destination ou SQS-Lambda direto — Pipes overkill (custo + latência).
S3 Express assumido durável cross-AZ: single-AZ design — outage da AZ = perda total. Use só para data reconstruível (cache, scratch, training shuffle).
Mountpoint para workload write-heavy: otimizado read — writes vão direto S3 sem cache, latência ruim. Use EFS ou FSx para write-heavy.
Graviton 4 sem container multi-arch: deploy falha em ARM se build x86-only. docker buildx --platform linux/arm64,linux/amd64 mandatório no CI.
Aurora Limitless em workload single-shard friendly: overhead de routers + 2PC sem benefit — Aurora Serverless v2 é mais simples e barato para <50K TPS single-tenant.
Distributed Map sem ItemBatcher em datasets massivos: 10000 execuções concorrentes saturam downstream (RDS connection pool, third-party API). ItemBatcher + MaxConcurrency mandatórios.
Bedrock multi-region failover sem cross-region inference quota: request denied silent quando primary region throttla. Configure cross-region inference profile (Q1 2025) ou fallback explícito.
EventBridge Pipes enrichment Lambda síncrono lento (>1s p99): pipe stalls, SQS messages re-deliver, custo explode. Enrichment deve ser <200ms p99 — se não, mova para target Step Functions async.
Cruza com 03-05 §2.5 (S3 foundation, Express é tier complementar), §2.6 (RDS/Aurora foundation, Limitless evolui o pattern), §2.8 (Lambda foundation, Pipes substitui glue Lambdas), §2.11 (EventBridge/SQS/SNS, Pipes orchestra os três), §2.21 (cost optimization, Graviton 4 + Aurora I/O-Optimized + S3 Express trade-offs), §2.22 (Lambda runtime + EventBridge schemas, Pipes consome schemas), 04-10 §2.21 (RAG architectures — Bedrock Knowledge Bases como RAG turnkey vs build-your-own), 04-10 §2.23 (MCP — Bedrock Agents é predecessor managed do mesmo padrão), 03-06 (Terraform/CDK provisioning de tudo acima), 04-09 §2.22 (multi-region scaling — Bedrock cross-region inference Q1 2025 resolve quota single-region).
3. Threshold de Maestria
Você precisa, sem consultar:
Diagrama VPC com 3 AZs, subnets pub/priv, IGW, NAT, ALB.
Justificar IAM Role over IAM User com 2 cenários.
Diferenças entre RDS Postgres, Aurora Postgres, Aurora Serverless v2.
Decisão Lambda vs Fargate vs EKS pra 3 cenários distintos.
Por que NAT Gateway é custoso e como mitigar.
3 ações pra reduzir egress cost.
Distinguir SQS Standard vs FIFO; SNS vs EventBridge.
Princípios de DynamoDB modeling (single-table design overview).
Estratégia de secrets em ECS task com Secrets Manager.
3 práticas pra evitar bill explosivo.
4. Desafio de Engenharia
Migrar Logística v1 pra AWS, abandonar Railway pra esse exercício, ainda em escala pequena.
Especificação
Conta AWS:
Free tier ou conta dedicada.
Não use root. Crie IAM user admin com MFA + acesso CLI; ou Identity Center.
Infra (criada via Console + AWS CLI a princípio; em 03-06, IaC):
VPC com 3 AZs, subnets pub/priv.
1 NAT Gateway (custo controlado).
VPC Endpoints pra 04-03 e ECR (reduzir egress).
Compute:
ECS Fargate pra api e web.
2 services (api, web), task definitions com image GHCR ou ECR.
Application Load Balancer na frente, com listener 443 + cert ACM.