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

Forrige måned bygde jeg et Client VPN-estimat i et regneark, sendte det til en kunde og reviderte det deretter to ganger: én gang fordi jeg ganget assosiasjoner med subnett, og én gang fordi jeg brukte antall personer i stedet for sesjonsdata. Versjonen som overlevde gjennomgangen, hviler på to timemålere og en kort liste med sidekostnader. Du kan bygge den på nytt fra konsollen og én loggeksport, uten en priskalkulator.

To målere, og ingenting annet på endepunktet

AWS fakturerer et Client VPN-endepunkt på assosiasjonstimer og tilkoblingstimer. Assosiasjonstimene tikker for hvert målnettverk som er knyttet til endepunktet, døgnet rundt, uansett om noen kobler til. Tilkoblingstimene tikker per tilkoblet klient, så lenge den sesjonen holder seg oppe.

To konsekvenser følger rett ut av den tabellen. Et endepunkt uten noen på seg koster fortsatt penger, og én person som kjører laptop og telefon samtidig, gir to tilkoblinger.

Tell assosiasjoner i konsollen, ikke subnett i VPC-en

Åpne VPC, deretter Client VPN endpoints, deretter ditt endepunkt, deretter fanen Associations. Hver rad der er en subnett-tilknytning, og det radantallet er assosiasjonsmultiplikatoren din. Antall applikasjonssubnett bak VPC-en har ingenting med det å gjøre.

Én assosiasjon er nok til å nå et autorisert VPC-nettverk når endepunktets ruter og autorisasjonsregler dekker destinasjonen. Ekstra assosiasjoner kjøper robusthet mot feil i en tilgjengelighetssone, ikke ekstra rekkevidde. En to-AZ-design dobler derfor assosiasjonstimene, mens en applikasjons-VPC med åtte subnett ikke ganger noe med åtte.

Legg merke til assosiasjonstypen mens du er på den siden. En VPC-subnett-assosiasjon og en direkte Transit Gateway-assosiasjon er ulike ordninger med ulike linjer, så ikke flytt én modell inn i den andres tilbud. Og ikke test antallet ved å koble fra ting: fjerning av det siste målnettverket avslutter aktive sesjoner og blokkerer nye tilkoblinger til noe er assosiert igjen.

Utled tilkoblingstimer fra sesjonsdata

Antall personer er feil innsatsfaktor, og den er feil i begge retninger. Ti personer som hver holder tre enheter tilkoblet, er tretti tilkoblinger. Hundre personer som kobler til i tjue minutter om dagen, gir langt fra hundre samtidige sesjoner.

Client VPN-tilkoblingslogger registrerer tilkoblings- og frakoblingshendelser per klient, som er nøyaktig det paret du trenger. Eksporter en representativ uke, match hendelsene og summer varighetene:

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

Rett deretter for to vaner. Sesjoner som blir stående tilkoblet gjennom lunsjen, natten eller en laptop-suspend som aldri rev ned tunnelen, faktureres fortsatt, og de er usynlige i et personantall. Målingen er også timebasert, så budsjetter en tjue-minutters sesjon som en hel time i stedet for å anta proporsjonal fakturering; hvis regningen kommer lavere, behandle det som margin og ikke som planleggingsinput.

Gjør regnestykket med satsene i din region

Satsene varierer per region, så hent dem fra AWS VPN-prissiden for regionen du distribuerer til, og lim dem inn i arket som input. Bare som illustrasjon: ta en assosiasjonssats på 0.10 dollar i timen og en tilkoblingstimesats på 0.05 dollar, og prissett deretter en måned på 30 dager med to assosiasjoner hele måneden og 100 personer som kobler til seks timer på 20 arbeidsdager:

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

Flytt nå én input om gangen og se hvilken linje som reagerer. Å doble assosiasjonene legger til 144 dollar her; å doble gjennomsnittlig sesjonslengde legger til 600. Det forholdet avgjør vanligvis designargumentet for deg: kutt overflødighet du ikke kan forsvare, eller gå etter ledige sesjoner, alt etter hvilket tall som er størst. Skriv regionen og satsdatoen ved siden av resultatet, for et tilbud uten dem kan ikke gjenskapes seks uker senere.

Legg til kostnadene delsummen utelater

Endepunktavgiften betaler for endepunktet. Alt trafikken berører etterpå har sin egen måler, og det er på de linjene optimistiske VPN-estimater faller fra hverandre.

• Internett-egress for trafikk som forlater gjennom endepunktet, fakturert per GB.
• Offentlige IPv4-adresser, som bærer sin egen timeavgift uavhengig av VPN-en.
• CloudWatch Logs-inntak og -lagring for tilkoblingsloggene du nettopp eksporterte.
• Lambda-kall hvis du kjører en client-connect-handler.
• Directory Service eller din SAML-identitetsleverandør, hvis det er slik brukerne autentiserer, pluss ACM Private CA-avgifter hvis du utsteder sertifikater der.
• NAT Gateway-timer og databehandling, og Transit Gateway-tilknytningstimer pluss databehandling, når stien bruker dem.

Ingen av disse skalerer med assosiasjonsantallet, og derfor ser et tall per bruker som bare er satt sammen av endepunktavgifter, fint ut på papiret og vokser så når ekte trafikk dukker opp. Sett dem på egne linjer selv når du må anslå dem, slik at leseren ser hvilke deler som er målt og hvilke som er gjetninger.

Kontroller arket før du sender det

Fire kontroller fanger feilene jeg faktisk gjorde: assosiasjonsantallet stemmer nøyaktig med fanen Associations, tilkoblingstimene kom fra sammenkoblede logghendelser og ikke fra et personantall, regionen og satsdatoen er skrevet ned, og hver sidekostnad har sin egen linje. Hvis én av de fire mangler, har du en gjetning med formatering.

Trekk loggeksporten først. Det er den eneste inputen du senere ikke kan rekonstruere fra minnet, og den forteller deg også om problemet med ledige sesjoner er verdt å fikse før den første regningen kommer.