概要

  • Cloud Provider USA, LLC. には実際の公開ネットワークマーカーがある。ARIN は AS46518 をアクティブとしてリストし、RIPEstat はアナウンスを確認しており、現在のルーティングビューでは同社が発信する 5 つの IPv4 プレフィックスが確認できる。
  • サービス面のストーリーはルーティング面ほど完全ではない。同社自身の HTTP ホームページはクラウドホスティング、IaaS、DaaS、DRaaS、BaaS を説明しているが、現在の HTTPS パスは Itrica に遷移し、Itrica の公開ページによれば Cloud Provider USA は 2013 年後半に Itrica のサービスプラットフォームに統合された。
  • 最も強い運用上の主張は「クラウド」ではなく「ホスティングされた物理的依存」である。すなわち、リースまたは管理されたデータセンター容量、トランジットの多様性、サーバーとストレージの在庫、サポート対応、請求の継続性、顧客の退出オプションである。
  • 購入者は、Cloud Provider USA または運用プラットフォームが現在の施設割り当て、復旧テストの証拠、RPKI カバレッジ、トランジット契約、エスカレーションパス、ポータブルなバックアップアクセスを提示できるまで、冗長性、ローカリティ、ディザスタリカバリの表現を仮説として扱うべきである。

小さいながらも可視性のあるネットワークを持つクラウドプロバイダ

Cloud Provider USA, LLC. は、サービスの語彙ほどには公開証拠が大きく見えないインフラ企業の一種である。その名称は全国的なクラウドプロバイダを約束する。かつての公開サイトは、ビッグデータからクラウドホスティングまでミッションクリティカルなデータとテクノロジーサービスを提供すると述べ、提供を予定する製品として IaaS、DaaS、DRaaS、BaaS を挙げていた。しかし、レジストリの証拠ははるかに狭く、有用である。1 つの自律システム、1 つの直接割り当てられた IPv4 ブロック、5 つの可視のオリジネートプレフィックス、公開 PeeringDB エントリなし、そして現在 Itrica のウェブプレゼンスと併せて読む必要があるサービス記録である。

これは否定ではない。インフラにおいて、小規模であっても本物であることはあり得る。プロバイダは、マネージドサポート、固定費、コンプライアンス支援、人間によるエスカレーションパスを重視する顧客に対して有意義なワークロードを実行するためにハイパースケール規模を必要としない。重要な区別は、公開容量の表現と運用容量の間にある。Cloud Provider USA のホームページは、クラウドホスティング、プロフェッショナルサービス、マネージドサービス、準拠したソフトウェア開発のためのプラットフォームを説明している。また、完全なサービス範囲の詳細については後日訪れるよう訪問者に求めている。サイトマップは、ホームページとプライバシーおよび法的 PDF のみで、簡素である。これにより、購入者は企業を特定するのに十分な証拠を得られるが、現在のラック数、ストレージクラスタ、ハイパーバイザー、技術者、復旧サイト、サポートされている顧客ワークロードの正確な数を推測するには不十分である。

ネットワークの証拠はより最新である。ARIN の AS46518 の RDAP レコードは、自律システムを CLOUDPROVIDERUSA、Cloud Provider USA, LLC. を登録者として識別する。AS はアクティブで、登録者の住所はマサチューセッツ州クインシーにある。関連する100.42.112.0 ～ 100.42.127.255 の ARIN ネットワークレコードは、CPU-1 という名前の直接 IPv4 割り当てをリストしている。RIPEstat の AS 概要は、クエリ時に AS がアナウンスされていたことを示し、RIPEstat のルーティングステータスは、その結果セット内のすべての 326 の IPv4 RIS ピアからネットワークを観測し、5 つのプレフィックスにわたって 1,536 の IPv4 アドレスがアナウンスされ、IPv6 スペースはアナウンスされていない。

これにより、Cloud Provider USA は、単なる駐車中のウェブサイトやリセラーのリストよりも実質的な痕跡を持つ。これはオリジネーションネットワークであり、ディレクトリ内の単なる名前ではない。同時に、痕跡には限界がある。5 つのプレフィックスは、RIPEstat のアナウンスプレフィックスデータによると、100.42.112.0/24、100.42.113.0/24、100.42.114.0/24、100.42.124.0/23、100.42.126.0/24 である。アドレス数は、コンパクトなマネージドホスティングプラットフォーム、カスタマーサービス、制御システム、プロバイダインフラには十分である。それ自体は、大規模な予備容量の証拠にはならない。また、実際に使用されているアドレスの数、稼働しているコンピューティングの量、スペアハードウェアが在庫されているかどうか、1 つの施設が停電した場合やトランジットプロバイダが障害を起こした場合に顧客をどう移行するかについてもほとんど語らない。

これが 2026 年の Cloud Provider USA の中心的な読み方である。ネットワークは本物であり、サービスの歴史は本物であり、公開運用の詳細は薄い。したがって、同社は、最も重要な事実がマーケティング層の下にあるホスティング容量プロバイダとして評価されるべきである。

同社が販売すると言っているもの

同社の公開約束はホスティング容量から始まるが、語彙は仮想マシンよりも広い。Cloud Provider USA のホームページは、クラウドホスティング、インフラサービス、デスクトップアズアサービス、ディザスタリカバリアズアサービス、バックアップアズアサービス、プロフェッショナルサービス、マネージドサービス、準拠したソフトウェア開発に言及している。マスターサービス契約は、ランディングページよりも有益である。なぜなら、サービスが実際にどのように契約されるかを説明しているからである。サービスは単一の汎用的公開メニューとして提示されていない。署名されたサービスオーダーで定義され、各サービスオーダーはサービス、料金、その他の条件を記述することになっている。これは、完全なセルフサービスのパブリッククラウドマーケットプレイスではなく、カスタムまたはマネージドサービスの姿勢を示している。

