VPC Peering: conectando redes privadas entre contas e regiões na AWS

Bianca Szimanski — Sun, 13 Sep 2026 02:44:25 +0000

1. Cenário de negócio

Neste projeto, será implementado um VPC peering entre duas VPCs que estão em contas e regiões distintas, sendo uma conta de infraestrutura e outra de segurança. Em ambientes corporativos, é comum que empresas adotem uma estratégia multi-account para isolar recursos e dividir responsabilidades por área. Por exemplo, o gerenciamento de DNS via Route 53, processos de backup e pipelines de CI/CD, podem ser centralizados na conta de infraestrutura, enquanto a conta de segurança pode ser utilizada para centralizar scanners de vulnerabilidade, soluções de VPN, SIEM e outros serviços voltados à proteção e auditoria do ambiente.

Quando um recurso hospedado na VPC de infraestrutura precisa se comunicar com os serviços da VPC de segurança, é necessário estabelecer uma integração de rede privada entre as contas. Para esse tipo de comunicação direta, o VPC peering é uma solução adequada em ambientes menores ou de arquitetura simples. Em empresas de maior porte ou com requisitos de escalabilidade, o Transit Gateway atende melhor.

2. Arquitetura do ambiente

Foram criadas duas contas, sendo a BS-Infra responsável pela infraestrutura, onde estão hospedados, por exemplo, um servidor de aplicação e um banco de dados em subnets privadas, além de um servidor de testes em subnet pública. Já a conta BS-Security possui uma subnet pública, também utilizada por um servidor de testes e duas subnets privadas, sendo uma destinada ao servidor de VPN e outra voltada à servidores que hospedam ferramentas de segurança, como Wazuh e Vault, por exemplo. Em ambas as contas, o servidor de testes foi provisionado apenas para validar a conectividade do VPC peering.

Os workloads das duas contas estão distribuídos em 3 zonas de disponibilidade, em duas regiões diferentes. Em cenários reais, o ideal é distribuir os workloads estrategicamente entre diferentes AZs para garantir alta disponibilidade. Já a escolha por múltiplas regiões, normalmente é pensada em disaster recovery, custo, latência ou normas de compliance que não permitem que determinados dados sejam hospedados fora do país de origem.

As subnets privadas possuem tabelas de rotas configuradas para direcionar o tráfego de saída para um NAT gateway, permitindo o acesso à internet (por exemplo, para atualização de pacotes e instalação de dependências) sem expor diretamente os recursos internos. O NAT gateway, por padrão, é provisionado em uma subnet pública, mesmo que o roteamento seja originado das subnets privadas, pois é necessário realizar a tradução de endereços de origem (SNAT), substituindo os IPs privados das instâncias por um endereço IP público associado ao NAT gateway. Já a subnet pública é associada a uma tabela de rotas que possui um caminho para um internet gateway anexado à VPC, permitindo o tráfego bidirecional, ou seja, a comunicação de entrada e saída com a internet. Em situações reais, jamais se deve colocar um banco de dados ou servidor de aplicação em subnets públicas, por questões de segurança.

Será realizado um peering entre as duas VPCs, com o objetivo de estabelecer uma comunicação privada e direta entre elas, sem que o tráfego precise passar pela internet pública.

O ambiente também conta com o VPC Flow Logs, que realiza a captura do tráfego das VPCs (como IPs de origem/destino, portas e protocolo, e se o tráfego foi aceito ou rejeitado). Esses logs serão centralizados no CloudWatch, facilitando análise e troubleshooting de conectividade. Vale mencionar que, em cenários corporativos com alto volume de tráfego, outra alternativa comum é enviar os flow logs diretamente para um bucket S3 e utilizar o Amazon Athena para realizar consultas SQL sob demanda.

3. Elementos Chave

Esta seção descreve os principais componentes utilizados na implementação. Cada um deles tem um papel específico para garantir que a comunicação entre as VPCs funcione corretamente.

3.1. VPC Peering

