Como Conectar Duas VPCs com VPC Peering

Regiões

Este recurso está disponível nas seguintes regiões:

br-se1

br-ne1

O VPC Peering é uma conexão de rede entre duas VPCs do mesmo tenant que permite o roteamento de tráfego entre elas por endereços IP privados. As instâncias de uma VPC se comunicam com as da outra como se estivessem na mesma rede, sem gateway de internet, VPN ou endereço IP público, e o tráfego permanece na rede interna da Magalu Cloud.

Disponibilidade

O VPC Peering está disponível nas regiões Sudeste (br-se1) e Nordeste (br-ne1), via CLI e Terraform.

MGC CLI: versão v0.64.0 ou superior
Provider Terraform para MGC: versão v0.55.0 ou superior

O suporte no Console está previsto para uma próxima versão.

Provisionamento como código

Este guia cobre as operações via CLI. Para provisionar a conexão com Infraestrutura como Código, consulte Como Gerenciar VPC Peering via Terraform.

Como o VPC Peering Funciona

A conexão é composta por dois elementos que precisam ser configurados em sequência: o peering, que estabelece o vínculo entre as duas VPCs, e as rotas, que direcionam o tráfego para esse vínculo.

Os papéis requester (solicitante) e accepter (aceitante) identificam os dois lados da conexão e são retornados no campo direct_role de cada membro. Não existe convite a ser aceito: a conexão é bidirecional e é provisionada no momento da criação, sem necessidade de aprovação pela outra ponta.

O peering estabelece o caminho, mas não habilita o tráfego por si só. Para que a comunicação ocorra, cada VPC precisa de uma rota em sua tabela de roteamento apontando para o CIDR de uma sub-rede da VPC oposta. Com a rota configurada em apenas um dos lados, os pacotes chegam ao destino mas não encontram caminho de retorno.

As regras de Security Group permanecem em vigor sobre o tráfego que cruza a conexão. O peering entrega o pacote à instância de destino, e o Security Group dessa instância determina se ele será aceito.

Topologia de uma conexão de VPC Peering entre duas VPCs

Regras e Limites

Regra	Detalhe
Mesmo tenant	As duas VPCs precisam pertencer ao mesmo tenant.
Mesma região	Não é possível criar peering entre VPCs de regiões diferentes (ex: `br-se1` com `br-ne1`).
CIDRs sem sobreposição	Os blocos de IP privados das duas VPCs não podem se sobrepor. Se houver conflito, o roteamento fica ambíguo e a comunicação não funciona.
Um peering por par de VPCs	Não é possível criar dois peerings entre as mesmas duas VPCs.
VPCs distintas	Não é possível conectar uma VPC a ela mesma.
Sem transitividade	O peering não propaga rotas de forma transitiva. Se A tem peering com B, e B com C, os recursos de A não alcançam C através de B por roteamento nativo. Consulte Trânsito entre VPCs não adjacentes.
Nome	Apenas letras, números e hífens, até 50 caracteres.

Trânsito entre VPCs Não Adjacentes

Cada conexão de peering transporta tráfego apenas entre as duas VPCs que a compõem. Em uma topologia onde a VPC A tem peering com a VPC B, e a VPC B tem peering com a VPC C, o roteamento nativo não permite que A alcance C.

Há dois caminhos para atender esse cenário.

Peering direto. Criar uma conexão adicional entre A e C, com as rotas correspondentes nas duas pontas. É a opção mais simples de operar, sem componente intermediário no caminho do tráfego, e a recomendada sempre que o número de conexões for administrável.

Instância de trânsito na VPC intermediária. Uma VM na VPC B atua como gateway entre A e C, reaproveitando os peerings existentes. Nesse arranjo, a VPC A recebe uma rota com destino ao CIDR da VPC C e próximo salto na porta dessa VM, em vez de apontar para um peering:

mgc network vpcs route-table routes create \
  --vpc-id="[ID_DA_VPC_A]" \
  --cidr-destination="[CIDR_DA_VPC_C]" \
  --targets.type="port_id" \
  --targets.id="[ID_DA_PORTA_DA_VM_DE_TRANSITO]" \
  --region="br-se1"

Na instância de trânsito, o encaminhamento de pacotes precisa estar habilitado no sistema operacional (net.ipv4.ip_forward = 1). A forma de tratar o endereço de origem define o restante da configuração:

