AWS Verified Access vs Client VPN: O Guia de 2026 para Design ZTNA

O Client VPN tradicional é uma dívida arquitetônica legada pela qual a maioria das empresas ainda paga juros em 2026. Embora o AWS Client VPN continue sendo uma ferramenta funcional para acesso administrativo básico, a mudança para Zero Trust Network Access (ZTNA) via AWS Verified Access (AVA) representa o único caminho viável para uma postura de segurança moderna. A escolha não é apenas sobre protocolos; é sobre passar de um modelo "conectar-então-autenticar" para um modelo de "verificação contínua" onde o perímetro da rede deixa de existir.

A Divergência Arquitetural: Baseado em Túnel vs. Baseado em Proxy

Para entender por que o AWS Verified Access (AVA) é superior para entrega de aplicações, devemos analisar a diferença no fluxo de pacotes. O AWS Client VPN é uma implementação do OpenVPN. Ele cria uma Virtual Network Interface (VIF) na máquina cliente, atribui um IP de um bloco CIDR e insere rotas na tabela de roteamento local. Uma vez que o túnel está ativo, o usuário está "na rede". Mesmo com Security Groups, a superfície de movimento lateral é enorme.

O AWS Verified Access opera como um reverse proxy gerenciado. Ele usa a linguagem de política Cedar para avaliar cada solicitação em relação aos dados de confiança. Não há túnel. Não há IP do cliente atribuído à máquina do usuário. O usuário interage com um endpoint público, o AVA avalia a identidade e a postura do dispositivo e, se permitido, faz o proxy da solicitação para o Load Balancer interno (ALB) ou ENI. Isso elimina todo o conceito de acesso em "nível de rede", movendo o ponto de imposição para a Camada 7.

Integração com Provedores de Confiança: Identidade e Postura do Dispositivo

O verdadeiro poder do AVA reside em sua capacidade de consumir "Trust Providers". Em uma configuração padrão de Client VPN, você normalmente depende do SAML 2.0 para um evento de autenticação única. Uma vez que a sessão é estabelecida, é isso. O AVA suporta avaliação contínua integrando-se a Identity Providers (IdP) e sistemas de Gerenciamento de Dispositivos (EDR/UEM).

• Identity Providers: Integração nativa com AWS IAM Identity Center (anteriormente SSO) ou qualquer provedor compatível com OIDC como Okta ou Azure AD.
• Device Trust Providers: Integração com CrowdStrike, Jamf ou Tanium. Isso permite que você escreva políticas que dizem: "Permitir acesso ao CIDR de Produção apenas se o usuário estiver no grupo 'DevOps' E o nível de segurança do CrowdStrike for 'High'."

// Exemplo de Política Cedar para AVA
permit(
    principal,
    action == "http-request",
    resource
)
when {
    context.identity.groups.contains("Engineers") &&
    context.device.assessment.overall_health_score == "STABLE" &&
    context.device.assessment.jamf.compliance_status == "COMPLIANT"
};

Comparando o AWS Client VPN: O Caso de Uso para Legado

Apesar da superioridade do ZTNA, o AWS Client VPN não está morto. Ele continua sendo o mal necessário para protocolos que não se dão bem com proxies de Camada 7. Se seus engenheiros precisam usar aplicações de thick-client que exigem streams TCP/UDP brutos em portas não padrão (pense em gerenciamento legado de SQL Server, chamadas RPC customizadas ou SSH/RDP direto sem um jump box), o AVA é uma adaptação difícil porque é otimizado principalmente para tráfego HTTP/HTTPS.

Além disso, o Client VPN permite configurações de "Full Tunnel", que algumas indústrias altamente regulamentadas usam para forçar todo o tráfego de internet através de um ponto de inspeção centralizado (como um Transit Gateway com AWS Network Firewall). O AVA não pode fazer isso; é inerentemente uma solução de acesso a aplicações "Split-Tunnel".

Análise de Custos: O Imposto Oculto do ZTNA

Vamos falar sobre a realidade de hardware e licenciamento. O preço do AWS Client VPN é previsível: US$ 0,05 por associação de endpoint por hora + US$ 0,05 por conexão de cliente ativa por hora. Para 100 usuários ativos 8 horas por dia, você está olhando para aproximadamente US$ 400-US$ 600/mês, mais transferência de dados. É barato, mas é um "cano burro".