それは信頼性にとって重要である。セルフサービスクラウドは通常、リージョン名、インスタンスファミリー、ストレージクラス、ネットワークエグレス条件、サポートプラン、ステータスページを公開する。マネージドプロバイダはしばしば異なる取引を行う。公開 SKU が少なく、よりプライベートな設計、よりカスタムサポート、名前付きサービスオーダーへの依存度が高く、プロバイダスタッフへの依存度が高い。Cloud Provider USA の法的文書は 2 番目のパターンに適合する。標準サービス、技術サービス、補足プロフェッショナルサービス、サードパーティ製品に言及している。また、プロバイダはサードパーティのハードウェアまたはソフトウェアを使用または提供する可能性があると述べている。実際には、顧客の稼働時間は、Cloud Provider USA のラックだけでなく、基盤となる施設契約、キャリア回線、ストレージプラットフォーム、仮想化ソフトウェア、バックアップソフトウェア、セキュリティツール、専門家労働力の組み合わせに依存する可能性がある。

現在のウェブ動作はさらに別の層を追加する。HTTP サイトは依然として Cloud Provider USA の資料を表示するが、同じドメインへの HTTPS リクエストはItricaに遷移する。Itrica 自身のアバウトページは、Cloud Provider USA は 2011 年にインフラ管理に必要なコストと時間を削減するテクノロジーソリューションを構築するために設立され、両社は 2013 年後半にサービスが統合されたと述べている。同じページは、統合プラットフォームはデータモビリティとデータ保護を備えたミッションクリティカルな高性能ワークロードを実行し、コアプラットフォームは時間の経過とともにコンプライアンス指向の認証を取得したと述べている。これは重要な公開主張であるが、Cloud Provider USA 固有の施設、ネットワーク、サポート証拠の代わりではなく、現在の運用コンテキストのシグナルとして読まれるべきである。

Itrica の現在のサービスページは、Cloud Provider USA の古いランディングページよりも豊富な提供内容を説明している。Itrica のホームページは、高性能コンピューティングとストレージ、マネージドクラウドサービス、バックアップ、ディザスタリカバリ、組み込みセキュリティ、固定費インフラ、Kubernetes、AI、エッジネットワーキング、アプリケーション統合のサポートについて議論している。Itrica の IaaS データセンターのページは、ボストン、ラスベガス、東京、チューリッヒ、デュッセルドルフに施設があり、マネージドシステム、コンプライアンス文書、セキュリティ対策、冗長電源と冷却、24 時間 365 日の監視、ディザスタリカバリ、高可用性を必要に応じて提供すると主張している。アバウトページは、ラスベガス、サマービル、チューリッヒ、デュッセルドルフ、東京に施設をリストし、プラットフォームはバックアップとディザスタリカバリ環境のためにデータセンターをリンクする独自の 10 Gbps BGP ネットワークを使用していると述べている。

これらの記述は、Cloud Provider USA のネットワーク連絡先と現在のウェブ動作が Itrica の運用面を指しているため、関連性がある。しかし、特定のワークロードの安全性を宣言するにはまだ不十分である。「クラウド」は配信モデルであり、どの建物、どのケージ、どのキャリアミートミールーム、どの電源パス、どのディスクシェルフ、どのバックアップジョブ、どの担当者が悪い週に顧客を支えるかを知る必要性を排除するものではない。NIST のクラウド定義は、リソースプーリングや測定されたサービスなどのサービス特性を、それらを可能にする基盤資産から分離するため、ここで有用である。顧客は抽象化を購入するかもしれないが、プロバイダは依然としてハードウェアを運用する。

したがって、Cloud Provider USA は、摩擦のないコモディティクラウドではなく、マネージドホスティング容量を販売しているように見える。これは規制された顧客やハンズオンサポートを必要とするアプリケーションオーナーにとって魅力的であり得る。また、契約前の証拠の価値を高める。プロバイダのサービスオーダーが実際のコミットメントが存在する場所である場合、顧客は広範なウェブサイトのフレーズに依存すべきではない。サービスオーダーは、場所、復旧目標、責任、メンテナンス権限、エクスポート権限、サポート時間、エスカレーション連絡先、請求中断の結果、関係終了時の顧客データと機器の扱いを特定しなければならない。

抽象化の背後にある物理的フットプリント

Cloud Provider USA を読む最も有用な方法は、物理的依存関係から始めて上に向かって進むことである。ホストされたサーバー、仮想デスクトップ、バックアップリポジトリ、ディザスタリカバリ環境には、電源、冷却、ラックスペース、ネットワーククロスコネクト、スイッチング、ルーティング、ストレージ、コンピューティング、監視、リモートハンズ、交換部品が必要である。また、運用を継続するための法的許可も必要である。施設アクセス、キャリアサービス、ソフトウェアライセンス、支払い状況、顧客の承認である。プロバイダはこれらの詳細を通常のユーザーインターフェースから隠すことができるが、それらから逃れることはできない。

Cloud Provider USA の記録はマサチューセッツ州を繰り返し挙げている。ARIN はクインシーの会社住所をリストしている。ARIN の連絡先レコードはボストンの住所と cloudproviderusa.com および itrica.com のサポートメールアドレスを使用している。Itrica のページはボストン本社住所を示し、マサチューセッツ州および他の場所の施設または仮想データセンターを説明している。動作環境からの公開 DNS ルックアップは、cloudproviderusa.com およびwww.cloudproviderusa.comが 100.42.124.32 に解決され、これは Cloud Provider USA の直接割り当て内にあり、portal.cloudproviderusa.com は 100.42.120.30 に解決された。これは、顧客向けウェブ資産の少なくとも一部がプロバイダ自身のアドレス空間を指していることを意味する。ポータルサブドメインは、この研究環境からの 20 秒のテストウィンドウ内で HTTP または HTTPS に応答しなかったため、利用可能性シグナルとして扱われるべきであり、廃止の証拠ではない。

