Cloud Metric Inc.は、ラック、トランジット、修理窓口に依然として依存するホスティング容量を販売

概要

• Cloud Metric Inc.は、マネージドクラウド、マネージド IT、セキュリティのカナダのプロバイダーとして自らを位置付けている。同社のウェブページでは、マネージドクラウドホスティングと移行、バックアップと災害復旧、監視対象インフラ、カナダのサポート、カナダのプライバシー義務に関連するデータローカリゼーションの主張が強調されている。
• 公開されたデジタルリソースの記録は、具体的だが限定的なネットワーク証拠を提供する。ARIN は、AS205663 および直接割り当てられた IPv4 ブロック142.249.190.0/24の登録者として Cloud Metric Inc.を示している。RIPEstat は、2026年7月12日に AS205663 によってこの/24がアナウンスされたことを確認し、そのビューの全326フルフィードピア全体に IPv4 の可視性があり、同じルーティングステータス結果では現在 IPv6 空間はアナウンスされていないことを示した。
• 可視トランジットの状況は薄い。AS205663 の RIPEstat ネイバービューでは、隣接 AS として AS16276 が1つ示され、RIPEstat の概要では OVH SAS と識別されている。PeeringDB は ASN 205663のネットワークプロファイルを返さなかった。これはサービスが脆弱であることを証明するものではないが、サイト数、相互接続ポリシー、トラフィック比率、サイトの多様性が PeeringDB で公に文書化されていないことを意味する。
• Cloud Metric のインフラストラクチャと災害復旧に関する文言は、冗長性の証明としてではなく、検証すべき主張の集合として読まれなければならない。同社は自社のホスティングがカナダにあると述べ、複数のカナダのデータセンター、バックアップ、フェイルオーバー、監視、リストアに言及している。公開情報源は、これらの主張の背後にある正確な施設、ラックの所有権、キャリアの組み合わせ、スペアパーツ計画、またはテスト済みの移行制限を特定していない。
• 証拠レベルは中程度である。同社によって登録されたライブネットワークのフットプリントと、相当な一次情報によるサービス文書が存在するが、現在の公開フットプリントは小さく、冗長性の表面は大部分が開示されていない。顧客は、このサービスを回復力のある能力と見なす前に、マルチサイトアーキテクチャ、アップストリームの独立性、サポートエスカレーション、クレジット制限、データポータビリティ条件を検証する必要がある。

公開上の存在は本物だが、クラウドには常に物理的な基盤がある

Cloud Metric Inc.に関して最も有益な点は、公開証拠がマーケティングページで止まっていないことだ。同社はcloudmetric.caに公開サイトを持ち、マネージドクラウドホスティングと移行のマネージドクラウドオファリング、安全なインフラストラクチャソリューションのページ、サポートのページ、そしてサポート、クレジット、停止、制限について説明する法的条件を備えている。また、デジタルリソース記録にも登場している。AS205663 の ARIN RDAP レコードは Cloud Metric Inc.を指名し、142.249.190.0の ARIN RDAP レコードは同じ組織の下で直接割り当てられた/24ネットワークを示している。

これは単なるディレクトリのラベルよりも強固な出発点である。購入者に、名前、アドレスリソース、サービス主張、サポート面、契約文言を提供する。また、より正確なテストを提起する。Cloud Metric がマネージドホスティング容量を販売しているのであれば、顧客は単にブランドを購入しているのではない。顧客は、クライアントアプリケーションからハイパーバイザーやサーバーへ、そのマシンからストレージ層へ、ストレージからバックアップへ、バックアップからリストアターゲットへ、ラックから電源へ、施設からトランジットへ、そしてサポートデスクから障害を修復できる誰かへと至る一連の信頼性を購入しているのである。

「クラウド」という言葉はこの連鎖を曖昧にしがちだ。容量が伸縮自在で場所に依存しないという印象を与える。Cloud Metric の提案はそれよりも物理的だ。同社のインフラストラクチャページは、ホスティング環境、バックアップ、アンチマルウェア、サイバー保護、災害復旧サービス向けのクラウドネットワークインフラを説明している。カナダの地域性に関する表現は、カナダでのホスティング、接続性、サポートを説明している。法的条件は、CMI ネットワーク、計画メンテナンスウィンドウ、アップストリームプロバイダー、顧客側機器、CMI ネットワーク外のサービスに言及している。これらは抽象的なフレーズではない。ラック、キャリア、契約、サポートシステム、チケット、人々を指し示している。

したがって、本稿では Cloud Metric をハイパースケールクラウドとも幽霊プロバイダーとも扱わない。これは、可視的だが控えめなルーティングフットプリントと、マネージドクラウドに関する広範な文言を持つ、カナダのマネージドサービス企業である。実際的な問題は、運用境界がどこにあるかだ。どの部分が Cloud Metric 自身のネットワークに属するのか？どの部分が、借りたデータセンタースペース、アップストリームプロバイダー、バックアップソフトウェア、サードパーティのサポートサービス、または顧客側機器に依存しているのか？どの部分がクレジットでカバーされるのか？どの部分がベストエフォートでしかカバーされないのか？購入者はサービスを利用するためにすべてのプライベートな詳細を必要としないが、何が同時に故障するかを知るために十分な境界線を必要とする。

Cloud Metric のサービス内容は、経路広報されている /24 よりも広い

