🔧Como esta trilha funciona

Aqui o jogo vira do avesso: em vez de "crie o recurso X", você recebe um chamado — a infraestrutura já existe, já está no ar e está quebrada. Ninguém te diz qual é o defeito. Seu trabalho é investigar e consertar. E a rede funciona de verdade: quando você acerta o conserto, o site volta na hora.

O que você vai treinar

A habilidade que separa quem decorou comandos de quem opera nuvem: diagnosticar sob incerteza. É o que você faz num plantão de verdade, e é o que uma entrevista técnica pergunta — não "qual o comando pra criar uma VPC", mas "o site caiu, e agora?".

O método, passo a passo

• Reproduza o erro primeiro. Antes de mexer em nada, confirme com seus olhos que está quebrado (um curl). É o passo que mais gente pula — e sem ele você não sabe se consertou.
• Ligue as câmeras. Os VPC Flow Logs registram cada tentativa de conexão, com ACCEPT ou REJECT. Sem eles você adivinha; com eles você tem prova.
• Descarte a hipótese óbvia. Todo mundo culpa o security group. Confira e elimine — assim você para de girar em falso na primeira suspeita.
• Siga o caminho do pacote, camada por camada: tabela de rotas → internet gateway → network ACL → security group. O pacote passa por todas, em ordem; o defeito está numa delas.
• Conserte UMA coisa e teste. Se mudar três de uma vez e voltar a funcionar, você não aprendeu qual era o problema — e no próximo plantão vai adivinhar de novo.
• Comprove nos logs. No fim, o grep REJECT mostra exatamente as conexões que estavam sendo barradas, na porta certa. É assim que se fecha um incidente: com evidência, não com "acho que resolveu".

Onde o problema costuma estar

Tabela de rotas

diz pra onde o tráfego vai. Sub-rede pública precisa de uma rota 0.0.0.0/0 apontando pro internet gateway — a falta dela é clássica.

Network ACL

firewall da SUB-REDE. Duas pegadinhas: vale a regra de menor número que casar, e ela não tem estado (precisa liberar entrada E saída).

Security group

firewall da INSTÂNCIA. Esse tem estado: se a entrada é permitida, a resposta volta sozinha. É o suspeito mais acusado e muitas vezes inocente.

ACCEPT / REJECT

o veredito de cada linha do flow log. REJECT numa porta específica aponta o dedo pra quem bloqueou.

Interface de rede (eni-)

o "cabo" da instância. O id dela nos logs é o que liga uma linha de log à máquina certa.

Comandos que você aprende nesta trilha

Cada um deles roda de verdade no terminal do CLImb, com a mesma saída e as mesmas mensagens de erro que a AWS devolve.

aws ec2 create-network-acl-entry --network-acl-id acl-xxxx --rule-number 100 \
--protocol tcp --port-range From=80,To=80 --cidr-block 0.0.0.0/0 \
--rule-action allow --ingress

aws ec2 delete-flow-logs --flow-log-ids fl-xxxx

aws s3 mb s3://<nome-do-bucket>

aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-xxxx \
--traffic-type ALL --log-destination-type s3 \
--log-destination arn:aws:s3:::meu-bucket-de-logs

aws ec2 describe-flow-logs

aws ec2 describe-security-groups

aws ec2 describe-route-tables
aws ec2 describe-route-tables --route-table-ids rtb-xxxx
aws ec2 describe-route-tables --filter "Name=association.subnet-id,Values='subnet-xxxx'"

aws ec2 create-route --route-table-id rtb-xxxx --gateway-id igw-xxxx --destination-cidr-block 0.0.0.0/0

aws ec2 describe-network-acls
aws ec2 describe-network-acls --filter "Name=association.subnet-id,Values='subnet-xxxx'"

aws ec2 delete-network-acl-entry --network-acl-id acl-xxxx --ingress --rule-number 40

aws s3 cp <origem> <destino>

O que você pratica (15 atividades)

Cada atividade é um pedido de trabalho, do jeito que ele chega no dia a dia — você resolve digitando os comandos, não escolhendo alternativa.

Continue por aqui

• 🚀 Primeiros passos
• 🐧 Linux essencial
• 📄 JSON e YAML
• 🪣 S3
• 🖥️ EC2
• 👤 IAM
• ⚡ Lambda
• 🗄️ DynamoDB