施設のストーリーは直接観測可能ではない。Itrica の公開ページは、ボストンまたはサマービル、ラスベガス、東京、チューリッヒ、デュッセルドルフをデータセンターの場所として特定し、冗長電源と冷却を説明している。ここでレビューされた公開ページテキストでは、現在の施設名、スイート番号、ミートミールームプロバイダ、クロスコネクト図、テナントケージの詳細、監査済み容量、電力消費、ハードウェアインベントリ、サイトごとの顧客分布、現在のフェイルオーバーテストは提供されていない。この欠如はマネージドプロバイダにとって珍しいことではないが、デューデリジェンスの負担を変える。購入者は「グローバル」という言葉だけから復元力を検証できない。

設置容量と使用可能容量は異なる。設置容量はプロバイダが指し示すことができるものである。ラック、サーバー、ストレージシェルフ、回線、IP アドレス、ソフトウェアプラットフォーム。使用可能容量は、オーバーサブスクリプション、内部システム、バックアップ予備、メンテナンスウィンドウ、障害ディスク、電力密度制約、顧客コミットメント、ライセンス制限の後に残るものである。プロバイダは十分な IP スペースを持っていても、障害を吸収するために適切な CPU 世代、RAM プロファイル、ストレージクラス、ハイパーバイザーバージョンを備えたスペアホストを欠いている可能性がある。逆に、スペアハードウェアを持っていても、キャリアパスや顧客データポータビリティが不足しているため、許容できないダウンタイムなしにワークロードを移動できない可能性がある。Cloud Provider USA の公開記録は、もっともらしいネットワークベースを示しているが、顧客が気にするであろう使用可能な余裕を開示していない。

法的文書も物理的所有権の境界を明らかにする。マスターサービス契約は、クライアントが CPU の敷地内に財産を置いたり保管したりする可能性があり、クライアントはその財産に対して責任を負うと述べている。また、解約時に当事者はクライアントの財産の撤去を手配し、30 日以内に撤去されなかったクライアントの財産は CPU の財産になる可能性があると述べている。この条項は、少なくとも一部のサービスには、プロバイダ管理スペース内の顧客機器、ホスト型ハードウェア、アプライアンス、またはその他のクライアント所有資産が含まれていた可能性があるという強いシグナルである。これにより復旧の問題が変わる。顧客は、データをエクスポートする方法だけでなく、サービス関係が終了したり施設の移動が必要になった場合に、機器、キー、ソフトウェアメディア、バックアップアプライアンス、その他の財産をどのように回収するかを知る必要があるかもしれない。

これにより、サービスカテゴリのタイトルはやや誤解を招くものになる。「クラウドプロバイダ」はリモートで弾力的に聞こえる。ここの記録はマネージドインフラのように聞こえる。サービスオーダーのコミットメント、ホストされた容量、サードパーティ製品、クライアント財産、サポート資格情報、ACH 請求、施設に依存した復旧。運用リスクは、Cloud Provider USA がクラウドの語彙を欠いていることではない。運用リスクは、最も重要な生存可能性の事実がローカルで契約的で物理的であることである。

ルーティング面：5 つのプレフィックス、いくつかのネイバー、IPv6 の可視性なし

AS46518 は、Cloud Provider USA が依然としてグローバルルーティングシステムで可視であることを示す最も明確な証拠である。BGP.toolsは AS を Cloud Provider USA, LLC. として説明し、ウェブサイトを cloudproviderusa.com として示している。RIPEstat で可視の同じ 5 つのプレフィックスをリストし、ページ読み込み時に 4 つのアップストリームキャリアと 6 つのピアを報告している。取得したページに示されているアップストリームには、TowardEX Technologies International、Arelion、Lumen、IPTP が含まれる。RIPEstat のASN ネイバーデータは、クエリの最新利用可能時間に 5 つのユニークなネイバー ASN を観測した。AS1299、AS140951、AS27552、AS3356、AS41095 である。

このトランジットの状況は、シングルホームエッジよりも優れている。AS が複数のアップストリームから到達可能であれば、単一のアップストリーム障害が必ずしもすべてのアドレスを到達不能にするわけではない。しかし、ルーティングの多様性はサービスの多様性と同じではない。2 つのアップストリームが同じダクトを通って同じ建物に入る可能性がある。複数の BGP ネイバーが同じルーターペアで終端する可能性がある。ルートは世界中で可視である一方で、特定の顧客 VM、ストレージボリューム、ファイアウォールクラスタがダウンしている可能性がある。プロバイダの BGP テーブルは「プレフィックスへの何らかのパスが存在する」と言うが、「あなたのアプリケーションは正常である」とは言わない。

現在の RIPEstat ルーティングステータス結果は、IPv4 可視性に関して肯定的である。データセット内のすべての IPv4 RIS ピアから AS46518 を観測し、1,536 アドレスをカバーする 5 つの IPv4 プレフィックスをカウントした。また、ゼロの IPv6 アナウンスを報告した。これは、Cloud Provider USA がプライベートな取り決めで IPv6 を提供できないことを証明するものではないが、公開 IPv6 到達可能性がそのビューを通じて可視ではないことを意味する。現代のコンプライアンス、調達、製品要件を持つ顧客にとって、公開 IPv6 の証拠の欠如は直接尋ねるべき制限である。一部のエンタープライズワークロードは IPv4 のみのインフラで実行できる。他のもの、特にパブリックアプリケーション、政府向けシステム、モバイルエコシステム、デュアルスタック SaaS サービスは、通常の到達可能性パスとしてますます IPv6 を必要としている。