Estabelece uma comunicação privada e direta entre duas VPCs, podendo ser na mesma conta, entre contas diferentes ou até entre regiões diferentes. O tráfego entre as VPCs não passa pela internet pública, ele é roteado diretamente pela infraestrutura da AWS, o que garante menor latência e maior segurança. Para funcionar, além de criar a conexão de peering, é necessário configurar as tabelas de rotas de ambas as VPCs e ajustar os security groups para permitir o tráfego entre os CIDRs envolvidos. Vale destacar que o VPC peering não é transitivo, ou seja, se a VPC A tem peering com a VPC B, e a VPC B tem peering com a VPC C, a VPC A não consegue se comunicar com a VPC C automaticamente. Cada conexão precisa ser estabelecida de forma independente. Trata-se de uma conexão ponto a ponto.

Documentação: https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html

3.2. NAT Gateway (NGW)

Permite que recursos (neste caso, as duas instâncias) em subnets privadas enviem tráfego para a internet, sem que a internet estabeleça conexões diretas com esses recursos. Isso é possível graças ao processo de SNAT (Source Network Address Translation), que substitui o IP privado da origem pelo IP público do NAT gateway antes de encaminhar o pacote para a internet. Quando a resposta retorna, o NAT gateway realiza o processo inverso, entregando o tráfego ao recurso correto dentro da subnet privada. Por esse motivo, o NAT gateway deve ser provisionado em uma subnet pública, pois é necessário ter um IP público para executar essa tradução.

Documentação: https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html

3.3. Internet Gateway (IGW)

Permite o tráfego bidirecional entre recursos em subnets públicas e a internet. Para isso, o recurso precisa de um IP público associado e uma rota configurada apontando para o internet gateway. Diferentemente do NAT gateway, a comunicação por meio do internet gateway ocorre nos dois sentidos, então, a instância pode iniciar conexões com a internet, e a internet também pode iniciar conexões com a instância. Na prática, um bom exemplo é um servidor web em subnet pública, onde ele recebe requisições HTTPS de usuários na internet e responde a elas (pode ser um site institucional, um portal acessível externamente ou uma API consumida por um aplicativo, por exemplo). Outro exemplo comum é um bastion host, que pode ficar em uma subnet pública para permitir que administradores acessem os recursos internos, seja via SSH (em ambientes Linux) ou RDP (em ambientes Windows), funcionando como um ponto de entrada controlado.

Documentação: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html

3.4. Route Tables

As tabelas de rotas definem como o tráfego de rede é roteado dentro da VPC, direcionando os pacotes para destinos como NAT gateway, internet gateway, conexões de VPC peering, entre outros.

Documentação: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html

3.5. Security Groups

Atuam como um firewall a nível de instância, controlando o tráfego de entrada e saída. Por exemplo, para acesso via SSH, é necessário permitir a porta 22 no security group e restringir o IP de origem. No entanto, em ambientes mais seguros, é comum utilizar bastion host ou acesso via AWS SSM, eliminando a necessidade de exposição dessa porta. Um ponto importante é que os security groups são stateful, ou seja, ao permitir o tráfego de entrada em uma porta, a resposta desse tráfego é automaticamente permitida na saída, sem precisar criar uma regra explícita para isso, diferente das NACLs (Network Access Control List), que atuam a nível de subnet e são stateless, exigindo regras explícitas para entrada e saída. Em ambientes corporativos, o ideal é utilizar os dois em conjunto, para garantir uma melhor proteção dos recursos.

Documentação SG: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html
Documentação NACL: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html

3.6. VPC Flow Logs

Permite capturar informações sobre o tráfego de IP de entrada e saída das interfaces de rede da VPC. Os dados coletados incluem IPs de origem e destino, portas, protocolo e se o tráfego foi aceito ou rejeitado, o que o torna uma ferramenta muito útil para troubleshooting de conectividade (por exemplo, como identificar problemas de comunicação entre duas instâncias, detectar tráfego de rede suspeito, etc). Os logs podem ser publicados no CloudWatch Logs, S3 ou Data Firehose, dependendo da necessidade da empresa e do volume de dados.

Documentação: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html

4. Implementação

Durante a implementação, os seguintes recursos serão configurados:

