COLUMN

1．想定する読者

• 自身の環境のIPv6移行を検討されている方
• AWSの各種ネットワーク系サービスを知っている方

2．アーキテクチャ毎の解説

アーキテクチャ1：デュアルスタックVPCにおけるインターネット接続

デュアルスタックVPCにおけるインターネット接続は、大きく分けると二つあります。

インターネットゲートウェイを利用した接続

IPv4においては、インターネットへの接続はインターネットゲートウェイを通じて接続します。

Elastic IPやAWS払い出しのパブリックIPv4アドレスを持っているリソースは直接通信できます。

一方、パブリックIPv4アドレスを持たないリソースは、NATゲートウェイを通じて通信を行います。

IPv6においては、AWSから払い出したIPv6アドレスも、自ら持ち込んだIPv6アドレスもグローバルでユニークなアドレスとなりますので、インターネットゲートウェイを通じての接続では、直接通信することができます。

IPv6アドレスを使用していても、インターネットから直接通信したくないリソースもあります。

その場合に登場するのが、次にご紹介するEgress-onlyインターネットゲートウェイを利用した接続となります。

Egress-onlyインターネットゲートウェイを利用した接続

Egress-onlyという名称から、送信専用のインターネットゲートウェイです。

正しい理解ではありませんが、IPv6版のNATゲートウェイのイメージになります。

Egress-Onlyインターネットゲートウェイを利用した場合は、インターネットからの直接通信ができなくなりますので、プライベートサブネットとして取り扱うことが可能です。

ルートテーブル設定の注意点

IPv6のルートテーブルのデフォルトルートの設定は次のようにします。

パブリックサブネット：デフォルトルート(::/0)をインターネットゲートウェイに向ける

プライベートサブネット：デフォルトルート(::/0)をEgress-onlyインターネットゲートウェイに向ける

アーキテクチャ2：IPv6のみのサブネットの構成

前回のコラムの通り、IPv6のみのサブネットを作ることができます。同一のVPC内でIPv4のみのサブネットと混在させることもできます。

IPv4はIPv4同士、IPv6はIPv6同士で通信しますので、IPv6のみのサブネットに作られたリソースはIPv6アドレスを持つサブネットのリソースと通信することができます。

リソースに割り当てるIPv6アドレスは、DHCPv6による払い出しのほか、サブネットの範囲内で決めることもできます。

アーキテクチャ3：IPv6のみのサブネットからのインターネット接続

IPv6を払い出したVPCにおいて、IPv6のみのサブネットを作ることもできます。プレフィックスは/64で払い出されて、下記のように00からffまで指定することができます。

インターネット通信については、アーキテクチャ1と同様なので省略します。

アーキテクチャ4：デュアルスタックVPCにおけるALBへのIPv4接続

インターネットからの接続はデュアルスタック、Webアプリケーションなどのリソースは引き続きIPv4を利用する場合です。

クライアント端末はRoute 53で名前解決を行います。

クライアント端末においてALBまでは自身のOS設定などで優先される通信経路を使い、ALBのエンドポイントまで通信します。

ALBはデュアルスタックになりますが、ターゲットグループとの通信はIPv4で行います。

WebアプリケーションなどのワークロードでIPv6からでも接続できるようにしたい、というケースに使われることが多いかと思います。

アーキテクチャ5：デュアルスタックVPCにおけるALBへのIPv6接続

インターネットからの接続はデュアルスタック、WebアプリケーションなどのリソースはIPv6を使う場合です。

IPv6のターゲットを使う場合の注意点は、ターゲットグループがIPタイプのもののみ指定できる点です。

ということは、AutoScaling環境では通常使用できず、AutoScaling下で使用する場合にはインスタンスの入れ替え時にIPv6アドレスの変更を検出し、EventbridgeとLambda等を活用してターゲットグループの設定変更を行う必要があるということになります。

IPv6のターゲットグループが属するサブネットは、IPv6のみのサブネット、デュアルスタックのサブネット両方とも登録可能です。

アーキテクチャ6：デュアルスタックVPCにおけるNLBへのIPv4接続

基本的にはアーキテクチャ4のNLB版なので、大きく変わることはありません。

NLBはHyperplaneを介したインターフェースになるので、実際の通信は変わるのですがHyperplaneの話を始めると、AWSの基盤技術の話をする必要があり、長くなるので省略します。

興味ある方はre:Invent2018のセッションで公開されている資料の29p以降を参照いただくとよいかと思います。

Amazon VPC: Security at the Speed Of Light (NET313) – AWS re:Invent 2018

Jerry Hargrove – Amazon VPC Security at the Speed of Light

アーキテクチャ7：デュアルスタックVPCにおけるNLBへのIPv6接続

こちらもアーキテクチャ5のNLB版ですので、大きく変わることはありません。

NLBもALBと同じくIPv6をターゲットグループにする場合はIPタイプのみ使用可能ですので、注意が必要です。

アーキテクチャ8：デュアルスタックVPCにおける内部ALB/NLBの利用

Transit Gateway、VPCピアリング、VPN、Direct Connectで接続された外部のネットワークからの通信例です。

前提として、ALB/NLBのあるサブネットはTransit Gatewayなどを通じて外部のネットワークへの接続が可能であることです。

ここの解説はアーキテクチャ12～14で解説します。また、ALB/NLBのあるサブネットはデュアルスタックである必要もあります。

ALB/NLBがターゲットとするターゲットグループはIPv6のみのターゲットグループまたは、IPv4のターゲットグループである必要があります。

IPv6/IPv4が混在したターゲットグループは指定できません。

内部ALB/NLBはインターネットゲートウェイからのアクセスをデフォルトで拒否しますが、その他の通信経路からの通信は拒否しないので、内部からの通信経路を制御する場合は別途セキュリティグループやNACLなどでの通信制御が必要です。

3．まとめ・次回

今回はリファレンスアーキテクチャの前半部を解説しました。

今回は通信経路に関する解説が多かったかと思いますので、次回は外部のネットワークがIPv4でしか対応していないケースや、大規模ネットワークになった場合のリファレンスアーキテクチャを解説していきます。

AWSのIPv6対応に限らず、NTT東日本はクラウド利用時のネットワーク設計や接続方法などのノウハウを多数有しております。

ネットワーク設計にお困りの方、是非お気軽にご相談ください！