Configure VPN site-to-site Azure AWS com Virtual WAN. Reduza custos em 40% e simplifique multicloud. Guia passo a passo com Terraform e BGP.

VPN Site-to-Site Azure AWS com Virtual WAN: O Guia Definitivo para Conectividade Multicloud de Alta Performance

Você já parou para calcular quanto sua empresa gasta por mês com enlaces dedicados (MPLS/SD-WAN proprietários) para interconectar Azure, AWS e dezenas de filiais? Se a resposta for sim, há uma boa chance de que esse custo esteja entre 30% e 60% acima do necessário. E o pior: a complexidade operacional dessa abordagem cresce de forma exponencial a cada nova filial ou cloud provider adicionado à sua infraestrutura.

A realidade é que, segundo o relatório State of the Cloud 2024 da Flexera, 89% das empresas já operam em ambientes multicloud — e a conectividade entre provedores deixou de ser um diferencial competitivo para se tornar infraestrutura crítica. Contudo, a maioria das organizações ainda gerencia dezenas de túneis VPN point-to-point individuais, cada um com sua própria configuração de roteamento, política de segurança e ciclo de manutenção. O resultado? Fragmentação, latência imprevisível e equipes de NetOps sobrecarregadas.

Neste guia completo, você vai aprender passo a passo como configurar uma VPN site-to-site entre Azure e AWS usando o Azure Virtual WAN — uma arquitetura que centraliza toda a conectividade multicloud em um único painel de controle, automatiza o provisionamento via Terraform e reduz a complexidade operacional em até 40% em cenários com mais de 5 filiais.

Por Que Túneis VPN Point-to-Point Tradicionais Estão Obsoletos

Antes de mergulharmos na configuração técnica, é essencial entender por que a abordagem tradicional de VPN entre Azure e AWS gera tantos problemas no dia a dia. Imagine o seguinte cenário real:

Sua empresa possui 15 filiais, cada uma com um router SD-WAN local. Você precisa conectar essas filiais a uma VPC na AWS e a VNets no Azure. A abordagem tradicional exigiria:

  • 15 túneis IPsec da filial para a AWS (um por filial)
  • 15 túneis IPsec da filial para o Azure (um por filial)
  • 1 túnel adicional entre AWS e Azure (para comunicação cross-cloud)
  • 31 políticas de roteamento para manter tudo funcionando
  • 31 pontos de falha (um por túnel)
  • Múltiplas equipes gerenciando configurações em diferentes consoles

Agora imagine que você precisa adicionar uma 16ª filial. Com a abordagem tradicional, são +2 túneis, +2 políticas de roteamento e +2 pontos de monitoramento. Com o Virtual WAN, você adiciona um único branch ao hub centralizado e ele automaticamente ganha conectividade com todos os ambientes cloud.

Além da complexidade operacional, há o custo. Um Virtual Private Gateway da AWS + um VPN Gateway do Azure, juntos, custam a partir de US$ 0,04/hora cada um (cerca de US$ 70/mês cada). Quando você multiplica isso por dezenas de túneis individuais e adiciona o custo de enlaces MPLS para redundância, a fatura de rede pode facilmente ultrapassar US$ 3.000 a US$ 10.000/mês em empresas de médio porte. O Virtual WAN centraliza tudo em um único hub, reduzindo esse custo drasticamente.

O Que É o Azure Virtual WAN e Como Ele Transforma a Conectividade Multicloud

O Azure Virtual WAN é um serviço de rede totalmente gerenciado pela Microsoft que funciona como uma camada de orquestração centralizada para toda a conectividade de rede da sua empresa. Ele unifica três capacidades críticas:

  1. Branch-to-Cloud: Conecta filiais (via SD-WAN, VPN site-to-site ou ExpressRoute) diretamente ao Virtual WAN Hub no Azure
  2. Branch-to-Branch: Permite que filiais se comuniquem entre si através do hub, sem precisar atravessar a internet pública
  3. Cloud-to-Cloud: Integra o Virtual WAN Hub com AWS (via VPN site-to-site ou AWS Direct Connect em conjunto com Interconnect Gateway) e outros provedores cloud

