各レイヤーのスペシャリストが集まった9月の「NW X Security JAWS勉強会」に登壇したのは、アマゾン ウェブ サービス ジャパンの荒木靖宏さん。ネットワークのスペシャリストと言えば荒木さんということで、AWSのIPv6対応について濃厚に語り尽くした。
お客様の使い方を考えれば、99%カバーできるIPv6対応
AWSのIPv6対応状況というセッションを披露したのが、AWSJ歴6年になる荒木靖宏さん。技術統括部 レディネスソリューションのマネージャーという肩書きだが、今も資格取得は続けており、研鑽を重ねていると自己紹介した。
荒木さんは、いったん決めたら変えられなかったVPCのCIDRブロックがあとから変えられるようになったという最新のアップデートを披露。残念ながらIPv6には未対応だが、メニューがグレーアウトしているだけなので「遠からず対応するはず」(荒木さん)という見込みを披露し、さっそく本題のAWSのIPv6対応に話を移した。
AWSはグローバルに100Gbps単位で冗長化したネットワークを張り巡らせており、中国以外のリージョンではIPv6にも対応している。今後、開設が予定されているパリやスウェーデン、香港、大阪(日本)などのリージョンにおいても、IPv6にネイティブ対応すると見込まれている。
とはいえ、90とも、100以上とも言われるAWSのサービスを見ると、IPv6の対応状況はけっこうまちまちだ。サービスごとのIPv6対応状況を披露した荒木さんは、「よく見るとIoTは対応しているけど、RDSとか対応してない。でも、IPv6でデータベースを晒すようなお客様はそんなにいないので、99%のお客様はこれでカバーできているはず」と語る。実際、Amazonには「Working Backwords」というポリシーがあり、お客様が使わないものはサービス化しない。IPv6も同じで、サービスを出してみて使われたらどんどん拡張し、使われなかったらやせ我慢して続けるというのが大まかな方向性になっているという。
2011年から始まったAWSのIPv6対応を振り返る
続いて荒木さんはAWSのIPv6対応の歴史を振り返る。最初にIPv6に対応したのは、現在のClassic Load Balancer(旧:ELB)で、IPv4のサーバーの手前でIPv4とIPv6を変換する役割を持っていたという。ただし、EC2 Classicしかサポートしていなかったため、VPC環境で利用できなかったため、昔のユーザーだけ使えていたというしろものだ。また、ELBは当初からデュアルスタック対応で、「Aレコード」「AAAAレコード」「どちらでも応答」という3つの設定を用意していた。「2011年5月というかなり早いタイミングでこのアップデートを施している。これは各コンテンツプロバイダーがIPv6対応を進めていた6月8日のWorld IPv6 Dayに合わせてのこと」とのことで、2011年がAWSにとってのIPv6元年だったという。
その後、久しぶりに現れたIPv6対応のサービスが、2015年に発表された「AWS IoT」だ。「目指すデバイス数が1億個と答えるお客様の声を聞くと、やはりスケールすることが重要になると考えている。そのため、AWS IoTはIPv6ネイティブ対応になっている」と荒木さんは解説する。
一方で黎明期から提供されているAmazon S3がIPv6対応したのは2016年8月とかなり最近「けっこう大騒ぎになると思ったら、全然ならなかった(笑)。みなさんIPv6でアップロードしてみたらわかりますが、速いですよ。ぜひ使ってみてください」と荒木さんはアピールする。ちなみにEC2とVPCは2016年12月にIPv6対応している。
その他、マネージドCDNのAmazon CloudFrontやWebアプリケーションファイアウォールのAWS WAFもIPv6に対応済みだ。「AWS WAFはいいサービスなのですが、ブロックリストが1万件くらいしか書けない。IPv6のアドレス数を考えたら、まだ現実的ではないかも」とは荒木さんの弁。荒木さんは、IPv6対応のサービスとして、AAAAレコード対応のみならず、クエリも使えるようになったDNSサービスのRoute53や、VPC環境でのIPv6対応やAWS WAF連携を実現するApplication Load Balancer(ALB)もあわせて紹介。Direct ConnectでAWSのVPCとユーザーのサイトをつなぐ場合も、もちろんIPv6が利用できるという。
VPCをIPv6で使うためのコツ
最後に荒木さんがトピックとして挙げたのは、VPCにおける利用方法の深掘りだ。まずVPCでIPv6を有効にした場合は、必ずデュアルスタックになる。ただし、IPv4とIPv6でルーティングテーブルなどが別なので、両者はそれぞれ設定が必要になる。「マネジメントコンソールでもIPv4がデフォルトで、IPv6はオプトインなので、たまにはIPv6もオンにしてやってほしい(笑)」と荒木さんは訴える。
AWSでIPv6を有効にしたVPCではグローバルユニキャストアドレス(GUA)が割り当てられ、それぞれのインスタンスに付与される。「Amazonが持っているIPv6のプレフィックスレンジのみ利用可能にしたアドレスなので、要はプライベートアドレスではない。それぞれのインスタンスにIPv6アドレスを割り当てても、ぶつからないことが保証されている。だから、IPv4のようなNATが存在しない」と荒木さんは解説する。ここが分散型のNATルーターが数多く配置されている既存のAWSのIPv4ネットワークとの大きな違いだ。
とはいえ、GUAの利用はセキュリティ問題の解消を意味するわけではない点に注意。「アドレス枯渇してから、すでにずいぶん時間が経っている。だから、NAPTの時代からプライベートアドレスだから安全、パブリックアドレスは危険という概念がお客様にもすり込まれている」(荒木さん)ということで、インターネットから直接見えるGUAに懸念を示すユーザーも多い。そのため、ルートテーブルやセキュリティグループ、ゲートウェイなどは別途できちんと設定する必要があるという。また、インターネットからのアクセスをVPC内からの通信のみに限定する「Egress-only Internet Gateway」という仮想ルーターも用意されている。
CIDRのブロックサイズが56ビット固定となる理由とは?
ただし、VPCでのIPv6利用に際してはいくつか制限があり、CIDRのブロックサイズはAmazon保有のプレフィックスから56ビット固定でアサインされる。この理由について、荒木さんは「アドレス空間が違うので、IPv6ですべてルーティングするには広大なメモリ空間が必要になる。でも、ルックアップに便利な機能を持つルーター用のメモリは非常に高価。そのため、フルルートでのIPv6対応はあきらめ、Amazon保有のアドレスだけでルーティングするようになっている」とためになる説明をしてくれた。
前述したとおり、IPv6の利用に際しては、セキュリティの懸念がつきまとう。これに対して荒木さんは、IPトラフィックに関する情報をキャプチャし、CloudWatch Logsへパブリッシュする「VPC Flow Logs」の利用を推奨する。また、収集したログはElastic Search+Kibana等で可視化するとよいという。荒木さんは「AWSのIPv6は日本だけ、米国だけではなく、世界中で使えます。IPv4とIPv6のデュアルスタックで使えるので、ぜひお試しいだきたい」と語り、IPv6愛にあふれたセッションを終えた。