EC2 Instance Connect Endpoint: acesse EC2 privada sem bastion host

Para entrar numa EC2 que está em subnet privada, sem IP público, você precisava de um bastion host. O EC2 Instance Connect Endpoint faz essa ponte no lugar dele, sem custo. Aqui estão os passos para criar o endpoint e conectar por SSH numa Linux e por RDP numa Windows.

O que o endpoint resolve

O bastion host é uma instância intermediária, com acesso público, que serve de ponte até os recursos. Com o endpoint, todos eles ficam em subnet privada, o que é um grande ganho de segurança. Você não paga nada para usá-lo.

Ele é um serviço gerenciado pela AWS e entra na sua VPC como um VPC Endpoint. A comunicação entre o endpoint e as instâncias, Linux ou Windows, é controlada por security group. Continua valendo o custo de transferência entre subnets, o mesmo que você já paga hoje.

O cenário do laboratório

Usei uma VPC com duas subnets privadas, A e B. No mapa da VPC não há internet gateway nem NAT gateway, só um Gateway Endpoint para o S3, que não dá saída para a internet e não interfere neste teste.

Precisamos de três security groups: o do endpoint (bia-instance-connect), o da EC2 Linux, para SSH, e o da EC2 Windows, para RDP.

1Security group do endpoint

O security group do endpoint não precisa de nenhuma regra de entrada. Na saída, você pode deixar tudo liberado ou restringir às instâncias que quer alcançar: a porta SSH da Linux e a porta RDP da Windows.

2Liberar a entrada nas EC2

Quem precisa de regra de entrada são as EC2, e a origem da regra é o security group do endpoint:

1. Na Linux, deixe só a entrada SSH, com origem em bia-instance-connect. Eu encontrei uma regra "All Traffic" e troquei, porque o mais adequado é liberar só o SSH.
2. Na Windows, deixe só a entrada RDP, também com origem em bia-instance-connect.

3Lançar as duas EC2 em subnet privada

Lancei uma Windows e uma Linux, ambas t3.micro. Na Windows, usei um par de chaves, porque é com ele que se recupera a senha depois.

Em rede, escolha a VPC do laboratório e uma das subnets privadas, sem IP público, e o security group de cada instância. Sem IP público, não há como se conectar de fora. É aqui que o endpoint entra.

4Criar o EC2 Instance Connect Endpoint

No console da VPC, no menu lateral:

1. Abra Endpoints e clique em criar um endpoint.
2. Dê um nome. Eu usei ec2-instance-connect-endpoint.
3. Em categoria de serviço, marque EC2 Instance Connect Endpoint.
4. Escolha a VPC e o security group do endpoint (bia-instance-connect).
5. Escolha uma subnet e crie.

O endpoint demora um pouco para ficar disponível. Enquanto o status está pendente, a conexão não funciona: espere ele ir para Available.

5Conectar por SSH pelo console

Na lista de instâncias, selecione a Linux, clique em Connect e vá na aba EC2 Instance Connect. Há duas formas:

• Connect using EC2 Instance Connect: exige IP público. Não é o nosso caso.
• Connect using EC2 Instance Connect Endpoint: usa o IP privado da instância.

Marque a segunda. O console mostra o IP privado, o usuário (ec2-user), o tempo máximo do túnel e o campo do endpoint, onde você seleciona o que criou.

Clique em Connect. Entrei na instância pelo navegador, rodei pwd e atualizei os pacotes com sudo, sem IP público e sem bastion.

6Conectar por SSH pelo terminal

O mesmo acesso funciona pela linha de comando:

aws ec2-instance-connect ssh --instance-id <id-da-instancia>

Troque <id-da-instancia> pelo ID da sua EC2. Rodei primeiro no CloudShell, que dispensa ir para a sua máquina, e funcionou. Depois rodei na minha máquina, acrescentando o profile com as permissões IAM da conta, e o resultado foi o mesmo.

Na documentação que mostrei, o comando aceita ainda o parâmetro --connection-type eice, para indicar que a conexão é pelo endpoint. Nos meus testes rodei sem ele. Veja a documentação do ec2-instance-connect ssh e o guia de conexão com o endpoint.

7Entrar na Windows por RDP

Na Windows muda uma coisa: você precisa abrir um túnel. A instância não é pública, então não há endereço remoto para informar ao cliente RDP. Você roteia a porta 3389 da instância para a porta 3389 local:

aws ec2-instance-connect open-tunnel --instance-id <id-da-windows> --remote-port 3389 --local-port 3389 --profile <seu-profile>

O terminal responde que está escutando a porta 3389. Para a senha do Administrator, use Get Password na instância, com o par de chaves do lançamento.

Depois é só abrir o cliente de área de trabalho remota. Eu estava no Linux e usei o Remmina: servidor localhost, usuário Administrator e a senha recuperada. Tive que reduzir a quantidade de cores da conexão, senão ela não funcionava.

O que o endpoint ainda não resolve

O túnel só está disponível para as portas 22 e 3389, até o momento. Para chegar a um PostgreSQL na porta 5432, a um RDS ou a um Redis ou Memcached privado, você ainda precisa de um bastion host para rotear o tráfego, criando o túnel. Pode ser que a AWS libere outras portas no futuro. O exemplo do RDS está em Acesso seguro ao RDS: bastion host e túnel SSH.

O caminho que funciona para SSH e RDP:

Checklist

• Crie um security group para o endpoint, sem regra de entrada.
• No security group de cada EC2, libere a entrada só da porta necessária (SSH ou RDP), com origem no security group do endpoint.
• Lance as instâncias em subnet privada, sem IP público.
• Crie o endpoint na VPC, com o security group dele, e espere o status Available.
• Conecte por SSH pelo console, na aba EC2 Instance Connect, ou pelo comando aws ec2-instance-connect ssh.
• Na Windows, abra o túnel na porta 3389 com open-tunnel e conecte o cliente RDP em localhost.
• Mantenha o bastion host para RDS, Redis ou qualquer porta diferente de 22 e 3389.