Direct Connect e VPN Site-to-Site: Conectando o Datacenter à AWS

Cabos de fibra óptica conectados a um switch de rede representando uma conexão AWS Direct Connect
Índice do artigo

Uma VPN Site-to-Site fica pronta em minutos. Um circuito de AWS Direct Connect costuma levar semanas — envolve negociar com um parceiro de colocation, instalar fibra e agendar um cross-connect físico. Essa diferença de prazo é só a primeira de várias decisões que uma empresa com datacenter próprio ou colocation precisa tomar antes de assinar um contrato de conectividade híbrida com a AWS. Este guia explica como funcionam o AWS Direct Connect e a AWS Site-to-Site VPN, quando cada um faz sentido, e como as duas estratégias — sozinhas ou combinadas — resolvem o problema de latência, banda e resiliência entre o ambiente físico e a nuvem.

O Que É AWS Direct Connect e Como Ele Funciona

O Direct Connect é uma conexão física e dedicada entre a rede da sua empresa e a AWS, estabelecida por um cabo de fibra óptica em um dos locais de Direct Connect espalhados pelo mundo. O tráfego nunca passa pela internet pública: sai do seu roteador, atravessa a fibra até o roteador da AWS, e chega à nuvem por um caminho fisicamente isolado. Isso muda a natureza do problema de rede — de "como proteger e priorizar tráfego que compete com todo o resto da internet" para "como usar um caminho que já é seu".

Existem dois modelos de contratação. Uma conexão dedicada é um link físico só seu, com portas de 1, 10, 100 ou 400 Gbps, provisionado diretamente pela AWS num local de Direct Connect onde sua empresa tem presença física ou colocation. Uma conexão hospedada é uma fração de capacidade de um circuito que já existe, provisionada por um parceiro da AWS Partner Network — com opções bem mais granulares, de 50 Mbps a 25 Gbps, incluindo faixas intermediárias como 2 Gbps e 5 Gbps conforme o parceiro. Para a maioria das empresas de porte médio, a conexão hospedada é o caminho de entrada: não exige negociar colocation nem comprar equipamento de borda dedicado, e o parceiro de conectividade (o mesmo que já entrega o link MPLS ou internet dedicada) provisiona o circuito.

Depois de estabelecida a conexão física, o tráfego só flui de fato quando você cria uma interface virtual (VIF) sobre ela. A AWS suporta três tipos: a VIF privada conecta um roteador on-premises a uma VPC específica usando IPs privados; a VIF pública dá acesso a serviços AWS com endereço público, como S3, usando o IP público do serviço, sem passar pela internet; e a VIF de trânsito conecta o circuito a um ou mais AWS Transit Gateway, permitindo alcançar várias VPCs em várias contas e regiões pelo mesmo circuito físico. Cada circuito pode ter várias VIFs simultâneas, cada uma isolada por VLAN 802.1Q e roteada por BGP — a sessão precisa suportar autenticação BGP MD5, o que já elimina roteadores domésticos ou de borda mais simples da equação.

Quando a operação cresce além de uma VPC ou de uma região, entra o Direct Connect Gateway: um recurso que associa uma VIF privada ou de trânsito a múltiplos virtual private gateways ou Transit Gateways, em contas e regiões diferentes (exceto China), sem cobrança adicional por essa associação. É o mecanismo que permite ter um único circuito físico em São Paulo, por exemplo, e alcançar cargas de trabalho hospedadas em us-east-1 sem contratar um segundo circuito lá. Vale notar que esse desenho de rede multi-conta e multi-região é o assunto do artigo VPC e Transit Gateway: a Arquitetura de Rede Avançada para Ambientes AWS Multi-Região — este guia foca na conectividade entre o datacenter físico e a AWS, não na arquitetura interna que recebe esse tráfego do outro lado.

VPN Site-to-Site: Conectividade Híbrida Sobre a Internet Pública

Cabeamento de rede estruturado representando um cross-connect entre datacenter e provedor de nuvem

A AWS Site-to-Site VPN resolve o mesmo problema — ligar a rede on-premises à AWS — por um caminho completamente diferente: um túnel IPsec criptografado sobre a internet pública. Não exige fibra dedicada, cross-connect nem colocation. Do lado da empresa, um customer gateway device (um firewall, roteador ou appliance de VPN que já existe na maioria das redes corporativas) estabelece o túnel com um target gateway do lado da AWS, que pode ser um virtual private gateway anexado a uma VPC específica ou um Transit Gateway compartilhado entre várias VPCs.

