要約
- クラウド NAT は、単にプライベートサブネットを隠すための技術的装置ではない。クラウド市場においては、パブリック IPv4 の希少性、出力 ID、価格設定、アカウント管理、許可リスト、プロバイダ制御のルーティングが交錯する場となる。
- 大規模プラットフォームは、自らのパブリック IPv4 プール、NAT ゲートウェイ、BYOIP 受入ルール、アカウント制御、およびデプロビジョニング手順が、アジア太平洋の事業者がプラットフォーム外で安定したパブリック ID を維持できるかどうかを決定する場合に、希少なアドレス容量をアドレスパワーへと変換する。
- APNIC がこの連鎖において重要であるのは、信頼性の高いレジストリ記録、RDAP、Whois、移転証拠、RPKI/ROA、アドレス履歴記録がリソース保持者に外部選択肢を提供するからである。しかし、レジストリの最も強力な役割は狭義の証拠インフラであり、クラウドアーキテクチャの監督ではない。
- 政策リスクは微妙である。レジストリ証拠が遅く、不明瞭で、可搬性がなく、裁量的承認に絡め取られていると、クラウドプロバイダのアドレスがデフォルトのアイデンティティ層となる。これにより、アドレス資本を保有するネットワークから、アドレス使用を貸与し、計量し、管理するプラットフォームへと交渉力が移行する。
クラウド移行の真実の瞬間は、多くの場合、顧客の目に見えないスプレッドシートで訪れる。シンガポールのあるフィンテック企業が、2 つのコロケーションルームにあった台帳、不正検知エンジン、顧客通知サービスをパブリッククラウドのリージョンに移行したとする。コンピュート計画は承認され、Kubernetes クラスタはプライベートである。セキュリティチームはアプリケーションサーバがパブリックアドレスを持たなくなることを好み、財務チームはラックの設置面積が小さくなることを歓迎する。そこへ、銀行統合チームから当然の質問が飛ぶ。「銀行、決済ネットワーク、不正検知ベンダー、税務ポータル、SMS プロバイダがアウトバウンドトラフィックを許可リストに登録している。送信元 IP アドレスはどうすればいいのか?」
最初の答えはアーキテクチャ上のものである。ワークロードはプライベートサブネット内に配置され、アウトバウンドトラフィックはマネージド NAT ゲートウェイを通過する。NAT ゲートウェイは少数のパブリック IPv4 アドレスを使用し、それらのアドレスはパートナーの許可リストに記録される。ログは内部ワークロード ID を外部の送信元アドレスおよびポートにマッピングし、プロバイダの監視はバイト数、パケット数、接続数、障害、課金を表示する。図面上ではこれはクリーンだ。内側はプライベート、外側はパブリック、中間に制御されたチョークポイントがある。
第二の答えは経済的なものだ。それらのパブリック IPv4 アドレスは単なる数字ではない。取引相手の運用記憶に埋め込まれたクレデンシャルである。銀行が API 呼び出しを受け入れるか、不正検知エンジンがリクエストを見慣れたものと扱うか、電子メールベンダーが継続性を見るか、規制当局の提出先が手動例外を回避するか、インシデントレスポンダーが自社のトラフィックをプラットフォームの他のテナントから分離できるかを決定する。それらを変更することは、サブネットラベルを変更するのとは違い、ビジネスパスポートを変更するのに近い。
第三の答えは制度的なものだ。誰がアドレスを管理するのか?フィンテックがクラウドプロバイダのアドレスを使う場合、プロバイダがパブリックな出力 ID を供給し、価格を設定し、アカウントに関連付け、予約、移動、削除、不正利用対応、リージョン利用、請求に関するルールを変更できる。もしフィンテックが自社の APNIC 登録済み IPv4 レンジを持ち込めば、外部 ID を保持し、評判を守り、プロバイダのプールへの依存を減らせるかもしれない。しかし、プロバイダの BYOIP 受入プロセスを通過し、適切なルーティング承認を作成し、レンジを正しいアカウントとリージョンに紐付け、プラットフォーム固有の制限を受け入れ、同じレンジを他に移す前に慎重にデプロビジョニングしなければならない。
これこそが本題である。クラウド NAT はしばしばプライベートネットワークのための便宜として説明されるが、同時にクラウドプラットフォームがアドレス希少性をプラットフォームパワーに変えるメカニズムでもある。その力は荒々しいものではない。パケットに対する目に見える独占ではない。それは製品のデフォルト、パブリック IPv4 料金、NAT 処理料金、BYOIP 適格性、アカウント制御、ルーティング承認、不正利用の評判、パートナーの許可リスト、そして離脱の運用上の苦痛に分散している。急速なクラウド採用が成熟した通信事業者、国家クラウドプロジェクト、フィンテック統合、ゲームプラットフォーム、断片化された規制管轄と共存するアジア太平洋において、その結果はサービスのパブリックな顔を誰が所有するかという静かな移行である。
これはクラウド製品の解説ではない。NAT ゲートウェイ、Elastic IP アドレス、カスタムプレフィックス、外部アドレス、パブリックアドバタイズドプレフィックス、Elastic IP サービスはプロバイダによって異なる。名前は変わるが、根本的な経済構造は安定している。大規模なパブリック IPv4 在庫を持つプラットフォームは利便性を販売できる。可搬性のあるアドレス資本を持つ顧客は交渉できる。アドレス資本のない顧客はプラットフォームからアイデンティティを借りる。APNIC の記録はどのアーキテクチャを選択すべきかを決めるものではない。顧客が自らのアドレスリソースに対して十分な制御を証明し、選択を意味あるものにできるかどうかを決めるのである。
パブリックアドレスがエグレス認証情報となった
ほとんどのアプリケーションチームはアドレスの経済学を逆順で学ぶ。彼らはまず、安価で豊富にあり、自動化しやすいという理由でプライベートアドレッシングを発見する。クラウドテンプレートはプライベートサブネットを作成する。コンテナノードはプライベートアドレスを受け取る。サーバレスおよびマネージドサービスは送信元ホストを隠蔽する。セキュリティグループ、ルーティングテーブル、アイデンティティポリシーはパブリック番号よりも重要に見える。パブリック IPv4 は古いインターネットのように感じられ、境界では必要だが、設計の中心ではない。
その印象はプラットフォーム内では部分的に正しい。境界では誤りである。外部世界は依然として送信元アドレスを見る。銀行は依然として静的なエグレスレンジを求める。政府ゲートウェイはサプライヤーにパブリックエンドポイントの申告を求める。レガシーな不正検知ベンダーは依然として IP レピュテーションをスコアリングする。SaaS ベンダーは依然として送信元ネットワークにレート制限、国ルール、テナント履歴を適用する。メールシステムは以前の振る舞いを記憶する。ゲームや広告プラットフォームはアカウントシグナルと IP シグナルを組み合わせて不正と戦う。セキュリティオペレーションセンターは既知のエグレス IP の周りに例外を記述する。抽象的なクラウドアイデンティティに基づく例外が組織境界を越えることは稀だからである。
その結果、分割されたアイデンティティが生まれる。クラウド内部では、アイデンティティはアカウント、ロール、ワークロード、サービスプリンシパル、ポリシー、タグである。クラウド外部では、アイデンティティはいまだにパブリック IP アドレス、プレフィックス、ASN、リバース DNS パターン、ジオロケーションレコード、レピュテーション履歴、一連のパートナー許可リストである。NAT は二つの世界の間の翻訳者である。多数のプライベートワークロードを少数のパブリックアイデンティティに圧縮し、その後、インターネットの残りの部分に、それらがあたかも一貫した事業者を表しているかのように信頼するよう求める。
圧縮は有用である。パブリック IPv4 消費を減らし、プライベートサブネット設計を管理可能にし、パートナー許可リストに配置しなければならないアドレスの数を制限する。ログとポリシーのために少数のエグレスチョークポイントをセキュリティチームに提供する。しかし圧縮は管理権も生み出す。外部アドレスがプラットフォームに属するならば、プラットフォームは単にコンピュートとネットワーク輸送を販売しているだけではない。顧客の公の顔を貸し出しているのである。
そのレントは公表された時間当たりの価格だけではない。すべての契約と許可リストに組み込まれた依存関係を含む。1 万件のパートナーリクエストを送り、4 つのクラウドアドレスをホワイトリストに登録したフィンテックはスイッチングコストを生み出している。アンチチート、決済、カスタマーサポートをプロバイダ所有のエグレスアドレスを通じて運営するゲーム事業者はレピュテーション依存を生み出している。文書提出のために少数のクラウド NAT アドレスを認定した公共セクターベンダーは、それらのアドレスを調達、監査、インシデントプレイブックに埋め込んでいる。顧客はコードとデータを所有しているかもしれないが、プラットフォームは外部世界がサービスを認識するアドレスの記憶を依然として所有しているかもしれない。
これが、クラウド NAT が IPv4 希少性の経済学に属する理由である。NAT は希少なアドレスをより遠くまで引き伸ばすが、その引き伸ばしは制度的な仲介者を通じて行われる。その仲介者がキャリアである場合、議論は CGNAT、ログ、合法的な要求、不正利用の帰属、サポートコストになる。仲介者がクラウドプラットフォームである場合、議論はパブリック IP 価格、アカウント権限、プロバイダプール、BYOIP 受入、クラウド退出摩擦になる。どちらも希少性への対応であり、異なる形の力を配分する。
価格設定がアドレスを再び可視化した
10 年間にわたり、クラウドユーザーはパブリック IPv4 を付属品として扱うよう訓練されてきた。それはマシン、ロードバランサ、ゲートウェイ、またはマネージドサービスにバンドルされていた。アイドル状態の予約に対していくつかの料金は存在したが、アドレス自体は常に普遍的なラインアイテムとして現れるわけではなかった。それによって経済性は無視しやすくなった。エンジニアはコンピュート、ストレージ、データベースライセンス、データ転送、可観測性を最適化した。アドレス数は衛生上の問題だった。
最近の価格設定の変化が心理を変えた。AWS は、サービスに接続されているかアイドル状態であるかを問わず、すべてのパブリック IPv4 アドレスに対して料金を導入した。公開資料では公表レートを IP 時間あたり 0.005 米ドルとし、NAT ゲートウェイの料金もゲートウェイ時間と処理データに対して課金する。Google Cloud は使用中の外部 IPv4 アドレスの料金を設定し、Cloud NAT によって使用される外部 IP アドレスもネットワーク料金表でカウントする。Azure は NAT ゲートウェイリソース時間と処理データに対して課金し、パブリック IPv4 プレフィックスはカスタム BYOIP プレフィックスに由来しない限り、IPv4 アドレスあたり時間単位で課金する。Alibaba Cloud のパブリック Elastic IP モデルは多くの場合データ転送または帯域幅の料金と設定保持料金を含み、BYOIP 文書では顧客のパブリック IPv4 レンジの移行について記述しており、公開向けサービスの IP を変更しないままにできる。
正確なレートはプロバイダ、リージョン、サービスクラス、契約によって異なるが、その変動がポイントではない。ポイントは、パブリック IPv4 がクラウド設計の課金単位として戻ってきたことである。NAT ゲートウェイは今や二つの希少性価格の間に位置する。一つはパブリックアドレス自体のコストであり、もう一つはプライベートワークロードからインターネットへの経路としてマネージド変換を利用する課金である。その課金はアプリケーション収益と比べると小さいかもしれないが、小さな課金でも誰が希少な入力を管理しているかを明らかにしうる。
小規模なデプロイメントにとっては、1 時間あたり 0.005 ドルは致命的ではない。数百または数千のパブリックアドレス、テストアカウント、パブリックロードバランサ、NAT ゲートウェイ、マネージドサービス、忘れられた予約が散在する巨大なエンタープライズのエステートでは、請求書が可視化される。財務チームはなぜパブリック IP の数がそれほど多いのかを問い、セキュリティチームはなぜすべてのワークロードが直接の露出を必要とするのかを問い、アーキテクトは NAT を通じてエグレスを統合する。統合はアドレス数を減らすが、アイデンティティも集中させる。多数のパブリックエンドポイントの代わりに、企業は少数のプラットフォームに紐付いたエグレスアイデンティティを持ち、その障害、評判、またはアカウントの問題が一度に多数のサービスに影響しうる。
したがって価格設定の変化は二つの相反する行動を促す。プライベートサブネットと NAT を使ってパブリック IPv4 の使用を減らす顧客に報いる。また、既に可搬性のある IPv4 を管理している顧客にも報いる。なぜなら BYOIP は継続性を維持し、一部のプロバイダモデルでは一部のパブリックアドレス料金を回避できるからである。可搬性のあるリソースを持たない顧客はプロバイダのアドレス経済の内部で最適化する。可搬性のあるリソースを持つ顧客は、プロバイダのアドレス価格と自身のプレフィックスを使う機会費用を比較できる。その比較が交渉力である。
ここにアジア太平洋の文脈が重要となる。この地域にはグローバルなクラウドリージョン、高密度な金融ハブ、アウトソースされたサービスプラットフォーム、モバイルファーストの市場、国境を越えたゲームおよびメディアサービス、公共セクターのデジタル化プログラムが存在する。また、非常に異なるアドレス履歴を持つ事業者や企業も存在する。一部の既存事業者や機関は重要な APNIC 認識の IPv4 リソースを保有している。多数の新興企業は保有していない。クラウドプラットフォームは両方の顧客を同じコンソールを通じて見るが、彼らの外部選択肢は異なる。既存事業者はプレフィックスを持ち込むべきかどうかを問える。新規参入者はデフォルトでプラットフォームのパブリックアイデンティティを借りるかもしれない。
この区別は単純な「持てる者対持たざる者」の議論と混同すべきではない。より深いポイントは資本管理である。可搬性のある IPv4 は資本投入物となった。企業がそれを管理していれば、使用するか、リースするか、移転するか、留保するか、あるいはプラットフォームに持ち込むかを決定できる。管理していなければ、プラットフォームのアドレスプールが製品の一部となる。プロバイダの価格設定は単なるコストスケジュールではなく、パブリックアイデンティティの配分システムになる。
BYOIP は可搬性だが、独立性ではない
BYOIP はプラットフォームのアドレスパワーに対する自然な回答である。企業が既に履歴、評判、パートナー認識、APNIC レジストリ証拠を伴うパブリック IPv4 レンジを持っているのであれば、なぜワークロードをクラウドに移す際にそのパブリックアイデンティティを放棄すべきなのか?レンジを持ち込み、クラウドにそれをアドバタイズさせ、ロードバランサ、NAT ゲートウェイ、VM、その他のサポートされたリソースにアドレスをアタッチする。インフラを移しつつアドレスを安定に保つ。
主要プロバイダの公開文書はその約束を明確に記述している。AWS は顧客がパブリックにルーティング可能なアドレスレンジを Amazon EC2 に持ち込み、そのレンジが顧客のアカウントにアドレスプールとして現れることを許可する。前提条件として、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 プロセスに失敗しうる。各失敗は交渉の瞬間となる。顧客はアドレスアイデンティティを保持したい。プロバイダはルーティングの安定性、自身の評判、製品境界を守りたい。APNIC のレジストリ証拠は顧客の証明書類である。しかしプロバイダのポータルが目の前のゲートである。
プラットフォームの管理権は時間的でもある。BYOIP プレフィックスがプロバイダによってアドバタイズされている間、顧客はそれを同時に他のすべての用途に自由に使えるものとして扱えない。クラウドの文書は競合するアナウンスに対して警告し、しばしば移転や移動の前にデプロビジョニングまたは撤収を要求する。これは健全なルーティング衛生であるが、退出コストでもある。あるプレフィックスを一つのプロバイダに配置した顧客は、同じパブリックアイデンティティを別のプロバイダや自社保有のインフラに移す前に、制御されたハンドオフを計画しなければならない。そのハンドオフにはルート、ROA、リバース DNS、DNS レコード、ロードバランサマッピング、ファイアウォールルール、パートナー許可リスト、セキュリティ監視、時には契約上の通知が含まれる。
したがって BYOIP の経済性は、所有権に似た制御とプラットフォームの管理権の間に位置する。可搬性のあるプレフィックスは保有者にレバレッジを与える。プロバイダのパブリックプールへの依存を減らし、評判とパートナー許可リストを維持し、一部のパブリックアドレス料金を削減できる可能性があり、マルチクラウドや退出計画を信頼に足るものにしうる。しかし、プラットフォームの力を消し去りはしない。交渉を「あなたのパブリックアイデンティティを貸してください」から「私のアドレス資本を、それを閉じ込めない条件でプラットフォームに受け入れてください」へと変えるのである。
アカウント権限がアドレス権限になる
クラウドプラットフォームは通常、番号付けに関する劇的な決定を通じてアドレスパワーを行使するのではない。アカウントシステムを通じて行使する。パブリック IP アドレスはアカウント、サブスクリプション、プロジェクト、リージョン、VPC、リソースグループ、ロードバランサ、NAT ゲートウェイ、または Elastic アドレスプールに紐付けられる。顧客は請求書を支払い、ID およびアクセス管理を維持し、サブスクリプションを良好な状態に保ち、認証情報を保護し、不正利用および利用規定を遵守し、パブリックアドレスをワークロードに接続する構成を保持しなければならない。
これはクラウド事業者には馴染みがあるが、IP アドレスをネットワーク資産と考える取締役会にはあまり馴染みがない。コロケーションやキャリア環境では、アドレス管理ファイルはネットワークエンジニアリング、法務、レジストリアカウント保持者と共にあるかもしれない。クラウドでは、実効的なアドレス管理ファイルは組織アカウント、セキュリティ管理者、デプロイ自動化、請求関係、サービスクォータに跨がるかもしれない。どの層でのミスもパブリックアイデンティティに影響しうる。
リスクは仮説ではない。侵害されたクラウドアカウントはリソースを作成、削除、再割り当て、露出させることができる。停止されたアカウントはサービスを中断させる。設定ミスの組織ポリシーは必要なパブリックアドレス操作を妨げる。削除された NAT ゲートウェイはプロバイダの仕組み次第でアドレスを解放または切断しうる。失敗した自動化実行は、パートナー許可リストの準備が整う前にトラフィックを新しいエグレスアイデンティティに移動させうる。請求紛争はサービス継続性の問題になりうる。コンプライアンスレビューは、移行ウィンドウに間に合ってプレフィックスがオンボーディングされるのを妨げうる。
これらのリスクはクラウドプラットフォームが不注意であることを意味しない。多くの場合、プロバイダの管理は顧客が単独で運用できるものよりも強力である。ポイントは別にある。プラットフォームのアカウント権限はアドレス権限になる。なぜなら顧客のパブリックアイデンティティはアカウントを通じて仲介されるからだ。顧客がプロバイダのアドレスを使う場合、依存は直接的である。BYOIP を使う場合でも、プロバイダがプレフィックスをアドバタイズし管理している期間は依存が残る。
これが大規模プラットフォームに、生のアドレス保有量では捉えられない形のアドレスパワーを与える。アドレス在庫は重要だが、管理アーキテクチャも同様に重要である。プラットフォームはアドレスが割り当てられる API、NAT が構成されるコンソール、変更を承認するアイデンティティシステム、パブリック利用に価格をつける課金モデル、苦情に対応する不正利用チーム、BYOIP を利用できるサポートサービス、レンジを顧客管理に戻すデプロビジョニングシーケンスを管理する。これは所有権ではなく、運用上のレバレッジである。
このレバレッジの連鎖における APNIC の役割は間接的だが重要である。クリーンな APNIC 記録はクラウドアカウントを保護しない。請求停止を防がない。プロバイダがすべての BYOIP ユースケースをサポートするように強制しない。しかし、誰がプレフィックスを管理しているか、どの組織がルーティング承認を作成できるか、取引相手がどの履歴を信頼すべきかについての曖昧さを減らす。レジストリ証拠が精密であればあるほど、クラウドアカウント権限とアドレス権限が曖昧になり始めたときの顧客の手札は強くなる。
アドレスの評判は記憶であり、在庫ではない
パブリック IPv4 の価格設定はエンジニアにアドレスを数えるよう促す。アドレスの評判は、すべてのアドレスが等しいわけではないことを思い出させる。長期にわたる事業利用、安定したジオロケーション、一貫したリバース DNS、低い不正利用履歴、既知の取引相手の許可リストを備えたクリーンなプレフィックスは、プロバイダプールから新たに割り当てられたアドレスよりも価値がありうる。逆に、不正利用、スパム、スクレイピング、不正なサインアップ、設定ミスのサービスの履歴があるパブリックアドレスは、技術的にルーティング可能でも割引を伴いうる。
クラウド IP の再利用やクラウドスクワッティングに関する学術研究は、評判と潜在的な設定がなぜ重要かを示してきた。パブリッククラウドはアドレスを大規模に割り当て、再利用する。サービスが不十分にデコミッションされると、古くなった DNS レコード、サードパーティの統合、ソフトウェアのコールバック、顧客のトラフィックが、アドレスが移動した後も依然としてそれを指している可能性がある。研究者たちは、アドレスの再利用が以前のテナントと後の保持者にとって機密トラフィックを露出させ、セキュリティリスクを生み出すことを実証した。クラウドスケールでの安全な IP 割り当てに関する他の研究は、パブリッククラウドのアドレスプールをセキュリティ上敏感なリソースとして扱っている。なぜなら悪意のあるテナントが割り当て挙動、評判、レート制限の前提を悪用できるからである。
規制対象のサービスをクラウドに移行させつつあるアジア太平洋の事業者にとって、これは単なるセキュリティペーパーの関心事ではない。アドレスの記憶は銀行統合、顧客の信頼、不正評価、到達性、サポートチケット、インシデント対応に影響しうる。サービスがプロバイダ所有の NAT アドレスを使う場合、プラットフォームのプール評判の一部とプロバイダの割り当て規律を引き継ぐ。BYOIP を使う場合、自身の履歴をクラウドに持ち込む。各選択肢にリスクがある。プロバイダアドレスは運用上便利だが可搬性に劣るかもしれない。顧客アドレスは可搬性が高いが、より強力な証拠、より良い衛生、注意深いクラウドオンボーディングを必要とする。
NAT は評判の重要性を増幅させる。なぜなら多数のワークロードが同じパブリックアイデンティティを共有するからだ。NAT ゲートウェイの背後にある一つのサービスが悪質に振る舞えば、取引相手は問題を引き起こした内部ワークロードではなく、共有されたエグレスアドレスを見るかもしれない。ゲートウェイが決済、分析、顧客メッセージ、脆弱性スキャン、ソフトウェアアップデート、管理呼び出しを運ぶならば、評判の影響は機能横断的になりうる。内部ログは精密かもしれないが、外部の当事者はパブリック IP とタイムスタンプしか見えないかもしれない。
これもプラットフォームがレバレッジを得るもう一つの方法である。彼らはマネージド NAT、ログ統合、不正利用プロセス、DDoS 防御、IP 評判ツール、アドレスインサイト製品を提供できる。これらのサービスは価値があるが、顧客をプラットフォーム固有の可観測性と応答システムへと深く引き込む。パブリックなエグレス評判を説明し、防御し、修復するためにプロバイダに依存すればするほど、迅速に離れることは難しくなる。
可搬性のあるアドレスだけでは評判を解決しない。それらは接頭辞に評判が追従するため、保持者をより責任ある立場にさえしうる。しかしそれこそがアドレス資本が重要である理由である。自身のプレフィックスを持つ顧客は、評判を資産として維持するインセンティブを持つ。プロバイダアドレスを使う顧客は間接的に評判を借りており、修復の速度を決定するのは顧客自身の証拠ではなく、プロバイダの管理対応であることに気づくかもしれない。
退出摩擦は許可リストの中に潜む
クラウドのロックインは通常、データベース、プロプライエタリサービス、データエグレス、マネージド Kubernetes バリアント、アイデンティティシステム、運用ツールを通じて議論される。それらは現実のものである。しかし、多くの規制対象および B2B サービスにとって、パブリックなエグレスアイデンティティは同じくらい粘着性がありうる。ロックインはコードライブラリの中にはない。他の人々のファイアウォールの中にある。
すべてのパートナー許可リストは小さな調整コストである。フィンテックは、銀行、決済代行業者、カードネットワーク、分析ベンダー、税務当局、カスタマーサポートプラットフォーム、不正検知ベンダー、SMS ゲートウェイに新しいソースレンジを受け入れさせる必要があるかもしれない。ゲームプラットフォームは、アンチチートベンダー、決済ゲートウェイ、CDN オリジンルール、パブリッシャーツール、モデレーションシステム、地域コンプライアンスインターフェースに新しいアイデンティティを受け入れさせる必要があるかもしれない。公共セクターのクラウドサプライヤーは、調達ファイル、セキュリティ認証、侵入テストの例外、監査レポート、運用ラン book を更新する必要があるかもしれない。各取引相手には独自の変更ウィンドウ、リスク選好、書式、証拠基準がある。
プロバイダ所有の NAT アドレスは、プラットフォームが即座に使えるパブリックアイデンティティを提供するため、最初の移行を容易にする。二度目の移行を難しくする。なぜならそのアイデンティティは真に顧客のものではないからだ。顧客がプロバイダを去るならば、許可リストを変更しなければならない。顧客がアカウントを統合したり、リージョンを変更したり、NAT ゲートウェイを再構築したり、別のプロバイダに移ったりするならば、取引相手に連絡しなければならない。プロバイダが製品制限や価格を変更すれば、顧客は自分のアドレスアイデンティティが、むしろ再交渉したい商用関係に絡まっていることに気づくかもしれない。
BYOIP はそのロジックの一部を逆転させる。最初の移行は、顧客がプロバイダの受入、ルーティング承認、アカウント制御を通じてプレフィックスを持ち込まなければならないため、より困難である。二度目の移行は、プロバイダがクリーンにデプロビジョニングし、次のプラットフォームがプレフィックスを受け入れるならば、パブリックアイデンティティが移動できるため、より容易になりうる。顧客は将来の退出オプション性を買うために前もって複雑さを支払う。
そのオプション性は、顧客が決して退出しなくても価値を持つ。信頼できる外部選択肢は交渉を変える。「私たちはパブリックアイデンティティを移動させることができる」と言える顧客は、「アプリケーションを再構築し、すべてのパートナーに許可リストの変更を依頼できる」としか言えない顧客とは異なる。前者はプラットフォームを比較できる。後者は自らの過去の設定と交渉している。
APNIC のレジストリ証拠は、その外部選択肢の静かな支えである。記録は誰がリソースを保持しているかを示す。RDAP と Whois はリソースを可読にする。RPKI と ROA はどの AS がプレフィックスを発信してよいかを示すのを助ける。移転ログと履歴記録は取引相手が継続性を理解するのを助ける。これらはどれも華やかなものではない。それは最良の意味での書類仕事である。すなわち、企業がプラットフォームにアイデンティティの供給を頼むことなく移動することを可能にする証拠である。
APNIC の課題は証拠の品質であり、クラウド監督ではない
APNIC がクラウド NAT 設計を規制すべきだと主張するのは誤りであろう。レジストリは、顧客がマネージド NAT、NAT インスタンス、パブリックロードバランサ、プロバイダアドレス、BYOIP、IPv6、デュアルスタック、またはハイブリッド構成のいずれを使うべきかを決定すべきではない。それらは事業者の選択である。レジストリはクラウドの請求書を支払わず、アプリケーションを実行せず、銀行統合チケットに直面せず、インシデントコールに応答しない。
有用な APNIC の問いはより狭い。レジストリ層はアジア太平洋のリソース保持者に、アドレス制御に関する明確で信頼性が高く可搬性のある証拠を提供しているか?保持者は BYOIP をオンボーディングするのに十分な速さで自らの権限を証明できるか?不必要な摩擦なしにルーティング承認を作成または調整できるか?取引相手は曖昧さなく公開記録を検査できるか?移転、合併、再編は商業的生活が求める速度で記録に反映されるか?一つのレジストリ管理パスが遅くなったり、捕捉されたり、争われたりした場合に、リソース保持者は継続性を維持できるか?
これが狭義のレジストリの見方である。レジストリは一意性を保護し、制御を記録し、連絡可能性をサポートし、セキュリティ表明を保持し、移転を記録し、監査証跡を保存し、希少性を裁量的命令に変えることを避けるべきである。IPv4 が資本となった時点で、レジストリの義務はより広範になるのではなく、より規律的になる。レジストリの記録は制御を記述するものであり、クラウドアーキテクチャや顧客の地理に対するライセンスになるべきではない。
このドクトリンが重要であるのは、レジストリ証拠が弱まるときにプラットフォームパワーが拡大するからである。顧客自身のアドレス証明が使いにくいならば、プラットフォームのアドレスプールがより容易になる。合併後にレジストリ記録が不明瞭であれば、BYOIP よりもプロバイダアドレスが容易になる。移転の認識が遅ければ、買い手はクラウドオンボーディングを遅延させたり、一時的にプロバイダアドレスを借りたりするかもしれない。一時的な借り入れがその後、許可リストの蓄積のために恒久的になる。移行の最初の段階での小さなレジストリ摩擦が、後のプラットフォーム依存になる。
このように、レジストリの裁量とプラットフォームパワーは意図せずして相互に強化されうる。厚いレジストリプロセスは必ずしも公益層に力を留めない。それはプロバイダのアドレスが消費するのにより単純であるため、顧客をプライベートプラットフォームアイデンティティへと押しやるかもしれない。プロバイダはその後、アドレスレントを稼ぎ、トラフィックをログし、アカウント境界を定義し、不正利用プロセスを処理し、サービスの実質的なパブリックアイデンティティとなる。レジストリは事業者を保護したのではなく、事業者の外部選択肢をより高価にしたのである。
したがって APNIC の最善の貢献は、クラウド依存を不可能にすることではない。アドレスの自己所有を利用可能にすることである。それは正確な記録、予測可能な移転記録、タイムリーな RPKI 操作、明確な保持者権限、可読な RDAP/Whois、境界付けられた執行、可搬性指向の手続きを意味する。これらはイデオロギー上の気取りではない。自らのパブリックアイデンティティを保持したいクラウド顧客のための市場インフラである。
アドレス割り当て者としてのクラウドプロバイダ
伝統的なレジストリの物語は、APNIC がインターネット番号リソースを割り当てまたは記録し、クラウドプロバイダは他の皆と同じようにそれを消費するというものである。実際には、大規模プラットフォームは自らの製品システム内部でプライベートなアドレス経済も運営している。彼らは顧客がデフォルトで予約できるパブリックアドレスの数、どのサービスがパブリック IPv4 を露出するか、パブリックエンドポイントが自動的か明示的か、NAT がどのようにスケールするか、NAT ゲートウェイが使用できるアドレスの数、ポートがどのように割り当てられるか、どのログが利用可能か、各単位にどの価格が付くかを決定する。
これはレジストリ割り当てではないが、割り当てに似ている。プラットフォームは自身のパブリックプールへのアクセスと顧客所有のレンジへの受入を割り当てている。クォータ、価格、サポートチケット、製品制限、不正利用防止管理、アカウントレビューを通じて配給する。またデザイン上のデフォルトを使って行動を形成する。マネージドサービスがプライベート接続を容易にし、パブリック IPv4 を高価にすれば、顧客は統合する。BYOIP がより大きなプレフィックスや特定のリソースタイプに限定されれば、一部の顧客しかアイデンティティを保持できない。パブリックアドレスが簡単に作成でき、アカウント間で監査が困難であれば、財務が介入するまで顧客はアドレス請求書を積み上げる。
この内部アドレス経済はプラットフォームの観点からは合理的である。パブリック IPv4 は希少である。不正利用リスクは現実である。ルーティング安定性は重要である。プロバイダプールは保護されなければならない。ある顧客の誤用が多数のテナントに影響しうるため、プラットフォームは明確な制御を必要とする。しかし合理的な制御も交渉力を生み出す。何百万もの顧客エンドポイントを管理するプロバイダは、運営上の必要性を製品依存に変換しうる。
市場のテストは、顧客が信頼できる代替手段を持っているかどうかである。顧客はプロバイダアドレスを使える。自分のアドレスを持ち込める。第三者を通じてアドレスをリースし、許可されている場所に持ち込める。エグレスをクラウド間で分割できる。パブリックアイデンティティのためにコロケーションを維持し、プライベート接続をクラウドワークロードに使うことができる。取引相手がサポートする場合には IPv6 を使い、残りには IPv4 を維持できる。各選択肢にはコストがある。重要なポイントは、APNIC のレジストリ証拠がいくつかの選択肢のコストを下げ、プロバイダ管理が他の選択肢のコストを上げるということである。
これはまた、クラウドプラットフォーム内部でのパブリック IPv4 価格が小さいと片付けるべきではない理由も説明する。月額 3 〜 4 ドルのアドレスラインアイテムがハイパースケールプロバイダに力を与えるのではない。力はバンドルから来る。パブリックアドレス在庫 + NAT 製品 + アカウントシステム + ログ + サポート + 不正利用プロセス + パートナー許可リスト慣性 + BYOIP 受入。価格はアドレスを可視化する。バンドルはプラットフォームを重大にする。
これが成長圧力や CGNAT と異なる理由
APNIC の地域は真の成長圧力に直面している。モバイル需要、クラウドオンボーディング、フィンテックのリーチャビリティ、公共セクターのデジタル化、既存事業者のアドレスの厚みはすべて、誰が迅速に拡大できるかに影響する。それは別の記事の重心である。クラウド NAT の問題はより狭い。顧客がプラットフォームを使用することを決定し、誰のパブリックアドレスアイデンティティがインターネットに面するかを選択しなければならなくなった後に何が起きるかを問う。
CGNAT もまた隣接しているが異なる。キャリアグレード NAT は共有パブリック IPv4 アイデンティティのコストを、加入者への帰属、合法的要求、アプリケーション障害、不正摩擦、サポートコール、静的なアドレスプレミアムへと移行させる。クラウド NAT はそのコストをプロバイダのエグレス製品、パブリック IP 料金、アカウント権限、パートナー許可リスト、アドレス評判、BYOIP 受入、退出摩擦へと移行させる。共通の概念は変換である。経済的表面は異なる。
キャリア NAT では、エンドユーザーは共有パブリックアドレスがアプリケーションの振る舞いを形作っていることを知らないかもしれない。クラウド NAT では、顧客は通常アーキテクチャを選択するが、その選択はプロバイダ製品と外部の取引相手によって制約される。キャリア NAT では難しい証拠問題はしばしば加入者、ポート、時間のマッピングである。クラウド NAT では難しい証拠問題は、商用プラットフォームを越えたワークロード、アカウント、パブリックアドレス、パートナー例外、アドレス制御証明のマッピングである。
この区別は、改善策が異なるために重要である。CGNAT の改善策はログの精度、サポート負担、合法的要求の規律、パブリック IP 製品の可用性、IPv6 準備に焦点を当てるかもしれない。クラウド NAT の改善策はアドレス可搬性、BYOIP の透明性、プロバイダ中立の証拠、許可リスト移行計画、アカウント制御ガバナンス、単一プラットフォーム外で使用できるレジストリ記録に焦点を当てる。
会計的視点:レント、資本、オプション価値
クラウド NAT 経済を読み解く単純な方法は、レントと資本を分けることである。プロバイダのパブリックアドレスは借りられたアイデンティティである。BYOIP アドレスは顧客が管理する資本であり、プロバイダの環境に受け入れられたものである。NAT ゲートウェイは変換インフラであり、借りられたアイデンティティと顧客資本のいずれも使用できる。パートナー許可リストは、選択されたアイデンティティに価値を結びつける関係固有の投資である。
顧客がプロバイダのアイデンティティを借りる場合、前払いコストは低い。移転ファイルも、ROA 準備も、プレフィックス受入も、持ち込むのに十分クリーンかどうかの心配も、顧客所有レンジの外部ルーティングを調整する必要もない。顧客はプロバイダに支払い、移動する。サービスが新しく、低リスクで、一時的で、深く許可リスト化されていない場合には効率的である。サービスが規制対象で、評判に敏感で、マルチクラウドで、買収されやすく、長年続くことを意図している場合にはあまり効率的ではない。
顧客がアドレス資本を使う場合、前払いコストは高い。保持者は APNIC 記録を維持し、正しいアカウント権限を管理し、ルートオリジン承認を準備し、プロバイダの検証を満たし、切り替えを計画し、リバース DNS と評判を保護し、デプロビジョニング規律を管理しなければならない。しかし顧客はオプション価値を買う。プロバイダを越えて外部アイデンティティを保持できる。一部のプロバイダアドレス希少料金を BYOIP が免除される場合にはそれを回避できる。取引相手に継続性を証明できる。アドレスの評判をプロバイダのプール内部ではなく自らのバランスシートに保持できる。
オプション価値は移行プロジェクトにおいてしばしば過小評価される。なぜなら移行ビジネスケースは即時の節約に焦点を当てるからだ。スプレッドシートは月次のコンピュート、データベース、ストレージ、データ転送、NAT ゲートウェイ、サポート、人員を比較する。200 の取引相手に許可リストの更新を依頼せずに離脱できることに価値を割り当てることは稀である。プロバイダ所有のエグレスアドレスと、10 年の事業履歴を持つ APNIC 認識のプレフィックスとの違いに価格をつけることは稀である。アカウント停止、買収、紛争、制裁レビュー、プロバイダポリシーの変更がパブリックアイデンティティを中断させる可能性があるかを問うことは稀である。
この省略はプラットフォームに有利に働く。プラットフォームは顧客生涯価値を理解している。顧客はしばしばプロジェクト単位で予算を組む。プラットフォームは今、クリーンな移行を売り、後に退出摩擦を捕捉する。顧客の最善の防御はクラウドへの敵意ではない。資産を意識したアーキテクチャである。パブリックアイデンティティが重要ならば、最初の許可リストが提出される前にそれを戦略的資産として扱うことである。
優れたガバナンスの姿
この分野での優れたガバナンスは、APNIC がクラウドの審判になることを必要としない。異なるアクターにわたる三つの規律を必要とする。
第一に、クラウド顧客は移行前にパブリックなエグレスアイデンティティの棚卸しを行うべきである。問いは単に「どれだけのパブリック IP が必要か?」ではない。「どの外部関係がこれらのアドレスに依存しているか?誰がそれらを所有しているか?それらはどのような評判を帯びているか?それらを変更するのにどれだけのコストがかかるか?」である。規制対象または大量のトラフィックを持つサービスは、ドメイン管理ファイルや証明書管理ファイルと同じく、アドレス管理ファイルを持つべきである。そのファイルは保持者、レジストリ証拠、ROA、リバース DNS、クラウドアカウントマッピング、NAT ゲートウェイ設定、パートナー許可リスト、不正利用連絡先、退出シーケンスを特定すべきである。
第二に、プラットフォームは BYOIP の受入とデプロビジョニングをより透明にすべきである。最小プレフィックスサイズ、サポートされるリソース、リージョン、想定されるタイムライン、ROA 要件、アカウント移転の制限、同時アナウンスのリスク、リバース DNS プロセス、不正利用エスカレーション、顧客への返却手順は、顧客がコミットする前にそれらに価格をつけられる程度に予測可能であるべきである。プロバイダは受入を不透明な特権に変えることなく、ネットワークを保護できる。プロセスが予測可能であればあるほど、プラットフォームパワーがサポートチケットの中に隠れることは少なくなる。
第三に、APNIC はレジストリ証拠を市場インフラとして扱うべきである。クラウド顧客にとってのその価値は、どのプロバイダを使うべきかを教えられることではない。その価値は、顧客が管理するアドレス資本をプロバイダ、パートナー、貸し手、監査人、取引相手にとって判読可能にすることである。それには正確な記録、タイムリーな更新、信頼できる RDAP/Whois、利用可能な RPKI、履歴の可視性、予測可能な移転記録、既に埋め込まれた運用資産に対する裁量的制御に対する明確な境界が必要である。
これらの規律は控えめなものである。しかし、いくつかの制度的誘惑にも逆らう。顧客は速度を好み、退出コストを後で発見する。プラットフォームは製品固有の粘着性を好む。レジストリは希少性により多くの制御で応えようとする誘惑に駆られうる。しかしネットワーク経済は、証拠が可搬性を持ち、制御がコストを負うアクターに帰するときに、より良く機能する。
公共セクターとフィンテックの利害関係
この問題は公共セクターとフィンテックの環境で一層鮮明になる。なぜならアドレスアイデンティティはしばしばコンプライアンスのオーラを帯びるからである。文書処理ワークロードをクラウドに移行させつつある省庁のサプライヤーは、安全な提出、監査取得、または省庁間 API のために承認されたアウトバウンドアドレスを必要とするかもしれない。決済会社は銀行接続のために安定したアドレスを必要とするかもしれない。ヘルスケアプラットフォームは、クラウド移行がエンドポイントの信頼を変えないことを取引相手に安心させる必要があるかもしれない。地域のゲーム事業者は、決済、アンチチート、モデレーションベンダーのために安定したエグレスを必要とするかもしれない。
これらの事例は稀なエッジ条件ではない。成熟したサービスをデジタル化する通常の作業である。サービスが古い制度と対話すればするほど、パブリック IP アイデンティティが信頼ファイルの一部であり続ける可能性が高まる。公の物語はゼロトラスト、サービスアイデンティティ、API レベルの認証を称揚するかもしれない。運用上の形式は依然として IP 許可リストを含んでいる。なぜならそれらはシンプルで、監査可能で、組織の境界を越えて馴染み深いからである。
これがクラウド NAT をガバナンス問題にする。NAT ゲートウェイは、現代のプラットフォームアーキテクチャがレガシーな信頼インフラと出会う場所である。プライベートワークロードが古い許可リストシステムに参加することを可能にする。また、公の顔がプロバイダに属するか、事業者に属するかを決定する。プロバイダのアドレスが使われる場合、公的機関や銀行は実質的に、顧客のアカウントをプラットフォーム所有のアドレス経済内部で信頼している。BYOIP が使われる場合、機関や銀行は、レジストリ証拠を通じて制御が見える可搬性のあるリソースに信頼を結びつけることができる。
どちらのモデルも普遍的に優れているわけではない。プロバイダアドレスは新しいサービス、低リスクのワークロード、プロバイダの制御が主な保証である場合に適切かもしれない。顧客管理のプレフィックスは、永続的な取引相手、マルチプロバイダ戦略、買収リスク、高い評判価値を持つサービスにより適しているかもしれない。過ちは、デフォルトの NAT ウィザードが速かったために偶発的に決定を下してしまうことである。
プラットフォーム権力は不可視の時に最も強い
最大のアドレス権力の移行は、権力の移行として発表されることは稀である。それらは価格更新、製品改善、セキュリティ要件、クォータ変更、不正利用制御、新しい BYOIP 機能、コスト最適化ガイダンスとして発表される。それぞれは防御可能かもしれない。それらが共に、顧客のパブリックアイデンティティをプラットフォームの管理ドメインへと移動させる。
エンジニアはより少ないパブリックエンドポイントを見る。財務チームは IPv4 ラインアイテムを見る。セキュリティチームはより良いプライベートサブネット規律を見る。コンプライアンスチームは安定した許可リストを見る。プラットフォームはマネージドゲートウェイとパブリックアドレス製品を通じてより多くのワークロードが流れるのを見る。APNIC のリソース保持者は、自身のプレフィックスを使うこととプロバイダのそれを借りることの違いを見る。同じアーキテクチャが、セキュリティの改善、コスト最適化、権力の移転でありうる。
これが、問いが早期にかつ率直に尋ねられるべき理由である:この移行の後、誰がサービスのパブリックアドレスアイデンティティを管理するのか?答えは「プロバイダであり、それは受け入れ可能だ」かもしれない。「顧客であり、BYOIP を通じて、広告中のプロバイダ管理下で」かもしれない。「ハイブリッドであり、汎用ワークロードにはプロバイダアドレス、規制対象のエグレスには顧客プレフィックス」かもしれない。重要なのは、その答えが意図的なものであることだ。
APNIC ガバナンスにとっての教訓も同様に平明である。希少性が IPv4 を資産化し、クラウドプラットフォームがパブリックエグレスアイデンティティを製品化した。レジストリはクラウド利用に対してより主権的になろうとすることで応えるべきではない。より良い台帳になることによって応えるべきである:より薄く、より速く、より正確に、より可搬性をもって、より予測可能に。事業者に信頼できる証拠を提供するレジストリは、プラットフォームと交渉する能力を強化する。証拠を裁量に変えるレジストリは、彼らを弱体化させる。
シンガポールのフィンテックの移行は、最良の場合、パブリックエグレスアドレスの小さなテーブルで終わる。そのテーブルの背後には、はるかに大きな制度的和解が存在する。企業はプロバイダアドレスを借り、将来の許可リスト摩擦を受け入れたかもしれない。APNIC 認識のプレフィックスを持ち込み、BYOIP 受入の作業を受け入れたかもしれない。リスクに応じてワークロードを分割したかもしれない。設計がどうであれ、パブリックアドレスはもはや背景の詳細ではない。それはクラウドアーキテクチャとビジネス権限の蝶番である。
したがってクラウド NAT は IPv4 希少性の終わりではなく、希少性の最も現代的な形態の一つである。それはプライベートな複雑さを少数のパブリックアドレスの背後に隠し、そしてそれらのアドレスをプラットフォームを通じて価格付けし、管理する。APNIC 証拠層がより良く機能するほど、より多くの事業者がそのアイデンティティを借りるか、自ら持ち運ぶかを決定できる。証拠層がより悪く機能するほど、プラットフォームアイデンティティがデフォルトになる。依然としてパブリックな番号によってサービスを認識するインターネットにおいて、その違いは力である。
情報源と参考文献
- https://heng.lu/the-bill-of-rights-of-uniqueness-coordination/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-why-the-present-registry-model-becomes-impossible-once-ipv4-becomes-a-real-asset/
- https://heng.lu/on-the-absurdity-of-the-ipv6-escape-from-scarcity-narrative/
- https://heng.lu/on-the-manufactured-narrative-of-ipv4-scarcity/
- https://heng.lu/why-ipv6-was-pushed-and-who-it-actually-serves/
- https://heng.lu/on-scarcity-is-not-hoarding-why-ipv4-assetization-strengthens-not-harms-connectivity/
- https://heng.lu/on-why-rir-enforcement-creep-is-the-silent-killer-of-ipv4-liquidity-and-why-it-must-be-stopped/
- https://heng.lu/on-why-ipv6-transition-is-just-another-name-for-a-permanent-dual-stack-tax-and-why-operators-should-stop-paying-it/
- https://heng.lu/unlocking-the-hidden-value-of-ipv4/
- https://heng.lu/on-the-upper-potential-of-ipv4-as-an-investment-asset/
- https://aws.amazon.com/vpc/pricing/
- https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-pricing.html
- https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html
- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/prepare-for-byoip.html
- https://docs.aws.amazon.com/global-accelerator/latest/dg/using-byoip.prepare.html
- https://azure.microsoft.com/en-us/pricing/details/azure-nat-gateway/
- https://azure.microsoft.com/en-us/pricing/details/ip-addresses/
- https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/custom-ip-address-prefix
- https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/create-custom-ip-address-prefix-portal
- https://cloud.google.com/nat/pricing
- https://cloud.google.com/vpc/pricing
- https://docs.cloud.google.com/vpc/docs/bring-your-own-ip
- https://docs.cloud.google.com/vpc/docs/create-pap
- https://www.alibabacloud.com/help/en/eip/bring-your-own-ip
- https://www.alibabacloud.com/help/en/eip/pay-as-you-go/
- https://www.alibabacloud.com/help/en/vpc/ipv4-gateway-overview
- https://www.APNIC.net/about-APNIC/whois_search/
- https://www.APNIC.net/about-APNIC/whois_search/about/rdap/
- https://www.APNIC.net/community/security/resource-certification/
- https://www.APNIC.net/manage-ip/manage-resources/transfer-resources/transfer-logs/
- https://www.APNIC.net/manage-ip/manage-resources/transfer-resources/
- https://arxiv.org/abs/2204.05122
- https://arxiv.org/abs/2210.14999
- https://arxiv.org/abs/2105.03864

