Configure VPN site-to-site Azure AWS com Virtual WAN. Guia técnico completo com passos, custos e boas práticas para arquitetura híbrida.


Você está perdendo dinheiro com enlaces dedicados de alta capacidade quando uma VPN site-to-site Azure AWS poderia resolver 80% dos seus casos de uso por uma fração do custo? Ou talvez esteja lutando para manter múltiplas túneis VPN point-to-point entre dezenas de branches e seus ambientes multicloud, o que degrada a performance e multiplica a complexidade operacional.

A realidade é que integrar Azure e AWS de forma segura nunca foi tão crítico quanto agora. Segundo o último relatório da Flexera (2024), 89% das empresas受访者 já operam em ambientes multicloud, e a conectividade entre provedores deixou de ser opcional para ser infraestrutura crítica.


O que é o Virtual WAN e por que usar para VPN site-to-site Azure AWS?

O Azure Virtual WAN é um serviço de rede que unifica conectividade branch-to-cloud, branch-to-branch e VPNAzure/AWS em uma única arquitetura gerenciável. Em vez de configurar túneis IPsec individuais entre cada site e cada cloud provider, você centraliza tudo em um Virtual WAN Hub — que funciona como um concentrador (hub-and-spoke) para todo o tráfego de rede.

Na prática, isso significa que quando você conecta a AWS via VPN site-to-site ao Virtual WAN do Azure, todos os seus branches que usam SD-WAN ou túneis VPN point-to-site podem alcançar recursos na AWS através de uma única conexão. A complexidade operacional cai drasticamente.

Comparado com abordagens tradicionais (túneis manuais VNet-peering + VPN Gateways individuais):

  • Virtual WAN: Gerenciamento centralizado, automação via Terraform/PowerShell, roteamento dinâmico com BGP, suporte a SD-WAN nativo
  • VPN tradicional: Cada túnel é gerenciado independentemente, sem visão unificada de tráfego, roteamento manual

Para cenários com mais de 5 branches ou múltiplas VNets/VPCs, o Virtual WAN reduz custos operacionais em aproximadamente 40% segundo estimativas baseadas em implementações reais em produção.


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

Antes de mexer no console, garanta que você tem:

Do lado Azure:

  • Assinatura Azure com permissões de Contributor ou Network Contributor no resource group de destino
  • Virtual Network (VNet) com pelo menos um subnet para o GatewaySubnet (/27 ou maior)
  • Conta de armazenamento para logs (opcional mas recomendado)
  • Conhecimento básico de BGP e endereçamento IP

Do lado AWS:

  • Conta AWS com permissões de IAM para VPC, VPN e DirectConnect (mesmo sem usar DirectConnect, os permisos são necessários)
  • Uma VPC existente com subnets para as suas aplicações
  • CIDR da VPC que não sobreponha com o CIDR do Azure VNet ou outros branches
  • Amazon VPC CIDR exemplo: 10.2.0.0/16

Importante —Sobreposição de CIDR:
Este é o erro mais comum em implementações de VPN site-to-site Azure AWS. Se o bloco CIDR do seu Azure VNet (ex: 10.0.0.0/16) sobrepõe com a VPC da AWS (ex: 10.0.0.0/16), o tráfego nunca funcionará corretamente. Planeje seus blocos IP antes de começar. Recomendação: use RFC 6598 (100.64.0.0/10) para links point-to-point entre provedores se você tiver escassez de endereços.


Passo a Passo: Configurando o Azure Virtual WAN

1. Criar o Recurso Virtual WAN

No portal Azure, pesquise por "Virtual WAN" e clique em Create.

Resource Group: rg-cloud-hub-prod
Name: vwan-cloud-interconnect
Region: Brazil South (ou East US, West Europe — escolha proximidade geográfica)
Type: Standard (para suportar conectividade cross-cloud avançada)

Por que Standard e não Basic? A versão Basic suporta apenas túneis VPN site-to-site básicos sem roteamento dinâmico. Para integrar AWS com BGP e ter a possibilidade de conectar ExpressRoute ou outras branches no futuro, Standard é obrigatório. O custo adicional é mínimo (cerca de R$25/mês por hub vs R$12/mês na Basic) e a flexibilidade compensará.

2. Criar o Virtual WAN Hub com VPN Gateway

Após criar o Virtual WAN:

  1. Vá em HubsAdd Hub
  2. Configure o hub:
    • Region: Brazil South
    • Hub name: hub-vpn-prod
    • Hub private address space: 10.100.0.0/24 (subnet do hub)
    • Enable Site-to-site VPN: ✓
    • Configure VPN Gateway:
      • Gateway scale units: 1 (mínimo) ou 2 (para alta disponibilidade — recomendável para produção)
      • Routing preference: Microsoft (padrão) ou ASG (Autonomous System Gateway)
      • VPN protocol: IKEv2 (suportado pela AWS)

