# EC2 Instance Connect Endpoint: acesse EC2 privada sem bastion host

> Crie o EC2 Instance Connect Endpoint e conecte por SSH e RDP numa EC2 de subnet privada, sem bastion host e sem IP público.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Segurança, Rede
- URL: https://pages.formacaoaws.com.br/blog/ec2-instance-connect-endpoint/
- Aula de origem: "EC2 Instance Connect Endpoint: Conheça o novo serviço da AWS para conexão privada com as suas EC2" (https://www.youtube.com/watch?v=Q7-j9xFoRbY)

Para entrar numa EC2 que está em subnet privada, sem IP público, você precisava de um [bastion host](https://pages.formacaoaws.com.br/blog/bastion-host-3-estrategias/). 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.

## Passo 1: security 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.

## Passo 2: liberar 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`.

## Passo 3: lanç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.

## Passo 4: criar 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.

![Lista de security groups na criação do endpoint, com bia-instance-connect marcado](https://pages.formacaoaws.com.br/blog/assets/posts/ec2-instance-connect-endpoint/security-group-do-endpoint.webp)

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**.

## Passo 5: conectar 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.

![Formulário de conexão com IP privado 172.32.128.18, usuário ec2-user, túnel de 3600 segundos e o endpoint selecionado](https://pages.formacaoaws.com.br/blog/assets/posts/ec2-instance-connect-endpoint/conectar-pelo-endpoint.webp)

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

## Passo 6: conectar por SSH pelo terminal

O mesmo acesso funciona pela linha de comando:

```bash
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`](https://docs.aws.amazon.com/cli/latest/reference/ec2-instance-connect/ssh.html) e o [guia de conexão com o endpoint](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-using-eice.html).

![Trecho da documentação com o comando ssh e o parâmetro --connection-type com o valor eice](https://pages.formacaoaws.com.br/blog/assets/posts/ec2-instance-connect-endpoint/comando-cli-eice.webp)

## Passo 7: entrar 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:

```bash
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.

> **Importante:** na primeira tentativa usei o ID da instância Linux no túnel e deu erro. Confira que o ID é o da Windows.

## 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](https://pages.formacaoaws.com.br/blog/acesso-seguro-ao-rds-bastion-host/).

O caminho que funciona para SSH e RDP:

**Fluxo:** Você (console, CLI ou túnel) → Instance Connect Endpoint (security group próprio) → EC2 privada (sem IP público)

## 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.