Cloud Metric の公開サイトは、単なるウェブホスティング以上のものを説明している。トップページは、安全なデータソリューション、マネージドサイバーセキュリティ、マネージド IT、マネージドクラウドサービスを中心に据えている。マネージドクラウドのページでは、Cloud Metric がクラウド環境を管理することで、ビジネスチームが日々の運営に集中できるとしている。その周辺のメニュー構造には、マネージドクラウドホスティングと移行、マネージドクラウドセキュリティ、バックアップと災害復旧、アプリケーションデプロイメント、データベース管理が並ぶ。サポートページはチケット発行経路と電話番号を提供する。インフラストラクチャページは、サービス説明をプライベートで安全なカナダのホスティングに結びつける。

この広がりは重要だ。マネージドクラウドプロバイダーは、アンマネージドの仮想サーバー販売業者よりも多様な形で失敗しうるからだ。仮想サーバーの顧客は主に、計算、ストレージ、ネットワーク到達性、認証情報、課金継続性を必要とする。一方、マネージドサービスを利用する顧客は多くの場合、監視、変更管理、パッチ適用、セキュリティ管理、バックアップ構成、サポートトリアージ、リストア実行に依存する。プロバイダーはサーバーを到達可能に保ちつつ、契約のマネージド部分で失敗することもありうる。また、サポートデスクを開いたままでも、サービスを迅速に復旧するためのハードウェア、アクセス、アップストリーム容量を欠くこともありうる。

Cloud Metric 自身の資料もこの広い見方を促す。バックアップとディザスタリカバリのページでは、重要なビジネスデータを保護し、必要に応じて復旧できるとしている。インフラストラクチャページは、自動バックアップ、組み込みのフェイルオーバーとリカバリ、リソースおよびアプリケーション監視、ソフトウェアまたはサービスのリストア、強化された暗号化に言及する。マネージドクラウドセキュリティのページは、セキュリティとコンプライアンスをクラウドプロバイダー選択の問題の一部として位置づける。これらは価値の高い約束である。同時に、その実際の強さは一般にルーティングテーブルには見えない能力に依存する約束でもある。

インフラの購入者にとって、「提供されている」と「運用上証明されている」の違いは極めて重要だ。提供されているとは、ベンダーにサービスのページ、販売プロセス、そしておそらく提供アプローチがあることを意味する。運用上証明されているとは、購入者が配置、依存関係、復旧、サポートの証拠を見たことを意味する。ワークロードがどこにあるか、コピーがどこにあるか、トラフィックがどう出入りするか、誰がハードウェアを操作できるか、リストア目標がどの程度か、優先アップストリームプロバイダーが停止した時に何が起きるか、顧客がシステム設計やタイミングによって閉じ込められることなくどう離脱するか、といったことだ。Cloud Metric の公開上の存在感は前者を支える。後者を開始するが、完了はしない。

これは珍しいギャップではない。小規模な地域クラウドプロバイダーは、ビジネス上およびセキュリティ上の理由から、施設名、キャリアの詳細、プライベート顧客のアーキテクチャを公開しないことが多い。こうした詳細が公開されていないことは、不十分なエンジニアリングを証明するものではない。それは、顧客がマーケティング文言をエンジニアリングレビューの代用とすべきでないことを意味する。Cloud Metric が本番ワークロードの責任当事者であるならば、購入者は、ラック障害、アップストリームの混乱、バックアップ失敗、サポートの滞留、契約紛争にサービスがどう耐えるかを理解するために、十分な非公開証拠を入手すべきである。

AS205663 によって同社は測定可能なネットワークとなるが、限界もある

最も明確な公開ネットワーク証拠は AS205663 である。AS205663 の ARIN RDAP レコードは、CLOUD-METRIC という名称と Cloud Metric Inc. を登録組織として記載している。CM-1729の ARIN 組織ビューは、同じ組織を AS205663 および IPv4 ネットワーク 142.249.190.0/24 に結びつけている。これは重要だ。なぜなら、Cloud Metric を単なるウェブ上の存在から、登録されたデジタルリソースを持つ企業へと引き上げるからである。

現在のルーティングの視野は小さいままだ。AS205663 の RIPEstat アナウンスプレフィックスは、2026年6月28日から2026年7月12日までの観測期間において、現在のプレフィックスとして 142.249.190.0/24 が1つ示された。RIPEstat ルーティングステータスは、1つの IPv4 プレフィックスと256個の IPv4 アドレスがアナウンスされ、現在のところ IPv6 空間はアナウンスされていないと報告した。同じルーティングステータスビューでは、最後に観測された経路が 142.249.190.0/24 （2026-07-12T00:00:00）であり、このサンプル内ではそのフルフィードピア全体に完全な IPv4 可視性があったことを示している。

これで、ネットワークが公開 BGP 上で稼働していると言うには十分だ。ネットワークが大規模で、マルチサイトで、マルチキャリアで、あらゆるホストされたワークロードに対応可能だと言うには不十分だ。単一の /24 は、大量の顧客トラフィック、管理機能、エッジサービス、テストシステム、または小規模なホスティングファームを提供できる。また、他の場所でプロバイダーアドレス空間を使用する、より大規模なアーキテクチャの可視的なエッジに過ぎない可能性もある。公開ルーティングは、プライベートアドレッシング、プライベートインターコネクト、ストレージレプリケーション、顧客固有の仮想ネットワークを見ることはできない。グローバルインターネットから見えるものを教えてくれるが、エッジの背後にあるすべてのマシンを教えてくれるわけではない。