5 プレフィックスの形状も重要である。3 つの /24 と 1 つの /23 ともう 1 つの /24 はルーティングが容易で運用上従来型であるが、巨大ではない。プロバイダのウェブサービス、顧客 NAT、マネージドサーバー、バックアップエンドポイント、VPN、監視、管理システムを運ぶことができる。また、レピュテーションと障害の影響を集中させる。プロバイダのアドレススペースが 1 人の顧客から悪いレピュテーションを受けた場合、ルートが誤ってフィルタリングされた場合、アップストリームにポリシーの問題がある場合、または一部のネットワークでルートオリジン検証が失敗した場合、その影響はコンパクトなアドレス資産全体に広がる可能性がある。ホスト型メール、ファイル転送、API エンドポイント、マネージド VPN を使用している顧客は、アドレスがどのように分離されているか、1 人の顧客が共有アドレスのレピュテーションに影響を与えた場合のインシデント対応がどのように機能するかを尋ねるべきである。

ルートオリジン検証は、公開証拠のもう 1 つの弱点である。RIPEstat の100.42.112.0/24 の RPKI 検証応答、および他の可視プレフィックスに対する同等の応答は、クエリ時に「unknown」を返し、検証可能な ROA はなかった。RPKI 用語では、unknown は invalid ではない。ルートがバリデータに可視のルートオリジン認証でカバーされていなかったことを意味する。IETF RPKI アーキテクチャは、ルートオリジンセキュリティのためのリソース認証モデルを説明している。マネージドインフラプロバイダにとって、可視の ROA の欠如はそれ自体で顧客の障害にはならないが、1 つのルートハイジャックおよびフィルタリング保護層が未使用のままになる。AS に公開エンドポイントを依存している顧客は、Cloud Provider USA または運用プラットフォームが ROA を公開し、ルートオブジェクトを一貫して維持する計画があるかどうかを尋ねるべきである。

PeeringDB API クエリを通じて公開 PeeringDB エントリは見つからず、エンティティは返されなかった。これは、ネットワークにプライベートトランジットやエクスチェンジプレゼンスがないことを意味するものではない。交換場所、トラフィックポリシー、NOC 連絡先、プレフィックス制限、ピアリングポスチャを検査するための公開 PeeringDB 自己記述がないことを意味する。多くの小規模マネージドプロバイダにとって、これは正常である。冗長性を主張する顧客にとって、これは簡単な外部クロスチェックを削除する。実際のアップストリーム契約、回線の多様性、現在のルートポリシーを示すプロバイダ文書を要求すべきである。

BGP 自体は到達可能性プロトコルにすぎない。RFC 4271は、BGP が自律システム間でネットワーク到達可能性情報を交換する方法を説明している。アドレスの背後にあるサーバーが正常であるか、バックアップが完了したか、ディスクアレイが再構築中であるか、メンテナンスウィンドウが伝達されたか、顧客が午前 3 時に復元を受けられるかを検査しない。したがって、Cloud Provider USA のルーティング面は下限であり、上限ではない。企業をインフラの会話に残すのに十分な証明である。現在のサービス証拠なしにプラットフォームに依存するのに十分な証明ではない。

冗長性の主張には復元の証拠が必要

Cloud Provider USA のサービス語彙にはディザスタリカバリとバックアップが含まれる。Itrica の現在のサービスページはさらに進んで、代替サイトのデータ保護、年次ディザスタリカバリテスト、オフサイト長期保存によるバックアップ、セルフサービス復旧、オプションのオンプレミスバックアップストレージ、エグレス料金なしを説明している。これらは予測可能な復旧コストを必要とする顧客にとって強力な主張である。また、バックアップとディザスタリカバリは、「データが存在する」と「実際に事業を再開できる」の境界で頻繁に失敗するため、最も注意深い証明を必要とする。

最初の質問は、復旧容量がどこにあるかである。Itrica のページは、米国、欧州、日本にまたがる複数のデータセンターの場所に言及している。顧客は、それらの場所のどれが自社のサービスオーダーに割り当てられているかを知る必要がある。マサチューセッツ州の本番 VM と同じ都市圏のバックアップコピーは、オペレーターエラーや単一サーバーの損失には十分かもしれないが、地理的ディザスタリカバリと同じではない。ラスベガスのバックアップは、地域の電力や建物の問題を解決するかもしれないが、レプリケーションが最新であり、アプリケーションがそこで実行でき、ネットワークルートが変更でき、ライセンスがそれを許可し、顧客がランブックをテストしている場合に限る。欧州や日本のコピーは継続性を向上させるかもしれないが、レイテンシ、管轄権、プライバシー、サポート時間の問題を引き起こす。

2 番目の質問は、復元の優先順位がどのように割り当てられるかである。広範囲の障害では、すべての顧客が最初に復旧したいと考える。プロバイダが顧客のサブセットに合わせてサイズ設定されたスペアコンピューティングを持っている場合、「DRaaS」は予約ポリシーに依存する。専用復旧容量は高価である。共有復旧容量は安価であるが、オーバーサブスクライブされる可能性がある。Cloud Provider USA の公開資料は予約比率を開示していない。購入者は、復旧コンピューティング、ストレージ IOPS、パブリック IP 割り当て、VPN 容量、サポート労働力が専用か、プールか、ベストエフォートかを尋ねるべきである。

