Resolva os exercícios na ordem — cada nível constrói sobre o anterior. Tente resolver antes de consultar o gabarito.
Nível 1 — Conceitual
1.1 Identificando o serviço. Para cada situação, indique qual serviço AWS você usaria:
a) Subir uma máquina virtual Linux para rodar um script Python
b) Armazenar 50 mil fotos de produtos enviadas pelos vendedores
c) Banco de dados relacional com backup automático para um SaaS
d) Distribuir tráfego entre 5 servidores de uma API
e) Definir que o usuário maria@empresa.com só pode ler arquivos do bucket X
f) Acompanhar uso de CPU e disparar alerta no Slack se ultrapassar 85%
1.2 Vertical x Horizontal. Sua API está sofrendo com lentidão. Você tem 1 EC2 m5.large com 50% de CPU.
Qual abordagem você escolheria e por quê?
a) Trocar por uma m5.2xlarge (vertical)
b) Adicionar mais 1 m5.large atrás de um ALB (horizontal)
Justifique sua resposta considerando custo, risco e escalabilidade futura.
1.3 SPOF Hunt. Olhe esta arquitetura e liste todos os pontos únicos de falha (SPOFs):
- 1 EC2 com Nginx e uma API Go
- 1 RDS PostgreSQL single-AZ
- 1 bucket S3 (região
sa-east-1) - DNS apontando direto para o IP da EC2
Para cada SPOF, sugira uma solução.
Nível 2 — Prático
2.1 Sua primeira EC2. Suba uma EC2 t3.micro Ubuntu na região sa-east-1 (São Paulo).
- Conecte via SSH
- Instale Nginx
- Edite a página
/var/www/html/index.htmlcom seu nome - Acesse pelo navegador
- Configure o Security Group para permitir HTTP (80) apenas do seu IP
Entrega: print da página aberta + comandos do Security Group.
2.2 S3 e IAM.
- Crie um bucket S3 (nome único)
- Suba um arquivo qualquer
- Crie uma IAM Policy que permite somente
s3:GetObjectes3:ListBucketnesse bucket - Crie um IAM User chamado
reader, anexe essa policy - Gere access keys para o reader e configure um perfil local (
aws configure --profile reader) - Tente fazer upload (deve falhar) e tente fazer download (deve funcionar)
Entrega: o JSON da policy e prints dos dois comandos (sucesso e falha).
2.3 Health check inteligente. Modifique a API do projeto guiado para que o /health:
a) Retorne 200 se conseguir consultar SELECT 1 no banco
b) Retorne 503 se o banco estiver indisponível
c) Retorne JSON com {"db": "ok"|"down", "uptime": <segundos>, "version": <git-sha>}
Pense: por que esse health é melhor que só retornar "ok"?
Nível 3 — Desafio
3.1 Custo ótimo. Você tem uma aplicação com este perfil:
- Backend que precisa rodar 24/7 com 2 EC2
m5.large - Job batch noturno que roda 2h por dia em 10 EC2
c5.xlarge - Banco RDS
db.m5.large24/7
Calcule (com base na página de pricing oficial da AWS) o custo mensal estimado:
a) Tudo On-Demand b) Backend e RDS em Reserved Instances 1 ano + batch em Spot c) Backend e RDS em Savings Plans 3 anos + batch em Spot
Qual a economia da opção (c) versus (a)?
3.2 Migração para containers. Pegue a API do projeto guiado e migre de EC2 para ECS Fargate:
- Crie um Dockerfile
- Faça push da imagem para o ECR
- Crie a Task Definition
- Crie um Service ECS no mesmo ALB
- Configure Auto Scaling baseado em CPU
Bônus: cite 3 vantagens do Fargate sobre EC2 nesse cenário.
3.3 Disaster recovery. Sua aplicação está em sa-east-1. Como você implementaria DR (Disaster Recovery) para o caso da região inteira ficar fora do ar?
Considere: RTO (tempo para voltar): 1 hora. RPO (perda de dados): 5 minutos.
Desenhe a arquitetura, indique serviços AWS envolvidos e estime quanto isso aumenta a fatura.
3.4 Infra como código. Reescreva o projeto guiado inteiro em Terraform OU AWS CDK.
Você deve poder rodar terraform apply (ou cdk deploy) uma única vez e ter toda a stack subindo. E terraform destroy deve apagar tudo limpinho.
Esse exercício é o que mais te aproxima do dia a dia profissional.
Gabarito comentado (resumido)
1.1
a) EC2 | b) S3 | c) RDS | d) Application Load Balancer | e) IAM (User + Policy) | f) CloudWatch Alarm + SNS
1.2
Resposta esperada: horizontal. Motivos: 50% de CPU significa que você ainda tem folga de capacidade na máquina atual — a lentidão provavelmente não é CPU. Adicionar uma segunda instância traz 2 ganhos: dobra a capacidade e remove SPOF. Vertical só resolve se você comprovou que o gargalo é CPU/RAM, e mantém o SPOF.
Em qualquer caso, sempre investigue o gargalo antes (CloudWatch + APM) — escalar antes de saber a causa é desperdício.
1.3
SPOFs encontrados:
- EC2 única → Auto Scaling Group multi-AZ atrás de um ALB
- RDS single-AZ → habilitar Multi-AZ
- S3 em uma região → habilitar Cross-Region Replication para outra região
- DNS apontando para IP da EC2 → usar Route 53 apontando para o DNS do ALB (com health check)
Para os exercícios práticos (2.x e 3.x), o gabarito está nos capítulos anteriores desta apostila. Use como referência, mas faça o exercício antes de consultar — errar é parte do aprendizado.