Como estimar a fatura do AWS Client VPN pelo console

No mês passado montei uma estimativa de Client VPN numa planilha, enviei a um cliente e depois a revisei duas vezes: uma porque multipliquei as associações pelas sub-redes, e outra porque usei o número de pessoas em vez dos dados de sessão. A versão que sobreviveu à revisão repousa em dois medidores por hora e numa lista curta de custos laterais. Você pode reconstruí-la pelo console e por uma exportação de log, sem calculadora de preços.

Dois medidores, e nada mais no endpoint

A AWS cobra um endpoint de Client VPN por horas de associação e horas de conexão. As horas de associação correm para cada rede de destino anexada ao endpoint, dia e noite, conecte-se alguém ou não. As horas de conexão correm por cliente conectado, enquanto aquela sessão permanecer ativa.

Dessa tabela saem duas consequências. Um endpoint sem ninguém nele custa dinheiro mesmo assim, e uma pessoa usando notebook e celular ao mesmo tempo gera duas conexões.

Conte associações no console, não sub-redes na VPC

Abra VPC, depois Client VPN endpoints, depois o seu endpoint, depois a aba Associations. Cada linha ali é uma anexação de sub-rede, e essa contagem de linhas é o seu multiplicador de associações. O número de sub-redes de aplicação atrás da VPC não tem nada a ver com isso.

Uma associação basta para alcançar uma rede VPC autorizada quando as rotas do endpoint e as regras de autorização cobrem o destino. Associações extras compram resiliência a falha de zona de disponibilidade, não alcance extra. Por isso um desenho com duas AZ dobra as horas de associação, enquanto uma VPC de aplicação com oito sub-redes não multiplica nada por oito.

Note o tipo de associação enquanto estiver nessa página. Uma associação de sub-rede VPC e uma associação direta de Transit Gateway são arranjos diferentes com linhas de cobrança diferentes, então não leve um modelo para a cotação do outro. E não teste a contagem desconectando coisas: remover a última rede de destino encerra sessões ativas e bloqueia conexões novas até algo ser associado de novo.

Derive as horas de conexão dos dados de sessão

O número de pessoas é a entrada errada, e é errada nas duas direções. Dez pessoas que mantêm três dispositivos conectados cada uma são trinta conexões. Cem pessoas que se conectam vinte minutos por dia não produzem nem de longe cem sessões simultâneas.

Os logs de conexão do Client VPN registram eventos de conexão e desconexão por cliente, que é exatamente o par que você precisa. Exporte uma semana representativa, combine os eventos e some as durações:

connection-hours = sum of (disconnect_time - connect_time) per session
sessions         = one per client connection, not per person

Depois corrija dois hábitos. Sessões deixadas conectadas durante o almoço, a noite ou uma suspensão de notebook que nunca derrubou o túnel continuam sendo cobradas, e são invisíveis numa contagem de pessoas. A medição também é por hora, então orçe uma sessão de vinte minutos como uma hora cheia em vez de supor cobrança proporcional; se a fatura vier menor, trate isso como margem e não como dado de planejamento.

Faça as contas com as tarifas da sua região

As tarifas variam por região, então pegue-as na página de preços do AWS VPN para a região onde você implanta e cole na planilha como entradas. Só como ilustração, use uma tarifa de associação de 0.10 dólar por hora e uma tarifa de hora de conexão de 0.05 dólar, e então precifique um mês de 30 dias com duas associações o mês inteiro e 100 pessoas conectadas seis horas em 20 dias úteis:

association-hours = 2 * 24 * 30     = 1,440
association fee   = 1,440 * 0.10    = 144.00

connection-hours  = 100 * 6 * 20    = 12,000
connection fee    = 12,000 * 0.05   = 600.00

Client VPN subtotal                 = 744.00

Agora mova uma entrada de cada vez e veja qual linha reage. Dobrar as associações acrescenta 144 dólares aqui; dobrar a duração média da sessão acrescenta 600. Essa proporção costuma resolver a discussão de projeto por você: corte a redundância que você não consegue justificar ou vá atrás das sessões ociosas, conforme o número maior. Escreva a região e a data das tarifas ao lado do resultado, porque uma cotação sem isso não pode ser reproduzida seis semanas depois.

Some os custos que o subtotal deixa de fora

A tarifa do endpoint paga o endpoint. Tudo o que o tráfego toca depois tem seu próprio medidor, e é nessas linhas que as estimativas otimistas de VPN desmoronam.

• Saída para a internet do tráfego que sai pelo endpoint, cobrada por GB.
• Endereços IPv4 públicos, que carregam a própria cobrança horária independente da VPN.
• Ingestão e armazenamento no CloudWatch Logs para os logs de conexão que você acabou de exportar.
• Invocações de Lambda se você opera um manipulador client-connect.
• Directory Service ou seu provedor de identidade SAML, se for assim que os usuários autenticam, mais as cobranças do ACM Private CA se você emite certificados ali.
• Horas de NAT Gateway e processamento de dados, e horas de anexação do Transit Gateway mais processamento de dados, sempre que o caminho os usa.

Nada disso escala com o número de associações, por isso um número por usuário montado só com tarifas de endpoint parece bom no papel e depois cresce quando aparece tráfego real. Coloque-os em linhas separadas mesmo quando você tiver de estimá-los, para que o leitor veja quais partes são medidas e quais são suposições.

Revise a planilha antes de enviar

Quatro verificações pegam os erros que eu realmente cometi: a contagem de associações bate exatamente com a aba Associations, as horas de conexão vieram de eventos de log emparelhados e não de uma contagem de pessoas, a região e a data das tarifas estão escritas, e cada custo lateral tem a sua própria linha. Se falta qualquer uma das quatro, você tem uma suposição com formatação.

Puxe primeiro a exportação do log. É a única entrada que você não consegue reconstruir de memória depois, e ela também diz se vale a pena corrigir o problema das sessões ociosas antes da primeira fatura.