概況

  • Outofbox Cloud の現在の公開ルート: AS147192 は103.174.148.0/23を発信し、2026年7月15日の観測では326の RIPE RIS IPv4 ピアのうち325に可視であった。
  • 物理的証拠はベラガヴィのサダシブ・ナガルに集中している。2020年の地元報道では100台以上のサーバーが設置され、約300台の収容が可能とされ、2025年9月の大学訪問では同じ場所でラック、冷却、バックアップ電源が確認された。どちらの情報源も、現在の通電、使用可能、または予備容量を証明するものではない。
  • 同社の8つのデータセンターリージョンという主張には、公開製品ページにおいて8つの都市名、施設運営者、電源設計、容量数値、リージョン別のステータス履歴は付随していない。また、同社の利用規約は、別途99.99%の SLA を主張しているにもかかわらず、中断のない、またはエラーのない運用を否認している。
  • AS147192 には1つの観測された隣接 AS、法的に別個の Outofbox Networks Private Limited に登録された AS141815 がある。そのネットワークはより広範なアップストリームおよびエクスチェンジ接続を持つが、最初のホップを超えた論理的なルート多様性は、Outofbox Cloud の多様なファイバー入口、導管、建物、ユーティリティ供給、障害ドメインを確立するものではない。

8つのリージョンが宣伝されているが、1つの拠点のみが立証されている

Outofbox Cloud の製品サイトで最も重要な文は、小さな仮想マシンの価格ではない。それは、同社のBoxes ページで、顧客が8つのデータセンターリージョンにデプロイできるという主張である。同じページでは、「グローバルアベイラビリティ」というマーケティングフレーズを使用し、55秒の起動時間と99.99%のアップタイム SLA を宣伝している。これらは測定可能な提案であるが、グローバルな運用フットプリントの証拠ではない。それらは、ウェブストアフロント以上のものを暗示する。注文を受け入れるのに十分なインストール済みコンピューティング、ストレージ、アドレス容量、ワークロードを配置できるコントロールプレーン、通電された施設、ルーティングされたパス、サポートスタッフ、そして「リージョン」という言葉が通常のインフラの意味で使用されている場合、地理的に区別可能な運用場所である。

公開証拠では、読者がそのような8つの場所を列挙することはできない。主張に8つの都市リストは付随していない。ページには、施設所有者、コロケーション・パートナー、ユーティリティ供給、ラック数、電力エンベロープ、認証、試運転日、リージョンステータスエンドポイントは記載されていない。顧客はアカウント作成後により詳細な情報を得られる可能性があり、プライベート契約に含まれている可能性がある。それでも、公開された主張は、8つの独立して運用可能な施設が存在すること、すべてがデプロイを受け入れていること、またはワークロードがそれらの間でフェイルオーバーできることの証明として扱われるべきではない。

立証できるのは、実際の運用シグナルを持つより小さいフットプリントである。BTW ディレクトリエントリは、このプロフィールの対象となる会社を特定している。APNIC レコードは、その会社を自律システムとポータブル IPv4 割り当てに関連付けている。会社のウェブサイトとレジストリ連絡先は、カルナータカ州ベラガヴィのサダシブ・ナガルを指している。独立した地元の資料には、そこでのサーバー、ラック、冷却、バックアップ電源が記載されている。観測時には、会社のウェブおよび顧客管理ドメイン名も、その割り当てられた IPv4 ブロック内のアドレスに解決された。DNS 観測はアドレスの関連付けのみを確立する。物理的およびルーティングの証拠は、別々に考慮すると、実際のローカル運用を支持する。そのどれもが8サイトのマップを支持するものではない。

この区別は衒学的ではない。リージョナルプロバイダーを選ぶ顧客は、ローカルサポート、インドのデータレジデンシー、カルナータカ州からの低レイテンシーアクセスを合理的に重視するかもしれない。これらの利点は、プラットフォームが1つの都市に集中していても十分に大きい。リスクは、コンパクトなローカルプラットフォームが、読者がハイパースケールの地理として解釈する可能性のある言語で販売されたときに現れる。正しい評価は、「インフラは存在しない」でも「8つのリージョンが証明された」でもない。ベラガヴィのフットプリントは裏付けられているが、それを超えた地理は公開証拠では不明のままである。

会社、以前のブランド、ネットワーク事業者は互換性がない

OUTOFBOX CLOUD PRIVATE LIMITED はインドの非公開会社である。IndiaFilingsが公開する現在の MCA 由来の会社記録は、会社識別番号 U72900KA2021PTC149665、2021年7月19日の設立日、2025年11月の更新時点でのアクティブな提出状況、登録事務所をベラガヴィのサダシブ・ナガルの Oneness4 階としている。取締役として Ajit Kumar S Patil と Gowdesh Singangouda Patil を挙げている。このページはレジストリ情報を再公開しているのであり、レジストリ自体ではないため、重要な契約の前に、正確な現在の提出状態を企業省のマスターデータと確認すべきである。

