【AWSユーザーガイド非公式解説】［VPC］ 2.VPCとサブネットのIPアドレス指定
この記事はAWSユーザーガイドの以下リンクの解説記事です。
Classless Inter-Domain Routing (CIDR) 表記は、IP アドレスとそのネットワークマスクを表す方法です。
CIDR表記についてはIPv4アドレスを例にすると
10.0.0.0/16
の/16の部分を言います。
IPv４アドレスは8ビットずつの区切りとなっていて、8ビットを10進法で表記した４つの数字で表現されます。
| 10. | 0. | 0. | 0 |
|---|---|---|---|
| 8bit | 8bit | 8bit | 8bit |
/16は前から16ビットをネットワーク部として取り扱うという意味です。
| 10.0. | 0.0 |
|---|---|
| ネットワーク部 | ホスト部 |
ネットワーク部のアドレスはそのネットワークでは固定となり、ネットワーク内のリソースにホスト部のIPアドレスを割り当てるため、CIDRは、そのネットワークにIPアドレスを保有するリソース（EC2インスタンス等）がどの程度の数になるか、により決定します。
/24とした場合、ホスト部は8ビットのため256、/16とした場合、ホスト部は16ビットのため65,536が割り当て可能なIPアドレス数となります（実際には、AWSで予約済みのIPアドレスがあるため最大-5となります）。
IIPv6の場合は、16ビットを16進法で表記した8つの数字で表現され、CIDR表記は/64のような表記になります。
例：2001:0db8:85a3:0000:0000:8a2e:0370:7334/64
| 2001: | 0db8: | 85a3: | 0000: | 0000: | 8a2e: | 0370: | 7334 |
|---|---|---|---|---|---|---|---|
| 16bit | 16bit | 16bit | 16bit | 16bit | 16bit | 16bit | 16bit |
プライベート IPv4 アドレス
プライベートIPv4アドレスは、インターネットから接続しない内部通信用IPアドレスです。
VPCでインスタンスを起動すると、サブネットに割り当てたIPv4アドレス範囲内で、プライベートIPv4アドレスがインスタンスに割り当てられます(自動割り当てとせず、指定することも可能)。
最初に割り当てられたIPv4アドレスをプライマリIPアドレスと呼び、プライマリIPアドレスはインスタンスのデフォルトのネットワークインターフェース (eth0)に割り当てられます。
IPアドレスは正確にはEC2インスタンスが内包するネットワークインターフェース（eth〜）に割り当てられます。物理サーバーのネットワークカードをイメージすると理解しやすいのではと思います。
EC2インスタンスにはデフォルトでネットワークインターフェース (eth0)が割り当てられており、ネットワークインターフェースを追加することでIPアドレスを複数割り当てることも可能です。追加されたIPアドレスはセカンダリプライベート IP アドレスと呼びます。
パブリック IPv4 アドレス
AWSではそのネットワークをインターネットに公開するパブリックネットワークとするかはサブネットの設定により決まります。
サブネットの設定で「パブリックIPv4 アドレスの自動割り当てを有効化」することによってパブリックIPアドレスの割り当てが可能です。
パブリックIPｖ４アドレスを有効にすると、プライマリネットワークインターフェース(eth0)にパブリックIPｖ４アドレスが追加設定されます。
AWSがインスタンスに自動割り当てを行うパブリック IPｖ4 アドレスは固定できません。インスタンスを停止（または休止）するとIPアドレスは解放され、再度起動した際は別のIPアドレスになる可能性があります。IPアドレスを固定したい場合はElastic IP アドレスを使用します。
AWS では、実行中のインスタンスに関連付けられているパブリック IPv4 アドレスと Elastic IP アドレスを含む、すべてのパブリック IPv4 アドレスに対して料金が課されます。
IPv6 アドレス
IPv6アドレスをVPCおよびサブネットに関連付けることができます。IPv6アドレスはグローバルに一意でありプライベート・パブリックの区別がありません。割り当てたIPv6アドレスはインターネット経由でアクセス可能なIPアドレスとなります。
IPv6アドレスを関連付けたサブネットではインスタンスにIPv6アドレスを割り当てて起動可能です。IPv6アドレスはプライマリネットワークインターフェイス (eth0)に設定されます。IPv6アドレスは、インスタンスの停止・休止では保持され、再度起動する際は同じアドレスで起動可能です。インスタンスの終了時にリリースされます。
VPC CIDR ブロック
VPCを作成する際、IPv4アドレス範囲をCIDR表記で関連付けます。作成後に追加のIPv4アドレス範囲をVPCに関連付けることもできます。
IPv4 VPC CIDR ブロック
VPCを作成するときに関連付けることができるCIDRの範囲は/16から/28です。
通常はRFC1918に指定されているプライベートIPv4アドレス範囲から割り当てます。
プライベートIPv4アドレス範囲外のアドレスを割り当てることもできますが、様々な問題を引き起こす可能性があるため非推奨です。
| プライベートIPv4アドレス範囲 |
|---|
| 10.0.0.0 ～ 10.255.255.255 |
| 172.16.0.0 ～ 172.31.255.255 |
| 192.168.0.0 ～ 192.168.255.255 |
一部の AWS サービスは、172.17.0.0/16 CIDR 範囲を使用します。将来競合が発生しないように、VPC を作成するときはこの範囲を使用しないでください。
VPCのIPv4 CIDRブロックを管理する
作成時にVPC関連付けたIPv4 CIDRブロック（プライマリCIDRブロック）の他に、追加で
IPv4 CIDRブロック（セカンダリCIDRブロック）を関連付けることができます。
追加したセカンダリCIDRブロックを使ったローカル通信用のルートがルートテーブルに自動的に追加されます。
下のイメージのVPCには2つのCIDRブロックを関連付けています。
- 10.0.0.0/16（プライマリCIDRブロック）
- 10.1.0.0/16（セカンダリCIDRブロック）
（リソースマップの仕様上、VPCにはプライマリCIDRブロックしか表示されていませんが）
subnetAにはプライマリCIDRブロック範囲内のCIDRブロックから10.0.0.0/20を関連付け、
subnetBにはセカンダリCIDRブロック範囲内のCIDRブロックから10.1.0.0/20を関連付けており、
ルートテーブルには送信先がプライマリCIDRブロック、セカンダリCIDRブロックの場合にlocal通信を行うルートが追加されています。
VPCではプライマリCIDRブロック範囲のIPアドレスでは足りなくなっても、アドレス範囲（ホスト部）を拡大することはできません。
その場合はセカンダリCIDRブロックを使用します。
ホスト部を大きく取れる会社であれば足りなくなることはないと思いますが、例えば多数のシステムを管理する会社で全社的にネットワークを管理している場合、/28のCIDRブロックしか割り当てられないということもあります。
その場合、/27にアドレス範囲（ホスト部）を拡大することはAWSではできず、
プライマリCIDRブロックと重複しないアドレス範囲で、セカンダリCIDRブロックを割り当てる必要があります。
VPCに関連付けできるCIDRブロックのデフォルトは５です。この制限は拡張することができます。
また、以下の制限があります。
-
追加するCIDRブロックと同じまたはそれよりも小さいCIDRブロックがルートテーブルにある場合、CIDR ブロックを追加できません。それよりも大きいCIDRブロックを追加することはできます。
「プライマリCIDRブロック 10.0.0.0/16」
「仮想プライベートゲートウェイ 10.1.0.0/24」
がルートテーブルに設定されている場合
| 送信先 | ターゲット | |
|---|---|---|
| プライマリCIDRブロック | 10.0.0.0/16 | local |
| 仮想プライベートゲートウェイ | 10.1.0.0/24 | vgw-xxxxxxx |
セカンダリCIDRブロックとして10.1.0.0/24またはそれよりもネットワーク部が小さいCIDRブロックを追加することはできません。10.1.0.0/24よりもネットワーク部が大きいCIDRブロックを追加することはできます。セカンダリCIDRブロックとして「10.1.0.0/25」を追加した場合、ルートテーブルはロンゲストマッチ（CIDRの数値＝ネットワーク部が大きいものが優先）となるため、セカンダリCIDRブロック内のIPアドレスに対する通信はlocal宛としてルーティングし、それを除く10.1.0.0/24の範囲のIPアドレス宛の通信を仮想プライベートゲートウェイ宛としてルーティングします。
| 送信先 | ターゲット | |
|---|---|---|
| プライマリCIDRブロック | 10.0.0.0/16 | local |
| セカンダリCIDRブロック | 10.1.0.0/25 | local |
| 仮想プライベートゲートウェイ | 10.1.0.0/24 | vgw-xxxxxxx |
仮に10.1.0.0/24よりもネットワーク部が大きいCIDRブロックの追加ができてしまうと、仮想プライベートゲートウェイ宛の通信が優先され、VPC内の一部リソースへのlocal通信ができなくなるため、不可となっていると思われます。
-
VPCピアンリングについては以下の制約があります。
-
VPCピアリング接続が行われている（active）場合、相手側VPCのCIDRブロックと重複しているCIDRブロックは追加できません。
（ルートテーブルにピアリング先のCIDRブロックが登録されており、セカンダリCIDRブロックを登録できないため、不可となっていると思われます。） -
VPCピアリング接続を要求し、相手側VPCから受け入れられていない場合（pending-acceptance）、VPC に CIDR ブロックを追加できません。
（相手が受け入れた場合に、相手側のCIDRブロックをルートテーブルに追加する必要があり、セカンダリCIDRブロックと重複する可能性があるため、不可になっていると思われます。） -
VPCピアリング接続の受け入れ側は、まだ受け入れていない場合（pending-acceptance）は、要求側のCIDRブロックに関わらずVPCにCIDRブロックを追加できます。追加したCIDRブロックと要求側のCIDRブロックが重複していた場合は、VPCピアリングの受け入れが失敗します。
（ルートテーブルに重複するCIDRブロックを追加できないためだと思われますが、受け入れ側はCDIRブロックの追加が優先されます。）
-
-
AWS Direct Connectを使用してDirect Connectゲートウェイ経由で複数の VPC に接続する場合 、Direct Connectゲートウェイに関連付けられたVPCと重複するCIDRブロックを追加することはできません。
（送信先のVPCへの通信を行う設定がルートテーブルに必要であり、重複ができないためと思われます。）
サブネット CIDR ブロック
サブネットのCIDRブロックはVPCのCIDRブロックの範囲内（VPCより大きいネットワーク部）で設定します。
VPCと同じCIDRブロックを設定することもできますが、その場合、VPC内に他のCIDRを作成することができなくなるため、通常はVPCブロックよりも大きいCIDRを設定します。
IPv4 のサブネットのサイズ設定
サブネットで設定できるIPv4 CIDRブロックは/16から/28の間です。
AWSではサブネット内のIPアドレスの最初の4つ及び最後のIPアドレス（合計５つ）は使用できません。
| 10.0.0.0/24 の場合の予約済みIPアドレス |
|---|
| 10.0.0.0 |
| 10.0.0.1 |
| 10.0.0.2 |
| 10.0.0.3 |
| 10.0.0.255 |
IPv6 のサブネットのサイズ設定
IPv6 CIDRブロックをVPCに関連付けている場合、サブネットにもIPv6 CIDRブロックを関連づけることができます。関連付け可能なCIDRサイズは/44 から/64の/4刻みです。
IPv4と同じくサブネット内のIPアドレスの最初の4つ及び最後のIPアドレス（合計５つ）は使用できません。
| 2001:db8:1234:1a00/64 の場合の予約済みIPアドレス |
|---|
| 2001:db8:1234:1a00: |
| 2001:db8:1234:1a00::1 |
| 2001:db8:1234:1a00::2 |
| 2001:db8:1234:1a00::3 |
| 2001:db8:1234:1a00:ffff:ffff:ffff:ffff |
IPv4 と IPv6 を比較する
| 特徴 | IPv4 | IPv6 |
|---|---|---|
| VPC のCIDRサイズ | /16 から /28 まで。 デフォルトでは最初に設定したCIDRの他に4個のCIDRブロックを追加可能です。 CIDRブロックの数を6個以上にしたい場合は申請が必要です。 |
/44 から /60までの/4 刻み。 最大 5個のCIDRブロックを設定可能です。 CIDRブロックの数を6個以上にしたい場合は申請が必要です。 |
| アドレスの設定方法 | 以下のいずれか。 ・任意のCIDRブロックを設定する。 ・Amazon VPC IP Address Manager (IPAM) から CIDR ブロックを設定する。 |
以下のいずれか。 ・ユーザー所有のCIDRブロックを設定する。 ・Amazon提供のCIDRブロックを設定する。 ・Amazon VPC IP Address Manager (IPAM) から CIDR ブロックを設定する。 |
| インターネットアクセス | インターネットゲートウェイを使用します。 | インターネットゲートウェイを使用します。 インターネットからの通信を受け付けず、VPCからの送信のみの場合、 エグレス専用インターネットゲートウェイが使用可能です。 |
| Elastic IP アドレス | サポート対象。 |
サポート対象外ですが、IPv6 アドレスはインスタンスを停止しても保持されるため、固定IPとして使用することができます。 |
| NAT ゲートウェイ | サポート対象。以下が利用可能です。 ・パブリックNAT ゲートウェイをプライベートサブネットからパブリックIPアドレスに変換してインターネット接続を行う。 ・プライベートNATゲートウェイを利用して、他のVPCまたはオンプレミスネットワークに対して、固定のプライベートIPアドレスで接続する。 |
サポート対象。NATゲートウェイを使用すると、NAT64の機能によって、IPv4ネットワークと通信することができます。 |
| DNS 名 | IPアドレスベース またはリソース名（インスタンスID）ベースの DNS名を付与し、DNSによる名前解決に使用できます。 | IPアドレスベース またはリソース名（インスタンスID）ベースの DNS名を付与し、DNSによる名前解決に使用できます。 |
マネージドプレフィックスリスト
複数のCIDRブロックをグルーピングしたもので、セキュリティグループ、ルートテーブル等に利用できます。
例えば、拠点のCIDRブロックのみからアクセス可能な設定をセキュリティグループに設定する場合、複数のセキュリティグループがある場合は、それぞれのセキュリティグループに同じ変更を行う必要があります。マネージドプレフィックスリスト（後述のカスタマー管理プレフィクスリスト）を作成し、それぞれのセキュリティグループでマネージドプレフィックスリストを使用する形に設定すれば、セキュリティグループに個別にCIDRブロックを設定する必要がなくなります。拠点の増減時もマネージドプレフィックスリストをメンテナンスすれば、変更内容がそれぞれのセキュリティグループに反映されます。
また、マネージドプレフィックスリスト（後述のカスタマー管理プレフィクスリスト）はResource Access Manager (RAM) を使用して、他の AWSアカウントと共有できます。メンテナンスを行うアカウントで保有し、各システムのアカウントで使用する等の使い方ができます。
プレフィックスリストには、次の 2 つのタイプがあります。
- カスタマー管理プレフィクスリスト：ユーザーが定義可能なプレフィックスリスト
- AWS マネージドプレフィクスリスト：AWSが管理するプレフィックスリスト（編集・共有不可）
カスタマーマネージドプレフィックスリスト
プレフィックスリストに登録するCIDRブロックをエントリと呼びます。
カスタマーマネージドプレフィックスリストには、次のルールが適用されます。
-
1つのプレフィックスリスト内では、IPv4とIPv6を混在させることはできません。
-
プレフィクスリストを作成したリージョン以外で使用することはできません。
-
プレフィックスリストを作成する際に最大エントリ数を設定する必要があります。
プレフィックスリストを使用する際は、最大エントリ数の設定を使用しているものとしてカウントされます。例えば、ルートテーブルでプレフィックスリストを使用する場合、ルートテーブルのデフォルト最大ルール数（クォータ）は50です。作成したプレフィックスリストの最大エントリ数を60としていた場合、実際にプレフィックスリストに登録したエントリ数が50以下であっても、そのルートテーブルでプレフィックスリストを使用することはできません。
-
プレフィックスリストを変更した場合、自動でバージョン管理が行われ、問題が発生した場合に以前のバージョンに戻すことが可能です。
-
ルートテーブル内でプレフィックスリストを参照する場合、次のルート優先度ルールが適用されます。
ルートテーブルに、プレフィックスリストを持つ静的ルートと重複する送信先の CIDR ブロックを持つ静的ルートが含まれている場合、CIDR ブロックを持つ静的ルートが優先されます。
伝播されたルートがルートテーブルに含まれていて、プレフィックスリストを参照するルートと一致する場合は、プレフィックスリストを参照するルートが優先されます。重複するルートについては、伝播されたルート、静的ルート、またはプレフィクスリストを参照するルートであるかどうかにかかわらず、より具体的なルートが常に優先されることに注意してください。
ルートテーブルで複数のプレフィックスリストが参照されていて、異なるターゲットへの CIDR ブロックが重複する場合、優先されるルートはランダムに選択されます。その後は、同じルートが常に優先されます。
カスタマーマネージドプレフィックスリストの操作
AWS マネージドプレフィックスリスト
AWSマネージドプレフィックスリストは、AWSが提供するサービスのCIDRブロックが登録されたリストです。管理はAWSが行っており編集はできません。
カスタマーマネージドプレフィックスリストと同じようにセキュリティグループ等で利用可能です。
上のイメージはDynamoDBのプレフィックスリストで、6個のCIDRブロックが登録されています。
このAWSマネージドプレフィックスリストをセキュリティグループで使用することで、通信先をDynamoDBに限定したルールが作成できます。DynamoDBのCIDRブロックが変わった場合も、AWSにより修正が行われるため、セキュリティグループの設定を変更する必要がありません。
下表はAWSマネージドプレフィックスリストの一覧とそのウエイトになります。
| AWS サービス | ウェイト |
|---|---|
| Amazon CloudFront | 55 |
| Amazon DynamoDB | 1 |
| AWS Ground Station | 5 |
| Amazon Route 53 | 25 |
| Amazon S3 | 1 |
| Amazon S3 Express One Zone | 6 |
| Amazon VPC Lattice | 10 |
AWS マネージドプレフィックスリストのウェイト
AWSマネージドプレフィックスリストのウェイトは、使用した場合に消費される設定数になります。
例えば、セキュリティグループでプレフィックスリストを使用する場合、セキュリティグループのデフォルト最大設定数（クォータ）は60です。DynamoDBのAWSマネージドプレフィックスリストを使用した場合、ウェイトは１であり、ユーザーがそれ以外に登録できる設定は59となります。
カスタマーマネージドプレフィックスリストにおける最大エントリ数と似ていますが、例えばDynamoDBの場合、実際に登録されているCIDRブロックは６ですが、消費される数は１となり、AWSマネージドプレフィックスリストを使用した場合に消費される数は実際の登録数よりも小さくなっています。
プレフィックスリストを使用して AWS インフラストラクチャ管理を最適化する
AWS IP アドレスの範囲
AWSサービスの一部のCIDRブロックはip-ranges.jsonとして公開されています。
公開されているの情報は、送信制限を行う用途が想定されるサービスのみです。
このファイルの解析を行うことによって必要な通信のみに通信を制限することが可能となります。
DynamoDBのような一部のサービスはAWSマネージドプレフィックスリストでも提供されています。AWSマネージドプレフィックスリストが利用できないサービス、より細かい制御を行う場合は、ip-ranges.jsonを解析し使用します。
AWSマネージドプレフィックスリストとは違い、ip-ranges.jsonには全てのリージョンの情報が格納されています。
ip-ranges.jsonはAWSによって更新されるため、更新された情報を取得し、常に最新の状態に保つ必要があります。
AWS サービスの IP アドレスを検索し、サービスへのアクセスを制限する
構文
{
"syncToken": "1723830789",
"createDate": "2024-08-16-17-53-09",
"prefixes": [
{
"ip_prefix": "3.5.140.0/22",
"region": "ap-northeast-2",
"service": "AMAZON",
"network_border_group": "ap-northeast-2"
},
{
"ip_prefix": "15.230.15.29/32",
"region": "eu-central-1",
"service": "AMAZON",
"network_border_group": "eu-central-1"
},
ユーザーガイドではヘッダ部とデータ部という分け方をしていませんが、便宜的に分けて説明します。
- ヘッダ部
| キー | 内容 | 型 | 例 |
|---|---|---|---|
| syncToken | UNIX エポック時刻形式での公開時刻。 | 文字列 | "syncToken": "1723830789" |
| createDate | 発行日時 (UTC YY-MM-DD-hh-mm-ss 形式) | 文字列 | "createDate": "2024-08-16-17-53-09" |
| prefixes | 配列内に含まれるデータがIPv4であることを示す項目 | 配列 | |
| ipv6_prefixes | 配列内に含まれるデータがIPv6であることを示す項目 | 配列 |
ip-ranges.jsonを使用する場合は、取得した情報を保持し、最新の情報かどうかをチェックする運用が必要となります。
syncTokenは名前の通り、取得済みの情報のsyncTokenと新たに取得したsyncTokenの比較に使用する項目です。
syncTokenとcreateDateは同時刻の形式違いのものです。createDateを使用する場合はUTCであることに注意してください。
- データ部
| キー | 内容 | 型 | 例 |
|---|---|---|---|
| ip_prefix | サービスが使用するIPv4CIDRブロックです。 | 文字列 | "ip_prefix": "15.230.15.29/32" |
| ipv6_prefix | サービスが使用するIPv6CIDRブロックです。 | 文字列 | "ipv6_prefix": "2600:1ff9:81d0::/46" |
| network_border_group | AWSがそのCIDRブロックをアドバタイズするネットワーク境界グループの識別子です。リージョン又はローカルゾーンを識別するID若しくはGLOBALが設定されます。 | 文字列 | "network_border_group": "us-west-2-lax-1" |
| region | リージョンを識別するIDまたはGLOBALが設定されます。 | 文字列 | "region": "ap-northeast-1" |
| service | サービスを特定する識別子です。全てのサービスのCIDRブロックを取得する場合はこの項目の値がAMAZONのものを使用します。 | 文字列 | "service": "DYNAMODB" |
範囲の重複
AMAZONサービス識別子から返されるCIDRブロック全てのサービスのCIDRブロックが含まれるため、S3等のサービス識別子からも返される可能性があります。
特定のサービス識別子のCIDRブロックを取得した場合に、内包するサービス識別子のCIDRブロックも併せて返される場合があります。
例えば、Amazon S3 は Amazon EC2 のリソースを使用するため、S3 と EC2 両方のサービスコードから返される IP アドレス範囲があります。ただし、これらの IP アドレス範囲は Amazon S3 でのみ使用されます。したがって、S3 サービスコードは、Amazon S3 でのみ使用されるすべての IP アドレス範囲を返します。Amazon EC2 でのみ使用される IP アドレス範囲を特定するには、S3 サービスコードではなく、EC2 サービスコードから返される IP アドレス範囲を探してください。
AWS の IP アドレス範囲の通知
AWSのCIDRブロック変更をSNSトピックの機能で通知を受け取ることができます。
VPC のIPv6 サポート
VPCは作成時にIPv6CIDRブロックを指定することも、後から追加することもできます。
VPCはIPv4及びIPv6の双方をサポートするデュアルスタックモードで動作し、IPv4とIPv6は、互いに独立して通信されます。
VPC の IPv6 サポートを追加する
デュアルスタックのセキュリティグループ設定の例
この例では、プライベートサブネットにDBサーバ用EC2インスタンス、パブリックサブネットにWebサーバ用EC2インスタンスを配置しています。
（簡略化のためアベイラビリティーゾーンは省略しています）
この例の場合、Webサーバのセキュリティグループには以下のようなインバウンドルールになります。
| タイプ | プロトコル | ポート範囲 | ソース | コメント |
|---|---|---|---|---|
| すべてのトラフィック | すべて | すべて | SG-Pri-xxxx | DBサーバに関連付けられたセキュリティグループからのトラフィックのすべてのインバウンドアクセスを許可します。 |
| HTTP | TCP | 80 | 0.0.0.0/0 | HTTP を介したインターネットからのインバウンド IPv4 トラフィックを許可します。 |
| HTTP | TCP | 80 | ::/0 | HTTP を介したインターネットからのインバウンド IPv6 トラフィックを許可します。 |
| HTTPS | TCP | 443 | 0.0.0.0/0 | HTTPS を介したインターネットからのインバウンド IPv4 トラフィックを許可します。 |
| HTTPS | TCP | 443 | ::/0 | HTTPS を介したインターネットからのインバウンド IPv6 トラフィックを許可します。 |
本題から外れますが、DBサーバのセキュリティグループには以下のようなインバウンドルールになります。
| タイプ | プロトコル | ポート範囲 | ソース | コメント |
|---|---|---|---|---|
| MySQL | TCP | 3306 | SG-Pub-xxxx | WEBサーバに関連づけられたセキュリティグループからの MySQL トラフィックのインバウンドアクセスを許可します。 |
IPv6 をサポートする AWS サービス
全てのAWSサービスIPv6をサポートしているわけではありません。
また、IPv6をサポートしていないサービスでも、PrivateLinkを使用したプライベートエンドポイントによってIPv6でのアクセスが可能なものがあります。
サービスごとにサポート内容がことなるため、詳細は公式サイトをご確認ください。
Discussion