Contas AWS: duas contas ativas (BS-Infra e BS-Security), com permissão para criar os recursos.
VPCs: será criada uma em cada conta, com blocos CIDR privados que não se sobrepõem e seguem as diretrizes da RFC 1918. As subnets públicas e privadas foram criadas dentro do intervalo de endereçamento de cada VPC e associadas às suas respectivas tabelas de rotas.
NAT Gateway e Internet Gateway: serão configurados e associados às subnets corretas.
Security Groups: serão configurados para permitir apenas o tráfego entre as VPCs envolvidas no peering.
VPC Flow Logs: serão configurados em ambas as VPCs, com os logs publicados no CloudWatch.
Instâncias EC2: será criada uma em cada conta para realizar um teste (srv-infra-test e srv-sec-test).

5. Passo a passo

5.1. Criação das VPCs, subnets e tabelas de rotas

Nesta etapa, serão criadas as VPCs em cada conta, seguidas de duas subnets privadas e uma pública, distribuídas entre diferentes zonas de disponibilidade.
Conta: BS-Infra | Região: us-east-1 | VPC: VPC-BS-INFRA

1.Acessar o serviço de VPC e clicar em “Create VPC”:

A opção “VPC only” foi selecionada, permitindo que as subnets e demais recursos sejam configurados manualmente posteriormente. No campo “IPv4 CIDR”, será utilizado o bloco 172.31.0.0/16, que está contido dentro da faixa privada 172.16.0.0/12 definida pela RFC 1918. Essa norma estabelece 3 blocos de endereços IP reservados para redes privadas, sendo 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16.

A VPC foi criada com sucesso:

OBS: Quando há mais de uma VPC na conta, é possível filtrar a que está sendo utilizada no momento, para facilitar a visualização e organização:

2.Agora, será necessário criar as 3 subnets da VPC-BS-INFRA, conforme o diagrama:

Subnet INFRA-PRIVATE-APP

Selecionar a aba “Subnets” e clicar em “Create subnet”:

Em seguida, selecionar a VPC-BS-INFRA, definir o nome da subnet, IP e zona de disponibilidade.

OBS: no momento de definir o bloco CIDR da subnet, deve-se prestar atenção para que o bloco CIDR da subnet esteja contido dentro do bloco CIDR da VPC, pois a subnet é uma subdivisão da rede principal. Neste caso, vamos trabalhar com a máscara /16 para a rede, o que nos dá 65.536 endereços IP disponíveis, e /24 para as subnets, cada uma com 256 endereços, garantindo que cada subnet caiba perfeitamente dentro da VPC:

OBS: caso não seja necessário definir uma zona de disponibilidade, é possível selecionar a opção “No preference”. Neste caso específico, vamos trabalhar com a AZ A (us-east-1a), na subnet 1.

Já que serão criadas 3 subnets na mesma VPC, podemos criar as outras duas clicando em “Add new subnet” e por fim, “Create subnet” para concluir:

As 3 subnets foram criadas com sucesso:

OBS: a tabela abaixo explica o que significa cada coluna da aba “Subnets”:

3.Agora, será necessário criar as tabelas de rotas da VPC-BS-INFRA, para definir o roteamento das subnets privadas e da pública.

Ao criar uma VPC, a AWS provisiona automaticamente uma tabela de rotas principal, contendo uma única rota local (neste caso,a nossa VPC 172.31.0.0/16), que permite a comunicação interna entre todas as subnets da VPC. Subnets sem associação explícita herdam essa tabela por padrão:

Podemos renomeá-la como RTB-BS-INFRA-PRIVATE e torná-la a tabela de rotas para as duas subnets privadas:

Para editar, basta clicar em “Edit subnet associations”, na aba “Subnet associations” e selecionar as subnets privadas:

No final, as subnets ficarão associadas dessa forma:

Agora, será necessário clicar em “Create route table” para criar a tabela de rotas para a subnet pública:

OBS: o ideal, por boas práticas de arquitetura na AWS, é que sejam criadas route tables separadas para subnets públicas e privadas, mantendo cada camada com apenas as rotas necessárias para sua função.

Subnets públicas: route table com rota 0.0.0.0/0 apontando para um internet gateway.

Subnets privadas: route table com rota 0.0.0.0/0 apontando para um NAT gateway (ou sem rota de saída, se não precisar sair para a internet).

Por que separar?

