AWS Cloud WAN

AWS Cloud WAN は、複数リージョンにまたがる VPC・データセンター・拠点・SD-WAN を、ひとつの論理的なグローバルネットワークとして構築・運用できるマネージドサービスです。接続やセグメント分離の設計をポリシーとして記述し、AWS が管理するグローバル網の上に宣言的に展開することで、リージョンごとに Transit Gateway を作り込み手作業でつなぎ合わせる運用の煩雑さを軽減します。

解決する課題

グローバルにまたがるネットワークを AWS 上で構成しようとすると、リージョンごとに Transit Gateway を作成し、それらをピアリングで相互接続し、各リージョンのルートテーブルやセグメント分離を個別に設計・維持する必要があります。リージョンや拠点が増えるほど構成要素と設定箇所が増え、全体像の把握とガバナンスの一貫性を保つのが難しくなります。

また、本番系と検証系、共有サービスといったセグメント分離のルールをリージョンをまたいで一貫させるには、各リージョンで同等の設定を漏れなく再現しなければならず、人手での運用は誤りを生みやすくなります。

Cloud WAN は、グローバルなコア網と中央のポリシーという抽象化を導入し、接続・セグメント・ルーティングの意図を 1 つのポリシー文書に集約します。これにより、広域ネットワークの設計を宣言的に記述し、AWS 側がリージョン間の実体を構成する形へと運用モデルを変えます。

主要概念と用語

• グローバルネットワーク: Cloud WAN と関連リソースをまとめて管理する最上位のコンテナ。Transit Gateway を含めたネットワーク全体の可視化の単位にもなる。
• コアネットワーク: グローバル網の実体。利用したいリージョンごとにエッジが配置され、その上に各種アタッチメントを接続して通信を成立させる。
• コアネットワークエッジ: コアネットワークを有効化した各リージョンにおける接続点。そのリージョンの VPC や VPN などをここへ接続する。
• コアネットワークポリシー: 利用するリージョン、セグメント、接続の受け入れ条件、ルーティングなどを宣言的に記述した中央の定義文書。バージョン管理され、変更は適用前にレビューできる。
• セグメント: ルーティングドメインに相当する論理的な区画。本番系と検証系の分離や共有サービスへの到達制御を表現するために使う。
• アタッチメント: コアネットワークに接続する対象を表す単位。VPC、Site-to-Site VPN、SD-WAN を接続する Connect、Transit Gateway ルートテーブルなどの種類がある。
• アタッチメントポリシー: アタッチメントをどのセグメントへ割り当てるかを、タグなどの条件に基づいて自動的に決めるルール。
• Network Manager: グローバルネットワーク全体のトポロジ、イベント、メトリクスを可視化するための管理・監視面。

仕様・制限・クォータ

Cloud WAN のコアネットワークはグローバルなリソースで、ポリシーで指定したリージョンごとにエッジが作られ、リージョン間はマネージド網で接続されます。利用者はリージョン間の物理的なピアリング配線を意識せず、ポリシー上でどのリージョンを有効化するかを宣言します。

コアネットワークに接続できるアタッチメント数、セグメント数、ポリシーのバージョン保持数、ルート数などにはアカウントやコアネットワーク単位のクォータが定められています。多くは Service Quotas から緩和申請できるものと、ハードリミットとして固定されるものがあるため、大規模設計時には最新のドキュメントで上限を確認してください。

ジャンボフレームの扱いや、アタッチメント単位の帯域上限など、下回るべき値が定義されている項目があります。想定するパケットサイズやスループットが対応範囲に収まるかを、設計段階で公式ドキュメントに照らして確認することが重要です。

内部の仕組み

Cloud WAN は、AWS が運用するグローバルなコア網と、その上で動作する中央ポリシーの 2 層で構成されます。コアネットワークポリシーを適用すると、ポリシーに記述されたリージョンにコアネットワークエッジが配置され、定義したセグメントとルーティングルールに従って各エッジ間の到達性が構成されます。

VPC や VPN などをアタッチメントとして接続すると、アタッチメントポリシーのルールに基づいて、そのアタッチメントがどのセグメントへ所属するかが決まります。セグメントは独立したルーティングドメインとして働き、同じセグメント内は到達可能、異なるセグメント間はポリシーで明示的に共有を許可しない限り分離されます。これにより、リージョンをまたいでも一貫したセグメント境界を保てます。

ポリシーはバージョン管理され、変更は新しいバージョンとして提案し、差分を確認してから実行に移します。意図したトポロジとルーティングを 1 つの宣言で表現するため、各リージョンに同等の設定を手作業で複製する必要がなく、構成の再現性とガバナンスが高まります。

設計パターン / ベストプラクティス

