Como Gerenciar VPC Peering via Terraform

Regiões

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

br-se1

br-ne1

Este guia demonstra como provisionar e gerenciar uma conexão de VPC Peering entre duas VPCs da Magalu Cloud utilizando o Provider Terraform para MGC. Com o Terraform, a topologia de rede é descrita como código (IaC), o que garante reprodutibilidade, rastreabilidade e integração com pipelines de CI/CD.

Pré-requisitos

Certifique-se de que o Provider Terraform para MGC, na versão v0.55.0 ou superior, está configurado no seu projeto antes de prosseguir. Consulte a documentação de configuração do provider para os passos iniciais.

Disponibilidade limitada

O gerenciamento de VPC Peering está disponível a partir da CLI e do Terraform, nas regiões Sudeste (br-se1) e Nordeste (br-ne1). O suporte no Console está previsto para uma próxima versão.

Para os conceitos da funcionalidade, as regras de uso e o diagnóstico de conectividade, consulte Como Conectar Duas VPCs com VPC Peering.

Recursos e Data Sources Disponíveis

Tipo	Nome	Descrição
Resource	`mgc_network_vpcs_peering`	Cria e gerencia uma conexão de peering entre duas VPCs.
Resource	`mgc_network_vpcs_route`	Cria a rota que direciona o tráfego para o peering.
Data Source	`mgc_network_vpcs_peering`	Consulta os detalhes de um peering pelo ID.
Data Source	`mgc_network_vpcs_peerings`	Lista os peerings do tenant, com filtro opcional por VPC.
Data Source	`mgc_network_vpcs_route`	Consulta os detalhes de uma rota pelo ID.
Data Source	`mgc_network_vpcs_routes`	Lista todas as rotas de uma VPC.

Exemplo Completo

O exemplo abaixo cria as duas VPCs, as sub-redes, o peering e as rotas cruzadas:

# VPCs
resource "mgc_network_vpcs" "app" {
  name        = "vpc-app"
  description = "VPC das aplicações"
}

resource "mgc_network_vpcs" "db" {
  name        = "vpc-db"
  description = "VPC dos bancos de dados"
}

# Sub-redes IPv4 com CIDRs que não se sobrepõem
resource "mgc_network_vpcs_subnets" "app" {
  vpc_id          = mgc_network_vpcs.app.id
  name            = "subnet-app-v4"
  cidr_block      = "172.16.0.0/24"
  ip_version      = "IPv4"
  subnetpool_id   = var.subnetpool_id
  dns_nameservers = ["8.8.8.8", "8.8.4.4"]
}

resource "mgc_network_vpcs_subnets" "db" {
  vpc_id          = mgc_network_vpcs.db.id
  name            = "subnet-db-v4"
  cidr_block      = "172.17.0.0/24"
  ip_version      = "IPv4"
  subnetpool_id   = var.subnetpool_id
  dns_nameservers = ["8.8.8.8", "8.8.4.4"]
}

# Conexão de peering
resource "mgc_network_vpcs_peering" "app_to_db" {
  name             = "peering-app-to-db"
  description      = "Conexão entre a VPC de aplicação e a VPC de banco de dados"
  requester_vpc_id = mgc_network_vpcs.app.id
  accepter_vpc_id  = mgc_network_vpcs.db.id
}

# Rotas cruzadas: uma em cada VPC
resource "mgc_network_vpcs_route" "app_to_db" {
  vpc_id           = mgc_network_vpcs.app.id
  peering_id       = mgc_network_vpcs_peering.app_to_db.id
  cidr_destination = mgc_network_vpcs_subnets.db.cidr_block
  description      = "Acesso a VPC de banco de dados"
}

resource "mgc_network_vpcs_route" "db_to_app" {
  vpc_id           = mgc_network_vpcs.db.id
  peering_id       = mgc_network_vpcs_peering.app_to_db.id
  cidr_destination = mgc_network_vpcs_subnets.app.cidr_block
  description      = "Retorno para a VPC de aplicação"
}

output "peering_status" {
  value = mgc_network_vpcs_peering.app_to_db.status
}

Tempo de propagação da rota

Após o terraform apply, as rotas chegam ao status created em poucos segundos, mas a comunicação entre as VPCs passa a funcionar depois que a configuração é propagada pela rede, o que leva alguns minutos. É esperado que um teste de conectividade executado logo após o apply ainda não responda. Considere esse intervalo ao encadear testes de conectividade em pipelines de CI/CD.

Atenção ao nome do argumento

