Jak oszacować rachunek AWS Client VPN z konsoli

W zeszłym miesiącu zbudowałem szacunek Client VPN w arkuszu, wysłałem go do klienta i poprawiałem dwa razy: raz, bo pomnożyłem skojarzenia przez podsieci, a raz, bo użyłem liczby osób zamiast danych sesji. Wersja, która przetrwała przegląd, opiera się na dwóch licznikach godzinowych i krótkiej liście kosztów pobocznych. Możesz odtworzyć ją z konsoli i jednego eksportu dziennika, bez kalkulatora cen.

Dwa liczniki, i nic więcej na endpoincie

AWS rozlicza endpoint Client VPN według godzin skojarzenia i godzin połączenia. Godziny skojarzenia płyną dla każdej sieci docelowej przypiętej do endpointu, przez całą dobę, niezależnie od tego, czy ktoś się łączy. Godziny połączenia płyną dla każdego podłączonego klienta, dopóki ta sesja trwa.

Z tej tabeli wynikają dwie konsekwencje. Endpoint, na którym nikogo nie ma, nadal kosztuje, a jedna osoba z laptopem i telefonem naraz daje dwa połączenia.

Licz skojarzenia w konsoli, a nie podsieci w VPC

Otwórz VPC, potem Client VPN endpoints, potem swój endpoint, potem kartę Associations. Każdy wiersz to przypięcie podsieci, a ta liczba wierszy to twój mnożnik skojarzeń. Liczba podsieci aplikacyjnych za VPC nie ma z tym nic wspólnego.

Jedno skojarzenie wystarcza, by dotrzeć do autoryzowanej sieci VPC, gdy trasy endpointu i reguły autoryzacji obejmują cel. Dodatkowe skojarzenia kupują odporność na awarię strefy dostępności, a nie dodatkowy zasięg. Dlatego projekt z dwiema AZ podwaja godziny skojarzenia, a aplikacyjne VPC z ośmioma podsieciami niczego nie mnoży przez osiem.

Zwróć uwagę na typ skojarzenia, będąc na tej stronie. Skojarzenie podsieci VPC i bezpośrednie skojarzenie Transit Gateway to różne układy z różnymi pozycjami rachunku, więc nie przenoś jednego modelu do oferty drugiego. I nie testuj liczby przez odpinanie rzeczy: usunięcie ostatniej sieci docelowej kończy aktywne sesje i blokuje nowe połączenia, dopóki coś znów nie zostanie skojarzone.

Wyprowadź godziny połączenia z danych sesji

Liczba osób to złe wejście i jest zła w obu kierunkach. Dziesięć osób, z których każda trzyma trzy podłączone urządzenia, to trzydzieści połączeń. Sto osób łączących się po dwadzieścia minut dziennie daje daleko od stu równoczesnych sesji.

Dzienniki połączeń Client VPN zapisują zdarzenia połączenia i rozłączenia dla każdego klienta, czyli dokładnie tę parę, której potrzebujesz. Wyeksportuj reprezentatywny tydzień, dopasuj zdarzenia i zsumuj czasy trwania:

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

Potem popraw dwie nawyki. Sesje pozostawione połączone przez lunch, noc lub uśpienie laptopa, które nigdy nie zerwało tunelu, nadal są rozliczane i są niewidoczne w liczbie osób. Pomiar jest też godzinowy, więc zaplanuj sesję dwudziestominutową jako pełną godzinę, zamiast zakładać rozliczanie proporcjonalne; jeśli rachunek wyjdzie niższy, potraktuj to jako marżę, a nie jako dane do planowania.

Policz to według stawek swojego regionu

Stawki różnią się między regionami, więc weź je ze strony cen AWS VPN dla regionu, w którym wdrażasz, i wklej do arkusza jako wejścia. Wyłącznie jako ilustrację: przyjmij stawkę skojarzenia 0.10 dolara za godzinę i stawkę godziny połączenia 0.05 dolara, a potem wyceń miesiąc 30-dniowy z dwoma skojarzeniami przez cały miesiąc i 100 osobami łączącymi się sześć godzin w 20 dni roboczych:

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

Teraz przesuwaj po jednym wejściu i patrz, który wiersz reaguje. Podwojenie skojarzeń dodaje tu 144 dolary; podwojenie średniej długości sesji dodaje 600. Ten stosunek zwykle rozstrzyga spór o projekt za ciebie: odetnij nadmiar, którego nie umiesz uzasadnić, albo zajmij się sesjami bezczynnymi, zależnie od tego, która liczba jest większa. Zapisz region i datę stawek obok wyniku, bo oferty bez nich nie da się odtworzyć sześć tygodni później.

Dodaj koszty, które suma pomija

Opłata za endpoint płaci za endpoint. Wszystko, czego ruch dotknie później, ma własny licznik, i właśnie na tych wierszach optymistyczne szacunki VPN się rozsypują.

• Wyjście do internetu dla ruchu opuszczającego endpoint, rozliczane za GB.
• Publiczne adresy IPv4, które noszą własną opłatę godzinową niezależnie od VPN.
• Przyjmowanie i przechowywanie w CloudWatch Logs dla dzienników połączeń, które właśnie wyeksportowałeś.
• Wywołania Lambda, jeśli uruchamiasz procedurę client-connect.
• Directory Service lub twój dostawca tożsamości SAML, jeśli tak uwierzytelniają się użytkownicy, plus opłaty ACM Private CA, jeśli tam wystawiasz certyfikaty.
• Godziny NAT Gateway i przetwarzanie danych oraz godziny przypięcia Transit Gateway plus przetwarzanie danych, ilekroć ścieżka ich używa.

Nic z tego nie skaluje się z liczbą skojarzeń, dlatego liczba na użytkownika złożona tylko z opłat za endpoint wygląda dobrze na papierze, a potem rośnie, gdy pojawia się prawdziwy ruch. Umieść je w osobnych wierszach nawet wtedy, gdy musisz je oszacować, żeby czytelnik widział, które części są zmierzone, a które zgadywane.

Sprawdź arkusz przed wysłaniem

Cztery kontrole łapią błędy, które naprawdę popełniłem: liczba skojarzeń dokładnie odpowiada karcie Associations, godziny połączenia pochodzą z sparowanych zdarzeń dziennika, a nie z liczby osób, region i data stawek są zapisane, a każdy koszt poboczny ma własny wiersz. Jeśli brakuje którejkolwiek z czterech, masz zgadywanie z formatowaniem.

Najpierw pobierz eksport dziennika. To jedyne wejście, którego później nie odtworzysz z pamięci, a przy okazji mówi, czy warto naprawić problem bezczynnych sesji przed pierwszym rachunkiem.