Cada conexão VPN Site-to-Site já nasce com dois túneis IPsec simultâneos, apontando para dois endpoints diferentes na AWS — a redundância vem embutida no produto, não é uma opção à parte. O padrão de largura de banda é de 1,25 Gbps por túnel; para quem precisa de mais, a AWS oferece o Large Bandwidth Tunnel, que sobe esse limite para até 5 Gbps por túnel, mas só para conexões anexadas a um Transit Gateway ou ao Cloud WAN — não está disponível em conexões apontando direto para um virtual private gateway.

Tecnicamente, a Site-to-Site VPN suporta IKEv2, autenticação BGP com ASN de 4 bytes do lado AWS, criptografia AES de 256 bits, hashing SHA-2 e opções de grupo Diffie-Hellman configuráveis por túnel — não é uma VPN de consumo, é um produto pensado para tráfego de produção. A cobrança é simples: por hora de conexão provisionada, mais a tarifa normal de data transfer out da região. Não há taxa de porta como no Direct Connect, o que também explica por que ela pode ser provisionada, testada e descartada em minutos.

Direct Connect vs VPN Site-to-Site: Comparando as Duas Estratégias

Nenhuma das duas opções é superior de forma absoluta — a escolha depende do que a carga de trabalho exige e do quanto a empresa está disposta a esperar e a comprometer contratualmente.

Critério AWS Direct Connect AWS Site-to-Site VPN
Caminho do tráfego Fibra dedicada, fora da internet pública Túnel IPsec sobre a internet pública
Latência Previsível e baixa, sem competir com outro tráfego Variável, sujeita a congestionamento e rota da internet
Largura de banda 1 a 400 Gbps (dedicada) ou 50 Mbps a 25 Gbps (hospedada) 1,25 Gbps por túnel padrão; até 5 Gbps com Large Bandwidth Tunnel (só via Transit Gateway/Cloud WAN)
Prazo de contratação Semanas — depende de local, parceiro e instalação física Minutos a horas
Modelo de cobrança Port-hour + data transfer out Connection-hour + data transfer out
Criptografia nativa Não — o isolamento é físico, não criptográfico Sim — IPsec com AES-256
SLA de referência 99,9%+ só em desenho multi-site; conexão única não tem SLA de disponibilidade garantida Sem SLA formal de uptime documentado da mesma forma; depende da resiliência do túnel duplo
Melhor para Tráfego alto e constante, workloads sensíveis a latência/jitter Backup, ambientes menores, migração rápida, prova de conceito

A diferença que mais pesa na decisão de uma empresa de porte médio costuma ser o prazo: enquanto o time de rede negocia o circuito físico e aguarda a instalação, a VPN já está entregando conectividade. É por isso que a arquitetura mais comum não escolhe uma ou outra — combina as duas, como o próximo tópico detalha.

Benefícios do Direct Connect: Latência Previsível, Largura de Banda e Segurança

O ganho mais citado do Direct Connect é a latência previsível. Como o tráfego não compartilha caminho com o resto da internet, ele não sofre as variações de jitter e roteamento que uma conexão via internet pública tem, mesmo quando essa conexão está criptografada e íntegra. Para cargas sensíveis a essa variação — replicação síncrona de banco de dados, VDI, tráfego de storage entre o datacenter e a AWS — essa previsibilidade importa mais do que a velocidade nominal do link.

O segundo ganho é largura de banda em escala: uma porta de 10, 100 ou 400 Gbps atende volumes de dados que uma VPN, limitada a 1,25 ou 5 Gbps por túnel, simplesmente não sustenta sem multiplicar túneis e complicar o roteamento. Para uma empresa migrando um datacenter inteiro, ou operando replicação contínua de um volume grande de dados, essa diferença de ordem de grandeza é o fator decisivo.

O terceiro ganho, menos intuitivo, é de custo de transferência de dados em volume: a tarifa de saída de dados por Direct Connect costuma ser mais barata por gigabyte do que a mesma transferência pela internet pública — o que, somado ao custo fixo do port-hour, tende a compensar a partir de um determinado volume mensal, e não antes disso. Vale a conta real, não a intuição: circuitos de baixo uso raramente justificam o investimento.

