Para a maioria das empresas, VPN resolve a conexão com a cloud de forma segura e econômica. Mas quando o volume de tráfego é alto, a latência é crítica ou o SLA de negócio não tolera a variabilidade da internet pública, acesso direto dedicado passa a fazer mais sentido.
VPN: o que cobre e o que não cobre
Antes de entrar no comparativo, vale definir com precisão do que estamos falando — porque “VPN” cobre dois cenários bastante diferentes.
VPN site-to-site conecta sua rede local (escritório ou datacenter on-premise) à rede do seu ambiente cloud. É um túnel permanente e criptografado que faz com que as duas redes se comportem como se fossem uma só. Servidores no seu escritório enxergam servidores no cloud como vizinhos de rede. A conexão é estabelecida entre roteadores ou firewalls, não entre usuários individuais.
VPN de acesso remoto é o que os colaboradores usam para acessar a rede corporativa de fora — de casa, do hotel, do aeroporto. O usuário instala um cliente VPN no computador, autentica e recebe um endereço IP da rede corporativa, passando a ter acesso aos recursos como se estivesse no escritório.
Os desafios são diferentes para cada cenário. Para acesso remoto de usuários, VPN tradicional tem limitações de escala, experiência e segurança que ZTNA resolve melhor. Para conectar site a site, a questão é desempenho e confiabilidade — e aí entra a comparação com acesso direto dedicado.
Quando VPN site-to-site é suficiente
Na prática, VPN site-to-site sobre internet funciona bem para a maioria das empresas em cenários onde:
O volume de tráfego entre o site local e o cloud é moderado — transferências de arquivos, acesso a aplicações internas, sincronização de dados não urgentes. A latência variável da internet não impacta criticamente a experiência do usuário ou a operação dos sistemas. O SLA do negócio tolera alguma variabilidade — uma queda de alguns minutos por mês é aceitável. O custo importa e o investimento em link dedicado não se justifica pelo volume de uso.
VPN IPSec com criptografia AES-256 e autenticação forte é suficiente do ponto de vista de segurança para a maioria dos workloads. O risco principal não é de intercepção do dado criptografado — é a disponibilidade e performance dependendo do estado da internet entre os dois pontos.
Quando acesso direto dedicado faz sentido
Pense numa empresa de logística com operação 24h que processa pedidos em tempo real via aplicação rodando em cloud privada. O sistema de ERP e WMS estão no datacenter cloud; a operação de separação, faturamento e emissão de NF-e acontece em tempo real em duas filiais. Qualquer lentidão na rede vira perda de SLA com clientes e risco de parar a linha de separação.
Nesse cenário, depender de internet pública para o link entre as filiais e o datacenter cloud cria um risco que o negócio não tolera. Um link dedicado (Direct Connect, no contexto AWS; ExpressRoute no Azure; ou link privado no caso de cloud privada como Adentro) elimina a variabilidade da internet pública do caminho.
O acesso direto se justifica quando você tem um ou mais destes fatores:
Latência crítica: aplicações com requisito de latência abaixo de 5-10ms que VPN sobre internet não garante de forma consistente.
Volume alto e constante: transferências de terabytes por semana entre on-premise e cloud. Além da performance, há economia: link dedicado geralmente tem custo de egress menor do que transferência via internet em provedores de cloud.
SLA contratual de rede: quando você precisa garantir em contrato ao seu cliente um nível de disponibilidade de sistema que requer que o link de rede também tenha SLA. Internet pública não tem SLA.
Conformidade regulatória: alguns setores exigem que dados em trânsito entre ambientes nunca passem por internet pública — mesmo criptografados.
Os riscos de depender só de internet pública
Empresas que conectam toda a operação ao cloud via internet pública sem contingência estão expostas a alguns riscos específicos:
Variabilidade de rota BGP: o caminho que seus pacotes tomam na internet muda dinamicamente. Um dia está ótimo, outro dia passa por um ponto de congestionamento no meio do caminho e a latência triplica — sem que nada na sua rede tenha mudado.
Ponto único de falha no ISP local: se o único link de internet da sua empresa cair, toda a conectividade com o cloud cai junto. Para operações críticas, dois provedores de internet diferentes (ou internet + link dedicado) são o mínimo.
Qualidade de upload: a maioria dos links de internet corporativos tem download maior que upload. Workloads que movem muitos dados do on-premise para cloud (backup, replicação, migração) sentem essa assimetria.
VPN vs ZTNA: para acesso remoto de usuários
Para conectividade de usuários remotos, VPN tradicional está sendo substituída gradualmente por ZTNA (Zero Trust Network Access). A diferença conceitual é importante:
VPN tradicional dá ao usuário autenticado acesso à rede — um endereço IP interno que, na prática, alcança muitos recursos além do necessário. Se aquela conta for comprometida, o atacante tem acesso de rede amplo.
ZTNA parte do princípio de não confiar em ninguém por padrão. Cada acesso a cada aplicação específica precisa ser autorizado individualmente, com base em identidade do usuário, postura do dispositivo e contexto (horário, localização). O usuário nunca recebe acesso de rede genérico — só acesso às aplicações que precisa, verificado a cada sessão.
| Critério | VPN Tradicional | Acesso Direto Dedicado | ZTNA |
|---|---|---|---|
| Caso de uso principal | Site-to-site e acesso remoto | Conectividade site-to-datacenter | Acesso remoto de usuários |
| Custo | Baixo | Alto | Médio |
| Performance | Variável (depende da internet) | Consistente (link dedicado) | Variável (depende da internet) |
| Segurança | Boa com MFA | Boa (rede privada) | Excelente (verificação contínua) |
| Escalabilidade | Limitada | Alta | Alta |
| Complexidade | Baixa | Média a alta | Média |
Quer entender qual modelo de conectividade faz sentido para o seu ambiente? Fale com a equipe técnica da Adentro para uma avaliação.