Så här uppskattar du en AWS Client VPN-faktura från konsolen

Förra månaden byggde jag en Client VPN-uppskattning i ett kalkylblad, skickade den till en kund och reviderade den sedan två gånger: en gång för att jag multiplicerade associeringar med subnät, och en gång för att jag använde antal personer i stället för sessionsdata. Versionen som överlevde granskningen vilar på två timmätare och en kort lista med sidokostnader. Du kan bygga om den från konsolen och en loggexport, utan en priskalkylator.

Två mätare, och inget annat på endpointen

AWS fakturerar en Client VPN-endpoint på associeringstimmar och anslutningstimmar. Associeringstimmarna tickar för varje målnätverk som är kopplat till endpointen, dygnet runt, oavsett om någon ansluter. Anslutningstimmarna tickar per ansluten klient, så länge den sessionen håller sig uppe.

Två konsekvenser följer direkt av tabellen. En endpoint utan någon på sig kostar fortfarande pengar, och en person som kör laptop och telefon samtidigt ger två anslutningar.

Räkna associeringar i konsolen, inte subnät i VPC:n

Öppna VPC, sedan Client VPN endpoints, sedan din endpoint, sedan fliken Associations. Varje rad där är en subnätskoppling, och det radantalet är din associeringsmultiplikator. Antalet applikationssubnät bakom VPC:n har inget med det att göra.

En associering räcker för att nå ett auktoriserat VPC-nätverk när endpointens rutter och auktoriseringsregler täcker destinationen. Extra associeringar köper motståndskraft mot fel i en tillgänglighetszon, inte extra räckvidd. En design med två AZ fördubblar därför associeringstimmarna, medan en applikations-VPC med åtta subnät inte multiplicerar något med åtta.

Notera associeringstypen medan du är på den sidan. En VPC-subnätsassociering och en direkt Transit Gateway-associering är olika upplägg med olika fakturarader, så flytta inte en modell in i den andras offert. Och testa inte antalet genom att koppla loss saker: att ta bort det sista målnätverket avslutar aktiva sessioner och blockerar nya anslutningar tills något är associerat igen.

Härled anslutningstimmar från sessionsdata

Antal personer är fel indata, och det är fel i båda riktningarna. Tio personer som var och en håller tre enheter anslutna är trettio anslutningar. Hundra personer som var och en ansluter i tjugo minuter om dagen ger långt ifrån hundra samtidiga sessioner.

Client VPN:s anslutningsloggar registrerar anslutnings- och frånkopplingshändelser per klient, vilket är precis det par du behöver. Exportera en representativ vecka, matcha händelserna och summera varaktigheterna:

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

Rätta sedan för två vanor. Sessioner som lämnas anslutna över lunchen, natten eller en laptopsuspendering som aldrig rev tunneln faktureras fortfarande, och de är osynliga i ett personantal. Mätningen är också timbaserad, så budgetera en tjugominuterssession som en hel timme i stället för att anta proportionell fakturering; om fakturan blir lägre, behandla det som marginal och inte som planeringsindata.

Gör räkningen med din regions priser

Priserna varierar per region, så hämta dem från AWS VPN-prissidan för den region du distribuerar till och klistra in dem i arket som indata. Endast som illustration: ta en associeringsavgift på 0.10 dollar i timmen och en anslutningstimavgift på 0.05 dollar, och prissätt sedan en månad på 30 dagar med två associeringar hela månaden och 100 personer som ansluter sex timmar under 20 arbetsdagar:

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

Flytta nu en indata i taget och se vilken rad som reagerar. Att fördubbla associeringarna lägger till 144 dollar här; att fördubbla den genomsnittliga sessionslängden lägger till 600. Det förhållandet avgör oftast designargumentet åt dig: skär bort överflödighet du inte kan motivera, eller gå efter lediga sessioner, beroende på vilket tal som är störst. Skriv regionen och prisdatumet bredvid resultatet, för en offert utan dem kan inte återskapas sex veckor senare.

Lägg till kostnaderna som delsumman utelämnar

Endpointavgiften betalar endpointen. Allt trafiken rör vid efteråt har sin egen mätare, och det är på de raderna optimistiska VPN-uppskattningar faller sönder.

• Internetutgång för trafik som lämnar via endpointen, fakturerad per GB.
• Publika IPv4-adresser, som bär sin egen timavgift oberoende av VPN:en.
• CloudWatch Logs-intag och -lagring för anslutningsloggarna du just exporterade.
• Lambda-anrop om du kör en client-connect-hanterare.
• Directory Service eller din SAML-identitetsleverantör, om det är så användarna autentiserar, plus ACM Private CA-avgifter om du utfärdar certifikat där.
• NAT Gateway-timmar och databehandling, och Transit Gateway-kopplingstimmar plus databehandling, när vägen använder dem.

Inget av detta skalar med associeringsantalet, och därför ser en siffra per användare som bara är sammansatt av endpointavgifter bra ut på papperet och växer sedan när verklig trafik dyker upp. Sätt dem på egna rader även när du måste uppskatta dem, så att läsaren ser vilka delar som är mätta och vilka som är gissningar.

Kontrollera arket innan du skickar det

Fyra kontroller fångar felen jag faktiskt gjorde: associeringsantalet stämmer exakt med fliken Associations, anslutningstimmarna kom från parade logghändelser och inte från ett personantal, regionen och prisdatumet är nedskrivna, och varje sidokostnad har sin egen rad. Om någon av de fyra saknas har du en gissning med formatering.

Dra loggexporten först. Det är den enda indata du senare inte kan rekonstruera ur minnet, och den berättar också om problemet med lediga sessioner är värt att åtgärda innan den första fakturan kommer.