したがって、可視フットプリントのサイズは、答えを出すものではなく、質問を形作るべきだ。顧客が小規模なホスト環境を購入するのであれば、/24 で全く十分かもしれない。重要なホスティング、マルチテナントバックアップ、災害復旧、またはデータ主権のあるインフラを購入するのであれば、現在の単一の公開 /24 は、容量計画をデューデリジェンスの項目とする。顧客ワークロードに割り当てられるパブリックアドレスはいくつか？顧客は Cloud Metric が所有する IP 空間、アップストリームの空間、または NAT やロードバランサの背後にあるプライベート空間のいずれにいるのか？災害復旧サイトはそれ自体のルーティング可能な容量を持っているか？プライマリサイトがダウンした場合、Cloud Metric は別の場所からプレフィックスをアナウンスできるか？これらが、デジタルリソースレコードを運用知識に変える問いである。

アップストリームの兆候は限定的: OVH が現れるが、多様性は見えない

トランジットの多様性は、図面上のキャリア数だけではない。障害後に必要なトラフィックを運べる真に独立した経路の数である。AS205663 の RIPEstat ASN ネイバービューは、利用可能な最新サンプルで1つの隣接 AS を観測した: AS16276。AS16276 の RIPEstat 概要は、この ASN を OVH SAS と識別している。この公開された隣接関係は有用だ。なぜなら、可視的な BGP 経路が孤立して存在しているわけではないことを示すからだ。また、現在の公開ビューが幅広いアップストリームの混合を示していないことも示している。

この注意点は重要だ。ルートコレクタのネイバービューは契約書ではない。OVH が Cloud Metric の全サービスの背後にある唯一の商業的依存関係であることを証明するものではない。サンプルで可視的でなかったバックアップトランジット、非公開ルーティング、プライベートリンク、または他のアドレスで運ばれるトラフィックを明らかにするものではない。物理的なシングルホーミングを証明するものでもない。しかし、公開のレジリエンスプロファイルにとって、可視的な隣接が1つというのは薄いシグナルだ。Cloud Metric がバックグラウンドで多様な物理サイトや複数のプロバイダーを持っているならば、顧客が必要とする証拠は公開のネイバービューにはない。

ASN 205663 の PeeringDB ネットワークプロファイルが見つからないことも、この不確実性を増す。PeeringDB は必須のレジストリではなく、多くの正当なネットワークがプロファイルを管理していない。それでも、プロファイルが存在すれば、購入者に施設、IX プレゼンス、ピアリングポリシー、トラフィック規模の簡易なビューを提供することが多い。Cloud Metric の場合、PeeringDB はプロファイルを返さなかった。このディレクトリには、施設リスト、IX ファブリックの証拠、自己公表の相互接続ポリシーは存在しないということになる。

だからこそ、トランジットの問いは二度問われるべきだ。まず、ルーティングの問い: 観測されたアップストリームプロバイダーの損失後も、プレフィックスまたは顧客トラフィックは存続できるか？次に、物理的な問い: 残りの経路は、別個のルーター、電源、クロスコネクト、接続部屋、ファイバー入口を経由するか？2つの BGP セッションが、同じ施設依存性に依拠しているならば同時に落ちる可能性がある。高品質なアップストリームプロバイダー1つは、非クリティカルなワークロードには許容できるかもしれない。クリティカルなワークロードは、テスト済みの代替経路と、アップストリームプロバイダー、ローカルループ、またはサードパーティネットワークが落ちた場合に何がサービスに含まれるかについての書面での説明を要求すべきだ。

「カナダでホスティング」は設置場所の主張であり、魔法の盾ではない

Cloud Metric はカナダの地域性に強く賭けている。インフラストラクチャページは、同社がカナダで所有・運営するクラウドホスティングソリューションを提供し、カナダ全土の複数のデータセンターに言及し、組織と顧客のデータはカナダの土に留まるとしている。フッターには「100%カナダ産、準拠」と繰り返される。サポートページのナビゲーションテキストは、ホスティング、接続性、サポートのすべてがカナダにあると述べている。プライバシーポリシーは、カナダのプライバシー原則をカナダの個人情報に適用するとし、アクセスと訂正の請求のためにオンタリオ州キングストンの住所を挙げている。

この文言は、特に医療、公共部門に隣接する業務、規制対象サービス、または厳格なローカリゼーションルールを持つ組織の購入者にとって関連性が高い。スローガンに矮小化されるべきではない。データローカリゼーションには少なくとも6つの層がある: 一次処理、一次ストレージ、バックアップストレージ、ログ、サポートチケット、管理アクセス、法的支配である。あるサービスは、本番ファイルをカナダに保持しながら、監視やサポートに非カナダのプラットフォームを使うかもしれない。バックアップをカナダに保持しながら、外国のサポートプロバイダーがチケットを処理できるようにするかもしれない。カナダのデータルームを使いながら、外国所有のアップストリームプロバイダー経由でトラフィックをルーティングするかもしれない。これらの事実はいずれも自動的に契約違反とはならないが、それぞれが購入者のリスク見解にとって重要になりうる。

公開されている法的およびプライバシーの証拠は、この区別がなぜ重要かを示している。Cloud Metric のプライバシーポリシーは、個人情報が技術サポートのために代行するサードパーティサービスプロバイダーに転送される可能性があり、その一部はカナダ国外に所在する可能性があると述べている。また、外国の法的要件がこれらの組織に適用される可能性があるとも述べている。これはサービスプロバイダーとして通常の率直な文言だが、「カナダ」という広範な主張の意味を狭める。データセンターはカナダにあっても、すべてのサポート担当者や処理がカナダにあるとは限らない。

