🌐 Networking — IPv6 Migration

AWS IPv6サポート 完全ガイド
住所体系の大革命〜

「住所が足りない街」から「全世界に住所が行き渡る街」へ。
AWSでのIPv6移行を、街づくりのたとえで徹底図解。

📮
IPv4
43億個
🔄
移行期間
デュアルスタック
🌍
IPv6
340澗個
結論ファースト:このページで分かること

IPv4は「4桁の郵便番号」のようなもので、約43億個しか住所がなく枯渇が進んでいます。IPv6は「無限に近い住所体系」で、AWSはこの新しい住所体系への移行をデュアルスタックVPCIPv6専用サブネットエグレス専用IGWDNS64/NAT64などのサービスで全面サポートしています。古い住所しか分からない施設にも、翻訳サービス(DNS64/NAT64)を使えば新しい住所体系から問題なくアクセスできます。

たとえ話:「街の住所が足りなくなった!」
🏘️ ストーリー

ある巨大都市で「4桁の住所番号」(= IPv4)を使っていました。しかし人口爆発で住所が足りなくなり、市は「超長い新住所番号」(= IPv6)を導入することに。ただし、古い住所のお店もあるため、両方の住所を併記する期間(= デュアルスタック)が必要です。新住所しか持たない住民が古い住所のお店に行くには、翻訳窓口(= DNS64/NAT64)が必要になります。

🏙️ 街の住所体系ビジュアル
🏪
192.x
🏢
Dual
🏠
10.x
🏗️
2001:db8
🏬
Dual
🏥
fd00::
🏚️
172.x
🏛️
2001:db8
旧住所のみ(IPv4)
両方併記(デュアル)
新住所のみ(IPv6)
🏘️ 街の住所たとえ ☁️ AWS / ネットワーク用語 📝 役割
4桁の住所番号 IPv4アドレス 32ビット、約43億個の限られた住所
超長い新住所番号 IPv6アドレス 128ビット、ほぼ無限の住所空間
両方の住所を併記する地区 デュアルスタックVPC IPv4/IPv6の両方が使えるVPC
新住所のみの新興住宅地 IPv6専用サブネット IPv6だけで動作するサブネット
街の正面玄関 インターネットゲートウェイ IPv4/IPv6両方の出入口
出口専用の裏門 エグレス専用IGW IPv6のアウトバウンドのみ許可
翻訳窓口(電話帳+通訳) DNS64 / NAT64 IPv6→IPv4の住所・通信変換
IPv4 と IPv6 —— アドレス体系の比較
📮
IPv4(旧住所体系)
32ビットアドレス空間
約 43億個
🏘️ 「一つの都市の住所」くらい
→ 世界人口80億人に足りない
🌍
IPv6(新住所体系)
128ビットアドレス空間
約 340澗個
🌌 「地球の砂粒すべてに割当てても余る」
→ 3.4 × 10³⁸ 個のアドレス
📊 アドレス空間の規模を比較(対数スケール)
IPv4
4.3×10⁹
IPv6
3.4×10³⁸
IPv6のアドレス数はIPv4の約 7.9 × 10²⁸ 倍(790億×10億×10億倍)
IPv4
192.168.1.1
📮 4桁の旧住所
IPv6
2001:0db8:85a3:0000:0000:8a2e:0370:7334
🌍 超長い新住所
💡 なぜIPv6が必要? — IoTデバイスの爆発的増加(スマート家電・センサー・自動車等)により、1人あたり複数アドレスが必要な時代に。IPv4の43億では到底足りず、IPv6なら事実上無限に近いアドレスを提供できます。
AWSの IPv6 サポート — 5つの主要コンポーネント
🏗️ たとえ:市が実施した5つのインフラ整備

市が新住所体系に対応するため、5つのインフラ整備を実施。①旧新両方の住所が使える地区、②新住所専用の新興地区、③両方対応の正面玄関、④新住所住民用の出口専用裏門、⑤新→旧の翻訳窓口です。

🏠 ネットワーク基盤(VPC / サブネット)

