要約

  • クラウド NAT は単にプライベートサブネットを隠すための技術的装置ではない。クラウド市場では、パブリック IPv4 の希少性、出力 ID、価格設定、アカウント管理、許可リスト、プロバイダー制御のルーティングが交差する場となる。
  • 大規模プラットフォームは、パブリック IPv4 プール、NAT ゲートウェイ、BYOIP 受け入れルール、アカウント制御、プロビジョニング解除手順によって、アジア太平洋の事業者がプラットフォーム外で安定したパブリック ID を維持できるかどうかを決定する際に、希少なアドレス容量をアドレスパワーに変換する。
  • 信頼性の高いレジストリ記録、RDAP、Whois、移転証拠、RPKI/ROA、アドレス履歴記録がリソース保有者に外部オプションを提供するため、APNIC はこのチェーンにおいて重要である。しかし、レジストリの最も強力な役割は狭義の証拠インフラであり、クラウドアーキテクチャの監督ではない。
  • ポリシーリスクは微妙である。レジストリの証拠が遅く、不明瞭で、ポータブルでないか、裁量的な承認に絡め取られると、クラウドプロバイダーのアドレスがデフォルトの ID レイヤーになる。これにより、アドレス資本を保有するネットワークから、アドレス使用をレンタルし、計測し、管理するプラットフォームへと交渉力が移行する。

クラウド移行における真実の瞬間は、顧客が決して目にすることのないスプレッドシートで訪れることが多い。シンガポールのフィンテック企業が、その台帳、不正エンジン、顧客通知サービスを2つのコロケーションルームからパブリッククラウドリージョンに移行した。コンピュート計画は承認済み。Kubernetes クラスターはプライベート。セキュリティチームはアプリケーションサーバーがパブリックアドレスを持たなくなるというアイデアを気に入っている。財務チームはラックフットプリントの縮小を歓迎している。そして銀行統合チームが素朴な質問をする。「銀行、支払いネットワーク、不正ベンダー、税務ポータル、SMS プロバイダーに送信する送信元 IP アドレスは何ですか？これらのパートナーは当社の送信トラフィックを許可リストに登録しています。」

最初の答えはアーキテクチャに関するものだ。ワークロードはプライベートサブネットに配置される。送信トラフィックはマネージド NAT ゲートウェイを通過する。NAT ゲートウェイは少数のパブリック IPv4 アドレスを使用する。それらのアドレスはパートナーの許可リストに記録される。ログは内部ワークロードの ID を外部送信元アドレスとポートにマッピングする。プロバイダーの監視はバイト数、パケット数、接続数、障害数、料金を示す。図上では、これはクリーンだ。内部はプライベート、外部はパブリック、中央に制御されたチョークポイントがある。

2番目の答えは経済に関するものだ。これらのパブリック IPv4 アドレスは単なる数字ではない。それらはカウンターパーティの運用記憶に埋め込まれた資格情報である。それらは銀行が API 呼び出しを受け入れるかどうか、不正防止エンジンがリクエストを既知のものとして扱うかどうか、メールベンダーが継続性を認識するかどうか、規制当局の提出エンドポイントが手動例外を回避するかどうか、インシデント対応担当者が企業のトラフィックをプラットフォームの他のテナントから分離できるかどうかを決定する。それらを変更することは、サブネットラベルを変更するのとは異なる。ビジネスパスポートを変更するのに近い。

3番目の答えは制度的なものだ。誰がアドレスを管理するのか？フィンテックがクラウドプロバイダーのアドレスを使用する場合、プロバイダーはパブリック出力 ID を提供し、価格を設定し、アカウントに紐付け、予約、移動、削除、不正利用対応、リージョン使用、課金に関するルールを変更できる。フィンテックが自社の APNIC 登録済み IPv4 範囲を持ち込む場合、外部 ID を維持し、評判を保持し、プロバイダーのプールへの依存を減らすことができる。ただし、プロバイダーの BYOIP 受け入れプロセスを通過し、適切なルーティング認可を作成し、範囲を適切なアカウントとリージョンにバインドし、プラットフォーム固有の制限を受け入れ、同じ範囲を他に移動する前に慎重にプロビジョニング解除する必要がある。

それが本当の主題である。クラウド NAT はしばしばプライベートネットワークの利便性として説明される。しかし、それはクラウドプラットフォームがアドレス希少性をプラットフォームパワーに変えるメカニズムでもある。そのパワーは粗雑ではない。パケットに対する可視的な独占ではない。それはプロダクトのデフォルト、パブリック IPv4 料金、NAT 処理料金、BYOIP 適格性、アカウント制御、ルーティング認可、不正利用評判、パートナー許可リスト、そして離脱の運用負荷に分散している。アジア太平洋では、急速なクラウド採用が成熟した通信事業者、国家クラウドプロジェクト、フィンテック統合、ゲームプラットフォーム、断片的な規制管轄区域と並存しており、その結果、サービスのパブリックな顔を誰が所有するかという静かなシフトが起きている。

これはクラウド製品の解説ではない。NAT ゲートウェイ、Elastic IP アドレス、カスタムプレフィックス、外部アドレス、パブリックアドバタイズドプレフィックス、Elastic IP サービスはすべてプロバイダー間で異なる。名前は変わるが、根底にある経済性は安定している。大規模なパブリック IPv4 在庫を持つプラットフォームは利便性を販売できる。ポータブルなアドレス資本を持つ顧客は交渉できる。ポータブルなアドレス資本を持たない顧客はプラットフォームから ID をレンタルする。APNIC の記録は顧客が選択すべきアーキテクチャを決定するものではない。それらは顧客が自身のアドレスリソースを十分に管理していることを証明し、選択を有意義にするかどうかを決定する。

パブリックアドレスが出力資格情報になった

ほとんどのアプリケーションチームはアドレス経済を逆の順序で学ぶ。彼らはまずプライベートアドレス指定を発見する。それは安価で豊富で自動化が容易だからだ。クラウドテンプレートはプライベートサブネットを作成する。コンテナノードはプライベートアドレスを受け取る。サーバーレスおよびマネージドサービスは送信元ホストを隠す。セキュリティグループ、ルーティングテーブル、ID ポリシーはパブリック番号付けよりも重要に見える。パブリック IPv4 は古いインターネットのように感じられる。境界では必要だが、もはや設計の中心ではない。