Outofbox Cloud ブランドはその会社よりも古い。保存された2020年2月の地元報道は、OutofBox.cloud をベラガヴィから開始されたサービスとして説明し、FAAST Networks の完全所有子会社と呼んでいた。サービスはカスタマイズされた OpenStack 環境で動作し、当時100台以上のサーバーがあり、約300台の物理サーバーを収容できると述べられていた。また、そのサイトをブランドの最初のデータセンターとも説明していた。これらの記述は2020年の運用と、OUTOFBOX CLOUD PRIVATE LIMITED が2021年7月に設立される前のブランド関係に関するものである。これらは有用な歴史であるが、現在の所有権証明書ではない。

2番目の法人はネットワークストーリーにとって重要である。APNIC は AS141815 をOutofbox Networks Private Limitedに登録し、AS147192 は Outofbox Cloud に属する。レコードは同じサダシブ・ナガルの住所と同じ電話番号を使用しているが、異なるネットワーク連絡先メールドメインを使用している。企業データソースは取締役の重複を示しており、2020年の報道はグループ関係を説明している。それでも、2つの非公開会社は2つの法人である。ネットワーク会社の通信認可、契約、回線、アドレススペースは、自動的にクラウド会社の資産または負債として計上することはできない。

この境界は、障害や撤退の場合に特に重要になる。顧客が Outofbox Cloud からコンピューティングを購入しても、最初に見えるネットワークパスが Outofbox Networks によって提供されている場合、顧客はどの会社がサービス契約に署名するのか、どの会社がサーバーを所有またはリースするのか、どの会社が施設リースを保有するのか、どの会社が帯域幅を請求するのか、どの会社がネットワーク運用スタッフを雇用するのか、どのエンティティが復旧責任を負うのかを知る必要がある。取締役、ブランディング、住所、電話番号の共有は調整を容易にするかもしれない。それは契約上の権利に取って代わるものではない。

現在の公開ウェブサイトは、製品とインフラの層を曖昧にすることがある。パブリッククラウド、バーチャルプライベートクラウド、プライベートクラウド、ロードバランシング、マネージド Kubernetes、プラットフォームサービス、SAP 向けホスティング、バンキングコミュニティクラウド、専用サーバー、コロケーションを宣伝している。一部は直接提供され、一部は関連インフラやサプライヤーに依存している可能性がある。公開ページはサービスごとの所有権マトリックスを公開していない。したがって、このプロフィールは製品を会社のマーケティングに、番号リソースをその登録保有者に帰属させ、すべての層が同じエンティティによって所有されているとは想定しない。

ベラガヴィで物理的に立証されているもの

最も強力な最近の物理的証拠は、マーケティングマップではない。それは、Angadi Institute of Technology and Management の人工知能・データサイエンス学科による2025年9月の記録である。学科の活動記録は、9月22日に学生がベラガヴィのサダシブ・ナガルにある Outofbox Cloud Private Limited を訪問したと述べている。仮想マシン管理、バーチャルプライベートクラウド、ファイアウォールについて説明し、その後、データセンターのセットアップにおける物理および仮想サーバー、サーバーラック、冷却、バックアップ電源、ルーター、スイッチ、ファイアウォール、ストレージシステムを特定している。学科はまた、その記録を2025-26ニュースレターにも掲載している。

これは意味のある裏付けである。この記事の執筆時点から1年以内に、名前の付けられた場所で会社に関連する機器が物理的に見える状態にあったことを示している。IP 地理位置データベースよりも位置情報として有用である。なぜなら、機関訪問はネットワークレイテンシーや登録データからの推測ではなく、実際の場所に関するものであるからだ。Belagavi Technology Companies Associationも Outofbox Cloud を地元でホストされインド拠点と説明しているが、その協会プロフィールは宣伝的であり、検証方法を開示していない。

証拠には依然として限界がある。大学の記録は、建物の正確な部屋、床面積、ラック数、ラック密度、ユーティリティサービス、UPS トポロジー、バッテリー自律時間、発電機定格、燃料持続時間、冷却能力、火災抑制、占有承認、施設運営者を明記していない。閲覧されたシステムが本番顧客ワークロードを実行していたのか、トレーニングラボとして機能していたのか、あるいは両方を混合していたのかは述べられていない。機器の所有権ラベルを特定していない。共有されたストリートアドレスは会社および番号リソース記録に管理連絡先として出現するが、管理アドレスはそれ自体では施設証明書ではない。

2020年の記事は数値を提供するが、現在の状況ではない。「100台以上のサーバー」はある時点での設置機器の主張である。「約300台の物理サーバー」は設計またはスペース容量の主張である。その時点で何ラックユニット、何電源ソケット、何キロワットが通電されていたかは明記していない。2026年に何台のサーバーが稼働中か、何台が顧客対応可能か、どの程度が予約済みか、後年の成長によりワークロードが他の場所に移動したかどうかを示すことはできない。その報告書にある「事実上無制限」の仮想マシンという表現は、宣伝用の言葉として理解されるべきである。すべての仮想マシンは最終的に有限の CPU、メモリ、ストレージ、ネットワーク、電力、冷却容量を消費する。

このプロフィールのために特定された公開記録で、同等の物理的証拠を持つ2番目の Outofbox Cloud 施設はない。公共の電力制裁、ユーティリティ接続容量、発電機承認、火災無異議証明書、建物レベルのデータセンター許可、環境提出書類で、クラウド会社の生産フロアに安全に結びつけられるものは見つからなかった。公開検索での不在は、文書または承認が存在しないことの証明ではない。それは、読者がそれを使用してサイトを定量化したり、8リージョンの主張をテストしたりできないことを意味する。