Sobre segurança, é importante não confundir isolamento físico com criptografia: o Direct Connect, por padrão, não criptografa o tráfego — ele isola fisicamente o caminho, o que já é uma barreira relevante, mas não é o mesmo que cifrar os dados em trânsito. Quem precisa de criptografia ponta a ponta sobre um circuito Direct Connect normalmente estabelece uma VPN dentro dele (uma VIF privada com um túnel IPsec por cima), ou usa um dos serviços de MACsec da AWS nos locais que suportam. Essa é uma decisão de arquitetura separada da decisão de qual conectividade contratar.

Fileiras de racks de servidores em datacenter representando uma arquitetura de conectividade redundante

A AWS documenta três modelos de resiliência para Direct Connect, e a diferença entre eles não é sutil — é a diferença entre sobreviver à queda de um roteador e sobreviver à perda de um datacenter inteiro. No modelo Single-Site Redundant, a empresa contrata pelo menos duas conexões em dispositivos diferentes, mas no mesmo local de Direct Connect. Isso protege contra falha de equipamento, mas a própria AWS é explícita: esse desenho "não ajuda em caso de falha total do local" — se o datacenter que hospeda esse local cair, as duas conexões caem junto.

Para workloads de produção, a AWS recomenda um dos dois modelos seguintes. O Multi-Site Non-Redundant (também chamado de High Resiliency) usa uma conexão em cada um de pelo menos dois locais diferentes, protegendo contra falha de fibra, de dispositivo e de local inteiro. O Multi-Site Redundant (Maximum Resiliency) vai além: exige conexões separadas em dispositivos separados, em múltiplos locais — tipicamente quatro conexões distribuídas em dois ou mais locais — para a resiliência máxima. Segundo a página de SLA do Direct Connect, só esses dois desenhos multi-site têm cobertura de SLA (entre 99,0% e 99,99%, dependendo da faixa e do modelo, e condicionada a ter Enterprise Support); uma conexão única não tem compromisso formal de disponibilidade comparável.

Para quem já opera múltiplas VPCs e contas, o Direct Connect Gateway permite estender essa resiliência para um desenho multi-região: uma VIF de trânsito ou privada associada ao gateway alcança Transit Gateways ou virtual private gateways em regiões diferentes, sem precisar de um circuito físico dedicado em cada região. Isso combina bem com uma Landing Zone e AWS Organizations bem estruturada, onde a conectividade de rede é centralizada numa conta de rede e propagada para as contas de carga de trabalho.

E é aqui que a VPN Site-to-Site entra como peça de arquitetura, não como concorrente: montar uma VPN de contingência sobre o mesmo Transit Gateway que recebe o Direct Connect é o padrão mais comum de resiliência híbrida em empresas de porte médio. Como a VPN é provisionada em minutos e cobrada só por hora de conexão, ela funciona como plano B de baixo custo fixo para o cenário — raro, mas real — de corte de fibra ou falha do circuito dedicado. O roteamento por BGP decide automaticamente qual caminho usar, priorizando o Direct Connect por métrica de rota quando ele está disponível.

Quanto Custa Conectar o Datacenter à AWS

Patch panel de fibra óptica organizado representando a infraestrutura física de um cross-connect AWS Direct Connect

O Direct Connect tem dois componentes de cobrança, segundo a página oficial de preços: a tarifa de porta (port-hour), cobrada continuamente enquanto o circuito existe — mesmo sem tráfego passando — e a tarifa de data transfer out, por gigabyte, que varia conforme a região de origem e o local de Direct Connect de destino. Como referência de ordem de grandeza (os valores variam por região e mudam com o tempo, então confirme na página oficial antes de orçar): uma conexão dedicada de 1 Gbps parte de algo como US$ 0,30 por hora, uma de 10 Gbps perto de US$ 2,25 por hora, chegando a faixas bem maiores nas portas de 100 e 400 Gbps. Conexões hospedadas, por serem fracionadas por um parceiro, começam bem mais baratas — na casa de poucos centavos de dólar por hora para os planos de entrada — mas o parceiro cobra a própria mensalidade do circuito por cima. A entrada de dados (data transfer in) não é cobrada pela AWS em nenhum dos dois modelos.

A Site-to-Site VPN tem estrutura mais simples: cobrança por hora de conexão provisionada, mais a tarifa padrão de data transfer out da região — sem tarifa de porta separada. Não há economia de escala aparente na VPN como há no Direct Connect: o custo por hora é fixo independentemente do volume trafegado, o que a torna previsível para orçamento, mas menos vantajosa que o Direct Connect quando o volume de dados cresce muito.

