概況
- 経済的単位は NAT ゲートウェイ料金ではない。それは、顧客、銀行、サプライヤー、公共システムがすでに認識している、プラットフォームが管理する公開アイデンティティを保存または置き換えるためのワークロードあたりのコストである。
- セキュリティと可観測性の記録は、公開アドレスを蓄積された証拠に変える。その証拠がプロバイダー割り当てのアイデンティティに結びつけられると、既存事業者は交渉上のレバレッジを得る。なぜなら、移行では帰属と外部の信頼を再構築しなければならないからだ。
- BYOIP は、ホルダーコントロール、宛先の受容、ルーティング、テレメトリー、ロールバックが一緒に証明された場合にのみ、立場を改善する。ポータブルな証拠は、相手先の承認を短縮し、撤退をアーキテクチャ上の主張からテスト済みのオプションに変えることができる。
買収は最後に公開エッジを見つける
統合ミーティングは通常の自信から始まる。2つの事業が統合されている。アプリケーションにはオーナーがおり、データストアには移行計画があり、インフラチームは仮想マシン、コンテナ、マネージドデータベースが優先クラウド環境に再作成される方法を示すことができる。調達部門は既存事業者との困難な交渉を予想しているが、存続を左右するような交渉ではない。取締役会は、統合企業がホスティングを簡素化し、重複するツールを削減し、新しいグループに合わなくなった一連の契約を解消することを部分的に期待して買収を承認している。
部屋の雰囲気を変える質問はコンピューティングに関するものではない。それは調達側から来る。優先プラットフォームが商業条件を拒否した場合、更新期限前に買収したワークロードを顧客、銀行、サプライヤー、セキュリティ調査を破綻させることなく別の場所に移動できるか？最初の答えはデプロイ可能な資産のリストだ。2番目の答えは沈黙だ。なぜなら、公開エッジは同じ注意で棚卸しされていないからだ。決済チェック、ソフトウェア更新、顧客ポータル、規制報告からの発信トラフィックは、プラットフォームが管理する公開アドレスを通じて出ていく。外部の関係者はそれらのアドレスを許可し、監視し、または既知のビジネスと関連付けてきた。ログ、ファイアウォールルール、インシデントファイルは、内部ワークロード名を外部にトラフィックを提示したゲートウェイに結び付ける。
それが、クラウド NAT が小さなアーキテクチャコンポーネントから交渉の表面に変わる瞬間だ。変換デバイスは賢明かもしれない。直接露出を減らし、プライベートワークロードをプライベートに保ち、セキュリティチームに集中ポイントを提供する。経済的問題は異なる。少数のプラットフォーム管理の公開アイデンティティが、多数のワークロードの信頼履歴を運ぶ可能性がある。それらのアイデンティティが移動できない場合、コードが別の場所で完全に実行されても、ワークロードは商業的に移動できない。
これはエンドユーザーのキャリアグレード NAT と同じ問題ではない。小売アクセスネットワークは、共有公開アドレスの背後にサブスクライバを圧縮し、帰属、不正使用、サポート、アプリケーションの破損を処理する。クラウド NAT はエンタープライズおよびプラットフォームアーキテクチャ内に位置する。そのハードコストは主に家庭の苦情やサブスクライバポート検索ではない。それは、買い手が公開エッジを提供するプラットフォームを変更したい場合に、外部から認識されるビジネスアイデンティティを保存するためのコストだ。
これはクラウド依存に関する一般的な嘆きではない。多くのクラウドサービスは、チームがプロバイダーインターフェース、セキュリティコントロール、デプロイ習慣を学ぶため、スイッチングコストを生み出す。公開アイデンティティは、認識が買い手と供給者の関係の外に存在するため、より鋭い。銀行、公共機関、ソフトウェア供給者、主要顧客は、公開送信元アドレスを、どの調達決定がそれを生み出したかを忘れた後も長く信頼するかもしれない。Lu Heng のネットワークアイデンティティの経済学に関するノートは、この点で有用である。なぜなら、それは番号を継続性の表面として扱い、装飾的な技術ラベルとしてではないからだ。ユニークネスコーディネーションの権利章典は制度的規律を提供する。すなわち、共通層は管理を読みやすくすべきであり、使用を許可に変えるべきではない。
統合チームはしたがって新しいレジスタを必要とする。各重要なワークロードについて、どの公開アイデンティティが世界に面しているか、誰がそれらを管理しているか、どの相手先がそれらに依存しているか、どのセキュリティ証拠がそれらに依存しているか、そしてそれらを保存または置き換えるために何が必要かを尋ねなければならない。そのレジスタが存在するまで、移行計画はデプロイ可能なコンピューティングと移動可能な信頼を混同している。
買収の設定は感情を取り除くので有用である。買い手はあるプラットフォームが流行であるか別のプラットフォームが古いかを議論しているのではない。資産が合理化された場合に買収した収益を保護できるかを決定している。顧客によって静かに信頼されるようになった公開アイデンティティは、午後に再デプロイできるアプリケーションよりも価値があるかもしれない。慎重な統合チームは、したがって、アドレス継続性をドメインコントロール、証明書管理、決済マーチャント識別子、銀行署名者と同様に扱う。ビジネスの公開の顔を変更できるのは誰か、その権利を証明する証拠は何か、変更を急いで行わなければならない場合に失われる価値はどれくらいかを尋ねる。
コスト対象は外部認識であり、ゲートウェイ料金ではない
クラウドの請求書は間違った分母を奨励する。購入者にコンピューティング、ストレージ、ネットワーク転送、ゲートウェイ時間、セキュリティサービス、サポート階層を比較するよう促す。その見解はコスト管理に必要だが、経済的なホールドアップを特定しない。依存関係はゲートウェイライン自体ではない。それは、ワークロードが外部の世界に受け入れられ、観察され、非難されるために使用する、組み立てられた公開アイデンティティである。
発信ワークロードは独自の公開アドレスを持っていないかもしれない。それは変換ゲートウェイに到達し、ゲートウェイは顧客、銀行、サプライヤー、公共システムが受け入れた公開送信元アドレスを提示する。同じアドレスがファイアウォールルール、不正防止例外、インシデントレポート、契約サポートノート、セキュリティベースラインに現れるかもしれない。プラットフォームはアカウント内のリソースを見る。エンタープライズはプライベートサブネットからのパスを見る。相手先は既知の送信元を見る。調査者は帰属の境界を見る。これらは別々の資産ではない。それらは同じ外部認識の異なる見方である。
したがって、分子には明示的なプラットフォーム料金以上のものが含まれる。アドレスを保存または置き換えるために必要なエンジニアリング作業、トラフィックが受け入れられる前に必要な相手先の承認、古いパスと新しいパスを一緒に実行しなければならない期間、2つの証拠ストリームを一貫性に保つコスト、および購入者が更新前にそれらのタスクを完了できない場合に既存事業者に支払われる交渉上の譲歩が含まれる。金額を誤った精度に押し込むべきではない。名前付きのボトルネックを含むテスト済みの範囲は、カレンダーを管理する相手先を除外したきれいな数字よりも正直である。
分母には2つの部分がある。第1はワークロードあたりのコストである。共有エグレスアイデンティティは、1つの公開アドレスが多くの内部システムをサポートするため、効率的に見える。購入者が、アドレスが変更された場合にどのシステムが信頼されなくなるか、または追跡不可能になるかを知っている場合にのみ効率的である。外部許可リストのないバッチジョブは、相手先が固定ソースを認識する支払いアプリケーションと同等ではない。プールされたエグレスはアドレス在庫を節約しながら、ビジネス中断を集中させる可能性がある。
第2の部分は、実行可能な出口オプションあたりのコストである。ワークロードがポータブルであるという主張は、購入者が関連するアイデンティティの管理、宛先による受容、機能するルーティングとアタッチメント、生き残るセキュリティ証拠、相手先の移行計画、ロールバックパスを示せない限り、ほとんど意味がない。以前の BTW のルートオブジェクトガバナンスとルーティングセキュリティを財産インフラとしての分析は、アドレス使用に関する公開証拠が商業的依存にどのように影響するかを示している。クラウド NAT バージョンはより狭いが具体的である。購入者は、認識された公開アイデンティティがワークロードと共に移動できるか、またはプラットフォームがその認識の実質的な管理者になっているかを知らなければならない。
この会計はまた、良いクラウド決定を保護する。一部のワークロードは、短命、低リスク、または容易に再識別可能であるため、プラットフォーム割り当てのアイデンティティを使用すべきである。他のワークロードはそうすべきではない。統一ルールは高価で粗いだろう。ポイントは、デプロイ図の優雅さではなく、蓄積する外部認識に従ってワークロードを分類することである。
分類は方向も記録すべきである。インバウンドの公開アイデンティティは通常、顧客が名前、証明書、アドレス、ロードバランサー、コンテンツ玄関を通じてサービスに到達するため、可視である。アウトバウンドのアイデンティティはしばしば静かで、接続を受信する相手先によってのみ発見されるため、より危険である。サプライヤーポータルは、送信元アドレスが何年も前に作成されたファイルと一致するため、API コールを受け入れるかもしれない。顧客はそのアドレスを決して見ないかもしれないが、契約は予告なく変更された場合に失敗する可能性がある。したがって、コスト対象には、トラフィックを引き寄せる公開エンドポイントと、他のシステムにトラフィックを受け入れさせる公開送信元の両方が含まれる。
翻訳は、アイデンティティがプラットフォーム管理であるときに権力になる
翻訳は技術的な行為である。翻訳された公開アイデンティティに対するプラットフォームの管理は経済的な立場である。その区別は重要である。なぜなら、この記事は NAT が良いか悪いかを尋ねているのではないからだ。翻訳は露出を減らし、プライベートアドレッシングを簡素化し、セキュリティチームに管理可能な公開エッジを与えることができる。問題は、そのエッジによって提示される公開アドレスがサプライヤーのアドレス経済に属し、購入者が外部の信頼を再構築せずに持ち運べないときに始まる。
通常のクラウド依存は通常、サプライヤー関係の内部にある。データベースインターフェースは別のデータベースインターフェースと異なる。監視ツールは独自の言語を持つ。セキュリティ製品は特定の形式でルールを保存する。これらの違いは高価になる可能性があるが、多くの場合、エンジニアリング、再トレーニング、契約管理によって解決できる。公開アイデンティティは外部の構成員を追加する。サプライヤーは移行をブロックする必要はない。他の関係者がすでにサプライヤー管理のエッジを認識しているため、交渉力を保持できる。
地域のエンタープライズを考えてみよう。そのカスタマーサポートシステム、文書提出ツール、サプライヤーAPI はすべて、マネージド変換ゲートウェイを通じて出ていく。プラットフォームは企業を強制していない。有用なサービスを提供している。サプライヤーは強力なオペレーターであり、優れたセキュリティと信頼性のあるサポートを備えているかもしれない。しかし時間の経過とともに、ゲートウェイの公開アドレスは第三者のファイルに埋め込まれる。調達がワークロードを移動したいとき、2つのゲートウェイ製品を比較しているのではない。すべての重要な相手先に異なる公開の顔を認識するよう求めるか、別のプラットフォームに企業が管理するアイデンティティを受け入れるよう求めているのだ。
それがサービス依存とアイデンティティ依存の違いである。サービス依存はアプリケーションを再構築できるかどうかを尋ねる。アイデンティティ依存は、再構築後も世界が誰と話しているかを知っているかどうかを尋ねる。最初の質問は主にエンジニアリングとソーシングに属する。2番目は調達、法務、セキュリティ、顧客、財務に属する。
このメカニズムは、隣接する BTW のLACNIC クラウドプロバイダーのアドレスパワーに関する作業にすでに登場しているが、NAT バージョンは独自の扱いに値する。翻訳は認識を集中させるからだ。可視アドレスを持つ公開ウェブサイトは気づかれる可能性が高い。ビジネス間トラフィックに使用される静かなエグレスアドレスは、アプリケーション資産の背後に何年も座っているかもしれない。購入者は、銀行統合、決済ゲートウェイ、税務ポータル、マネージドセキュリティレビューが、古い公開ソースが買収スケジュールで消えることはできないと言ったときにのみそれを発見するかもしれない。
プラットフォームの力は、それが目に見えないままであるときに最も強い。購入者がゲートウェイ料金しか見ない場合、サプライヤー関係は競争可能に見える。購入者がそのゲートウェイに付随する外部認識を見る場合、関係は継続的な交渉になる。サプライヤーはまだビジネスに値するかもしれないが、今は誰も価格設定しなかったアドレス記憶ではなく、サービス価値でそれを保持しなければならない。
これがプロバイダーニュートラルな言語が重要である理由である。このメカニズムは1つのハイパースケールサプライヤー、1つのマネージドサービスブランド、1つの商業モデルに固有ではない。公開アドレスプール、アカウントコントロール、ゲートウェイサービス、セキュリティ証拠を持つプラットフォームは、顧客がアプリケーションを所有している場合でも、外部認識の管理者になることができる。したがって、この記事は名前付きのプラットフォーム価格設定や機能比較を避ける。製品メニューは変わる。永続的な質問は、購入者が認識された公開アイデンティティを提供の変更を通じて持ち運べるか、または各外部関係者が新しいプラットフォーム管理の顔を信頼するよう説得されなければならないかである。
共有エグレスは無関係なワークロードを1つの交渉面に結び付ける
共有エグレスの効率はその危険でもある。単一のゲートウェイまたは少数の公開アイデンティティは、互いに商業的関係のない多くのワークロードグループのトラフィックを運ぶことができる。顧客ポータル、ベンダー更新プロセス、従業員ツール、規制報告サービス、分析コネクタは、アドレス経済と運用の単純さのために設計されたアーキテクチャのため、同じ公開送信元を共有するかもしれない。エントリー時には賢明に見える。出口時にはそれらのカレンダーを結び付ける。
最も弱い依存関係がゲートウェイを所定の位置に保持できる。長い承認プロセスを持つ1つの顧客、保守的なファイアウォール変更ウィンドウを持つ1つのサプライヤー、遅い受け入れを持つ1つの公共セクターシステム、または過去の証拠を必要とする1つの調査により、ほとんどのワークロードがもう必要としないアドレスの廃止を防ぐことができる。購入者はほとんどすべてのコンピューティングを移動し、変更を受け入れていない最後の相手先のために古い公開エッジを保存するために支払いを続けているかもしれない。
これはデュアルスタックコストの話ではない。問題は、2つのアドレスファミリをすべての顧客またはアプリケーションに維持しなければならないことではない。プラットフォーム管理の公開アイデンティティが、異なるビジネスクロックを持つワークロードの共通面になったことである。低リスクのサービスは数日で移動できるかもしれない。支払い統合には数週間の証拠と承認が必要かもしれない。規制対象の顧客には署名付き通知とテストウィンドウが必要かもしれない。セキュリティ調査では、移行計画が予想したよりも長く古いログを解釈可能に保つ必要があるかもしれない。
したがって、調達はアプリケーションオーナーやクラウドアカウントだけでなく、公開アイデンティティ依存によってワークロードをグループ化すべきである。レジスタは、どのワークロードがエグレスアイデンティティを共有し、どの外部関係者がそのアイデンティティを認識し、どの変更が事前通知を必要とし、どの証拠がカットオーバー後に保持されなければならないかを識別すべきである。共有ゲートウェイは、購入者がそれを共有解除するコストも知っている場合にのみ安い。
以前の BTW の顧客継続性に関する作業は、異なる角度から同じ点を指摘している。ネットワーク関係は、顧客がサービス周りのアイデンティティの仮定を再構築せずに継続できるときに価値になる。クラウド NAT はその継続性を保護するか、またはそれを閉じ込めることができる。違いは、エンタープライズがその背後に配信を移動するのに十分な公開アイデンティティと証拠を管理しているかどうかにある。
アーキテクチャ対応は選択的分離である。エンタープライズはすべての内部システムに専用の公開アドレスを必要としない。外部の信頼関係に一致する移行グループが必要である。耐久性のある相手先、遅い承認、または高い証拠義務を持つワークロードは、単に共有ゲートウェイが整然としているという理由で、使い捨てのワークロードと軽率に混ぜられるべきではない。低依存のシステムはプラットフォーム割り当てのエグレスの背後に残ることができる。高依存のシステムは、管理されたアイデンティティ、明示的な移行条件、またはプラットフォームがレバレッジを保持するという価格設定された受け入れのいずれかを必要とする。
これがコストを削減する最初の実用的な方法である。どの無関係なシステムが公開の顔を共有しているかを見つけるために更新紛争を待ってはいけない。信頼表面が購入者自身のアーキテクチャによって書かれた身代金メモになる前に分割せよ。
分割は技術的な整頓ではなく、ビジネスの結果によって導かれるべきである。低リスクのテレメトリを送信するワークロードは、受信システムが同じグループによって所有されている場合、新しい送信元アドレスを許容できる。税務申告、決済指示、医療更新、サプライヤー注文を提出するワークロードは、はるかに遅い変更プロセスを必要とするかもしれない。両方を混ぜる共有ゲートウェイは、低リスクシステムを高リスクのタイムテーブルの乗客にし、高リスクシステムを同じ公開送信元を使用するすべてのマイナーな実験の人質にする。良いアーキテクチャはそれらのカレンダーを異ならせることを可能にする。
サプライヤー割り当てのアドレスはビジネス資格情報に熟成する
プラットフォームによって提供されるアドレスは利便性として始まる。すぐに利用可能で、サプライヤーによって管理され、最小限の交渉でサービスにアタッチされるかもしれない。多くのプロジェクトにとって合理的なエントリー選択である。経済的変化は時間とともに起こる。アドレスは参照、承認、評判、組織的記憶を収集する。購入者が独立して管理していなくても、ビジネス資格情報になる。
資格情報は実用的であり、儀式的ではない。パートナーはアドレスを許可リストに記録する。不正システムはその行動を学習する。サポートデスクはトラブルシューティングノートにそれを書き込む。セキュリティチームはそれを内部ログに結合する。サプライヤーのマネージドサービスはそれを既知のソースとして扱う。顧客はトラフィックがそれから発信されるという文書を受け取る。新しい参照ごとに、プラットフォームのアタッチメント管理が変わらないまま、アイデンティティは購入者にとってより価値になる。
置き換えは常に悪いとは限らない。古いアドレスに評判問題や悪い歴史的関連がある場合、新しい公開アイデンティティはよりクリーンかもしれない。逆に、有用な履歴を持つアドレスは、相手先がすでにそれを学習しているため価値があるかもしれない。エンタープライズはどちらにせよ証拠を必要とする。BTW のアドレス評判汚染の分析は、評判がクリーンな元帳エントリーだけで決まるわけではないため関連する。プラットフォーム、相手先、フィルタリングシステムはすべて異なる履歴を観察するかもしれない。
これが、「独自のアドレスを持ち込む」というアイデアをプラットフォーム機能リストのバッジではなく、管理決定として扱うべき理由である。独自の認識されたアイデンティティを持つ購入者は、配信を変更しながら相手先の信頼を維持できるかもしれない。そのようなアイデンティティを持たない購入者は、サプライヤーの公開の顔をレンタルする。両方の選択肢は合理的であり得るが、混同されるべきではない。前者はアイデンティティをプラットフォームに受け入れられる企業資本として扱う。後者はアイデンティティをプラットフォームサービスの一部として扱う。出口経済学は完全に異なる。
買収は特にコストがかかる。ターゲット企業は、統合後に冗長に見えるアドレス、関係、承認を保持しているかもしれない。すべてを購入者の優先プラットフォームの背後に統合することは、運用を簡素化しながら、独立したアイデンティティオプションを破壊する可能性がある。したがって、デューデリジェンスファイルは、どのアイデンティティがサプライヤー割り当てか、どのアイデンティティが買収されたビジネスによって管理されているか、どのアイデンティティが貴重な相手先履歴を持っているか、どのアイデンティティが移行ハンドルとして保存できるかを尋ねるべきである。外部記憶を理解する前に公開アイデンティティを廃止することは、シナジーを将来の依存に変える可能性がある。
同じ規律が、残らなければならないプラットフォーム割り当てアドレスに適用される。ワークロードが代替の価値がないためにサプライヤーアイデンティティを使用する場合、契約は終了、停止、紛争、移行時に何が起こるかを述べるべきである。ビジネス資格情報になった公開アドレスは、その下のサービスラインが管理上と説明されたという理由だけで消えるべきではない。サプライヤーは自身のプールの永続的なポータビリティを負っていないかもしれないが、購入者は資格情報が依存に熟成する前に置き換えパスを知るべきである。
資格情報が古くなるほど、購入者はカジュアルな保証を疑うべきである。サプライヤーは新しいアドレスを迅速に取得できると言うかもしれず、それはプラットフォーム内では真実かもしれない。公共機関、支払いパートナー、顧客セキュリティチームが迅速に代わりを受け入れるかどうかは答えない。経過時間は最も遅い認識主体によって管理され、最速のプロビジョニングインターフェースではない。したがって、調達は割り当て速度と認識速度を区別すべきである。前者はサプライヤーの製品運用に属する。後者は古いアイデンティティを学習した相手先の市場に属する。
セキュリティ証拠は既存事業者のパスを放棄しにくくする
公開アイデンティティは証拠を通じて信頼され、信仰ではない。セキュリティチームは、ログ、アラート、調査がパスの周りに蓄積されているため、どの公開送信元アドレスがどの内部ワークロード、アカウント、ユーザー、インシデントに対応するかを知っている。移行中、購入者はパケット到達可能性以上のものを保存しなければならない。変更の前、最中、後に何が起こったかを説明する能力を保存しなければならない。
この証拠負担は多くの場合、アドレス変更自体よりも大きい。新しいパスは一般的に同等のセキュリティサービスを持っているかもしれないが、古いパスを使いやすくした特定の履歴を欠いている。検出ルールは既存プラットフォームのフィールドに依存するかもしれない。調査はゲートウェイログをワークロードメタデータに結合する方法で、他の場所で再現するのが難しいかもしれない。保持期間は異なるかもしれない。エクスポート形式は、インシデント後にのみ重要だったコンテキストを省略するかもしれない。相手先は、古いソースが何年もの通常の行動を運んだとき、新しいソースからのトラフィックをどのように信頼できるか尋ねるかもしれない。
既存事業者はこの履歴から恩恵を受ける。たとえそれを悪用しなくても。エンタープライズがクリーンな証拠橋渡しを示せない場合、離脱は無謀に見える。セキュリティリーダーシップは、サプライヤーを愛しているからではなく、帰属が弱い期間を受け入れられないため、移行を遅らせるかもしれない。コンプライアンスチームは新旧のログを調整するよう要求するかもしれない。主要顧客は、新しい公開アイデンティティからのトラフィックがブロックされたり誤って帰属されたりした場合に誰が責任を負うか尋ねるかもしれない。それらの質問は合理的である。それらはまた交渉力である。
証拠橋渡しは、購入者が更新圧力下に置かれる前に設計されるべきである。現在の公開アイデンティティ、それに関連するワークロード、その背後にある内部ソース、関連する相手先、それを解釈するセキュリティツール、カットオーバー後に生き残る保持義務を記録すべきである。次に、宛先環境で新規または保存されたアイデンティティをテストし、ログを比較し、例外を確認し、ギャップの責任を割り当てるべきである。橋渡しは儀式的なリスク文書ではない。それは、エンタープライズが調査能力を放棄せずに離脱できる証明である。
ルーティングとセキュリティの公開は別の層を追加する。以前の BTW のROA 失効リスク、IRR データベースの脆弱性、DNS 委任権限の分析は、管理状態が依存関係者によって使用されるときに運用上重要になる方法を示している。クラウド NAT 設定では、購入者はどのレコードとアサーションが公開アイデンティティをサポートし、どの機関またはサプライヤーがそれらを変更できるかを知る必要がある。
規律は単純である。公開アイデンティティが顧客ファイルやセキュリティ検出に配置されるほど重要であれば、継続性ファイルを持つほど重要である。そのファイルはサプライヤー変更を生き残るべきである。それができない場合、購入者はワークロードをプラットフォーム依存として扱い、依存関係を正直に価格設定すべきである。
継続性ファイルには正常状態だけでなく例外も含めるべきである。セキュリティチームは多くの場合、インシデント、一時的なブロック、不正使用の苦情、緊急許可リスト、顧客エスカレーションから最も多くを学ぶ。これらの記録は、アドレスがなぜ単に信頼されているだけでなく、慎重に信頼されているかを説明する。アドレスを保存するがインシデント履歴を失う移行は防御を弱めるかもしれない。アドレスを置き換えるが証拠を運び、相手先に通知し、古いログを検索可能に保つ移行は、文書化が不十分な名目上安定したパスよりも安全かもしれない。ポイントは継続性をそれ自体のために崇拝することではない。継続性が重要である理由を保存することである。
顧客管理のアドレスでも受容が必要であり、形容詞ではない
顧客管理の公開アイデンティティは、受け入れられたときにのみ価値がある。エンタープライズによって管理されるプレフィックスは外部認識を保存するかもしれないが、それでも宛先プラットフォームに受け入れられ、関連ネットワークによって運ばれ、意図されたサービスにアタッチされ、相手先によって信頼されなければならない。それをポータブルと呼んでもポータブルにはならない。ポータビリティはテストによって証明される関係である。
受容の質問は具体的な形で尋ねられるべきである。どの管理範囲が宛先で使用できるか？どのトラフィック方向がサポートされているか？どのレコードが管理を証明するか？どのルートとセキュリティアサーションが存在しなければならないか？プラットフォームが範囲を拒否したり、アナウンスを停止したり、変更を要求したらどうなるか？矛盾する使用を作成せずに移行のために範囲をステージングできるか？運用管理がいつある環境から別の環境に移動したかを示す証拠は何か？プラットフォームの受容プロセスがカットオーバーを遅らせた場合、誰が支払うか？
これらの質問はプラットフォームに対する不満ではない。顧客管理のアドレス空間をアナウンスまたはアタッチするプラットフォームには正当な責任がある。ルーティングの安定性を保護し、不正使用を防ぎ、権限を検証し、自身のネットワークとの競合を避けなければならない。ポイントは、受容が市場の一部であることである。購入者のアドレス資本は、他の関係者が予測可能な条件下でそれを認識する場合にのみ価値がある。
LARUS Oneの継続性のアイデアは、特定のサービスを購入する命令ではなく、類推としてここで有用である。それは公開ネットワークアイデンティティを配信パスから分離する。Lu Heng のLARUS One と顧客継続性に関する長いノートは、配信は変わっても公開アイデンティティが壊れるべきではない理由を説明している。クラウド NAT を使用するエンタープライズにとって、同じ論理は調達テストになる。それを運ぶインフラを変更しながら、認識された公開アイデンティティをビジネスが維持できるか？
受容はまた購入者を訓練する。エンタープライズは、自身のレコード、ルーティング衛生、セキュリティアサーション、不正使用連絡可能性、相手先通知を無視しながら独立を要求できない。ホルダー管理は義務を生み出す。薄い調整モデルは責任からの逃避ではない。リソースを運用する当事者に責任を置き、プラットフォーム、キャリア、レジストリを定義されたレビュー可能な役割内に保つ。
実用的な成果物は受容パックである。管理の証明、現在のレコード、ルートとセキュリティ証拠、許可された連絡先、変更履歴、アドレス評判ノート、相手先依存リスト、テスト結果、撤退手順を含む。フォレンジック遠征なしで宛先がアイデンティティを評価できるように、最新に保つべきである。更新前にパックを組み立てられない場合、購入者にはまだ実行可能なオプションがなく、願望しかない。
その区別は交渉力が変わるところである。テストされた宛先、受け入れられたアイデンティティ、マッピングされた相手先移行を持つ顧客に直面するサプライヤーは、真の代替案と競争しなければならない。「ポータブル」というスライドしか持たない顧客に直面するサプライヤーは脅威を割り引くことができる。
受容は外部からもサンプリングされるべきである。宛先プラットフォームは範囲を受け入れるかもしれないが、主要顧客は自身のセキュリティチームが追加の評判チェックを使用するため、変更を拒否するかもしれない。キャリアはルートを運ぶかもしれないが、マネージドセキュリティサプライヤーはポリシーを更新する前に別の証拠を必要とするかもしれない。レジストリレコードは管理を示すかもしれないが、財務相手先は契約上の通知とテスト取引を望むかもしれない。購入者は1つの成功した証明をチェーン全体と混同すべきではない。収益を停止できるすべての関係者がアイデンティティを受け入れるか、テストされた変更パスを割り当てられた場合にのみ、ポータビリティは現実になる。
バンドルは出口シーケンスが消えるまで有用である
クラウドバンドルは統合に価値があるために存在する。マネージド変換ゲートウェイは、顧客がすべての部分を組み立てることなく、ルーティング、ロギング、セキュリティポリシー、スケーリング、サポート、アカウントコントロールと連携できる。すべてのバンドルを罠として扱うのは悪い経済学である。購入者は、調整コストを削減し、難しい操作をうまく行うかもしれないサプライヤーに委託するため、統合サービスを選ぶ。
リスクは、バンドルが出口シーケンスを消滅させるときに現れる。公開アイデンティティはあるサービスを通じてアタッチされ、別のサービスを通じてログされ、アカウントコントロールによって管理され、商業階層を通じてサポートされ、セキュリティ製品によって保護されるかもしれない。契約はこれらを別々のラインとして説明するかもしれないが、移行はそうではない。割引はより広いコミットメントを報いるかもしれない。サポートはより広い支出を維持することに依存するかもしれない。ゲートウェイアドレスは請求書では小さく、出口問題では大きいかもしれない。
これが、クラウドサービス間の価格比較が誤解を招く理由である。より安いゲートウェイは、新しい公開アイデンティティ、新しい相手先承認、弱い証拠、より長い並行稼働を必要とする場合、より安くない。より高価なサプライヤーは、管理されたアイデンティティを受け入れ、ログを保存し、段階的撤退をサポートし、拒否のレビュー可能な理由を与える場合、コストが低いかもしれない。調達は、パケットが通過するコンポーネントの価格だけでなく、ワークロード周りのアイデンティティ移行コストを比較すべきである。
契約条件はバンドルを露出させることができる。購入者は、公開アイデンティティが撤回される前の事前通知、終了後の関連ログへの継続アクセス、顧客管理アイデンティティの段階的導入支援、明確な停止基準、エクスポート可能なセキュリティ証拠、並行運用中の名前付きサポート、提案されたアドレスを拒否する理由を要求できる。また、単一のコミットメントにロールされ、その実用的目的が古い公開エッジを生かし続けることであるサービスを特定できる。
責任は管理に従うべきである。Lu Heng のレジストリ権限と責任に関する議論は番号リソース層のために書かれているが、運用原則は移動する。重要な公開アイデンティティ機能を管理する当事者は、説明不能な中断からの損害を他人の管理上の不便として扱うべきではない。プラットフォーム、エンタープライズ、キャリア、レジストリ、相手先は異なる役割を占める。契約はそれらの役割を見えるようにすべきである。
拒否は特別な注意に値する。宛先は有効な技術的またはセキュリティ上の理由で管理範囲を拒否するかもしれない。それでも購入者がテストできる理由を与えるべきである。「未サポート」は、決定が公開アイデンティティを移動できるかどうかを決定するときには十分ではない。レビュー可能性は裁量を管理されたリスクに変える。それがなければ、購入者は拒否が技術的か、商業的か、または既存事業者のアドレス経済を保護する製品境界かを判断できない。
目標はコストのかからない柔軟性ではない。目標は、購入者が実際のサービス価値と実際の移行サポートに対して支払い、サプライヤーが有用な統合を商業的挑戦を生き残るアイデンティティ管理に静かに変換できない相互運用契約である。
これはまた、調達が割引と依存を区別すべきところである。コミットされた支出割引は、購入者が本当にサプライヤーの統合環境を望む場合に合理的である。購入者が公開エッジを離れられないためにのみ割引が手頃である場合、危険である。更新書類は、どのサービスがパフォーマンスのために保持され、どのサービスが移行証拠が準備できていないために保持され、どのサービスが相手先が移動されている間、外部から認識されたアイデンティティを生かし続けるためだけに保持されているかを述べるべきである。その正直さは、依存を一時的で測定可能な所有されたものにし、ブレンドされた商業的節約の背後に隠れないようにする。
LACNIC はポータブル証明としてのみ重要である
このチェーンにおける LACNIC の役割は薄く、正確で、有用であるべきである。それはクラウドゲートウェイを設計せず、エンタープライズワークロードを運用せず、銀行のファイアウォールを承認せず、どのサプライヤーが契約に値するかを決定しない。その経済的に価値のある機能は、ラテンアメリカ・カリブ地域でユニークな公開番号リソース管理を読みやすくするのに役立つことである。その証明は、プラットフォーム、貸し手、アクワイアラ、相手先の検証コストを削減できる。
役立つレジストリは信頼できる元帳である。競合する主張を防ぎ、正確なホルダーレコードを維持し、連絡可能性をサポートし、関連履歴を保存し、セキュリティ隣接の事実を依存関係者が理解できる形で公開する。宛先プラットフォームが顧客管理のアイデンティティを評価するとき、エンタープライズが管理を示せるかどうか、レコードが首尾一貫しているかどうかを知る必要がある。貸し手が継続性を評価するとき、ビジネスがサプライヤー割り当てのアドレスにのみ依存しているか、認識されたアイデンティティを他の場所に運べるかを知る必要がある。買い手がターゲットを調査するとき、耐久性のあるアイデンティティとアカウントで消えるサービス成果物を区別する必要がある。
有害な拡大は、記録管理が正当な使用に対する許可として扱われるときに始まる。エンタープライズが公開アイデンティティをクラウドプラットフォーム、マネージドプロバイダー、地域キャリア、または自身のネットワークを通じて使用するかどうかは、主に商業的および運用上の決定である。LACNIC の関心事は、ユニークネス、正確性、連絡可能性、関連レコードの整合性である。レジストリ継続性の誤謬はポイントを直接述べている。元帳とその技術機能は継続性を必要とする。ゲートキーパーのより広い権限主張はそれに従わない。
この薄さはホルダーだけでなくプラットフォームにも役立つ。クリアな元帳は、プラットフォームがより低い不確実性で顧客管理のアイデンティティを受け入れることを可能にする。裁量的または曖昧な層は、プラットフォーム自身のプールが消費しやすいため、サプライヤー割り当てのアイデンティティをより魅力的にする。結果は逆説的になる。より多くの管理を行使しようとするレジストリは、意図せずにエンタープライズをプライベートプラットフォームアイデンティティのより深いところに押し込む可能性がある。
実行コード優先からの実行ネットワークテストは正しい境界である。実行中のネットワークは、ユニークネス、正確なレコード、セキュリティ関連の証拠、連絡可能性、転送記録、継続性を必要とする。クラウド移行、買収統合、サプライヤー切り替えが商業的に高潔であるかを判断するために地域機関を必要としない。Lu Heng の番号リソースは政治的な財産ではないおよび厚いガバナンスは二重抽出に変わるに関するノートは、IPv4 が資産グレードのインフラになるとこの区別がより鋭くなる理由を説明している。
実用的な要求はポータブル証明である。ホルダーは管理を示し、運用上の事実を更新し、変更を記録し、関連するセキュリティ状態を維持し、通常の商業的使用を広範な制度的裁量に依存させることなく紛争を分離できるべきである。最小初期仕様、ローカライズされた将来決定、自発的採用の設計原則はこの問題に適合する。共通でなければならないものを調整し、残りはビジネスリスクを負う当事者に委ねる。
クラウド NAT 経済学にとって、それは LACNIC が証明周りの不確実性を低下させるべきであることを意味する。購入者のプラットフォーム選択の別の参加者になるべきではない。
薄い証明役割はまた LACNIC を不可能な期待から保護する。プラットフォームが独自の技術的理由でエンタープライズ管理範囲を拒否した場合、プラットフォームの製品境界について LACNIC を非難すべきではない。購入者が相手先を維持しなかった場合、LACNIC に購入者の調達怠慢を治癒するよう求めるべきではない。レジストリレコードが正確でポータブルであれば、共通層に属する部分を果たした。残りの決定は、取引に契約、ネットワーク、顧客、責任を持つ当事者によって行われるべきである。
NRS はホルダー側の交渉を強化すべきであり、新しいセンターを売るべきではない
この設定における建設的な制度的方向性は、番号資源社会（NRS）を通じたホルダー側の調整であり、その主張も狭くあるべきである。NRS はクラウドプラットフォーム、レジストリの代替、価格設定委員会、アドレスプール、プラットフォーム依存に対する普遍的な答えではない。その価値は、ホルダーがより強い相手先との交渉で証明、ポータビリティ、レビュー、継続性をより使いやすくするのに役立つ場合にのみ存在する。
その役割は実用的である。メンバーは、異なるプラットフォームや仲介者によって要求される証拠を、その演習を製品リストに変えることなく比較できる。繰り返し発生する拒否パターン、不明確な責任条件、証明がポータブルでなかったためにアイデンティティ継続性が失敗したケースを特定できる。ケースアーカイブは、検証された事実を申し立てから分離し、商業的に敏感な情報を保護する場合、孤立した経験を組織的記憶に変えることができる。NRS Shieldなどのツールは、ホルダーにとって継続性とレビューをより執行可能にし、依存の別の層を追加しない場合にのみ重要である。
NRS にはまたアドボカシーとメンバー代表機能がある。レジストリ、プラットフォーム、仲介者が公開アイデンティティの使用を停止、拒否、条件付けることができる場合、ホルダーはルール、必要な証拠、レビュー経路、責任境界を知る必要がある。グローバルプラットフォームと交渉する孤立したエンタープライズ、またはレジストリ側の不確実性に対応するエンタープライズは、裁量に挑戦するための言語と比較証拠を欠くかもしれない。ホルダー組織は、基礎となるビジネスを統治すると主張することなく、その孤立を減らすことができる。
これは販売議論ではない。NRS は、実行可能な出口オプションのコストを低下させるかどうかによって判断されるべきである。より良い証明パック、より明確な受容期待、より強いエスカレーション、より低い重複法務作業、より良い継続性言語、より信頼性のある代替案。それらの効果を示せない場合、アーキテクチャの外に留まるべきである。ポジティブな将来方向は制度的インフレを意味しない。単一ポイントの裁量を決定的でなくすることを意味する。
Lu Heng のNRS が存在する理由に関するノートは、分散化をスローガンではなくシステム問題として位置付けている。それがここでの唯一の有用な読み方である。購入者はクラウドプラットフォームやレジストリの上の新しい権威センターを必要としない。証明を管理し、アイデンティティを保存し、代替案をテストし、強力な相手先がノーと言ったときに理由を受け取る能力を必要とする。
したがって、NRS はネットワーク図の中央ではなく、調達ファイルの端に属する。ホルダーに共有言語と証拠プラクティスを提供できる。どのワークロードが移動すべきか、どのプラットフォームが勝つべきか、どの商業モデルが道徳的に優先されるかを決定すべきではない。エンタープライズは、サービス、顧客、財務結果を負うため、それらの決定を保持する。
その抑制が NRS の役割を信頼できるものにする。すべてのアドレス、クラウド、移行問題を解決することを約束する新しい機関は、それが批判する過剰を単に再現するだろう。証明規律を改善し、裁量のパターンを記録し、レビュー可能性をサポートし、メンバーが受容要件を比較するのを助けるホルダー側の団体は、交渉を所有するふりをせずに交渉のコストを削減できる。プラットフォームとレジストリの両方が多くの個々のホルダーよりも強い市場では、控えめな調整は壮大な言語よりも価値がある。
オプションは更新圧力の前に測定されなければならない
購入者のレバレッジはプロダクション移動の前に変わる。テストされたオプションは、既存事業者が顧客が自身の公開エッジに閉じ込められていないのを見ることができるため、交渉に影響する。テストされていないオプションはそうではない。取締役会を慰めるかもしれないが、更新日が近いときにサプライヤーの行動を変えない。
測定は因果連鎖に従うべきである。まず、どの公開アイデンティティが重要で誰が管理しているかを証明する。次に、それらのアイデンティティとそれらを認識する相手先によってワークロードをグループ化する。第三に、宛先がエンタープライズ管理のアイデンティティを受け入れるか、どの置き換えアイデンティティが必要かをテストする。第四に、ルーティング、アタッチメント、セキュリティ証拠、可観測性を再現する。第五に、重要な相手先の受容またはそれを得るために必要な変更プロセスを確認する。第六に、カットオーバー、オーバーラップ、ロールバックを定義する。順序は重要である。各段階が遅延の異なる理由を除去するからだ。
この測定は、地域オペレーターが新しい需要にデプロイ可能な公開アイデンティティを迅速に一致させて契約を収益に変えなければならない成長圧力の問題とは異なる。ここではエンタープライズはすでにワークロードと外部認識を持っている。その質問は、その認識がクラウド資産の寿命の間にプラットフォーム管理になったかどうかである。コストは新しい顧客の限界アドレスではない。それは、サプライヤーの挑戦、移行、買収を通じて既存のビジネスアイデンティティを運ぶコストである。
測定はまたデュアルスタック請求書とは異なる。問題は、顧客とアプリケーションのために2つの到達可能性システムを生かし続ける年間コストではない。それは、プラットフォーム配信パスを変更しながら認識された公開アイデンティティを保存できるオプション価値である。IPv6 は将来の依存を減らすかもしれない。それだけでは、銀行、顧客、監査人に購入者のタイムテーブルで変更された公開エグレスパスを認識させることはできない。
財務チームは結果を信頼レベルのある範囲として記録すべきである。重要なワークロードグループごとに、アイデンティティを保存、置き換え、または限定的な移行のために既存事業者を保持するのにコストはいくらか？どのコストがエンジニアリング、相手先承認、法務レビュー、セキュリティ証拠、並行運用、顧客通知、商業的譲歩か？どれが一回限りで、どれが出口オプションを新鮮に保たなければならないために繰り返されるか？BTW の相互接続依存と転送価格の透明性に関する作業は、アイデンティティとルーティングがきれいに証拠化されていない場合、隠れた認識コストが交渉コストになる方法を示すため、関連する。
テストは古くなる。相手先は変わる。プラットフォームはサポート境界を変更する。新しいワークロードは古いゲートウェイにアタッチする。2年前にポータビリティをテストした購入者は、もはやライブオプションを持っていないかもしれない。したがって、レジスタは買収が署名されるとき、主要サプライヤー条件が更新されるとき、規制対象顧客がオンボードされるとき、またはセキュリティ証拠が実質的に変更されるときにレビューされるべきである。脅威の下で再構築されるよりも継続的に行うとき、作業は小さい。
結果は不快かもしれない。一部のワークロードは一定期間プラットフォーム依存であることが判明するだろう。それは失敗ではない。情報である。明示的に価格設定された依存は、ゲートウェイ料金の背後に隠れた依存よりも安全である。
エンタープライズ内にはガバナンス上の利点もある。公開アイデンティティがワークロードと出口オプションごとに測定されると、アーキテクチャチームはもはや回復力のために抽象的に議論する必要がない。どの欠けている証拠が更新レバレッジを生み出すかを調達に示し、どの証拠が失われるかをセキュリティに示し、どの譲歩が実際には移行コストであるかを財務に示し、どの相手先が移動を遅らせるかをビジネスオーナーに示すことができる。その共有ビューは内部の非難を減らす。組織はクラウド出口をイデオロギーとして扱うのをやめ、所有者、日付、テストを持つ名前付き依存のセットとして扱い始める。
最終テストは調達、貸し手、主要顧客に属する
最終決定はアーキテクトだけに委ねられるべきではない。彼らはアプリケーションが他の場所で実行できるかどうかを会社に伝えることができる。調達、貸し手、主要顧客は、ビジネスアイデンティティが移動を生き残れるかどうかをテストしなければならない。彼らの質問は異なり、より厳しい。なぜなら、彼らは交渉力、継続性、責任に焦点を当てるからだ。
調達は、サプライヤーがサービス品質のために保持されているのか、購入者が時間内に認識された公開アイデンティティを移動できないために保持されているのかを尋ねるべきである。答えがサービス品質なら、パフォーマンス、セキュリティ、価格で交渉できる。答えが閉じ込められたアイデンティティなら、更新はその事実を開示し、移行サポートを購入し、依存を減らす期限を設定すべきである。自社の価値に自信があるサプライヤーは、購入者の蓄積されたアドレス記憶を保持の隠れた基盤として必要とすべきではない。
貸し手は、サプライヤー関係が悪化した場合、買収が資産を変更した場合、またはプラットフォームアカウントが紛争になった場合に、収益重要なワークロードが顧客にサービスを継続できるかどうかを尋ねる。答えは証拠を指すべきである。管理されたアイデンティティまたはマッピングされた置き換え、宛先受容、ルーティングとセキュリティテスト、相手先移行記録、保持されたログ、割り当てられたオーナー、オーバーラップウィンドウ、ロールバック。システムがクラウドネイティブであるという声明は貸し手の質問に答えない。クラウドネイティブコンピューティングは、現在の代替案を持たないプラットフォーム管理の公開アイデンティティを通じて世界に直面することができる。
主要顧客は、承認された送信元アドレスが変更されるかどうか、セキュリティ帰属が生き残るかどうか、移行がビジネスを中断した場合に誰がリスクを負うかを尋ねる。エンタープライズは事前に二次アイデンティティを交渉し、オーバーラップ期間に同意し、または顧客に配信プラットフォームから独立したエンタープライズ保持範囲を認識するよう説得する必要があるかもしれない。それは単にサプライヤーのレバレッジではない。顧客自身の契約チェーン全体の相関リスクを減らす。
委員会はポータビリティ劇場を拒否すべきである。顧客管理のアドレスに言及する契約は、宛先が範囲を受け入れていない場合弱い。ログをエクスポートする権利は、エクスポートが帰属をサポートできない場合弱い。終了権は、相手先が変更できる前に公開アイデンティティが消える場合弱い。レジストリレコードは、プラットフォームが受容を説明できない裁量として扱う場合弱い。すべての権利はテスト、名前付きオーナー、レビュー日、救済策に対応すべきである。
これは、LACNIC 地域の証明層、プラットフォーム契約、購入者自身の運用規律が出会うところである。LACNIC はホルダー管理をポータブルで読みやすくすべきである。プラットフォームは受容、拒否、証拠、移行サポートをレビュー可能にすべきである。エンタープライズは自身のアイデンティティを信頼できるものにするレコードと相手先を維持すべきである。NRS はホルダーがそれらの期待を比較し防御するのを助けることができるが、購入者のデューデリジェンスを置き換えることはできない。
調達ミーティングの終わりに、ゲートウェイ料金はまだスプレッドシートにあるが、それはもはや決定を枠組みしない。本当の質問は、配信が変わった場合にいくつの収益重要なワークロードが信頼された公開アイデンティティを保存できるか、どの証明がそのオプションを実行可能にするか、古いパスが撤回される前に誰が行動しなければならないか、管理が失敗した場合に誰が損失を負うかである。コンピューティング移動はエンジニアリング能力である。公開アイデンティティ出口は交渉資産である。契約は、調達委員会、貸し手、主要顧客がそれが使用される前にその資産をテストできる場合にのみ健全である。
その最終テストは契約が署名された後に繰り返されるべきである。新しい資産の最初の年は、チームがサービスを追加し、サプライヤーを接続し、顧客を承認し、次の外部記憶の層を作成するときである。すべての新しいワークロードが最も簡単なプラットフォーム管理の公開エッジを継承する場合、購入者は新しいロゴの下で同じ依存を再構築する。重要なワークロードがエントリー時にアイデンティティ結果によって分類される場合、エンタープライズはクラウドサービスが価値がある場所で使用しながら選択肢を生かし続ける。目的は離れることではない。それは、滞在を、サービスメリット、貸し手の信頼、顧客継続性によって防御できる決定にすることであり、ビジネスが知られている公開アイデンティティの静かな管理によってではない。