その印象はプラットフォーム内部では部分的に正しい。境界では間違っている。外部世界は依然として送信元アドレスを見ている。銀行は依然として静的出力範囲を要求する。政府ゲートウェイは依然としてサプライヤーにパブリックエンドポイントを宣言するよう求める。レガシーな不正ベンダーは依然として IP レピュテーションをスコアリングする。SaaS ベンダーは依然として送信元ネットワークにレート制限、国別ルール、テナント履歴を適用する。メールシステムは依然として過去の動作を記憶する。ゲームおよび広告プラットフォームは依然としてアカウントシグナルと IP シグナルを組み合わせて不正利用と戦う。セキュリティ運用センターは依然として既知の出力 IP に対する例外を記述する。抽象的なクラウド ID に関する例外は組織の境界を越えることはほとんどないからだ。

その結果、ID が分裂する。クラウド内部では、ID はアカウント、ロール、ワークロード、サービスプリンシパル、ポリシー、タグである。クラウド外部では、ID は依然としてパブリック IP アドレス、プレフィックス、ASN、逆 DNS パターン、地理位置情報記録、レピュテーション履歴、そして一連のパートナー許可リストである。NAT は2つの世界を翻訳する。それは多くのプライベートワークロードを少数のパブリック ID に圧縮し、インターネットの残りの部分に、それらの ID が一貫した運用者を代表しているかのように信頼するよう求める。

圧縮は有用だ。パブリック IPv4 消費を削減する。プライベートサブネット設計を管理可能にする。パートナー許可リストに配置する必要のあるアドレス数を制限する。セキュリティチームにログ取得とポリシーのための少数の出力チョークポイントを提供する。しかし、圧縮は管理責任も生み出す。外部アドレスがプラットフォームに属する場合、プラットフォームはコンピュートとネットワーク転送を販売しているだけではない。顧客のパブリックな顔をレンタルしているのである。

そのレンタル料は公開されている時間単位の料金だけではない。それにはすべての契約と許可リストに組み込まれた依存関係が含まれる。1万件のパートナーリクエストを送信して4つのクラウドアドレスをホワイトリストに登録したフィンテックは、スイッチングコストを生み出している。アンチチート、支払い、カスタマーサポートをプロバイダー所有の出力アドレスを通じて実行するゲーム事業者は、レピュテーション依存を生み出している。少数のクラウド NAT アドレスを書類提出用に認定した公共部門ベンダーは、それらのアドレスを調達、監査、インシデントプレイブックに組み込んでいる。顧客はコードとデータを所有しているかもしれない。しかし、外部世界がサービスを認識するアドレス記憶は、プラットフォームが依然として所有している可能性がある。

これが、クラウド NAT が IPv4 希少性の経済学に属する理由である。NAT は希少なアドレスをさらに活用可能にするが、その活用は制度的な仲介者を通じて行われる。その仲介者がキャリアである場合、議論は CGNAT、ログ取得、法的要請、不正利用属性、サポートコストになる。仲介者がクラウドプラットフォームである場合、議論はパブリック IP 価格設定、アカウント権限、プロバイダープール、BYOIP 受け入れ、クラウド退出摩擦になる。どちらも希少性への対応である。異なる形のパワーを割り当てる。

価格設定によりアドレスが再び可視化された

10年にわたり、クラウドユーザーはパブリック IPv4 をおまけのように扱うよう訓練されてきた。それはマシン、ロードバランサー、ゲートウェイ、またはマネージドサービスにバンドルされていた。アイドル予約にはいくつかの料金が存在したが、アドレス自体が常にユニバーサルなラインアイテムとして表示されるわけではなかった。そのため、経済性を無視しやすかった。エンジニアはコンピュート、ストレージ、データベースライセンス、データ転送、可観測性を最適化した。アドレス数は衛生上の問題だった。

最近の価格設定の変化が心理を変えた。AWS はすべてのパブリック IPv4 アドレスに対して課金を導入した。サービスにアタッチされているかアイドルかに関わらない。その公開資料は公表レートを1IP 時間あたり0.005米ドルと設定しており、NAT ゲートウェイの価格設定はゲートウェイ時間と処理データに対しても課金する。Google Cloud は使用中の外部 IPv4 アドレスに価格を設定し、Cloud NAT で使用される外部 IP アドレスもネットワーク価格表に含める。Azure は NAT Gateway リソース時間と処理データに課金し、パブリック IP アドレス価格設定では、カスタム BYOIP プレフィックスから派生しない限り、パブリック IPv4 プレフィックスを1IPv4 時間あたりの課金として扱う。Alibaba Cloud のパブリック Elastic IP モデルは、多くの場合、データ転送または帯域幅料金と設定または保持料金を含み、BYOIP ドキュメントは顧客のパブリック IPv4 範囲の移行を説明し、公開サービス IP を変更せずに維持できるようにする。

正確な料金はプロバイダー、リージョン、サービス区分、契約によって異なる。その変動は重要ではない。重要なのは、パブリック IPv4 がクラウド設計の有料単位として戻ってきたことだ。NAT ゲートウェイは現在、2つの希少性価格設定の間に位置している。1つはパブリックアドレス自体のコストである。もう1つは、プライベートワークロードからインターネットへの経路としてマネージド変換を使用するための料金である。この料金はアプリケーション収益に比べれば小さかもしれないが、小さな料金でも誰が希少なインプットを管理しているかを明らかにすることができる。

小規模なデプロイメントにとって、1時間あたり0.005米ドルは死活問題ではない。何百または何千ものパブリックアドレス、テストアカウント、パブリックロードバランサー、NAT ゲートウェイ、マネージドサービス、忘れられた予約を持つ大規模なエンタープライズ環境では、請求書が可視化される。財務チームはなぜパブリック IP 数が這麼に多いのかと尋ねる。セキュリティチームはなぜすべてのワークロードが直接露出を必要とするのかと尋ねる。アーキテクトは NAT を通じて出力を統合する。統合によりアドレス数は減少するが、ID も集中する。多くのパブリックエンドポイントの代わりに、企業は少数のプラットフォームに依存した出力 ID を持ち、その障害、評判、アカウント問題が多くのサービスに一度に影響を与える可能性がある。

