AWSの顧客はIPv4から脱却できない

 (tty.neveragain.de)
1 ポイント 投稿者 GN⁺ 2023-09-24 | 1件のコメント | WhatsAppで共有
  • AWSは2024年2月から専用パブリックIPv4アドレスに対して1時間あたり $0.005 を課金するが、AWSサービスの制約により顧客がIPv6でこのコストを回避するのは難しい
  • 課金対象はElastic Load Balancer、EC2/Elastic IP、パブリックIPが設定されたECS Fargateタスク、Global Accelerator、Site-to-site VPN、RDS、Managed NAT Gatewayなど広範囲に及ぶ
  • EC2、VPN、Transit Gateway、Direct Connect、Network FirewallなどはIPv6ベースで動作する一方、API Gateway、Lambda、ECS、App Runnerといった中核サービスは IPv6-only サブネット を拒否したり、十分にサポートしていなかったりする
  • 内部をデュアルスタックで構成しても、サービスAPIエンドポイントの 90%以上 がIPv6をサポートしておらず、VPCでパブリックIPv4なしにS3、Systems Manager、SQSなどを使うのは難しい
  • 大口顧客では請求額の1%未満に収まることが多く移行動機が弱い一方、SMB・趣味ユーザー・スタートアップは10〜30%のコスト増になる可能性があり、負担が大きい

2024年2月から専用パブリックIPv4を課金

  • AWSは2024年2月から 専用パブリックIPv4アドレス ごとに1時間あたり$0.005を課金
    • 月額ではほぼ$4、年額では$40超に相当
    • AWS所有のIPに適用され、顧客がルーティング可能なパブリックIPv4ブロックを持ち込む BYOIP のアドレスは課金対象外
  • 課金対象はパブリックIPv4を直接利用する主要リソース全般に及ぶ
    • Elastic Load Balancer
      • アベイラビリティゾーンごとに1アドレスを使用
      • 最低2つ必要で、IPv4を無効化できない
    • EC2インスタンスとElastic IP
    • パブリックIPが設定されたECS Fargateタスク
    • Global Accelerator IP
    • Site-to-site VPN IP
    • RDS
    • Managed NAT Gateway
  • 共有IPv4アドレスは対象外
    • CloudFrontディストリビューションやAPI Gatewayエンドポイントで使われる共有アドレスは課金されない
    • VPC外部のLambda関数が使用するパブリックIPv4アドレスも対象外

コストが大きく増える構成

  • 3つのアベイラビリティゾーンに構成されたパブリックElastic Load Balancerは、基本料金が50%以上 上昇する
  • Managed NAT Gatewayは基本料金が約 10% 上がる
    • NAT Gatewayはアベイラビリティゾーン単位の冗長性を提供しない
    • アウトバウンド接続が重要なら、各アベイラビリティゾーンごとにNAT Gatewayが必要
  • 特にアドレスを多く浪費する2つのパターンが大きな影響を受ける
    • VPCごとに複数のLoad Balancerを置く構成
      • 複数のCloudFormationテンプレートやTerraformモジュールを組み合わせたり、Kubernetes ingress controllerがサービスごとにLoad Balancerを作成したりする場合に発生
      • 1つのLoad Balancerで複数のURLやサービスを処理できる
    • Managed NAT Gatewayを避けるため、EC2インスタンスやFargateタスクに意図的にパブリックIPv4を付与する構成
      • 皮肉なことに、アベイラビリティゾーンあたりのパブリックIPv4アドレスが約10個に達するまでは、この方法のほうが依然として安価

現在の使用量の確認方法

  • パブリックIPv4アドレスの使用量はすでにアカウントで集計されている
    • 現在は$0と表示されるが、2024年2月からは1時間あたり$0.005が請求される
  • 確認方法は次のとおり
    • Billing Dashboard > Bills
      • Virtual Private Cloudセクションで PublicIPv4:InUseAddress として表示
    • Cost Explorer
      • PublicIPv4:InUseAddress のみを含むようにフィルタすれば、日次・時間単位の使用量を確認できる
      • メンバーアカウント単位でのグループ化も可能
    • VPC > VPC IP Address Manager > Public IP insights
      • パブリックIPv4使用量の概要を確認できる
      • IPAMのこの部分は無料
      • アカウント・リージョン単位のデータしか表示せず、一時的に使われたアドレスは捉えられないため、データは不完全