Controle granular de tráfego por camada (aplicação, banco de dados, ferramentas, etc).
Subnets privadas não ficam expostas diretamente à internet.
Facilita aplicar regras diferentes por ambiente ou serviço.
Segurança por princípio do menor privilégio.

Após clicar em “Create route table”, será necessário inserir um nome (neste caso, será RTB-BS-INFRA-PUBLIC para a subnet pública) e selecionar a VPC:

Para editar, basta clicar em “Edit subnet associations”, na aba “Subnet associations” e selecionar a subnet pública:

Ficará dessa forma:

Ao finalizar, teremos duas tabelas de rotas:

No entanto, ainda não existe conectividade de rede para nenhuma das subnets. Por isso, agora será necessário configurar o internet gateway para a subnet pública e o NAT gateway para as subnets privadas.

OBS: lembrando que o uso do NAT gateway não é obrigatório. Ele só é necessário quando os recursos em subnets privadas precisam sair para a internet de forma segura (por exemplo, para atualizar pacotes de software ou instalar dependências). No geral, o que torna uma subnet privada é simplesmente não possuir uma rota para o internet gateway na tabela de rotas. Isso por si só já a define como privada.

Em seguida, será necessário criar um internet gateway. Para isso, será necessário acessar a aba “Internet gateway” e clicar em “Create internet gateway”:

Definir o nome, neste caso, será IGW-BS-INFRA-PUBLIC:

Após a criação do IGW, será necessário vinculá-lo à VPC-BS-INFRA, clicando em “Actions” e “Attach to VPC”:

Em seguida, podemos voltar na aba “Route tables” e apontar a rota da subnet pública para o IGW que foi criado, clicando em “Routes” e “Edit routes”:

Devemos definir o destino 0.0.0.0/0, selecionar a opção “Internet Gateway” e escolher o IGW que foi criado anteriormente:

Por fim, a tabela de rotas ficará com duas rotas configuradas, sendo uma rota local para comunicação interna da VPC (172.31.0.0/16) e uma rota padrão apontando para o internet gateway, permitindo tráfego de entrada e saída com a internet (0.0.0.0/0):

Em seguida, podemos criar o NAT gateway, vinculá-lo à VPC-BS-INFRA e prosseguir com a configuração na tabela de rotas da mesma forma.

OBS: o NAT gateway necessita estar em uma subnet pública e com um Elastic IP alocado para funcionar corretamente. Ao selecionar a opção “Allocate Elastic IP”, é criada uma interface de rede com dois IPs: um público, utilizado para realizar o SNAT e se comunicar com a internet, e um privado, utilizado para a comunicação interna dentro da VPC.

Sendo assim, podemos criar o NAT gateway. Para isso, será necessário acessar a aba “NAT gateways” e clicar em “Create NAT gateway”:

Abaixo, alguns detalhes importantes na página de criação do NGW:

Availability mode:

Zonal: o NAT gateway fica em uma única AZ. Se essa AZ cair, as subnets privadas daquela AZ perdem saída para internet. É mais barato.
Regional: o NAT gateway é distribuído entre AZs automaticamente, com alta disponibilidade. É mais caro.

Na prática, muitas empresas ainda usam o modo zonal e criam um NAT gateway por AZ (um em cada AZ onde há subnet privada), associando cada subnet privada ao NAT da sua própria AZ. Isso evita o tráfego cross-AZ (que tem custo) e mantém resiliência sem depender do modo regional.

Zonal ou regional em cenários corporativos?

O padrão corporativo geralmente é zonal com um NAT gateway por AZ. O modo regional é um recurso novo e tem custo mais alto. A abordagem consolidada do mercado é:

1 NAT gateway na subnet pública da AZ-a sendo usado pelas subnets privadas da AZ-a.
1 NAT gateway na subnet pública da AZ-b sendo usado pelas subnets privadas da AZ-b.

Connectivity type:

Público: permite que instâncias privadas acessem a internet. Requer Elastic IP. É o caso mais comum.
Privado: usado para rotear tráfego entre VPCs ou on-premises via VPN/Direct Connect, sem sair para internet.

Devemos deixar “público” se o objetivo é dar saída à internet para as subnets privadas. Devemos selecionar a subnet pública e clicar em “Allocate Elastic IP”:

