AWS Cloud WAN の紹介 (プレビュー)

2022 年 7 月 12 日更新: AWS Cloud WAN が一般利用可能になりました。

本日、AWSは新しいネットワークサービス「AWS Cloud WAN」のプレビューリリースを発表しました。Cloud WAN は、クラウドやオンプレミス環境で稼働するリソースを接続するグローバルネットワークの構築、管理、監視を容易にするマネージド広域ネットワーキング（WAN）サービスです。AWS は、クラウドネットワーキングのための強力かつシンプルなサービスを数多く提供しています。最も便利で中心的な機能の1つであるAmazon Virtual Private Cloud (VPC) について考えてみてください。また、AWS Transit Gateway は、AWS リージョン内でハブ＆スポークのネットワークトポロジーを構築することを可能にします。 Cloud WAN は、データセンター、支店、クラウドリソースを統合し、一元管理されたネットワークに接続する簡単な方法を提供し、グローバルネットワークの運用に伴う運用コストと複雑さを軽減します。

ここ数年、私たちはお客様のAWS ネットワークの使い方に変化が見られるようになりました。これまで以上に、お客様はインフラの複雑さを減らしてアプリケーションやその他のビジネス上の優先事項に集中できるようにしたいと考えており、ネットワークはグローバル拠点に広がっていて、お客様はこれを実現するために様々なテクノロジーを利用しています。しかし、このような要件の組み合わせを管理することの複雑さは、お客様の足を引っ張ることになります。Cloud WAN は、グローバルで AWS が管理し、VPN、SD-WAN（Software-Defined WAN）、固定回線など、AWS へのアクセス方法を選択できるため、私たちは Cloud WAN を提供できることを嬉しく思っています。

本ブログでは、Cloud WAN の主な使用例について説明します。開始方法を説明し、パブリックプレビューで利用できる主要な機能を見ていきます。

業界をリードするパートナー

Cloud WAN の立ち上げにあたり、業界をリードするパートナーと協力できることを大変嬉しく思っています。ユースケースに入る前に、彼らが行ってきたことや発言してきた素晴らしいことを取り上げておきたいと思います。

Aviatrix – blog post >>
Cisco Systems – announcement >>
Fortinet – blog post >>
Prosimo – quick start guide >>
VMware – blog post >>
Aruba – blog post >>
Alkira – blog post >>
Intercloud – blog post >>
DXC Technologies – blog post >>
Kyndryl – blog post >>
Ubyon- announcement >>

AWS Cloud WAN の主なユースケース

Cloud WAN は、AWS 内の接続、データセンターへの接続、支店への接続など、ブログシリーズ「Introduction to Network Transformation on AWS」で説明されているユースケースのいくつかに役立ちます。

Cloud WAN はネットワークを接続するだけでなく、ネットワークセグメントを定義し、それをグローバル WAN 全体に一貫して伝播することもできます。これは、一元的に定義されたポリシーと自動化を通じて行われます。

Cloud WAN は、複数のリージョンにまたがる VPC を構築しているお客様（ディザスタリカバリやマルチリージョンアプリケーションのため）、SD-WAN の AWS への拡張を検討しているお客様、既存のネットワークの一部を AWS のバックボーンで置き換えまたは増強したいお客様にとって良い選択です。

読者の方はもしかすると AWS Direct Connect SiteLink について聞いたことがあり、Cloud WAN とどのような関係があるのだろうかと思ったことがあるかもしれません。簡単な答えは互いに補完し合うということです。SiteLink では AWS リージョンをバイパスしながら Direct Connect のロケーション間でデータを送信することができます。これは、Cloud WAN ネットワークで使用できるいくつかの接続オプションの1つであり、多くのお客様が両方を使用したいと思うだろうと予想しています。

概要と主要な用語

開始方法を検討する前に、次の図でコアコンポーネントと関連する概念を確認しましょう (図 1)。