法的文脈も顧客によって変わる。カナダプライバシーコミッショナー事務局のPIPEDA の概要は、PIPEDA が商業活動の過程で個人情報を収集、使用、または開示する場合、カナダ全土の民間部門組織に適用されると説明している。連邦法の現行テキストは、PIPEDAで司法法サイトを通じて入手可能だ。オンタリオ州の医療購入者は、PHIPA の義務も気にするかもしれない。オンタリオ州情報プライバシーコミッショナーは、小規模医療機関向けプライバシー管理マニュアルなどの資料を公表している。Cloud Metric は配置とサポートの地域性に対処する手助けができるが、顧客は依然として、自身の法的義務に照らしてサービスをマッピングする責任を負う。

実務上の要求は単純だ: 配置マトリックスを求めよ。本番システムがどこで動作するか、バックアップがどこにあるか、ログとチケットがどこにあるか、どのベンダーが環境にアクセスできるか、どのサポート作業がカナダで行われるか、フェイルオーバー時に何が起こるかを示すべきだ。ワークロードがすべてのコピーとすべてのサポートアクセスをカナダに留める必要がある場合、顧客はそれをフッターから推測すべきではない。それは発注書またはアーキテクチャの説明に明記されるべきである。

サポート条件は約束と限界の両方を示している

Cloud Metric のサポートポリシーとサービスレベルコミットメントは、このプロファイルにとって最も重要な公開文書の一つだ。なぜなら、同社が何を測定する用意があり、何を除外するかを顧客に伝えるからである。これは、単一の顧客回線に固有ではなく、CMI ネットワーク全体で99.999%の CMI ネットワーク可用性コミットメントを示している。可用性を、全測定期間中にネットワークが情報を受け入れ配送できる時間の比率と定義している。また、クレジット、応答、修復、スループット、および多数の除外事項についても説明している。

除外事項は脚注ではない。それらはサービス作業の境界線だ。Cloud Metric またはそのベンダーによる計画メンテナンスは、ネットワークダウンタイムから除外される。顧客側システム、サードパーティシステム、ローカルループ、アップストリームプロバイダー、バックアップまたは代替経路の障害、Cloud Metric の合理的制御を超える状況は、サポートポリシーの除外カテゴリに現れる。マネージドサービスは遠隔サポートとコンサルテーションと表現され、オンサイトでの修復、交換、トラブルシューティングは該当セクションでは顧客の責任とされている。

これにより、サポートポリシーは貴重なレジリエンスマップとなる。ベンダーがアップストリーム、ローカルループ、顧客側コンポーネントが除外されると言うならば、購入者は望ましいアーキテクチャのどの部分がこれらのカテゴリに該当するかを特定すべきだ。ホスト型サービスはユーザー視点では単一のまとまりに見えるかもしれないが、サポートポリシーは責任をプロバイダー、顧客、ベンダー、アップストリームに分割しうる。インシデント発生時、この分割が誰がどのチケットを開くか、誰が待つか、誰が支払うか、誰がレビュー後にクレジットのみを受け取るかを決定する。

クレジットの構造も注目に値する。サポートポリシーは、特定の検証された障害に対して15%のサービス信用の救済策を説明し、クレジット請求にはタイミング、検証、良好なアカウント状態の条件があると述べている。また、クレジットが該当するコミットメント違反に対する唯一かつ排他的な救済策であるとも述べている。これは通信・ホスティング契約では一般的だ。事業継続性と同じではない。クレジットは請求の一部を相殺できるが、裁判所への提出期限の遅れ、クリニックの一日の損失、失敗した顧客ローンチを取り戻すことはできない。

Cloud Metric の購入者にとって、正しい問いはサポート条件が異常かどうかではない。正しい問いは、同社がそれらを前提に設計しているかどうかだ。アプリケーションが計画メンテナンスウィンドウ、顧客側障害、ローカルループ問題、上流プロバイダーイベントを許容できないならば、顧客は別個のアーキテクチャと別個の契約上の対話を必要とする。サービスコミットメントは定義されたネットワーク指標をカバーする。それによって顧客の企業内部のあらゆる依存関係が耐障害性を持つわけではない。

災害復旧の文言は、復旧目標と予備容量に結び付けられなければならない

Cloud Metric のバックアップと災害復旧のページは、顧客がマネージドプロバイダーを利用する主な理由の一つ、すなわち自力で復旧環境を設計する負担を避けることを語るため、運用上重要である。バックアップとディザスタリカバリのページは、Cloud Metric が必要な時に必要な場所で重要なデータを保護・復旧する手助けをすると述べている。インフラストラクチャページは、システムがファイル、構成、アプリケーション、またはシステム全体を、異なるハードウェアやプライベートクラウドを含む別のマシンに数分で復元できると述べている。また、ハイブリッドバックアップオプションや監視されたシステムヘルスにも言及している。

これらは価値の高い能力だが、いくつかの容量問題を隠しうる。復元は保存されたコピーだけではない。十分な CPU、メモリ、ストレージ、ネットワークアドレッシング、ファイアウォール設定、アイデンティティアクセス、管理上の注意を備えた復元ターゲットを必要とする。多数の顧客が同時に復元を必要とする場合、制限要因はバックアップファイルではないかもしれない。利用可能なハードウェア、利用可能な仮想化容量、ネットワーク帯域幅、サポート人員、またはライセンス制約かもしれない。顧客が自前の施設に復元しなければならない場合、制限要因は顧客のローカル機器とアクセスリンクかもしれない。

