DEV Community: Angelo Alberto Santos

teste3

Angelo Alberto Santos — Wed, 30 Sep 2026 20:12:17 +0000

teste3

Managing Private EC2 Instances Without Opening Port 22 Using AWS Systems Manager Session Manager

Angelo Alberto Santos — Wed, 30 Sep 2026 20:10:30 +0000

When we need to manage a Linux instance, SSH is usually one of the first options that comes to mind.

And there is nothing wrong with that. SSH is still a valid solution and can work through private networks, VPNs, Direct Connect, bastion hosts, and other controlled network paths.

But on AWS, there is another option: using AWS Systems Manager Session Manager to establish an administrative session without exposing an inbound port on the instance.

That leads to a more interesting question:

If there is no SSH connection coming into the EC2 instance, how does the administrator reach it?

To answer that, we first need to understand Session Manager before looking at any Terraform code.

What is AWS Systems Manager Session Manager?

Session Manager is a feature of AWS Systems Manager that allows you to establish interactive sessions with machines registered with Systems Manager as Managed Nodes.

For a Linux EC2 instance, the session mainly depends on two sides:

the administrator, authenticated and authorized through IAM;
the SSM Agent running inside the instance.

The administrator requests the session through Systems Manager. The agent maintains the required communication with AWS services and participates in establishing the session channel.

Because this flow does not start with a direct network connection from the administrator to the EC2 instance, there is no need to expose TCP/22 in the instance Security Group for this type of access.

That does not mean the instance can operate without connectivity.

The SSM Agent still needs to reach the required Systems Manager endpoints. We will come back to this because it is one of the most important architectural decisions in this design.

What changes compared to SSH?

Managing Private EC2 Instances Without Opening Port 22 Using AWS Systems Manager Session Manager

Angelo Alberto Santos — Tue, 01 Sep 2026 01:57:32 +0000

teste teste

Angelo Alberto Santos — Tue, 01 Sep 2026 01:20:50 +0000

teste teste

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.