AWS Public IPv4 Address Charge

https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/

https://aws.amazon.com/blogs/networking-and-content-delivery/identify-and-optimize-public-ipv4-address-usage-on-aws/

3.6 USD / address / month starting 2024 Feb

いい取り組みだと思うけどもう少し真面目に IPv6 singlestack に取り組んでからやってほしい、というのが正直な感想

AWS サービスの各種 API エンドポイントにおける dualstack 対応は形としてはあるけど実用には程遠い

各種 SDK で Endpoint の手動設定が必要な状況が続いている上に、全リージョンでのサポートがない場合もある https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Using_Endpoints.html#ipv6

この手の話は IPv4 singlestack でも問題なく生きれる現状、IPv6 adoption の必要性について各種ツールのメンテナーが理解してスムーズに移行してもらえるとは考えにくい

現状だと SDK を利用していればいい感じになるという状況では全くないので、利用している OSS 含めて対応を進めていかなければ IPv6 singlestack での運用が難しい

従って、SDK 側で手厚いサポートをするべき

SDK が読む設定や環境変数で dualstack endpoint を強制できるくらいの状況にならないとサポートしたとは言えない

接続できなくなるリスクがあって分けているのは理解できるんだけど、できればデフォルトで dualstack になってはほしい

かつ、自動でいい感じにできる実装がリリースされた後ある程度待たないとその実装が入ったバージョンの SDK を利用するツールは出回らないと思われるので、2024/2 までにそれが達成できるかは非常に疑問

バイナリもそうだし、Gemfile.lock, yarn.lock, go.sum みたいな依存のロックでも古い SDK を参照しうるため

SDK の動作もそうだが、現状でも各種サービスの API エンドポイントでのサポートは圧倒的に間に合っていないので対応を進めてほしい

それが困難なのであれば NAT Gateway の値下げや安価なプランがあってほしい

AWS の中から v6 only subnet だったら AWS API に対してだけ NAT64 利くとかでも良い……。

一旦 NAT Gateway を安くしてくれたら 2024/2 からでも強行可能だと思う

AWS API Endpoint 以外の IPv6 対応の欠けについて

AWS API Endpoint 自体の IPv6 dualstack 対応は先述の通り無いと思うしかない。真面目にやりきってくれ

Site-to-Site VPN は今すぐ v6 singlestack 対応してほしい

IPv6 only internet-facing ALB を作成することができない (検証した)

IPv6 only subnet だと作成できない。Addressing mode は ipv4 と dualstack の 2 択しかない

IPv4 経路なし、IPv6 は igw に向けた subnet に置くにも internet-facing ALB だと Public IPv4 Address がついてしまう。internal ALB だと外からアクセスできなくなる

internal ALB でも public subnet に置いたらアクセスされうると思ってたけどダメだった

CloudFront が IPv6 origin をサポートしてない (検証した)

まあ IPv6 only ALB を作成できない時点でダメなんですけど、CloudFront や Fastly などで IPv4 terminate して後は IPv6 singlestack の世界に出来れば Public IPv4 Address を利用しなくて済む

なお Fastly はサポートしていない模様 https://docs.fastly.com/en/guides/ipv6-support

Canonical っぽいけど {region}.ec2.archive.ubuntu.com も IPv6 対応ないんだよな

AL (cdn.amazonlinux.com) はちゃんと v6 enabled で偉い

Debian (deb.debian.org) も CDN だから v6 enabled で偉い。Debian は CDN の上に乗ってるの Debian を使いたくなる理由の一つ… (Ubuntu のリリースペースの方がありがたいので選択肢から外れがち)

ALB の IP アドレス数は ALB control plane が制御する ALB ノードのオートスケールの具合に左右されてしまう

仕様をちゃんと把握していないが、dualstack だとノードは必ず v4v6 両方のアドレスを持つ理解で良いのだろうか

さすがにたぶんそう

仮に IPv6 adoption がスムーズに行って IPv6 のトラフィックがマジョリティとなった場合、IPv4 トラフィックを処理する ALB ノードは IPv6 を処理するノードより少なくて済むはず。つまり、IPv4 アドレスの消費は少なくできるはず。ただ、ALB ノードが必ず dualstack になる仕様であれば public IPv4 address を ALB の都合で過剰に消費することにならないか?

ユーザー側での対処は IPv4/v6 の ALB を分けるしかない。これは運用面で painful。v6 only の internet-facing ALB も作成できないし、ALB の仕様として v6 only のオプションが必要

また dualstack にした場合でも IPv4 トラフィックの様子を見て不必要に Public IPv4 アドレスを確保しない動作になることが妥当なのではないか

つまり、A, AAAA レコードの数が現状だと等しくなると思っているが、そのような動作だと無駄に IPv4 アドレスを払わなければならなくなる可能性が高い

現実的にそんなシナリオが来るとはあんまり思ってないけど………。

現状の Workaround としては AWS Global Accelerator を利用するしかないか

internal dualstack ALB で問題なく AWS Global Accelerator からアクセスできていそう

AGA で 2 アドレス使ってしまう上に AGA の費用がかかるので 8 ノード以上くらいから効果ありそう

クライアント側の IPv6 対応の推進について

家庭や携帯回線の IPv6 対応は進みつつあり、enterprise が使うような回線でも IPv6 対応は十分可能だろうが、中小企業が利用するような回線では (冗長化を前提にすると) IPv6 対応がしづらい状況が続いていることは理解しているか。

今回のような取り組みは IPv6 adoption を前に進めるための良い取り組みだと思っている一方で、対応したくても妥当なコストで IPv6 対応をオフィスのネットワークに導入することができない状況でもある。各種キャリアや ISP にも IPv6 adoption を推し進めるような動きをしてもらえるとありがたいと感じている。

参考: https://datatracker.ietf.org/doc/draft-fbnvv-v6ops-site-multihoming/