公開ページは、Cloud Metric の復旧プールの規模、使用される正確な施設、サイト間のレプリケーション距離、ストレージ分離の種類、または最大同時復元負荷を特定していない。また、サービス階層ごとの標準復旧時間目標や復旧ポイント目標の数値も公表していない。これはこれらの数値が存在しないことを意味するのではなく、顧客が約束に依存する前に収集されるべきことを意味する。

最良のテストは具体的なものだ。代表的なワークロードを選び、そのデータサイズ、依存関係、期限を定義した上で、Cloud Metric に復旧経路を示すよう依頼する。最新のコピーはどこにあるか？どこに復元されるか？前回のテストはどれくらいの時間がかかったか？フェイルオーバー後に使われるアドレス範囲は？どのユーザーが新しい認証情報を必要とするか？データが無傷であることを証明するログは？手動作業が完了するまで利用できない機能は？最初に対応しなければならないベンダーは？復旧の主張は、サービスのページ上のフレーズではなく、測定された演習にマッピングされた時に信頼できるものとなる。

設置容量と使用可能容量は同じではない

可視的なネットワークフットプリントは、現在の /24 である。これは、現在の RIPEstat アナウンスプレフィックスビューで見られる設置済みパブリックアドレス容量である。使用可能容量はより難しい問いだ。これらのアドレスのうち、いくつが顧客ワークロードに割り当てられているか？いくつがルーター、ファイアウォール、管理、NAT、監視、ロードバランサー、将来の使用のために予約されているか？経路の背後にどれだけの帯域幅があるか？性能が許容閾値を下回る前に、実際にどれだけの計算・ストレージ容量が割り当て可能か？公開文書はこれらの問いに答えない。

この区別は、ホスティングの経済学の核心である。地域プロバイダーは、需要パターンが異なる顧客間でハードウェア、ネットワークコミットメント、サポート時間を共用することで、良好なサービスを提供できる。この共用こそがマネージドクラウドを経済的にするものだ。また、共用容量のショックを危険にするものだ。複数の顧客が同時に拡張、移行、または復元を必要とする場合、プールがボトルネックになりうる。平均的な日には完璧に健全なプロバイダーが、障害の日には使用可能容量を使い果たす可能性がある。

Cloud Metric のサービスのページは、明示的に運用上の解放を売り込んでいる。顧客はよりハンズオフのアプローチを採用でき、プロバイダーがシステムを監視・保護し、プロバイダーが重要なインフラタスクを処理する。この解放は、顧客がもはやすべての層を自力で人員配置する必要がないため、価値がある。しかし、解放は依存を移転する。顧客はもはや同じハードウェアチームを必要としないが、今や Cloud Metric の在庫、データセンターアクセス、ベンダーリレーションシップ、サポートの層の厚さへの信頼を必要とする。

設置対使用可能の区別は、ライブ BGP プレフィックスを過大解釈すべきでない理由でもある。公開 BGP は 142.249.190.0/24 が到達可能であることを示せる。その背後にあるサービスが予備のハイパーバイザ容量、適切なタイプのストレージ、ルーティング可能な復旧アドレス、移行システム、エンジニアリング時間を持っているかは示せない。小規模な可視フットプリントは、小規模なファームには十分かもしれない。顧客が広範で伸縮自在なプラットフォームを期待するならば、早期警告にもなりうる。購入者は、クラウドという言葉が生む印象ではなく、測定された容量に発注書を一致させるべきだ。

公開ウェブサイトの Cloudflare はホスティングネットワークの証拠ではない

小さな手がかりをサービス自体から分離する価値がある: cloudmetric.ca の DNS ルックアップは、このキャプチャでは Cloudflare のアドレスを返した。これは、公開マーケティングサイトがウェブ保護またはコンテンツ配信のレイヤーの背後にある可能性を意味する。顧客のホスティングワークロードが Cloudflare を利用していることを証明するものではない。Cloud Metric の AS205663 が顧客へのサービス提供に含まれているかいないかを証明するものでもない。単に、公開サイトのアドレスをサービスネットワークの地図として使うことに警鐘を鳴らすものだ。

この区別は、あらゆるマネージドプロバイダーにとって重要だ。プロバイダーのウェブサイト、チケットポータル、課金サイト、リモート管理システム、顧客ワークロードはすべて異なるネットワークを使う可能性がある。マーケティングサイトは、別の場所に置かれていれば、ホスティング障害の間も到達可能なままかもしれない。サポートサイトは、顧客ワークロードが稼働し続ける間ダウンするかもしれない。プロバイダーの公開ページが正常に見える間に、顧客ワークロードが失敗するかもしれない。公開サイトがフロンティングサービスを使う場合、ウェブサイトはブランドの到達性を証明するが、ホスティングアーキテクチャを証明するものではない。

Cloud Metric にとって、企業が管理する公開ネットワークの直接的な証拠は、AS205663 と 142.249.190.0/24 に関する ARIN と RIPEstat の証拠である。公開サイトの証拠は、製品、サポート、法的条件を説明する。これらの二つの証拠の流れは分けておくべきだ。購入者は、cloudmetric.ca の背後にあるウェブサーバーが顧客データのある場所と同じだと想定すべきではないし、すべての顧客データが AS205663 の背後にあるとも想定すべきではない。両方とも誤りかもしれない。

