Solução de Problemas de Conectividade e Erros Comuns em Instâncias EC2

Conectar-se a uma instância Amazon Elastic Compute Cloud (EC2) é fundamental para gerenciar seus recursos na nuvem. Seja usando SSH para instâncias Linux ou Remote Desktop Protocol (RDP) para instâncias Windows, falhas de conectividade são comuns e muitas vezes frustrantes. Este guia fornece uma abordagem sistemática e passo a passo para diagnosticar e resolver as razões mais frequentes pelas quais você pode não conseguir acessar sua instância EC2.

Compreender as falhas de conectividade requer olhar além da própria instância. Os problemas geralmente decorrem de configurações incorretas nas camadas de segurança (Grupos de Segurança, NACLs), configuração de rede incorreta (roteamento VPC) ou problemas de autenticação. Ao verificar metodicamente esses componentes em ordem, você pode isolar rapidamente a causa raiz e restaurar o acesso.

Fase 1: Verificações Iniciais e Saúde da Instância

Antes de mergulhar em configurações de rede complexas, certifique-se de que a instância está funcionando corretamente e acessível em um nível fundamental.

1. Verificações de Status da Instância

Use o Console de Gerenciamento da AWS ou a AWS CLI para verificar a saúde geral da instância. Duas verificações cruciais devem ser aprovadas:

Verificações de Status do Sistema: Falhas aqui geralmente indicam problemas de hardware ou infraestrutura subjacentes que exigem intervenção da AWS ou término/recriação da instância.
Verificações de Status da Instância: Falhas aqui geralmente se relacionam a problemas de boot do sistema operacional, corrupção do sistema de arquivos ou problemas de driver. Se isso falhar, a instância provavelmente está com a saúde comprometida o suficiente para rejeitar conexões de rede.

Ação: Se alguma verificação falhar, considere parar e iniciar a instância (o que a move para um novo hardware se a verificação do sistema falhar) ou verificar o Log do Sistema em busca de pistas.

2. Verificando o Endereço IP Público e o Nome DNS

Certifique-se de que você está tentando se conectar ao endereço correto. Se sua instância estiver em uma sub-rede pública, ela requer um Endereço IPv4 Público ou um IP Elástico. Se estiver em uma sub-rede privada, você deve se conectar via um Host Bastion ou usar o AWS Systems Manager Session Manager.

Dica: Se a instância foi parada e iniciada, seu endereço IP público pode ter mudado, a menos que você tenha atribuído um IP Elástico.

3. Verificando a Configuração do Cliente (SSH/RDP)

Erros de conectividade são às vezes locais. Verifique se o seu software cliente está funcionando corretamente.

Para SSH (Linux/macOS): Certifique-se de que você está usando o arquivo de chave privada correto (.pem ou .ppk) e que as permissões estão configuradas corretamente (chmod 400 /caminho/para/chave.pem).
Para RDP (Windows): Certifique-se de que você está usando a senha correta obtida descriptografando a senha do administrador usando o arquivo de chave privada no console EC2.

Fase 2: Diagnóstico das Camadas de Segurança (As Falhas Mais Comuns)

Configurações de segurança incorretas são a principal causa de problemas de conectividade. Tanto os Grupos de Segurança quanto as NACLs atuam como firewalls, e ambos devem permitir o tráfego necessário.

4. Regras de Ingressão do Grupo de Segurança (SG)

Grupos de Segurança são firewalls com estado anexados diretamente à Interface de Rede Elástica (ENI) da instância.

Requisitos para Linux (SSH):

Protocolo: TCP
Intervalo de Portas: 22
Origem: Seu endereço IP público (Meu IP) ou 0.0.0.0/0 (para todos os IPs, embora isso seja desencorajado por segurança).

Requisitos para Windows (RDP):

Protocolo: TCP
Intervalo de Portas: 3389
Origem: Seu endereço IP público ou 0.0.0.0/0.

Passo de Solução de Problemas: Altere temporariamente a origem da regra de ingressão necessária para 0.0.0.0/0 para a porta relevante (22 ou 3389). Se você conseguir se conectar, o problema foi que seu endereço IP de cliente específico foi bloqueado ou não identificado corretamente.