IPv6導入の2つの方法

  • IPv4アドレスにはコストがかかり、IPv6アドレスは無料なので、表面的にはIPv6移行が自然な選択に見える
  • IPv6にはプライベートアドレスの概念がなく、Managed NAT Gatewayとそのコストを回避できる
  • IPv6導入には大きく2つの方法がある
    • デュアルスタック
      • すべてのシステムにIPv4とIPv6アドレスを併せて設定する
    • 内部IPv6-only
      • 内部ではIPv6のみを使用し、一般ユーザーと接するエッジやCDNでのみIPv4接続性を提供する
  • 米国大統領府のメモランダムでは、デュアルスタック運用は維持が過度に複雑で不要になりつつあり、標準化団体や主要テクノロジー企業がIPv6-only展開へ移行し始めていると明記している
  • AWSの基本的なIPv6ネットワーク対応自体は比較的よく整っている
    • IPv6-onlyサブネットでIPv6-onlyのEC2インスタンスを構成できる
    • ローカルDNS、時刻サービス、ホスト設定、セキュリティなど、IPv6ネットワークで期待される機能が動作する
    • VPN、Transit Gateway、Direct Connect、Network FirewallもIPv6をサポートする

AWSサービス利用の段階で詰まるIPv6

  • ボトルネックはネットワーク自体よりも、他のAWSサービスと接続する段階 に現れる
  • API Gateway、Lambda、ECS、App Runnerのような中核サービスは、IPv6-onlyサブネット構成を拒否したりエラーを返したりする
    • Elastic Load Balancerは Not enough IP space available のようなエラーを出すことがある
  • 内部をデュアルスタックにしても十分ではない
    • 多くのサービスは、サブネットにIPv6が設定されていてもそれを無視する
    • IPv4の宛先にしか接続できないことが多い
  • VPCでパブリックIPv4アドレスなしにサービスAPIを使うのは難しい、あるいは不可能なケースが多い
    • EC2インスタンスで aws s3 ls の実行が失敗する
    • インスタンス接続と管理の推奨手段であるSystems Managerが動作しない
    • ECS TaskからSQSへアクセスできない
  • AWS IPv6対応状況 によると、サービスAPIエンドポイントの 90%以上 がIPv6をサポートしていない
  • SES SMTP、ECR repositoryエンドポイントも動作せず、CloudFrontはIPv6 originに接続できない
    • ECRではECSタスクを起動できないが、IPv6をサポートするDocker Hubなら可能
    • Docker Hubはpullにレート制限を適用している

PrivateLinkは代替手段だがコスト制約が大きい

  • 多くのサービスは PrivateLink で接続できる
    • 顧客VPCへ直接接続するため、パブリックIPアドレスは不要
    • ただし、すべてのサービスをサポートしているわけではない
  • PrivateLinkは サービスごと・アベイラビリティゾーンごと に課金される
    • エンドポイントあたり月額約$9
    • たとえばSecrets Manager、EC2、SSM、SSM-Messagesを3つのアベイラビリティゾーンで接続すると、VPCあたり年間$1,200超になる
    • 追加のトラフィック料金も発生する

IPv4課金がIPv6移行につながりにくい理由

  • 規模の大きい顧客にとって、IPv4課金はおおむね 請求額の1%未満 であり、大きな変化とは感じにくい
    • このコストだけで意味のあるエンジニアリング投資が起きる可能性は低い
  • SMB、趣味ユーザー、スタートアップにとっては、料金が請求額の 10〜30% まで増える可能性がある
    • 彼らにはコスト回避のためにIPv6を導入する動機がある
    • しかしAWSサービスのIPv6対応の空白により、IPv4コストを避ける手段は限られている
  • 最近のIPv4確保コストを考えれば、IPv4アドレス課金自体は必要かもしれない
  • AWS全体でのIPv6対応が成熟していれば、より多くの顧客がIPv6-only環境へ移行できるはず
  • 現状のIPv6はAWSにおいて 第一級の市民 とは言いがたく、この状況ではIPv4課金によって、個人アカウント、学習、資格試験準備、オープンソース支援のためのAWS利用の魅力が下がってしまう

関連記事