1
🏘️
デュアルスタックVPC
IPv4とIPv6の両方のアドレスをサポートするVPC。既存環境を維持しながら段階的にIPv6へ移行可能。
🏘️ 古い住所と新住所の「両方が使える地区」
2
🏗️
IPv6専用サブネット
IPv6アドレスのみを使用するIPv6ネイティブなサブネット。IPv4アドレスの節約とコスト削減に最適。
🏗️ 新住所「専用」の新興住宅地

🚪 ゲートウェイ&翻訳(通信経路)

3
🚪
インターネットGW
IPv4/IPv6両方のトラフィックを処理する正門。
🚪 新旧両対応の「正面玄関」
4
🚶
エグレス専用IGW
IPv6のアウトバウンドのみ許可。外→内はブロック。
🚶 出口だけの「裏門」
5
🔄
DNS64 / NAT64
IPv6→IPv4の通信を自動翻訳する仕組み。
🔄 新→旧住所の「翻訳窓口」
デュアルスタック VPC アーキテクチャ全体図
☁️ VPC ネットワーク構成の階層図
🌐 インターネット(IPv4 + IPv6)
⬇️ ⬆️ トラフィック
🚪 インターネットGW
IPv4 + IPv6 双方向
🚶 エグレス専用IGW
IPv6 OUT のみ
⬇️
🏘️ デュアルスタック VPC
IPv4: 10.0.0.0/16
IPv6: 2001:db8::/56
🟢 パブリック
Webサーバー / ALB
10.0.1.0/24 + 2001:db8:0:1::/64
🟡 プライベート
DB / アプリサーバー
10.0.2.0/24 + 2001:db8:0:2::/64
🟣 IPv6専用
コンテナ / Lambda(IPv4不要なワークロード)
2001:db8:0:3::/64 のみ — IPv4アドレス不使用 → コスト削減!
🎯 ポイント:IPv6専用サブネットはIPv4アドレスを消費しないため、パブリックIPv4の有料化が進む中で直接的なコスト削減効果があります。コンテナ(ECS/EKS)やLambdaなど、パブリックIPが不要なワークロードに最適です。
NAT(Network Address Translation)の仕組み
📬 たとえ話:会社の私書箱サービス

内部社員(プライベートIP)が外部にお手紙を出すとき、「会社の代表住所(パブリックIP)」に差出人を書き換えます。外部からは全て「会社の住所」から届いているように見える。これがNATです。IPv4トラフィック専用で、IPv6では使いません。

1
🖥️ プライベートサブネットのEC2が送信
送信元: 10.0.2.15(内部住所)→ 外部へ通信したい
2
🔁 NATゲートウェイでアドレス変換
10.0.2.1554.xxx.xxx.xxx(パブリックIP)に書き換え
3
🌐 インターネットへ送信
外部には 54.xxx.xxx.xxx から来たように見える
4
↩️ 応答の逆変換
戻り通信も NAT が 54.xxx10.0.2.15 に戻してEC2に配送
⚠️ 重要:NATゲートウェイはIPv4専用。IPv6はすべてグローバルアドレスのためNAT不要。代わりにエグレス専用IGWでアウトバウンド制御を行います。
DNS64 と NAT64 — IPv6 → IPv4 への翻訳メカニズム
🗣️ たとえ:外国語しか話せない住民と日本語しか話せないお店

新しい街に来た住民(IPv6)は「新言語」しか話せません。昔からのお店(IPv4サーバー)は「旧言語」のみ。そこで、電話帳翻訳サービス(DNS64)がお店の住所を新言語に変換し、通訳窓口(NAT64)が実際の会話を双方向に翻訳してくれます。

📦 DNS64 + NAT64 で通信が繋がるまで(アニメーション)
🖥️ IPv6
クライアント
🔄 DNS64
+ NAT64
🖥️ IPv4
サーバー
IPv6パケット →
変換処理
→ IPv4パケット

📞 DNS64 の仕組み(電話帳翻訳)