A arquitetura do Virtual WAN é fundamentalmente diferente de um VPN Gateway tradicional. Em vez de configurar túneis individuais entre cada par de endpoints, todos os fluxos de tráfego passam por um Virtual WAN Hub — que funciona como um super-concentrador BGP. Isso significa que:

  • BGP routing é propagado dinamicamente entre todos os connected sites
  • Políticas de segurança são aplicadas uma única vez no hub
  • SD-WAN pode ser integrado nativamente (fabricantes como Cisco, VMware Velocloud, Citrix e Nuage são suportados nativamente)
  • Terraform e Azure CLI permitem provisionamento completo como código

Quando você conecta a AWS ao Virtual WAN do Azure via VPN site-to-site, todos os seus branches conectados ao hub ganham acesso transparente aos recursos na AWS. O mesmo vale para VNets no Azure que estão attached ao hub. A complexidade operacional cai de O(n²) para O(n), onde n é o número de branches.

Virtual WAN vs. VPN Tradicional: Comparativo Técnico

Para que você possa tomar a melhor decisão para o seu cenário, preparei um comparativo detalhado entre a arquitetura Virtual WAN e a abordagem VPN tradicional com túneis manuais:

Critério Virtual WAN (Hub-and-Spoke) VPN Tradicional (Túneis Manuais)
Número de túneis 1 túnel por branch ao hub n × m túneis (n=branches, m=cloud providers)
Gerenciamento de roteamento Dinâmico via BGP, propagação automática Manual, por túnel individual
Console de gerenciamento Única interface (Azure Portal/PowerShell) Múltiplos consoles (Azure + AWS)
Automação (IaC) Terraform, Ansible, PowerShell Scripts individuais por túnel
Suporte SD-WAN nativo Sim (Cisco, VeloCloud, Nuage, Citrix) Requer gateway VPN adicional
Custo estimado ~US$ 0,025/hora por hub + túneis ~US$ 0,08/hora por túnel individual
Redundância Ativa-ativa com failover automático Configuração manual de failover
Escalabilidade Adiciona branches em minutos Requer reconfiguração a cada novo site
Visibilidade de tráfego Painel unificado no Virtual WAN Logs fragmentados por túnel
Latência Rotas otimizadas via BGP Rotas estáticas, sem otimização

Recomendação prática:** Se sua empresa tem mais de 3 filiais ou precisa conectar mais de 2 cloud providers, o Virtual WAN já se paga em menos de 6 meses considerando apenas a redução do tempo operacional da equipe de NetOps. Para场景 com menos de 3 filiais e conectividade simples, um par de VPN Gateways dedicados pode ser suficiente.

Pré-requisitos e Considerações Antes de Começar

Antes de iniciar a configuração da VPN site-to-site entre Azure e AWS via Virtual WAN, certifique-se de ter os seguintes pré-requisitos:

Pré-requisitos do Lado Azure

  • Assinatura ativa do Azure com permissões deContributor ou Network Contributor no resource group destino
  • Região do Azure preferencial: East US, West Europe ou Southeast Asia (regiões com Virtual WAN Standard disponíveis)
  • Azure Virtual WAN Standard habilitado (a versão Basic é gratuita, mas não suporta todas as features de roteamento)
  • Terraform (opcional, mas recomendado) ou Azure CLI versão 2.50+
  • Conhecimento básico de BGP e IPsec

Pré-requisitos do Lado AWS

  • Conta AWS com permissões IAM para criar Virtual Private Gateway e Customer Gateway
  • VPC configurada com subnets para as instâncias que serão acessadas via VPN
  • Amazon VPC IP Address range definido (evitar overlaps com VNets do Azure)
  • AWS CLI configurada com credenciais da conta

Pré-requisitos de Rede

  • Endereçamento IP não sobreposto entre AWS VPC e Azure VNets. Exemplo:
    • AWS VPC: 10.10.0.0/16
    • Azure VNet: 10.20.0.0/16
    • Filiais (SD-WAN/VPN): 192.168.0.0/16
  • Portas UDP 500 e 4500 abertas nos firewalls das filiais para tráfego IPsec
  • Autonomous System Number (ASN) para peering BGP (pode usar ASN privado, ex.: 65001)

Passo a Passo: Configurar VPN Site-to-Site Azure AWS com Virtual WAN

Agora vamos à parte prática. Vou detalhar cada etapa da configuração, desde a criação do Virtual WAN Hub até a verificação da conectividade entre Azure e AWS.

Passo 1 — Criar o Virtual WAN Hub no Azure