したがって、価格設定の変化は2つの相反する行動を促す。顧客がプライベートサブネットと NAT を使用してパブリック IPv4 使用量を削減することを報奨する。同時に、ポータブルな IPv4 をすでに管理している顧客が BYOIP によって継続性を維持し、一部のプロバイダーモデルではパブリックアドレス料金を回避できることを報奨する。ポータブルリソースを持たない顧客はプロバイダーのアドレス経済の中で最適化する。ポータブルリソースを持つ顧客は、プロバイダーのアドレス価格と、自社のプレフィックスを使用する機会費用を比較できる。その比較が交渉力である。

ここにアジア太平洋地域の文脈が重要になる。この地域には、グローバルクラウドリージョン、密集した金融ハブ、外部委託サービスプラットフォーム、モバイルファースト市場、クロスボーダーのゲームおよびメディアサービス、公共部門のデジタル化プログラムが含まれる。また、非常に異なるアドレス履歴を持つ事業者や企業も含まれる。一部の既存事業者や機関は重要な APNIC 承認 IPv4 リソースを保有している。多くの新興企業は保有していない。クラウドプラットフォームは両方の顧客を同じコンソールを通じて見るが、彼らの外部オプションは異なる。既存事業者はプレフィックスを持ち込むかどうかを尋ねることができる。新規参入者はデフォルトでプラットフォームのパブリック ID をレンタルするかもしれない。

その区別は、単純な豊かさ対貧しさの議論と混同されるべきではない。より深い点は資本管理である。ポータブル IPv4 は資本投入物となった。企業がそれを管理していれば、その使用、リース、移転、予約、プラットフォームへの持ち込みを決定できる。管理していなければ、プラットフォームのアドレスプールが製品の一部になる。そしてプラットフォームの価格設定は、コストスケジュールであるだけでなく、パブリック ID の割り当てシステムとなる。

BYOIP はポータビリティだが、独立ではない

BYOIP はプラットフォームのアドレスパワーに対する当然の答えである。企業がすでに歴史、評判、パートナー認識、APNIC レジストリ証拠を持つパブリック IPv4 範囲を持っているなら、なぜワークロードをクラウドに移行する際にそのパブリック ID を放棄するのか？範囲を持ち込み、クラウドにそれを広告させ、ロードバランサー、NAT ゲートウェイ、VM、またはその他のサポートリソースにアドレスをアタッチする。インフラを移動しながらアドレスを安定に保つ。

主要プロバイダーの公開ドキュメントはその約束を明確に説明している。AWS は顧客が公的にルーティング可能なアドレス範囲を Amazon EC2 に持ち込むことを許可し、その範囲が顧客のアカウントにアドレスプールとして表示されるようにする。AWS の前提条件には、Amazon ASN 向けの RPKI/ROA 認可と、オンボーディングのための最も具体的な IPv4 プレフィックスサイズが含まれる。Azure のカスタム IP アドレスプレフィックス機能により、顧客は連続した範囲をサブスクリプションに持ち込むことができ、Microsoft はそれを広告することが許可され、カスタムプレフィックスからのアドレスは Azure 所有のパブリック IP プレフィックスと同様に使用できる。Google Cloud の BYOIP ドキュメントは、インポートされたアドレスが Google 提供のアドレスと同様に管理されるが、重要な例外があり、それらはそれらを持ち込んだ顧客のみが利用でき、Google はアイドルまたは使用中の BYOIP アドレスに対して課金しないと述べている。Alibaba Cloud は、BYOIP により顧客がパブリック IPv4 範囲を Alibaba Cloud に移行し、公開サービス IP アドレスを変更せずに維持できると述べており、Alibaba が顧客に代わって範囲を広告する。

これらは強力な機能である。また、BYOIP が完全な独立ではない理由も示している。顧客のアドレス資本はゲートを通じてプロバイダーに入る。プロバイダーは最小プレフィックスサイズ、対象リソース、リージョン、プロビジョニング順序、検証プロセス、経路元認証、アカウントバインド、クォータ効果、プロビジョニング解除ルールを定義する。顧客は範囲が自身のものであるという意味で管理を維持する。プロバイダーはそれを製品システム内で広告し、割り当て、マッピングし、公開するという運用管理を得る。

その区別が重要なのは、受け入れが中立的ではないからである。インターネット上でルーティング可能なプレフィックスでも、プロバイダーの BYOIP プロセスに失敗する可能性がある。経路元認証が間違っている、レジストリ記録が不明瞭、プレフィックスが小さすぎる、ホルダーがアカウント権限を証明できない、現在のアナウンスが計画されたクラウド広告と競合する、またはターゲットサービスが望ましい使用をサポートしていないなどの理由で。それぞれの失敗は交渉の瞬間になる。顧客はアドレス ID を維持したい。プロバイダーはルーティングの安定性、自社の評判、製品境界を保護したい。APNIC レジストリ証拠は顧客の証明ファイルである。しかし、プロバイダーのポータルが即時のゲートである。

プラットフォームの管理は一時的でもある。BYOIP プレフィックスがプロバイダーによって広告されている間、顧客はそれを同時に他のすべての使用に自由に利用できるとは扱えない。クラウドドキュメントは競合するアナウンスに対して警告し、多くの場合、移転または移動の前にプロビジョニング解除または撤回を要求する。これは良いルーティング衛生である。同時に退出コストでもある。プレフィックスをあるプロバイダーに配置した顧客は、同じパブリック ID を別のプロバイダーに移動したり、自己運用インフラに戻したりする前に、管理された引き継ぎを計画しなければならない。その引き継ぎには、ルート、ROA、逆 DNS、DNS レコード、ロードバランサーマッピング、ファイアウォールルール、パートナー許可リスト、セキュリティ監視、場合によっては契約上の通知が含まれる。