No Terraform, a rota de peering usa o argumento peering_id, diferente da CLI, que usa --targets.type e --targets.id. Um recurso mgc_network_vpcs_route aceita exatamente um próximo salto: ou port_id, ou peering_id, nunca os dois.

Schema do recurso `mgc_network_vpcs_peering`

Argumentos obrigatórios:

Argumento	Tipo	Descrição
`name`	`string`	Nome do peering. Letras, números e hífens, até 50 caracteres.
`requester_vpc_id`	`string`	ID da VPC do lado solicitante.
`accepter_vpc_id`	`string`	ID da VPC do lado aceitante.

Argumentos opcionais:

Argumento	Tipo	Descrição
`description`	`string`	Texto descritivo para identificar a conexão.

Atributos somente leitura (computed):

Atributo	Tipo	Descrição
`id`	`string`	ID único do peering, também usado no import.
`status`	`string`	Status atual. Chega a `completed` quando totalmente provisionado.
`created_at`	`string`	Data e hora da criação.
`updated_at`	`string`	Data e hora da última atualização.

A API de peering não possui endpoint de atualização

Qualquer alteração de atributo provoca destruição e recriação do recurso. Como a recriação derruba a conexão temporariamente, planeje mudanças com atenção em ambientes de produção.

Schema do recurso `mgc_network_vpcs_route`

Argumentos obrigatórios:

Argumento	Tipo	Descrição
`vpc_id`	`string`	ID da VPC que recebe a rota, ou seja, a origem do tráfego.
`cidr_destination`	`string`	CIDR de destino. Para rotas de peering, use o CIDR de uma sub-rede da outra VPC.

Argumentos opcionais:

Argumento	Tipo	Descrição
`peering_id`	`string`	ID do peering usado como próximo salto. Informe ou `peering_id` ou `port_id`.
`port_id`	`string`	ID da porta usada como próximo salto. Informe ou `peering_id` ou `port_id`.
`description`	`string`	Texto descritivo para identificar a rota.

Consultando com Data Sources

# Detalhes de um peering específico
data "mgc_network_vpcs_peering" "app_to_db" {
  id = mgc_network_vpcs_peering.app_to_db.id
}

# Todos os peerings do tenant
data "mgc_network_vpcs_peerings" "todos" {}

# Apenas os peerings de que uma VPC participa
data "mgc_network_vpcs_peerings" "da_vpc_app" {
  vpc_id = mgc_network_vpcs.app.id
}

# Todas as rotas de uma VPC, útil para auditoria no pipeline
data "mgc_network_vpcs_routes" "rotas_app" {
  vpc_id = mgc_network_vpcs.app.id
}

output "peerings_da_vpc_app" {
  value = data.mgc_network_vpcs_peerings.da_vpc_app.items
}

O data source mgc_network_vpcs_peerings retorna a lista em items, e cada item traz id, name, description, status, requester_vpc_id, accepter_vpc_id, created_at e updated_at.

Importando um Peering Existente

terraform import mgc_network_vpcs_peering.app_to_db "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

Após o import, execute terraform plan para confirmar que o estado local está sincronizado com a infraestrutura real.

Boas Práticas

Use referências entre recursos: Evite hardcode de vpc_id, peering_id e cidr_destination. Referencie os atributos dos próprios recursos Terraform para que o grafo de dependências garanta a ordem correta de criação.
Planeje antes de aplicar: Execute terraform plan antes de qualquer terraform apply para revisar as mudanças, especialmente em ambientes de produção.
Atenção à recriação do peering: Como a API não possui endpoint de atualização, qualquer alteração de atributo destrói e recria a conexão, o que interrompe o tráfego entre as VPCs durante a operação.
Documente com description: Preencha o campo description do peering e das rotas com informações sobre a finalidade de cada recurso. Isso facilita auditorias e o entendimento da topologia por outros membros do time.
Planeje o endereçamento: Reserve CIDRs distintos para as VPCs que serão conectadas. A correção de uma sobreposição exige a recriação das sub-redes envolvidas.

Próximos Passos

Para os conceitos, as operações via CLI e o diagnóstico de conectividade, consulte Como Conectar Duas VPCs com VPC Peering.
Para os demais tipos de rota da tabela de roteamento, veja Como Gerenciar Rotas na Tabela de Roteamento via Terraform.

Regiões

Recursos e Data Sources Disponíveis​

Exemplo Completo​

Schema do recurso mgc_network_vpcs_peering​

Schema do recurso mgc_network_vpcs_route​

Consultando com Data Sources​

Importando um Peering Existente​

Boas Práticas​

Próximos Passos​