Aviso: Nunca deixe grupos de segurança abertos para 0.0.0.0/0 para portas de gerenciamento (22/3389) em ambientes de produção. Use IPs de origem específicos ou endpoints VPC quando possível.

5. NACLs de Rede (NACLs)

NACLs de Rede são firewalls sem estado, em nível de sub-rede. Elas verificam o tráfego de entrada e saída independentemente. Se o tráfego for permitido na entrada, o tráfego de retorno também deve ser permitido na saída.

Requisitos de NACL para Conectividade:

Direção	Protocolo	Intervalo de Portas	Ação da Regra
Entrada	TCP	22 (SSH) ou 3389 (RDP)	Permitir
Saída	TCP	Portas Efêmeras (1024-65535)	Permitir

As portas efêmeras são críticas. Quando seu cliente se conecta (por exemplo, da porta 54321), o servidor responde em uma porta efêmera de alto número. Se a NACL bloquear o tráfego de saída nessas portas altas, o servidor não poderá enviar a resposta de volta para você, resultando em um timeout de conexão.

Passo de Solução de Problemas: Verifique se tanto a porta de entrada (22/3389) quanto as portas efêmeras de saída (1024-65535) têm uma regra de Permitir na NACL associada.

Fase 3: Roteamento e Configuração da VPC

Se as camadas de segurança estiverem confirmadas como abertas, o problema está em como o tráfego é roteado para e da sub-rede da instância.

6. Tipo de Sub-rede e Tabelas de Roteamento

A conectividade depende inteiramente se sua instância está em uma Sub-rede Pública ou em uma Sub-rede Privada.

Conectividade em Sub-rede Pública

Para acesso direto à internet (SSH/RDP do mundo exterior):

A instância deve ter um endereço IPv4 público ou IP elástico atribuído.
A Tabela de Roteamento associada deve ter uma rota para 0.0.0.0/0 apontando para um Gateway de Internet (IGW).

Conectividade em Sub-rede Privada

Instâncias em sub-redes privadas não podem ser alcançadas diretamente da internet. A conexão requer um caminho de múltiplos saltos:

Conexão via Host Bastion (Jump Box): Você se conecta via SSH a uma instância EC2 pública e, em seguida, se conecta via SSH do Host Bastion para a instância privada (usando seu IP Privado).
Conexão via VPN/Direct Connect: Se estiver usando AWS Site-to-Site VPN ou Direct Connect, o roteamento deve ser configurado para direcionar o tráfego para sua rede local, que então roteia para a sub-rede privada.

7. Problemas de Firewall no Nível do SO

Se as verificações de segurança da AWS passarem, o sistema operacional em execução na própria instância EC2 pode estar bloqueando a conexão. Isso é comum se você instalou ou configurou manualmente firewalls locais (como iptables no Linux ou o Firewall do Windows Defender).

Diagnóstico (Se possível via Console ou Session Manager):

Linux: Verifique iptables -L ou use firewall-cmd --list-all. Certifique-se de que a porta 22 está explicitamente permitida.
Windows: Verifique as configurações do Firewall do Windows Defender para regras de entrada na porta 3389.

Dica de Recuperação: Se você perdeu toda a conectividade, considere parar a instância, desanexar o volume raiz, anexá-lo a uma instância de recuperação funcional, modificar os arquivos de configuração do SO para desabilitar o firewall e, em seguida, reanexar o volume ao ID da instância original.

Resumo do Fluxo de Solução de Problemas

Quando a conectividade falhar, siga esta lista de verificação priorizada:

Saúde da Instância: As verificações de status do Sistema/Instância estão passando?
Autenticação do Cliente: O arquivo de chave está correto e com as permissões adequadas (SSH)?
Grupo de Segurança: O SG permite tráfego de entrada na Porta 22/3389 do seu IP?
NACLs: A NACL permite tráfego de entrada (22/3389) E saída (1024-65535)?
Roteamento: A Tabela de Roteamento aponta para um IGW para sub-redes públicas?
Firewall do SO: O firewall local na instância EC2 está permitindo a conexão?

Ao revisar sistematicamente essas seis áreas, você pode resolver com confiança a grande maioria das falhas de conectividade do EC2.