Hoe u een AWS Client VPN-factuur vanaf de console schat

Vorige maand bouwde ik een Client VPN-schatting in een spreadsheet, stuurde die naar een klant en herzag hem daarna twee keer: één keer omdat ik associaties met subnetten had vermenigvuldigd, en één keer omdat ik het aantal mensen gebruikte in plaats van sessiegegevens. De versie die de beoordeling overleefde, rust op twee uurmeters en een korte lijst nevenkosten. U kunt hem opnieuw opbouwen uit de console en één logexport, zonder prijscalculator.

Twee meters, en niets anders op het endpoint

AWS factureert een Client VPN-endpoint op associatie-uren en verbindingsuren. Associatie-uren lopen voor elk doelnetwerk dat aan het endpoint is gekoppeld, dag en nacht, of er nu iemand verbindt of niet. Verbindingsuren lopen per verbonden client, zolang die sessie blijft staan.

Uit die tabel volgen twee gevolgen. Een endpoint waar niemand op zit kost nog steeds geld, en één persoon die tegelijk een laptop en een telefoon gebruikt, levert twee verbindingen op.

Tel associaties in de console, niet subnetten in de VPC

Open VPC, dan Client VPN endpoints, dan uw endpoint, dan het tabblad Associations. Elke rij daar is een subnetkoppeling, en dat rijaantal is uw associatiemultiplicator. Het aantal applicatiesubnetten achter de VPC heeft er niets mee te maken.

Eén associatie is genoeg om een geautoriseerd VPC-netwerk te bereiken zodra de routes van het endpoint en de autorisatieregels de bestemming dekken. Extra associaties kopen weerbaarheid tegen uitval van een availability zone, geen extra bereik. Een ontwerp met twee AZ's verdubbelt dus de associatie-uren, terwijl een applicatie-VPC met acht subnetten niets met acht vermenigvuldigt.

Let op het type associatie terwijl u op die pagina bent. Een VPC-subnetassociatie en een directe Transit Gateway-associatie zijn verschillende opzetten met verschillende factuurregels, dus neem niet het ene model mee in de offerte van het andere. En test het aantal niet door dingen los te koppelen: het laatste doelnetwerk verwijderen beëindigt actieve sessies en blokkeert nieuwe verbindingen tot er weer iets is geassocieerd.

Leid verbindingsuren af uit sessiegegevens

Aantal mensen is de verkeerde invoer, en het is in beide richtingen verkeerd. Tien mensen die elk drie apparaten verbonden houden, zijn dertig verbindingen. Honderd mensen die elk twintig minuten per dag verbinden, leveren lang geen honderd gelijktijdige sessies.

Client VPN-verbindingslogs registreren verbind- en verbreekgebeurtenissen per client, precies het paar dat u nodig hebt. Exporteer een representatieve week, koppel de gebeurtenissen en sommeer de duur:

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

Corrigeer daarna twee gewoonten. Sessies die verbonden blijven tijdens de lunch, de nacht of een laptopslaapstand die de tunnel nooit afbrak, worden nog steeds gefactureerd, en ze zijn onzichtbaar in een personenaantal. De meting is ook per uur, dus begroot een sessie van twintig minuten als een vol uur in plaats van proportionele facturering aan te nemen; komt de factuur lager uit, behandel dat als marge en niet als planningsinvoer.

Reken met de tarieven van uw regio

Tarieven verschillen per regio, dus haal ze van de AWS VPN-prijspagina voor de regio waarin u uitrolt en plak ze als invoer in het werkblad. Alleen als illustratie: neem een associatietarief van 0.10 dollar per uur en een verbindingsuurtarief van 0.05 dollar, en prijs dan een maand van 30 dagen met twee associaties de hele maand en 100 mensen die zes uur verbinden op 20 werkdagen:

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

Verschuif nu één invoer tegelijk en kijk welke regel reageert. De associaties verdubbelen voegt hier 144 dollar toe; de gemiddelde sessieduur verdubbelen voegt 600 toe. Die verhouding beslecht meestal de ontwerpdiscussie voor u: snijd overbodigheid weg die u niet kunt verantwoorden, of jaag op lege sessies, afhankelijk van welk getal groter is. Schrijf de regio en de tariefdatum naast het resultaat, want een offerte zonder die twee is zes weken later niet te reproduceren.

Voeg de kosten toe die het subtotaal weglaat

De endpointvergoeding betaalt het endpoint. Alles wat het verkeer daarna aanraakt heeft zijn eigen meter, en op die regels vallen optimistische VPN-schattingen uiteen.

• Internettoegang voor verkeer dat via het endpoint naar buiten gaat, per GB gefactureerd.
• Openbare IPv4-adressen, die hun eigen uurtarief dragen, onafhankelijk van de VPN.
• CloudWatch Logs-opname en -opslag voor de verbindingslogs die u zojuist hebt geëxporteerd.
• Lambda-aanroepen als u een client-connect-handler draait.
• Directory Service of uw SAML-identiteitsprovider, als gebruikers zo authenticeren, plus ACM Private CA-kosten als u daar certificaten uitgeeft.
• NAT Gateway-uren en gegevensverwerking, en Transit Gateway-koppeluren plus gegevensverwerking, telkens wanneer het pad die gebruikt.

Niets hiervan schaalt mee met het aantal associaties, daarom ziet een getal per gebruiker dat alleen uit endpointvergoedingen bestaat er op papier goed uit en groeit het zodra er echt verkeer verschijnt. Zet ze op aparte regels ook wanneer u ze moet schatten, zodat de lezer ziet welke delen gemeten zijn en welke gissingen.

Controleer het werkblad voordat u het verstuurt

Vier controles vangen de fouten die ik werkelijk maakte: het aantal associaties komt exact overeen met het tabblad Associations, de verbindingsuren komen uit gepaarde loggebeurtenissen en niet uit een personenaantal, de regio en de tariefdatum staan erin, en elke nevenkost heeft zijn eigen regel. Ontbreekt een van de vier, dan hebt u een gissing met opmaak.

Haal eerst de logexport op. Het is de enige invoer die u later niet uit het geheugen kunt reconstrueren, en het vertelt u ook of het probleem met lege sessies het waard is om te verhelpen voordat de eerste factuur komt.