1件のコメント

 
GN⁺ 2023-09-24
Hacker Newsのコメント

  • ずっと昔、Amazonでジュニア開発者だったころ、社内システムをすべてリージョン別バージョンに分割し、リージョン間呼び出しは限定されたゲートウェイ経由でのみ許可するという大規模な社内プロジェクトがあった
    理由は社内のIPv4アドレスが枯渇したためだった
    「単にIPv6に変えればよかったのでは？」という質問に、担当のPrincipal PMは「現在保有している社内ネットワーク機器のうち、IPv6をサポートできないものが多すぎて、置き換えるには世界の年間生産量に近い機器を買って全部設置する必要があったはずだ」といった趣旨の答えをしていた
    AmazonがIPv4まわりで悪意ある振る舞いをしているように見えがちだが、AWSシステムの規模を考えると、古いネットワークハードウェアをすべて短期間で置き換えるのはあまりに大きなプロジェクトだった可能性も十分に信じられる

    • それが何年ごろだったか覚えているか気になる
      多少はたわごとだったか、少なくとも事実を創造的に包み直した話ではないかという疑いがある。たとえば実際にはすべてIPv6対応していたが、恐怖・不確実性・疑念に満ちたネットワークエンジニアたちが有効化したがらなかっただけかもしれない
      私が見てきたネットワーク機器の大半は、周囲でIPv6が実際に使われるずっと前からデュアルスタックで、米国政府や軍の要件が理由で入ったものだとずっと思っていた
    • そのリージョン化は覚えている。傍から見ていても「面白い」仕事だった。私は最初からリージョン別に作られた新規サービス側にいた
      そのプロジェクトのPMが誰だったかは覚えていないが、当時TPMが生み出せる価値を本当に尊重するようになった
      コストとネットワーク機器の交換が必要になることが、IPv6に進まなかった強い理由の一つだったという話は正しい。Amazonはさまざまな理由で自社設計・製造のネットワーク機器を使っていて、おそらく今もそうだろう
      それらの機器はすべて固定メモリ容量だったため、IPv6ルーティングテーブルなどを扱えるだけのメモリを増やすには交換が必要だった。IPv6専用を選んだとしても既存機器では足りなかっただろうし、いずれにせよIPv4/IPv6デュアルスタックなしでは通すのも難しかった
    • そのPMはたぶんLaura Gritで、実際にはTPMだったのだと思う。Lauraは今ではDistinguished Engineerだ
      いつも途方もない規模のプロジェクトをやっているようで、IPv4は今となってはその中では小さな柱の一つに入る。今取り組んでいる大きなプロジェクトのいくつかは残念ながら共有できない
      何度か時間を取ってもらって賢明な助言を受けたことがあり、感謝している
    • 古いネットワークハードウェアをすべて短期間で置き換えるのがあまりに大きなプロジェクトなら、Amazonは社内のどこでもIPv6をサポートできるよう置き換えを完了するまで、短いスケジュールでIPv4課金を押し進めるべきではない
    • だからといってIPv6の段階的導入をしなくてよいわけではない。この問題を永遠に先送りすることはできない
      きっとすでに手順を始めているのだろう
      そうだよね？ AWSが頭を砂に突っ込んでこれを無視しているとは想像しにくい

  • AWSがきちんと動作するIPv6を提供するのは、インセンティブに明らかに反しているように見える。AWSの影響力を持つ道具、たとえばWell-Architected基準や認定は、エンドツーエンドのアドレス指定があるインターネット的なアーキテクチャではなく、曖昧にアドレスが付いた10.x RFC1918ネットワークの迷路を作るよう強く誘導している
    AWSの推奨事項の世界では、「パブリックIPアドレス」という概念そのものが危険信号であり、AWSは追加料金を取ってそうしたアドレスを表示し「緩和」するツールまで推奨している
    顧客にセキュリティの名目で複雑なインフラを構築する労力を使わせれば、強いロックイン効果が生まれる。実際には不要な複雑性やアドレスの曖昧さなどによってセキュリティを損なっているにもかかわらずだ

    • Azureもこれを丸ごとまねしている
      「Private Endpoints」「Private Links」「Service Endpoints」「Private Resolvers」「Virtual WAN」のような製品がどれほど出てきたか数え切れなくなっていて、すべてIPv4を大規模に回すためのものだ
      IPv6をきちんと動作させていれば、こうした製品は文字どおり一つも必要なかった
      その代わりAzureはIPv6もNATするので、IPv4のせいで強制されるNATを避けるためにIPv6を使うこともできない。2023年になってもIPv6をサポートせず、今後もそうである可能性が高い新製品を出している
      ドキュメントには今でも制限事項がページ丸ごと残っている: https://learn.microsoft.com/en-us/azure/virtual-network/ip-s...
      これがIPXからIPv4への移行だったと考えると、どれほど筋が通らないか分かる。このページに「IPv4の制限事項: すべてのVMは少なくとも1つのIPXアドレスを含む必要がある」といった具合に書かれているようなものだ
      奇妙に聞こえないだろうか？ 1999年に顧客をIPXからIPv4へ移行させていて、IPv6対応はおおむね2001〜2003年ごろに現れた。何十年も経ったのに「まだすべてがIPv4をサポートしているわけではないのでIPX+IPv4が必要だ」と言っていたNovell NetWare移行前の時代のような感じだ
      このリストは決して制限事項の全体ではない。ほとんどのPaaS製品がIPv6をサポートしていないため、IaaS+PaaSの解決策は結局ほとんどIPv4を使わざるを得ない
    • AWSだけの問題ではない。Microsoft、セキュリティ監査人、ペネトレーションテスター、サイバー保険会社なども、おおむね公開アドレス指定可能なエンドポイントを置かないよう求める
      なぜそうなのかは理解できないが、どこかの大手テクノロジー企業がエンドツーエンドのアドレス指定をベストプラクティスとして推すまでは、危険信号を作らないために既存の通念に従うしかない
    • Azureで働いているが、私の経験では顧客がこれを望んでおり、それには相応の理由もある
      顧客は、自分が所有していないマシン上でも侵入やデータ流出を防ぐために、自分専用のプライベートネットワークを求めている。さらに、バッテリー同梱型の充実したPaaSサービスもそのネットワーク内に入れたがっている
    • この2つが関連しているとは確信していない。AWSが望めば、IPv6が内部ネットワーク問題をすべて解決する万能薬だと宣伝できたし、実際に動作するなら競合他社が追いつくのは難しかったはずだ
      私の推測では、理由はもっと平凡だ。AWSのサービス数まで考えると、IPv4対応のほうが単に楽なのだ
    • 内部サービスへの外部アクセスを防ぐことが、どうセキュリティを損なうのか分からない

  • AWS の顧客として、私は IP そのものから離れたい。IP、BGP、DNS のような古いプロトコルで構成された複雑なネットワーキングシステムを管理するのは時間の無駄だ
    ワークロードに強いアイデンティティをひも付け、どのワークロードがどのワークロードとデータをやり取りできるかだけをポリシーで適用できればよい
    データがあるワークロードから別のワークロードへどう到達するかは、私の関心事であるべきではなく、ただ動いてくれればよい

    • 完全に同意する。ちなみに、こういう感覚があるから、最近はそうしたことをやってくれるクラウド「プラットフォーム」がたくさん生まれている
      仮想化されたデータセンター、つまりまね事のネットワーキングの構成要素の動物園にはまる代わりに、すべて抽象化してしまうのだ
    • その感情は妥当だが、こうした主張は人々がローコード解決策を語るときの論理に似ている
      現実には一度もまともに機能したことがなく、今後もそうはなり得ない。実際のワークロードを実行し最適化するには、考慮すべきニュアンスや細部が多すぎる
    • 「大局を見る人たち」も、その大局が細部を解決してくれないとなると、突然細部を気にし始める
    • Heroku みたいなものか？ 何年も Heroku を使っていないので、今の状態は分からない
    • インターネットプロトコルなしでインターネットが欲しいということ？

  • AWS で IPv6 のみにするとき、私の経験上いちばん大きな問題は、GitHub がまだ IPv6 に対応していないことだ。多くのソフトウェアは、何かを取得するために GitHub へ接続できると仮定している
    公開 NAT64 サービスを使うことはできるが、本格的な用途にはあまり信頼できない: https://nat64.xyz/
    AWS は NAT ゲートウェイのトラフィックに莫大な料金を請求するし、IPv4 のみのホストへ向かうトラフィックだけを横取りするよう設定できるのかも分からない。間違っていたら教えてほしい
    それ以外では、AWS で IPv6 のみで使うことは文句なく動作し、より安い。プライベートネットワーク用のエグレスゲートウェイは無料だ。もちろん IPv4 を気にしないという前提が必要だ

    • GitHub が親会社である Microsoft の IPv6 展開の流れに追いついていないのは残念だ
    • AWS でデュアルスタックネットワークを使えば、DNS では IPv6 を優先しつつ IPv4 も引き続き動作するのでは？ 一般的なインターネットへのエグレスが必要なものの多くは、そう設定している

  • 私の考えでは、Lambda と S3 が IPv6 をサポートしていないことこそが本当の問題で、AWS はまずこれらをデュアルスタックにして IPv6 でアクセスできるようにしてから、価格変更を行うべきだった
    技術的には S3 には別のデュアルスタックエンドポイントがあるにはあるが、いずれにせよこの変更に対応するにはアプリケーション設定を変えなければならず、あまり助けにはならない

  • そもそも AWS が IPv6 サポートで先行している理由の半分は、米国政府が移行を始めるように出した政策上の義務化によるものだ
    コストの観点では、新たな費用が大口顧客にとって些細だという点はその通りだが、最大級の顧客たちの政策上の義務化が持つ力を過小評価してはいけない。コンプライアンスのために独自の代替案を作ると脅すだけでも、AWS は最終的にサポートの優先順位を上げざるを得なくなる可能性がある

    • その通り。あまり好ましい考えではないが、「サーバー側」で IPv6 を促進する別の方法はだんだんなくなっているように見える
      クライアント、つまりエンドユーザー側はうまく進んでいるようだ。Google が最近、エンドユーザーの IPv6 トラフィックをほぼ 50% と報告しているのを見るとそう思う

  • 個人的に最悪なのは、CloudFront がカスタムオリジンの IPv6をサポートしていないことだ
    別個の Fargate コンテナをオリジンとして多数動かしているなら、パブリック IPv4 アドレスを有効にしなければならず、まもなく小さなコンテナのコストが倍になる
    Amazon はレガシー IPv4 の利用に追加料金を課す前に、自社のインフラが実際に IPv6 をサポートするようにすべきだ

    • その通り。妙なことに、これがいちばん痛い
      Amazon が巨大な怪物を作っており、多数のサービス全体に IPv6 を展開するのが途方もない作業だというのは分かるが、CloudFront が今すぐどころか昨日から IPv6 オリジンをサポートできていない理由は見当たらない
      相対的にそれほど難しそうにも見えないし、ほかの制限を回避するよい手段にもなり得る
      正直、これまでは Amazon の意思決定は結局のところ顧客の最善の利益を念頭に置いていると感じていたが、今はそうではない。今後にとって良くない兆候だと思う

  • 米国に本当のISP 競争があれば、大いに助けになったはずだ
    私が借りて住んでいる場所は Seattle 近郊の郊外なのに、実質的なブロードバンド ISP は 1 社しかない。どんな定義でも田舎ではないのに、Comcast が唯一の選択肢だ。価格とサービスはその現実をそのまま反映している

    • この分野で法的に強制された独占を可能にした、終わりのないロビー活動に感謝しなければならない。電話会社にも同じことをした
      偶然「Comcast だけ」なのではなく、法規制によって「Comcast だけ」になったのだ
    • Comcast は IPv6 をサポートしている。2016 年に IPv6 対応率 98% に到達した
    • 消費者は IPv6 を知りもしないし、気にもしていないので、競争が ISP の実装を促すことはできない
      Comcast に文句を言うのが面白いのは、私が Comcast を使っていたときはネイティブ IPv6 があったことだ。今使っているプロバイダーは NAT46 経由の IPv6 しかない
    • Starlink が別の選択肢になるかもしれない
      豪雨時の性能低下のような欠点はあるが、好意的なレビューもいくつか見た
    • IPv6 の導入は、顧客を大規模な独占事業者へさらに追いやることになる。安定して動作させるための専任のネットワークエンジニアリング人材を抱えられるのは彼らだけだからだ
      ほとんどの人は、今の IPv6 インターネットが 2 つあるという事実を知らない。Cogent 側と Hurricane Electric 側があり、両者は規模が似ていて、互いに接続を拒んでいる。だから、これを知ったうえで両方からトランジットを買うか、両方からトランジットを買っているネットワークから買う必要がある
      私の知る限り、少なくとも 1 つの大手事業者はいまだにトンネル上で v6 を動かしている。多くの場所で v6 トラフィックは最適でない経路を通り、企業ネットワークでは各データセンターに v4 接続があっても、v6 は「Dave の机の下にあるあの箱」1 台へすべて送られる、といった具合だ
      それでも Google や Cloudflare のように、パケットの到達を保証する専任チームを持つところで v6 導入率を測り、自分たちを褒めている

  • 「IPv4から抜け出せない」という表現は適切です。IPv6専用VPCを作ることはできますが、多くのAWSサービスからパッケージリポジトリまで、あまりに多くのものが壊れます: https://blog.devopstom.com/ipv6-only-ec2/
    結局、IPv4を有効にするか、NAT64ゲートウェイを自前で運用するか、誰かが運用しているNAT64を信頼する必要があります: https://nat64.net および http://v4-frontend.netiter.com

  • 「IPv6にはプライベートアドレスの概念がないので、Managed NAT Gatewayとその壮大な料金に別れを告げられる」という話は、AWS内ではそうかもしれませんが、IPv6には fc00::/7 の Unique Local IPv6 Address があり、NATを本当に愛しているならNAT66もあります

    • その通りで、AWSを指した話でしたし、それを明確にすべきでした
      ただしULAはあまり推奨されず、NAT66は……単にダメです
      最近聞いたところでは、MicrosoftはAzureのIPv6をすべて NAT中心 にしたそうです。本当に奇妙です