Acesse o Azure Portal e procure por "Virtual WAN" no marketplace. Clique em "Criar" e preencha:

  • Grupo de recursos: rg-cirocloud-vwan-prod
  • Nome do Virtual WAN: vwan-cirocloud-global
  • Tipo: Standard (recomendado para produção)
  • Região: East US 2

Após a criação, dentro do recurso Virtual WAN, clique em "Hubs virtuais" → "Novo hub virtual":

  • Nome do hub: hub-eastus-01
  • Região: East US 2
  • Espaço de endereço do hub: 10.100.0.0/24 (este é o bloco de endereços do hub em si)
  • SKU do hub: Standard (suporta até 1.000 sites conectados)
  • Enable VPN Gateway: Sim (ativo-ativo, 2 túneis)
  • BGP ASN do hub: 65001

⚠️ Nota sobre custo: O Virtual WAN Hub Standard cobra aproximadamente US$ 0,025/hora + US$ 0,015/GB de dados processados. Para workloads de produção com 1 TB/mês de tráfego, o custo mensal fica em torno de US$ 45-60, muito inferior a uma arquitetura equivalente com múltiplos VPN Gateways.

Passo 2 — Criar o VPN Gateway no AWS (Customer Gateway)

No console da AWS, vá em VPC → Site-to-Site VPN Connections → Create Customer Gateway:

  • Nome: CGW-AzureVirtualWAN
  • IP Address: O IP público do Virtual WAN Hub (encontre em hub-eastus-01 → VPN → Gateway)
  • BGP ASN: 65515 (ASN do AWS, ou um ASN privado se preferir)
  • Tipo de routing: Dinâmico (BGP)

Em seguida, crie o Virtual Private Gateway:

  • Nome: VPG-CiroCloudProd
  • ASN: 65002 (ASN privado que será usado para peering BGP com o Azure)
  • Associar à VPC: vpc-cirocloud-prod (10.10.0.0/16)

Passo 3 — Configurar o VPN Connection no AWS e Baixar a Configuração

No AWS, crie a Site-to-Site VPN Connection:

  • Customer Gateway: CGW-AzureVirtualWAN
  • Virtual Private Gateway: VPG-CiroCloudProd
  • Routing Options: Dinâmico (BGP)
  • Tunnel Options: Deixe em branco para que o AWS gere automaticamente (ou defina IPs específicos para redundancy ativa-ativa)

Após criar a conexão, clique em "Download Configuration" e selecione o vendor como "Generic". Isso gerará um arquivo de configuração com os parâmetros IPsec necessários (IP do túnel, chaves pré-compartilhadas, parâmetros Phase 2, etc.).

Passo 4 — Configurar o VPN Site no Azure Virtual WAN

No Azure Portal, dentro do Virtual WAN Hub criado no Passo 1, vá em "VPN (Site-to-Site)" → "Sites" → "Adicionar":

  • Nome do site: site-aws-vpc-prod
  • Dispositivo/vendor: AWS
  • Endereço IP privado do site: (preencha com o IP do Customer Gateway da AWS)
  • Espaço de endereço do site: 10.10.0.0/16 (a VPC da AWS)
  • BGP: Ativar
  • ASN do site: 65002 (ASN do Virtual Private Gateway da AWS)
  • Link privado: Adicionar o link com o IP do túnel primário da AWS

O Azure Virtual WAN criará automaticamente 2 túneis IPsec (ativo-ativo). Anote os IPs dos túneis que serão atribuídos pelo Azure.

Passo 5 — Aplicar a Configuração IPsec da AWS ao Azure Virtual WAN

Este é o passo crítico: você precisa garantir que os parâmetros IPsec do Azure correspondam aos gerados pela AWS. No arquivo de configuração baixado no Passo 3, localize:

  • Outside IP Addresses (IPs dos túneis AWS)
  • Pre-Shared Key (chave pré-compartilhada)
  • Phase 1 e Phase 2 Parameters (algoritmos de criptografia, DH Group, PFS)

No Azure, edite o "Link" do site VPN criado e preencha os valores correspondentes. Garanta que o IKE version (IKEv1 ou IKEv2) seja consistente entre ambos os lados. Recomendação: Use IKEv2 para melhor compatibilidade e segurança.

Passo 6 — Configurar o Roteamento no Virtual WAN (Route Table)

