Existe um momento muito comum em projetos de cloud que eu chamo de “o SSH do desespero”: o ambiente está quase pronto, o banco de dados subiu, mas na hora de acessar a instância para validar a configuração, a equipe percebe que não tem bastion host, a porta 22 não está liberada e a deadline está chegando. A solução rápida vira um buraco de segurança que ninguém fecha depois.
Esse artigo é sobre como evitar exatamente esse cenário usando o AWS Systems Manager Session Manager, a partir de um caso real que vivi com um cliente.
O contexto: PostgreSQL em EC2 por escolha estratégica
Antes de falar da solução, preciso contextualizar a decisão de arquitetura porque ela importa.
Muita gente vai dizer que banco de dados em EC2 é errado por padrão. Eu discordo. Em alguns cenários, o RDS ou o Aurora não são a escolha certa, principalmente quando o cliente tem restrição de custo significativa, já tem expertise operacional para gerenciar PostgreSQL, ou precisa de configurações específicas de extensões e parâmetros que os serviços gerenciados não permitem.
Nesse caso, o cliente escolheu subir o PostgreSQL em uma EC2 por questões de custo. Decisão válida, consciente e documentada. Meu papel como arquiteta foi garantir que essa escolha fosse implementada com segurança, não tentar convencer o cliente a mudar de ideia.
E é exatamente aqui que o SSM entra como peça fundamental da arquitetura.
O que é o AWS Systems Manager Session Manager
O Session Manager é um recurso do AWS Systems Manager que permite abrir sessões interativas em instâncias EC2 sem precisar de SSH, sem bastion host e sem abrir nenhuma porta de entrada no Security Group.
A comunicação acontece de forma inversa ao que estamos acostumados: o SSM Agent instalado na instância inicia uma conexão de saída para o endpoint do Systems Manager. Você, na sua máquina local, se conecta a esse canal já estabelecido via AWS CLI. A instância nunca precisa aceitar conexões de entrada.
Isso muda a postura de segurança completamente. Não há porta 22 exposta. Não há chave SSH para gerenciar ou vazar. Não há bastion host para manter, atualizar e pagar.
Referência oficial: AWS Systems Manager Session Manager
O que você precisa para funcionar
A configuração tem três partes: a instância, as permissões e a sua máquina local.
Na instância EC2
O SSM Agent precisa estar instalado e rodando. Nas AMIs Amazon Linux 2, Amazon Linux 2023 e Ubuntu fornecidas pela AWS ele já vem instalado por padrão. Se você estiver usando uma AMI customizada ou um sistema operacional diferente, precisará instalar manualmente.
Documentação de instalação: Instalar SSM Agent em Linux
A instância também precisa ter conectividade de saída para o endpoint do Systems Manager. Isso pode ser feito via NAT Gateway (se estiver em subnet privada) ou via VPC Endpoints do SSM (se quiser evitar o custo do NAT Gateway ou manter tudo dentro da rede AWS).
Os três endpoints necessários quando se usa VPC Endpoint são:
com.amazonaws.REGIÃO.ssm
com.amazonaws.REGIÃO.ssmmessages
com.amazonaws.REGIÃO.ec2messagesNas permissões IAM
A instância precisa de uma IAM Role com a policy AmazonSSMManagedInstanceCore anexada. Na prática, basta usar a managed policy em vez de criar a policy manualmente.
Para o usuário ou role que vai iniciar a sessão, a permissão mínima necessária é:
{
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": [
"arn:aws:ec2:REGIÃO:CONTA:instance/INSTANCE_ID",
"arn:aws:ssm:*:*:document/AWS-StartSSHSession"
]
}Referência: Controle de acesso por IAM no Session Manager
Na sua máquina local
Você precisa da AWS CLI instalada e do plugin do Session Manager. Documentação completa: Instalar o Session Manager Plugin
# Instalação do plugin no macOS
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
unzip sessionmanager-bundle.zip
sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-pluginComo abrir uma sessão
Com tudo configurado, abrir uma sessão interativa na instância é um único comando:
aws ssm start-session --target i-0abc123def456789Você cai direto em um shell na instância, sem senha, sem chave, sem SSH.
Para verificar se a instância está aparecendo como gerenciada pelo SSM:
aws ssm describe-instance-information --query "InstanceInformationList[*].[InstanceId,PingStatus,PlatformName]" --output tablePor que isso importa além do acesso remoto
Quando você começa a usar o Session Manager, percebe que ele resolve mais do que o problema de acesso. Ele resolve governança.
Toda sessão aberta fica registrada no AWS CloudTrail. Você sabe quem abriu, quando abriu e quanto tempo ficou conectado. Se configurar o Session Manager com S3 ou CloudWatch Logs, os comandos executados durante a sessão também ficam registrados.
Para o cliente com PostgreSQL em EC2, isso foi um argumento importante. Não era só sobre economizar o custo de um bastion host. Era sobre ter auditabilidade completa de quem acessa o banco de dados, algo que auditorias de segurança e compliance cobram com frequência.
O Security Group fica limpo
No caso do cliente, o Security Group da instância EC2 com o PostgreSQL ficou assim:
Inbound rules: nenhuma regra
Outbound rules: HTTPS 443 para o endpoint do SSM (ou para o NAT Gateway)Sem porta 22. Sem porta 5432 exposta. O banco de dados não é alcançável de fora da VPC por nenhum protocolo direto. Isso é o que eu chamo de menor superfície de ataque real, não só no papel.
O que vem na Parte 2
Acesso interativo à instância resolve uma parte do problema. Mas no caso do cliente, a necessidade era mais específica: conectar ferramentas locais como DBeaver ou pgAdmin diretamente no PostgreSQL rodando na EC2, sem expor a porta 5432 para a internet.
A solução é o Port Forwarding via Session Manager, que é exatamente o que vou cobrir na Parte 2.
Referência oficial: Port Forwarding Using AWS System Manager Session Manager
Tem dúvidas sobre configuração do SSM no seu ambiente ou quer discutir quando faz sentido PostgreSQL em EC2 versus RDS? Me chama no LinkedIn ou deixa nos comentários.