AWS Client VPN ou uma VPN no EC2: um manual operacional

As duas opções dão à sua equipe uma VPN de acesso remoto, então a pergunta interessante não é qual existe, mas qual você consegue operar. A diferença é quem é dono do endpoint às 3 da manhã e a quais controles você chega quando algo quebra. Siga os cinco passos abaixo em ordem, porque cada um pode encerrar a comparação mais cedo. Pular a etapa do inventário é justamente como as equipes acabam migrando duas vezes.

Passo 1: escreva o requisito antes da fatura

Você precisa de cinco fatos em uma página: quem se autentica e contra o quê, quais plataformas de cliente precisam funcionar, quais destinos privados são alcançáveis, qual disponibilidade você prometeu e como o tráfego realmente é. Sem isso, toda comparação posterior vira discussão sobre uma lista de recursos.

Seja concreto sobre os destinos. «Acesso à VPC» normalmente significa três coisas diferentes: o CIDR da VPC, uma rede emparelhada e um intervalo local atrás de um Transit Gateway. Um endpoint gerenciado alcança os três, mas cada um exige uma rota e uma regra de autorização, e cada um é uma linha separada no seu requisito.

Passo 2: enumere o que já roda

Antes de projetar qualquer coisa, liste os endpoints existentes e qualquer servidor hospedado no EC2 junto com seus grupos de segurança. Essas chamadas são somente leitura e seguras a partir de uma conta com permissões describe.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

Leia a saída como um mapa do que os clientes já alcançam. Uma regra de autorização ausente explica uma falha que parece problema de roteamento, e um endpoint associado a uma única sub-rede explica por que uma falha de zona derrubou o serviço inteiro.

Anote também os grupos de segurança ligados a qualquer instância auto-hospedada. Essas regras fazem parte do modelo de acesso, e são a primeira coisa que quebra em silêncio quando alguém reconstrói uma instância a partir de um modelo.

Passo 3: divida as responsabilidades

O serviço gerenciado é dono da frota de endpoints, do seu patching e da sua disponibilidade dentro da região. Você é dono do cadastro de identidades, das regras de autorização, dos caminhos de rede atrás do endpoint, da configuração de logs e da decisão de quantas sub-redes associar.

A auto-hospedagem inverte isso. Você é dono do sistema operacional convidado, do daemon VPN e da sua configuração, dos certificados e chaves, dos backups, do monitoramento e da recuperação. O modelo de segurança do EC2 coloca a segurança do convidado e da aplicação no cliente, e um servidor VPN é um convidado como qualquer outro.

Escreva a divisão como uma tabela com nomes na coluna da direita. Se nenhum nome aparecer ao lado da renovação de certificados, esse é o achado, e ele pesa mais do que a diferença por hora.

Passo 4: compare com uma carga de trabalho que você saiba descrever

O custo segue a forma, não o tamanho. Para a opção gerenciada, conte as horas de associação de endpoints, as horas de conexão de clientes, a transferência e os serviços de identidade e logs que você ativa. Para a auto-hospedagem, conte computação, armazenamento, rede, licenças e o tempo de engenharia que mantém o servidor corrigido. Coloque os dois conjuntos de números numa mesma planilha com o mesmo horizonte de tempo. Uma comparação de três anos que ignora horas de patching sempre vai favorecer o servidor que você já tem.

Comparações de desempenho exigem a mesma disciplina. Uma sessão interativa de desktop, uma transferência grande e cinquenta solicitações pequenas simultâneas pressionam partes diferentes do caminho: a CPU para criptografia, a capacidade de rede da instância, a pilha do próprio cliente e o destino. Teste com clientes representativos e a mesma tarefa nos dois desenhos.

Uma instância maior não é prova de que a transferência será mais rápida, e uma sessão bem-sucedida não é um plano de capacidade. Trate qualquer folclore herdado sobre famílias de instâncias como hipótese a testar, não como regra de compra.

Passo 5: mude com uma reversão que você já executou

Rode os dois endpoints em paralelo por um período definido, distribua o novo perfil de cliente primeiro a um grupo pequeno e não toque nas regras de autorização do endpoint antigo até o grupo ter usado o novo em trabalho real. A reversão é uma troca de perfil, não uma reconstrução, então decida agora onde vive o perfil antigo.

Verifique nesta ordem: a autenticação funciona, o cliente recebe as rotas esperadas, um destino autorizado responde e um destino não autorizado falha, e os logs mostram os dois eventos. Se qualquer passo falhar, pare e corrija esse passo em vez de passar ao próximo grupo de clientes. Anote o resultado de cada verificação, porque uma mudança lembrada apenas como «funcionou» não pode ser depurada um mês depois.

Depois da mudança, agende as verificações entediantes: vencimento dos certificados, número de associações, regras de autorização que não correspondem mais a um grupo e o número de conexões contra a sua expectativa. O guia de administração do Client VPN é a referência para as partes de endpoint, autenticação e roteamento que você configurou.