Esta etapa é onde a magia do Virtual WAN acontece. No Azure Portal, vá em Virtual WAN → hub-eastus-01 → Roteamento:

  1. Criar uma Route Table chamada rt-all-branches
  2. Associar a Route Table a todos os branch sites que devem ter acesso à AWS VPC
  3. Propagação: Habilite a propagação de rotas do site AWS VPC para todos os branch sites
  4. Adicionar rota estática (opcional, para destinos específicos):
    • Prefixo: 10.10.0.0/16 (AWS VPC)
    • Próximo salto: VPN site (site-aws-vpc-prod)

Isso garante que o tráfego de qualquer filial conectada ao Virtual WAN seja automaticamente routado para a AWS VPC sem configuração adicional em cada branch.

Passo 7 — Verificar a Conectividade

Após aplicar as configurações, aguarde 2-5 minutos para que os túneis IPsec sejam estabelecidos. Para verificar:

No Azure:

# Verificar status dos túneis via CLI
az network vpn-connection show --resource-group rg-cirocloud-vwan-prod \
  --name site-aws-vpc-prod --query "connectionStatus"

No AWS:

# Verificar status dos túneis via CLI
aws ec2 describe-vpn-connections --filter "Name=tag:Name,Values=site-aws-vpc-prod" \
  --query "VpnConnections[0].VpnConnectionState"

Teste de conectividade:

# A partir de uma VM Linux no Azure VNet, testar acesso à AWS
ping -c 4 10.10.0.10  # IP de teste dentro da VPC da AWS
traceroute 10.10.0.10

O traceroute deve mostrar que o tráfego passa pelo Virtual WAN Hub (10.100.0.1) antes de chegar à VPC da AWS.

Cenários Avançados: Integrando SD-WAN e Multi-Cloud

A configuração básica da VPN site-to-site Azure AWS via Virtual WAN é apenas o ponto de partida. Para empresas que buscam maturidade em conectividade multicloud, os cenários avançados abaixo são fundamentais:

Cenário 1 — Integrando SD-WAN com Virtual WAN

Empresas que já utilizam Cisco VMWare VeloCloud, Nuage Virtualized Network Services ou Citrix SD-WAN podem conectar seus appliances diretamente ao Virtual WAN via SD-WAN Branch, sem precisar de túneis IPsec individuais. O processo:

  1. No Virtual WAN Hub, habilite "SD-WAN Configuration" nas propriedades do hub
  2. Configure o SD-WAN Branch como "SD-WAN Partner Device" no portal do fabricante
  3. O Virtual WAN Hub reconhece automaticamente o branch e propaga as rotas via BGP

Benefício mensurável: Em testes da Microsoft com clientes Enterprise, essa integração reduziu o tempo de provisionamento de nova filial de 2 semanas para 4 horas.

Cenário 2 — Adicionando GCP ao Virtual WAN

A arquitetura Virtual WAN também suporta Google Cloud Platform (GCP). O processo é similar à conexão com AWS:

  1. Criar Cloud Router e VPN Tunnel no GCP
  2. Configurar o GCP como um VPN Site no Virtual WAN Hub
  3. Adicionar a rota da VPC do GCP (ex.: 10.30.0.0/16) à Route Table do hub

Com isso, todas as filiais conectadas ao Virtual WAN têm acesso nativo a Azure, AWS e GCP através de uma única arquitetura centralizada.

Cenário 3 — Automação Completa com Terraform

Para Times de DevOps e NetOps que praticam Infrastructure as Code (IaC), a configuração do Virtual WAN pode ser totalmente automatizada com Terraform. Aqui está um exemplo simplificado do provider azapi (para Terraform 1.5+):

# Providers
terraform {
  required_providers {
    azapi = {
      source  = "azure/azapi"
      version = "~> 1.5"
    }
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# Recurso Virtual WAN Hub
resource "azapi_resource" "vwan_hub" {
  type                   = "Microsoft.Network/virtualHubs@2023-04-01"
  name                   = "hub-eastus-01"
  location               = "eastus2"
  resource_group_name    = "rg-cirocloud-vwan-prod"
  parent_id              = azapi_resource.vwan.id
  body = jsonencode({
    properties = {
      sku        = "Standard"
      hubRoutingPreference = "VpnGateway"
      virtualRouterAsn     = 65001
    }
  })
}

# VPC e Virtual Private Gateway na AWS
resource "aws_vpc" "main" {
  cidr_block           = "10.10.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
}

resource "aws_vpn_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "VPG-CiroCloudProd"
  }
}