O preço do AWS Verified Access é mais complexo e significativamente mais alto em escala. Ele cobra por aplicação (US$ 0,20 por aplicação por hora) e por GB processado (US$ 0,02/GB). Se você tem 50 microserviços internos que deseja expor via AVA, o custo "por aplicação" sozinho é de US$ 7.200/mês. É aqui que a arquitetura exige consolidação. Engenheiros inteligentes usam uma abordagem "Wildcard" ou agregam aplicações atrás de um ponto de entrada central para gerenciar custos, mas mesmo assim, o AVA é posicionado como um produto de segurança premium.

AVA vs. Palo Alto Prisma Access: A Batalha Empresarial

Para organizações que já usam Palo Alto Firewalls, a pergunta é frequentemente: Por que usar AVA quando temos o Prisma Access? Isso se resume à visão de "Global Secure Access". O Prisma Access fornece um framework ZTNA 2.0 mais maduro que lida com todas as portas e protocolos, não apenas o tráfego web. Ele também inclui DLP integrado e prevenção avançada de ameaças que o AVA não possui nativamente.

No entanto, o AVA ganha na integração nativa com a AWS. Se toda a sua stack está em us-east-1 e eu-west-1, o AVA aproveita o backbone da AWS e o ecossistema IAM sem a sobrecarga de gerenciar agentes GlobalProtect ou túneis GRE/IPsec para uma cloud SASE de terceiros. Se você é uma casa Palo Alto, fique com o Prisma para o motor de políticas unificado. Se você é cloud-native e está se afastando de agentes globais, o AVA é a escolha mais enxuta.

Estratégia de Implantação: Migrando para ZTNA em 2026

Não tente fazer um "lift-and-shift" de toda a sua VPN para o AVA em um fim de semana. A melhor prática de 2026 é uma abordagem híbrida. Use o Client VPN para seu acesso administrativo "Backstage" (os 5% dos usuários que precisam de acesso bruto à VPC) e mova 95% de sua equipe geral para o AVA para ferramentas baseadas na web (Jira, Portais Internos, Aplicações de RH).

Passo 1: A "Cola" OIDC

Configure o AWS IAM Identity Center. Este é o pré-requisito. Não tente gerenciar usuários locais para o AVA. Sincronize suas identidades do Google Workspace ou Azure AD. Isso garante que, quando um usuário é desativado do seu IdP, seu acesso a todas as aplicações protegidas pelo AVA seja revogado em tempo real.

Passo 2: A Instância Verified Access

Crie uma Verified Access Instance. Este é um recurso global que mantém seus provedores de confiança e grupos. Associe-o às suas VPCs de destino via Verified Access Endpoints. Esses endpoints podem ser baseados em Load Balancer ou em Network Interface.

Passo 3: Definindo as Políticas Cedar

Comece com "Permitir Tudo" dentro do grupo e refine. Use os campos context.device para impor que apenas laptops gerenciados pela empresa possam se conectar. Esta única ação elimina a ameaça de "PCs domésticos" não gerenciados introduzindo malware no ambiente.

O Veredito: AVA é o Futuro, Client VPN é a Muleta

O AWS Client VPN é uma ferramenta legada para uma mentalidade legada. Ele trata a segurança como um estado binário – você está "dentro" ou "fora". Em 2026, isso é uma receita para uma violação catastrófica. O AWS Verified Access, apesar de seu custo mais alto e complexidade de configuração, fornece os controles granulares, cientes da identidade e do dispositivo que os frameworks de conformidade modernos (como SOC2 ou FedRAMP High) exigem. Se seu tráfego é principalmente baseado na web, pare de construir túneis. Use um proxy.

Para aqueles que lutam com a transição de modelos de alcançabilidade de VPC para proxies cientes da identidade, nossa equipe em techleague.io fornece a expertise em engenharia prática para refatorar seu perímetro na AWS. Entre em contato para agendar uma revisão arquitetônica aprofundada de seus padrões de ingresso atuais.