3 番目の質問は、バックアップがアプリケーション一貫性があるかどうかである。ファイルコピーやボリュームスナップショットは技術的に成功しても、データベース、ID サービス、メッセージキュー、ライセンスサーバー、外部依存関係が順序どおりに復旧されない場合、ビジネスは失敗する。Itrica の現在のコピーはマネージドサポートとコンプライアンス文書を強調しており、これは有用なシグナルである。しかし、購入者は復元記録を必要とする。最終テストの日付、テストの範囲、データの経過時間、実際の復旧時間、例外、責任者、アプリケーションオーナーが承認したかどうか。NIST のコンティンジェンシープランニングガイダンスは、復旧を単なるストレージ機能ではなく、計画されテストされた能力として扱うため、関連性がある。

4 番目の質問は、出口または緊急時にエグレスが本当に予測可能なままであるかどうかである。Itrica はホームページで「エグレス料金なし。永久に。」と述べ、一部のホスティングサービスに対して固定価格の運用コストモデルを説明している。これは、データ転送料金が緊急移行を高価にする可能性があるハイパースケールパブリッククラウドに対して意味のある利点となり得る。しかし、「エグレス料金なし」はサービスオーダーの文言に結び付けられるべきである。顧客は、このフレーズがすべてのバックアップエクスポート、すべてのリージョン、すべての緊急移行、すべてのクロスコネクト転送、すべてのサードパーティキャリア、すべての物理メディアオプション、すべての解約後のデータ検索に適用されるかどうかを尋ねるべきである。料金無料の転送でも、レート制限されたり、サポートの可用性によって遅延されたり、プロプライエタリなバックアップ形式によってブロックされたりすれば、ポータビリティリスクである。

5 番目の質問は、誰が作業を行うかである。マネージドプロバイダは、熟練したスタッフが顧客のスタックを知っている場合、セルフサービスプラットフォームよりも復元力が高くなり得る。また、重要な知識が小さなチームに集中している場合、より脆弱になり得る。Cloud Provider USA の古い契約は、ユーザーインターフェース、認証情報、サービス設定、サポート責任に関して CPU に広範な権利を与える一方、Itrica の現在のページは社内の専門家とホワイトグローブサービスを強調している。これはチームが到達可能で最新である場合に魅力的である。顧客が長期のインシデント中にエスカレーションを得られない場合、危険である。復旧の証拠には、単なるサポートメールではなく、名前付きのエスカレーションロールを含めるべきである。

バックアップとディザスタリカバリは、したがって、はい・いいえの機能ではない。容量予約、スクリプト、人材、データ形式、ネットワークルート、契約である。Cloud Provider USA の公開記録は質問をサポートする。それ自体で答えるものではない。

契約はいくつかの障害経路を明らかにする

マスターサービス契約は、障害モードの驚くほど直接的なマップである。最初は請求である。サービスオーダーが別段の定めをしない限り、契約は月々のサービス支払いは ACH を通じて前払いされ、変動料金や特別料金は別途請求されると述べている。請求に関する紛争は、定義された期間内に電子メールで送信されなければならない。延滞料金は解約権を引き起こす可能性がある。本番ワークロードを実行している顧客にとって、請求の失敗は会計上の詳細ではない。銀行変更、買収、紛争、期限切れの支払い承認、請求書の誤解が支払いを中断した場合、プロバイダはサービス継続に影響を与える権利を持つ可能性がある。顧客は、請求連絡先、紛争手続き、緊急支払い救済を可用性管理として扱うようにすべきである。

2 番目の障害経路はサービス変更である。契約は、クライアントサービスが許可された担当者が CPU ユーザーインターフェースを通じて設定を調整することを許可する可能性があり、クライアントはユーザー名とパスワードに対して責任を負うと述べている。また、CPU の重大な過失または意図的な不正行為の場合を除き、CPU はインターフェースまたは認証情報の使用に対して責任を負わないと述べている。これにより、アクセス制御衛生が信頼性モデルに入る。侵害された管理者アカウントは、コスト、構成、可用性の損害を生み出す可能性がある。失われた管理者アカウントは復旧を遅らせる可能性がある。顧客は、現在のプラットフォームが MFA、ロール分離、変更承認、アクセスログ、緊急ロックアウト、委任された復旧連絡先をサポートしているかどうかを知るべきである。

3 番目の障害経路はサードパーティ依存である。CPU の契約は、サービスがサードパーティ製品を使用または提供する可能性があり、それらの製品はサードパーティの条件に従う可能性があると述べている。これはマネージドホスティングでは正常である。また、顧客の継続性がソフトウェア更新、ベンダーサポート、ハイパーバイザーの互換性、バックアップ製品のライセンス、ストレージファームウェア、セキュリティツール、供給可用性に依存する可能性があることを意味する。ハードウェア交換にベンダー部品が必要な場合、バックアッププラットフォームのライセンスが期限切れになった場合、ストレージ製品がサポート終了に達した場合、プロバイダのクラウド約束はベンダー管理問題になる。顧客は、リスク評価に必要なレベルで現在のプラットフォームスタックを尋ねるべきであり、たとえプロバイダが公開しなくても。

4 番目の障害経路は法的責任とコンテンツである。契約は、クライアントが利用規定に違反した場合、または CPU に法的責任を課す可能性のあるコンテンツをホストし続けた場合、CPU は直ちにサービスを終了または停止できると述べている。これはどのインフラプロバイダにとっても理解できるが、運用上の結果がある。センシティブなユーザー生成、規制対象、または国境を越えるコンテンツをホストする顧客は、停止前のエスカレーションプロセスを知るべきである。誰が通知を受け取るか？どのような証拠が必要か？論争のあるコンテンツは環境全体をダウンさせずに分離できるか？改善する猶予はあるか？バックアップはまだアクセス可能か？これらの質問は重要である。なぜなら、法的および虐待の手続きは、エンドユーザーには技術的な障害のように見える停止を引き起こす可能性があるからである。