Após criar o NAT gateway, é possível observar que uma ENI (Elastic Network Interface) foi criada automaticamente, ela possui um IP privado (172.31.3.123) para receber o tráfego dos recursos das subnets privadas, e um Elastic IP público (100.50.71.167) para se comunicar com a internet, realizando o SNAT, que substitui o IP privado de origem pelo IP público, mantendo os recursos privados invisíveis para a internet:

O IP elástico que foi alocado na criação do NGW, está localizado no serviço de EC2, na aba “Elastic IPs”.

OBS: um Elastic IP sem associação à algum recurso, gera custo (em dólar) na AWS. O custo atual é de $0,005 por hora por IP público não associado (ou associado a uma instância parada). Isso dá aproximadamente $3,60/mês por IP ocioso. Quando alocamos um Elastic IP sem usá-lo, está reservando um endereço do pool da AWS que poderia ser usado por outro cliente. A cobrança serve como incentivo para que os usuários não acumulem e liberem IPs ociosos, evitando desperdício desse recurso, uma vez que os endereços IPv4 públicos são recursos limitados.

Para evitar custos, o ideal é liberar os Elastic IPs que não estiverem em uso. Neste caso, o EIP será utilizado para o NAT, mas em outro cenário de teste, após realizá-lo, será importante liberar o IP, clicando em “Release Elastic IP addresses”:

Como boa prática para manter a organização dos recursos, podemos renomeá-lo com o nome do NGW, para facilitar as auditorias futuras:

Em seguida, podemos voltar na aba “Route tables” e configurar a tabela de rotas da subnet privada, apontando o destino 0.0.0.0/0 para o NAT gateway recém-criado, permitindo que os recursos privados acessem a internet através dele:

Por fim, as subnets privadas deverão ser associadas dessa forma:

E o “Resource map” da VPC ficará assim:

Agora, podemos criar a VPC na conta BS-Security e prosseguir da mesma forma, criando as subnets, tabela de rotas, Internet e NAT gateway:

Conta: BS-Security | Região: sa-east-1 | VPC: VPC-BS-SECURITY

1.Criação da VPC:

A VPC foi criada com sucesso:

2.Agora, será necessário criar as 3 subnets da VPC-BS-SECURITY, conforme o diagrama:

3.Após a criação das subnets, será necessário criar o Internet e o NAT gateway:

4.Em seguida, será necessário criar e configurar as tabelas de rotas:

Tabela RTB-BS-SEC-PRIVATE:

Tabela RTB-BS-SEC-PUBLIC:

5.2.Configuração do peering entre as VPCs

Após a criação das VPCs e subnets nas contas BS-Infra e BS-Security, o próximo passo será criar o peering entre as duas contas.

Conta: BS-Infra | Região: us-east-1 | Peering connection: VPC-BS-INFRA

1.Acessar o serviço de VPC, aba “Peering connections” e criar:

Será necessário definir um nome, por padrão, iremos adotar o prefixo “PCX”, que é uma convenção comum para peering connection, adotada pela própria AWS para nomenclaturas. Neste caso, será criada uma conexão do requester VPC-BS-INFRA para o accepter VPC-BS-SECURITY:

Alguns detalhes:

A requisição de conexão foi enviada:

Em seguida, será necessário acessar a conta BS-Security e aceitar:

Agora, será necessário configurar as rotas. Dependendo do caso de uso da empresa, podemos permitir a comunicação entre tabelas de rotas privadas, públicas ou ambas. Em cenários reais, o mais recomendado é conectar tabelas de rotas privadas entre si, mantendo os recursos sensíveis isolados da internet. Neste caso de teste, faremos com que a tabela pública da conta BS-Infra tenha comunicação com a tabela da conta BS-Security, e vice-versa. Em produção, é necessário analisar cada cenário para configurar o roteamento de acordo com os requisitos de conectividade e segurança.

Em seguida, podemos ir na route table da conta BS-Security e editar as duas tabelas:

Tabela RTB-BS-SEC-PRIVATE

Adicionar o IP de destino 172.31.0.0/16 da VPC-BS-INFRA e selecionar o peering connection criado:

Em seguida, podemos repetir o mesmo procedimento na route table pública:

