Korleis ein kan estimere ein AWS Client VPN-rekning frå konsollen

Førre månad bygde eg eit Client VPN-estimat i eit rekneark, sende det til ein kunde og reviderte det så to gonger: éin gong fordi eg gonga assosiasjonar med subnett, og éin gong fordi eg brukte talet på personar i staden for sesjonsdata. Versjonen som overlevde gjennomgangen, kviler på to timemålarar og ei kort liste med sidekostnader. Du kan byggje han opp att frå konsollen og éin loggeksport, utan ein priskalkulator.

To målarar, og ingenting anna på endepunktet

AWS fakturerer eit Client VPN-endepunkt på assosiasjonstimar og tilkoplingsstimar. Assosiasjonstimane gå for kvart mål nettverk som er knytt til endepunktet, døgnet rundt, uansett om nokon koplar til. Tilkoplingsstimane går per tilkopla klient, så lenge den sesjonen held seg oppe.

To følgjer kjem rett ut av den tabellen. Eit endepunkt utan nokon på seg kostar framleis pengar, og éin person som køyrer berbar datamaskin og telefon samtidig, gjev to tilkoplingar.

Tel assosiasjonar i konsollen, ikkje subnett i VPC-en

Opne VPC, så Client VPN endpoints, så ditt endepunkt, så fana Associations. Kvar rad der er ei subnett-tilknyting, og det radtalet er assosiasjonsmultiplikatoren din. Talet på applikasjonssubnett bak VPC-en har ingenting med det å gjere.

Éin assosiasjon er nok til å nå eit autorisert VPC-nettverk når rutene til endepunktet og autorisasjonsreglane dekkjer destinasjonen. Ekstra assosiasjonar kjøper robustheit mot feil i ei tilgjengelegheitssone, ikkje ekstra rekkjevidd. Ein to-AZ-design doblar derfor assosiasjonstimane, medan ein applikasjons-VPC med åtte subnett ikkje gongar noko med åtte.

Legg merke til assosiasjonstypen medan du er på den sida. Ein VPC-subnett-assosiasjon og ein direkte Transit Gateway-assosiasjon er ulike ordningar med ulike linjer, så ikkje flytt éin modell inn i tilbodet til den andre. Og ikkje test talet ved å kopie frå ting: fjerning av det siste mål nettverket avsluttar aktive sesjonar og blokkerer nye tilkoplingar til noko er assosiert igjen.

Leid ut tilkoplingsstimar frå sesjonsdata

Talet på personar er feil innsatsfaktor, og han er feil i båe retningar. Ti personar som kvar held tre einingar tilkopla, er tretti tilkoplingar. Hundre personar som kvar koplar til i tjue minutt om dagen, gjev langt frå hundre samtidige sesjonar.

Client VPN-tilkoplingsloggar registrerer tilkoplings- og fråkoplinghendingar per klient, som er nøyaktig det paret du treng. Eksporter ei representativ veke, match hendingane og summer varigheitene:

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

Rett så for to vanar. Sesjonar som blir ståande tilkopla gjennom lunsjen, natta eller ein berbar-datamaskin-suspend som aldri reiv ned tunnelen, blir framleis fakturerte, og dei er usynlege i eit persontal. Målinga er òg timebasert, så budsjetter ein tjue-minutts sesjon som ein heil time i staden for å ante proporsjonal fakturering; kjem rekninga lågare, handsame det som margin og ikkje som planleggingsinnsats.

Gjer reknestykket med satsane i din region

Satsane varierer per region, så hent dei frå AWS VPN-prissida for regionen du distribuerer til, og lim dei inn i arket som innsats. Berre som illustrasjon: ta ein assosiasjonssats på 0.10 dollar i timen og ein tilkoplingstimesats på 0.05 dollar, og pris så ein månad på 30 dagar med to assosiasjonar heile månaden og 100 personar som koplar til seks timar på 20 arbeidsdagar:

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 no éin innsats om gongen og sjå kva linje som reagerer. Å doble assosiasjonane legg til 144 dollar her; å doble gjennomsnittleg sesjonslengd legg til 600. Det tilhøvet avgjer vanlegvis designargumentet for deg: kutt overflod du ikkje kan forsvare, eller gå etter ledige sesjonar, alt etter kva tal som er størst. Skriv regionen og satsdatoen ved sida av resultatet, for eit tilbod utan dei kan ikkje atterskapast seks veker seinare.

Legg til kostnadene delsummen utelèt

Endepunktavgifta betaler for endepunktet. Alt trafikken rører etterpå har sin eigen målar, og det er på dei linjene optimistiske VPN-estimat fell frå kvarandre.

• Internett-egress for trafikk som går ut gjennom endepunktet, fakturert per GB.
• Offentlege IPv4-adresser, som ber si eiga timeavgift uavhengig av VPN-en.
• CloudWatch Logs-inntak og -lagring for tilkoplingsloggane du nettopp eksporterte.
• Lambda-kall om du køyrer ein client-connect-handterar.
• Directory Service eller SAML-identitetsleverandøren din, om det er slik brukarane autentiserer, pluss ACM Private CA-avgifter om du gjev ut sertifikat der.
• NAT Gateway-timar og databehandling, og Transit Gateway-tilknytingstimar pluss databehandling, kvar gong stien brukar dei.

Ingen av desse skalerer med assosiasjonstalet, og derfor ser eit tal per brukar som berre er sett saman av endepunktavgifter, fint ut på papiret og veks så når ekte trafikk dukkar opp. Set dei på eigne linjer sjølv når du må estimere dei, slik at lesaren ser kva delar som er målte og kva som er gissingar.

Kontroller arket før du sender det

Fire kontrollar fangar feila eg faktisk gjorde: assosiasjonstalet stemmer nøyaktig med fana Associations, tilkoplingsstimane kom frå samankopla logghendingar og ikkje frå eit persontal, regionen og satsdatoen er skrivne ned, og kvar sidekostnad har si eiga linje. Om éin av dei fire manglar, har du ei gissing med formatering.

Trekk loggeksporten først. Det er den einaste innsatsen du seinare ikkje kan rekonstruere frå minnet, og han fortel deg òg om problemet med ledige sesjonar er verdt å fikse før den første rekninga kjem.