したがって、BYOIP の経済性は所有権に近い管理とプラットフォーム管理の間に位置する。ポータブルプレフィックスはホルダーにレバレッジを与える。プロバイダーのパブリックプールへの依存を減らす。評判とパートナー許可リストを維持する。パブリックアドレス料金を削減する可能性がある。マルチクラウドや退出計画を信頼できるものにすることができる。しかし、プラットフォームパワーを消し去るわけではない。交渉を「パブリック ID をレンタルしてください」から「アドレス資本をトラップしない条件でプラットフォームに受け入れてください」に変える。

アカウント権限がアドレス権限になる

クラウドプラットフォームは通常、番号に関する劇的な決定を通じてアドレスパワーを行使することはない。アカウントシステムを通じて行使する。パブリック IP アドレスはアカウント、サブスクリプション、プロジェクト、リージョン、VPC、リソースグループ、ロードバランサー、NAT ゲートウェイ、または Elastic IP プールにアタッチされる。顧客は請求書を支払い、ID およびアクセス管理を維持し、サブスクリプションを良好な状態に保ち、資格情報を保護し、不正利用および利用規約に準拠し、パブリックアドレスをワークロードに接続する設定を維持しなければならない。

これはクラウド運用者にとっては馴染み深い。IP アドレスをネットワーク資産と考える取締役会にとっては馴染みが薄い。コロケーションまたはキャリア環境では、アドレス管理ファイルはネットワークエンジニアリング、法務、レジストリアカウントホルダーにあるかもしれない。クラウドでは、効果的なアドレス管理ファイルは、組織アカウント、セキュリティ管理者、デプロイメント自動化、請求関係、サービス割り当て全体に分散している可能性がある。どのレイヤーでのミスもパブリック ID に影響を与える可能性がある。

このリスクは仮想的なものではない。侵害されたクラウドアカウントはリソースを作成、削除、再割り当て、公開する可能性がある。停止されたアカウントはサービスを中断する可能性がある。誤設定された組織ポリシーは必要なパブリックアドレス操作を妨げる可能性がある。削除された NAT ゲートウェイはプロバイダーのメカニズムに応じてアドレスを解放またはデタッチする可能性がある。失敗した自動化実行は、パートナー許可リストが準備される前にトラフィックを新しい出力 ID に移動する可能性がある。請求紛争はサービス継続性の問題になる可能性がある。コンプライアンスレビューは、移行ウィンドウに間に合うようにプレフィックスをオンボードすることを妨げる可能性がある。

これらのリスクは、クラウドプラットフォームが不注意であることを意味するものではない。多くの場合、プロバイダーの制御は顧客が単独で運用できるものよりも強力である。重要な点は異なる。顧客のパブリック ID がアカウントを通じて仲介されるため、プラットフォームのアカウント権限がアドレス権限になる。顧客がプロバイダーのアドレスを使用する場合、依存は直接的である。BYOIP を使用する場合でも、プロバイダーがプレフィックスを広告し管理している期間中は依存が残る。

これにより、大規模プラットフォームは単なるアドレス保有量では捉えられない形のアドレスパワーを得る。アドレス在庫は重要である。管理アーキテクチャも同様に重要である。プラットフォームはアドレスが割り当てられる API、NAT が設定されるコンソール、変更を認可する ID システム、パブリック使用に価格を設定する課金モデル、苦情に対応する不正利用チーム、BYOIP を使用できるサポートサービス、範囲を顧客管理に戻すプロビジョニング解除シーケンスを管理する。それは所有権ではない。運用上のレバレッジである。

このレバレッジチェーンにおける APNIC の役割は間接的だが重要である。クリーンな APNIC 記録はクラウドアカウントを保護しない。請求停止を防がない。すべての BYOIP ユースケースをプロバイダーにサポートさせるわけではない。しかし、誰がプレフィックスを管理しているか、どの組織がルーティング認可を作成できるか、カウンターパーティがどの履歴を信頼すべきかについての曖昧さを減らす。レジストリ証拠が正確であればあるほど、クラウドアカウント権限とアドレス権限が曖昧になり始めたときに顧客の立場は強くなる。

アドレスレピュテーションは在庫ではなく記憶である

パブリック IPv4 の価格設定はエンジニアにアドレスを数えることを促す。アドレスレピュテーションは、すべてのアドレスが等しいわけではないことを思い出させる。長年のビジネス使用、安定した地理位置情報、一貫した逆 DNS、低い不正利用履歴、既知のカウンターパーティ許可リストを持つクリーンなプレフィックスは、プロバイダープールから新たに割り当てられたアドレスよりも価値がある可能性がある。逆に、不正利用、スパム、スクレイピング、不正なサインアップ、または誤設定されたサービスの履歴を持つパブリックアドレスは、技術的にルーティング可能であっても割引を被る可能性がある。

クラウド IP 再利用とクラウドスワッティングに関する学術的研究は、レピュテーションと潜在的な設定がなぜ重要かを示している。パブリッククラウドは大規模にアドレスを割り当て、リサイクルする。サービスが適切に廃止されていない場合、古い DNS レコード、サードパーティ統合、ソフトウェアコールバック、顧客トラフィックがアドレスが移動した後もそのアドレスを指し続ける可能性がある。研究者は、アドレス再利用が機密性の高いトラフィックを露出させ、以前のテナントと後のホルダーにセキュリティリスクを生み出すことを実証している。クラウドスケールでの安全な IP 割り当てに関する他の研究は、悪意のあるテナントが割り当て動作、評判、レート制限の前提を悪用する可能性があるため、パブリッククラウドアドレスプールをセキュリティセンシティブなリソースとして扱っている。

規制対象サービスをクラウドに移行するアジア太平洋の事業者にとって、これは単なるセキュリティペーパーの関心事ではない。アドレス記憶は銀行統合、顧客信頼、不正評価、到達可能性、サポートチケット、インシデント対応に影響を与える可能性がある。サービスがプロバイダー所有の NAT アドレスを使用する場合、プラットフォームのプール評判とプロバイダーの割り当て規律の一部を継承する。BYOIP を使用する場合、自身の履歴をクラウドに持ち込む。各オプションにはリスクがある。プロバイダーのアドレスは運用上便利かもしれないが、ポータブルではない。顧客のアドレスはよりポータブルかもしれないが、より強力な証拠、より良い衛生、慎重なクラウドオンボーディングが必要である。