したがって、マップは控えめに描かれるべきである。ベラガヴィは裏付けられた運用拠点および登録連絡先所在地である。ムンバイは NIXI での AS141815 の論理的な交換拠点であり、Outofbox Cloud がムンバイにサーバーを所有している証拠ではない。商用 IP ロケーションツールによって返されるベンガルールやチェンナイのラベルは、測定推定値であり、施設の住所ではない。残りの宣伝されたリージョンは、会社が都市名とそれぞれの法的または運用上の根拠を公開するまで不明である。

製品カタログは在庫ではない

Outofbox Cloud の現在の価格ページは、サービスを経済的に具体的にしている。小さな2CPU、2GB メモリ、100GB NVMe プランの月額₹630から、はるかに大きなコンピューティングとメモリの組み合わせまで、構成をリストしている。Boxes ページは、汎用、CPU 最適化、メモリ最適化、ストレージ最適化インスタンスを説明し、一部のプランは専用ハイパースレッドを使用すると述べている。これらの詳細は、会社が販売を申し出ているものを示している。物理ホストの数や世代、オーバーサブスクリプションポリシー、ストレージレプリケーション、スペアパーツ在庫、プランの背後にある配置ルールを明らかにしていない。

カタログと容量の区別は、急増や障害の際に最も重要になる。適切なホストに空きメモリがない場合でも、プランは表示されたままにできる。ハードウェアのフルフィルメントが遅れている間でも、コントロールパネルは注文を受け付けることができる。名目上の専用 vCPU は、スケジューラで分離されていても、ソケット、メモリチャネル、ストレージコントローラー、トップオブラックスイッチ、電源供給を共有する可能性がある。NVMe 容量は、ホストローカル、ホスト間でレプリケート、ストレージクラスターでバックアップ、または別のバックアップサービスから復元される可能性がある。公開プランテーブルはこれらの可能性を解決していない。

ホームページは、プラットフォームに40以上のクライアントと500以上のクラウドデプロイがあると述べている。これらは、日付、定義、監査のないファーストパーティのカウンターである。「デプロイ」は、アクティブな仮想マシン、アプリケーションの起動、過去のプロビジョニングアクション、テスト環境、顧客プロジェクトの可能性がある。設置サーバーや販売容量に変換することはできない。また、512の割り当てられた IPv4 アドレスは、1アドレス1サーバーのルールを課さない。アドレスは、ハイパーバイザー、仮想マシン、ネットワークアドレス変換、ロードバランサー、ルーター、予約、顧客割り当てに使用される可能性がある。

ウェブサイトはまた、ロードバランシングを宣伝している。ロードバランサーは複数のサーバー間でリクエストを分散できるが、地理的冗長性を証明するものではない。その背後にあるサーバーは、ラック、トップオブラックスイッチ、UPS、冷却ループ、建物入口、アップストリームルーターを共有する可能性がある。同様に、バーチャルプライベートクラウドは論理的な分離を提供するが、物理的に別個のクラウドではない。プライベートクラウドの提供は、共有施設内の専用ハードウェアで実行できる。それぞれ有用であるが、それぞれ異なる障害層に対処する。

容量が意思決定グレードであるためには、プロバイダーはプランと運用エンベロープを結び付ける必要がある。リージョン別の利用可能なホストプール、CPU およびメモリ割り当てルール、ストレージ耐久性、ネットワークポートコミットメント、プロビジョニングリードタイム、メンテナンス予備、そして「利用可能」な容量が実際に通電されデプロイ可能なポイント。これらの値はどれも公開されていない。安全な結論は、特定の製品が販売され、サービスのエンドポイントが稼働している一方で、設置済みおよび利用可能な在庫は不明である。

公開ネットワークは現実的で、コンパクトで、可視である

最も明確な現在の運用証拠は AS147192 である。APNIC 自律システムレコードは、OOBCLOUD-AS-IN および OUTOFBOX CLOUD PRIVATE LIMITED を指定し、レコードをアクティブとマークし、2021年10月13日の登録日を示している。APNIC アドレスレコードは、103.174.148.0から103.174.149.255をポータブル IPv4 スペースとして会社に割り当てている。これは512アドレスを含む/23である。リソースレコードには対応する IPv6 ブロックはない。

RIPE NCC のルーティングステータス観測は、2026年7月15日に1つの発信された IPv4 プレフィックス、512アドレス、IPv6 プレフィックスなし、1つの観測された隣接 AS を発見した。ルートは326の IPv4 ピアのうち325に RIPE のルーティング情報サービスで可視であり、その時点での広範な公開ルート可視性の強力な証拠である。これは到達可能性の証拠であり、グローバルな運用フットプリントではない。アナウンスされたプレフィックスの結果は、1日から15日の観測ウィンドウで103.174.148.0/23が継続的に表示されることを示している。

