Hogyan becsüljük meg az AWS Client VPN számlát a konzolból

A múlt hónapban egy táblázatban építettem fel egy Client VPN-becslést, elküldtem egy ügyfélnek, majd kétszer átdolgoztam: egyszer, mert a társításokat alhálózatokkal szoroztam, egyszer pedig, mert a munkamenet-adatok helyett létszámot használtam. A felülvizsgálatot túlélő változat két óránkénti mérőn és rövid mellékköltség-listán nyugszik. A konzolból és egy naplóexportból újraépítheti, árkalkulátor nélkül.

Két mérő, és semmi más a végponton

Az AWS a Client VPN végpontot társítás-órák és kapcsolat-órák alapján számlázza. A társítás-órák minden végponthoz csatolt célhálózat után ketyegnek, a nap huszonnégy órájában, akár csatlakozik valaki, akár nem. A kapcsolat-órák minden csatlakozott kliens után ketyegnek, ameddig a munkamenet fennáll.

Két következmény adódik közvetlenül a táblázatból. Egy végpont, amelyen nincs senki, továbbra is pénzbe kerül, és egy ember, aki egyszerre futtat laptopot és telefont, két kapcsolatot hoz létre.

A társításokat a konzolban számolja, ne az alhálózatokat a VPC-ben

Nyissa meg a VPC-t, majd a Client VPN endpoints oldalt, majd a saját végpontját, majd az Associations lapot. Minden sor ott egy alhálózat-csatolás, és az a sorszám a társítási szorzó. A VPC mögötti alkalmazás-alhálózatok számához ennek semmi köze.

Egy társítás elég egy engedélyezett VPC-hálózat eléréséhez, ha a végpont útvonalai és az engedélyezési szabályok lefedik a célt. A további társítások rendelkezésre állási zóna elleni ellenálló képességet vásárolnak, nem több elérést. Ezért a két AZ-s kialakítás megduplázza a társítás-órákat, míg egy nyolc alhálózatos alkalmazás-VPC semmit sem szoroz nyolccal.

Figyelje meg a társítás típusát, amíg azon az oldalon van. A VPC-alhálózat társítás és a közvetlen Transit Gateway társítás eltérő elrendezések, eltérő költségsorokkal, ezért ne vigyen át egy modellt a másik ajánlatába. És ne a számot tesztelje azzal, hogy dolgokat leválaszt: az utolsó célhálózat eltávolítása lezárja az aktív munkameneteket, és blokkolja az új kapcsolatokat, amíg valami újra nem társul.

Vezesse le a kapcsolat-órákat a munkamenet-adatokból

A létszám rossz bemenet, és mindkét irányban rossz. Tíz ember, aki egyenként három eszközt tart csatlakoztatva, harminc kapcsolat. Száz ember, aki naponta húsz percet csatlakozik, korántsem száz párhuzamos munkamenetet ad.

A Client VPN kapcsolatnaplói kliensenként rögzítik a csatlakozási és bontási eseményeket, ami pontosan a szükséges párosítás. Exportáljon egy reprezentatív hetet, párosítsa az eseményeket, és adja össze az időtartamokat:

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

Aztán javítson két szokáson. Az ebéden, éjszakán vagy olyan laptop-alváson át csatlakozva maradt munkamenetek, amely soha nem szakította meg az alagutat, továbbra is számlázódnak, és létszámban láthatatlanok. A mérés óránkénti is, ezért a húszperces munkamenetet számolja teljes óraként, ne feltételezzen arányos elszámolást; ha a számla alacsonyabb, tekintse marzsnak, nem tervezési bemenetnek.

Számoljon a régiója díjaival

Az árak régiónként eltérnek, ezért vegye őket az AWS VPN árazási oldaláról ahhoz a régióhoz, ahová telepít, és illessze be bemenetként a táblázatba. Csak szemléltetésképpen: vegyen 0.10 dollár/óra társítási árat és 0.05 dolláros kapcsolat-óra árat, majd árazzon be egy 30 napos hónapot két, egész hónapban tartott társítással és 100 emberrel, akik hat órát csatlakoznak 20 munkanapon:

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

Most mozgasson egyszerre egy bemenetet, és figyelje, melyik sor reagál. A társítások megduplázása itt 144 dollárt ad hozzá; az átlagos munkamenet-hossz megduplázása 600-at. Ez az arány általában eldönti a tervezési vitát ön helyett: vágja le az indokolhatatlan redundanciát, vagy menjen a tétlen munkamenetek után, amelyik szám nagyobb. Írja az eredmény mellé a régiót és az árak dátumát, mert ezek nélkül az ajánlat hat hét múlva nem reprodukálható.

Adja hozzá a költségeket, amelyeket a részösszeg kihagy

A végpontdíj a végpontért fizet. Mindennek, amit a forgalom utána érint, saját mérője van, és ezeken a sorokon omlanak össze az optimista VPN-becslések.

• Internetes kimenő forgalom a végponton keresztül távozó forgalomhoz, GB-onként számlázva.
• Nyilvános IPv4-címek, amelyek saját óradíjat hordoznak, a VPN-től függetlenül.
• CloudWatch Logs bevitel és tárolás az imént exportált kapcsolatnaplókhoz.
• Lambda-hívások, ha client-connect kezelőt futtat.
• Directory Service vagy a SAML identitásszolgáltatója, ha a felhasználók így hitelesítenek, plusz ACM Private CA díjak, ha ott állít ki tanúsítványokat.
• NAT Gateway órák és adatfeldolgozás, valamint Transit Gateway csatolási órák és adatfeldolgozás, amikor az útvonal ezeket használja.

Ezek egyike sem skálázódik a társítások számával, ezért a csak végpontdíjakból összerakott felhasználónkénti szám papíron jól néz ki, majd nő, amikor valódi forgalom jelenik meg. Tegye őket külön sorokra akkor is, ha becsülnie kell őket, hogy az olvasó lássa, mely részek mértek és melyek találgatások.

Ellenőrizze a táblázatot küldés előtt

Négy ellenőrzés kapja el a hibákat, amelyeket valóban elkövettem: a társítások száma pontosan megegyezik az Associations lappal, a kapcsolat-órák párosított naplóeseményekből jöttek, nem létszámból, a régió és az árak dátuma le van írva, és minden mellékköltségnek saját sora van. Ha a négy közül bármelyik hiányzik, formázott találgatása van.

Először húzza le a naplóexportot. Ez az egyetlen bemenet, amelyet később nem tud emlékezetből rekonstruálni, és azt is megmondja, érdemes-e a tétlen munkamenetek problémáját az első számla előtt javítani.