Service Insertion を使用した AWS Cloud WAN マルチリージョンインスペクションへの移行

本記事は 2024年9月11日に公開された ”Migration to AWS Cloud WAN multi-Region inspection using service insertion” を翻訳したものです。

はじめに

AWS Cloud WAN はリリース以来、多くのお客様から関心を集め、数々の機能強化が行われてきました。2024年6月11日に発表された機能である Service Insertion は、一元化されたポリシー設定を使用して AWS およびサードパーティのネットワークおよびセキュリティサービスを AWS Cloud WAN に簡単に組み込むことができる新機能です。この機能を使用すれば、シンプルなポリシーステートメントを定義するか、UI で数回の操作を行うだけで、VPC 間、VPC とオンプレミス間、またはインターネットへのトラフィックをネットワークやセキュリティアプライアンスを経由するように簡単にルーティングできます。Service Insertion の詳細については、「Simplify global security inspection with AWS Cloud WAN Service Insertion」で説明されています。
現在、ほとんどのお客様は、各リージョンに集中型インスペクションを配置したマルチリージョン構成を採用しています。この記事では、以下の移行を段階的に行う方法ついて解説いたします。：

Transit Gatewayで構成された集中型セキュリティインスペクションから、移行中の接続性を維持しダウンタイムを最小限に抑えた Service Insertion を使用した AWS Cloud WAN への移行。
Service Insertion を使用していない AWS Cloud WAN の構成から、Service Insertion を使用した構成への移行。

AWS Transit Gateway は、Amazon Web Services (AWS) のネットワーキングソリューションにおいて不可欠な存在であり、Virtual Private Cloud (VPC)、Virtual Private Network (VPN)、およびオンプレミスネットワーク間をスケーラブルかつ効率的に接続します。この記事は、ポリシーベースの管理、ワンクリックでのセグメンテーション、AWS ネイティブな自動化などの AWS Cloud WAN の特定の機能を利用したいと考えているお客様を対象としています。本記事では、AWS の環境内でこれらの機能を採用する際の洞察や考慮点を解説します。読者の皆様には、意思決定の前に、自社のネットワークへのニーズを評価し、利用可能なオプションを検討することをお勧めします。

ソリューション概要

AWS Cloud WAN Service Insertion は、ファイアウォールなどのネットワークサービスを通信経路に挿入する際の複雑さを解消します。これは、シンプルなインテントベースのポリシーステートメントを設定するか、UI で数回のクリックを行うことで、トラフィックをインスペクション VPC にリダイレクトすることが可能です。
この機能では、インスペクション VPC アタッチメントを統合的に管理する Network Function Group (NFG) と呼ばれる新しい構成要素が導入されています。NFG は、ポリシーで定義された管理者の意図に基づいて、通信を目的のファイアウォールへリダイレクトするように制御します。これには、セグメント間およびセグメント内、VPC 間、リージョン間、オンプレミスと VPC 間、さらに VPC またはオンプレミスからインターネットへのトラフィックが含まれます。Service Insertion を使用することで、NFG と経路伝播が自動管理されるため各リージョンのインスペクションセグメントの設定やトラフィックリダイレクト用のスタティックルートの設定を管理する複雑さが解消されます。
Service Insertion の使用に対する追加料金は発生せず、通常の AWS Cloud WAN の料金のみが適用されます。

前提条件

以下のセクションでは、AWS の基本的なネットワーク構成要素（Amazon VPC、AWS Transit Gateway、AWS Cloud WAN、AWS Network Firewall）について理解していることを前提としています。
初期構成及び各サービスのデプロイ手順の詳細には焦点を当てず、以下の構成をテスト環境にデプロイしていることを前提とします。そのため、初期構成として以下のサービスの事前デプロイが必要です。：

シナリオ1：ワークロード用 VPC、AWS Network Firewall を含むインスペクション VPC、AWS Transit Gateway、および関連するルートテーブル、アタッチメント、ピアリングをデプロイして下さい。
シナリオ2：ワークロード用 VPC、AWS Network Firewall を含むインスペクション VPC、Service Insertion を含まない AWS Cloud WAN、および関連するセグメント、アタッチメント、ルーティングをデプロイして下さい。

移行のユースケース

シナリオ1：Transit Gateway から Service Insertion を含む AWS Cloud WAN への移行