AWS Network Manager – AWS Management Console のユーザーインターフェイスと関連 API で、グローバルネットワークを一元的に管理します。
Global Network – ネットワークオブジェクトのルートレベルのコンテナとして機能する単一のプライベートネットワークです。グローバルネットワークには、Transit GatewayとCore Networkの両方を含めることができます。
コアネットワーク – AWS によって管理されるお客様のグローバルネットワークの一部です。
コアネットワークポリシー – コアネットワークのすべてを定義する、単一のバージョン管理されたポリシードキュメントです。
アタッチメント – コアネットワークに追加する接続やリソースです。サポートされているアタッチメントには、VPC、VPN、および接続アタッチメントが含まれます。
コアネットワークエッジ (CNE) – ポリシーで定義されたアタッチメントのリージョン接続ポイントです。Cloud WAN は、Transit Gateway に似た技術を使用しています。AWS によって管理されていますが違いがあります（ダイナミックルーティングがその一例です）。
ネットワークセグメント – デフォルトでセグメント内の通信のみを許可するルーティングドメインで、グローバルネットワーク全体で一貫しています。これらは強く強制されるレイヤー3ルーティングドメインです（ネットワークポリシーで共有関係を作成しない限り）。

図 1: AWS Cloud WAN コンポーネント

Cloud WAN により何ができるようになるのか

リージョン間 VPC ピアリングやリージョン間　Transit Gateway ピアリングなど、当社のネットワークサービスを利用したマルチリージョンアプリケーションの構築は数年前から可能であり、 Engie や Zendesk などのお客様がこのモデルを利用しています。Cloud WAN は、現在利用可能なものに加えて、さらにいくつかの次元を追加します：

単一の統合されたグローバルな制御ポイント：1 つのネットワークポリシーからネットワーク全体を設定でき、AWS はそのポリシーから設定情報を取得し、ネットワーク全体でそれを実現します。

より管理された独自のサービス：Cloud WAN はお客様に代わってネットワークの一部を構築します。お客様はコアネットワークポリシーで AWS リージョンを定義し、AWS はそれらのリージョン間のピアリングと動的ルーティングを処理します。フルメッシュの接続は、AWS マネジメントコンソールで数回クリックするだけで設定できます（あるいは JSON 形式で）。

ダッシュボード、モニタリング、イベントの一元化：Cloud WAN は、AWS Network Manager コンソールを使用して、物理および論理トポロジーの表示、中央ダッシュボード（独自の Transit Gateway を含む）、詳細なモニタリング、Amazon EventBridge による集中型イベントバスを提供します。

アタッチメントの自動化を内蔵：Transit Gateway では、独自のルーティング、伝搬、アタッチメントのルートテーブルへのマッピングを定義することができます。多くの場合、新しいルートテーブルやアタッチメントを追加すると、下流で十数回の変更が発生します。Cloud WAN では、アタッチメントのタグを使用して、アタッチメントを自動的にセグメントにマッピングし、ポリシーによってセグメント間の関係を定義することができます。

Cloud WAN は Transit Gateway に似た技術を使っています。AWS によって管理されていますが、異なる機能群（動的ルーティングなど）をもっており多少の違いはあります。しかし、長年にわたって開発し、Transit Gateway が可能にした統合やルーティングパターンをそのまま利用することができます。これには接続アタッチメントタイプによる SD-WAN ベンダーとの統合、ファイアウォールの挿入パターン、ingress/egress のインターネットアクセスの一元化などがあります。

はじめに

AWS Network Manager は、AWS とオンプレミスにまたがる Cloud WAN コアネットワークと　Transit Gateway を一元的に管理することができます。Network Manager は、グローバルなコンソール UI から利用できます。以下がスクリーンショットです。（図2）。

図 2: AWS Network Manager コンソール

通信サービスプロバイダーを利用し、オンプレミス環境と AWS を接続します。この接続は、お客様のデータセンターまたはコロケーション施設と AWS ネットワークとの間のギャップを埋めるもので、既存の WAN ネットワークをクラウドに拡張するものです。

Cloud WAN を始めるには、まずグローバルネットワークと、すべての基本的なコンポーネントを起動するためのコアネットワークを作成します。こちらのドキュメントの「Getting Started with AWS Cloud WAN」セクションのステップも参考になります。プロセスの概要は、次の図に示されています（図3）。グローバルネットワークは、ネットワークおよび接続管理専用の AWS アカウント内に作成することをお勧めします。