5 番目の障害経路は顧客財産である。CPU の敷地内にある財産に関する契約の文言は、一部の顧客がプロバイダ管理スペースに物理的に資産を持っている可能性があることを示唆している。その場合、移行は単なるデータエクスポートではない。輸送、リモートハンズ、国際移動の税関、ライセンス移転、セキュアワイピング、機器撤去、チェーンオブカストディ記録が必要になる可能性がある。顧客は、「クラウド」が自分たちが取り出すものは何もないことを意味すると想定すべきではない。ハードウェア所有権、メディア返却、安全な廃棄条件についてサービスオーダーを読むべきである。

6 番目の障害経路は不可抗力である。契約には、気象、政府規制、テロリズム、戦争、反乱、制御不能な壊滅的イベントに関する従来の条項が含まれ、遅延が所定の期間を超えた場合の解約権がある。ここで物理的世界がクラウド契約に再び入る。施設の電力、地域の気象、キャリアの停止、政府命令、国境管理が重要になる。顧客が Itrica プラットフォームを通じて Cloud Provider USA に重要なワークロードを依存している場合、別の場所へのフェイルオーバーが契約上義務付けられているか、オプションか、テスト済みか、単に有料設計として利用可能かを理解すべきである。

これらはエキゾチックなリスクではない。ホスト型インフラの通常の障害モードである。支払い、アクセス、サードパーティ製品、法的苦情、物理的財産、災害。契約はそれらを可視化する。良い購入者はそれらを定型文として扱わない。

データローカリティは具体的である場合にのみ機能する

Cloud Provider USA はここでは米国のクラウドサービス企業として分類されており、ARIN の記録は米国のネットワークと企業フットプリントをサポートしている。しかし、サービスのストーリーは純粋に国内ではない。Itrica の公開ページは、米国、欧州、日本のデータセンターを説明し、グローバルカバレッジを SaaS ビジネスにとっての利点として提示している。これはレイテンシと復元力に有用である。また、データ主権が会社名から推測できないことを意味する。

Cloud Provider USA のプライバシーポリシーは、サイトは米国でホストおよび運営されており、サイトに提出された情報は処理のために米国に転送され保存されると述べている。この記述は、2014 年のポリシーで説明されているウェブサイトとサービスのコンテキストには役立つ。すべての現代のワークロードの質問に答えるものではない。ホスト型アプリケーションは、別のバックアップ場所、ディザスタリカバリコピー、ロギングシステム、監視ツール、チケットシステム、サポートアクセス、サードパーティ製品、電子メールサービスを使用する可能性がある。公開 DNS 結果は、cloudproviderusa.com の Google メール交換も示し、Itrica ページは itrica.com の連絡先アドレスをリストしている。これらは本質的に問題ではない。単に、ローカリティはブランドの地理から推測されるのではなく、データタイプとシステムによって指定される必要があることを意味する。

米国の顧客にとって、マサチューセッツ州またはネバダ州の施設は多くのローカリティ要件を満たす可能性がある。ヘルスケア、金融、公共部門、国際 SaaS 顧客にとって、必要な答えはより詳細である。どの本番データが米国に留まるか？どのバックアップが国外に出るか？ログは欧州または日本に複製されるか？米国外のサポートスタッフが顧客システムにアクセスできるか？暗号化キーは顧客管理かプロバイダ管理か？バックアップエクスポートはパブリックインターネット、プライベート回線、物理メディア、顧客 VPN のいずれかで配信されるか？欧州の復旧コピーは GDPR またはセクター固有の義務を生じさせるか？日本のサイトはレイテンシセンシティブなトラフィックのみを処理するか、規制対象データを保持できるか？

現在の公開資料はこれらの質問を解決しない。Itrica は、IaaS データセンターのページで、施設が HIPAA、PCI、SOC2 を含む業界標準を満たしていると述べている。アバウトページは、プラットフォームは臨床試験作業以来コンプライアンス指向であり、後に SOC 2 Type II を取得したと述べている。これらの主張は価値があるかもしれないが、コンプライアンスの主張には範囲が必要である。SOC 2 レポートは、定義されたシステム、制御、期間に適用される。HIPAA サポートは事業提携契約と実際の保護手段に依存する。PCI の関連性は、カード会員データが範囲内にあるかどうかに依存する。顧客は、ウェブページの省略形に頼るのではなく、現在のレポート、ブリッジレター、範囲の説明、サイトリストを要求すべきである。

データローカリティはルーティングとも相互作用する。AS46518 はアップストリームネットワークとエクスチェンジビューを通じてグローバルに可視であるが、グローバルルート可視性はグローバルデータ配置と同じではない。ロンドン、ニューヨーク、東京で見られるルートは、データがそれらの都市に保存されていることを意味しない。プレフィックスがそれらの場所から可視のパスを通じて到達可能であることを意味する。逆に、チューリッヒのデータバックアップは、別のトランスポート配置の背後にある場合、別の Cloud Provider USA プレフィックスとして BGP で可視ではない可能性がある。唯一の信頼できる答えは、顧客のサービスに関連付けられたプロバイダ署名のアーキテクチャステートメントである。