可視性には履歴があり、1日のアーティファクトではない。RIPE のルーティング履歴は、AS147192 が/23を2021年11月から現在のクエリウィンドウまで発信していることを示しており、コレクターシステムのサンプリングと可視性のしきい値の影響を受ける。ルートオリジン検証結果は有効で、AS147192 が/23および/24までのプレフィックスを発信することを許可するルートオリジン認証があった。RPKI の有効性は、あるクラスのオリジンエラーを減らす。それはアップタイム、容量、パスの多様性、または許可されたオペレーターのミスに対する保護を提供しない。

観測時には、会社の公開ウェブサイトと顧客管理ホスト名の A レコードは、OUTOFBOX CLOUD PRIVATE LIMITED に割り当てられた/23内のアドレスを指していた。メインサイトは103.174.148.253、mycloud.outofbox.cloud は103.174.148.14。これは、それらのドメイン名とその割り当てられた範囲との間の時点での関連付けのみを確立する。応答するサーバーやアプリケーションの所有者や運営者、それらが物理的にどこでホストされていたか、どちらかのアドレスがエニーキャストであったか、どちらかのホスト名が本番コントロールプレーンの一部であったか、またはどちらかのサービスが顧客ワークロードと障害ドメインを共有していたかは確立しない。

PeeringDB のAS147192 プロフィールは、文書化されていない点で主に有益である。自己報告されたエントリは、アジア太平洋スコープ、100-1000 Mbps のトラフィック帯域、512の IPv4 アドレスを説明している。0の公開エクスチェンジ接続と0の施設をリストし、2022年10月以降実質的に更新されていない。PeeringDB は任意である。ゼロフィールドは、物理的な不在ではなく、非開示または古い情報を意味する可能性がある。それでも、8つのリージョンを実証するために使用することはできない。

したがって、ネットワークは本物でありかつコンパクトである。安定したルート、有効なオリジン認証、稼働中のサービスエンドポイントを持っている。しかし、公開発信サーフェス全体は1つの IPv4 ブロックであり、可視の IPv6 アナウンスはなく、1つの直接観測された隣接 AS しかない。ルート証拠は、ウェブサイト単独よりも強力に運用ステータスを支持する。また、検討に値する狭い論理的依存関係を定義する。

1つの直接隣接、その後より広いネットワーク

RIPE のAS147192 隣接観測は、収集されたパスの左側に AS141815 のみを特定する。2番目のコレクターベースのレポートも同じ基本トポロジーに達する。これは、物理的な回線が1つだけであることを証明するものではない。プライベートリンク、バックアップセッション、ポリシーによって隠されたルート、コレクターの可視性が低すぎる接続は表示されない可能性がある。それが証明するのは、調査されたコレクターが利用できる公開ルートが独立した最初のホップの多様性を示さなかったことである。

AS141815 は Outofbox Networks Private Limited に登録されている。インド電気通信省の2026年の ISP 認可リストは、その会社を、Outofbox Cloud Private Limited ではなく、カルナータカ州のカテゴリーB 認可とともに、同じサダシブ・ナガルの住所でリストしている。これは貴重な法的区別である。ネットワーク会社は開示された ISP 認可を保持し、クラウド会社は可視のクラウド ASN とアドレスブロックを所有する。公開記録は、トランジットまたは施設が供給される際のインターカンパニー契約を示していない。

その最初の隣接を超えて、AS141815 はより多くのルートオプションを持っている。RIPE の現在の隣接結果は、4つの観測された隣接を示している。AS45117、AS9730、AS137085、そしてクラウド会社の AS147192。そのルーティングステータスは、4つの発信された IPv4 /24と可視の IPv6 なしを示している。PeeringDB は、AS141815 に対してNIXI ムンバイでの運用中の1 Gbps 接続をリストしている。AS141815 を超える複数の外部 AS 隣接の存在は、アップストリームルーティング障害からのルート選択と復旧を改善する可能性がある。

それでも、クラウドの物理的冗長性を証明するものではない。2つのアップストリーム ASN は、1本のケーブル、1つのキャリアハンドオフ、1つの街路トレンチ、1つの建物入口、または1つのルーター内のファイバーを経由して到着する可能性がある。ムンバイのインターネットエクスチェンジポートは、ベラガヴィからの単一のバックホールを介して到達される可能性がある。クラウド ASN は、1つのクロスコネクトまたは1つのデバイスを介してネットワーク ASN に接続する可能性がある。公開情報源は、回路プロバイダー、ハンドオフ場所、ルートリフレクター、エッジルーターペア、ファイバー入口、導管経路、保護スイッチング、コミッティドレート、フェイルオーバーテスト結果を特定していない。

論理的および物理的多様性の区別は、地理にも適用される。NIXI ムンバイは AS141815 がポートを持つ交換ポイントであり、Outofbox Cloud がムンバイでコンピューティングまたはストレージを運用している証拠ではない。ルートはムンバイを通過する可能性があるが、ワークロードはベラガヴィに残る。逆に、プロバイダーは AS147192 からアナウンスせずに他の場所でコンピューティングをリースする可能性がある。ネットワークマップと AS パスはパケットの到達可能性を示し、サーバーの所有権ではない。

顧客にとって、有用な質問は単に「アップストリームはいくつか？」ではない。それは「どの障害がこの特定のワークロードへのアクセスを除去するか？」である。それに答えるには、仮想マシンのホストとトップオブラックスイッチから、施設エッジ、クラウドネットワークハンドオフ、長距離回線、アップストリームプロバイダーを通るパスが必要である。公開ルーティングはそのチェーンの AS レベルの中央を明らかにする。ラックレベルおよび土木工学の末端は不明のままである。

