В прошлом месяце я собрал оценку Client VPN в таблице, отправил её клиенту и затем дважды переработал: один раз потому, что умножил связи на подсети, и один раз потому, что использовал число людей вместо данных сеансов. Версия, пережившая проверку, опирается на два почасовых счётчика и короткий список побочных расходов. Её можно воспроизвести из консоли и одной выгрузки журнала, без калькулятора цен.

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

AWS выставляет счёт за endpoint Client VPN по часам связи и часам подключения. Часы связи идут для каждой целевой сети, привязанной к endpoint, круглосуточно, независимо от того, подключается кто-нибудь или нет. Часы подключения идут для каждого подключённого клиента, пока этот сеанс остаётся активным.

MeterWhat increments itWhat does not change it
Association-hoursEach associated subnet or Transit Gateway attachment, per hour, 24/7 while attachedNumber of users, traffic volume
Connection-hoursEach active client session, per hourHow many subnets that client can reach

Из этой таблицы следуют два вывода. 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, часы подключения взяты из спаренных событий журнала, а не из подсчёта людей, регион и дата тарифов записаны, и у каждого побочного расхода есть своя строка. Если не хватает любого из четырёх, у вас догадка с форматированием.

Сначала выгрузите журнал. Это единственный вход, который потом не восстановить по памяти, и он же говорит, стоит ли исправлять проблему простаивающих сеансов до прихода первого счёта.

Похожие статьи