まず、ネットワークに名前を付け、CNE を作成するリージョンを選択し、デフォルトのネットワークセグメントの名称を選択します。また、コアネットワーク作成ウィザードを使用する際には、AS 番号（ASN）の範囲も指定します。Cloud WAN は、提供された範囲から各 CNE に ASN を自動的に割り当てます。きめ細かい割り当てが必要な場合は、ネットワークポリシー内で各 CNE にASN を明示的に定義することができます。

図 3: グローバルネットワークの高レベルの作成手順

コアネットワークを作成したら、AWS コンソールで詳細、トポロジ、ポリシーとアタッチメントに関する情報を確認できます。以下がスクリーンショットです。 (図 4)。

図 4: コアネットワークの概要

アタッチメントとコアネットワークの共有

コアネットワークを作成した次のステップは、クラウド・リソースとオンプレミス・ネットワークをアタッチすることです。次のスクリーンショット（図5）に示すように、アタッチメントを作成することで実行します。なお、Cloud WAN プレビューでは最初は VPC、VPN、接続のアタッチメントをサポートしています。

図5：AWS Cloud WAN アタッチメントの作成

アタッチメントの作成で重要なのは、タグ付けです。Cloud WAN は、アタッチメントのタグを使用して、アタッチメントポリシーで定義された希望するセグメントにアタッチメントを自動的に関連付けることができます。アタッチメントをセグメントにマッピングするには、リソース（vpc-idなど）を明示的にセグメントにマッピングする方法と、アタッチメントのタグを使用する方法の2つを選択することができます。

コアネットワークの接続を完了するために、VPC のルーティングテーブルをコアネットワーク接続対象 WAN に対応するプレフィックスで更新します。図6にその画面を示しますが、コアネットワークの接続先には完全な ARN が使用されていることに注意してください。

図6：コアネットワークのアタッチメントをターゲットとしたプレフィックスで変更した VPC ルートテーブル

VPC の多くは、AWS Organizations の一部として異なる AWS アカウントに配置されていると思われます。それらをアタッチするにはスクリーンショット図7のように、まず AWS Resource Access Manager (RAM) でコアネットワークを共有する必要があります。実際、コアネットワークは RAM 内で共有できる最初のグローバルリソースです。追加の作業として、他のすべてのリージョンがグローバルリソースを見ることができるようにするため、バージニア北部（us-east-1）リージョンからグローバルリソースを共有する必要があります。コアネットワークを所有する同じ AWS アカウント内で VPN と接続のアタッチメントを作成する必要があります。コアネットワークは、AWS Organizations および組織単位(OU)で共有できます。また、特定の AWS アカウント ID（AWS Organizations の外にある可能性がある）と明示的に共有することができます。

図 7: コアネットワークの共有

コアネットワークを共有する各 AWS アカウントは、標準の AWS RAM 共有モデルに従って、共有の招待を受け入れる必要があります。これを図 8 に示します (グローバルオブジェクトであるため、これもバージニア北部にあります)。

図 8: コアネットワークリソース共有の招待を受け入れる

ネットワークポリシーと変更セット

この時点で、AWS 環境全体で共有される基本的なコアネットワークができ、いくつかのアタッチメントが作成されています。ここでコアネットワークの変更を開始し、アタッチメントポリシーなどの自動化ルールを定義することができます。まず、コアネットワークポリシーについて見てみましょう。

コアネットワークポリシー、または単にポリシーは、コアネットワーク構成のすべての側面を定義します。ポリシーは JSON テンプレートとして表現され、AWS Console の JSON エディタ、GUI インターフェースを使用して変更したり、API コールで供給したりすることができます。以下は、「mynetwork」という単一のセグメントを作成し、単一の AWS リージョン（us-east-1）内に CNE を作成するシンプルなポリシーです。注：JSON はコメントをサポートしていませんので、テンプレートを独自の構成にコピーしようとする前に、コメントを削除してください。

{ 
  "version": "2021.12",                # Required Policy document version 
  "core-network-configuration": {      # Required Core network definition section 
      "asn-ranges": ["65500-65510"],   # Required ASNs automatically assigned to CNEs 
      "edge-locations": [              # Required Array of CNEs 
          {"location": "us-east-1"}    # Single CNE defined 
      ] 
  }, 
  "segments": [                        # Required Array of segments 
      {"name": "mynetwork"}            # Single segment defined 
  ] 
}

