Kiel taksi fakturon de AWS Client VPN el la konzolo

Pasintmonate mi konstruis takson pri Client VPN en kalkultabelo, sendis ĝin al kliento kaj poste reviziis ĝin dufoje: unufoje ĉar mi multiplikis asociojn per subretoj, kaj unufoje ĉar mi uzis nombron de homoj anstataŭ sesiaj datumoj. La versio, kiu travivis la revizion, baziĝas sur du horaj mezuriloj kaj mallonga listo de flankaj kostoj. Vi povas rekonstrui ĝin el la konzolo kaj unu protokola eksporto, sen prizkalkulilo.

Du mezuriloj, kaj nenio alia sur la finpunkto

AWS fakturas Client VPN-finpunkton laŭ asocio-horoj kaj konekto-horoj. Asocio-horoj funkcias por ĉiu cela reto alkroĉita al la finpunkto, ĉirkaŭ la horloĝo, ĉu iu konektiĝas aŭ ne. Konekto-horoj funkcias por ĉiu konektita kliento, dum tiu sesio restas malfermita.

Du sekvoj rekte eliras el tiu tabelo. Finpunkto kun neniu sur ĝi ankoraŭ kostas monon, kaj unu persono funkciiganta tekkomputilon kaj telefonon samtempe produktas du konektojn.

Nombru asociojn en la konzolo, ne subretojn en la VPC

Malfermu VPC, poste Client VPN endpoints, poste vian finpunkton, poste la langeton Associations. Ĉiu vico tie estas subreta alkroĉo, kaj tiu vicnombro estas via asocia multiplikanto. La nombro de aplikaĵaj subretoj malantaŭ la VPC neniel rilatas.

Unu asocio sufiĉas por atingi rajtigitan VPC-reton, post kiam la itineroj de la finpunkto kaj la rajtigaj reguloj kovras la celon. Pliaj asocioj aĉetas rezistecon al paneo de havebleca zono, ne plian atingon. Do dizajno kun du AZ duobligas asocio-horojn, dum aplikaĵa VPC kun ok subretoj multiplikas nenion per ok.

Rimarku la asocian tipon dum vi estas sur tiu paĝo. VPC-subreta asocio kaj rekta Transit Gateway-asocio estas malsamaj aranĝoj kun malsamaj fakturaj eroj, do ne portu unu modelon en la oferton de la alia. Kaj ne testu la nombron per malkroĉado: forigo de la lasta cela reto finas aktivajn sesiojn kaj blokas novajn konektojn ĝis io estos asocie rekroĉita.

Derivu konekto-horojn el sesiaj datumoj

Nombro de homoj estas la malĝusta enigo, kaj ĝi malĝustas en ambaŭ direktoj. Dek homoj, kiuj ĉiu tenas tri aparatojn konektitaj, estas tridek konektoj. Cent homoj, kiuj ĉiu konektiĝas dudek minutojn tage, produktas neniel cent samtempajn sesiojn.

Protokoloj de Client VPN-konektoj registras konektajn kaj malkonektajn eventojn laŭ kliento, kio estas ĝuste la paro, kiun vi bezonas. Eksportu reprezentan semajnon, parigu la eventojn kaj sumigu la daŭrojn:

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

Poste korektu du kutimojn. Sesioj lasitaj konektitaj tra tagmanĝo, dum la nokto aŭ tra tekkomputila paŭzo, kiu neniam rompis la tunelon, ankoraŭ fakturiĝas, kaj ili estas nevideblaj en nombrado de homoj. Mezurado ankaŭ estas hora, do buĝetu dudekminutan sesion kiel plenan horon anstataŭ supozi proporcionan fakturidadon; se la fakturo venas pli malalta, traktu tion kiel marĝenon, ne kiel planan enigon.

Kalkulu per la tarifoj de via regiono

Tarifoj varias laŭ regiono, do prenu ilin el la preza paĝo de AWS VPN por la regiono, en kiun vi deplojas, kaj algluu ilin en la tabelon kiel enigojn. Nur kiel ilustraĵo: prenu asocian tarifon de 0.10 dolaroj hore kaj konektohoran tarifon de 0.05 dolaroj, poste prizkalkulu monaton de 30 tagoj kun du asocioj la tutan monaton kaj 100 homoj konektantaj ses horojn en 20 labortagoj:

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

Nun movu unu enigon samtempe kaj observu, kiu linio reagas. Duobligo de la asocioj aldonas ĉi tie 144 dolarojn; duobligo de la averaĝa sesia longeco aldonas 600. Tiu proporcio kutime solvas la dizajnan diskuton por vi: fortranĉu redundon, kiun vi ne povas pravigi, aŭ ĉasu senokupajn sesiojn, laŭ kiu nombro estas pli granda. Skribu la regionon kaj la tarifan daton apud la rezulto, ĉar oferto sen ili ne estas reproduktebla ses semajnojn poste.

Aldonu la kostojn, kiujn la subtotalo ellasas

La finpunkta kotizo pagas la finpunkton. Ĉio, kion la trafiko poste tuŝas, havas sian propran mezurilon, kaj ĝuste en tiuj linioj optimismaj VPN-taksoj disfalas.

• Interreta eliro por trafiko, kiu forlasas tra la finpunkto, fakturata laŭ GB.
• Publikaj IPv4-adresoj, kiuj portas propran horan kotizon sendepende de la VPN.
• Enpreno kaj stokado en CloudWatch Logs por la konektaj protokoloj, kiujn vi ĵus eksportis.
• Alvokoj de Lambda, se vi funkciigas client-connect-traktilon.
• Directory Service aŭ via SAML-identecprovizanto, se tiel aŭtentikiĝas uzantoj, plus kotizoj de ACM Private CA, se vi tie eldonas atestilojn.
• Horoj de NAT Gateway kaj datuma prilaborado, kaj alkroĉaj horoj de Transit Gateway plus datuma prilaborado, kiam la vojo uzas ilin.

Neniu el tiuj skaliĝas kun la nombro de asocioj, tial nombro po uzanto kunmetita nur el finpunktaj kotizoj aspektas bone surpapere kaj poste kreskas, kiam aperas reala trafiko. Metu ilin en apartajn vicojn eĉ kiam vi devas taksi ilin, por ke la leganto vidu, kiuj partoj estas mezuritaj kaj kiuj estas konjektoj.

Kontrolu la tabelon antaŭ ol sendi ĝin

Kvar kontroloj kaptas la erarojn, kiujn mi vere faris: la nombro de asocioj kongruas ekzakte kun la langeto Associations, la konekto-horoj venis el parigitaj protokolaj eventoj anstataŭ el nombrado de homoj, la regiono kaj la tarifa dato estas skribitaj, kaj ĉiu flanka kosto havas sian propran vicon. Se mankas iu el la kvar, vi havas konjekton kun formatado.

Unue eltiru la protokolan eksporton. Ĝi estas la sola enigo, kiun vi poste ne povas rekonstrui el memoro, kaj ĝi ankaŭ diras al vi, ĉu la problemo de senokupaj sesioj indas ripari antaŭ ol la unua fakturo alvenos.