Com masquerade (SNAT). A VM reescreve o endereço de origem para o seu próprio IP antes de encaminhar o pacote para a VPC C. Como o tráfego que sai da porta usa um endereço que pertence a ela, a proteção de Anti Spoofing pode permanecer ativa. Em contrapartida, a VPC C enxerga todas as conexões com o IP da VM de trânsito, o que impede distinguir a origem real em logs e em regras de Security Group.
Sem masquerade (encaminhamento puro). O endereço de origem da VPC A é preservado até a VPC C. Nesse caso, a porta da VM envia tráfego com endereços que não são os seus, e a proteção de Anti Spoofing precisa ser desativada na porta. Consulte Como Usar o Anti Spoofing. A VPC C também precisa de rota de retorno para o CIDR da VPC A apontando para a mesma instância.

Implicações do trânsito por instância

A VM de trânsito passa a integrar o caminho de dados entre as VPCs e concentra riscos que o peering nativo não possui: ela é ponto único de falha, limita a banda à capacidade da própria instância e exige manutenção do sistema operacional, das regras de firewall e do encaminhamento. Avalie o peering direto antes de adotar esse desenho.

Casos de Uso

O VPC Peering é indicado em arquiteturas que exigem isolamento administrativo entre ambientes, mas mantêm pontos de comunicação privada definidos entre eles:

Serviços compartilhados (modelo hub-and-spoke): Uma VPC central concentra recursos comuns (monitoramento, repositório de artefatos, bastion host, servidores de log) e cada ambiente de aplicação se conecta a ela por um peering dedicado, sem que os ambientes se enxerguem entre si.
Separação entre aplicação e banco de dados: Manter as instâncias de banco em uma VPC própria, com regras de acesso mais restritas, e liberar apenas o caminho privado até a VPC das aplicações.
Segregação por ambiente: Produção, homologação e desenvolvimento em VPCs separadas, cada uma com seu próprio controle de acesso, conectando apenas o que for necessário (por exemplo, o ambiente de homologação consumindo um serviço de autenticação que vive na VPC compartilhada).
Segregação por área ou squad: Cada time com sua VPC e autonomia sobre a própria rede, integrando-se às demais apenas nos pontos previstos pela arquitetura.
Plataforma de dados isolada: Um ambiente de analytics ou processamento de dados em VPC dedicada, consumindo dados das VPCs de aplicação por rede privada, sem expor endpoints à internet.
Migração e coexistência: Durante a migração de cargas de uma VPC antiga para uma nova, o peering mantém os dois ambientes se comunicando enquanto os recursos são movidos gradualmente.
Saída centralizada por appliance: Uma VPC concentra o appliance de firewall ou proxy, e as demais direcionam para ela o tráfego que precisa de inspeção, combinando o peering com uma rota para a porta do appliance. Veja Trânsito entre VPCs não adjacentes.

Pré-requisitos

Duas VPCs no mesmo tenant e na mesma região.
Sub-redes IPv4 com CIDRs que não se sobrepõem entre as duas VPCs.
MGC CLI v0.64.0+ autenticada, ou o Provider Terraform para MGC v0.55.0+ configurado.
Security Groups preparados para liberar o tráfego que vai cruzar a conexão.

Planejamento de endereçamento

A correção de uma sobreposição de CIDRs exige a recriação das sub-redes envolvidas. Ao planejar VPCs que serão conectadas por peering, reserve blocos distintos desde a criação, por exemplo 172.16.0.0/24 e 172.17.0.0/24.

Passo a Passo via CLI

1. Identifique as VPCs e suas sub-redes

Liste as VPCs da região e anote os IDs das duas que serão conectadas:

mgc network vpcs list --region="br-se1"

Em seguida, liste as sub-redes de cada VPC para anotar os CIDRs que serão usados nas rotas:

mgc network vpcs subnets list --vpc-id="[ID_DA_VPC_A]" --region="br-se1"
mgc network vpcs subnets list --vpc-id="[ID_DA_VPC_B]" --region="br-se1"

VPCs novas não vêm com sub-rede IPv4

Uma VPC recém-criada recebe automaticamente apenas sub-redes IPv6. Se você acabou de criar a VPC, crie a sub-rede IPv4 antes de seguir:

mgc network vpcs subnets create \
  --vpc-id="[ID_DA_VPC]" \
  --name="subnet-app-v4" \
  --cidr-block="172.17.0.0/24" \
  --ip-version=4 \
  --subnetpool-id="[ID_DO_SUBNETPOOL]" \
  --region="br-se1"

Para listar os subnet pools disponíveis: mgc network subnetpools list --region="br-se1".

2. Crie a conexão de peering