このシナリオでは、Transit Gateway と集中型インスペクションをベースとするアーキテクチャから、Service Insertion を利用する AWS Cloud WAN への移行について解説します。

現状構成（AWS Cloud WAN を使用していない）

マルチリージョン環境において、一般的に採用されるアーキテクチャは、各リージョンにデプロイしたTransit Gatewayをピアリングアタッチメントで相互接続し、それぞれ集中型インスペクションを行う構成です。アーキテクチャは実績が豊富であり、動作が予測し易く、必要に応じてトラフィックをインスペクション VPC にリダイレクトできる利点があります。これはリージョン間トラフィックにおいて、ピアリング接続を経由するトラフィックは、セグメンテーションポリシーに準拠している場合のみファイアウォールで許可されます。ただし、このアーキテクチャでは多数のスタティックルートの管理が必要であり、多くの場合、二重のインスペクションにより追加コストが発生します。
アーキテクチャ図1は、2つのリージョンと、セグメント化された2つのワークロードを示しています。例として、本番環境と非本番環境のワークロードを使用していますが、他の種類のセグメンテーションでも問題ありません。これは多くのお客様が採用している構成のため、本記事ではこれを初期構成として使用します。

図1: Transit Gateway とセキュリティインスペクションを使用したマルチリージョン環境

フェーズ1: AWS Cloud WAN のデプロイと Transit Gateway ピアリングの確立

図2に示すように、最初のステップとして両方のリージョンに AWS Cloud WAN のコアネットワークをデプロイし、各リージョンの Transit Gateway とのピアリングを作成します。

図2: Transit Gateway ピアリングを使用した AWS Cloud WAN のデプロイ

「Deploying hybrid networks using AWS Cloud WAN and AWS Direct Connect」および「Achieving traffic segmentation in multi-AWS Region environments using AWS Transit Gateway and AWS Cloud WAN」では、フェーズ1（図2）に示されている設定の詳細について解説しています。
次のフェーズに進むにはポリシーの変更を適用する必要があります。ただし、この段階ではまだセグメント、アタッチメント、またはルーティングを設定していないため、既存のルーティングに変更はありません。リージョン間の通信は引き続き Transit Gateway のピアリングを経由します。

フェーズ2: セグメントの構成と Transit Gateway ルートテーブルアタッチメントの作成

次のステップは、2つのリージョンの Transit Gateway に構成された本番環境と非本番環境のルートテーブルを、AWS Cloud WAN 上に拡張することです。これにより、各リージョン内で定義されたセグメンテーションをコアネットワーク全体に拡張できます。この結果、リージョン間のセグメンテーションを維持するためにファイアウォールを通過させる必要がなくなります。ホップ数が減少することでパフォーマンスが向上し、同一セグメント内のトラフィックに関連するインスペクションと処理の料金も削減できます。
これを実現するには、AWS Cloud WAN でセグメントを作成し、両方のリージョンで関連するルートテーブルアタッチメントを設定する必要があります。この構成の詳細については、フェーズ1で紹介したブログ記事で解説されているため、本記事では解説しません。

図3: コアネットワーク全体への本番環境と非本番環境のセグメントの拡張

us-east-1 の Transit Gateway 上の本番環境のルートテーブルは、現在コアネットワーク経由で eu-west-2 の本番環境 VPC の経路を学習しており、その逆も同様です。これらは図3のルートテーブルで赤色で示されています。非本番環境のルートテーブルについても同様です。
これは、図3の紫色の矢印で示すように、us-east-1 の本番環境 VPC から eu-west-2 の本番環境 VPC へのトラフィックが AWS Cloud WAN を経由することを意味します。これは、Transit Gateway のルートテーブルがより詳細な経路を学習した為であり、この経路は直接接続されていない VPC へのトラフィックをインスペクション VPC を経由するように初期設定したデフォルトルートよりも優先されます。
デフォルトルートの代わりにより詳細なスタティックルートを設定していた場合は、トラフィックを AWS Cloud WAN 経由で送信するためにこれらを削除する必要があります。これは、同じプレフィックスの場合、スタティックルートが動的に学習された経路よりも優先されるためです。非対称ルーティングを避けるため、両方のリージョンでルーティングを調整する必要があります。詳細については、Transit Gateway ドキュメントのルート評価のセクションを参照してください。
ただし、現時点では本番環境と非本番環境のワークロード間のトラフィックは引き続きデフォルトルートに一致します。リージョン間トラフィックについては、Transit Gateway に接続されたインスペクション VPC を経由し、Transit Gateway 間のピアリングを経由して転送されます。
以下は、本番環境と非本番環境の Transit Gateway ルートテーブルおよび VPC アタッチメントを、それぞれのAWS Cloud WAN セグメントに関連付けるために必要なコアネットワークポリシー設定の例です：