Tabela RTB-BS-SEC-PUBLIC

Agora será necessário fazer o mesmo procedimento nas route tables da conta BS-Infra, com o IP de destino 10.0.0.0/16, referente à VPC-BS-SECURITY.

Tabela RTB-BS-INFRA-PRIVATE

Tabela RTB-BS-INFRA-PUBLIC

Agora teremos duas route tables vinculadas neste peering connection:

5.3. Criação de instâncias EC2 para testar a conexão entre as redes

Agora, será necessário criar duas instâncias, sendo uma em cada conta.

Conta: BS-Infra

1.Acessar o serviço EC2 e clicar em “Launch instance”:

2.Definir as opções abaixo:

Nome da instância: SRV-INFRA-TEST
AMI: neste caso, pode ser Amazon Linux 2023.
Tipo de instância: neste caso, pode ser t2.micro (é barata).
Key pair: não será criado o par de chaves. Caso a instância fosse acessada via SSH, por exemplo, seria necessário criar o par, pois a chave pública ficaria dentro da instância e a privada seria baixada no formato .pem ou .ppk para acesso via SSH.
Rede: VPC-BS-INFRA
Subnet: Pode ser a subnet pública para teste (INFRA-PUBLIC-SRV)
Auto-assign public IP: deixar habilitado para ser atribuído um IP público para a instância.
Firewall (Security Groups): como o acesso à instância será via SSM, não será necessário configurar regras de entrada (como SSH, por exemplo). Dessa forma, o security group pode ser definido apenas com regras de saída.

Para o teste, não será necessário alterar o tipo e tamanho do storage:

Podemos clicar em “Advanced details” para criar a IAM role que permitirá o acesso à incia via SSM. Para isso, será necessário anexar a política “AmazonSSMManagedInstanceCore” à role, que fornece as permissões usadas pelo AWS Systems Manager para gerenciar a instância:

Após isso, podemos clicar em “Launch instance” para criar a instância:

No security group, para acesso via SSM, por padrão é liberada apenas a saída para a internet (outbound), pois o SSM agent é quem inicia a comunicação com os endpoints da AWS na porta 443. Nenhuma regra de entrada (inbound) é necessária, o que elimina a exposição de portas como SSH (22) ou RDP (3389).

Neste caso, como será realizado um teste de ping, será necessário liberar tráfego ICMP no inbound do security group, restrito ao bloco de IP da VPC-BS-SECURITY (10.0.0.0/16):

Em seguida, podemos repetir o mesmo processo na conta BS-Security, para criar a instância:

E configurar o security group, liberando o ICMP no inbound, restrito ao bloco de IP da VPC-BS-INFRA (172.31.0.0/16):

5.4. Acesso às instâncias e teste de conectividade

Agora, vamos acessar as duas máquinas e testar um ping e telnet entre elas:

Instância: SRV-INFRA-TEST

Com o comando ip a, é possível visualizar o IP privado dessa máquina:

E também, diretamente no console:

Foi realizado um teste de conectividade via ping da instância SRV-INFRA-TEST (172.31.3.215) para a SRV-SEC-TEST (10.0.3.67).

O retorno foi bem-sucedido, confirmando a comunicação entre as máquinas.

Também é possível validar a conectividade TCP entre as instâncias utilizando o Telnet. Para isso, basta instalar a ferramenta nas duas máquinas e executar o teste informando o IP e a porta desejada.

sudo yum install telnet -y

Para isso, será necessário acessar os security groups das duas instâncias e liberar, por exemplo, a porta 22 (SSH) nas regras de entrada, permitindo testar a conectividade.

BS-Infra:

BS-Security:

Por fim, executar telnet <IP> <porta> em ambas as máquinas. O teste confirmou que a conectividade TCP entre as instâncias funcionou corretamente na porta 22. O retorno “Connected to” e a identificação do serviço OpenSSH demonstram que a comunicação entre as VPCs foi estabelecida com sucesso:

OBS: foi utilizada a porta 22, pois as instâncias Linux utilizadas já possuíam o serviço SSH disponível por padrão, não sendo necessária a instalação de serviços adicionais para a realização dos testes básicos.

5.5. Configuração do VPC Flow Logs

