概要

  • 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 があるのみである。これにより、バイヤーは会社を特定するには十分な証拠を得られるが、現在のラック数、ストレージクラスター、ハイパーバイザー、技術者、復旧サイト、あるいはサポート対象の顧客ワークロードの正確な数を推測するには不十分である。

ネットワークの証拠はより最新である。AS46518 の ARIN RDAP レコードは、自律システムを CLOUDPROVIDERUSA として識別し、Cloud Provider USA, LLC. を登録者として示している。AS がアクティブであり、登録者の住所がマサチューセッツ州クインシーにあることも示している。関連するARIN ネットワークレコード（100.42.112.0 から 100.42.127.255 まで）は、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 のホームページでは、クラウドホスティング、インフラサービス、デスクトップサービス（DaaS）、災害復旧サービス（DRaaS）、バックアップサービス（BaaS）、プロフェッショナルサービス、マネージドサービス、コンプライアンスソフトウェア開発について言及している。マスターサービス契約は、サービスが実際にどのように契約されるかを記述しているため、ランディングページよりも示唆に富む。サービスは、1 つの一般的な公開メニューとして提示されてはいない。それらは、署名されたサービスオーダーで定義されており、各サービスオーダーはサービス、料金、その他の条件を記述することになっている。これは、完全にセルフサービス型のパブリッククラウドマーケットプレイスというよりは、カスタムまたはマネージドサービス型の姿勢を示している。

これは信頼性にとって重要である。セルフサービス型クラウドは通常、リージョン名、インスタンスファミリー、ストレージクラス、ネットワークエグレス条件、サポートプラン、ステータスページを公開する。マネージドプロバイダーはしばしば異なる取引条件を持つ。すなわち、公開された 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、さらに別の /24 はルーティングが容易で運用上も慣例的だが、それほど大きくはない。プロバイダーのウェブサービス、顧客の NAT、マネージドサーバー、バックアップエンドポイント、VPN、監視、管理システムを運ぶことができる。これらはまた、レピュテーションと障害の影響を集中させる。プロバイダーのアドレス空間が 1 つの顧客から悪い評判を受けた場合、経路が誤ってフィルタリングされた場合、アップストリームにポリシーの問題が生じた場合、または一部のネットワークで経路起点検証が失敗した場合、影響はコンパクトなアドレス資産全体に広がる可能性がある。ホスト型電子メール、ファイル転送、API エンドポイント、マネージド VPN を使用する顧客は、アドレスがどのように分離されているか、また、ある顧客が共有アドレスのレピュテーションに影響を与えた場合のインシデント対応がどのように機能するかを問いただすべきである。

経路起点検証（RPKI）は、公開証拠におけるもう一つの弱点である。RIPEstat の100.42.112.0/24 の RPKI 検証レスポンス、および他の可視プレフィックスに対する同等のレスポンスは、クエリ時点で有効な ROA がなく「unknown」を返した。RPKI の用語では、unknown は invalid ではない。経路が、バリデーターから見える経路起点認証によってカバーされていなかったことを意味する。IETF RPKI アーキテクチャは、経路起点セキュリティのためのリソース認証モデルを説明している。マネージドインフラプロバイダーにとって、可視の ROA がないこと自体が顧客の停止を引き起こすわけではないが、経路ハイジャックとフィルタリング保護の一層が未使用のまま残される。公開エンドポイントでこの AS に依存する顧客は、Cloud Provider USA または運用プラットフォームが ROA を発行し、経路オブジェクトを一貫して維持する予定があるかどうかを問いただすべきである。

ASN 46518 の PeeringDB API クエリを通じて公開 PeeringDB エントリは見つからず、エンティティは返されなかった。これは、ネットワークがプライベートなトランジットやエクスチェンジでの存在を欠いていることを意味しない。公開された PeeringDB の自己記述がなく、エクスチェンジロケーション、トラフィックポリシー、NOC コンタクト、プレフィックス制限、ピアリング姿勢を検査できないことを意味する。小規模なマネージドプロバイダーにとっては、それが普通である。冗長性の主張を行う顧客にとっては、容易な外部クロスチェックが一つ取り除かれる。彼らは、実際のアップストリーム契約、回線多様性、現在の経路ポリシーを示すプロバイダーの文書を要求するべきである。

BGP それ自体は到達可能性プロトコルに過ぎない。RFC 4271は、BGP が自律システム間でネットワーク到達可能性情報を交換する方法を説明している。アドレス背後のサーバーが健全か、バックアップが完了したか、ディスクアレイがリビルド中か、保守ウィンドウが通知されたか、あるいは顧客が午前 3 時に復旧を受けられるかどうかは検査しない。したがって、Cloud Provider USA のルーティング面は下限であり、上限ではない。同社をインフラの会話に留めておくには十分な証拠である。現在のサービス証拠なしにプラットフォームに依存するには十分ではない。

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

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