A conta que decide qual opção compensa não é o preço de tabela isolado, é o custo total por gigabyte transferido somado ao custo de oportunidade do prazo de contratação. Isso é exatamente o tipo de análise que uma prática de FinOps na AWS deveria capturar antes de assinar um contrato de circuito dedicado de longo prazo — inclusive porque, diferente de um recurso de nuvem, um circuito físico não se desliga da noite para o dia se o volume de tráfego cair.

Qual Modelo Faz Sentido Para o Porte da Sua Empresa

Close-up de switch de rede corporativo representando a infraestrutura de conectividade híbrida de uma empresa

Para empresas na faixa de 30 a 100 funcionários, com uma carga de trabalho migrada parcialmente para a AWS e tráfego moderado entre datacenter e nuvem, a Site-to-Site VPN sozinha costuma resolver — o custo fixo baixo e o provisionamento rápido pesam mais do que o ganho de latência de um circuito dedicado que ficaria subutilizado. É também o caminho natural durante uma migração: sobe a VPN em minutos, valida a arquitetura, e só depois avalia se o volume justifica um Direct Connect.

Na faixa de 100 a 300 funcionários, com bancos de dados híbridos, replicação constante ou uma aplicação sensível a latência entre o ambiente local e a AWS, uma conexão hospedada de Direct Connect com VPN de contingência costuma ser o ponto de equilíbrio: banda suficiente sem o compromisso de uma conexão dedicada inteira, e resiliência garantida pelo túnel de backup.

Para empresas de 300 a 700 funcionários, especialmente as que mantêm datacenter próprio com dependência real de baixa latência — ERP crítico, storage compartilhado, VDI em escala — o cenário típico é uma conexão dedicada com desenho Multi-Site Non-Redundant ou Redundant, Direct Connect Gateway para alcançar múltiplas contas e regiões, e VPN como camada de contingência. É o único porte em que o investimento de um circuito físico redundante, com o custo de porta correspondente, costuma se pagar pelo volume de dados e pela criticidade da aplicação.

Não existe modelo certo por tamanho de empresa isoladamente — depende do quanto a aplicação realmente sofre com latência variável e do volume de dados que atravessa a conexão todo mês. Uma empresa de 80 funcionários rodando um workload de renderização ou telemetria industrial pode justificar um Direct Connect que uma empresa de 400 funcionários com aplicações tolerantes a latência nunca precisaria.

Tendências: SD-WAN, Multi-Nuvem e Conectividade Híbrida Sob Demanda

Duas tendências estão mudando como as empresas pensam essa decisão. A primeira é a integração entre Direct Connect e soluções de SD-WAN — cada vez mais os appliances de borda corporativos enxergam o circuito Direct Connect e o túnel de VPN como caminhos de uma mesma malha de rede, escolhendo a rota automaticamente por política, não só por métrica BGP simples. Isso reduz a complexidade operacional de manter os dois caminhos coordenados.

A segunda é a pressão para conectividade multi-nuvem pelo mesmo circuito físico: empresas que operam AWS e outro provedor a partir do mesmo datacenter buscam consolidar o cross-connect em vez de contratar um circuito dedicado por nuvem, o que empurra a decisão de arquitetura de rede para fora da AWS isoladamente e para dentro da estratégia geral de conectividade da empresa — outro motivo para tratar essa escolha como projeto de infraestrutura, não como configuração pontual de um serviço.

Perguntas Frequentes sobre AWS Direct Connect

Direct Connect substitui a VPN Site-to-Site?

Na maioria dos desenhos de produção, não — as duas coexistem. O Direct Connect carrega o tráfego principal, com latência previsível e banda alta, enquanto a VPN Site-to-Site atua como caminho de contingência, provisionado sobre o mesmo Transit Gateway, assumindo o tráfego automaticamente por BGP se o circuito físico falhar.

Quanto tempo leva para contratar um Direct Connect?

A AWS não publica um prazo oficial fechado. Na prática, uma conexão dedicada envolve negociar colocation ou parceiro, agendar a instalação física da fibra e o cross-connect no local de Direct Connect — um processo tipicamente medido em semanas, não em dias. Uma conexão hospedada por um parceiro de conectividade costuma ser mais rápida, porque usa capacidade que o parceiro já tem instalada.

O tráfego pelo Direct Connect é criptografado?

Não por padrão. O Direct Connect isola o tráfego fisicamente da internet pública, mas não aplica criptografia automaticamente. Para cifrar os dados em trânsito sobre um circuito Direct Connect, a prática comum é estabelecer uma VPN IPsec sobre a VIF privada, ou usar MACsec nos locais de Direct Connect que oferecem suporte a esse recurso.