1
🖥️ IPv6クライアントが名前解決を要求
「example.com のIPv6アドレス(AAAAレコード)を教えて」
2
🔍 DNS64がAAAAレコードを検索 → 見つからない
IPv4のAレコード(93.184.216.34)を取得
3
🔄 合成IPv6アドレスを生成
NAT64プレフィックス + IPv4 → 64:ff9b::93.184.216.34
4
📨 クライアントに合成アドレスを返答
クライアントは普通のIPv6アドレスだと思って通信を開始
🔬 合成IPv6アドレスの構造分解
64:ff9b::
93.184.216.34
64:ff9b::5DB8:D822
🟣 NAT64プレフィックス
(96ビット固定)
🟠 元のIPv4アドレス
(32ビット → 16進変換)
🔵 合成IPv6アドレス
(128ビット完成形)

🔄 NAT64 の仕組み(通訳窓口)

🖥️ IPv6クライアント
宛先: 64:ff9b::5DB8:D822
IPv6パケット
🔄 NAT64
ヘッダー変換
IPv4パケット
🖥️ IPv4サーバー
受信: 93.184.216.34
A
NAT64プレフィックスを検出・IPv4抽出
64:ff9b:: で始まるアドレスから IPv4部分(93.184.216.34)を抽出
B
パケットヘッダーを IPv6 → IPv4 に変換
IPv6パケットヘッダーを完全にIPv4形式に書き換え
C
IPv4宛先へ転送 & 応答も逆変換
戻りの通信は IPv4 → IPv6 に再変換してクライアントに届ける
連携まとめ:DNS64が「住所を翻訳」し、NAT64が「実際の会話を翻訳」。IPv6クライアントはIPv4サーバーと話していることを意識する必要がありません。すべて裏側で自動変換されます。
エグレス専用インターネットゲートウェイ
🚪 たとえ:出口専用の自動ドア

ビルの裏口に設置された「出口専用の自動ドア」。中→外は自由ですが、外→中は入れません。IPv6のプライベートサブネットが外部通信したいが外部からの接続は拒否したい場合に使います。

🚪
インターネットGW
✅ IPv4 + IPv6 対応
✅ インバウンド+アウトバウンド双方向
📍 パブリックサブネット向け
🚶
エグレス専用IGW
🔵 IPv6のみ対応
🚫 アウトバウンドのみ(インバウンド不可)
📍 プライベートサブネット向け
💡 使い分け:IPv4ではプライベート→外部にNATゲートウェイが必要でしたが、IPv6はすべてグローバルアドレスのためNAT不要。代わりにエグレス専用IGWで「外向き通信のみ許可」を実現します。
IPv4 vs IPv6 — 通信パターンの比較
通信シナリオ 🟠 IPv4 の方法 🔵 IPv6 の方法
パブリック → インターネット インターネットGW経由 インターネットGW経由(同じ)
プライベート → インターネット NATゲートウェイ経由 エグレス専用IGW経由
インターネット → プライベート 不可(NAT一方向) 不可(エグレス専用は出口のみ)
IPv6 → IPv4サーバー DNS64 + NAT64 で翻訳
アドレスコスト パブリックIPv4は有料 IPv6は追加料金なし
❌ IPv6導入前
すべてのインスタンスにIPv4アドレスが必要
NATゲートウェイの料金が発生
パブリックIPv4 に 1時間 $0.005
アドレス枯渇でスケールに限界
✅ IPv6導入後
IPv6専用サブネットでIPv4不要なリソースを分離
エグレス専用IGWでNAT不要に
IPv6は追加料金なし
ほぼ無限のアドレス空間で自由にスケール

💰 コストインパクトの試算例(EC2 100台の場合)