第一の問いは、復旧容量がどこに存在するかである。Itrica の各ページは、米国、欧州、日本にわたる複数のデータセンター所在地に言及している。顧客は、それらの所在地のうち、もしあれば、自らのサービスオーダーに割り当てられているのはどれかを知る必要がある。マサチューセッツ州の本番用 VM と同じ都市圏内のバックアップコピーは、オペレータのエラーや単一サーバーの喪失には十分かもしれないが、地理的な災害復旧と同じではない。ラスベガスのバックアップは、レプリケーションが最新で、アプリケーションがそこで実行可能で、ネットワーク経路が切り替え可能で、ライセンスが許容し、顧客がランブックをテスト済みである場合に限り、地域的な電力や建物の問題を解決する可能性がある。欧州や日本のコピーは継続性を改善するかもしれないが、レイテンシ、管轄、プライバシー、サポート時間帯に関する問題を提起する。

第二の問いは、復旧の優先順位がどのように割り当てられるかである。広範な停止時には、すべての顧客が最初に復旧したいと望む。プロバイダーに一部の顧客向けにサイズ設定された予備のコンピュートがある場合、「DRaaS」は予約ポリシーに依存する。専用の復旧容量は、部分的にアイドル状態になるため高価である。共有の復旧容量は安価だが、オーバーサブスクライブされる可能性がある。Cloud Provider USA の公開資料は予約比率を開示していない。バイヤーは、復旧用のコンピュート、ストレージ IOPS、公開 IP 割り当て、VPN 容量、サポート労働力が、専用か、共有か、ベストエフォートかを問いただすべきである。

第三の問いは、バックアップがアプリケーション整合性を保っているかどうかである。ファイルコピーやボリュームスナップショットは、データベース、アイデンティティサービス、メッセージキュー、ライセンスサーバー、外部依存関係が順序通りに復旧されない場合、技術的には成功してもビジネスにとっては失敗に終わる可能性がある。Itrica の現在のコピーはマネージドサポートとコンプライアンス文書を強調しており、これは有用なシグナルである。しかし、バイヤーは復旧の記録を必要とする。すなわち、最後のテストの日付、テストの範囲、データの古さ、実際の復旧時間、例外、責任担当者、アプリケーション所有者の承認の有無である。NIST の緊急時対応計画の指針は、復旧を単なるストレージ機能としてではなく、計画されテストされた能力として扱っているため、関連性がある。

第四の問いは、退出時や緊急時にエグレスが本当に予測可能なままかどうかである。Itrica はホームページで「No Egress Fees. Ever.」と述べ、一部のホスティングサービスでは固定費の運用コストモデルを説明している。これは、データ転送料金が緊急時の移行を高額にする可能性があるハイパースケールパブリッククラウドに対する意味のある優位性になりうる。しかし、「エグレス料金無し」はサービスオーダーの文言と結びつけられるべきである。顧客は、このフレーズがあらゆるバックアップエクスポート、全リージョン、全緊急移行、全クロスコネクト転送、全サードパーティキャリア、全物理メディアオプション、全契約終了後のデータ取得に適用されるかどうかを問いただすべきである。無料の転送がレート制限されていたり、サポートの可用性によって遅延したり、独自のバックアップフォーマットによってブロックされたりする場合、それは依然として可搬性のリスクである。

第五の問いは、誰がその作業を行うのかである。マネージドプロバイダーは、熟練したスタッフが顧客のスタックを熟知している場合、セルフサービスプラットフォームよりも耐障害性が高くなりうる。また、重要な知識が少数のチームに集中している場合、より脆弱にもなりうる。Cloud Provider USA の古い契約は、ユーザーインターフェイス、資格情報、サービス設定、サポート責任に関して CPU に広範な権利を与えており、Itrica の現在のページは社内の専門家とホワイトグローブサービスを強調している。チームが到達可能で最新の状態であれば魅力的である。長時間のインシデント発生中に顧客がエスカレーションを得られなければ危険である。復旧の証拠には、単なるサポートメールアドレスではなく、指名されたエスカレーションの役割が含まれるべきである。

したがって、バックアップと災害復旧は単純な可否の機能ではない。それらは容量の予約、スクリプト、人、データフォーマット、ネットワーク経路、契約である。Cloud Provider USA の公開記録は、質問をすることを支持している。それ自体で質問に答えるものではない。

契約は複数の障害経路を明らかにする

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

第二の障害経路はサービス変更である。契約は、クライアントサービスが、権限を与えられた人物が CPU ユーザーインターフェイスを通じて設定を調整することを許可する可能性があり、クライアントがユーザー名とパスワードに責任を負うと述べている。また、CPU の重大な過失または故意の違法行為の場合を除き、CPU は当該インターフェイスまたは資格情報の使用について一切の責任を負わないとも述べている。これにより、アクセス制御の衛生状態が信頼性モデルに組み込まれる。侵害された管理者アカウントは、コスト、構成、可用性の損害をもたらしうる。失われた管理者アカウントは復旧を遅らせる可能性がある。顧客は、現在のプラットフォームが多要素認証、役割分離、変更承認、アクセスログ、緊急ロックアウト、委任された復旧連絡先をサポートしているかどうかを知るべきである。

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