resource "aws_customer_gateway" "azure" {
  bgp_asn     = 65001
  ip_address  = azapi_resource.vwan_hub.output("properties.vpnGatewayConfiguration.publicIP")
  device_name = "Azure Virtual WAN"
  type        = "ipsec.1"
}

Benefício da IaC: Quando bem implementada, a automação com Terraform reduz erros de configuração em ~73% (segundo pesquisa da Hashicorp State of Terraform 2023) e permite que mudanças de rede sejam revisadas via Git pull request, aumentando a segurança operacional.

Custos, Limites e Best Practices para Produção

Estimativa de Custos Mensais (Cenário de Referência)

Considere um cenário com 10 filiais, 1 VPC AWS, 2 VNets Azure e 1 Virtual WAN Hub Standard na East US 2:

Recurso Quantidade Custo Estimado (USD/mês)
Virtual WAN Hub Standard 1 ~US$ 18
VPN Gateway (dentro do hub) 1 par ativo-ativo ~US$ 36
AWS VPN Connection (Customer Gateway) 1 ~US$ 36
Tráfego de dados (1 TB/mês) 1 TB ~US$ 15
Total ~US$ 105/mês

Comparando com a mesma arquitetura em túneis VPN individuais (10 filiais × 2 cloud providers = 20 túneis), o custo total seria aproximadamente US$ 400-600/mês — uma diferença de 75-85%.

Limites Importantes do Virtual WAN

  • Virtual WAN Standard: até 1.000 branch sites por hub
  • Virtual WAN Premium: até 10.000 branch sites por hub (para cenários hyperscale)
  • Largura de banda por túnel VPN: até 2,5 Gbps (limitação do VPN Gateway Standard SKU)
  • Rotas por Route Table: até 1.000 rotas
  • ** ASN**: range privado 64512-65534 ou 4200000000-4294967294

Best Practices para Ambientes de Produção

  1. Sempre use VPN Gateway ativo-ativo: Garante failover automático sem intervenção manual
  2. Configure BGP com TTL > 1: Evita loops de roteamento em cenários de múltiplos hops
  3. Use IKEv2 com AES-256-GCM e DH Group 14+: Para criptografia robusta do túnel IPsec
  4. Implemente monitoramento com Azure Monitor + AWS CloudWatch: Use o Network Watcher do Azure para visualizar métricas de latência e throughput dos túneis
  5. Separe Route Tables por domínio: Uma Route Table para tráfego de produção, outra para ambientes de desenvolvimento/testes
  6. Automatize backups de configuração: O Virtual WAN não tem versionamento nativo de configuração, então use Terraform para manter o estado versionado no Git

Conclusão: Vale a Pena Implementar VPN Site-to-Site Azure AWS com Virtual WAN?

Absolutamente, para a grande maioria dos cenários de produção. Se sua empresa opera em ambiente multicloud com 3 ou mais filiais, a arquitetura de VPN site-to-site entre Azure e AWS via Virtual WAN oferece:

  • Redução de custo de 40-75% compared to túneis VPN individuais
  • Simplificação operacional drástica (um console, uma fonte de verdade para roteamento)
  • Escalabilidade para adicionar dezenas de filiais sem refatoração de arquitetura
  • Automação nativa via Terraform, PowerShell e Azure CLI
  • Integração com SD-WAN para empresas que já utilizam VMware VeloCloud ou Cisco SD-WAN

Os únicos cenários onde a abordagem tradicional pode ser preferível são: implementações temporárias/POCs, empresas com apenas 1 filial e conectividade simples, ou quando há restrições regulatórias que exigem túneis dedicados sem intermediários.

No próximo artigo desta série, vamos abordar como integrar AWS Direct Connect ao Virtual WAN para cenários onde o tráfego crítico requer latência ainda menor e largura de banda dedicada. Fique atento.

Este guia faz parte do hub de conhecimento Ciro Cloud. Quer aprofundar? Leia também: [Conectividade Multicloud com Azure Private Link e AWS PrivateLink] e [FinOps Cloud: 7 Estratégias para Reduzir Custos de Rede em 30%].

Weekly cloud insights — free

Practical guides on cloud costs, security and strategy. No spam, ever.

Comments

Leave a comment