実務上の問いは、運用システムが停止中に機能するために十分に帯域外にあるかどうかだ。インシデントが Cloud Metric の主要顧客環境に影響する場合、顧客は依然としてチケットを発行できるか？Cloud Metric は依然としてその管理プレーンに到達できるか？障害の影響を受けたサービスから独立したネットワークからステータス更新を公開できるか？課金、アイデンティティ、サポートシステムが損傷した場合に復元リクエストを処理できるか？支援への経路は、アプリケーションへの経路と同じくらい重要かもしれない。

所有権、運用境界、ベンダー集中

Cloud Metric のインフラストラクチャページは、同社がカナダで所有・運営されていると述べている。ARIN レコードは Cloud Metric Inc. をオンタリオ州キングストンに置き、関連する ASN とネットワーク割り当てに同社を指名している。これにより、カナダの企業とデジタルリソースの公開リンクが確立される。それ自体は、サービスの背後にあるデータセンターオペレーター、ラックスペースの賃貸条件、上流契約、バックアップソフトウェアベンダー、施設保守の当事者を特定するものではない。

すべてのホスト容量プロバイダーにはベンダー依存関係がある。クラウドサービスは、電力と冷却をあるビル運営者に、トランジットを別の会社に、バックアップソフトウェアをさらに別の会社に、リモートハンズを別の会社に、支払い処理を別の会社に、セキュリティサービスをさらに別の会社に依存するかもしれない。ベンダー集中はそれ自体悪いことではない。顧客がどのベンダーが単一障害点であり、どれがテスト済みの代替によって支えられているかを可視化できない場合に危険になる。

RIPEstat のネイバービューは、一つのベンダー問いを不可避にする: 現在可視的な経路について、OVH はどのような役割を果たしているのか？サンプル中に可視的な隣接 AS が AS16276 だけならば、購入者は、本番トラフィック用の他の上流が存在するか、それらはアクティブかスタンバイか、それらは分離された施設にあるか、顧客トラフィックは再ナンバリングや大規模な手動作業なしに移動できるかを尋ねるべきだ。その答えが、OVH が可視的な公開エッジの主要上流であるというものならば、それでも受け入れ可能かもしれない。それは単に既知の依存関係であるべきだ。

施設の問いも同様に重要だ。Cloud Metric は、カナダ全土の複数のデータセンターがホスティングのストーリーの一部であると述べている。顧客は、実際にどのサービスがマルチサイトなのかを尋ねるべきだ。プロバイダーは複数のデータセンターにアクセスできる一方で、特定の顧客展開は単一のデータセンターで動作しているかもしれない。バックアップは第二のサイトにある一方で、本番サービスは自動フェイルオーバーがないかもしれない。ホットスタンバイはプレミアムなサービス階層には存在するが、別の階層にはないかもしれない。「複数のデータセンター」というフレーズは、顧客が自分のワークロードがそれらの間で配置、複製、ルーティング可能かどうかを知った後で初めて有用になる。

請求、停止、退出リスクはインフラリスクの一部である

インフラストラクチャの障害は、常にハードウェア故障とは限らない。それは、請求保留、アカウント紛争、切れた契約、サポートされない移行経路、またはワークロードに対して短すぎるデータエクスポートの期間かもしれない。したがって、Cloud Metric のクライアントサービス契約は、ネットワークレコードと同じくらい関連性がある。契約は、サービス、支払い、修正、責任制限、機密保持、管轄、不可抗力を規定している。また、契約はオンタリオ州法とカナダ法により準拠し、オンタリオ州の裁判所を裁判地とすると述べている。

公開契約は、よくあるマネージドサービスのリスク配分を用いている。保証の否認、責任制限、補償文言、不可抗力文言、発注書への依存を含む。顧客の視点から、重要なポイントは後で驚かないことだ。顧客の事業が Cloud Metric に依存するならば、契約は、請求が争われた時に何が起きるか、顧客が緊急移行支援を必要とする時に、サービスが終了する時に、顧客データが返却される必要がある時に、第三者ベンダーが停止の原因である時に、何が起きるかを明記すべきである。

クラウドサービスは退出摩擦を生み出す。顧客はファイルをコピーできるが、ファイアウォールルール、スナップショット、監視履歴、仮想マシンイメージ、アイデンティティ設定、DNS 状態、バックアップ保持、アプリケーション依存関係を容易に再現できないかもしれない。マネージドプロバイダーは、これらの部品がどのようにはまり合うかを顧客よりもよく知っているかもしれない。これは通常運用では便利であり、退出時にはリスクだ。Cloud Metric が顧客のために管理すればするほど、顧客は移行経路を文書化すべきである。

ここで「データポータビリティ」が、調達スローガンではなく、レジリエンスの話題になる。顧客は、エクスポート形式、見積エクスポート時間、帯域幅制限、コスト、サポートキュー、終了後の保持期間、サービスが低下している期間中にエクスポートが可能かどうかを知るべきだ。顧客が第二のプロバイダーを待機させたいならば、実際の移行をテストすべきであり、移行がサポートされているという声明を受け取るだけでは不十分だ。ホスト容量のプロバイダーは、顧客がきれいに離れられ、したがってサービスの質のために留まることを選ぶときに最も強力であり、ロックインのためではない。

セキュリティとコンプライアンスの主張には技術的証拠が必要

Cloud Metric のマネージドクラウドセキュリティのページは、当然ながら、クラウドプロバイダーを選ぶ際にセキュリティとコンプライアンスが重要であると述べている。インフラストラクチャページは、監視されたシステムの健全性とセキュリティ、バックアップ、フェイルオーバー、暗号化、カナダ連邦および州のプライバシー法への準拠に言及している。プライバシーポリシーは、その保管または管理下にある個人情報の機密性に適した物理的、電子的、または手続き上のセキュリティ対策を用いると述べている。

