AWS における IPv6 インターネット検査アーキテクチャの設計および構築

本記事は 2025年6月3日に公開された Design and build IPv6 internet inspection architectures on AWS を翻訳したものです。

組織がパブリック IPv4 の枯渇に対応するために IPv6 を採用する機会が増えるにつれ、プライベート IPv4 の不足（特に大規模ネットワークにおいて）や IPv6 のみのクライアントをサポートする必要性から、 IPv4 と IPv6 の両方のトラフィックを保護することが重要になっています。Amazon Virtual Private Cloud（Amazon VPC）では、インバウンドおよびアウトバウンドフローに対して一貫したトラフィック検査を適用し、セキュリティを維持できます。この記事では、Amazon VPC におけるIPv6トラフィックのインターネット向け送信トラフィック検査を実装するためのベストプラクティスとリファレンスアーキテクチャについて説明します。これは AWS Network Firewall と AWS Gateway Load Balancer（GWLB）およびサードパーティのファイアウォールアプライアンスを使用して実現されます。
AWS では IPv6 を展開するために主な2つのアプローチがあります。デュアルスタックと IPv6-only です。デュアルスタック設定では、ワークロードは IPv4 と IPv6 の両方のアドレスで動作しますが、IPv6-only の場合は、ワークロードは IPv6 アドレスのみを使用します。2つのIPスタックは独立して機能するため、この記事ではIPv6に特化したベストプラクティスと設計上の考慮事項に焦点を当てます。

前提条件

読者は AWSの基本的なネットワーキング構成要素（Amazon VPC 、インターネットゲートウェイ（IGW）、サブネット、ルートテーブル、Network Firewall 、GWLB など）に精通していることを前提としています。本ポストではこれらのサービス自体には焦点を当てませんが、AWS で IPv6 インターネット向け送信トラフィック検査アーキテクチャを設計・構築する際に関連する機能については概説します。

AWS における IPv6 によるインターネット接続

デュアルスタックな Amazon VPC では、 IPv4 スタックに対して同様なインターネット接続構成を維持しつつ、IPv6スタックには Egress-only Internet Gateway（送信専用の IGW、以下 EIGW ）を追加します。IPv6 のパブリックサブネットでは IGW を通じて双方向のインターネット接続が可能ですが、IPv6 のプライベートサブネットではインターネット接続にEIGW を使用します。EIGW は、VPC内のリソースからのアウトバウンドな IPv6 通信のみを許可する、水平スケール可能で冗長性が高く、高可用性を持つ VPC コンポーネントです。EIGW の役割は、プライベートサブネットの概念を IPv4 と IPv6 の両方のスタックで一貫させることです。EIGW により、インターネット上のエンドポイントからプライベート IPv6 サブネット内のインスタンスへ IPv6 接続を開始することを防ぐことができます。以下の図は、VPC 内のプライベートサブネットとパブリックサブネットのIPv6 インターネット接続を示しています：

図1: Amazon VPC IPv4およびIPv6インターネット接続

VPC内のプライベートIPv4またはデュアルスタックサブネット内のリソースは、NAT Gateway を使用してインターネット上の IPv4 エンドポイントに出ていきます。NAT Gateway はパケットの送信元 IPv4 アドレスを変換し、IGWを通じてトラフィックをインターネットに送信します。
パブリック IPv4 またはデュアルスタックサブネット内のリソースは、Elastic IPv4 アドレスを使用して IGW を通じてインターネット上の IPv4 エンドポイントと双方向に通信します。トラフィックは VPC 内のリソースからもインターネットリソースからも開始できます。
パブリック IPv6 またはデュアルスタックサブネット内のリソースは、VPC 内の IPv6 アドレスを使用して IGW を通じてインターネット上の IPv6 エンドポイントと双方向通信します。トラフィックは VPC 内のリソースからもインターネットリソースからも開始できます。
プライベート IPv6 またはデュアルスタックサブネット内のリソースは、VPC 内の IPv6 アドレスを使用して、EIGW を通じてインターネット IPv6 エンドポイントと通信します。トラフィックはVPC内のリソースからのみ開始できます。