Core networkコアネットワークポリシー

  "segments": [
    {
      "name": "Production",
      "Isolated": "False"
    },
    {
      "name": "Non-Production",
      "Isolated": "False"
    }
  ],
  "attachment-policies": [
    {
      "rule-number": 100,
      "description": "Production VPCs",
      "conditions": [
        {
          "type": "tag-exists",
          "key": "Segment",
          "operator": "equal-to",
          "value": "Production"
        }
      ],
      "action": {
        "add-to-segment": "Production"
      }
    },
    {
      "rule-number": 200,
      "description": "Non-Production VPCs",
      "conditions": [
        {
          "type": "tag-exists",
          "key": "Segment",
          "operator": "equal-to",
          "value": "NonProduction"
        }
      ],
      "action": {
        "add-to-segment": "NonProduction"
      }
    }
  ]

Transit Gateway ルートテーブルアタッチメントの設定

本番環境と非本番環境の両方のルートテーブルに対して、Transit Gateway ルートテーブルアタッチメントを設定します。図4は、us-east-1 の本番環境ルートテーブルに対する設定方法を示しています。残りのルートテーブルについても同様の設定を行ってください。アタッチメントのタグがコアネットワークポリシーで定義されたアタッチメントポリシーと一致することを確認してください。
アタッチメントを設定する前に、まずポリシーの変更を適用する必要があります。これによって既存のルーティングが変更されることはありません。ただし、アタッチメントを作成すると、新しい経路が伝播され、上記で解説したようにルートが変更されます。

図4：Transit Gateway ルートテーブルアタッチメントの設定

フェーズ3：NFG の設定とインスペクション VPC のアタッチ

この段階では、AWS Cloud WAN で NFG を設定し、アタッチメントポリシーを使用して2つの新しいインスペクション VPC を NFG に追加します（図5）。ファイアウォールアプライアンス（図示されている AWS Network Firewall）の設定はこの記事の範囲外です。詳細については、ドキュメントの「Getting started with AWS Network Firewall」を参照してください。

図5：NFG の設定とインスペクション VPC のアタッチ

2つの新しいインスペクション VPC をデプロイする理由は、インスペクションを経由するセグメント間の通信を Transit Gateway から AWS Cloud WAN に移行する際にダウンタイムを最小限に抑えるためです。また、移行中は既存構成をそのまま残しておき、必要に応じてロールバックできるようにします。すべての VPC を AWS Cloud WAN に正常に移行した後は、AWS Cloud WAN 内のインスペクション VPC のみ残します。
NFG の作成とインスペクション VPC 用のアタッチメントポリシーの設定例を、以下の JSON ポリシーに示します：

Core network policy

  "network-functions-group": [
    {
      "name": "InspectionVpcs",
      "require-attachment-acceptance": false
    }
  ],
  "attachment-policies": [
    {
      "rule-number": 500,
      "description": "Service Insertion Inspection VPCs",
      "conditions": [
        {
          "type": "tag-exists",
          "key": "Network-Function-Group",
          "operator": "equal-to",
          "value": "InspectionVpcs"
        }
      ],
      "action": {
        "add-to-network-functions-group": "InspectionVpcs"
      }
    }
  ]

インスペクション VPC アタッチメントの設定

図6に示すように、us-east-1 と eu-west-1 リージョンの両方のインスペクション VPC を NFG にアタッチするよう設定します。アタッチメントのタグがコアネットワークポリシーで定義されたアタッチメントポリシーと一致することを確認し、Appliance mode support が選択されていることを確認してください。
アタッチメントを設定する前に、まずポリシーの変更を適用する必要があります。アタッチメントを設定した後もこの段階ではルーティングは変更されません。

図6：NFG へのインスペクション VPC アタッチメントの設定

フェーズ4：リージョン間インスペクションを AWS Cloud WAN に移行