O que é o Direct Connect Gateway e quando ele é necessário?

É o recurso que permite associar uma única VIF privada ou de trânsito a múltiplos virtual private gateways ou Transit Gateways, em contas e regiões diferentes, sem cobrança adicional por essa associação. Torna-se necessário quando a empresa opera mais de uma VPC, mais de uma conta ou mais de uma região e quer evitar contratar um circuito físico separado para cada uma.

Qual a diferença entre conexão dedicada e conexão hospedada?

A conexão dedicada é um circuito físico só seu, provisionado diretamente pela AWS, com portas de 1 a 400 Gbps. A conexão hospedada é uma fração de capacidade de um circuito que já existe, provisionada por um parceiro da AWS Partner Network, com opções bem mais granulares — de 50 Mbps a 25 Gbps. A hospedada costuma ser o ponto de entrada para empresas que não têm presença física num local de Direct Connect.

A Site-to-Site VPN tem SLA de disponibilidade garantido?

A AWS não publica um SLA de uptime para a Site-to-Site VPN da mesma forma detalhada como faz para o Direct Connect. A resiliência vem da arquitetura do produto: cada conexão já inclui dois túneis IPsec simultâneos apontando para endpoints diferentes, o que é o mecanismo de alta disponibilidade embutido, não uma opção contratada à parte.

Preciso de Direct Connect se meu volume de dados é pequeno?

Provavelmente não. O custo fixo do port-hour, somado ao prazo e à complexidade de contratação, raramente compensa para volumes baixos ou esporádicos de tráfego. A Site-to-Site VPN, com seu modelo de cobrança por hora sem tarifa de porta, tende a ser mais econômica até que o volume mensal de dados justifique o investimento — vale fazer essa conta antes de assinar qualquer contrato de circuito.

A Conectividade Híbrida É uma Decisão de Arquitetura, Não Só de Contrato

Escolher entre Direct Connect e VPN Site-to-Site — ou, mais frequentemente, decidir como combinar os dois — não é uma questão de qual serviço é "melhor", é uma questão de qual caminho o tráfego da sua empresa realmente precisa, com que previsibilidade, e a que custo por gigabyte. Datacenter e nuvem convivendo bem depende menos do produto contratado e mais de quem, na empresa, é responsável por revisar essa conta conforme o volume de dados e a criticidade das aplicações mudam com o tempo.

Empresas que tratam essa decisão como projeto de infraestrutura — com prazo de contratação mapeado, modelo de resiliência escolhido de propósito e VPN de contingência desenhada desde o início — evitam tanto o custo de um circuito dedicado subutilizado quanto o risco de depender de um único caminho de rede para uma operação crítica.

Artigos Relacionados

Foto de Eduardo Souza | CEO Dominit
Eduardo Souza | CEO Dominit
Eduardo Souza é um renomado CEO do setor de tecnologia da informação, especializado em soluções em Cloud Computing, gerenciamento de projetos, governança de TI e melhores práticas (ITIL, CobIT e ISO 20.000). Com vasta experiência em análise de processos, auditoria, gerenciamento de infraestrutura de TI e criação de plano diretor de TI, Eduardo é referência em reengenharia de Service Desk e palestras e treinamentos na área. Com uma abordagem colaborativa e inspiradora, Eduardo Souza lidera a Dominit, empresa de TI especializada em soluções inovadoras para empresas de todos os tamanhos. Sua visão estratégica e habilidade em transformar ideias em resultados fazem dele um dos mais respeitados CEOs de TI do mercado. Eduardo Souza é conhecido por sua capacidade de liderar equipes e extrair o melhor de cada membro, criando um ambiente de trabalho produtivo e inovador. Sua vasta experiência em tecnologia da informação e sua abordagem colaborativa fazem dele um líder nato, sempre em busca dos melhores resultados para sua empresa e seus clientes. Com sua visão de futuro e seu conhecimento técnico sólido, Eduardo Souza tem sido responsável por conduzir a Dominit em uma trajetória de sucesso, criando soluções inovadoras e eficientes para atender às necessidades de seus clientes.
Sobre nós

A Dominit Cloud and Management IT foi fundada no ano de 2009, pelo empresário Eduardo Souza com 15 anos de experiência em Serviços de infraestrutura e ex-sócio da empresa Megalan Consultoria.

Siga a nossa fanpage
Receba as nossas novidades em seu e-mail!

Se inscreva em nossa newsletter e receba as nossas matérias em primeira mão!