コンソールから AWS Client VPN の請求額を見積もる方法

AWS Client VPN の見積もり手順：関連付けを数え、セッションログから接続時間を導き、エンドポイント料金以外の費用を足します。

先月、スプレッドシートで Client VPN の見積もりを作り、顧客に送り、その後二度修正した——一度は関連付けをサブネット数で掛けたため、もう一度はセッションデータではなく人数を使ったためだ。レビューを生き残った版は、二つの時間メーターと短い副次費用の一覧に支えられている。コンソールとログ出力一回から、料金計算ツールなしで再現できる。

二つのメーター、そしてエンドポイントにはそれ以外何もない

AWS は Client VPN エンドポイントを関連付け時間と接続時間で課金する。関連付け時間は、エンドポイントにつないだターゲットネットワークごとに、誰も接続していなくても一日中動き続ける。接続時間は、接続中のクライアントごとに、そのセッションが続く限り動く。

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

この表から二つの帰結が直接出る。誰もいないエンドポイントでも費用はかかり、一人がノート PC とスマホを同時に使えば接続は二つになる。

コンソールで関連付けを数え、VPC のサブネットは数えない

VPC、次に Client VPN endpoints、次に自分のエンドポイント、次に Associations タブを開く。そこにある各行がサブネットの関連付けで、その行数が関連付けの乗数になる。VPC の背後にあるアプリケーションサブネットの数は関係ない。

エンドポイントのルートと認可ルールが宛先を覆っていれば、関連付け一つで認可された VPC ネットワークに届く。追加の関連付けが買うのはアベイラビリティーゾーン障害への耐性であり、追加の到達範囲ではない。したがって二つの 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

次に二つの習慣を補正する。昼食、夜間、またはトンネルを切らないノート PC のスリープを挟んで接続されたままのセッションも課金され、人数の集計では見えない。計測は一時間単位なので、二十分のセッションは比例請求を仮定せず一時間として見積もり、請求が低く出たらそれは計画の入力ではなく余裕とみなす。

自分のリージョンの料金で計算する

料金はリージョンごとに異なるので、デプロイするリージョンの AWS VPN 料金ページから取得し、入力としてシートに貼る——あくまで例として、関連付け一時間 0.10 ドル、接続一時間 0.05 ドルを取り、二つの関連付けを一か月維持し、100 人が 20 営業日に六時間接続する 30 日の月を計算する。

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 ドル増える。この比率が通常、設計の議論を決めてくれる——正当化できない冗長性を削るか、アイドルセッションを追うか、大きい方の数字で決める。結果の横にリージョンと料金の日付を書く、それがない見積もりは六週間後に再現できないからだ。

小計が除いている費用を足す

エンドポイント料金はエンドポイントの分だ。その後トラフィックが触れるものにはそれぞれメーターがあり、楽観的な VPN 見積もりが崩れるのはそこだ。

  • エンドポイントから出るトラフィックのインターネット出口で、GB 単位で課金。
  • パブリック IPv4 アドレスで、VPN とは独立した時間課金がある。
  • いま出力した接続ログの CloudWatch Logs への取り込みと保存。
  • client-connect ハンドラーを動かす場合の Lambda 呼び出し。
  • ユーザーがそこで認証するなら Directory Service か SAML プロバイダー、そこで証明書を発行するなら ACM Private CA の料金。
  • 経路が使うときの NAT Gateway の時間とデータ処理、Transit Gateway の接続時間とデータ処理。

これらはいずれも関連付け数に比例しない。だからエンドポイント料金だけで組んだ一人あたりの数字は紙の上では良く見え、実際のトラフィックが出ると膨らむので、見積もるしかない場合でも別の行に置き、どこが実測でどこが推測かを読者に示す。

送る前にシートを確認する

四つの確認が私が実際に犯した誤りを捕まえる。関連付け数が Associations タブと完全に一致する、接続時間が人数ではなく対になったログイベントから来ている、リージョンと料金の日付が書かれている、副次費用のそれぞれに行がある——四つのどれかが欠けていれば、それは整形された推測だ。

まずログ出力を取る。後から記憶で再構成できない唯一の入力であり、最初の請求が来る前にアイドルセッションの問題を直す価値があるかも教えてくれる。

関連記事