このフェーズでは、リージョン間のセグメント間トラフィックを AWS Cloud WAN 上の NFG を通るように転送します。図7のルートテーブルと紫色の矢印で示されているように、Service Insertion が新しいインスペクション VPC を通してトラフィックを送信します。
デフォルトでは、Service Insertion はリージョン間のすべてのトラフィックに対して単一のインスペクションポイントを選択します。この場合、デフォルトで選択されるインスペクション VPC は us-east-1 です（各リージョンペアに対してインスペクション VPC を指定することも可能です）。もう一方は、バックアップとして使用されます。単一のインスペクションポイントを使用することで、パフォーマンスが向上し、従来のデプロイメントで通常実装されていた二重インスペクションの必要性を排除することで、インスペクションと AWS Cloud WAN 処理の両方に関連するコストをさらに削減できます。

図7：Service Insertion を使用したリージョン間インスペクションの AWS Cloud WAN への移行

本番環境と非本番環境のセグメント間にインスペクションを挿入

Service Insertion を使用して、本番環境と非本番環境のセグメント間のトラフィックの通信経路にインスペクションポイントを挿入します。これは、以下の例に示すように、ポリシーに send-via ステートメントを追加することで実現できます。send via セグメントアクションの詳細については、AWS Cloud WANのドキュメントを参照してください。

{
    "segment-actions": [
        {
            "action": "send-via",
            "segment": "Production",
            "when-sent-to": {
                "segments": [
                    "Non-Production"
                ]
            },
            "via": {
                "network-function-group": [
                    "InspectionVpcs"
                ]
            }
        }
    ]
}

本番環境と非本番環境のセグメント間の双方向の通信を検査するには、単一の send-via セグメントアクションで十分です。非本番環境セグメントから本番環境へ向かうトラフィックに対して別のステートメントを設定する必要はありません。
図7の Transit Gateway ルートテーブルを確認し、赤で示された経路のように、本番環境のルートテーブルでコアネットワークから他のリージョンの非本番環境 VPC への経路を学習していることがわかります。同様に、非本番環境のルートテーブルも、他のリージョンの本番環境 VPC への経路をコアネットワークから学習しています。これは、Service Insertion と NFG セグメントが、先ほど定義したセグメントアクションの send-via ポリシーに基づいて、これらの経路を動的に伝播しているためです。
これらの経路は、初期構築で設定したリージョン間トラフィックを Transit Gateway にアタッチされたインスペクション VPC に送信するスタティックルートを上書きし、代わりに NFG にアタッチされたインスペクション VPC にトラフィックを送信します。ただし、同一リージョン内では、本番環境と非本番環境の VPC 間のトラフィックは、次のフェーズで解説するように、一方または両方のワークロード用 VPC が AWS Cloud WAN に移行されるまで、引き続き Transit Gateway にアタッチされたインスペクション VPC を経由します。
この段階でポリシーの変更を適用する必要があります。変更が適用されると、ルーティングの再収束と新しい経路の伝播が発生し、一部の通信において短時間中断する可能性があります。したがって、中断を最小限に抑えてスムーズに移行するために、これらの設定をスケジュールされたメンテナンスウィンドウ中に適用することがベストプラクティスです。

フェーズ5：VPC を Transit Gateway から AWS Cloud WAN に移行

この段階では、すべてのリージョン間トラフィックが AWS Cloud WAN 上を通過し、セグメント間のトラフィックの場合は NFG にアタッチされたインスペクション VPC を経由してルーティングされます。ここで、本番環境と非本番環境の VPC を Transit Gateway から AWS Cloud WAN の対応するセグメントに移行を開始します。万が一の設定ミスで多くのVPCに影響を与えるリスクを最小限に抑えるために、この移行は段階的に行うことを推奨します。
VPC を Transit Gateway から AWS Cloud WAN に移行する方法の詳細については、「AWS Cloud WAN and AWS Transit Gateway migration and interoperability patterns」で解説されています。
図8は、非本番環境 VPC を Transit Gateway から AWS Cloud WAN へ移行し、更新されたルートテーブルと通信フローを示しています。

図8：VPC を AWS Transit Gateway から AWS Cloud WAN に移行