Cloud Provider USA についての慎重な結論は次のとおりである。同社は米国の登録とルーティングの証拠を持ち、関連する現在のサービスページはグローバルインフラを説明している。この組み合わせは強みになり得る。また、曖昧さを生み出す可能性もある。データ主権は契約上およびアーキテクチャ上の事実であり、ブランド属性ではない。

システム障害時に影響を受ける人々

影響を受ける当事者はサービス設計に依存する。Cloud Provider USA または Itrica プラットフォームをマネージドアプリケーションホスティングに使用している顧客にとって、障害はまずアプリケーションユーザー（従業員、パートナー、患者、小売顧客、API クライアント、SaaS テナント）に影響を与える。バックアップアズアサービスとして使用している顧客にとって、障害は復元が必要になるまで目に見えない可能性があり、それはさらに悪い。バックアッププラットフォームは何ヶ月も静かに見え、ランサムウェアイベント、管理者エラー、ストレージ損失がそれを不可欠にする瞬間に失敗する可能性がある。ディザスタリカバリの場合、障害はしばしばすでにストレスがかかっているビジネスイベントと一致するため、影響を受けるグループはさらに広い。

ネットワーク障害は、公開エンドポイント、VPN、管理アクセス、レプリケーションに影響を与える。AS46518 が 1 つのアップストリームを通じてルートを失っても、他のアップストリームを通じて可視のままである場合、一部のユーザーは問題を感じないが、他のユーザーはパケットロスや高レイテンシを経験する。ルートが可視のままでも、ホストサーバーやファイアウォールがダウンしている場合、BGP データは正常に見えるが、顧客はオフラインになる。ルートリークやフィルタリング問題が 1 つのプレフィックスに影響を与える場合、そのアドレスブロックの顧客は他の顧客が到達可能なまま孤立する可能性がある。そのため、顧客は Cloud Provider USA が自社ネットワーク外からどのように監視しているか、インシデントがプレフィックス、サービス、顧客ごとにどのように伝達されるかを尋ねるべきである。

ラックまたは電源の障害は、クラスタリングに応じてワークロードに異なる影響を与える。単一の物理ホストは、ライブマイグレーションがない場合や共有ストレージが利用できない場合、複数の仮想マシンをダウンさせる可能性がある。トップオブラックスイッチは多くのサーバーを孤立させる可能性がある。ストレージシェルフは、コンピューティングが正常でも多くのワークロードを劣化させる可能性がある。電源障害は UPS と発電機で隠蔽できるが、燃料、転送スイッチ、メンテナンス、負荷容量が実際の条件下で機能する場合に限る。冗長電源と冷却が存在すると言う公開ページは出発点である。顧客は、自分のサービスが冗長ホスト、冗長ストレージコントローラ、別々の電力供給、テスト済み復旧グループを使用しているかどうかを知る必要がある。

ハードウェア在庫の障害はより微妙である。ディスクが故障しプロバイダにスペアがある場合、インシデントは日常的である。再構築中に複数のディスクが故障した場合、ストレージコントローラが寿命を迎えた場合、互換性のあるサーバー部品を注文しなければならない場合、ベンダーがプラットフォームをサポートしなくなった場合、ダウンタイムが延長する可能性がある。Cloud Provider USA の公開ページはハードウェアの経過年数やスペア在庫を開示していない。Itrica の現在のサイトは、高性能コンピューティング、エンジニアリングされたサーバーとストレージ容量、Ceph の専門知識、VMware および KVM スペシャリスト、ソフトウェア定義ストレージに言及している。これらは有用な能力シグナルであるが、顧客はサービスに関連するプラットフォームライフサイクル管理と交換在庫を依然として尋ねるべきである。

サポートの障害は他のすべての障害に影響を与える。現在の Itrica ページは、社内の専門家、一部のハイタッチサービスでの 15 分応答、特定のサービス説明での 24 時間 365 日のカバレッジを強調している。これらの主張はサービスオーダーに含まれている場合に意味がある。普遍的な証明ではない。顧客は、自分のプランに 24 時間 365 日のサポートが含まれているか、「応答」が何を意味するか、最初の対応者が問題を解決できない場合のエスカレーションパスは何か、サポートがアプリケーション層をカバーするのかインフラ層のみかを尋ねるべきである。Itrica のホームページにある 1 つの顧客の引用は、Itrica が責任範囲外の障害を支援したと述べており、少なくとも一部のケースでハイタッチサポートがあることを示唆している。見込み客はそのスタイルのサポートを書面による範囲に変換すべきである。

移行の障害は最後の影響を受ける当事者の問題である。顧客が障害後、価格変更後、コンプライアンス懸念後、または合併後に退去を決定した場合、出口パスはすでに存在しなければならない。バックアップはエクスポート可能でなければならない。IP 依存関係は特定されなければならない。DNS TTL は管理可能でなければならない。ファイアウォールルール、VPN、証明書、ライセンス、監視、ID 統合はポータブルでなければならない。エグレス料金がないことは、プロバイダが必要な速度で使用可能な形式でデータを移動できる場合にのみ役立つ。エクスポートをテストしていない顧客は、依然としてプロバイダの運用カレンダーに拘束される。

運用証拠の評価

公開記録は、Cloud Provider USA のネットワークに対して中程度の信頼度の見解を支持するが、その現在のサービス容量に対して高い信頼度ではない。最も強い証拠はレジストリとルーティングの証拠である。AS46518 は ARIN でアクティブである。直接割り当てはアクティブである。RIPEstat は AS がアナウンスされているのを見る。BGP.tools と RIPEstat は、コンパクトであるが可視の IPv4 ルートセットと複数のネイバーネットワークを示している。これは、同社が実際のネットワークフットプリントを持っていると言うのに十分である。

