VPN e Direct Connect

Arquiteturas híbridas conectam a rede corporativa, ou um datacenter próprio, à rede privada na nuvem, e essa conexão é uma decisão de segurança, latência e custo ao mesmo tempo. As duas técnicas centrais na AWS são o Site-to-Site VPN, que estabelece túneis IPsec criptografados sobre a internet, e o Direct Connect, que entrega um link físico dedicado entre o ambiente da empresa e a nuvem. A VPN provisiona em minutos e custa pouco, mas compartilha a internet com todo o resto do mundo; o Direct Connect entrega latência estável e banda garantida, mas leva semanas ou meses para ficar pronto e custa ordens de magnitude mais. Em produção, a escolha não é moral, é por caso de uso: a maioria das organizações acaba com as duas, VPN para rápida e para backup, Direct Connect para o tráfego crítico de dados. Este arquivo cobre o funcionamento, o roteamento BGP e a decisão por cenário.

Conectividade híbrida

A conexão híbrida existe porque migração é um processo, não um evento: bancos de dados replicam para a nuvem durante meses, sistemas on-premises chamam serviços na nuvem e vice-versa, e o Active Directory corporativo continua sendo fonte de identidade por tempo indefinido. Sem conexão privada, essa convivência atravessaria a internet pública, com latência imprevisível e superfície de exposição maior.

O desenho híbrido precisa responder três perguntas antes de escolher tecnologia, e cada uma elimina opções:

• Volume de tráfego: quantos GB por dia atravessam a conexão, em média e em pico, porque banda limitada por túnel e porta dedicada têm custos de natureza diferente.
• Sensibilidade à latência: o tráfego suporta variação de rota pela internet, ou é transacional e quebra com picos de jitter.
• Requisito de disponibilidade: a conexão tolera manutenção sem caminho alternativo, ou o ambiente exige failover automático testado.

As respostas definem se VPN basta, se Direct Connect é necessário ou se a combinação dos dois é o desenho correto.

Site-to-Site VPN

A Site-to-Site VPN cria túneis IPsec criptografados entre o gateway VPN da VPC e um Customer Gateway, que é o equipamento do lado da empresa, um firewall ou roteador compatível com IKEv1 ou IKEv2. Cada conexão provisiona dois túneis por padrão, terminados em dispositivos distintos na AWS, e o uso simultâneo dos dois é o que entrega redundância real. O tráfego dentro do túnel é criptografado, mas percorre a internet: a latência e a perda de pacote variam conforme a rota que os pacotes fazem no caminho público.

• Provisionamento em minutos: sem obra física, sem contrato de telecom, a conexão fica operável no mesmo dia; é o caminho padrão para começar qualquer híbrido.
• Custo por hora e por GB de saída: barato o suficiente para existir como conexão de backup em todo ambiente híbrido sério.
• Banda limitada por túnel: cada túnel suporta até cerca de 1,25 Gbps, e a agregação de múltiplos túneis exige ECMP para escalar além disso.
• Latência variável: o caminho pela internet muda, e picos de congestionamento afetam o tráfego corporativo junto com todo o resto.
• Criptografia por desenho: IPsec entrega confidencialidade e integridade mesmo sobre a internet, o que satisfaz a maior parte das políticas de segurança.

A VPN é a resposta correta quando o tráfego é moderado, a latência tolera variação e a velocidade de provisionamento importa, como em desenvolvimento, em migrações iniciais e como rota de backup do Direct Connect.

Três componentes formam o arranjo e precisam ser nomeados com precisão:

• Customer Gateway: o recurso que representa o equipamento físico ou lógico do lado corporativo, com IP público e ASN declarados.
• Virtual Private Gateway ou Transit Gateway: o lado da nuvem que termina o túnel e propaga rotas para a VPC; o Transit Gateway é o padrão atual quando múltiplas VPCs participam.
• Túneis: cada conexão provisiona dois túneis IPsec terminados em dispositivos distintos, e o desenho de produção usa os dois simultaneamente.

Direct Connect