多くのワークロードが同じパブリック ID を共有するため、NAT は評判の重要性を増幅する。NAT ゲートウェイの背後にある1つのサービスが悪意のある動作をした場合、カウンターパーティは問題を引き起こした内部ワークロードではなく、共有出力アドレスを見る可能性がある。ゲートウェイが支払い、分析、顧客メッセージ、脆弱性スキャン、ソフトウェアアップデート、管理呼び出しを運ぶ場合、評判の fallout は機能横断的になる可能性がある。内部ログは正確かもしれない。外部の関係者はパブリック IP とタイムスタンプしか見ないかもしれない。

これはプラットフォームがレバレッジを得るもう一つの方法である。彼らはマネージド NAT、ログ統合、不正利用プロセス、DDoS 保護、IP レピュテーションツール、アドレスインサイト製品を提供できる。それらのサービスは価値がある。また、顧客をプラットフォーム固有の可観測性および対応システムにさらに深く引き込む。顧客がパブリック出力評判の説明、防御、修復をプロバイダーに依存すればするほど、迅速に離脱することが難しくなる。

ポータブルアドレスはそれだけで評判を解決するわけではない。ホルダーをより責任あるものにすることさえできる。なぜなら、評判がプロバイダープールに吸収されるのではなく、プレフィックスに追随するからである。しかし、それがまさにアドレス資本が重要である理由である。自社のプレフィックスを持つ顧客は、評判を資産として維持するインセンティブがある。プロバイダーのアドレスを使用する顧客は間接的に評判をレンタルし、プロバイダーの管理対応が修復の速度を決定する可能性がある。

退出摩擦は許可リストの中に隠れている

クラウドロックインは通常、データベース、プロプライエタリサービス、データ出力、マネージド Kubernetes のバリアント、ID システム、運用ツールを通じて議論される。それらは現実的である。しかし、多くの規制対象および B2B サービスにとって、パブリック出力 ID は同樣に粘着的であり得る。ロックインはコードライブラリにあるのではない。それは他人のファイアウォールにある。

すべてのパートナー許可リストは小さな調整コストである。フィンテックは、銀行、支払い処理業者、カードネットワーク、分析ベンダー、税務機関、カスタマーサポートプラットフォーム、不正ベンダー、SMS ゲートウェイに新しい送信元範囲を受け入れてもらう必要があるかもしれない。ゲームプラットフォームは、アンチチートベンダー、支払いゲートウェイ、CDN オリジンルール、パブリッシャーツール、モデレーションシステム、地域コンプライアンスインターフェースに新しい ID を受け入れてもらう必要があるかもしれない。公共部門のクラウドサプライヤーは、調達ファイル、セキュリティ認可、侵入テスト例外、監査レポート、運用ランブックを更新する必要があるかもしれない。各カウンターパーティには独自の変更ウィンドウ、リスク選好、フォーム、証拠基準がある。

プロバイダー所有の NAT アドレスは、プラットフォームがすぐに使えるパブリック ID を提供するため、最初の移行を容易にする。ID が本当に顧客のものではないため、2回目の移行を困難にする。顧客がプロバイダーを離れる場合、許可リストを変更しなければならない。顧客がアカウントを統合したり、リージョンを変更したり、NAT ゲートウェイを再構築したり、別のプロバイダーに移動したりする場合、カウンターパーティに連絡しなければならない。プロバイダーが製品制限や価格を変更した場合、顧客はアドレス ID が再交渉したい商業関係に絡め取られていることに気づくかもしれない。

BYOIP はその論理の一部を逆転させる。最初の移行はより困難である。顧客はプロバイダーの受け入れ、ルーティング認可、アカウント制御を通じてプレフィックスを持ち込まなければならない。2回目の移行はより容易になり得る。なぜなら、プロバイダーがクリーンにプロビジョニング解除し、次のプラットフォームがプレフィックスを受け入れれば、パブリック ID は移動できるからである。顧客は将来の退出オプションを購入するために upfront の複雑さを支払う。

そのオプション性は、顧客が決して退出しなくても価値がある。信頼できる外部オプションは交渉を変える。「パブリック ID を移動できます」と言える顧客は、「アプリケーションを再構築し、すべてのパートナーに許可リストの変更を依頼しなければならない」としか言えない顧客とは異なる。前者はプラットフォームを比較できる。後者は自身の過去の設定と交渉している。

APNIC レジストリ証拠は、その外部オプションの静かな支えである。記録は誰がリソースを保持しているかを示す。RDAP と Whois はリソースを読み取り可能にする。RPKI と ROA は、どの AS がプレフィックスを発信できるかを示すのに役立つ。移転ログと履歴記録は、カウンターパーティが継続性を理解するのに役立つ。これらは華やかではない。最良の意味での書類作業である。ビジネスがアイデンティティを供給するためにプラットフォームに頼ることなく移動できるようにする証拠である。

APNIC の問題は証拠の質であり、クラウドの監督ではない

APNIC がクラウド NAT 設計を規制すべきだと主張するのは誤りである。レジストリは、顧客がマネージド NAT、NAT インスタンス、パブリックロードバランサー、プロバイダーアドレス、BYOIP、IPv6、デュアルスタック、またはハイブリッド構成を使用すべきかを決定すべきではない。これらは事業者の選択である。レジストリはクラウド請求書を支払わず、アプリケーションを実行せず、銀行統合チケットに直面せず、インシデントコールに応答しない。

有用な APNIC の問いはより狭い。レジストリ層はアジア太平洋のリソース保有者に明確で信頼性が高く、ポータブルなアドレス管理の証拠を提供しているか？ホルダーは BYOIP をオンボードするのに十分迅速にその権限を証明できるか？不要な摩擦なしにルーティング認可を作成または調整できるか？カウンターパーティは曖昧さなく公開記録を検査できるか？移転、合併、再編は商業生活が求める速度で記録に反映されるか？リソース保有者は、あるレジストリ管理経路が遅くなったり、捕捉されたり、争われたりした場合に継続性を維持できるか？