AWS における IPv6トラフィックの検査パターン

IPv6 では、VPC からのインターネットトラフィックは Network Firewall または、GWLBを使用したサードパーティアプライアンスのいずれかを使用してローカルで検査できます。AWS で IPv6 のインターネットトラフィックを検査するための主な2つのパターンを区別します

分散型の送受信 IPv6 インターネットトラフィック検査

分散型の設計では、各 VPC に Network Firewall または GWLB エンドポイントを展開し、インターネットアクセスには VPC 内の IGW を使用します。トラフィック検査が必要なサブネットは、アウトバウンドトラフィックをこれらのエンドポイントを通じてルーティングします。リターントラフィックやインバウンドインターネットトラフィックについては、IGWルートテーブルが各アベイラビリティゾーン（AZ）内のファイアウォールまたはロードバランサーエンドポイントを通じて対称ルーティングを確保します。インターネットからのインバウンドトラフィックを許可しないサブネットの場合、ファイアウォールポリシーはインターネット発信のトラフィックを拒否し、リターンフローのみを許可する必要があります。以下の図は、分散型インターネットトラフィック検査のための高レベルVPCルーティングの2つのバージョンを示しています：左の図はGWLBとアプライアンスを使用し、右の図はNetwork Firewallを使用しています：

図2: 分散型インターネットトラフィック検査—送信と受信

VPC 内のリソースから送信されるインターネットトラフィックは、同じ AZ 内にある Network Firewall または GWLB エンドポイントに送信されます。受信するトラフィックは、IGW に関連付けられたエッジルートテーブルの設定に従って、ファイアウォールエンドポイントを通過します。

集中型の受信 IPv6 インターネットトラフィック検査

集中型受信トラフィック検査では、トラフィック受信用 VPC と内部 VPC 間のルーティングに AWS Transit Gateway または AWS Cloud WANを使用する必要があります。受信用の ELB はプロキシとして機能し、アドレス変換を実行します。そのため、トラフィック検査には Network Firewall またはGWLBを使用したサードパーティアプライアンスのいずれかを使用できます。Network Firewall を使用した検査アーキテクチャの詳細については、「IPv6 deployment models for AWS Network Firewall」をご参照下さい。

集中型の送信 IPv6 インターネットトラフィック検査

集中型の送信 IPv6トラフィック検査には、2つのオプションがあります：

各スポークVPCに分散型 GWLB エンドポイントを展開: 以下の図に示すように、各 VPC に GWLB エンドポイントを展開することで、 GWLB とファイアウォールアプライアンスを含む VPC に送信トラフィックを集約できます。このオプションでは、Transit Gateway または AWS Cloud WAN を通じてトラフィックをルーティングする必要がなくなるため、データ処理コストを最適化できます。このオプションは送信専用として機能し、アプライアンス側からの新しいフローを受け入れることはできません。さらに、IPv6-only のサブネットでロードバランサーを作成することはできません。

図3: エンドポイントを分散させた集中型の送信トラフィック検査

Transit Gateway または AWS Cloud WAN を使用: Transit Gateway または AWS Cloud WAN を使用して、以下の図に示すように、GWLB、GWLB エンドポイント、およびサードパーティのファイアウォールアプライアンスを含む送信用 VPC に送信トラフィックをルーティングします。Transit Gateway を使用した集中型送信トラフィック検査の設定の詳細については、「Centralized inspection architecture with AWS Gateway Load Balancer and AWS Transit Gateway」をご参照ください。

図4: Transit Gateway または AWS Cloud WAN を使用した集中型送信トラフィック検査

この記事では、最初の手法、すなわち分散型 GWLB エンドポイントを使用した手法に焦点を当てます。この設計により、トラフィックは各 VPC 内でローカルに集中型検査アプライアンスにリダイレクトされるため、Transit Gateway を通じてルーティングする必要がなくなります。これによりルーティングが簡素化され、よりよい障害の分離が実現でき、検査エントリポイントを分散させることでスケーラビリティが向上します。