O Direct Connect é um link físico dedicado, de uma porta com capacidade de 1, 10 ou 100 Gbps, entre o equipamento da empresa ou o parceiro de colocation e a rede do provedor. O tráfego não atravessa a internet: percorre circuito privado com latência estável, banda garantida e picos de jitter previsíveis, o que muda a viabilidade de cargas sensíveis, como replicação transacional de banco e desktop remoto. A conexão é privada, e o padrão de produção é combinar MACsec ou VPN IPsec sobre o Direct Connect quando a criptografia da camada de enlace não está disponível, porque o link privado por si só não é criptografia.

A porta dedicada, contratada direto com o provedor, faz sentido para volumes altos e contínuos; a conexão hosted, entregue por parceiro de colocation que divide a capacidade da porta em partes menores, reduz o custo de entrada e é o formato mais comum para empresas que começam no serviço.

• Latência estável: sem congestionamento alheio, o p99 do caminho se torna previsível, o que é requisito para tráfego transacional entre ambientes.
• Banda dedicada: a porta contratada é exclusiva, e o throughput não depende de horário de pico.
• Provisionamento lento: circuito físico envolve telecom, colocation e testes; conte semanas a meses entre pedido e produção.
• Custo por porta e por GB de egress: o valor fixo mensal é significativo, e a modelagem precisa comparar com o custo de saída pela internet.
• Global Access: com DX Gateway, o mesmo link alcança VPCs em outras regiões, o que centraliza a entrada híbrida de uma organização multiconta e multirregião.

DX Gateway e VPN sobre DX

Duas composições ampliam o alcance dos dois instrumentos. A primeira é o DX Gateway, um roteador global que conecta um Direct Connect a VPCs de múltiplas contas e regiões, com propagação de rotas por BGP, e resolve o problema de uma empresa com dezenas de contas que não quer uma porta física por conta. A segunda é a VPN sobre Direct Connect, um túnel IPsec estabelecido por cima do link dedicado, que adiciona criptografia de camada de rede ao circuito privado, requisito comum em setores regulados.

• Public VIF: virtual interface que alcança endpoints públicos da nuvem, como S3 e API pública, sem internet.
• Private VIF: virtual interface que alcança VPCs via DX Gateway, o desenho padrão de acesso híbrido a recursos privados.
• Transit VIF: conecta o Direct Connect a um Transit Gateway, que por sua vez alcança dezenas de VPCs e conexões VPN, o desenho mais escalável em organizações multiconta.

A combinação madura é transit VIF para o tráfego interno e VPN Site-to-Site como rota de backup, com prioridade de rota definida para que o failover seja automático e testado. O desenho das interfaces virtuais pertence ao projeto desde o início: adicionar VIF depois de o circuito entrar em produção significa nova janela de manutenção com o parceiro, e a previsibilidade de custo depende de saber, por VIF, quanto tráfego cada uma carrega.

Roteamento BGP

O BGP (Border Gateway Protocol) é a linguagem de troca de rotas entre o lado corporativo e a nuvem, e seu funcionamento define o comportamento do failover. Cada lado anuncia prefixos: a empresa anuncia suas redes, a nuvem anuncia as VPCs alcançáveis. Quando existem dois caminhos, VPN e Direct Connect, o BGP decide pela preferência de origem, e a nuvem prefere rotas propagadas de Direct Connect a rotas estáticas de VPN; a empresa, por sua vez, controla a escolha com atributos como AS path prepend e local preference.

# Conexão Site-to-Site VPN com roteamento dinâmico e dois túneis
aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-0corporativo \
  --vpn-gateway-id vgw-0producao \
  --options '{"StaticRoutesOnly":false}'

# Ativa propagação de rotas do gateway VPN na tabela da sub-rede privada
aws ec2 enable-vgw-route-propagation \
  --route-table-id rtb-privadaA \
  --gateway-id vgw-0producao

# Prefixo corporativo anunciado por rota estática quando o lado remoto não fala BGP
aws ec2 create-vpn-connection-route \
  --vpn-connection-id vpn-0hibrido \
  --destination-cidr-block 192.168.0.0/16

