Pular para o conteúdo principal

Lab: Cenários de Solução de Problemas EC2

Objetivos do Lab​

Este lab coloca você diante de cenários realistas de falha. Para cada cenário, você deverá:

  • Analisar os sintomas
  • Formular hipóteses
  • Propor testes de diagnóstico
  • Identificar a solução
Exercício Teórico

Este lab é um exercício de análise. Não é necessário acesso à AWS - trabalhe em papel ou documento.

Duração Estimada​

1h30 a 2h

Cenário 1: Site Web Inacessível​

Contexto​

Situação:
- Instância EC2 lançada há 1 hora
- AMI: Amazon Linux 2023
- Tipo: t3.micro
- Apache instalado e iniciado
- Você pode se conectar via SSH
- Mas http://52.1.2.3 não responde (timeout)

Configuração atual:
- VPC: vpc-default
- Subnet: pública (com IGW)
- Security Group: sg-web

Informações Disponíveis​

Estado da instância: running
Status checks: 2/2 passed

Security Group sg-web:
Inbound Rules:
- SSH (22): 0.0.0.0/0
- HTTP (80): 10.0.0.0/8

Outbound Rules:
- All traffic: 0.0.0.0/0

Perguntas​

  1. Qual é o sintoma preciso?

  2. Liste 3 hipóteses por ordem de probabilidade

  3. Qual é a causa mais provável?

  4. Qual comando/ação corrige o problema?

  5. Como validar que foi resolvido?

📋 Ver solução

1. Sintoma: Timeout HTTP para 52.1.2.3 porta 80, enquanto SSH funciona.

2. Hipóteses:

  1. Security Group não permite HTTP da Internet (ALTA)
  2. Apache não está ouvindo na porta correta (MÉDIA)
  3. Firewall iptables na instância (BAIXA)

3. Causa: O Security Group permite HTTP (porta 80) apenas de 10.0.0.0/8 (rede privada), não da Internet (0.0.0.0/0).

4. Correção:

aws ec2 authorize-security-group-ingress \
    --group-id sg-web \
    --protocol tcp \
    --port 80 \
    --cidr 0.0.0.0/0

5. Validação:

curl http://52.1.2.3
# ou
Abrir http://52.1.2.3 em um navegador

Cenário 2: SSH Impossível​

Contexto​

Situação:
- Nova instância lançada
- Você baixou a chave .pem
- Instância: running, status checks OK
- IP público: 52.2.3.4

Comando executado:
$ ssh -i chave.pem ec2-user@52.2.3.4
ssh: connect to host 52.2.3.4 port 22: Connection timed out

Informações Disponíveis​

Detalhes da instância:
- ID: i-0123456789
- State: running
- Public IP: 52.2.3.4
- Subnet: subnet-abc123 (10.0.2.0/24)
- Security Group: sg-default

Security Group sg-default:
Inbound Rules:
- (nenhuma regra)

Outbound Rules:
- All traffic: 0.0.0.0/0

Subnet subnet-abc123:
- Route Table: rtb-main
- Routes:
  - 10.0.0.0/16 → local
  - (nenhuma outra rota)

Perguntas​

  1. Identifique TODOS os problemas nesta configuração

  2. Classifique-os por prioridade de correção

  3. Proponha os comandos para corrigir cada problema

📋 Ver solução

1. Problemas identificados:

Problema A - Security Group: Nenhuma regra inbound = porta 22 bloqueada

Problema B - Route Table: Sem rota para Internet Gateway = sem acesso à Internet

2. Prioridade:

  1. Route Table (sem rota, mesmo com SG OK, não funcionará)
  2. Security Group

3. Correções:

# 1. Criar/anexar um Internet Gateway (se ainda não feito)
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --vpc-id vpc-xxx --internet-gateway-id igw-xxx

# 2. Adicionar a rota para o IGW
aws ec2 create-route \
    --route-table-id rtb-main \
    --destination-cidr-block 0.0.0.0/0 \
    --gateway-id igw-xxx

# 3. Adicionar regra SSH ao Security Group
aws ec2 authorize-security-group-ingress \
    --group-id sg-default \
    --protocol tcp \
    --port 22 \
    --cidr 0.0.0.0/0

Cenário 3: Instância Termina Imediatamente​

Contexto​

Situação:
- Você lança uma instância
- Ela passa de "pending" para "running" e depois "terminated"
- Tudo em menos de 30 segundos
- Você tentou 3 vezes, mesmo resultado

Configuração:
- AMI: ami-custom-xyz (AMI personalizada)
- Tipo: t3.large
- Região: us-east-1

Informações Disponíveis​

Console EC2 → State transition reason:
"Client.VolumeLimitExceeded: Volume limit exceeded"

Seus volumes EBS atuais:
- 45 volumes de 100 GB cada
- Total: 4.5 TB

Sua AMI ami-custom-xyz:
- Criada há 6 meses
- Root volume: 200 GB
- Usa o snapshot snap-olddata

Perguntas​

  1. Qual é a causa da terminação?

  2. Como verificar os limites da sua conta?

  3. Quais são as soluções possíveis? (ao menos 3)

📋 Ver solução

1. Causa: A mensagem "Volume limit exceeded" indica que você atingiu o quota de armazenamento EBS da sua conta.

2. Verificar os limites:

aws service-quotas get-service-quota \
    --service-code ebs \
    --quota-code L-D18FCD1D

# Ou via o console:
# Service Quotas → Amazon Elastic Block Store (EBS)

3. Soluções:

Solução A - Excluir volumes não utilizados:

# Listar volumes não anexados
aws ec2 describe-volumes \
    --filters "Name=status,Values=available"

# Excluir
aws ec2 delete-volume --volume-id vol-xxx

