Sådan anslår du en AWS Client VPN-regning fra konsollen

I sidste måned byggede jeg et Client VPN-estimat i et regneark, sendte det til en kunde og reviderede det derefter to gange: én gang fordi jeg gangede associationer med subnetter, og én gang fordi jeg brugte personetal i stedet for sessionsdata. Den version, der overlevede gennemgangen, hviler på to timemålere og en kort liste sideomkostninger. Du kan genopbygge den fra konsollen og én logeksport, uden en prisberegner.

To målere, og intet andet på endpointet

AWS fakturerer et Client VPN-endpoint på associations-timer og forbindelsestimer. Associations-timer tikker for hvert målnetværk, der er knyttet til endpointet, hele døgnet, uanset om nogen forbinder. Forbindelsestimer tikker per tilsluttet klient, så længe sessionen er oppe.

To konsekvenser følger direkte af tabellen. Et endpoint, hvor der ikke er nogen, koster stadig penge, og én person, der kører laptop og telefon samtidig, giver to forbindelser.

Tæl associationer i konsollen, ikke subnetter i VPC'en

Åbn VPC, derefter Client VPN endpoints, derefter dit endpoint, derefter fanen Associations. Hver række der er en subnet-tilknytning, og det rækkeantal er din associationsmultiplikator. Antallet af applikationssubnetter bag VPC'en har intet med det at gøre.

Én association er nok til at nå et autoriseret VPC-netværk, når endpointets ruter og autorisationsregler dækker destinationen. Ekstra associationer køber robusthed mod Availability Zone-nedbrud, ikke ekstra rækkevidde. Et design med to AZ'er fordobler derfor associations-timer, mens et applikations-VPC med otte subnetter ikke ganger noget med otte.

Læg mærke til associationstypen, mens du er på den side. En VPC-subnet-association og en direkte Transit Gateway-association er forskellige ordninger med forskellige linjer, så flyt ikke én model ind i den andens tilbud. Og test ikke antallet ved at afkoble ting: fjernelse af det sidste målnetværk afslutter aktive sessioner og blokerer nye forbindelser, indtil noget er associeret igen.

Udled forbindelsestimer af sessionsdata

Personetal er det forkerte input, og det er forkert i begge retninger. Ti personer, der hver holder tre enheder tilsluttet, er tredive forbindelser. Hundrede personer, der hver forbinder i tyve minutter om dagen, giver langt fra hundrede samtidige sessioner.

Client VPN-forbindelseslogge registrerer forbind- og afbryd-hændelser per klient, hvilket er præcis det par, du skal bruge. Eksporter en repræsentativ uge, par hændelserne og summer varighederne:

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

Ret derefter for to vaner. Sessioner, der bliver efterladt tilsluttet gennem frokosten, om natten eller gennem en laptop-suspendering, der aldrig rev tunnelen ned, faktureres stadig, og de er usynlige i et personetal. Målingen er også timebaseret, så budgetter en tyveminutters session som en hel time i stedet for at antage proportional fakturering; hvis regningen kommer lavere, skal du behandle det som margin og ikke som planlægningsinput.

Regn med din regions satser

Satserne varierer per Region, så hent dem fra AWS VPN-prissiden for den Region, du udruller til, og indsæt dem i arket som input. Kun som illustration: tag en associationssats på 0.10 dollar i timen og en forbindelsestimesats på 0.05 dollar, og prissæt så en måned på 30 dage med to associationer hele måneden og 100 personer, der forbinder seks timer på 20 arbejdsdage:

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

Flyt nu ét input ad gangen og se, hvilken linje der reagerer. Fordobling af associationerne tilføjer 144 dollar her; fordobling af den gennemsnitlige sessionslængde tilføjer 600. Det forhold afgør normalt designdiskussionen for dig: skær overflødighed væk, som du ikke kan begrunde, eller gå efter ledige sessioner, alt efter hvilket tal der er størst. Skriv Region og satsdato ved siden af resultatet, for et tilbud uden dem kan ikke genskabes seks uger senere.

Læg de omkostninger til, som subtotalen udelader

Endpointgebyret betaler for endpointet. Alt, hvad trafikken derefter rører, har sin egen måler, og det er på de linjer, optimistiske VPN-estimater falder fra hinanden.

• Internetudgang for trafik, der forlader gennem endpointet, faktureret per GB.
• Offentlige IPv4-adresser, som bærer deres egen timeafgift uafhængigt af VPN'en.
• CloudWatch Logs-indtag og -lagring til de forbindelseslogge, du netop har eksporteret.
• Lambda-kald, hvis du kører en client-connect-handler.
• Directory Service eller din SAML-identitetsudbyder, hvis det er sådan brugerne godkender, plus ACM Private CA-gebyrer, hvis du udsteder certifikater der.
• NAT Gateway-timer og databehandling og Transit Gateway-tilknytningstimer plus databehandling, når stien bruger dem.

Ingen af disse skalerer med associationsantallet, og derfor ser et tal per bruger, der kun er samlet af endpointgebyrer, fint ud på papiret og vokser så, når der kommer rigtig trafik. Sæt dem på separate linjer, selv når du må estimere dem, så læseren kan se, hvilke dele der er målt, og hvilke der er gætværk.

Kontroller arket, før du sender det

Fire kontroller fanger de fejl, jeg faktisk lavede: associationsantallet matcher fanen Associations præcist, forbindelsestimer kom fra parrede loghændelser i stedet for et personetal, Region og satsdato er skrevet ned, og hver sideomkostning har sin egen linje. Hvis én af de fire mangler, har du et gæt med formatering.

Træk logeksporten først. Det er det eneste input, du senere ikke kan rekonstruere fra hukommelsen, og det fortæller dig også, om problemet med ledige sessioner er værd at rette, før den første regning ankommer.