Muitas pessoas com quem já conversei acreditam que o acesso remoto na AWS depende de uma única solução, como simplesmente habilitar uma VPN com acesso ao ambiente. Mas será que é só isso mesmo?
Sumário
Por que abrir VPN para tudo não é a melhor escolha?
Bem, se a pessoa só precisa abrir uma aplicação web privada, faz mais sentido liberar somente aquela aplicação. Se ela precisa administrar uma EC2 privada, também faz sentido liberar só o acesso administrativo naquela carga de trabalho, e assim por diante.
Agora, quando a necessidade é necessária para o administrador da rede ter acesso ao banco de dados, utilizar ferramentas internas para corrigir algo ou usar recursos on-premises conectados, a VPN se torna a melhor opção.
Quando usar AWS Verified Access?
Outro detalhe sobre o AWS Verified Access é que ele não concede acesso à rede, mas sim à aplicação. Por exemplo, se você tem um portal interno, um painel corporativo, ou uma aplicação web privada, esse serviço é a melhor escolha do que colocar todo mundo em uma VPN só para abrir uma URL.
Quando usar EC2 Instance Connect Endpoint?
Também gosto de mencionar que você pode restringir as regras de entrada da instância para permitir tráfego de gerenciamento apenas a partir do endpoint. Isso é bem melhor do que deixar SSH ou RDP aberto para a internet.
Quando usar AWS Client VPN?
Qual serviço usar em cada cenário?
| NECESSIDADE DO USUÁRIO | SERVIÇO INDICADO | MOTIVO |
|---|---|---|
| Abrir uma aplicação web privada | AWS Verified Access | Entrega acesso à aplicação sem exigir VPN e avalia cada requisição com base em política |
| Administrar uma instância EC2 privada | EC2 Instance Connect Endpoint | Permite acesso por IP privado, sem bastion host e sem expor gerenciamento à internet |
| Acessar banco de dados, APIs internas e vários recursos privados | AWS Client VPN | Entrega acesso de rede com rotas, associação de sub-redes e regras de autorização |
Quatro erros comuns para evitar
O primeiro erro é usar VPN para tudo. Isso pode até parecer prático no começo, mas costuma ampliar demais o alcance do usuário e aumentar a complexidade operacional.
O segundo erro é tratar AWS Verified Access como se fosse um substituto de VPN. Ele não é! Lembre-se que ele funciona muito bem para acesso à aplicação, mas não foi criado para entregar acesso à rede.
O quarto erro é esquecer que acesso seguro também depende do desenho da rede, das rotas e de autorização. No AWS Client VPN, por exemplo, não basta criar o endpoint. Você precisa associá-lo corretamente às sub-redes, criar as rotas necessárias e definir as regras de autorização adequadas.
Você quer ser um Arquiteto de Soluções AWS?
Se o seu objetivo é evoluir na carreira e entender como esses serviços se encaixam em arquiteturas reais, estudar cenários para ganhar experiência fará muita diferença. Por isso, não basta decorar o nome de serviço. É preciso entender quando usar, quando não usar e qual serviço foi feito para aquele cenário.