第四の障害経路は法的責任とコンテンツである。契約は、クライアントが利用規定ポリシーに違反した場合、または CPU を法的責任にさらす可能性のあるコンテンツをホストし続けた場合、CPU は直ちにサービスを解除または停止することができると述べている。これはどのインフラプロバイダーにとっても理解できることだが、運用上の結果を伴う。機密性の高い、ユーザー生成の、規制対象の、または国境を越えた素材をホストしている顧客は、停止前のエスカレーションプロセスを知っておくべきである。誰が通知を受け取るのか？どのような証拠が必要か？紛争中のコンテンツは環境全体を停止させることなく隔離できるか？治癒期間はあるか？バックアップは依然としてアクセス可能か？これらの質問が重要なのは、法的手続きや不正使用の手続きが、エンドユーザーにとっては技術的な障害のように見える停止を引き起こす可能性があるからだ。

第五の障害経路は顧客財産である。CPU 施設に所在する財産に関する契約の文言は、一部の顧客がプロバイダーの管理する空間に物理的に存在する資産を有している可能性があることを示唆している。もしそうであれば、移行は単なるデータエクスポートではない。配送、リモートハンズ、国際移動のための通関、ライセンス移転、安全な消去、機器の撤去、保管記録の連鎖を必要とするかもしれない。顧客は、「クラウド」が自分たちが回収すべきものは何もないことを意味すると思い込むべきではない。彼らはハードウェアの所有権、メディアの返却、安全な廃棄の条件についてサービスオーダーを読むべきである。

第六の障害経路は不可抗力である。契約は、天候、政府の制限、テロ、戦争、暴動、その他制御を超えた壊滅的な事象に関する慣習的な条項を含んでおり、遅延が一定期間を超えた場合の解除権を定めている。ここが物理的な世界がクラウド契約に再び入り込む場所である。施設の電力、地域的な天候、キャリアの停止、政府命令、国境管理が問題になりうる。顧客がクリティカルなワークロードのために 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 テナントである。バックアップサービス（BaaS）を利用している顧客にとっては、停止は復旧が必要になるまで見えない可能性があり、これはさらに悪い。バックアッププラットフォームは、ランサムウェアイベント、管理者の誤り、ストレージの喪失によってそれが不可欠になる瞬間まで、何ヶ月も静かに見える可能性がある。災害復旧（DRaaS）の場合、影響を受けるグループはさらに広範である。なぜなら、障害はしばしばすでにストレスを受けているビジネスイベントと同時に発生するからである。

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

ラックや電力の障害は、クラスタリングに応じてワークロードに異なる影響を与える。単一の物理ホストは、ライブマイグレーションがない場合や共有ストレージが利用できない場合、複数の仮想マシンを停止させうる。ToR（トップオブラック）スイッチは多くのサーバーを隔離しうる。ストレージシェルフは、コンピュートが健全であっても、多くのワークロードを劣化させうる。電力障害は UPS と発電機によって隠蔽されうるが、それは燃料、切替スイッチ、保守、負荷容量が実際の条件下で機能する場合に限られる。冗長電源と冷却が存在すると述べる公開ページは出発点である。顧客は、自分の正確なサービスが冗長ホスト、冗長ストレージコントローラー、独立した電力供給、テストされた復旧グループを使用しているかどうかを知る必要がある。

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

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

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

運用証拠のグレード

公開記録は、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、ストレージはどれほど確保されているか？ストレージのリビルドはどのように監視されているか？バックアップは本番環境の認証情報から隔離されているか？復旧テストはアプリケーション整合性を保っているか？テストされた最大の復旧は何か？それにかかった時間は？合意された復旧ポイント目標（RPO）と復旧時間目標（RTO）は何か？複数の顧客が同時に災害を宣言したらどうなるか？

サポートに関する質問は運用上であるべきである。緊急時の電話番号は何か？時間外に誰が応答するのか？最初の対応者が修理できない場合のエスカレーションパスは？指名された技術アカウント責任者はいるか？変更はログに記録され承認されているか？顧客は読み取り専用の監視可視性を持っているか？インシデント通知はメールのみで送られてくるのか、それとも電話、SMS、チケットシステム、顧客ポータルでも送られてくるのか？ポータルが利用できない場合、顧客はどのようにサポートに連絡するのか？

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

これらの質問は、Cloud Provider USA が弱いと仮定しているわけではない。ホスト型インフラが真のインフラであると仮定している。公開記録は、稼働中の IPv4 ネットワーク、マネージドサービスの歴史、Itrica に接続された現在の運用コンテキストを持つプロバイダーを示している。また、「クラウド」という言葉に証拠の作業をさせてはならないほどの不透明さも示している。この場合、信頼性はスローガンではない。それは、次の修理ウィンドウが始まる前に可視化される必要がある、ラック、経路、電力経路、復旧テスト、サポートコミットメント、請求管理、退出権の一式なのである。