過去の容量を現在の使用可能容量に昇格させることはできない

2020年の100台以上のサーバーという数字は、このプロフィールのために見つかった唯一の公開設置機器数である。同じ報告書の「約300」という数字は、最初のデータセンターがホストできる物理サーバーの数を説明している。両方が公開時に正確であったとしても、異なる状態を表している。設置機器は設計スペースではない。通電された機器は必ずしも運用可能ではない。運用可能な機器は必ずしも新規顧客が利用できるわけではない。利用可能な機器はすでに予約されているか、ワークロードの CPU、メモリ、ストレージ、ネットワークの組み合わせを満たさない可能性がある。

2026年の情報源で現在のサーバー数を述べているものはない。メガワット、キロワット、ラック数、ラック密度、ユーティリティ割り当てを提供する情報源はない。UPS モジュール、発電機容量、バッテリー持続時間、ディーゼル貯蔵、冷却冗長性、電力使用効率、火災抑制を定量化する情報源はない。N、N+1、2N、または分散冗長設計を特定する情報源はない。2025年の学生訪問は、冷却とバックアップ電源ソリューションが存在することを確認しているが、その容量、メンテナンス状態、または長期のユーティリティ障害時に完全な本番負荷を支える能力を特定していない。

ウェブサイトの「8つのデータセンターリージョン」にも容量の分母がない。リージョンは、完全な会社運営施設、リースされたラック、別のクラウドからレンタルされた容量、エッジサイト、計画中の場所、またはコントロールパネルの選択可能なラベルを意味する可能性がある。これらの取り決めは異なる義務と障害モードを生み出す。リージョン名と事業者開示がなければ、設置容量を会社に帰属させたり、顧客データの場所を確立したりすることはできない。

アドレススペースも同様に過大評価されやすい。/23は組織に512の IPv4 アドレスを与えるが、512台のサーバーではない。1台のサーバーは、少数のパブリックアドレスの背後で多くのプライベートアドレス仮想マシンをホストできる。顧客は複数のパブリックアドレスを受け取ることができる。一部のアドレスは、ネットワーク、ブロードキャスト、ゲートウェイ、管理、予約、アンチアビューズ機能によって消費される。IPv4 カウントは、特定のパブリックアドレス製品の有用な上限入力であるが、コンピューティング、ストレージ、電力、顧客数ではない。

宣伝された構成も在庫シグナルを提供しない。オンラインで表示される32コアプランはオファーであり、一致するホストが空いていることの証明ではない。会社はプールされたスケジューラーを運用したり、手動でプロビジョニングしたり、スペアハードウェアを維持したり、パートナーから容量を購入したりする可能性がある。公開ページは何も述べていない。利用規約はフルフィルメント期限を公開していない。見込み購入者は、選択したリージョンと構成について、リソースが設置、通電、テスト済み、即時割り当て可能かどうかを含む、日付入りの容量確認を求めるべきである。

したがって、防御可能な容量の調査結果は狭い。歴史的な設置容量: 2020年に報告され、独立して監査されていない100台以上のサーバー。歴史的な設計容量: 最初のベラガヴィサイトでの約300台の物理サーバー、2020年に報告。現在の物理的存在: 2025年の教育訪問で観察されたラック、サーバー、冷却、バックアップ電源。現在の設置、通電、使用可能、販売済み、予約済み、予備容量: 不明。

99.99%のバッジには時計、範囲、救済手段が必要

Boxes ページは99.99%のアップタイム SLA を宣伝している。除外なしで365日の年で測定した場合、0.01%のダウンタイムは約52.6分に相当する。月次で測定した場合、30日の月で約4.4分である。実際のサービスレベル契約は、測定期間、測定対象、利用不可と見なされるもの、メンテナンス除外、顧客責任、請求期間、サービス残高を定義する。これらの条件なしにパーセンテージは、ホスト、ストレージ、ネットワーク、またはコントロールプレーンの障害に対して顧客に何の救済手段があるかを伝えることはできない。

会社の公開利用規約は追加の不確実性を生み出す。会社は可用性とセキュリティに努めるが、中断のないまたはエラーなしの運用を保証せず、サービスを使用できないことに対する責任を否認すると述べている。別の署名済みサービスオーダーがこれらのウェブサイトの条件を無効にしたり補足したりする可能性がある。公開された SLA スケジュール、クレジットテーブル、ステータス履歴アーカイブは、マーケティングのパーセンテージと免責事項を調整するために見つからなかった。

範囲が重要である。コンピューティングアップタイムは顧客のオペレーティングシステムを除外できる。ホストアップタイムは到達不可能なネットワークと共存できる。ネットワークアップタイムはストレージの破損と共存できる。リージョナル SLA は同時マルチリージョン障害を除外できるが、1つのリージョンにのみデプロイされた仮想マシンには地理的な復旧手段がない。バックアップの成功は復元の成功ではない。サポートの可用性は復元時間を保証しない。