非本番環境 VPC が Transit Gateway から AWS Cloud WAN に移行されると、非本番環境セグメントはそれらの Classless Inter-Domain Routing（CIDR）を学習します。また、フェーズ2で設定したアタッチメントを通じて、これらの CIDR を Transit Gateway 上の非本番環境ルートテーブルに動的に伝播します。これにより、移行された VPC とまだ Transit Gateway 上にある VPC 間の到達可能性を維持しながら、段階的な移行が可能になります。
同様に、これらの経路は Service Insertion と NFG を介して AWS Cloud WAN 上の本番環境セグメントと Transit Gateway 上の本番環境ルートテーブルにも動的に伝播されます。Transit Gateway 上の本番環境ルートテーブルは、AWS Cloud WAN から学習した非本番環境 VPC 向けのより具体的な経路を持つようになるため、Transit Gateway にアタッチされたインスペクション VPC を指すデフォルトルートよりもこちらを優先します。したがって、トラフィックは AWS Cloud WAN を通じて NFG とそれにアタッチされたインスペクション VPC を経由し、非本番環境 VPC にルーティングされます。これは図8の青い矢印で示されており、紫の矢印はリージョン間のセグメント間通信を示しています。
VPC を Transit Gateway から AWS Cloud WAN に移行すると、ルーティングの再収束と新しい経路の伝播が必要となり、一部の通信が短時間中断する可能性があります。したがって、ここでも、中断を最小限に抑えてスムーズに移行するために、これらの設定をスケジュールされたメンテナンスウィンドウ中に適用することがベストプラクティスです。

フェーズ6：移行の完了

すべてのワークロード用 VPC が移行され、すべてのテストが正常に完了したら、図9の最終状態アーキテクチャに示されているように、古いインスペクション VPC と Transit Gateway を安全に削除できます。なお、NFG ルートテーブルはマネージドであり、Service Insertion ポリシーに基づいて自動的に経路設定されます。これらの経路は表示できますが、経路を追加、削除、または共有することはできません。

図9：最終構成と AWS Cloud WAN ルートテーブル

シナリオ2：既存の AWS Cloud WAN のリージョン毎のインスペクションから Service Insertion への移行

このシナリオ（図10）では、スタティックルートを使用してリージョン毎のインスペクション VPC にトラフィックをリダイレクトする AWS Cloud WAN の構成から Service Insertion を使用する構成へ移行する方法について解説します。

図10：初期構成：リージョン毎のインスペクションセグメントを持つAWS Cloud WAN（Service Insertion なし）

ステップ1：AWS Cloud WAN ネットワークポリシー UI でNFG を作成します（図11）（図12）。

図11：ポリシーの作成 – NFG

図12：NFG の作成

ステップ2：アタッチメントポリシーにルールを追加して、インスペクション装置（ファイアウォールなど）を含む1つ以上のアタッチメントを NFG にマッピングします。ここでは、Key: Network-Functions-Group、Value: InspectionVpcs を使用します。これは後で、インスペクション VPC をリージョン毎のインスペクションセグメントから新しく作成された NFG に移行する際に使用します。

図13：NFG 用の新しいアタッチメントポリシーの作成

ステップ3：シナリオ1で解説したように、本番環境と非本番環境のセグメント間の通信をインスペクション VPC にルーティングするには、これら2つのセグメントに対して Service Insertion ポリシーを作成する必要があります。図14と15は、UI での作成方法を示しています：

現在のポリシーバージョンを編集し、Service Insertion に移動して「作成」をクリックします
Action で「Send via」を選択し、Mode で「Single hop」を選択します
Segment form で「Production」を選択し、Segment To で「NonProduction」を選択します
「Send traffic via」で NFG を選択します
このユースケースでは必要ないため、Edge overridesセクションは空のままにします

図14：Service Insertion の作成

図15：Service Insertionの設定

次に進むにはポリシーの変更を適用する必要があります。これによる既存のルーティングや通信への影響はありません。

ステップ4：Service Insertion が作成され、ポリシーが適用されたら、インスペクション VPC を NFG に移行します。そのためには、リージョン毎のインスペクションセグメントへの既存のアタッチメントを変更し、新しいタグを追加して古いタグを削除する必要があります。これにより、アタッチメントがリージョナルインスペクションセグメントから新しく設定された NFG に関連付けられるように変更されます。

図16：アタッチメントタグの更新

