こんにちは!エンタープライズクラウド部ソリューションアーキテクト1課の足達です。
本ブログは、AWS上でIPv4からIPv6への切り替えを行う際に想定される作業の流れや影響についてまとめたものになります。
はじめに
「IPv4アドレス枯渇問題」が騒がれる昨今、IPv6への移行を検討している方も多いのではないでしょうか?
この流れに拍車をかけるかの如く、AWSでは2024年2月から、パブリックIPv4アドレスへの課金を開始しました。
今回は、「IPv4からIPv6へ切り替えた際にどのような影響が考えられるのか?」ということについて調査する機会があったため、そちらの内容をまとめていきたいと思います。
想定される影響
調査前の段階で私が想定していた影響(懸念点)は以下の4つです。
- 環境を1から作り直す必要があるのか?
- IPv6がサポートされていないAWSサービスがシステムに含まれていないか?
- オンプレミスとの接続に問題はないのか?
- IPv4専用のサービス(IPv6未対応のサービス)は利用できなくなってしまうのか?
これらの懸念点が解消されれば、IPv6移行に向けた検討がよりスムーズに進められると考えました。
本ブログにおいても、これらの懸念点に回答する形式でまとめていきます。
環境を1から作り直す必要があるのか?
結論、既存の環境にIPv6のアドレス範囲を後から追加することが可能です。
後述の導入方法でも軽く触れますが、既存のVPCに対して、新たなCIDR範囲としてIPv6を割り当てるだけのため、追加自体はとても簡単に行えます。
注意点としては、一部IPv6特有の接続方法が存在しているため、それらについては再構成、あるいはリソースの追加が必要となる場合があります。
例えば、プライベートサブネットからインターネットへ向けた通信が求められた際、IPv4ではパブリックサブネットにNATゲートウェイを設置する必要がありましたが、IPv6ではNATゲートウェイの設置は不要となり、EgressOnly Internet Gatewayを利用することで外向きの通信が可能となります。
また、2024年7月現在、AWS環境でIPv6を導入する場合は、既存のIPv4とIPv6を併用するデュアルスタックのみがサポートされているため、VPCからIPv4のアドレス範囲を完全に削除することは出来ませんので注意が必要です。
滅多にないケースかとは思いますが、もし完全にIPv6のみの通信を行いたいという要件がある場合は、
- セキュリティグループのルールでIPv4からの通信を許可しない
- Route 53のレコードでAAAAレコードのみを作成する
- IPv6の接続のみに対応しているALBを使用する
などの対策が必要となります。
ひとまず、環境を1から作り直す必要はないということが分かりホッとしました。
IPv6がサポートされていないAWSサービスがシステムに含まれていないか?
こちらも結論から述べますと、AWSの基本的なサービスではIPv6がサポートされており、何らかの方法でIPv6を使用することが可能です。
以下がIPv6に対応しているサービスとなっておりますが、表に記載されていないサービスを利用する可能性がある場合は注意が必要ですので、本格的にIPv6の導入をお考えの方はよくご確認ください。
docs.aws.amazon.com
とはいえ、こちらの情報は更新されていくものですので、IPv6に対応するサービスは今後も増加していくことが予想されます。
オンプレミスとの接続に問題はないのか?
オンプレミス環境とAWS環境の接続には、AWS Site-to-Site VPNやAWS Direct Connectを使用することが多いかと思われますが、
先程の表を見てみると、どちらもサポートされていることが分かります。
このことから、IPv6を使用したオンプレミス接続は可能であることが分かると思います。
IPv4専用のサービス(IPv6未対応のサービス)は利用できなくなってしまうのか?
こちらについては、NAT64およびDNS64という機能を使用することで、IPv4専用リソースとの通信も可能となります。
機能の提供開始当時はリージョンによる制限があったようですが、その後まもなくしてリージョンによる制限は緩和されたようです。
AWS上でのIPv6の導入方法
いくつかの注意点はあるものの、IPv6の導入自体には大きな問題はなさそうということが分かったところで、実際に導入する際の手順についてもまとめていきたいと思います。
IPv6を導入する手順は大きく以下の4ステップとなります。
- IPv6 CIDR ブロックをVPCおよびサブネットと関連付ける
- ルートテーブルを更新する
- セキュリティグループを更新する
- IPv6アドレスをインスタンスに割り当てる
※デュアルスタックのみとなっており、VPCの中からIPv4を削除することはできません。
※サブネット単位ではIPv6のみを割り当てたサブネットを作成することは可能です。
追加手順自体はそこまで複雑ではないようです。
しかし、ルートテーブルやセキュリティグループにIPv6用のルートを追加してあげる必要があるため、環境の規模が大きい、あるいはルートを細かく制御している環境であるほど作業の手間は大きそうです。
また、先述の通り、IPv6特有の構成については再度構成の見直しが必要となるため、実際に移行するかどうかは、手間と移行のメリットをしっかり見比べる必要がありそうです。
まとめ
基本的には何かしらの方法でIPv6を使用できるため、IPv6へ切り替えたからといってシステムが動かなくなるという心配はなさそうでした。
しかし一方で、一部構成を工夫する必要がある点や、ルートテーブル・セキュリティグループを編集する手間が発生するという点でのコストについても考慮する必要があるようでした。
内部的なネットワークに限られているなどIPv4のアドレス範囲でも事足りるような場合や、IPv6への切り替えが必須ではない場合は無理に切り替える必要はなさそうでした。
いずれにしても、切り替えによるメリットだけを見るのではなく、コストや手間を天秤にかけて比較検討したうえで進めていく必要がありそうです。