Summary

  • AWS Organizations内でVPCのサブネットを共有すると、参加アカウントは自分のEC2、RDSなどのアプリ資源を配置でき、その費用と指定されたデータ転送料金を支払う。
  • VPC所有者には共有VPC内のパブリックIPv4の料金と、NATゲートウェイ、PrivateLink、エンドポイントなどの該当する料金が付く。共有を停止しても参加者の既存資源は動き続け、撤去されるまで所有者はサブネットやVPCを削除できない。

「誰のサーバーか」だけでは請求先を決められない

会社がネットワークを一元管理し、各事業部は別々のAWSアカウントでサービスを運用する。共有VPCはそのための仕組みだ。AWSの説明では、参加者は共有サブネットにEC2インスタンス、RDSデータベース、Redshiftクラスター、Lambda関数などを置ける。これらのアプリ資源の費用は参加者のものになる。ところが同じ共有VPCで使うパブリックIPv4アドレスは、VPC所有者の請求対象だ。運用者と住所の支払人が別になる。

通信費も一括ではない。AWSは参加者が負担するものとして、アベイラビリティーゾーン間、VPCピアリング、インターネットゲートウェイ、Direct Connectゲートウェイを通るデータ転送を挙げる。所有者側にはNATゲートウェイ、仮想プライベートゲートウェイ、トランジットゲートウェイ、PrivateLink、VPCエンドポイントをめぐる該当する時間・処理・転送料金が付く。一つのアプリの通信経路が、二つのアカウントに別々の費目を残す。利用者のEC2代だけを見て「このサービスのネットワークは安い」と言えば、請求書の片面しか見ていない。

同一アベイラビリティーゾーン内の転送は、AWSがAZ IDで区別する範囲ならアカウントの所有者が違っても無料だ。この条件は、通信量だけでなく経路を監視する理由になる。別のゾーンにまたがる設計へ変われば、サーバー台数を増やさなくても転送費の見え方が変わり得る。どの費目が実際に発生したかは、両アカウントの利用記録と配置を照らす必要がある。

鍵を握る側の支払い

ネットワーク操作の権限も所有者に寄っている。サブネット、ルートテーブル、NATゲートウェイ、エンドポイントを作り管理するのはVPC所有者。参加者は自分のネットワークインターフェースやセキュリティーグループを扱えるが、共有サブネット内のNATゲートウェイを作成、削除、さらには記述することもできない。中央チームがゲートウェイを選び、その費用も受け取る設計は筋が通る。しかし参加者のアプリがその経路を多用するなら、利用の動機と支払いの痛みは一致しない。

パブリックIPv4はこのずれを数字にする。AWSの通常のVPC価格表は、使用中・未使用のパブリックIPv4を1アドレス1時間あたり0.005米ドルとし、秒単位、最低60秒で計算する。共有VPCの料金説明は、そこで使うアドレスを所有者負担とする。公開資料に特定企業のアドレス数や実際の請求額はない。誰のアプリが何個使うかを所有者の請求明細と突き合わせて初めて、社内の負担割合が見える。

共有解除は退去通知であって、更地ではない

所有者はサブネットの共有を止められる。止めた後、参加者は新しい資源を置けなくなる一方、既存の資源は稼働を続け、参加者はそれを変更・削除できる。参加者の資源が残る限り、所有者は当該サブネットやVPCを削除できない。ネットワークの持ち主だから即日撤去できる、という想像はAWSの運用規則と合わない。

共有VPCはネットワーク管理の集約に役立つ。同時に、サーバー代、転送代、IPv4代、ゲートウェイ代を別々の支払人へ配る。招き入れる前に、どの利用量を誰が示し、住所と共用設備をどう社内精算し、撤収時に誰が資源を片づけるか決めるべきだ。決めないまま始めれば、両チームがそれぞれ正しい請求書を振りかざす。

出典