Outofbox Cloud の場合、SLA の問題はネットワークと施設の証拠に直接結びついている。99.99%は個々の Box、ハイパーバイザープール、最初のネットワークホップ、コントロールパネル、ストレージ、またはそれらのすべてに適用されるのか？外部プローブから測定されるのか？8つのリージョンは別々の SLA スコープか？AS141815 の障害はカウントされるのか？ベラガヴィ施設での計画メンテナンスはカウントされるのか？どのようなクレジットが利用可能で、顧客の唯一の救済手段はクレジットか？契約がそれらの質問に答えるまで、バッジはマーケティングの主張であり、定量化された復旧保証ではない。

サービスがどのように失敗するか

最初の障害パスは施設電力である。ユーティリティの中断は、重要な負荷を UPS に、その後発電または別の供給に転送するべきである。2025年の訪問はバックアップ電源の存在を支持するが、公開情報源は自律時間または冗長性を述べていない。発電機は始動に失敗したり、燃料切れになったり、過熱したり、負荷の一部しかサポートしたりする可能性がある。バッテリーは劣化する可能性がある。開閉装置は共通の障害点を作り出す可能性がある。サイトに1つのユーティリティ供給または1つの分配経路しかない場合、個々のサーバーがデュアル電源を持っていても、複数のデバイスが同時に暗くなる可能性がある。

2番目のパスは冷却である。サーバーは電気的電力を維持しながら、熱制限がシャットダウンまたはスロットルを強制する可能性がある。コンパクトな施設には、部屋の名目面積だけでなく、実際のラック密度に対して十分な冷却が必要である。冗長空調ユニットでも、制御、復水器、ポンプ、電力を共有する可能性がある。教育訪問は冷却機器を確認するが、能力、冗長性、メンテナンスは確認していない。顧客は冷却ユニットの存在から熱的復元力を推測することはできない。

3番目のパスはネットワークアクセスである。AS147192 の1つの公に見える隣接 AS は、クラウドのルートが AS141815 を通じて観測されたインターネットに到達することを意味する。AS141815 を超える2番目のアップストリームは、1つのプロバイダールートが失敗した場合に役立つが、クラウドからネットワークへのハンドオフ、共有エッジルーター、ベラガヴィバックホール、または建物入口が失敗した場合には役立たない。ルートオリジン認証はオリジンの正当性を保護するが、可用性は保護しない。有効なルートでも、引き出されたり、フィルタリングされたり、到達不能になったりする可能性がある。

4番目のパスは管理アクセスであり、そのアーキテクチャは不明である。観測中、ウェブサイトと顧客管理ドメイン名は会社の割り当てられた/23内のアドレスを指していたが、その事実はサーバーやアプリケーションの所有権、物理的ホスティング、本番コントロールプレーンの役割、または顧客ワークロードとの同時障害を特定しない。DNS、認証、請求、サポートは、実際のアーキテクチャがそうする場合にのみ可用性の依存関係になる。顧客はアーキテクチャの説明とテスト済みのアウトオブバンド手順を必要とするが、公開記録はどちらも提供していない。

5番目のパスはストレージである。価格ページは NVMe 容量と、一部のウェブホスティングスタイルのプランでの毎週のバックアップを宣伝しているが、Boxes のレプリケーションを説明していない。ローカル NVMe は優れたパフォーマンスを提供する一方で、データが他の場所にレプリケートされない限り、仮想マシンをホストレベルの障害にさらす。レプリケートされたストレージクラスターは、ドライブまたはノードの障害を生き残ることができるが、必ずしも建物の停電やオペレータエラーではない。毎週のバックアップは、成功し、分離され、保持され、復元可能である場合にのみ、復旧ポイントの露出を制限する。サイトは復元テストやバックアップ場所の詳細を公開していない。

6番目のパスはハードウェア在庫である。小規模な地域プロバイダーは、親密なサポートと魅力的な価格を提供できるが、交換時間はスペアドライブ、電源、メモリ、ネットワークカード、スイッチ、完全なホストに依存する。会社は部品在庫やベンダーサポートを公開していない。故障したコンポーネントは、スペアがオンサイトにあれば数分で交換されるかもしれないし、調達しなければならない場合は数日かかるかもしれない。プランテーブルで宣伝された容量は修理在庫を確立しない。

7番目のパスは人とエスカレーションである。サイトは24時間365日の監視とサポートを宣伝しているが、公開利用規約は応答または復旧目標を定義していない。実際のエスカレーションチェーンには、認識されたインシデント、技術オーナー、コミュニケーションケイデンス、ワークロードを移動したり機器を交換したりする権限が必要である。オンコールチームの規模、ネットワーク運用の分離、アクセス制御モデル、時間外の施設アクセスは不明である。ホームページのカスタマーテストモニアルは有用な市場シグナルであるが、会社によって選択されており、インシデント統計に代わるものではない。

8番目のパスは請求または契約の失敗である。技術的に健全な仮想マシンでも、アカウントが停止されたり、支払いが紛争になったり、虐待の申し立てが誤って処理されたり、供給エンティティが条件を変更したりすると、利用できなくなる可能性がある。ウェブサイトの条件は広範な裁量を留保し、保証を制限する。顧客は通知期間、紛争エスカレーション、データエクスポート権利、定義された猶予期間を必要とする。規制対象または重要な顧客は、サブコントラクターとデータにアクセスできる法的エンティティについての明確さも必要である。