mgc network vpcs peerings create \
  --name="peering-app-to-db" \
  --description="Conexão entre a VPC de aplicação e a VPC de banco de dados" \
  --vpcs.requester-vpc-id="[ID_DA_VPC_A]" \
  --vpcs.accepter-vpc-id="[ID_DA_VPC_B]" \
  --region="br-se1"

Parâmetros do comando:

Parâmetro	Obrigatório	Descrição
`--name`	✅ Sim	Nome do peering. Apenas letras, números e hífens, até 50 caracteres.
`--vpcs.requester-vpc-id`	✅ Sim	ID da VPC do lado solicitante.
`--vpcs.accepter-vpc-id`	✅ Sim	ID da VPC do lado aceitante.
`--description`	❌ Não	Texto livre para identificar a finalidade da conexão.

O comando retorna o id do peering e o status inicial:

{
  "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "status": "pending"
}

3. Aguarde o status `completed`

O peering leva alguns instantes para ser provisionado. Consulte até que o status mude para completed:

mgc network vpcs peerings get --vpc-peering-id="[ID_DO_PEERING]" --region="br-se1"

{
  "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "name": "peering-app-to-db",
  "description": "Conexão entre a VPC de aplicação e a VPC de banco de dados",
  "status": "completed",
  "members": [
    {
      "direct_role": "requester",
      "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "vpc_id": "[ID_DA_VPC_A]"
    },
    {
      "direct_role": "accepter",
      "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "vpc_id": "[ID_DA_VPC_B]"
    }
  ],
  "created_at": "2026-08-18T12:27:03.698929",
  "updated": "2026-08-18T12:27:48.179210"
}

Só crie as rotas depois do completed

Rotas que apontam para um peering só entram em vigor quando a conexão já está completed. Aguarde o status antes de seguir para o próximo passo.

4. Crie as rotas nas duas VPCs

Este é o passo que efetivamente libera o tráfego. Você cria uma rota em cada VPC, com os destinos cruzados: na VPC A a rota aponta para o CIDR da sub-rede da VPC B, e vice-versa.

# Rota na VPC A, destino: sub-rede da VPC B
mgc network vpcs route-table routes create \
  --vpc-id="[ID_DA_VPC_A]" \
  --targets.type="vpc_peering" \
  --targets.id="[ID_DO_PEERING]" \
  --cidr-destination="172.17.0.0/24" \
  --description="Acesso a VPC de banco de dados" \
  --region="br-se1"

# Rota na VPC B, destino: sub-rede da VPC A
mgc network vpcs route-table routes create \
  --vpc-id="[ID_DA_VPC_B]" \
  --targets.type="vpc_peering" \
  --targets.id="[ID_DO_PEERING]" \
  --cidr-destination="172.16.0.0/24" \
  --description="Retorno para a VPC de aplicação" \
  --region="br-se1"

Parâmetros do comando:

Parâmetro	Obrigatório	Descrição
`--vpc-id`	✅ Sim	ID da VPC que recebe a rota, ou seja, a origem do tráfego.
`--targets.type`	✅ Sim	Tipo do próximo salto. Use `vpc_peering` para rotas de peering.
`--targets.id`	✅ Sim	ID do peering que atuará como próximo salto.
`--cidr-destination`	✅ Sim	CIDR da sub-rede da outra VPC que se deseja alcançar.
`--description`	❌ Não	Texto livre para identificar a finalidade da rota.

Uma rota por sub-rede de destino

A rota cobre apenas o CIDR informado. Se a VPC oposta tem mais de uma sub-rede IPv4 e você precisa alcançar todas, crie uma rota para cada CIDR.

Tempo de propagação da rota

A rota chega ao status created em poucos segundos, mas esse status confirma apenas o registro da configuração. A comunicação entre as VPCs passa a funcionar depois que a rota é propagada pela rede, o que leva alguns minutos.

É esperado que um teste de conectividade feito logo após a criação da rota ainda não responda. Aguarde a propagação e repita o teste antes de investigar a configuração.

5. Libere o tráfego no Security Group

Adicione ao Security Group da instância de destino uma regra de entrada que permita o tráfego originado do CIDR da VPC oposta, para cada protocolo e porta que a aplicação utilize.

# Exemplo: liberar ICMP (ping) vindo da VPC A
mgc network security-groups rules create \
  --security-group-id="[ID_DO_SECURITY_GROUP]" \
  --direction="ingress" \
  --ethertype="IPv4" \
  --protocol="icmp" \
  --remote-ip-prefix="172.16.0.0/24" \
  --region="br-se1"

