Як оцінити рахунок за AWS Client VPN із консолі

Минулого місяця я зібрав оцінку Client VPN у таблиці, надіслав її клієнтові й потім двічі переробив: одного разу через те, що помножив зв'язки на підмережі, і одного разу через те, що взяв кількість людей замість даних сеансів. Версія, що пережила перевірку, спирається на два погодинні лічильники та короткий список побічних витрат. Її можна відтворити з консолі та одного експорту журналу, без калькулятора цін.

Два лічильники, і більше нічого на endpoint

AWS виставляє рахунок за endpoint Client VPN за годинами зв'язку та годинами підключення. Години зв'язку йдуть для кожної цільової мережі, приєднаної до endpoint, цілодобово, незалежно від того, чи хтось підключається. Години підключення йдуть для кожного підключеного клієнта, поки цей сеанс залишається активним.

З цієї таблиці випливають два наслідки. Endpoint, на якому нікого немає, усе одно коштує грошей, а одна людина з ноутбуком і телефоном одночасно створює два підключення.

Рахуйте зв'язки в консолі, а не підмережі у VPC

Відкрийте VPC, потім Client VPN endpoints, потім свій endpoint, потім вкладку Associations. Кожен рядок там — приєднання підмережі, і це число рядків є вашим множником зв'язків. Кількість прикладних підмереж за VPC до цього не має відношення.

Одного зв'язку достатньо, щоб дістатися авторизованої мережі VPC, коли маршрути endpoint і правила авторизації покривають призначення. Додаткові зв'язки купують стійкість до відмови зони доступності, а не додаткове охоплення. Тому схема з двома AZ подвоює години зв'язку, а прикладна VPC з вісьмома підмережами нічого не множить на вісім.

Зверніть увагу на тип зв'язку, поки ви на цій сторінці. Зв'язок із підмережею VPC і прямий зв'язок через Transit Gateway — різні схеми з різними статтями витрат, тому не переносьте одну модель у пропозицію іншої. І не перевіряйте число, від'єднуючи щось: видалення останньої цільової мережі завершує активні сеанси й блокує нові підключення, доки щось знову не буде зв'язане.

Виведіть години підключення з даних сеансів

Кількість людей — неправильний вхід, і він неправильний в обидва боки. Десять людей, кожен з яких тримає три підключені пристрої, — це тридцять підключень. Сто людей, які підключаються по двадцять хвилин на день, дають далеко не сто одночасних сеансів.

Журнали підключень Client VPN фіксують події підключення й відключення для кожного клієнта, а це саме та пара, яка потрібна. Експортуйте репрезентативний тиждень, зіставте події та підсумуйте тривалості:

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

Потім виправте дві звички. Сеанси, залишені підключеними на обід, на ніч або через сплячий режим ноутбука, який так і не розірвав тунель, усе одно тарифікуються і не видні в підрахунку людей. Вимірювання також погодинне, тож плануйте двадцятихвилинний сеанс як повну годину, а не припускайте пропорційну тарифікацію; якщо рахунок прийде менший, вважайте це маржею, а не вхідними даними для планування.

Порахуйте за тарифами свого регіону

Тарифи різняться за регіонами, тож візьміть їх зі сторінки цін AWS VPN для регіону, у який розгортаєте, і вставте в таблицю як вхідні дані. Лише для ілюстрації: візьміть тариф зв'язку 0.10 долара за годину й тариф години підключення 0.05 долара, потім порахуйте місяць із 30 днів із двома зв'язками весь місяць і 100 людьми, які підключаються шість годин у 20 робочих днів:

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

Тепер рухайте по одному вхідному параметру й дивіться, який рядок реагує. Подвоєння зв'язків додає тут 144 долари; подвоєння середньої тривалості сеансу додає 600. Це співвідношення зазвичай вирішує суперечку про схему за вас: приберіть надмірність, яку не можете обґрунтувати, або займіться простоюючими сеансами, залежно від того, яке число більше. Запишіть регіон і дату тарифів поряд із результатом, бо пропозицію без них не відтворити через шість тижнів.

Додайте витрати, які проміжний підсумок пропускає

Плата за endpoint оплачує endpoint. Усе, чого трафік торкається після, має власний лічильник, і саме на цих рядках розсипаються оптимістичні оцінки VPN.

• Вихід в інтернет для трафіку, що виходить через endpoint, тарифікується за GB.
• Публічні адреси IPv4, які несуть власну погодинну плату незалежно від VPN.
• Приймання та зберігання в CloudWatch Logs для журналів підключень, які ви щойно експортували.
• Виклики Lambda, якщо ви запускаєте обробник client-connect.
• Directory Service або ваш постачальник ідентичності SAML, якщо користувачі автентифікуються саме так, плюс плата ACM Private CA, якщо ви видаєте там сертифікати.
• Години NAT Gateway і обробка даних, а також години приєднання Transit Gateway плюс обробка даних, коли маршрут їх використовує.

Ніщо з цього не масштабується з кількістю зв'язків, тому цифра на користувача, зібрана лише з плати за endpoint, гарно виглядає на папері, а потім зростає, коли з'являється реальний трафік. Ставте їх в окремі рядки, навіть коли доводиться їх оцінювати, щоб читач бачив, які частини виміряні, а які — здогади.

Перевірте таблицю перед надсиланням

Чотири перевірки ловлять помилки, які я справді зробив: кількість зв'язків точно збігається з вкладкою Associations, години підключення взяті зі спарених подій журналу, а не з підрахунку людей, регіон і дата тарифів записані, і кожна побічна витрата має свій рядок. Якщо бракує будь-чого з чотирьох, у вас здогад із форматуванням.

Спершу вивантажте журнал. Це єдиний вхід, який потім не відновити з пам'яті, і він також каже, чи варто виправити проблему простоюючих сеансів до першого рахунку.