先のポリシーは、作成できる最もシンプルなコアネットワークです。AWS Console のコアネットワーク作成ウィザードで同等のものを作成することができます。ポリシーのバージョン ID は「1」に設定され、自動的に適用されます。(次の図 9 を参照）

図9：コアネットワークを記述した初期ポリシーが作成され適用されている様子

AWS Cloud WAN のライフサイクルを示すために、このダイアグラム（図10）のトポロジーを考えてみましょう。

図10：2つのセグメントを持つコアネットワークとリソースタグに基づくアタッチメントポリシー

トポロジーの変更の一部として、セグメントの変更、新しいリージョン、およびアタッチメントタグに基づく新しいアタッチメントポリシーが存在します。「Untrusted」セグメントでは、アタッチメントを自動的に受け入れることができます（デフォルトでは、各アタッチメントを手動で受け入れる必要があります）。初期ポリシー（バージョン1）を変更し、以下のように JSON テンプレートを追加/変更することができます。

{
    "version": "2021.12",
    "core-network-configuration": {
        "asn-ranges": ["65500-65510"],
        "edge-locations": [
            {"location": "us-east-1"},
            {"location": "us-west-1"},             # Added CNE
            {"location": "eu-west-1"}              # Added CNE
        ]
    },
    "segments": [                               
        {"name": "Trusted"},                       # Renamed segment
        {
        "name": "Untrusted",                       # Added new segment
        "require-attachment-acceptance": false     # Added automatically accept attachments into untrusted
        }                      
    ],
    "attachment-policies": [                       # Added automation policies to associate attachments based on attachment tags
        {
        "rule-number": 100,
        "conditions": [{
            "type": "tag-value",
             "key": "segment",
            "value": "Trusted",
            "operator": "equals"
            }],
            "action": {
            "association-method": "constant",
            "segment": "Trusted"
            }
        },
        {
            "rule-number": 200,
            "conditions": [{
                "type": "tag-value",
                "key": "segment",
                "value": "Untrusted",
                "operator": "equals"
        }],
        "action": {
            "association-method": "constant",
            "segment": "Untrusted"
            }
        }
    ]
}

コアネットワークに変更を加えると、ポリシーの新バージョンが作成されます。この例ではバージョン2と呼んでいます。バージョンを選択し、「表示」または「変更セットを適用」をクリックし、新しい値を調べることで、管理された方法で変更セットを適用することができます（図11）。

図 11: 適用前の新しい値を示す変更セット

変更の適用には、1CNE あたり 20 分程度かかります。この時間は変更の複雑さによって異なります。例えば、新しい CNE はすべての CNE で完全なメッシュ接続を確立し経路の交換を開始する必要があるためより長い時間がかかります。新しい CNE など、新しいネットワークが追加された場合、コアネットワークは VPC のルートテーブルを更新しないことに留意してください。必要に応じて、コアネットワークに向けた VPC レベルのスタティックルートを更新する必要があります。また、古いバージョンのポリシーはすべて削除せず最近のものを残しておくと、必要に応じてロールバックに使用することができます。ロールバックするには利用可能なバージョンのいずれかを選択し、復元を選択またはクリックします。この操作により新しい変更セットが作成され、他の新しいポリシーのバージョンと同じように調べて適用することができます（図12）。

図12：復元されたポリシー変更セットの準備完了

Cloud WAN が不要になった場合は、まずアタッチメントを削除し、それが終わったらコアネットワークを削除することでクリーンアップできます。

トポロジー

時間の経過とともに要件が変化し、AWS の新しい機能が導入されると、ポリシーに制御された変更を加え続けることができます。例えば、次の図（図13）に示すように、Cloud WAN をオンプレミスに拡張しセグメント間にインスペクションポイントも導入したい場合があります。

図 13: セグメント間のトラフィック検査とサイト間 VPN によるハイブリッド接続

この例では、セグメント間のルーティング動作を定義するセグメントアクションを使用します。インスペクション用 VPC のアタッチメントに向かう静的ルートを作成できます。また、異なるセグメントのアタッチメントが通信できるように共有を定義することもできます。デフォルトでは、アタッチメントは同じセグメント内でしか通信できませんが、アタッチメント同士の通信を遮断することも可能です。このほかにも、さまざまなトポロジーの例や対応するポリシーの例が「Cloud WAN Policy Examples」のドキュメントに記載されています。

上記の例では、すべてのリージョンに VPN およびインスペクション用 VPC アタッチメントを配置することをお勧めします。ローカル接続がない場合、別のリージョンからの静的ルートはリージョン間ピアリング接続を通じて動的に伝播します。

知っておくべきこと

パブリックプレビュー期間中は、Cloud WAN を本番用ユースケースとして推奨しません。
CNE は、例えば VPC アタッチメントあたり 50Gbps のスループットなど、多くの Transit Gateway の特徴を引き継いでいます。より高いスループットが必要な場合は、AWS サポートにお問合わせください。
各 CNE には時間単位のコストがかかるため、必要な AWS リージョンでのみ CNE を有効にしてください。
Cloud WAN の価格詳細については、こちらをご覧ください。
Cloud WAN のクォータは、ドキュメントに記載されています。
Cloud WAN は、IPv4 と IPv6 の両方をサポートしています。
VPC からコアネットワークへのアクセスをより厳密に制御したい場合、アタッチメントを専用のサブネットに置くことができます。VPC アタッチメントを作成する前に、コアネットワークのアタッチメント用に AZ ごとに /28 サブネットを作成します。コアネットワークアタッチメント用のサブネットに関連するインバウンドおよびアウトバウンドネットワーク ACL をオープンにしておいてください。
Route 53 Resolver は、他の VPC からコアネットワークアタッチメント上のプライベート IP DNS ベースの名前を解決しません。
任意で接続アタッチメント（SD-WAN と CNE でピアリングされた仮想ルーター）のために CNE が使用する内部 CIDR ブロックを定義できます。各 CNE は /24 を使用するので、将来の成長のために十分な大きさのスーパーネットを割り当ててください。例として、コアネットワークに 16 台の CNE がある場合は、/20 で十分です。
AWS Transit Gateway と AWS Direct Connect のアタッチメントタイプは、パブリックプレビューではサポートされていませんが、計画されています。多くの変更を伴う大規模なネットワークでは、変更を検証できる別の開発およびテスト用グローバルネットワークを作成することを検討してください。

クリーンアップ

プレビュー終了後の不要な課金を避けるため、テスト中に作成されたリソースの削除をお願いします。まず、各種アタッチメントを削除し、対応するリソースを削除してください。コアネットワークの共有を停止するため、RAM リソース共有を削除してください。最後にコアネットワークそのものを削除し、親となるグローバルネットワークも削除してください。

まとめ

このブログ記事では AWS Cloud WAN を紹介しました。これは、クラウドとオンプレミスの環境で稼働するリソースを接続する統合グローバルネットワークを簡単に構築、管理、監視することができるマネージドな広域通信網（WAN）サービスです。支店、データセンター、Amazon VPC への接続に使用する接続を、わずか数クリックで AWS グローバルネットワークにアタッチするための中央ダッシュボードを提供します。シンプルなネットワークポリシーを使用して、ネットワーク管理およびセキュリティタスクを集中的に構成および自動化し、グローバルネットワークの全体像を把握することができます。Cloud WAN は、以下の AWS リージョンで本日よりパブリックプレビューを開始します：米国東部（北バージニア）、米国西部（北カリフォルニア）、アフリカ（ケープタウン）、アジア太平洋（ムンバイ）、アジア太平洋（シンガポール）、アジア太平洋（シドニー）、アジア太平洋（東京）、ヨーロッパ（アイルランド）、ヨーロッパ（フランクフルト）。Cloud WAN の詳細については、ドキュメントおよび FAQ ページをご覧ください。

この記事は「Introducing AWS Cloud WAN (Preview)」の日本語訳です。
プロフェッショナルサービス本部インフラストラクチャアーキテクトの大木和田留、大谷真広が翻訳しました。

Amazon Web Services ブログ