サードパーティアプライアンスを使用した集中型送信トラフィック検査の考慮事項

GWLB エンドポイントとサードパーティアプライアンスを使用した集中型 IPv6 送信トラフィック検査に関する設計上の考慮事項は以下の通りです。

NAT66 または NPTv6 のサポート: アーキテクチャで使用されるサードパーティ検査アプライアンスが IPv6 アドレス変換をサポートしていることを確認してください。IPv6 プレフィックスは割り当てられた VPC にローカルであるため、集中型検査 VPC で送信トラフィックの IPv6 アドレスを変換する必要があります。したがって、サードパーティアプライアンスは NAT66（ステートフルな IPv6 からIPv6 へのネットワークアドレス変換）または NPTv6（ステートレスな1対1の IPv6 プレフィックス変換）をサポートしている必要があります。Network Firewall は現在、NAT66 / NPTv6 をサポートしていないため、このアーキテクチャには適用できません。このアーキテクチャでは、GUA (Global Unicast Address) 、IPv6 ULA（Unique Local Address）、またはプライベート GUA IPv6 アドレスを使用してアドレス指定されたリソースにインターネットへのトラフィック送信を提供することもできます。
ツーアームモードのサポート: 選択した検査デバイスがツーアームモードで動作できることを確認してください。これにより、送受信の両方のインターフェースを通じてトラフィックを処理できます。アプライアンスが NAT66 / NPTv6 を実行するため、これは必要です。ツーアームモードの詳細については、「Best practices for deploying Gateway Load Balancer」をご参照ください。
GENEVE プロトコルのサポート: 検査アプライアンスが GWLB によって使用される Generic Network Virtualization Encapsulation （GENEVE）プロトコル（UDP 6081 ポート）をサポートし、GENEVE メタデータを解釈でき、GWLB ヘルスチェックに応答できることを確認してください。

分散型エンドポイントを使用した集中型送信トラフィック検査のトラフィックフロー

アプリケーション / Amazon EC2 インスタンスからインターネットへのトラフィックフロー：

VPC 内の Amazon Elastic Compute Cloud（Amazon EC2）インスタンスからのインターネット向けトラフィックは、VPC の同じ AZ 内に展開された GWLB エンドポイントにローカルにルーティングされます。
GWLB エンドポイントはトラフィックをGENEVE プロトコルを使用してカプセル化してエンドポイントに関連付けられた GWLB に送信します。
GWLB は GENEVE でカプセル化されたトラフィックをセキュリティアプライアンスの内向きのインターフェースに転送します。
トラフィックがファイアウォールによって検査された後、デバイスは NAT（セキュリティアプライアンスの機能に応じて NAT 66 または NPTv6）を実行し、 GENEVE でのカプセル化解除されたトラフィックを外向けのファイアウォールインターフェースを通じてIGWに向けてアウトバウンド送信します。

インターネットからアプリケーション / EC2インスタンスへのリターントラフィックフロー：

インターネットからのリターントラフィックは、受信ルートテーブルに基づいて IGW からファイアウォールの外向けインターフェースに向けられます。ファイアウォールは de-NAT（NAT66 または NPTv6 の逆変換）を実行して、宛先 EC2 インスタンスの元のプライベート IP アドレスを復元します。
de-NAT 後、セキュリティアプライアンスは GENEVE プロトコルを使用してトラフィックを再度カプセル化し、GWLB に送信します。
GWLB は元の GWLB エンドポイントを識別するメタデータを含む GENEVE ヘッダーを確認します。これに基づいて、GWLB は元のリクエストが来た同じ AZ と VPC にトラフィックを返します。GWLB はカプセル化されたパケットを元の VPC と AZ にある GWLB エンドポイントに送信します。エンドポイントはパケットのカプセル化を解除し、ローカルに EC2 インスタンスに転送します。
この設計では、専用のルートテーブルを使用できるようにするために、各 GWLB エンドポイントを独自のサブネットに配置する必要があります。このサブネットの分離は、GWLB リターントラフィックの正確なルーティング制御を可能にするため重要です。