# Exemplo: liberar PostgreSQL vindo da VPC A
mgc network security-groups rules create \
  --security-group-id="[ID_DO_SECURITY_GROUP]" \
  --direction="ingress" \
  --ethertype="IPv4" \
  --protocol="tcp" \
  --port-range-min=5432 \
  --port-range-max=5432 \
  --remote-ip-prefix="172.16.0.0/24" \
  --region="br-se1"

6. Valide a configuração

Confirme que as rotas estão com status created nas duas VPCs:

mgc network vpcs route-table routes list --vpc-id="[ID_DA_VPC_A]" --region="br-se1"
mgc network vpcs route-table routes list --vpc-id="[ID_DA_VPC_B]" --region="br-se1"

Uma rota de peering aparece com type: "peering" e o campo vpc_peering_id preenchido:

{
  "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "cidr_destination": "172.17.0.0/24",
  "description": "Acesso a VPC de banco de dados",
  "next_hop": null,
  "port_id": null,
  "type": "peering",
  "status": "created",
  "vpc_peering_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

Em seguida, teste a comunicação a partir de uma instância, usando o IP privado de uma instância da VPC oposta:

ping -c 4 [IP_PRIVADO_DA_INSTANCIA_NA_OUTRA_VPC]

Se o teste não responder de imediato

Conforme indicado no passo anterior, a propagação da rota leva alguns minutos. Caso o primeiro ping não obtenha resposta, aguarde e repita o teste. Persistindo a falha, siga o roteiro da seção Diagnóstico da Comunicação.

Operações Disponíveis na CLI

Listando os peerings do tenant

mgc network vpcs peerings list --region="br-se1"

Filtrando pelos peerings de uma VPC específica:

mgc network vpcs peerings list --vpc-id="[ID_DA_SUA_VPC]" --region="br-se1"

Parâmetros opcionais:

Parâmetro	Descrição
`--vpc-id`	Retorna apenas os peerings de que a VPC informada participa.
`--sort`	Ordena os resultados.
`--page`	Número da página (mínimo: `1`).
`--items-per-page`	Quantidade de itens por página (de `1` a `100`).

Consultando um peering específico

mgc network vpcs peerings get --vpc-peering-id="[ID_DO_PEERING]" --region="br-se1"

A resposta traz o array members, com as duas VPCs conectadas e o papel de cada uma no campo direct_role (requester ou accepter).

Excluindo um peering

Remova as rotas antes

Um peering não pode ser excluído enquanto existirem rotas ativas apontando para ele. A plataforma bloqueia a operação com a mensagem:

VPC peering has associated routes in created status.
Delete these routes before deleting the peering.

A ordem correta é: primeiro as rotas das duas VPCs, depois o peering.

# 1. Liste as rotas de cada VPC e identifique as que apontam para o peering
mgc network vpcs route-table routes list --vpc-id="[ID_DA_VPC_A]" --region="br-se1"
mgc network vpcs route-table routes list --vpc-id="[ID_DA_VPC_B]" --region="br-se1"

# 2. Remova a rota de cada lado
mgc network vpcs route-table routes delete \
  --vpc-id="[ID_DA_VPC_A]" \
  --route-id="[ID_DA_ROTA_NA_VPC_A]" \
  --region="br-se1"

mgc network vpcs route-table routes delete \
  --vpc-id="[ID_DA_VPC_B]" \
  --route-id="[ID_DA_ROTA_NA_VPC_B]" \
  --region="br-se1"

# 3. Agora exclua o peering
mgc network vpcs peerings delete \
  --vpc-peering-id="[ID_DO_PEERING]" \
  --region="br-se1"

Impacto imediato no tráfego

A remoção das rotas interrompe a comunicação entre as VPCs assim que aplicada. Em produção, planeje uma janela de manutenção e confirme que nenhum serviço depende dessa conexão. A operação não pode ser desfeita.

Ciclo de Vida

Status do peering:

Status	Descrição
`pending`	A conexão foi aceita e aguarda processamento.
`completed`	A conexão está provisionada. Rotas que apontam para ela já podem ser criadas.
`error`	Falha no provisionamento. Verifique os parâmetros informados e tente novamente.

Status da rota:

Status	Descrição
`pending`	A rota foi aceita e aguarda processamento.
`processing`	A rota está sendo provisionada na infraestrutura.
`created`	A rota está registrada. A comunicação fica disponível pouco depois.
`error`	Falha no provisionamento. Verifique os parâmetros e tente novamente.
`deleting`	A rota está em processo de exclusão.
`deleted`	A rota foi removida.

Erros Comuns

Mensagem	Causa	Como resolver
`Requester and accepter VPC IDs must be different.`	As duas pontas apontam para a mesma VPC.	Informe VPCs distintas em `--vpcs.requester-vpc-id` e `--vpcs.accepter-vpc-id`.
`A VPC peering already exists for the provided VPCs.`	Já existe peering entre essas duas VPCs.	Reutilize o peering existente. Localize-o com `peerings list --vpc-id`.
`Accepter VPC [id] not found.`	A VPC informada não existe na região da requisição.	Confirme que as duas VPCs estão na mesma região e que o `--region` está correto.
`Name must not contain special characters. Only letters (A-Z, a-z), numbers (0-9), and hyphens (-) are allowed.`	O nome tem espaços, underscores ou outros caracteres.	Use apenas letras, números e hífens.
`Name must be less than or equal to 50 characters.`	Nome acima do limite.	Reduza o nome para até 50 caracteres.
`VPC '[id]' is not a member of the VPC peering '[id]'`	A rota foi criada em uma VPC que não participa do peering.	Crie a rota em uma das duas VPCs conectadas pelo peering.
`Route with CIDR '[cidr]' already exists for this VPC.`	Já existe rota com esse CIDR de destino na VPC.	Cada rota é única por `vpc_id` + `cidr_destination`. Remova a anterior ou use outro destino.
`VPC peering has associated routes in created status. Delete these routes before deleting the peering.`	Tentativa de excluir o peering com rotas ativas.	Remova as rotas das duas VPCs e só então exclua o peering.

Diagnóstico da Comunicação

Quando a comunicação entre as VPCs não se estabelece, percorra as verificações abaixo na ordem apresentada.

1. Status do peering. Confirme que a conexão está completed:

mgc network vpcs peerings get --vpc-peering-id="[ID_DO_PEERING]" --region="[REGIAO]"

2. Rotas nos dois lados. Liste as rotas de cada VPC e confirme que ambas estão com status created. Uma rota configurada em apenas um dos lados não estabelece a comunicação, porque o tráfego de retorno não encontra caminho.

3. Cobertura dos CIDRs. Verifique se o IP de destino do teste está contido no cidr_destination da rota criada na VPC de origem, e se o IP de origem está contido no cidr_destination da rota criada na VPC de destino.

4. Security Group. Confirme que o Security Group da instância de destino possui regra de entrada para o protocolo e a porta utilizados, com remote_ip_prefix correspondente ao CIDR da VPC de origem.

5. Firewall do sistema operacional. Dentro da instância de destino, verifique as regras locais com sudo iptables -L -n e sudo ufw status. Em testes com ping, confirme que o ICMP não está desativado no kernel: sysctl net.ipv4.icmp_echo_ignore_all deve retornar 0.

6. Tempo desde a criação da rota. Rotas criadas há poucos minutos podem ainda estar em propagação, mesmo com o status created. Aguarde a conclusão e repita o teste antes de alterar a configuração.

Delimitando o escopo da falha

Um teste de ping ao gateway da própria sub-rede confirma que a rede local da VPC está operacional. Se o gateway local responde e o destino na VPC oposta não, a causa está no caminho do peering: rotas, Security Group ou tempo de distribuição da configuração.

Console

Funcionalidade Indisponível no Console

A criação e o gerenciamento de VPC Peering estão disponíveis apenas via CLI e Terraform neste momento.

O suporte via Console da Magalu Cloud está previsto para uma próxima versão.

Próximos Passos

Para provisionar a conexão como código, consulte Como Gerenciar VPC Peering via Terraform.
Para entender em detalhe a tabela de roteamento e os demais tipos de rota, veja Como Gerenciar Rotas na Tabela de Roteamento da VPC.
Para automatizar rotas como código, consulte Como Gerenciar Rotas na Tabela de Roteamento via Terraform.
Para liberar o tráfego que cruza a conexão, veja Gerenciamento de Grupos de Segurança nas suas VMs.

Regiões

Como o VPC Peering Funciona​

Regras e Limites​

Trânsito entre VPCs Não Adjacentes​

Casos de Uso​

Pré-requisitos​

Passo a Passo via CLI​

1. Identifique as VPCs e suas sub-redes​

2. Crie a conexão de peering​

3. Aguarde o status completed​

4. Crie as rotas nas duas VPCs​

5. Libere o tráfego no Security Group​

6. Valide a configuração​

Operações Disponíveis na CLI​

Listando os peerings do tenant​

Consultando um peering específico​

Excluindo um peering​

Ciclo de Vida​

Erros Comuns​

Diagnóstico da Comunicação​

Console​

Próximos Passos​