Para configurar, será necessário selecionar a VPC, neste caso a VPC-BS-INFRA e na aba de Flow Logs, clicar em “Create flow log”:

Podemos selecionar as opções “Accept”, “Reject” ou “All”, que definem o tipo de tráfego que será capturado. Neste caso, vamos utilizar a opção “All”, para registrar toda a comunicação, independentemente de o tráfego ter sido aceito ou rejeitado.

Na opção de agregação, podemos manter 1 minuto, para que um novo arquivo de log seja gerado a cada minuto:

Em seguida, podemos definir um destino para os logs. O S3 dificulta um pouco a leitura dos logs diretamente, então, caso optemos por armazená-los nele, podemos baixar os arquivos para análise local ou utilizar o Athena para filtrar e consultar os dados utilizando SQL. Já o CloudWatch Logs centraliza a visualização de logs, então, neste caso, vamos optar por ele. Para isso, será necessário criar um grupo de logs no CloudWatch.

Será necessário acessar o CloudWatch, e na aba “Log Management”, clicar em “Create log group”:

Podemos selecionar o tempo de retenção dos logs (neste exemplo, serão apenas 3 dias), também o log class (classes de armazenamento) e proteger os logs contra deleção acidental. Em cenários corporativos reais, o ideal seria também criptografar os logs, para manter a segurança em ambientes de produção.

Após criar o grupo de logs, podemos retornar à página de criação do Flow Logs e selecioná-lo para dar continuidade. Também podemos criar uma IAM role diretamente nesta tela, concedendo as permissões necessárias para que o Flow Logs possa enviar os registros ao CloudWatch Logs.

Em seguida, podemos customizar os registros dos logs, clicando em “Custom format” e selecionando as opções abaixo:

A criação foi feita com sucesso:

Em seguida, podemos repetir o mesmo procedimento com a VPC-BS-SECURITY:

5.6. Análise de tráfego das VPCs com o Flow Logs

Após criar os Flow Logs nas duas VPCs, podemos validar o monitoramento realizando, por exemplo, um telnet da VPC-BS-INFRA para a VPC-BS-SECURITY e, posteriormente, verificando no CloudWatch Logs se o tráfego foi registrado corretamente:

O log apresentou os IPs de origem e destino, a porta 22 e a ação “ACCEPT OK ”, confirmando que a comunicação entre as VPCs ocorreu com sucesso e foi devidamente monitorada pelo Flow Logs:

6.Conclusão

O recurso de VPC peering funciona sobre o backbone da rede privada da AWS e o tráfego entre as VPCs é roteado internamente pela infraestrutura global, sem nunca passar pela internet pública. Em conexões entre regiões diferentes, o tráfego é criptografado antes de sair das instalações da AWS, permanecendo sempre na rede global privada, o que reduz riscos de exposição externa e ataques como DDoS.

Foi possível validar na prática que o VPC peering funciona entre contas e regiões geográficas diferentes, conectando uma VPC em Norte da Virgínia (us-east-1) com uma VPC em São Paulo (sa-east-1). A conectividade foi comprovada através de testes com ping e telnet, onde a instância de origem conseguiu alcançar a instância de destino utilizando exclusivamente o IP privado, confirmando que o tráfego não passou pela internet pública.

O monitoramento foi realizado através do VPC Flow Logs, configurado nas duas contas, que registrou de forma detalhada todo o tráfego gerado durante os testes, incluindo IPs de origem e destino, portas, protocolo, quantidade de pacotes, bytes transferidos e a ação tomada pelo security group. Esse recurso é muito útil para troubleshooting, pois pode ajudar a descobrir onde o pacote morreu. Neste caso, por exemplo:

Se a conta de infraestrutura mostrasse ACCEPT no envio, mas a conta de segurança não registrasse nenhuma entrada correspondente, o problema poderia estar na configuração das tabelas de rotas ou no caminho até a VPC de destino.
Caso a conta de segurança registrasse o pacote chegando com o status REJECT, isso indicaria que a conectividade do VPC peering estaria funcionando, mas o tráfego poderia estar sendo bloqueado pelo security group ou pela NACL da instância de destino.

DEV Community: Bianca Szimanski