❌ IPv4のみの場合(月額)
〜$360 / 月
100台 × $0.005/h × 720h
パブリックIPv4アドレス料金のみ
✅ IPv6専用に移行した場合
$0 / 月
IPv6はアドレス料金なし
NATゲートウェイ料金も不要
年間 約 $4,320 のコスト削減 💸
どのサービスを使うべき? — 意思決定フローチャート
🧭 IPv6 コンポーネント選択フロー
❓ ワークロードにIPv4アドレスは必要?
はい — 必要
🏘️ デュアルスタック VPC
IPv4 + IPv6 の両方を割り当て
いいえ — 不要
🏗️ IPv6専用サブネット
コスト削減&アドレス節約
❓ プライベートサブネットから外部へ IPv6 通信する?
はい
🚶 エグレス専用 IGW
IPv6 のアウトバウンドのみ許可
いいえ
🚪 インターネット GW のみ
パブリックサブネット経由で通信
❓ IPv6クライアントからIPv4サーバーへのアクセスが必要?
はい
🔄 DNS64 + NAT64 を有効化
自動で IPv6 ⇄ IPv4 変換
いいえ
設定不要
IPv6ネイティブ通信のみで完結
AWS で IPv6 を有効化するステップ
1
VPC に IPv6 CIDR を追加
既存VPCにAmazon提供のIPv6 CIDRブロック(/56)を割り当て
2
サブネットに IPv6 CIDR を割り当て
各サブネットに /64 のIPv6 CIDRを割り当て(IPv6専用も選択可)
3
ルートテーブルを更新
::/0 → IGW(パブリック)、::/0 → エグレス専用IGW(プライベート)
4
セキュリティグループ / NACL を更新
IPv6通信ルール(::/0 や特定IPv6 CIDR)を追加
5
DNS64 / NAT64 の設定(必要に応じて)
IPv6専用サブネットからIPv4リソースへアクセスが必要な場合に有効化
# Step 1: VPCにIPv6 CIDRブロックを追加 aws ec2 associate-vpc-cidr-block \ --vpc-id vpc-12345678 \ --amazon-provided-ipv6-cidr-block # Step 2: サブネットにIPv6 CIDRを割り当て aws ec2 associate-subnet-cidr-block \ --subnet-id sub-12345678 \ --ipv6-cidr-block "2001:db8:0:1::/64" # Step 4: エグレス専用IGWの作成 aws ec2 create-egress-only-internet-gateway \ --vpc-id vpc-12345678 # Step 5: Route 53 ResolverでDNS64を有効化 aws route53resolver create-resolver-rule \ --rule-type FORWARD \ --name "dns64-rule" \ --domain-name "."
よくある質問
Q. IPv6に完全移行すべき?デュアルスタックのままでいい?
A. 現時点ではデュアルスタックが最も安全な選択肢です。IPv4のみのサービスがまだ多いため、IPv6専用サブネットはIPv4が不要なワークロード(コンテナ、Lambda等)から段階的に導入するのがベストプラクティスです。
Q. IPv6を有効にするとセキュリティリスクは増える?
A. IPv6自体がリスクを増やすわけではありませんが、セキュリティグループやNACLでIPv6ルールを適切に設定する必要があります。IPv6はNATを使わず全インスタンスにグローバルアドレスが付くため、ファイアウォール設定の確認が重要です。
Q. DNS64/NAT64はすべてのリージョンで使える?
A. DNS64はRoute 53 Resolverの機能、NAT64はNATゲートウェイの機能として提供されています。対応リージョンは拡大中ですが、最新状況はAWS公式ドキュメントで確認してください。
Q. 既存のEC2インスタンスにIPv6を追加できる?
A. はい。VPC・サブネットにIPv6 CIDRを追加後、既存ENIにIPv6アドレスを割り当て可能です。ただしOS側でもIPv6有効化が必要な場合があります。
Q. IPv6専用サブネットの制限事項は?
A. IPv4アドレスを持たないため、IPv4のみのAWSサービス(一部のエンドポイント等)と直接通信できない場合があります。DNS64/NAT64を併用するか、VPCエンドポイントのIPv6対応を確認してください。

📋 まとめ:AWS IPv6 サポートの全体像

🏘️
デュアルスタックVPC
IPv4/IPv6両対応
安全な移行の出発点
🏗️
IPv6専用サブネット
IPv4不要なワークロード
でコスト削減
🚪
インターネットGW
IPv4/IPv6両方の
双方向通信を処理
🚶
エグレス専用IGW
IPv6のアウトバウンド
専用ゲートウェイ
🔄
DNS64 / NAT64
IPv6→IPv4の
自動翻訳サービス
💰
コスト最適化
IPv4有料化で
IPv6移行メリット大

Created by SSuzuki1063

AWS SAP Learning Resources