代表的な構成は、利用するリージョンをポリシーで有効化し、本番・検証・共有サービスといった用途ごとにセグメントを定義したうえで、各リージョンの VPC をアタッチメントポリシーのタグ条件で自動的に適切なセグメントへ割り当てるパターンです。タグ駆動にすることで、新しい VPC を追加しても手動のルート設定なしに正しいセグメントへ収まります。

共有サービス用のセグメントは、各業務セグメントから片方向に到達できるように共有設定を定義し、業務セグメント同士は分離したままにすることで、最小限の到達性を保ちます。インターネット出口や集中検査が必要なら、検査用 VPC を経由させる設計をポリシーとルーティングで表現します。

ポリシーは Infrastructure as Code として扱い、変更はレビューを経てから適用します。宣言的な構成は再現性が高い一方で、ポリシー 1 つの変更が広範囲に波及するため、影響範囲を理解したうえで段階的に反映することが安全です。

運用・監視

Cloud WAN は Network Manager のダッシュボードを通じて、グローバルネットワーク全体のトポロジ、アタッチメントやエッジの状態、ルーティングの様子を一元的に可視化します。リージョンや拠点をまたいだ構成を俯瞰できるため、どこに到達できてどこが分離されているかを把握しやすくなります。

メトリクスは Amazon CloudWatch に発行され、アタッチメント単位の通信量やエッジの状態を監視できます。構成変更や接続状態の変化はイベントとして記録され、これらをもとに異常の早期検知やトラブルシューティングを行います。ルーティングの問題切り分けには、ルートの確認機能や到達性の分析を組み合わせます。

ポリシーの変更履歴はバージョンとして残るため、いつ・どの版で到達性が変わったかを追跡できます。変更前にプレビューを確認し、適用後にダッシュボードとメトリクスで結果を検証する運用を定着させると、広域ネットワークの安定運用につながります。

コスト

Cloud WAN の課金は、コアネットワークエッジを有効化しているリージョンに対する継続的な課金と、アタッチメントの接続、処理したデータ量に対するデータ処理課金などの組み合わせで構成されます。リージョンを増やすほどエッジ分の固定的なコストが積み上がるため、本当に必要なリージョンだけを有効化するのが基本です。

少数のリージョンで限られた数の VPC をつなぐだけなら、Transit Gateway とピアリングを手組みする方が安価になることがあります。Cloud WAN が費用面でも見合うのは、リージョンや接続が増えて一元的なポリシー管理と可視化の価値が運用コストの削減に効いてくる規模です。リージョン間のデータ転送料も加わるため、トラフィック量を見積もって比較してください。具体的な単価は変動するため、最新の料金ページで確認することが前提です。

セキュリティ

Cloud WAN 自体はセキュリティグループを持たないため、アクセス制御は接続される各 VPC のセキュリティグループ、ネットワーク ACL、そしてセグメントによる論理分離の組み合わせで実現します。あるセグメントから別セグメントへの到達を遮断したい場合は、ポリシーで共有を許可しないことで分離を保ちます。

中央でのトラフィック検査が要件であれば、検査用 VPC を経由させてファイアウォールでフィルタリングする経路をポリシーで定義します。ポリシーの変更はネットワーク全体に波及しうるため、変更権限を IAM で厳格に絞り、適用前のレビューを必須にすることが重要です。アタッチメントやポリシーの変更はすべて AWS CloudTrail で記録し、いつ誰が到達性を変えたかを監査可能にしておきます。

関連サービス・比較

最も比較されるのは AWS Transit Gateway です。Transit Gateway はリージョン単位の中継ルータで、複数リージョンをまたぐにはピアリングを手作業で組み合わせます。Cloud WAN はその上に、複数リージョンを単一の論理網として束ねる中央ポリシーと可視化を加えた位置づけで、広域・マルチリージョンの一元管理に向きます。少数リージョンの単純な構成では Transit Gateway の方が簡潔な場合もあります。

ハンズオン / CLI例

以下は、グローバルネットワークとコアネットワークを作成し、コアネットワークポリシーをドキュメントから適用する最小の流れの例です。ポリシー JSON はリージョンやセグメントの定義を記述したファイルとして用意し、ID は実際の値に置き換えてください。

# グローバルネットワークを作成
aws networkmanager create-global-network \
  --description "global-net"

# コアネットワークを作成（上で得た global-network-id を指定）
aws networkmanager create-core-network \
  --global-network-id global-network-0123456789abcdef0 \
  --description "core-net"

# 用意したポリシー文書を新しいバージョンとして登録
aws networkmanager put-core-network-policy \
  --core-network-id core-network-0123456789abcdef0 \
  --policy-document file://core-network-policy.json

# 提案されたポリシーバージョンを実行して反映
aws networkmanager execute-core-network-change-set \
  --core-network-id core-network-0123456789abcdef0 \
  --policy-version-id 1