EC2 not responding? The issue might be here (and it seems too basic to happen)

Angelo Alberto Santos — Thu, 30 Apr 2026 21:46:35 +0000

In day-to-day cloud operations, some incidents stand out not because of their complexity, but quite the opposite.

They are those cases where, once you discover the root cause, you think:
“this can’t be it”.

This is one of them.

⸻

The scenario

The EC2 instance was running, with a public IP and everything seemingly correct.

Status: running
Public IP available
No visible alerts

Even so, every attempt to access it resulted in a timeout.

No clear error. No direct clue.

⸻

Where to look first

In situations like this, before assuming something more complex, the first step is always to review the Security Group.

More specifically: the inbound rules.

⸻

The problem

When analyzing the Security Group, the situation was straightforward:

No inbound rules configured.

This means the instance was not accepting any external connections.
No SSH, no HTTP, no any other port.

This is expected behavior in AWS:
everything is denied by default unless explicitly allowed.

⸻

Why this happens

This type of situation is more common than it seems.

Some examples:

Creating an instance without reviewing the Security Group
Using a default Security Group with no rules
Changes made during testing that were not reverted
Switching Security Groups without proper validation

In the middle of daily operations, this kind of detail is easy to overlook.

⸻

How to fix

The fix is simple: add the required rule to the Security Group.

Example for SSH access:

Type: SSH
Port: 22
Source: your IP (recommended) or 0.0.0.0/0 for testing

After the fix

Once the rule was added, access to the instance was restored immediately.

No restart required. No additional changes needed.

⸻

Practical takeaway

Before assuming complex issues, always check the basics.

In many cases, what looks like a serious incident is just a simple configuration that went unnoticed.

And precisely because it looks simple, it happens more often than expected.

⸻

Quick checklist for unreachable EC2

Security Group
Network ACL
Route Table
Instance status

In most cases, the issue is in the first item.

⸻

Further reading

If you want to dive deeper, the official documentation explains how Security Groups work and how rules are evaluated:

docs.aws.amazon.com

⸻

Note

This content is based on real-world scenarios from day-to-day operations.
AI tools were used only for text review.

EC2 não responde? O erro pode estar aqui (e parece básico demais para acontecer)

Angelo Alberto Santos — Thu, 30 Apr 2026 21:05:20 +0000

No dia a dia de operações em cloud, alguns incidentes chamam atenção não pela complexidade, mas justamente pelo contrário.

São aqueles casos que, quando você descobre a causa, pensa:
“não é possível que foi isso”.

Esse é um deles.

⸻

O cenário

A instância EC2 estava em execução, com IP público e tudo aparentemente correto.

Status: running
IP público disponível
Sem alertas aparentes

Mesmo assim, qualquer tentativa de acesso resultava em timeout.

Sem erro claro. Sem pista direta.

⸻

Onde olhar primeiro

Em situações como essa, antes de pensar em algo mais complexo, o primeiro passo é sempre revisar o Security Group.

Mais especificamente: as regras de entrada (Inbound Rules).

⸻

O problema

Ao analisar o Security Group, o cenário era direto:

Nenhuma regra de entrada configurada.

Isso significa que a instância não aceitava nenhum tipo de conexão externa.
Nem SSH, nem HTTP, nem qualquer outra porta.

É um comportamento esperado da AWS:
tudo é bloqueado por padrão, a menos que seja explicitamente permitido.

⸻

Por que isso acontece

Esse tipo de situação é mais comum do que parece.

Alguns exemplos:

Criação da instância sem revisar o Security Group
Uso de um Security Group padrão sem regras
Alterações feitas durante testes e não revertidas
Troca de Security Group sem validação

No meio da rotina, esse tipo de detalhe passa despercebido com facilidade.

⸻

Como resolver

A correção é simples: adicionar a regra necessária no Security Group.

Exemplo para acesso via SSH:

Tipo: SSH
Porta: 22
Origem: seu IP (recomendado) ou 0.0.0.0/0 para testes

⸻

Após a correção

Depois de adicionar a regra, o acesso à instância foi restabelecido normalmente.

Sem necessidade de reiniciar a instância, sem mudanças adicionais.

⸻

Lição prática

Antes de assumir problemas mais complexos, vale sempre revisar o básico.

Em muitos casos, o que parece um incidente mais sério é apenas uma configuração simples que passou despercebida.

E justamente por parecer simples, é o tipo de erro que mais acontece.

⸻

Checklist rápido para EC2 inacessível

1. Security Group
2. Network ACL
3. Route Table
4. Status da instância

Na maioria das situações, o problema está no primeiro item.

⸻

Leitura complementar

Se quiser se aprofundar, a documentação oficial explica bem como os Security Groups funcionam e como as regras são avaliadas:

docs.aws.amazon.com

⸻

Nota

Este conteúdo foi baseado em cenários reais do dia a dia.
Ferramentas de IA foram utilizadas apenas para revisão do texto.

DEV Community: Angelo Alberto Santos

EC2 not responding? The issue might be here (and it seems too basic to happen)

EC2 não responde? O erro pode estar aqui (e parece básico demais para acontecer)