これらは方向性としてポジティブな主張である。同時に、サービス固有の証拠も必要とする。暗号化は、ディスク暗号化、バックアップ暗号化、転送暗号化、顧客管理鍵、プロバイダー管理鍵、またはアプリケーションレベルの暗号化を意味しうる。監視は、インフラ健全性チェック、セキュリティアラート、エンドポイント検出、バックアップ成功チェック、またはチケットレビューを意味しうる。コンプライアンスは、法律との整合、プライベートな運用慣行、顧客固有の管理策、または第三者保証を意味しうる。公開ページは、各ホスト型サービスに対して管理策のマトリックスを公表していない。

したがって、顧客はセキュリティの姿勢とセキュリティの証拠を分離すべきだ。姿勢は、プロバイダーが実施すると言っていることだ。証拠は、アクセス制御、ログ記録、バックアップレポート、脆弱性管理、インシデント通知条件、復元テスト、職員アクセスルール、ネットワークセグメンテーション、物理アクセス制御、ベンダーアグリーメントなど、検査可能なものである。機密性の高いワークロードに対しては、顧客は第三者保証報告書も必要とするかもしれないが、公開ページにはサービスの組織向けの SOC 図表が表示されているだけで、ここでレビューした資料の中では報告書は利用可能にされていない。

セキュリティの会話はルーティングにも戻る。RPKI による経路起点検証は、公開されたルーティングセキュリティ管理策である。142.249.190.0/24 と AS205663 の RIPEstat RPKI 検証ビューは、ここでのキャプチャでは、リストされたバリデーション ROA がない未知のステータスを返した。これはサービスが安全でないことを意味しない。この結果では、経路起点制御の公開シグナルが有効として可視的でなかったことを意味する。経路起点検証はあくまで一つの層に過ぎないが、公開インターネットサービスにとっては、有用な衛生上の問いである。

非公式な市場シグナルは可視性を示すが、性能を示すものではない

公開ルーティングアグリゲーターは有用なクロスリファレンスを提供するが、証拠というよりシグナルである。AS205663 の BGP.tools、AS205663 の Hurricane Electric BGP ツールキット、IPinfo の ASN ビュー、Cloudflare Radar のルーティングビューといったページは、Cloud Metric の自サイト以外から ASN がどのように見られているかを確認するのに役立つ。プロバイダーやタイミングによって、経路の可視性、プレフィックス、レジストリラベル、隣接経路を示すことができる。

これらの情報源は、単一のビューへの依存を減らすため貴重だ。ARIN、RIPEstat、複数の BGP アグリゲーターがすべて同じ方向を指し示せば、アイデンティティと現在のルーティング像はより信頼性を増す。また、経路が消えたり、プレフィックスが変わったり、公開情報源間で ASN の説明が異なる場合にそれを明らかにするのにも役立つ。小規模なプロバイダーにとって、この外部からの可視性は、もっともらしいネットワークと検証不能な名称との違いとなりうる。

しかし、これらの情報源は顧客のパフォーマンスを証明できない。特定の仮想マシンがオーバーサブスクライブされているか、バックアップ負荷時にストレージレイテンシが急上昇するか、サポートが故障したディスクを迅速に交換できるか、顧客固有のファイアウォールルールが誤っているかは分からない。また、Cloud Metric のウェブサイト上のすべてのサービスが AS205663 から提供されていることも証明できない。公開経路はインターネット向けの境界に関するシグナルであり、完全なプラットフォーム図ではない。

したがって、非公式な市場シグナルの正しい使い方は規律を伴う。ネットワークが存在することを確認するために使用し、プレフィックス数を観測し、アップストリームの変化を監視し、公開異常を検出する。これらを、契約上およびアーキテクチャ上の証拠なしに規制対象のホスティングワークロードを承認するために使用してはならない。公開アグリゲーターが ARIN や RIPEstat と矛盾するならば、調査する。すべての公開ビューが安定しているならば、それでも Cloud Metric にサービス固有の配置、冗長性、サポートの事実を尋ねるべきだ。

何が故障し、誰が最初に影響を受けるか

Cloud Metric の顧客にとっての主な故障経路は、劇的なイベントではない。マネージドプロバイダーが吸収するはずの日常的なインフラ障害の連鎖である。ラックが電力を失う、ルーターが故障する、上流経路が劣化する、ストレージレプリケーションが遅延する、バックアップジョブが静かに壊れる、サポートキューが過負荷になる、課金問題がアクションをブロックする、または移行が約束よりも長くかかる。それぞれの経路は、異なる集団に最初に影響を与える。

可視的な上流経路が故障し、アクティブな代替手段がない場合、インターネット向きの顧客が到達性の喪失を感じる。施設やラックが故障すれば、ホスト型ワークロードは停止するか復旧に入るかもしれない。ストレージやバックアップが故障すれば、当面のサービスは継続する一方で、顧客の復旧態勢は静かに悪化するかもしれない。サポートが遅ければ、小さな技術的問題が長期の運用停止になる。課金や契約の状態がサービス変更をブロックすれば、技術プラットフォームが利用可能でも顧客は問題を解決できないかもしれない。

Cloud Metric 自身の条件は、この層状の現実を示している。サポートポリシーは、計画メンテナンス、顧客側機器、サードパーティネットワーク、上流プロバイダーを含むいくつかのカテゴリを特定の指標から除外する。顧客契約は、施設の損害や第三者の行為を含む、合理的制御を超える事項に関する不可抗力の文言を含む。これらの条件は通常だが、顧客の実際のエクスポージャーが Cloud Metric の直接制御の外にある依存関係を含むことを明らかにする。