デュアルスタックな GWLB と GWLB エンドポイントの設定

ステップ1：ターゲットグループを作成する

EC2 サービスに移動し、ロードバランシング セクションの下で、ターゲットグループを選択します。
ターゲットグループの作成を選択します。
ターゲットタイプとしてはインスタンスを選択します。

図5: ターゲットグループ設定

ターゲットグループを作成する際は、ヘルスチェックを正しく設定していることを確認してください。ヘルスチェックのプロトコルとポートを設定する前に、アプライアンスのメーカーの推奨事項を参照してください。設定はデバイスによって大きく異なります：ウェブインターフェイスポートを使用するもの、専用のハートビートポートを指定するもの、まったく異なるプロトコルやポートを必要とするものもあります。メーカーのガイドラインに従うことで、最適なパフォーマンスと正確なヘルスチェックが保証されます。不適切な設定は、誤検知（偽陽性または偽陰性）のヘルスチェック結果を招き、アプリケーションの可用性とパフォーマンスに影響を与える可能性があります。ヘルスチェックを設定する前に、アプライアンスのドキュメントを十分に確認してください。

ステップ2: GWLB のデプロイ

EC2 サービスに移動し、ロードバランシングセクションの下にあるロードバランサーを選択します。
ロードバランサーの作成を選択し、Gateway Load Balancer を選択します。
基本的な設定で、Dualstack を選択し、次の図に示すようにVPCとAZ を追加します。

図6: GWLB 設定

先の手順で作成したターゲットグループを選択し、ロードバランサーの作成を選択します。
GWLB がプロビジョンされるまでまちます。プロビジョンされたらターゲットグループにてあなたが作成したターゲットグループを選択し、アプライアンスインスタンスのヘルスチェックが正常表示になるのを待ちます。50 秒後までに反応がない場合（デフォルトタイマーを使っている場合）ヘルスチェック設定とアプライアンスの設定を見直して下さい。

ステップ3: エンドポイントサービスの作成

VPC サービスに移動し、PrivateLink と Lattice セクションの下にあるエンドポイントサービスを選択します。
エンドポイントサービスの作成を選択します。
エンドポイントサービスの設定にて、ロードバランサのタイプとしてゲートウェイを選択し、作成した GWLB を選択して下さい。
追加設定のセクションで、承認が必要のチェックボックスがチェックされていることを確認し、また、以下の図のようにサポートされている IP アドレスタイプとして IPv4 と IPv6 がそれぞれチェックされていることも確認して下さい。

図7: エンドポイントサービス設定

完了したら作成を選択します。
詳細については「Create an endpoint service」のドキュメントを参照してください。

ステップ4: 各スポークVPCにエンドポイントを作成する

エンドポイントサービスが作成されたら、アプリケーションから接続できるよう、各サブネットごとに1つずつエンドポイントを作成する必要があります。以下の手順に従います。

VPC サービスに移動し、PrivateLink と Lattice セクションの下にあるエンドポイントを選択します。
「 connect to an endpoint service as the service customer 」の手順に従い、エンドポイントを作成します。
エンドポイントを作成する際は、次の図に示すように、作成した GWLB エンドポイントサービス名に関連付けられていることを確認してください。

図8: エンドポイント VPC 関連図付け

エンドポイントの作成を選択して下さい。

スポーク VPC と集約 VPC のルートテーブル設定

図9: 分散型エンドポイントを使用した集中型送信トラフィック検査のルートテーブル設定

考慮事項