Três práticas de roteamento evitam os incidentes clássicos de híbrido. Anuncie prefixos específicos, e não o mundo inteiro, para que um erro de configuração não desvie tráfego da internet corporativa para o túnel. Monitore a sessão BGP como serviço de primeira linha: sessão derrubada é conexão perdida, e o alerta precisa ser imediato. E teste o failover em janela agendada, derrubando o caminho principal e verificando que o backup assume sem ajuste manual.

Os atributos BGP que controlam a escolha de caminho merecem convenção documentada:

• Local preference: define a preferência de saída no lado corporativo; usado para eleger o Direct Connect como primário.
• AS path prepend: alonga o caminho anunciado para tornar uma rota menos atraente; usado para que a VPN assuma apenas quando o DX sair.
• MED e comunidades: refinam a escolha entre múltiplos pontos de presença, e padronizam políticas entre times.

Comparações

Escolha por cenário

A decisão correta parte do caso de uso, e não da tecnologia preferida do time:

• Migração começando agora: Site-to-Site VPN no primeiro dia, porque provisionamento rápido desbloqueia o trabalho enquanto o Direct Connect entra em fase de pedido.
• Replicação transacional de banco com requisito de p99: Direct Connect, porque a variância da internet quebra janelas de sincronização e RPO.
• Dados regulados com exigência de criptografia no trânsito: VPN sobre Direct Connect, ou MACsec onde disponível, para cumprir controle com evidência de auditoria.
• Centenas de filiais com tráfego pequeno: Site-to-Site VPN por filial, eventualmente agregada em SD-WAN, pois porta dedicada não se paga.
• Organização multiconta multirregião: Direct Connect com DX Gateway ou Transit Gateway centralizando a entrada, com VPN como rota de backup em cada região.

Erros comuns

• Um único túnel VPN em produção: a conexão provisiona dois túneis por desenho, e usar só um elimina a redundância que já foi paga.
• Assumir que o Direct Connect é criptografado: link privado não é link cifrado; reguladores esperam IPsec ou MACsec, e o gap só aparece na auditoria.
• Rotas estáticas em ambiente dinâmico: sem BGP, o failover exige intervenção humana, e o backup que precisa de pessoa para assumir não é backup.
• Prefixos sobrepostos entre on-premises e VPC: sobreposição de CIDR impede o roteamento inteiro; a checagem é pré-requisito de projeto, não ajuste de incidente.
• MTU ignorado: pacotes fragmentados em túnel IPsec produzem timeouts difíceis de diagnosticar; alinhe MTU dos dois lados no desenho.
• Failover nunca testado: a rota de backup existe no diagrama e nunca derrubou o caminho principal; teste agendado é a única prova válida.
• Documentação do lado corporativo ausente: sem registro do ASN, dos prefixos anunciados e do contato do equipamento Customer Gateway, cada incidente vira arqueologia de configuração.
• Custos de egress não modelados: a porta do DX foi dimensionada, mas o GB de saída pela internet de backup não entrou na planilha; o failover quebra o orçamento.

Boas práticas em produção

Desenhe com dois caminhos desde o primeiro dia: Direct Connect como primário para o tráfego crítico e Site-to-Site VPN como backup automático, com BGP priorizando o link dedicado e monitoramento de sessão em ambas as direções. Dimensione a porta do Direct Connect por pico observado na VPN durante a fase inicial, com margem para crescimento, e revise a utilização trimestralmente, porque porta ociosa e porta saturada são ambos erros de custo.

Documente os prefixos anunciados como código, com revisão formal para qualquer mudança de anúncio, e mantenha o inventário de Customer Gateway e de sessões BGP no mesmo repositório da infraestrutura. Para organizações multiconta, centralize a entrada híbrida com DX Gateway e Transit Gateway em conta de rede dedicada, e distribua rotas por propagação, evitando tabelas manuais que divergem entre ambientes. O híbrido maduro é aquele em que a conexão entre nuvem e datacenter é boring, no melhor sentido: monitorada, testada e invisível até o dia em que alguém pergunta por que a replicação nunca atrasou.