Solução B - Solicitar aumento de quota:

aws service-quotas request-service-quota-increase \
    --service-code ebs \
    --quota-code L-D18FCD1D \
    --desired-value 10000

Solução C - Usar outra região: Os quotas são por região. Lançar em eu-west-1, por exemplo.

Solução D - Usar um tipo de instância com instance store: Algumas instâncias possuem armazenamento local, não EBS.

Cenário 4: Banco de Dados Inacessível​

Contexto​

Arquitetura:
- Instância Web (subnet pública): 10.0.1.10
- Instância DB (subnet privada): 10.0.2.20
- Ambas no mesmo VPC

Problema:
- Da instância Web, impossível conectar ao MySQL
- telnet 10.0.2.20 3306 → timeout

A instância DB está funcionando:
- Status checks OK
- MySQL está iniciado (verificado via Session Manager)

Informações Disponíveis​

Security Group sg-web (instância web):
Inbound: HTTP 80, SSH 22
Outbound: All traffic 0.0.0.0/0

Security Group sg-database (instância DB):
Inbound: MySQL (3306) de 0.0.0.0/0
Outbound: All traffic 0.0.0.0/0

NACL da subnet privada (nacl-private):
Inbound Rules:
  Rule 100: DENY TCP 3306 from 0.0.0.0/0
  Rule 200: ALLOW ALL from 0.0.0.0/0
Outbound Rules:
  Rule 100: ALLOW ALL to 0.0.0.0/0

Perguntas​

  1. Por que a conexão falha?

  2. Explique por que a regra do Security Group não é suficiente

  3. Como corrigir o problema?

📋 Ver solução

1. Causa: A NACL bloqueia a porta 3306 com uma regra DENY (rule 100) que é avaliada ANTES da regra ALLOW (rule 200).

2. Explicação:

  • Os Security Groups são avaliados em conjunto (todas as regras)
  • As NACLs são avaliadas na ordem dos números das regras
  • Rule 100 (DENY 3306) é avaliada antes da Rule 200 (ALLOW ALL)
  • Portanto, a porta 3306 é bloqueada apesar do SG

3. Correção: Remover ou modificar a regra 100 da NACL:

# Opção A: Remover a regra DENY
aws ec2 delete-network-acl-entry \
    --network-acl-id nacl-private \
    --rule-number 100 \
    --ingress

# Opção B: Modificar para permitir do subnet web
aws ec2 replace-network-acl-entry \
    --network-acl-id nacl-private \
    --rule-number 100 \
    --protocol tcp \
    --port-range From=3306,To=3306 \
    --cidr-block 10.0.1.0/24 \
    --rule-action allow \
    --ingress

Cenário 5: Permission Denied (Desafio)​

Contexto​

Situação:
- Instância Amazon Linux 2023 lançada com chave "minha-chave"
- Arquivo minha-chave.pem presente em sua máquina
- Permissão do arquivo: 400 (OK)

Comando:
$ ssh -i minha-chave.pem ec2-user@52.5.6.7
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Testes realizados:
- Security Group: porta 22 aberta para 0.0.0.0/0
- Instância: running, status OK
- Ping: funciona

Informações Adicionais​

Você tem dois arquivos de chave na sua pasta:
- minha-chave.pem (criado ontem)
- minha-chave.pem.bak (criado na semana passada)

A instância foi lançada na semana passada.

Perguntas​

  1. Qual é provavelmente a causa?

  2. Como verificar sua hipótese?

  3. Quais são as opções para recuperar o acesso?

📋 Ver solução

1. Causa provável: Você está usando a chave errada. O arquivo "minha-chave.pem" atual (criado ontem) não é a chave associada à instância (lançada na semana passada).

2. Verificação:

# Ver qual chave está associada à instância
aws ec2 describe-instances --instance-ids i-xxx \
    --query 'Reservations[].Instances[].KeyName'

# Comparar a impressão digital da sua chave
ssh-keygen -l -f minha-chave.pem
ssh-keygen -l -f minha-chave.pem.bak

3. Opções de recuperação:

Opção A - Usar a chave correta:

ssh -i minha-chave.pem.bak ec2-user@52.5.6.7

Opção B - EC2 Instance Connect (se AMI compatível): Console → Instância → Connect → EC2 Instance Connect

Opção C - Systems Manager Session Manager: Se o agente SSM estiver instalado e o papel IAM configurado.

Opção D - Criar uma AMI e relançar:

  1. Criar AMI da instância
  2. Lançar nova instância com nova chave
  3. Montar o volume da instância antiga
  4. Modificar ~/.ssh/authorized_keys

Entregáveis do Lab​

Relatório de Solução de Problemas (para 2 cenários à escolha)​

Para cada cenário escolhido, documente:

# Cenário X: [Título]

## 1. Sintoma Identificado
[Descrição precisa]

## 2. Hipóteses Formuladas
1. [Hipótese 1] - Probabilidade: Alta/Média/Baixa
2. [Hipótese 2]
3. [Hipótese 3]

## 3. Testes de Diagnóstico
- Teste 1: [Comando/Ação] → Resultado esperado
- Teste 2: [Comando/Ação] → Resultado esperado

## 4. Causa Raiz
[Explicação da verdadeira causa]

## 5. Solução
[Comandos ou ações para corrigir]

## 6. Validação
[Como verificar que foi resolvido]

## 7. Prevenção
[Como evitar esse problema no futuro]

Grade de Avaliação​

CritérioPontos
Sintoma bem definido2
Hipóteses pertinentes e ordenadas3
Testes de diagnóstico corretos3
Causa raiz identificada3
Solução correta3
Validação proposta2
Clareza e estrutura2
Total por cenário18

Parabéns! Você concluiu o lab de solução de problemas EC2.