Amazon Web Services で IPv6 を使う
AWS で IPv6 がどの程度使えるかと、使う方法をざっくりとまとめました。(手順の詳細は割愛します。)
参考)
IPv4 の現状
2011 年 2 月、IANA による最後の IPv4 アドレスブロックの割り当てが完了したという大きなニュースからはや 10 年。アドレスが枯渇すると言われて久しい IPv4 ですが、今はどうなっているのでしょうか。「そんなのあったねえ」なんて、一過性のブームみたいに捉えられていないでしょうか。
現在の IPv4 アドレスプールの残りは IPv4 Address Report で確認することができます。さすがにいよいよ限界な気がします。自粛要請が必要です。
IPv6 化のメリット・デメリット
大量の IP アドレスが利用可能(?)
IPv4 の場合、ひとつの VPC に割り振れるアドレスは 16bit (65,536 個) まで。サブネットを分ける場合は各サブネット作成時にこれを振り分ける必要があり、あとから変更することはできません。一方 IPv6 は各サブネットで常に 64bit (1844 京) が使えるので、実質無限です。とは言え、IPv4/IPv6 のデュアルスタックなので、結局 IPv4 アドレスの数で作成できるインスタンス数は頭打ちです。惜しい！(誰がそんなに使うんだって話しですが)
IPv4 グローバルアドレス、Elastic IP が不要(?)
AWS から固定の IPv6 プレフィックスが割り当てられ、個々のホストも固定の IPv6 アドレスとなります。有限のグローバル IPv4 アドレスを取り合う必要がありません。とはいえ直接公開することも少ないでしょうし、IPv4 でのアクセスも必要な場合は必要になります。管理用にグローバルアクセスが必要なだけであれば、IPv4 グローバルアドレスを消費せず節約にささやかながら貢献しましょう！
NAT が不要(?)
IPv6 ではすべてのホストがグローバルアドレスを持ち、アドレス変換が不要となります。とは言え外部からの通信には IPv4 同様、Internet Gateway が必要になります。Internet Gateway への経路がないプライベートサブネットからインターネットへ IPv6 で通信するには、NAT の代わりに Egress Only Internet Gateway を設置します。これは NAT と違い無料なので、プライベートサブネットからの通信が IPv6 だけで良いのであれば、NAT ゲートウェイ/インスタンスのコストが不要になります。外部からプライベートサブネット内へのインバウンド通信は NAT 同様に防がれます。
注意
- 現状 AWS API の IPv6 対応は進んでいないため、プライベートサブネット内から AWS リソースにアクセスするにはやはり NAT または VPC エンドポイントが必要になります。
- Lambda も IPv6 対応されていないため、VPC に収容した Lambda からインターネットや AWS リソースにアクセスするにはやはり NAT や VPC エンドポイントが必要になります。
デメリット: 管理コストが増える
IPv6 化しても IPv4 を無効化することはできず IPv6 だけではできないこともあり、通常デュアルスタック運用が必要となり管理すべき項目が単純に増えます。セキュリティ面も意識する必要があります。IPv6 に起因するトラブルが発生する可能性もあるでしょう。完全に IPv6 だけにできれば良いのですが...まだまだ先のことです。
(Updated June 2021) IPv4 を無効化して IPv6 のみ有効なサブネットを作成できるようになりました。(Introducing IPv6-only subnets and EC2 instances)
デメリット: アドレス指定が面倒
アドレスが長くて覚えづらいですか？僕は IPv4 でも覚えていないので問題ないです。
設定方法
Amazon VPC/EC2
- VPC に対して IPv6 を有効にする。
- 56bit プレフィックスが自動的に割り当てられる(選択は不可)。
- 各サブネットに対して残りの 8bit を振り分ける。
- プライベートサブネットからインターネット通信をする場合、NAT の代わりに Egress Only Internet Gateway が必要(無料)。
- IPv6 ではグローバルアドレスのみなのでアドレス変換なく外部と通信ができるが、外部から内部への向きの通信はできないことでセキュリティを確保する。
- ルートテーブル、セキュリティグループ、ネットワーク ACL に適宜 IPv6 の設定を追加する。
Amazon CloudFront
- 「Enable IPv6」設定を有効にする(デフォルト有効)。
- カスタムドメイン運用時は AAAA レコードも CloudFront ディストリビューションに向けること。
Elastic Load Balancing
- インターネット向け ALB および NLB のみ対応。
- VPC に対して IPv6 が有効であり、ALB を収容するサブネットに IPv6 サブネットを割り当て済みであること。
- 「IP アドレスタイプ」に「dualstack」を選択する。
- カスタムドメイン運用時は AAAA レコードも ALB に向けること。
補足
- ALB エンドポイントに「dualstack」がつくものとつかないものが存在しますが、どちらを使っても変わらないようです。
- 例) dualstack.xxxxxxxx.ap-northeast-1.elb.amazonaws.com
- Elastic Beanstalk からは ALB に IPv6 を設定できないようです。作成された ALB に直接設定すれば有効にすることはできますが、AAAA レコードを Alias 設定する場合、Beanstalk のエンドポイントへ向けることはできないので、生成された ALB のエンドポイントに直接向ける必要があります。
Amazon S3
デュアルスタックのエンドポイントを指定することで、IPv6 でのアクセスをおこなうことができます。ただし、VPC エンドポイントは IPv6 には対応していないため、VPC エンドポイントを経由することはできません。
参考) Amazon S3 デュアルスタックのエンドポイントを使用する
例えば AWS CLI でデュアルスタックのエンドポイントを使用するには、以下を設定します。AWS SDK での方法は各言語の SDK を参照してください。
aws configure set default.s3.use_dualstack_endpoint true
これにより、~/.aws/config に以下のように設定されます。
[default]
s3 =
use_dualstack_endpoint = true
その他
以下のサービスも IPv6 対応しています。
- AWS IoT (これこそ IPv6 の出番ですね)
- AWS WAF
- Direct Connect
- Route 53
他に欲しいところとして、以下のサービスは未対応のようです。今後に期待しています。
- Amazon API Gateway
- Amazon RDS
- AWS Elastic Beanstalk
- AWS Lambda
- VPC Endpoint
さいごに
こうやって見てみると、正直まだ制限も多く IPv6 対応しようというモチベーションにつながるものがないのも事実です。IPv6 界隈そんな感じでずっときてはいますが、インフラの IPv6 化は着実に進んできています。クラウドサービスの IPv6 対応は遅れているほうではないでしょうか。顧客要望がない状況でも、インターネットの未来を牽引していって欲しいものです。
Discussion