これが狭義のレジストリビューである。レジストリは一意性を保護し、管理を記録し、連絡可能性をサポートし、セキュリティアサーションを維持し、移転を記録し、監査証跡を保存し、希少性を裁量的なコマンドに変えることを避けるべきである。IPv4 が資本になった今、レジストリの義務はより拡大的ではなく、より規律正しくなる。レジストリ記録は管理を記述する。それはクラウドアーキテクチャや顧客の地理に対するライセンスになるべきではない。

レジストリの証拠が弱まるとプラットフォームのパワーが拡大するため、このドクトリンは重要である。顧客の自身のアドレス証明が使いにくい場合、プラットフォームのアドレスプールがより容易になる。合併後のレジストリ記録が不明瞭な場合、BYOIP よりもプロバイダーアドレスの方が容易である。移転認識が遅い場合、買い手はクラウドオンボーディングを遅らせたり、一時的にプロバイダーアドレスをレンタルしたりするかもしれない。一時的なレンタルは、許可リストが蓄積されるために永久的になる。移行の初めの小さなレジストリ摩擦が、後でプラットフォーム依存になる。

このように、レジストリの裁量とプラットフォームのパワーは意図せずして相互に強化される可能性がある。厚いレジストリプロセスは必ずしも公共の利益層にパワーを保持させるわけではない。プロバイダーのアドレスが消費しやすいため、顧客をプライベートプラットフォーム ID に押し込む可能性がある。そしてプラットフォームはアドレスレントを稼ぎ、トラフィックをログし、アカウント境界を定義し、不正利用プロセスを処理し、サービスの実質的なパブリック ID になる。レジストリは事業者を保護していない。事業者の外部オプションをより高価にしている。

したがって、APNIC の最善の貢献は、クラウド依存を不可能にすることではない。アドレスの自己保有を使用可能にすることである。つまり、正確な記録、予測可能な移転記録、タイムリーな RPKI 運用、明確なホルダー権限、読み取り可能な RDAP/Whois、限定された執行、ポータビリティ指向の手順である。これらはイデオロギー的な気取りではない。彼らは自身のパブリック ID を維持したいクラウド顧客のための市場インフラである。

アドレス割り当て者としてのクラウドプロバイダー

従来のレジストリの話では、APNIC はインターネット番号リソースを割り当てまたは記録し、クラウドプロバイダーは他の人と同様にそれらを消費する。実際には、大規模プラットフォームは自社の製品システム内でプライベートなアドレス経済を運営している。彼らは顧客がデフォルトで予約できるパブリックアドレスの数を決定する。どのサービスがパブリック IPv4 を公開するかを決定する。パブリックエンドポイントが自動か明示的かを決定する。NAT のスケーリング方法、NAT ゲートウェイが使用できるアドレス数、ポートの割り当て方法、利用可能なログ、各ユニットに付与される価格を決定する。

これはレジストリの割り当てではないが、割り当てに似ている。プラットフォームは自社のパブリックプールへのアクセスと顧客所有範囲の受け入れを割り当てている。割り当て、価格、サポートチケット、製品制限、不正利用防止制御、アカウントレビューを通じて配分する。また、設計デフォルトを使用して行動を形成する。マネージドサービスがプライベート接続を容易にし、パブリック IPv4 を高価にする場合、顧客は統合する。BYOIP がより大きなプレフィックスまたは特定のリソースタイプに制限されている場合、一部の顧客のみが ID を維持できる。パブリックアドレスが作成しやすく、アカウント間で監査が難しい場合、顧客は財務が介入するまでアドレス請求書を蓄積する。

この内部アドレス経済はプラットフォームの観点から合理的である。パブリック IPv4 は希少である。不正利用リスクは現実的である。ルーティングの安定性は重要である。プロバイダープールは保護されなければならない。1人の顧客の誤用が多くのテナントに影響を与える可能性があるため、プラットフォームには明確な制御が必要である。しかし、合理的な制御でも交渉力が生まれる。何百万もの顧客エンドポイントを管理するプロバイダーは、運用上の必要性を製品依存に変換できる。

市場のテストは、顧客に信頼できる代替手段があるかどうかである。顧客はプロバイダーのアドレスを使用してもよい。自社のアドレスを持ち込んでもよい。サードパーティを通じてアドレスをリースし、許可された場所に持ち込んでもよい。クラウド間で出力を分割してもよい。パブリック ID のためにコロケーションを維持し、プライベート接続をクラウドワークロードに使用してもよい。カウンターパーティがサポートする場合に IPv6 を使用し、残りのために IPv4 を維持してもよい。各オプションにはコストがある。重要な点は、APNIC レジストリ証拠がいくつかのオプションのコストを下げ、プロバイダー管理が他のオプションのコストを上げることである。

これはまた、クラウドプラットフォーム内のパブリック IPv4 価格を小さく無視すべきではない理由も説明する。月額3〜4米ドルのアドレスラインアイテムは、ハイパースケールプロバイダーにパワーを与えるものではない。パワーはバンドルから来る。パブリックアドレス在庫プラス NAT 製品プラスアカウントシステムプラスログプラスサポートプラス不正利用プロセスプラスパートナー許可リスト慣性プラス BYOIP 受け入れ。価格はアドレスを可視化する。バンドルはプラットフォームを重要なものにする。

これが成長圧力や CGNAT と異なる理由

APNIC の地域は実際の成長圧力に直面している。モバイル需要、クラウドオンボーディング、フィンテック到達可能性、公共部門のデジタル化、既存事業者のアドレス深度はすべて、誰が迅速に拡大できるかに影響する。それは別の記事の中心である。クラウド NAT 問題はより狭い。顧客がプラットフォームを使用することを決定し、誰のパブリックアドレス ID がインターネットに直面するかを選択しなければならない場合に何が起こるかを問う。

