Amazon VPCでの IPv6利用に向けた はじめの一歩 で登壇しました #cm_odyssey
コンバンハ、千葉(幸)です。
先日行われた Classmethod Odyssey というイベントで、「Amazon VPCでの IPv6利用に向けた はじめの一歩」というタイトルで登壇しました。
セッションの概要は以下の通り。
AWS上でのパブリックIPv4アドレスの利用について2024年2月より新たな料金体系が導入されました。従来通りの利用の仕方ではコスト増になるワークロードが多く、IPv6アドレスの利用が見直されています。Amazon VPCでIPv6アドレスを利用する際に何を考えればいいのか?そのはじめの一歩となる、基本的な考え方をご紹介します。
Amazon VPC で IPv4 は使ったことあるけど IPv6 はこれまでノータッチ、という方を主のターゲットとしています。
このブログでは、登壇資料の公開と、簡単な補足を行います。
Amazon VPCでの IPv6利用に向けた はじめの一歩 の登壇資料
Amazon VPCでの IPv6利用に向けた はじめの一歩 の登壇動画
Amazon VPCでの IPv6利用に向けた はじめの一歩 の登壇内容補足説明
簡単に補足説明をします。
アジェンダ
- IPv6の簡単なおさらい 〜このあとの話の土台になる話〜
- VPCでのIPv6利用 〜VPCやサブネットでの関連付け〜
- IPv6 on VPCでのゲートウェイ 〜3つのゲートウェイを押さえよう〜
- IPv6 on VPCへのインバウンド 〜リソースの対応状況を意識しよう〜
- IPv6 on VPCからのアウトバウンド 〜サービスエンドポイントの対応状況を意識しよう〜
- EC2でIPv6を使う時のTips 〜細かいあれこれをまとめて〜
1. IPv6の簡単なおさらい
- グローバルアドレスが豊富にあるためプライベートIPアドレス←→パブリックIPアドレスのNAT が不要
- IPv4 と IPv6 には互換性がないため、直接の通信はできない
- 必要に応じて変換を行うコンポーネントを間に挟む必要がある
- 単一のコンポーネントに IPv4 と IPv6 が同居していることを指してデュアルスタックと呼ぶことがある
- 例えば「デュアルスタックなVPC」「デュアルスタックな EC2 インスタンス」など
「NATが不要」を VPC 上の通信で考えた際のイメージは以下です。
2. VPCでのIPv6利用
- 利用の大前提として、VPCへのIPv6 CIDR ブロックの関連付けが必要
- 続いて、サブネットへの IPv6 CIDR ブロックの関連付けが必要
- 関連付けられるIPv6 CIDR ブロックの基本的なサイズは以下の通り。実質無限にIPアドレスを割り当てられる
- VPCは/56
- サブネットは/64
- IPv6 CIDR ブロックの関連付けを行った VPC 上のネットワークリソースでは IPv6 向けの設定が必要
- ここでのネットワークリソースとは、セキュリティグループやネットワーク ACL、ルートテーブルなどを指す
- ルートテーブルにおけるlocal向けのルートなど、デフォルトの設定は自動的に反映される
VPC には IPv4 CIDR ブロックの関連付けが必須であるため、取れる構成は「IPv4のみ」か「デュアルスタック」のいずれかです。
デュアルスタック VPC の中のサブネットでは、「IPv6のみ」の構成も取れます。(ただし、「IPv4のみ」で作成したサブネットを後から「IPv6のみ」に変更はできません。)
3. IPv6 on VPCでのゲートウェイ
- 以下の 3 つのゲートウェイを特に意識する
- インターネットゲートウェイ
- Egress-Only インターネットゲートウェイ
- NAT ゲートウェイ
3つのゲートウェイを簡単に整理すると以下となります。
ゲートウェイ種別 | IPv6特有か | 用途 |
---|---|---|
インターネットゲートウェイ | いいえ | IPv6でのインターネットとの双方向通信 |
Egress-Only インターネットゲートウェイ | はい | IPv6でのインターネットへの片方向通信 |
NAT ゲートウェイ | いいえ | IPv6クライアントからIPv4への通信時のNAT |
インターネットゲートウェイ、NAT ゲートウェイは IPv4 向けに用いるものと同じコンポーネントであり、(ゲートウェイそのものとしては)IPv6 向けに独自の設定変更をする必要もありません。
2種のインターネットゲートウェイの構成イメージは以下の通り。
NAT ゲートウェイの IPv6 向けの構成イメージは以下の通りです。
4. IPv6 on VPCへのインバウンド
- VPC 上の IPv6 リソースへ外部のクライアントが接続することを考えた場合、大前提としてクライアント側で IPv6 に対応している必要がある
- VPC 上での IPv6 を持つ主要なリソースのうち、「IPv6のみ」に対応しているのは限定されたもののみ
- 上記2点を踏まえると、VPC 上のリソースで外部向けのサービスを公開しているのであれば、「IPv6のみ」の構成を取るのはハードルが高い。 IPv4も共存させる必要がある
2024/09/26時点の主要なリソースの IPv6 対応状況は以下の通りです。
現時点では EC2 インスタンスのみが「IPv6のみ」に対応しています。2024年5月にパブリック IPv4 アドレスを持たないデュアルスタック ALB がサポートされるなど、IPv6まわりはアップデートが頻繁に行われている印象です。最新の情報をチェックしてください。
5. IPv6 on VPCからのアウトバウンド
- VPC 上の IPv6 コンポーネントがインターネット向けにアウトバウンド通信を行う場合、以下の考慮が必要
- 通信先が IPv6 の場合、2種のインターネットゲートウェイのいずれかが利用可能な状態である
- 通信先が IPv4 の場合、DNS64/NAT64 が利用可能な状態である
- AWS サービスエンドポイントで IPv6 に対応しているものはあまり多くない
AWS サービスの IPv6 サポート状況は以下ページにまとめられています。
このページの表における「Public endpoints support IPv6(パブリックエンドポイントの IPv6 サポート)」列が「Yes(はい)」になっているもののみが、サービスエンドポイントとして IPv6 をサポートしています。
2024/09/26時点では20個強程度のサービスのみがサポートしています。これはサービス全体から見るとかなり少ない数(1割未満?)です。VPC 上のコンポーネントが AWS の API を呼び出すのであれば、多くの場合 IPv4 を通信先とする必要があります。
また、IPv6 をサポートするサービスのエンドポイントであっても、「シングルスタックエンドポイント」と「デュアルスタックエンドポイント」が分かれているものがあります。
エンドポイントの対応状況を意識したり、AWS CLI などのツールでデフォルトで向いているエンドポイント URL を明示的に変更したりなど、考慮すべき点が多々あります。
(以下エントリでのAWS CLIの利用を試行錯誤している点をご参考ください。)
6. EC2でIPv6を使う時のTips
- EC2 インスタンスへのIPv6 の割当は大まかに以下2種類の方法がある
- サブネットの「自動割当」属性によりインスタンス作成時に自動で割り当て
- 作成ずみのインスタンスへの手動での割当
- IPv6非対応のインスタンスタイプもある
- 2024/09/26時点ではt1,c1,m1,m2,m3の限定的なもののみ。マネジメントコンソールから確認可能
- EC2インスタンスに IPv6 を割り当てれば、現行の OS では自動的に認識される。古いOSの場合、別途OS上で有効化が必要な場合がある
- デュアルスタック EC2 インスタンスにおいて IPv4 と IPv6 のどちらが優先されるかは OSによる
- 多くの場合 IPv6 が優先される。OS上の設定で明示的に優先度を指定できる
まとめ
- IPv6 のみでシステム全体を構成するのはハードルが高い
- システムの一部など、採用可能な場所で IPv6 の利用を開始し慣れていくのがよい
終わりに
Classmethod Odyssey での「Amazon VPCでの IPv6利用に向けた はじめの一歩」の登壇資料の公開でした。
2024年2月からのパブリック IPv4 アドレスの新たな料金体系により、VPC での IPv6 に対する需要が高まっているように感じます。わたし自身、利用を検討する中で改めて調べ直し、いくつか発見がありました。この登壇では初歩として意識すべきことをなるべく網羅的に盛り込みましたので、何らか参考になれば幸いです。
加えて、IPv6 関連のアップデートが活発に行われるようにもなった所感がありますので、ぜひ最新の情報の確認も忘れずにお願いします。
以上、チバユキ (@batchicchi)がお送りしました。
余談
本筋には関係ありませんが、動画を改めて見て思い出したところもあるのでおまけ的に記しておきます。
- 画面共有が外れる
登壇動画では途中で画面共有が一瞬途切れています。登壇当日もここ以外で何度か画面共有まわりでイレギュラーが発生したのでヒヤヒヤしました。(配信組のみなさん迅速なフォローありがとうございました)
- GoogleスライドをPDFエクスポートするとちょっと体裁が変わる
このブログに載せた「登壇動画」では Google スライドの原本を映しており、「登壇資料」では PDF エクスポートしたものをアップロードしています。
両者で微妙に体裁が異なることに後から気づきました。(テキストの大きさだったり、絵文字のテイストが変わったり。)
冒頭の自己紹介が「登壇資料」においては若干見切れていたので、ここで原本を供養しておきます。
こんにちば