9番目のパスは移行である。仮想マシンを迅速に起動できる能力は、迅速に離脱できる能力と同じではない。イメージは、独自のネットワーキング、マネージドデータベース、オブジェクトストレージ、スナップショット、またはアイデンティティサービスに依存する可能性がある。大規模なデータセットは、エクスポートに時間と帯域幅を要する。出力課金、イメージ形式、API 互換性、削除確認は公開で説明されていない。テスト済みのエクスポートがなければ、顧客はインシデント中にプラットフォームとそのサポートチームの両方に依存したままになる。

10番目のパスは相関地理である。立証されたサーバー、コントロールプレーン、クラウドネットワークハンドオフ、スタッフがサダシブ・ナガルに集中している場合、1つの建物規模のイベントがそれらすべてに同時に影響を与える可能性がある。サイトは8つのリージョンを主張しているが、公開情報源は顧客が2つの名前のある施設を選択し、それらが別々の事業者、電力網、洪水地帯、バックホールルート、コントロールプレーンを持つことを検証することを許可していない。1つの部屋の中でのマルチサーバー配置は有用な可用性エンジニアリングであるが、地理的災害復旧ではない。

これらはシナリオであり、それらのいずれかが発生したという主張ではない。それらは、現在のルートと写真に撮られたラックが復元力にとって必要であるが不十分な証拠である理由を示している。信頼性は、層がどのように接続されているか、そしてプロバイダーが障害下で何をテストしたかに依存する。

銀行用語はより高いデューデリジェンス基準を引き上げる

Outofbox Cloud はバンキングコミュニティクラウドを宣伝し、そのプラットフォームはコンプライアンスに敏感なワークロードに適していると述べている。その言葉は、銀行がサービスを使用していることや、プラットフォームが特定の監査に合格したことを証明するものではない。それは、欠けている詳細をより重要にする。規制対象の金融機関は、銀行向けに販売されているサービスを購入するだけで、責任を外部委託することはできない。

インド準備銀行の2023年の IT サービスアウトソーシングに関する指示は、クラウドコンピューティングとデータセンターサービスを明示的に含んでいる。対象となる規制対象エンティティは、デューデリジェンスを実施し、サプライチェーンの依存関係をマッピングし、サービスレベルを監視し、事業継続および災害復旧の取り決めを維持し、監査およびアクセス権を保持し、撤退を計画することを要求している。クラウド付録は、クラウドホスト型サービスのデータライフサイクルと移動に対処している。これらの義務は主に規制対象の顧客にあるが、プロバイダーは顧客が必要とする証拠と契約上の権利を提供できなければならない。

CERT-In の2022年のサイバーセキュリティ指示は、サービスプロバイダー、データセンター、VPS プロバイダー、クラウドプロバイダーに運用上の義務を課している。それらには、時刻同期、特定のインシデントの6時間以内の報告、インド国内での180日間のログ保存要件、キャンセルまたは撤回後5年間の指定された顧客登録情報の保持が含まれる。このプロフィールは、Outofbox Cloud からの公開コンプライアンス証明を見つけなかった。その不在は非準拠を証明するものではない。これらの管理は内部である可能性がある。顧客は、それらの義務がどのように実装され、プライバシー、アクセス制御、削除のコミットメントとどのように相互作用するかを尋ねるべきである。

会社のプライバシーページは、これらのエンタープライズの質問に答えていない。コメント、クッキー、メディア、ユーザープロフィールに関する明らかに一般的な WordPress の「推奨テキスト」が含まれている。法人名、データセンターリージョン、サブプロセッサー、クラウドサービステレメトリー、保存スケジュール、セキュリティ連絡先、顧客ワークロードの取り扱い、越境移転を特定していない。署名されたデータ処理契約がそれらの詳細を提供する可能性があるが、公開ページはクラウド固有のプライバシーステートメントとして扱われるべきではない。

銀行または他の重要な顧客にとって、実用的な要求はエビデンスパックである。名前のあるサイトと運営者、サブコントラクター、データの場所と移動ルール、セキュリティ認証と範囲、ペネトレーションテストと監査の要約、インシデント履歴、バックアップと復元テスト、復旧時間と復旧ポイントのコミットメント、電力とネットワークトポロジー、スタッフアクセス制御、キー管理、削除の証拠、撤退のランブック。プロバイダーのコンパクトなローカルフットプリントは、レジデンシーとサポートにとって利点となり得るが、それは顧客がデータとコピーが実際にどこにあるかを検証できる場合に限られる。

データローカリティは国レベルで支持されるが、8リージョンの解像度ではない

証拠は Outofbox Cloud をインドに強く関連付けている。会社はカルナータカ州に登録されている。APNIC はその番号リソースをインドにマークしている。物理的報告はベラガヴィを指している。関連ネットワーク会社はカルナータカ州の ISP 認可を保持している。公開ルートとサービスエンドポイントはアクティブである。これらの事実は、インド中心の運用アイデンティティを支持する。