CGNAT も隣接しているが異なる。キャリアグレード NAT は、共有パブリック IPv4ID のコストを加入者属性、法的要請、アプリケーション障害、不正摩擦、サポートコール、静的アドレスプレミアムに移行する。クラウド NAT はコストをプロバイダー出力製品、パブリック IP 料金、アカウント権限、パートナー許可リスト、アドレスレピュテーション、BYOIP 受け入れ、退出摩擦に移行する。共通の概念は変換である。経済的な表面は異なる。

キャリア NAT では、エンドユーザーは共有パブリックアドレスがアプリケーション動作を形成していることを知らないかもしれない。クラウド NAT では、顧客は通常アーキテクチャを選択するが、その選択はプロバイダー製品と外部カウンターパーティによって制約される。キャリア NAT では、ハードな証拠問題は多くの場合、加入者、ポート、時間のマッピングである。クラウド NAT では、ハードな証拠問題はワークロード、アカウント、パブリックアドレス、パートナー例外、アドレス管理証明を商業プラットフォーム全体でマッピングすることである。

対策が異なるため、この区別は重要である。CGNAT 対策はログの精度、サポート負担、法的要請の規律、パブリック IP 製品の可用性、IPv6 readiness に焦点を当てるかもしれない。クラウド NAT 対策はアドレスポータビリティ、BYOIP 透明性、プロバイダーに依存しない証拠、許可リスト移行計画、アカウント管理ガバナンス、単一プラットフォーム外で使用できるレジストリ記録に焦点を当てる。

会計の視点：レンタル、資本、オプション価値

クラウド NAT 経済を読む簡単な方法は、レンタルと資本を分離することである。プロバイダーのパブリックアドレスはレンタルされた ID である。BYOIP アドレスは顧客管理の資本がプロバイダーの環境に受け入れられたものである。NAT ゲートウェイは変換インフラであり、レンタル ID または顧客資本のいずれかを使用できる。パートナー許可リストは、選択された ID に価値を付与する関係固有の投資である。

顧客がプロバイダーの ID をレンタルする場合、初期費用は低い。移転ファイルはなく、ROA 準備もなく、プレフィックス受け入れもなく、ブロックが持ち込むのに十分クリーンであるかどうかの懸念もなく、顧客所有範囲の外部ルーティングを調整する必要もない。顧客はプロバイダーに支払い、移行する。これはサービスが新しく、低リスクで、一時的、または深く許可リスト化されていない場合に効率的である。サービスが規制対象で、評判に敏感で、マルチクラウドで、買収されやすく、または何年も続くことを意図している場合、効率は低くなる。

顧客がアドレス資本を使用する場合、初期費用はより高い。ホルダーは APNIC 記録を維持し、適切なアカウント権限を管理し、経路元認証を準備し、プロバイダーの検証を満たし、カットオーバーを計画し、逆 DNS とレピュテーションを保護し、プロビジョニング解除の規律を管理しなければならない。しかし、顧客はオプション価値を購入する。プロバイダー間で外部 ID を維持できる。BYOIP が免除される場合、一部のプロバイダーのアドレス希少性料金を回避できる。カウンターパーティに継続性を示すことができる。アドレスレピュテーションをプロバイダーのプール内部ではなく、自社のバランスシートに保持できる。

オプション価値は、移行プロジェクトで過小評価されがちである。移行のビジネスケースは当面の節約に焦点を当てる。スプレッドシートは月間のコンピュート、データベース、ストレージ、データ転送、NAT ゲートウェイ、サポート、人員を比較する。200のカウンターパーティに許可リストの更新を依頼せずに離脱できることに対して価値を割り当てることはめったにない。プロバイダー所有の出力アドレスと10年のビジネス歴を持つ APNIC 認識プレフィックスの違いに価格を付けることはほとんどない。アカウント停止、買収、紛争、制裁レビュー、プロバイダーポリシー変更がパブリック ID を中断する可能性があるかどうかを問うことはほとんどない。

その省略はプラットフォームに有利に働く。プラットフォームはライフタイムバリューを理解している。顧客はしばしばプロジェクトごとに予算を組む。プラットフォームは今すぐクリーンな移行を販売し、後で退出摩擦を捕捉する。顧客の最善の防御はクラウドへの敵意ではない。資産認識型のアーキテクチャである。パブリック ID が重要なら、最初の許可リストが提出される前に戦略的資産として扱う。

良いガバナンスとはどのようなものか

この分野における良いガバナンスには、APNIC がクラウドの審判になることは必要ない。異なるアクター間の3つの規律が必要である。

第一に、クラウド顧客は移行前にパブリック出力 ID を棚卸しすべきである。質問は単に「いくつのパブリック IP が必要か？」ではなく、「これらのアドレスに依存している外部関係はどれか、誰がそれらを所有しているか、どのような評判を持っているか、それらを変更するのにどれだけのコストがかかるか？」である。規制対象または高ボリュームのサービスは、ドメイン管理ファイルや証明書管理ファイルと同様に、アドレス管理ファイルを持つべきである。そのファイルは、ホルダー、レジストリ証拠、ROA、逆 DNS、クラウドアカウントマッピング、NAT ゲートウェイ設定、パートナー許可リスト、不正利用連絡先、退出シーケンスを特定すべきである。

第二に、プラットフォームは BYOIP の受け入れとプロビジョニング解除をより透明にすべきである。最小プレフィックスサイズ、サポートリソース、リージョン、予想タイムライン、ROA 要件、アカウント移転制限、同時アナウンスリスク、逆 DNS プロセス、不正利用エスカレーション、顧客への返却手順は、顧客がコミットする前に価格設定できるほど予測可能であるべきである。プロバイダーは受け入れを不透明な特権に変えることなくネットワークを保護できる。プロセスが予測可能であればあるほど、サポートチケットの中にプラットフォームパワーが隠れることは少なくなる。

第三に、APNIC はレジストリ証拠を市場インフラとして扱うべきである。クラウド顧客にとってのその価値は、どのプロバイダーを使用すべきかを伝えられることではない。その価値は、顧客管理のアドレス資本をプロバイダー、パートナー、貸し手、監査人、カウンターパーティにとって読み取り可能にできることである。そのためには、正確な記録、タイムリーな更新、信頼性の高い RDAP/Whois、使用可能な RPKI、履歴の可視性、予測可能な移転記録、すでに埋め込まれた運用資産に対する裁量的管理に対する明確な境界が必要である。

