Como estimar unha factura de AWS Client VPN desde a consola

O mes pasado montei unha estimación de Client VPN nunha folla de cálculo, envieina a un cliente e logo reviseina dúas veces: unha porque multipliquei as asociacións polas subredes e outra porque empreguei o número de persoas en lugar dos datos de sesión. A versión que superou a revisión apóiase en dous medidores horarios e unha lista curta de cargos laterais. Podes reconstruíla desde a consola e unha exportación de rexistro, sen calculadora de prezos.

Dous medidores, e nada máis no endpoint

AWS factura un endpoint de Client VPN por horas de asociación e horas de conexión. As horas de asociación corren para cada rede de destino conectada ao endpoint, as vinte e catro horas, conéctese alguén ou non. As horas de conexión corren por cada cliente conectado, mentres esa sesión siga activa.

Desa táboa saen dúas consecuencias. Un endpoint sen ninguén enriba segue custando diñeiro, e unha persoa que ten un portátil e un teléfono á vez xera dúas conexións.

Conta asociacións na consola, non subredes na VPC

Abre VPC, logo Client VPN endpoints, logo o teu endpoint e logo a pestana Associations. Cada fila é unha conexión de subrede, e ese reconto de filas é o teu multiplicador de asociacións. O número de subredes de aplicación detrás da VPC non ten nada que ver.

Unha asociación abonda para chegar a unha rede VPC autorizada cando as rutas do endpoint e as regras de autorización cobren o destino. As asociacións extra compran resistencia de zona de dispoñibilidade, non máis alcance. Por iso un deseño de dúas AZ duplica as horas de asociación, mentres que unha VPC de aplicación con oito subredes non multiplica nada por oito.

Fíxate no tipo de asociación mentres estás nesa páxina. Unha asociación de subrede VPC e unha asociación directa de Transit Gateway son disposicións distintas con partidas distintas, así que non leves un modelo á cotización do outro. E non probas o reconto desconectando cousas: quitar a última rede de destino remata as sesións activas e bloquea conexións novas ata que algo volva estar asociado.

Deriva as horas de conexión dos datos de sesión

O número de persoas é a entrada equivocada, e éo en ambos os sentidos. Dez persoas que manteñen tres dispositivos conectados cada unha son trinta conexións. Cen persoas que se conectan vinte minutos ao día non producen nin de lonxe cen sesións simultáneas.

Os rexistros de conexión de Client VPN anotan eventos de conexión e desconexión por cliente, que é exactamente o emparellamento que necesitas. Exporta unha semana representativa, emparella os eventos e suma as duracións:

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

Logo corrixe dous hábitos. As sesións que quedan conectadas durante a comida, a noite ou unha suspensión do portátil que nunca cortou o túnel séguense facturando, e son invisibles nun reconto de persoas. A medición tamén é por horas, así que orzamenta unha sesión de vinte minutos como unha hora completa en lugar de asumir facturación proporcional; se a factura chega máis baixa, trátao como marxe e non como dato de planificación.

Fai os cálculos coas tarifas da túa rexión

As tarifas varían por rexión, así que tomaas da páxina de prezos de AWS VPN para a rexión onde despregas e pégaas na folla como entradas. Só como ilustración, toma unha tarifa de asociación de 0.10 dólares por hora e unha tarifa de hora de conexión de 0.05 dólares, e logo valora un mes de 30 días con dúas asociacións todo o mes e 100 persoas conectadas seis horas en 20 días laborables:

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 move unha entrada cada vez e observa que liña reacciona. Duplicar as asociacións engade aquí 144 dólares; duplicar a duración media de sesión engade 600. Esa proporción adoita resolver a discusión de deseño por ti: recorta a redundancia que non podes xustificar ou vai ás sesións inactivas, segundo que número sexa maior. Escribe a rexión e a data das tarifas xunto ao resultado, porque unha cotización sen elas non se pode reproducir seis semanas despois.

Engade os cargos que o subtotal deixa fóra

A tarifa do endpoint paga o endpoint. Todo o que o tráfico toca despois ten o seu propio medidor, e é nesas liñas onde se derruban as estimacións optimistas de VPN.

• Saída a internet do tráfico que sae polo endpoint, facturada por GB.
• Enderezos IPv4 públicos, que levan o seu propio cargo horario independente da VPN.
• Inxestión e almacenamento de CloudWatch Logs para os rexistros de conexión que acabas de exportar.
• Invocacións de Lambda se executas un manexador client-connect.
• Directory Service ou o teu provedor de identidade SAML, se así se autentican os usuarios, máis os cargos de ACM Private CA se emites certificados alí.
• Horas de NAT Gateway e procesamento de datos, e horas de adhesión de Transit Gateway máis procesamento de datos, sempre que a ruta os use.

Nada disto escala co número de asociacións, por iso unha cifra por usuario montada só con tarifas de endpoint parece ben en papel e logo medra cando aparece tráfico real. Ponas en filas separadas mesmo cando teñas que estimelas, para que o lector vexa que partes están medidas e cales son conxecturas.

Revisa a folla antes de enviarlas

Catro comprobacións atrapan os erros que realmente cometeu: o reconto de asociacións coincide exacto coa pestana Associations, as horas de conexión veñen de eventos de rexistro emparellados e non dun reconto de persoas, a rexión e a data das tarifas están escritas, e cada cargo lateral ten a súa propia fila. Se falta algunha das catro, tes unha conxectura con formato.

Saca primeiro a exportación do rexistro. É a única entrada que despois non podes reconstruír de memoria, e tamén che di se paga a pena arranxar o problema das sesións inactivas antes de que chegue a primeira factura.