Sobre Gateway Scale Units: Cada scale unit = 500 Mbps de throughput agregado. Para workloads de produção com 100+ Mbps de transferência de dados entre clouds, use pelo menos 2 scale units. O custo é aproximadamente R$0,035/hora por scale unit = ~R$25/mês por scale unit em regime 24/7.

3. Configurar o Connection (Site) para a AWS

No hub criado:

  1. Vá em Site-to-site VPNConnectionsAdd
  2. Preencha:
    • Connection name: aws-vpn-connection
    • Device name: AWS-VPN-Gateway (identificador interno)
    • Routing: Static (para começar) ou Dynamic (BGP — mais flexível)

Recomendação: Use BGP (Dynamic). A AWS só suporta BGP para VPN site-to-site, e o BGP permite que ambas clouds aprendam rotas dinamicamente, facilitando propagação de rotas em topologias complexas. O Azure Virtual WAN suporta BGP nativamente a partir da SKU Standard.


Passo a Passo: Configurando a VPN na AWS

1. Criar um Customer Gateway

No Console AWS (VPC → Site-to-Site VPN Connections → Customer Gateways):

Name tag: azure-vwan-cgw
Routing: Dynamic (BGP)
BGP ASN: 65001 (escolha um ASN privado que não conflite)
IP address: <PUBLIC_IP_DO_AZURE_VPN_GATEWAY> (você obterá esse IP no próximo passo)

Onde encontrar o IP público do Azure VPN Gateway: No Azure, vá ao Virtual WAN Hub → VPN Gateway → Overview. Você verá dois IPs públicos (para redundância active-active). Use ambos como Customer Gateways na AWS para alta disponibilidade.

2. Criar a VPN Connection e Virtual Private Gateway

a) Criar Virtual Private Gateway (VGW):

No Console AWS (VPC → Virtual Private Gateway):

Name tag: azure-vgw
ASN: 65002 (ASN privado diferente do Customer Gateway)

Attach o VGW à sua VPC de produção.

b) Criar Site-to-Site VPN Connection:

Name tag: azure-vpn-connection
Virtual Private Gateway: azure-vgw (criado acima)
Customer Gateway: Existing
Customer Gateway ID: azure-vwan-cgw
Routing options: Dynamic (requires BGP)
Tunnel Options: Use default ou customize

3. Baixar a Configuração da AWS

Este é o passo crítico que faltava. Após criar a VPN Connection na AWS:

  1. Clique na conexão → Download Configuration
  2. Selecione Vendor: Generic (não Azure — o Azure não tem perfil pré-configurado)
  3. Salve o arquivo .txt

Abra o arquivo e localize os parâmetros essenciais:

  • Tunnel 1 e Tunnel 2: Endereços IP externos (Outside IP Addresses)
  • Pre-shared keys (PSK): Para cada túnel
  • BGP Configuration: ASN da AWS, IP do Peer BGP (Inside IP Addresses)
  • VPC CIDR: O bloco de rede da sua VPC (ex: 10.2.0.0/16)

Conectando Azure Virtual WAN à AWS: Finalizando a Integração

Agora você tem as informações de ambos os lados. Volte ao Azure:

1. Preencher os Detalhes do Site (AWS) no Azure

No Azure Virtual WAN Hub → VPN Sites:

Site name: aws-production
Private address space: 10.2.0.0/16 (CIDR da VPC AWS)
BGP: Enable
BGP IP: <BGP_PEER_IP_DO_TUNNEL1_DA_AWS>
BGP ASN: 65002 (ASN da AWS)
Device vendor: AWS
Link speed: 100Mbps (estimativa)

2. Configurar a Pre-Shared Key e IP do Túnel

No Azure, vá para o Connection do site (aws-vpn-connection):

Connection Protocol: IKEv2
Authentication method: Pre-shared key
Pre-shared key: <PSK_DO_TUNNEL1_DA_AWS>
Remote IP: <TUNNEL_OUTSIDE_IP_DA_AWS>
BGP peer address: <BGP_PEER_IP_DA_AWS>
Local BGP IP: <BGP_PEER_IP_DO_AZURE>

Repita para o Túnel 2 — a AWS cria dois túneis redundantes por padrão (active-standby ou active-active dependendo da configuração). Configure ambos para alta disponibilidade.

3. Verificar a Conexão

No Azure:

# Verificar status do túnel
Get-AzVpnGatewayConnection -ResourceGroupName "rg-cloud-hub-prod" -Name "hub-vpn-prod"

O status deve mostrar "Connected" para ambos os túneis.

No AWS:

# Verificar túneis VPN
aws ec2 describe-vpn-connections --vpn-connection-ids <vpn-id>

Teste de Conectividade:

# Do Azure (VM em uma VNet conectada ao hub):
ping 10.2.0.1  # IP interno de uma instância EC2
traceroute 10.2.0.1