これらの規律は控えめである。同時に、いくつかの制度的誘惑に逆らう。顧客はスピードを好み、退出コストを後で発見する。プラットフォームは製品固有の粘着性を好む。レジストリは希少性に対してより多くの管理で答えようとする誘惑に駆られるかもしれない。しかし、証拠がポータブルで、コストを負担する主体に管理が属するとき、ネットワーク経済はより良く機能する。

公共部門とフィンテックの利害

公共部門やフィンテックの設定では、アドレス ID がしばしばコンプライアンスのオーラを帯びるため、問題はより一層鮮明になる。文書処理ワークロードをクラウドに移行する省庁サプライヤーは、安全なファイリング、監査検索、省庁間 API のために承認された発信アドレスを必要とするかもしれない。支払い企業は銀行接続のために安定したアドレスを必要とするかもしれない。健康プラットフォームは、クラウド移行がエンドポイントの信頼を変えないことをカウンターパーティに保証する必要があるかもしれない。地域のゲーム事業者は、支払い、アンチチート、モデレーションベンダーのために安定した出力を必要とするかもしれない。

これらのケースはまれなエッジコンディションではない。成熟したサービスをデジタル化する通常の作業である。サービスが古い機関と相互作用するほど、パブリック IP ID が信頼ファイルの一部であり続ける可能性が高い。公的な物語はゼロトラスト、サービス ID、API レベルの認可を称賛するかもしれない。運用形式は依然として IP 許可リストを含む。それらは単純で、監査可能で、組織境界全体で馴染みがあるからである。

それがクラウド NAT をガバナンス問題にする。NAT ゲートウェイは、現代のプラットフォームアーキテクチャがレガシー信頼インフラに接する場所である。プライベートワークロードが古い許可リストシステムに参加することを可能にする。また、パブリックな顔がプロバイダーに属するか事業者に属するかを決定する。プロバイダーのアドレスが使用される場合、公共機関や銀行は事実上、プラットフォーム所有のアドレス経済内の顧客のアカウントを信頼している。BYOIP が使用される場合、機関や銀行は、レジストリ証拠を通じて管理が見えるポータブルリソースに信頼を結びつけることができる。

どちらのモデルも普遍的に優れているわけではない。プロバイダーのアドレスは、新しいサービス、低リスクのワークロード、またはプロバイダーの制御が主な保証である場合に適切かもしれない。顧客管理のプレフィックスは、耐久性のあるカウンターパーティ、マルチプロバイダー戦略、買収リスク、高い評判価値を持つサービスに適しているかもしれない。デフォルトの NAT ウィザードが高速だったために偶然に決定を下すことが誤りである。

プラットフォームのパワーは目に見えないときに最も強い

最大のアドレスパワーのシフトは、パワーシフトとして発表されることはめったにない。それらは価格更新、製品改善、セキュリティ要件、割り当て変更、不正利用制御、新しい BYOIP 機能、コスト最適化ガイダンスとして発表される。それぞれは弁護可能かもしれない。それらが一緒になって、顧客のパブリック ID をプラットフォームの管理ドメインに移動させる。

エンジニアにはパブリックエンドポイントが少なく見える。財務チームには IPv4 ラインアイテムが見える。セキュリティチームにはより良いプライベートサブネットの規律が見える。コンプライアンスチームには安定した許可リストが見える。プラットフォームにはマネージドゲートウェイとパブリックアドレス製品を通じて流れるより多くのワークロードが見える。APNIC リソースホルダーには、自社のプレフィックスを使用することとプロバイダーのものをレンタルすることの違いが見える。同じアーキテクチャが、セキュリティ改善、コスト最適化、パワー移転であり得る。

だからこそ、この質問は早期かつ明確に行われるべきである。この移行後、サービスのパブリックアドレス ID を管理するのは誰か？答えは「プロバイダーであり、それは許容できる」かもしれない。「顧客が BYOIP を通じて、広告中のプロバイダー管理のもとで管理する」かもしれない。「ハイブリッドで、コモディティワークロードにはプロバイダーアドレス、規制対象出力には顧客プレフィックス」かもしれない。重要なのは、答えが意図的であることである。

APNIC のガバナンスにとって、教訓は同様に明白である。希少性は IPv4 を資産にし、クラウドプラットフォームはパブリック出力 ID を製品にした。レジストリはそれに対して、クラウド使用に対してより主権的になることで応答すべきではない。より良い台帳になることで応答すべきである。より薄く、より速く、より正確で、よりポータブルで、より予測可能に。事業者に信頼性の高い証拠を提供するレジストリは、プラットフォームと交渉する能力を強化する。証拠を裁量に変えるレジストリは、彼らを弱体化させる。

シンガポールのフィンテックの移行は、最良の場合、少数のパブリック出力アドレスの小さな表で終わる。その表の背後には、はるかに大きな制度的決着がある。企業はプロバイダーのアドレスをレンタルし、将来の許可リスト摩擦を受け入れたかもしれない。APNIC 認識のプレフィックスを持ち込み、BYOIP 受け入れの作業を受け入れたかもしれない。リスクに応じてワークロードを分割したかもしれない。どのような設計であれ、パブリックアドレスはもはや背景の詳細ではない。それはクラウドアーキテクチャとビジネス権限の間のヒンジである。

したがって、クラウド NAT は IPv4 希少性の終わりではない。それは希少性の最も現代的な形態の一つである。それはプライベートな複雑性を少数のパブリックアドレスの背後に隠し、それらのアドレスをプラットフォームを通じて価格設定し管理する。APNIC 証拠層がより良く機能すればするほど、事業者はその ID をレンタルするか、自前で持ち運ぶかを決定できる。証拠層の機能が悪ければ悪いほど、プラットフォーム ID がデフォルトになる。サービスをパブリック番号で認識し続けるインターネットでは、その違いはパワーである。

ソースと参考文献