それらはすべてのワークロードの場所を確立するものではない。IP 登録国はサーバー座標ではない。顧客は、プロバイダーが所有するハードウェア、リースされたラック、パートナー容量、または別のクラウドに配置される可能性がある。バックアップは他の場所に存在する可能性がある。宣伝された8つのリージョンは名前がない。製品ページの「グローバル」という言葉は、データセンターの地理ではなく、販売範囲またはインターネット到達可能性を説明することができる。

これは、データ主権とレイテンシーにとって重要である。カルナータカ州内のレジデンシーを求める顧客は、会社の住所に依存するのではなく、都市と施設境界を指定する契約を取得すべきである。インド国内のレジデンシーを求める顧客は、一次データ、レプリカ、スナップショット、ログ、サポートアクセスを特定すべきである。地理的復旧を求める顧客は、2番目のサイトを特定し、そこで復元をテストすべきである。1つの拠点を確立する証拠は、8つの拠点の証拠に拡張することはできない。

主張をインフラ証拠に変えるもの

Outofbox Cloud は、敏感なエンジニアリングの詳細を開示せずに、公開評価を実質的に改善できる。第一に、都市、国、立ち上げ状況、容量が会社運営かパートナー運営か、各リージョンで利用可能なサービスを含む8リージョンのリストを公開できる。計画中のリージョンは、本番ワークロードを受け入れているものから分離されるべきである。

第二に、サービスレベルスケジュールを公開できる。その文書は、測定対象、観測方法、メンテナンス除外、請求プロセス、クレジットを定義すべきである。インシデント履歴とリージョンレベルのコンポーネントを持つステータスページは、顧客がパーセンテージを運用履歴と比較することを可能にする。条件は署名された SLA によって無効にされるという声明は、現在の免責事項を調整するだろう。

第三に、ベラガヴィサイトの高レベルの復元力設計を提供できる。ユーティリティ供給の数、UPS と発電機の冗長性クラス、最小燃料自律時間、冷却冗長性、火災保護、ラックと電力エンベロープ、ネットワークエッジ設計、最後のフェイルオーバーテストの日付。正確な回路ルートとセキュリティに敏感な詳細は公開される必要はない。日付入りで独立して保証された要約は、設置、通電、使用可能な容量を区別するのに十分である。

第四に、Outofbox Networks Private Limited および FAAST Networks との境界を明確にできる。顧客は、誰がトランジットを供給するか、誰が通信認可を保持するか、誰がエッジ機器を運用するか、取り決めが関連会社の下請けであるかどうか、そしてその供給関係が変更された場合に何が起こるかを知る必要がある。ルートデータはすでに依存関係を可視にしており、契約上の開示がそれを管理可能にするだろう。

第五に、ポータビリティの詳細を公開できる。サポートされているイメージエクスポート、スナップショット形式、API ドキュメント、出力価格、帯域幅制限、削除手順、別のリージョンまたはプロバイダーへのテスト済み復元。ポータビリティは、小さなクラウドにとって二次的な機能ではない。それは復元力の一部である。なぜなら、プロバイダー、施設、または契約が障害ドメインである場合に、顧客に復旧経路を与えるからである。

最後に、容量の主張に日付を付けることができる。稼働中のホスト、販売可能なリソースプール、予約容量、メンテナンススペアのリージョン別四半期報告書は、異常に透明性が高い。粒度の低い声明でも、独立して保証され明確にラベル付けされれば、2020年の報告書の300台のサーバー設計指標が2026年の解釈を支えるままにしておくよりはましである。

運用上の結論

Outofbox Cloud は、単なる会社インデックスの名前ではない。長期間可視の自律システム、有効に認可された IPv4 オリジン、観測時にその割り当てられた/23にマッピングされた公開ドメイン名、そしてベラガヴィでの物理的クラウド機器の最近の独立した証拠がある。ローカル運用のケースは信頼できるが、DNS の関連付けはサーバーの所有権やホスティング場所を特定しない。公開ネットワークケースも明確である。AS147192 は1つの/23を発信し、1つの直接 AS 隣接、法的に別個だが密接に関連する Outofbox Networks Private Limited を通じて観測されたインターネットに到達する。

より大きな復元力の主張はまだ立証されていない。8つのデータセンターリージョンが宣伝されているが、名前は挙げられていない。99.99%の SLA が表示されているが、公開で定義されていない。歴史的報告書は設置数と設計上限を与えているが、現在の通電および使用可能容量は不明である。ラック、冷却、バックアップ電源が見られたが、そのエンジニアリングエンベロープと障害耐性は不明である。AS141815 の背後に広範な接続性が存在するが、物理的なルートと施設の多様性は不明である。

それは、実用的で公平な読み取りを残す。Outofbox Cloud は、裏付けられたベラガヴィフットプリントと運用中の公開ネットワークを持つ、インド中心の小規模プロバイダーとして評価できる。実証された地理的フェイルオーバーを持つ8リージョンのクラウドとして、公開証拠からまだ評価されるべきではない。顧客は、契約、サイトおよびアーキテクチャの証拠、容量確認、復元テスト、実際の SLA を通じてそのギャップを埋めることができる。それまでは、最も重要なインフラ事実は、Box がどれだけ速く起動できるかではない。それは、ベラガヴィ、最初のネットワークホップ、または供給会社が故障したときに、その Box を稼働し続けることができる独立して生存可能な場所の数である。