# Do AWS (instância EC2):
ping 10.0.1.4  # IP de uma VM no Azure VNet

Se o ping funcionar em ambas direções, a VPN site-to-site Azure AWS está operacionais.


Custos e Estimativas de Preço (2024)

Para uma configuração de produção com redundância:

Azure:

  • Virtual WAN: Gratuito (taxa por hub apenas se usar features premium)
  • Virtual WAN Hub Standard: R$0,035/hora × 730h ≈ R$25/mês
  • VPN Gateway (2 scale units para HA): R$0,035 × 2 × 730 ≈ R$51/mês
  • Egress data transfer (saída de dados): ~R$0,45/GB após o tier gratuito

AWS:

  • Site-to-Site VPN: R$0,05/hora × 730h ≈ R$36/mês (por VPN connection)
  • Data transfer: ~R$0,02/GB para transferência de dados para o Azure via VPN (inter-region)

Total estimado: R$112-160/mês para uma VPN site-to-site Azure AWS com alta disponibilidade, comparado com R$400-800/mês de um AWS Direct Connect dedicado ou Azure ExpressRoute.

Dica FinOps: Se o seu throughput entre clouds ultrapassa consistentemente 500 Mbps, Direct Connect ou ExpressRoute começam a fazer mais sentido economicamente. Para a maioria dos workloads (microserviços, backups cross-cloud, disaster recovery), a VPN com Virtual WAN oferece excelente custo-benefício.


Boas Práticas e Troubleshooting

Boas Práticas de Implementação

  1. Use BGP em todas as conexões. Evita configuração manual de rotas estáticas e permite failovers automáticos.

  2. Configure health checks. Use Azure Monitor ou AWS CloudWatch para monitorar o status dos túneis. Configure alertas quando um túnel cair.

  3. Implemente política de roteamento. No Virtual WAN, você pode configurar rotas específicas para controlar qual tráfego vai por qual túnel — essencial para compliance e segmentação.

  4. Habilite o Log Analytics. Para troubleshooting, conecte os logs do VPN Gateway ao Log Analytics Workspace. Queries úteis:

AzureDiagnostics
| where Category == "GatewayDiagnosticLog"
| project TimeGenerated, Message, Resource
| order by TimeGenerated desc
  1. Dê preferência ao IKEv2. A AWS suporta IKEv1 e IKEv2, mas IKEv2 tem melhor compatibilidade com NAT-Traversal e é mais robusto para túneis através de firewalls.

Troubleshooting Comum

Problema: Túneis não estabelecem (status: "Connecting" ou "Disconnected")

  • Verifique se o IP público do Azure VPN Gateway está correto no Customer Gateway da AWS
  • Confirme que as pre-shared keys coincidem exatamente (um espaço extra quebra a conexão)
  • Verifique se os Security Groups das instâncias EC2 permitem ICMP e tráfego na porta 500/4500 UDP

Problema: Túneis conectados mas sem ping entre clouds

  • Causa mais provável: sobreposição de CIDR — verifique se não há blocos IP duplicados
  • Verifique as rotas no Route Tables: tanto na VNet do Azure quanto nas subnets da VPC da AWS precisam ter rotas para o peer network
  • No Azure: VNet connection → effective routes
  • Na AWS: Route Table da subnet → rotas propagadas pelo VGW

Problema: Latência elevada ou throughput baixo

  • VPN sobre internet pública tem latência inerente (tipicamente 30-80ms dependendo da geografia)
  • Para benchmarks, use iperf3 entre VMs em cada cloud para medir throughput real (esperado: 80-300 Mbps para túneis de 1 Gbps)
  • Se precisar de mais performance, considere Direct Connect/ExpressRoute para workloads críticos

Quando Usar Virtual WAN vs Alternativas

Use Virtual WAN quando:

  • Você tem múltiplos branches/filiais conectando ao cloud
  • Quer gerenciar conectividade multicloud (Azure + AWS) de forma centralizada
  • Precisa de SD-WAN integration ou Branch-to-Cloud unificada
  • Seu throughput entre clouds é < 500 Mbps

Use alternativas quando:

  • Apenas duas clouds sem branches: VPN Gateway nativo do Azure + AWS VPN é mais simples
  • Precisa de latência < 10ms e throughput > 1 Gbps: Direct Connect ou ExpressRoute
  • Cargas de trabalho que exigem compliance PCI-DSS ou SOC2 com requisitos estritos de criptografia dedicados

A VPN site-to-site Azure AWS via Virtual WAN é uma solução robusta para a maioria dos cenários de integração multicloud empresarial. Com o BGP configurado corretamente e monitoramento ativo, você terá conectividade resiliente entre clouds a um custo significativamente inferior ao de links dedicados.

Weekly cloud insights — free

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

Comments

Leave a comment