ステップ2で作成したアタッチメントポリシーに一致するタグ（Key: Network-Functions-Group、Value: InspectionVpcs）を追加し、リージョン毎のインスペクションセグメント用に割り当てていたタグ（Key:segment、Value: InspectionUSWest2）を削除します。

図17：新しいタグの追加と古いタグの削除

タグが更新されると、ルーティングの再収束と新しい経路の伝播が必要となり、一部の通信が短時間中断する可能性があります。そのため中断を最小限に抑えてスムーズに移行するために、これらの設定をスケジュールされたメンテナンスウィンドウ中に適用することがベストプラクティスです。
インスペクション VPC へのアタッチメントが NFG アタッチメントポリシーに変更され、「Available」になっていることを確認します。

図18：アタッチメントが更新されたことの確認

ステップ5：この段階で、トラフィックは Service Insertion と NFG を使用して動的にインスペクション VPC にルーティングされます。リージョン毎のインスペクションセグメントに関連する設定はもう使用しないため安全に削除できます。
まず、AWS Cloud WAN セグメントの設定から、これまでリリージョン毎のインスペクション VPC アタッチメントにトラフィックを送信していたスタティックルートを削除します。

図19：スタティックルートの削除

古いリージョン毎のインスペクションセグメント用のアタッチメントポリシーを削除します。

図20：リージョン毎のインスペクションセグメント用のアタッチメントポリシーの削除

リージョン毎のインスペクションセグメントを削除します。

図21：リージョン毎のインスペクションセグメントの削除

図22は、インスペクション用に NFG と Service Insertion が設定された最終状態を示しています。

図22：Service Insertion を使用した最終状態

考慮事項

この記事では Egress インスペクションについては扱っていません。Egress が East-West インスペクションと組み合わさる場合、send-to セグメントアクションを使用する等の追加の考慮事項が必要になります。
移行を開始する前に、すべてのファイアウォールに同じセキュリティポリシーが適用されていることを確認して下さい。
AWS Direct Connect を接続している場合など、一部のユースケースでは、Transit Gateway をそのまま維持する必要があります。※ 訳者注: 2024年11月25日より、AWS Cloud WAN は AWS Direct Connect ゲートウェイアタッチメントをネイティブでサポートしています。但し一部のリージョンは 2025年2月26日時点で未サポートですのでご注意下さい。サポートリージョンの情報はこちらをご参照ください。
ワークロード用 VPC を AWS Transit Gateway から AWS Cloud WAN に移行する際、VPC のルートテーブルのターゲットを Transit Gateway からコアネットワークに更新する必要があります。
この記事では、Transit Gateway の本番環境および非本番環境のルートテーブルでデフォルトルートを使用してトラフィックをインスペクション VPC にルーティングしている事を前提としています。代わりに VPC 固有のスタティックルートを使用している場合（例：リージョン間トラフィック）、トラフィックが AWS Cloud WAN 上を経由するには、これらを削除する必要があります。これは、同じプレフィックスに対して、スタティックルートが動的に学習された経路よりも優先されるためです。非対称ルーティングを避けるため、両方のリージョンでルーティングを調整する必要があります。

クリーンアップ

このブログでデプロイしたリソースを削除するには、以下の手順に従ってください：

作成した Cloud WAN のアタッチメント、ピアリング、コアネットワークを削除します。
作成した Transit Gateway とアタッチメントを削除します。
- Transit Gateway への VPC アタッチメントの削除
- Transit Gateway の削除
EC2 インスタンス、AWS Network Firewall、VPC を含む初期構成のリソースを削除します。

結論

ネットワークインスペクションは、クラウド実装において重要な役割を果たします。ポリシーベースの管理、ワンクリックのセグメンテーション、ネイティブな自動化など、AWS Cloud WAN の利点を活用しようとするお客様は、特にインスペクションポイントへのトラフィックのルーティングにおいて、安全かつ円滑に移行することへの課題を持つことがあります。
この記事では、Service Insertion がどのように移行をスムーズにし、中断を最小限に抑え、全体的な効率性を高めることができるかを解説しました。また、スムーズかつ安全に実装するための段階的な手順についても解説しました。
詳しい情報については、AWS Cloud WAN Service Insertion をご覧ください。

翻訳は Technical Account Manager の米山京佑が担当しました。原文はこちらです。

Cookie の設定を選択する

Amazon Web Services ブログ