影響を受ける当事者も層をなす。エンドユーザーはウェブサイトやアプリケーションのダウンタイムを感じる。スタッフはファイル、システム、認証、電話サービスの喪失を感じる。コンプライアンス担当者はデータとログの所在に関する不確実性を感じる。財務チームは課金とクレジットの制限を感じる。経営陣は風評と継続性のリスクを感じる。サポートポリシーは一部のインシデントを除外またはクレジット制限付きで扱う一方で、事業はそれを存亡の危機として扱う。このギャップこそが、アーキテクチャがクレジットではできない仕事を果たさなければならない場所である。

調達テスト: ワークロードに合った証拠を求める

Cloud Metric は、完全な社内インフラチームを構築せずに、カナダのマネージドホスティング、バックアップ、セキュリティ、サポートを求める顧客にとって良い選択肢となりうる。同社には実際の公開プレゼンス、可視的なネットワーク割り当て、公表されたサービスのページ、サポート条件がある。懸念は、証拠が空っぽであることではない。懸念は、追加の証拠なしにサービスを広範に冗長であると扱うことを正当化するには証拠が不十分であることだ。

購入者は、ワークロードの分類から始めるべきだ。マーケティングウェブサイト、小規模なバックオフィスアプリケーション、規制対象の記録システム、収益に直結する顧客向けプラットフォームは、同じレベルのレジリエンスを必要としない。低リスクのワークロードであれば、Cloud Metric の公開主張、サポート窓口、カナダの配置は、小規模な関与を開始するのに十分かもしれない。高リスクのワークロードでは、顧客は移行前にアーキテクチャ証拠を求めるべきだ。すなわち、サイト数、セキュリティポリシーに適合するレベルのデータセンター所在地、ラックまたはベンダーの境界、アップストリームの混合、ファイアウォールとルーティングの設計、バックアップの隔離、復元テスト結果、人員配置とエスカレーションである。

第二のテストは障害シミュレーションだ。AS16276 経由の観測された上流経路が利用不能になったらどうなるか尋ねる。カナダのデータセンターが利用不能になったらどうなるか尋ねる。Cloud Metric のサポートページが到達不能になったらどうなるか尋ねる。複数の顧客に対して同時にバックアップ復元を実行しなければならない場合どうなるか尋ねる。顧客が30日以内に離脱しなければならない場合どうなるか尋ねる。答えは叙述的かもしれないが、検証可能なほどに十分に具体的であるべきだ。

第三のテストは契約上の整合性だ。発注書があることを言い、サポートポリシーが別のことを除外するならば、本番稼働前に不一致を解決する。顧客が標準クレジットよりも強力な救済を必要とするならば、それを交渉するか、別の経路を設計する。顧客がすべてのサポートアクセスをカナダ国内で必要とするならば、それをスコープに明記する。顧客がアクティブ・アクティブなホスティングを必要とするならば、バックアップのみの文言を代用として受け入れてはならない。

中程度の証拠は前進するには十分だが、安心するには不十分

最終的な判断は意図的にバランスが取られている。Cloud Metric は、単にディレクトリ上の名前ではない。公開されたサービスのページ、法的条件、サポート窓口、ARIN デジタルリソース、現在アナウンスされている IPv4 プレフィックスを持っている。RIPEstat は経路を観測している。ARIN は ASN と /24 を Cloud Metric Inc. に結びつけている。同社自身の資料は、一貫してカナダのマネージドクラウド、インフラストラクチャ、バックアップ、災害復旧、サポートを説明している。

同時に、外部から深く冗長化されていると見なすには証拠は十分に強くない。現在の公開 BGP フットプリントは単一の IPv4 /24 である。RIPEstat のネイバービューは、単一の可視的な隣接 AS のみを示している。PeeringDB にはその ASN のネットワークプロファイルがない。公開ページは複数のカナダのデータセンターに言及しているが、施設を名指しせず、どのサービス階層がマルチサイトであるかを開示していない。サポートポリシーは有意義なコミットメントを与える一方で、重要な依存関係のいくつかのクラスを除外している。プライバシーポリシーは、一部の技術サポートサービスプロバイダーがカナダ国外にいる可能性を認めている。

この組み合わせは、中程度のネットワーク証拠レベルを支持する。同社は可視的に稼働しており、公開記録は休眠中の ASN やプレースホルダーサイトよりもはるかに優れている。しかし、ホスト型容量は、背後にあるラック、経路、バックアップ、サポート、退出計画と同等の強度しかない。顧客がクリティカルなワークロードを移行する前に、Cloud Metric は容量がどこに存在するか、どのようにフェイルオーバーするか、誰が修理するか、経路にどのベンダーがいるか、関係が終了した場合に顧客がどのようにデータを回収するかを示すよう求められるべきである。

実務上の結論は「Cloud Metric を避けよ」ではない。「物理的依存関係の地図を手にサービスを購入せよ」である。プロバイダーはマネージド容量を販売するが、顧客のリスクは依然として物理的かつ契約的である。カナダのクラウド請求書は運用負荷を軽減しうる。電力、トランジット、スペアパーツ、サポート、バックアップの整合性、法的配置、ポータビリティを検証する必要性を消し去ることはできない。これが、Cloud Metric をマネージドパートナーとして利用することと、クラウドラベルがすでに難しい部分を解決したと想定することとの違いである。