FirstDocumentar não é só "fazer o lab"
É registrar o processo: o que era o problema, o que você decidiu fazer e por quê, e o que aprendeu no caminho. É essa parte - não o certificado - que vira material de portfólio de verdade.
O padrão
Uma pasta por dia de estudo, sempre com a mesma estrutura. Assim quem olha seu GitHub entende o ritmo e a evolução sem precisar perguntar nada.
├── guia-lab.md
├── screenshot-resultado.png
└── certificado.png (se disponível)
O que entra no guia-lab.md
-
1
O que é o serviçoDuas ou três frases, com suas próprias palavras - isso já mostra que você entendeu, não só copiou.
-
2
O cenário do problemaQual era a situação fictícia proposta pelo lab, e o que ela pedia.
-
3
O passo a passo do que você fezAs decisões que você tomou no console - não precisa ser um tutorial, é o seu raciocínio.
-
4
O que travou e como resolveuSe algo deu errado ou confundiu, registre. É frequentemente a parte mais interessante pra quem lê.
-
5
O que você aprendeuFechando em 2-3 linhas: o que muda no seu entendimento depois desse lab.
Depois de uns 3 ou 4 labs documentados assim, você já tem material pronto pra virar bullets de projeto no seu currículo - é só voltar pros modelos e preencher.
Veja um exemplo preenchido
Esse é um guia-lab.md real, do lab "Highly Available Web Applications"
do AWS SimuLearn - e, logo abaixo, como esse mesmo lab vira um bullet de currículo.
day-11-highly-available-web-applications/guia-lab.md
O que é o serviço
Nesse lab eu trabalhei com Application Load Balancer (ALB) e EC2 Auto Scaling. O ALB fica na frente da aplicação e distribui as requisições entre várias instâncias, pra nenhum servidor sobrecarregar sozinho. O Auto Scaling group garante um número mínimo de instâncias saudáveis - se uma cai, ele sobe outra automaticamente.
O cenário do problema
Uma agência de viagens fictícia teve um pico de tráfego que derrubou o site, e logo depois uma instância ficou indisponível por estar concentrada numa única Availability Zone instável. O desafio era redesenhar a infraestrutura pra que isso não se repetisse.
O que eu fiz
- Criei um target group e um Application Load Balancer distribuído em 3 Availability Zones.
- Configurei security groups em camadas: o load balancer aceita tráfego público, mas as instâncias só aceitam tráfego vindo dele.
- Configurei um health check customizado e testei o auto-healing encerrando uma instância manualmente.
- No desafio final, estendi de 2 para 3 Availability Zones - e aprendi que também é preciso aumentar a capacidade desejada, não só a rede.
O que travou
A validação continuou falhando mesmo após adicionar a terceira zona - porque eu tinha mudado só a rede, e a capacidade desejada continuava em 2. Só resolveu ao editar a capacidade separadamente.
O que eu aprendi
Auto-healing troca uma instância quebrada por outra igual; alta disponibilidade garante que o serviço continua no ar enquanto essa troca acontece. Configuração de infraestrutura tem camadas independentes (rede, capacidade, security group) que precisam ser alinhadas juntas.
Isso vira o item 4 dos Projetos Acadêmicos no currículo:
4. Alta Disponibilidade com Application Load Balancer e Auto Scaling (AWS)
- Configurei um Application Load Balancer distribuído em 3 Availability Zones com Auto Scaling group, incluindo health checks customizados para detecção rápida de falhas.
- Validei o comportamento de auto-healing na prática, testando substituição automática de instâncias e redundância entre zonas.
Quer ver mais exemplos assim?
O repositório RegiMaria/aws-challenge documenta a trilha inteira, dia a dia, seguindo esse mesmo padrão.