より弱い証拠は現在の商業運営に関するものである。Cloud Provider USA の HTTP サイトはまばらでスタイルが古い。HTTPS パスは Itrica に遷移する。カスタマーポータルサブドメインは解決するが、タイムドテストでは応答しなかった。PeeringDB には公開 ASN エントリがない。公開ページは、現在のステータスページ、名前付き施設、容量プール、顧客数、サポート名簿、稼働時間履歴、インシデント履歴、RPKI カバレッジ、詳細な IPv6 姿勢を公開していない。Itrica の現在のページはより豊富なサービスのストーリーを提供するが、現在の提供内容と歴史、広範な能力言語を混在させている。これらは有用なコンテキストであり、完全な運用監査ではない。

したがって、適切な評価は否定的ではない。否定的な評価は、公開記録がネットワークやサービスの存在と矛盾することを意味する。そうではない。適切な評価は強いでもない。強いには、施設の割り当て、本番容量、テスト済み復旧、セキュリティ範囲、メンテナンス履歴、顧客ステータス、ルートセキュリティに関する現在のサードパーティまたはプロバイダ公開の証明が必要である。ルートの証拠は強いが、顧客リスクの証拠は不完全である。

中程度はネットワーク証拠の実用的な評価であり、サービス容量の格下げを伴う。Cloud Provider USA は、可視の IPv4 到達可能性を持つ既存のインフラアクターとして扱うことができる。完全に透明なパブリッククラウドとして扱うべきではない。購入者の作業は、「アドレスは到達可能」と「私のワークロードはプロバイダ、施設、または契約の障害に耐えられる」の間のギャップを埋めることである。

Cloud Provider USA に依存する前に尋ねるべきこと

購入者または既存の顧客は、正確なサービスオーダーから始めるべきである。それは、どの法人がサービスを提供しているか、どのブランドまたはプラットフォームが運営しているか、どの施設が範囲内か、どのサービスが管理されているか、どのサードパーティ製品が組み込まれているか、サポート時間は何か、停止、解約、移行時に何が起こるかを明記すべきである。顧客が Cloud Provider USA の過去の資料のみではなく、Itrica の現在のプラットフォームに依存している場合、サービスオーダーはその旨を明確に述べるべきである。

施設の質問は具体的であるべきである。どのサイトが本番をホストしているか？どのサイトがバックアップをホストしているか？どのサイトがディザスタリカバリをホストしているか？これらのサイトは所有、リース、コロケーション、または別のデータセンター事業者を通じて提供されているか？本番と復旧は電力網、洪水地域、キャリアエントランス、管理プレーン、資格情報ドメインによって分離されているか？どの現在の監査またはコンプライアンスレポートがサイトをカバーしているか？顧客システムはシングルサイト、アクティブパッシブ、アクティブアクティブ、バックアップ専用か？どのメンテナンスウィンドウが影響を与える可能性があるか？

ネットワークの質問は、BGP をサービスに結び付けるべきである。顧客はどのプレフィックスを使用するか？AS46518 が複数のアップストリームを持っていても、サービスは 1 つの施設内でシングルホームか？Arelion、Lumen、TowardEX、IPTP などのキャリアは顧客の実際のサイトに使用されているか？ルートは RPKI ROA で保護されているか、従来のルーティングポリシーのみか？DDoS 保護は含まれているか？顧客は独自の IP アドレスを持ち込めるか？DNS レコードは顧客、プロバイダ、またはその両方によって制御されているか？アップストリーム、ルーター、またはクロスコネクトが故障した場合のフェイルオーバー手順は何か？

容量の質問は、設置容量を使用可能容量から分離するべきである。クラスタは何台のホスト障害を吸収できるか？どれだけのスペアコンピューティング、RAM、ストレージが予約されているか？ストレージ再構築はどのように監視されているか？バックアップは本番資格情報から分離されているか？復元テストはアプリケーション一貫性があるか？テストされた最大の復元は何か？どれだけの時間がかかったか？コミットされた復旧ポイントと復旧時間は何か？複数の顧客が同時に災害を宣言した場合、どうなるか？

サポートの質問は運用に関するものであるべきである。緊急電話番号は何か？時間外は誰が応答するか？最初の対応者が問題を解決できない場合のエスカレーションパスは何か？名前付きのテクニカルアカウントオーナーはいるか？変更は記録され承認されるか？顧客は読み取り専用の監視可視性を持っているか？インシデント通知は電子メールのみか、電話、SMS、チケットシステム、カスタマーポータルも含むか？ポータルが利用できない場合、顧客はどのようにサポートに連絡するか？

出口の質問は署名前に行うべきである。顧客はすべてのデータをどのようにエクスポートするか？どのバックアップ形式が使用されているか？暗号化キーはどのように扱われるか？プロバイダは物理メディアを発送できるか？データはどのくらいの速さでプラットフォームを離れられるか？帯域幅以外に料金はあるか？解約後、プロバイダはデータをどのくらい保持するか？顧客の機器、仮想アプライアンス、ログ、スナップショットはどうなるか？顧客は契約を終了せずに出口をテストできるか？

これらの質問は、Cloud Provider USA が弱いことを想定していない。ホスト型インフラは実際のインフラであると想定している。公開記録は、ライブ IPv4 ネットワーク、マネージドサービスの歴史、Itrica に関連する現在の運用コンテキストを持つプロバイダを示している。また、「クラウド」という言葉に証拠の役割をさせるべきではないほど十分な不透明さも示している。この場合、信頼性はスローガンではない。それは、次の修理ウィンドウが始まる前に可視化される必要がある一連のラック、ルート、電源パス、復元テスト、サポートコミットメント、請求管理、出口権利である。