GWLB IPv6 の動作: GWLB は IPv6 トラフィックをネイティブにサポートしています。ただし、トラフィックが IPv4 か IPv6 かに関わらず、 IPv4 パケットの GENEVE プロトコル（6081 番ポート）を使用してカプセル化します。サードパーティのセキュリティアプライアンスでIPv4 Geneveトラフィックをカプセル化の解除、および、ルーティングするために、6081番ポートを許可するようにしてください。
リソースのデュアルスタック構成: 関連するすべてのAWSリソース（EC2インスタンス、サブネット、ルートテーブル、ロードバランサーなど）がデュアルスタック（IPv4とIPv6）用に構成されていることを確認してください。
サブネットとルーティング構成: セキュリティのため、GWLB はプライベートサブネットで使用する必要があります。VPC がデュアルスタックサブネットで構成されていることを確認してください。これにより IPv6 トラフィックをルーティングするための IPv6 CIDR ブロックを構成できます。ルートテーブルを使用して、IPv6 トラフィックを VPC 内の GWLB エンドポイントに送信します。さらに、GWLB エンドポイントはゾーン単位であるため、インバウンドトラフィックが到達する各 AZ でルーティングを慎重に調整する必要があります。
IPv6 用のセキュリティグループと NACL : セキュリティグループと NACL が対象ポート（ HTTP / HTTPS ）へのインバウンドの IPv6 接続を許可していることを確認してください。
IPv6-only とデュアルスタック設計の比較: ネットワークが IPv6-only か IPv4+IPv6 のデュアルスタックかを決定します。最新のクラウドネイティブアプリケーションを構築する場合で、ネットワーク管理を合理化し、レガシーな IPv4 サポートが不要な場合は、IPv6 専用アーキテクチャを選択すると運用オーバーヘッドが削減されます。デュアルスタックは、新しいアプリケーション用に IPv6 を有効にしながら、レガシークライアント向けに IPv4 サポートを維持します。デュアルスタック構成を実行する場合、「NAT64 or other protocols when IPv6-only backends need to communicate with IPv4 resources」を検討してください。
可観測性とロギング: VPC フローログを使用して、GWLB エンドポイント間の IPv6 トラフィックフローを監視することを検討してください。これにより、異常なパターンを特定し、環境間の接続問題をトラブルシューティングするのに役立ちます。
トラフィックログとメトリクス: Amazon CloudWatch Logs と Metrics は、トラフィックの動作を理解し、潜在的な問題を特定するのに役立ちます。サードパーティのアプライアンスが IPv6 トラフィックをログに記録し監視していることを確認してください。
高可用性とスケーラビリティ: GWLB とそのエンドポイントはデフォルトで高可用性を備えていますが、さらに高可用性を確保するために、複数の AZ で GWLB エンドポイントを実行し、各サブネット内のルートテーブルを設定して、トラフィックを AZ ローカルのエンドポイントに向けるようにしてください。GWLB は大量のトラフィックを処理できますが、その処理はアプライアンスに依存するため、GWLB 背後の仮想アプライアンスが水平方向にスケーラブルであることを確認してください。
コストへの影響: AWS のコストを把握しておきましょう。月あたりのコストを計算するには、AWS 料金見積りツールを使用してください。
IPv6 DNS考慮事項: Amazon Route 53 レコードに、IPv6 アドレスでトラフィックを受信するリソース用の AAAA レコードが含まれていることを確認してください。これにより、クライアントはIPv6アドレスに直接接続できます。サービスがIPv4とIPv6の両方のクライアントをサポートする場合は、デュアルスタックDNS レコードを追加してください。

結論

この記事では、Gateway Load Balancer を使用した IPv6 対応の送信トラフィック検査アーキテクチャの設計方法について概説しました。このアプローチでは、サードパーティのファイアウォール/セキュリティアプライアンスの NAT66 または NPTv6 機能を活用することで、お客様は送信トラフィック検査に関する懸念なく IPv6 へのシームレスな移行を実現できます。さらに、このソリューションはアーキテクチャに NAT Gateway タイプのアプライアンスが不要となるため、AWS の観点からもコスト効率が高いです。また、送信トラフィックと受信トラフィックの両方のフローを詳細に説明し、IPv6 アーキテクチャを確立するためのデプロイプロセスについてステップバイステップのガイドを提供しました。さらに詳細が知りたい場合は、「Centralized egress to internet」のドキュメントをご参照ください。この記事に関するご質問がある場合は、AWS re:Post で新しいスレッドを開始するか、AWS サポートにお問い合わせください。

翻訳は Solutions Architect の山本大貴が担当しました。原文はこちらです。

Amazon Web Services ブログ