Infrazone Hosting Solution は、ラック、トランジット、修理窓口に依存するホスティング能力を販売している

要約

• Infrazone は検証可能な運用基盤を有する：APNIC は同社を AS151986 および IPv4 ブロック 43.248.56.0/23 の保有者として識別しており、一方 RIPEstat は 2026 年 7 月にこの ASN から 43.248.56.0/24 がアクティブであることを観測した。アクティブな経路は 326 の IPv4 ルートコレクターピアのうち 323 で可視であり、有効な Route Origin Authorization を保持していた。
• 可視範囲は狭い。登録された 512 の IPv4 アドレスのうち 256 のみが公にアナウンスされ、IPv6 空間はアナウンスされておらず、RIPEstat は隣接ネットワーク AS18229 を観測し、これは APNIC ルーティング登録でも Infrazone の上流プロバイダーとして識別されている。PeeringDB は Infrazone のネットワークエントリを返さなかった。
• Infrazone は、そのサービスがパートナーデータセンターを利用していることを示し、ロケーションページでノイダ、ベンガルール、ムンバイを挙げている；他の製品ページではアーメダバードとインドールにも言及している。これらの主張は、どの顧客製品がどの建物でアクティブか、どの程度のフェイルオーバー容量が予約されているか、あるいは障害時に顧客がサイト間を移動できるかどうかを開示していない。
• 日次スナップショットと 15 日間の保持に関するプロバイダーの説明は出発点としてのみ有用である。公開ページでは、独立したバックアップドメイン、テストされた復旧時間、エクスポートスループット、リストア優先度、あるいはアカウントまたは施設契約が終了した場合にデータがどうなるかが確立されていない。
• エビデンスレベルは中程度である。デジタルリソースとルーティングに関する企業固有のエビデンスは最新で強固であるが、マルチサイト提供、トランジット多様性、ハードウェアスペアパーツ、サポート応答、復旧能力に関する公のエビデンスは限定的である。

クラウドサービスは他社の建物から始まる

Infrazone は資本支出の回避というおなじみの手段を販売している。同社の専用サーバーページでは、顧客がハードウェア、電力、冷却の購入を回避できるとし、クラウド VPS ページでは迅速なスケーリング、管理サポート、インド国内配置を約束し、コロケーションページでは安全な施設のラックまたはユニットスペースを提供している。ビジネス提案は明確である：サーバールームを構築する代わりに、顧客はコンピュート、ストレージ、接続性、サポートを 1 つのサービスにまとめるために Infrazone に支払う。

物理的な提案はより複雑である。Infrazone のデータセンターページは、同社がデータセンターサービスプロバイダーと提携していると述べている。製品ページでは、サーバーはサードパーティ施設にコロケーションされているとしている。この文言は重要な所有権の境界を確立する。Infrazone はサーバー、仮想化、顧客アカウント、アドレス資源、特定のネットワーク機器を所有または管理する一方で、施設運営者は建物、電源、冷却、物理セキュリティ、相互接続プロセス、フロアアクセスを管理する。キャリアまたはデータセンターネットワークが上流ルートを提供する場合もある。これらの層はうまく連携しうるが、交換可能ではない。

この区別が重要なのは、施設のエンジニアリングが自動的にその内部で販売される各サービスのレジリエンスになるわけではないからだ。耐故障性を備えた建物であっても、ネットワークパスが単一のサーバー、独立したコピーのないストレージシステム、あるいは予備の容量がないラックのテナントが存在しうる。事業者は複数の都市をアナウンスしながらも、特定の顧客のマシンは単一のホールに留まっているかもしれない。顧客はマネージドサービスを購入し、ハードウェア交換に別の施設チケットと別の都市から発送されるスペアパーツが必要であることを知るかもしれない。

これが Infrazone にとっての中核的な問いである：堅牢なインドのデータセンターが存在するかどうかではなく、そのレジリエンスのどの部分が各 Infrazone 製品に実際に及ぶのかである。同社の公開資料は、施設とのパートナーシップのもっともらしいモデルを確立している。サイトごとの現在のインベントリ、サービス配置マップ、テストされたフェイルオーバー設計、あるいは顧客が所有するリソースと他社に依存する容量の約束を区別できる契約を公開していない。

アクティブな ASN が運用面を現実のものとする

企業固有の最も強固なエビデンスは、インターネットのデジタルリソースとルーティングの登録にある。AS151986 の APNIC RDAP 登録は Infrazone Hosting Solution を指名し、ASN をアクティブとマークし、国をインドとし、登録日を 2023 年 10 月 27 日と記録している。同じ登録はネットワーク名 TANEHA-AS-AP を使用し、AS18229 からの経路を受け入れ、AS151986 を AS18229 にアナウンスするルーティングポリシーを記述している。関連する組織の連絡先はニューデリーの West Vinod Nagar にある。不正利用連絡先は、本記事の検証時点の 2026 年 4 月に検証済みと表示された。

アドレス登録はルーティングされたフットプリントよりもわずかに大きい。43.248.56.0/23 の APNIC RDAP 応答は、43.248.56.0 から 43.248.57.255 までをカバーするアクティブでポータブルな IPv4 ブロックを組織に割り当てている。これはレジストリ上 512 アドレスに相当する。しかし、RIPEstat のアナウンスプレフィックスビューは、2026 年 7 月 12 日までの 2 週間で、AS151986 から発信されたのは 43.248.56.0/24 のみだった。ルーティングされたブロックは 256 アドレスを含む。登録は保有者に大きなブロックを使用する権利を与えるが、両方の半分が設定され、到達可能で、顧客に割り当てられていることを証明するものではない。

アクティブな経路は周辺的な観測ではない。RIPEstat のルーティングステータス応答は、326 の IPv4 フルフィードピアのうち 323 で /24 を記録し、初回観測は 2023 年 12 月、最終観測は 2026 年 7 月 12 日であった。ルーティング履歴は、2023 年末以降継続的な可視性を示している。これらの測定は、狭いながらも重要な結論を裏付ける：Infrazone は単なる未使用の ASN ではなく、グローバルに可視な IPv4 経路を運用していた。

経路は強力なオリジンセキュリティシグナルも持っていた。RIPEstat の RPKI 検証は、AS151986 と 43.248.56.0/24 に対して有効を返し、最大許容長は /24 であった。APNIC は、Route Origin Authorizationがプレフィックスをアナウンスする権限のある ASN を識別すると説明している。有効なステータスは、ネットワークが意図されたオリジンと不正なオリジンを区別するのに役立つ。これは興味深い運用上のチェックである。

これらのいずれも、経路の背後にあるホストされたコンピュートの量や品質を証明するものではない。/24 は共有ホスティングアカウント、仮想マシン、専用サーバー、アプライアンス、あるいはほとんど使用されていないアドレスを提供することができる。BGP はストレージレプリケーション、ラックの電力、顧客数、サポート人員、スペアパーツを明らかにしない。それはアクティブなネットワーク境界を確立する。これはマーケティング文言よりもはるかに強固な基盤だが、それでも販売されるサービスの 1 層に過ぎない。

単一の観測された上流は集中であり、評決ではない

公のルーティングビューは、それが示さないものによって注目に値する。RIPEstat の ASN ネイバー応答は、AS151986 のネイバーとして AS18229 を 1 つ観測した。APNIC のルーティングポリシーは、Infrazone がすべての経路を受け入れ、自身の ASN をアナウンスするネットワークとして同じ ASN を指定している。Cloudflare Radarも AS151986 を Infrazone のインドネットワークとして識別しているが、PeeringDB API クエリはネットワークレコードを返さなかった。

AS18229 は、インドの大手データセンターおよび接続事業者である CtrlS に属する。この関係は、ノイダとベンガルールのロケーションパネルに CtrlS を記載している Infrazone のウェブサイトと一致している。それはまた集中点でもある。外部から観測される唯一のパスが単一の上流 ASN を経由する場合、公衆インターネットは Infrazone のエッジで独立したキャリアレベルのフェイルオーバーを確認できない。プライベートリンク、休眠中のバックアップセッション、独立した管理ネットワーク、あるいは公のコレクターが見ることができないプロバイダー管理のパスが存在する可能性はあるが、公のエビデンスはそれらを実証していない。

論理的多様性と物理的多様性の区別は極めて重要である。同じ上流への 2 本のリンクは、コントロールプレーン、ビジネスアカウント、相互接続室、あるいは上流の外部ファイバールートを共有しながら、障害のあるポートやカードから保護できる。同じデータセンター内の 2 つの BGP セッションは、施設がネットワーク集約層を喪失した場合に同時にダウンする可能性がある。逆に、公に観測される単一の上流が、慎重に多様化された回線と耐障害性のあるプロバイダーインフラストラクチャの背後にある場合もある。ルーティングテーブルはこれらの物理的事実を解決できない。

インターネットエンジニアリングの文献は、複数の上流を可用性向上の手段として扱う一方で、マルチホーミングには運用上の複雑さがあると警告している。RFC 3221は、複数の上流プロバイダーをサービス可用性向上の一般的な手段として説明している。RFC 4116は、BGP ベースのマルチホーミングがセッション生存性を提供できるが、収束時間がセッションタイムアウトを引き起こす可能性があると指摘している。実際的な教訓は、すべてのホストが無差別にキャリアを追加すべきということではない。冗長接続の主張は、それがどの障害を乗り越えられるかを特定すべきであるということだ。

Infrazone にとって、信頼できる回答は、AS151986 がデフォルト可能な第 2 の上流を持っているかどうか、そのパスが別の導管、室、ルーター経由で入ってくるかどうか、定期的に訓練されているかどうか、そしてそのコミット容量が停止時に優先トラフィックを運べるかどうかを示すだろう。これらの事実が示されるまで、アクティブな経路は到達可能性を証明するが、観測された単一のネイバーは依然として重大な依存関係である。

企業のウェブサイト自体は AS151986 の外にある

Infrazone のウェブサイトは、もう一つの有用な境界マーカーを提供する。2026 年 7 月の DNS チェックでは、infrazone.inが 162.241.123.158 に解決されることがわかった。このアドレスに関する RIPEstat のネットワーク情報応答は、それを AS46606 から発信された 162.241.123.0/24 に配置し、AS151986 ではなかった。ドメインの権威ネームサーバーはhostgator.in下にあり、メールエクスチェンジャーは Zoho のインドメールサービスを指していた。サイトの Google Public DNS クエリとメールクエリは、DNS 応答が変更される可能性はあるものの、再現可能な公的検証を提供する。

これは問題を示唆するものではない。販売サイトとメールを顧客ホスティングネットワークの外に置くことは、その配置が意図的であり、サポートチャネルも独立している限り、停止時に通信を維持できる。多くのインフラプロバイダーは、自らの公開プレゼンスに外部のソフトウェアやホスティングを利用している。また、これはウェブサイトの可用性を AS151986 や顧客サーバーが健全である証拠として使用できないことも意味する。企業のランディングページがグリーンなまま、ホストされたワークロードが障害を起こすこともあれば、顧客インフラが到達可能なままウェブサイトの停止が発生することもある。

有用な問いは、その分離がインシデントコミュニケーションにも及ぶかどうかである。公開サポートページはメール、チャット、電話の見出しを提供するが、重大度レベル、応答目標、エスカレーション名、または別途ホストされたステータスページを公開していない。その内容は、大規模インシデント時に顧客が権限のあるエンジニアにどのように連絡を取るかを確立するのに十分な運用詳細を提供していない。お問い合わせページと APNIC 連絡先は、公の連絡手段が存在することを示しているが、到達可能性はテストされた緊急チャネルと同じではない。

耐障害性のあるサービスは、障害が発生したサービスから独立した少なくとも 1 つのサポートパスを維持し、コントロールパネル停止時に顧客 ID とチケット履歴を保持し、インシデントの所有権を検証する手段を公開するだろう。ウェブサイトとメールの外部配置は役立つ可能性がある。それ自体は、これらの要件が満たされていることを証明するものではない。

3 つの都市が挙げられ、より広範な主張と未解決の配置マップ

Infrazone のロケーションに関するエビデンスは検証可能なほど具体的だが、現在のキャパシティマップとして扱うには不十分である。データセンターページには 3 つのパネルが表示されている：デリー首都圏のノイダにある施設、エレクトロニックシティのベンガルールにある施設、ナビムンバイのムンバイにある施設。ノイダとベンガルールのエントリでは CtrlS が挙げられている。高度な電源冗長性、物理セキュリティ、認証について説明し、同社が最新のデータセンタープロバイダーと提携していると述べている。

他の製品ページは地理的範囲を拡大している。Windows クラウドページ、Linux クラウドページ、コロケーションページでは、利用可能な大都市圏の場所としてデリー、ムンバイ、ベンガルール、アーメダバード、インドールが挙げられている。VPS ページはインドのデータセンターを示し、同じより広範なセットをリストしている。公開資料は、3 つの詳細なロケーションパネルと 5 都市にわたる製品の主張を整合させていない。また、どの場所が現在新規注文を受け付けているか、どの場所が AS151986 アドレスをホストしているか、あるいは既存顧客のサイト間復旧をサポートしているかについても述べていない。

可能性のあるパートナー施設の存在と能力については独立した裏付けがある。CtrlS はノイダデータセンターページでハイパースケール施設と耐震設計を説明している。TIA-942 証明書は、エレクトロニックシティ内のCtrlS ベンガルール建設施設を特定している。インド電子情報技術省は、政府向けクラウドサービス提供のためにCtrlS のクラウドロケーションをハイデラバード、ナビムンバイ、ベンガルール、ノイダに列挙している。これらの記録は、CtrlS が関連するインドの施設を有していることを検証する。それらは Infrazone のラック数、契約上の権利、顧客配置、またはこれらの施設内で予約された復旧能力を検証するものではない。

ここで、誰も文字通りの虚偽を述べていないにもかかわらず、施設のブランディングが誤解を招く可能性がある。サービスプロバイダーは、認定された建物内に機器を正直にホストすることができる。その後、顧客はサービスが自動的にあらゆる層で耐障害性を備えていると推論するかもしれない。Uptime Institute の Tier 認証概要はより正確である：Tier 分類はサイトのインフラストラクチャと運用に関するものであり、設計、建設設備、運用持続性を評価する別個のマイルストーンがある。建物の証明書は、テナントのアプリケーション設計、バックアップの独立性、またはインターネットトランジットを認定するものではない。

したがって、Infrazone に必要なエビデンスは、サービスごとの配置に関する声明である。それには、施設の法的運営者、都市、建物またはキャンパス、ラックの電源構成、ネットワーク引き渡しポイント、バックアップ場所、代替サイトを明記すべきである。「注文可能」と「既に設置済み」、「別の都市が存在する」と「このワークロードはそこにフェイルオーバーできる」を区別すべきである。このマップなしでは、複数都市のマーケティングは調達可能性のエビデンスであって、証明された復旧のエビデンスではない。

可用性パーセンテージは復旧設計ではない

Infrazone の公開ページでは、複数の可用性の数値が使用されている。ホームページはあるセクションで「Tier 4 クラウド」と 99.995% の可用性を宣伝する一方、ヒーローテキストでは 99% を使用している。製品ページでは通常 99.99% または 99.995% が示されている。これらの違いは異なる製品や大まかな文言を反映している可能性があるが、サイトは測定点、除外事項、クレジット、または製品固有の目標を定義する公開サービス文書を公開していない。

算術は、定義が重要である理由を示している。365 日の年において、99.995% の可用性は約 26 分のダウンタイムを許容し、99.99% は約 53 分、99% は 87 時間以上を許容する。これらの結果は根本的に異なる。最も高い数値でさえ、施設の電源レベルで測定される一方で、顧客の仮想マシンはストレージ障害、ファイアウォールポリシー、オペレーティングシステム、または上流ルートのために利用できないままになる可能性がある。年間パーセンテージはまた、顧客の許容可能な停止時間を超える単一の長時間の停止を隠す可能性がある。

Uptime Institute は、Tier IV をサイトインフラレベルでの耐障害性と説明している：個々の機器障害や配電経路の中断が運用に影響を与えるべきではない。また、持続可能な運用のトポロジーを分離している。Infrazone の顧客にとって、同等のサービス上の問いは、必要な各層が保護されているかどうかである：二重化された電源、二重スイッチパス、ストレージコントローラー、ハイパーバイザー、ファイアウォール、トランジット、名前解決、顧客認証、そしてそれらを修復する権限を持つ人々。

有用なサービスレベルアグリーメントは、顧客の観点から可用性を定義し、計画メンテナンスの取り扱いを特定し、パケット損失や深刻な劣化がどのようにカウントされるかを説明し、ルート障害がサーバー可用性と別個に測定されるかどうかを明記するだろう。また、救済策も開示するだろう。クレジットは障害のあるアプリケーションを復元しないが、その構造はプロバイダーが約束を契約上測定可能にしたかどうかを示す。

公には、Infrazone はこうした仕組みを十分に備えずにパーセンテージを提供している。購入者はそれを計算されたリスク限界ではなく、冒頭の主張として扱うべきである。最も強力なエビデンスは、製品固有の契約、月次履歴測定、インシデントサマリー、および関連コンポーネントがサービスを中断することなく撤去できることの実証であろう。

設置容量と使用可能容量は異なる数値である

ホスティング会社は構成を販売するが、顧客が体験するのは残存容量である。Infrazone のホームページにはクラウドと専用サーバーの構成例が表示され、専用サーバーページには CPU、メモリ、ディスク、帯域幅割り当てがリストされている。リストされた CPU には、表が現在の在庫の貧弱な指標となるほど古い世代のものが含まれている。このページは、安価に入手可能なハードウェア、過去の計画、または説明的な構成を説明している可能性がある。日付付きの在庫、提供数量、または交換プールは提供されていない。

この差は停止時に最も重要になる。設置容量は、名目上存在する総機器または仮想リソースである。使用可能容量は、メンテナンス、サーバー障害、またはネットワークパス喪失後に残るものである。復旧可能容量は、データ、構成、アクセス制御の復元後に顧客の時間枠内で利用可能にできるものである。プロバイダーはしばしばサービスを販売するのに十分な総ハードウェアを持っているが、影響を受けるすべての顧客を同時に移動させるのに十分なアイドル状態で互換性のあるハードウェアを持っていない。

公のアドレスデータは、ネットワークレベルでの同じ区別を示している。Infrazone は /23 として登録されているが、/24 をアナウンスしている。アナウンスされていない半分は、予約されているか、未使用か、別の時点で別の場所にルーティングされているか、展開待ちか、意図的に保留されている可能性がある。それは単に割り振りが存在するからといって、アクティブな顧客容量としてカウントされるべきではない。逆に、ルーティングされた 256 アドレスは、いくつが割り当てられているか、あるいはどの程度の密度でサービスがそれらを共有しているかを明らかにしない。

したがって、容量に関する質問は制約条件下で行うべきである。ハイパーバイザーが失われた場合、その仮想マシンはどこで再起動し、どの程度のリソースマージンが残っているのか？ストレージアレイが劣化した場合、バックアップと本番読み取りは同時に実施できるのか？アクティブなトランジットパスが故障した場合、代替パスは同じトラフィック負荷と攻撃フィルタリングを運べるのか？ある都市が利用不可になった場合、コンピュート、アドレス、ファイアウォール、またはサポート容量が枯渇する前に、何人の顧客が別の都市で復旧できるのか？

Infrazone の「スケールアップまたはスケールダウン」という文言は、顧客が電話またはメールで CPU、メモリ、ストレージの変更を要求できることを示している。これはサービスのプロセスであり、予約済みハードウェアの証拠ではない。決定的なエビデンスは、予約ポリシー、展開時間、障害状態の容量モデル、購入構成に対する最近の復旧テストであろう。

ラックと施設の障害が運営者の境界を露呈する

ラックインシデントは、些細なことから始まる可能性がある：故障した電源ユニット、ラックトップスイッチの不良、過熱したホットアイル、誤ったケーブル配線、ブレーカートリップ、または誤った電源でのメンテナンス。パートナー施設では、責任は即座に分割される。施設運営者は安全なアクセスと建物システムを管理する。Infrazone は契約で割り当てられた機器とサービス層を管理する。キャリアが相互接続または外部回線を所有する場合がある。顧客はアプリケーションの復旧を管理し、破壊的なアクションを承認する必要があるかもしれない。

Infrazone のコロケーションページは、N+N 電源、冷却、専用インターネット管理、迅速な展開を宣伝している。専用サーバーページでは、監視、バックアップ電源、迅速なハードウェア交換に言及している。これらは関連する管理策だが、公開ページでは、各サーバーが独立した給電に接続されたデュアル電源を備えているか、各顧客がデュアルスイッチを使用しているか、あるいは「迅速」が営業時間外に何を意味するかが述べられていない。建物レベルの N+N は、単一のラック PDU 経由で接続された単一電源コードのデバイスには役立たない。

修理窓口は実際の製品能力の一部である。同じ建物内にスペアディスクを持つプロバイダーは、正確なコントローラー、CPU 世代、または RAID バッテリーを調達しなければならないプロバイダーとは異なる復旧を行う可能性がある。認定されたオンサイトスタッフを持つプロバイダーは、リモートハンドのキューで待つプロバイダーとは異なる行動をとる可能性がある。専用サーバーカタログに古い構成が混在していることは、どの互換部品がローカルに保管されているか、および交換が顧客のソフトウェアライセンスやパフォーマンスを変更するかどうかを尋ねることの重要性を高めている。

運営者の境界はインシデント前に文書化されるべきである。顧客は、誰が障害を検出するか、誰がラックを開けられるか、誰が各チケットを所有するか、誰が部品を提供するか、いつエスカレーションが Infrazone から施設やキャリアに移行するかを知る必要がある。また、メンテナンスポリシーも必要である：通知期間、高リスクウィンドウの拒否権、ロールバック基準、冗長コンポーネントが作業開始前にテストされるかどうか。

これらの事実がなければ、「マネージド」は OS 支援からハードウェアとネットワークの完全責任まで、何を意味するかわからない。Infrazone はマネージドホスティングとコロケーションの両方を販売しているが、これら 2 つの製品はタスクの分担が異なる。契約は、共通のサポートスローガンに頼るのではなく、サービスごとに境界を明示すべきである。

ハードウェア在庫とサポート要員が実際の復旧時間を決定する

クラウドインターフェースは、顧客に容量が即座に現れると考えさせる。ベアメタルは在庫問題をより明確に露呈するが、仮想サービスにも同じことがある。仮想マシンは、互換性のあるコンピュート、ストレージ、ネットワーク容量を別のホストが持っている場合にのみ復旧可能である。専用サーバーには互換性のあるシャーシまたは部品が必要である。コロケーション顧客は故障したハードウェアを所有し、ハンドと接続性のみを Infrazone に依存する場合がある。

Infrazone は、電話、メール、チャット、チケットによる 24 時間年中無休のサポートが利用可能であるとしている。Windows および Linux のページでは、OS、セキュリティ、マネージドサービスの支援も約束している。しかし、公開サイトでは、シフトごとのチーム規模、指名されたエスカレーション役割、英語とローカルサポートへの一般的な言及を超えた言語カバレッジ、あるいは追加承認なしに含まれるタスクについては説明されていない。ディレクトリは小規模企業と説明しているが、ソーシャルプラットフォームの人員数は自己申告であり、本番変更を許可されたエンジニアの数を示していない。

これは相関障害時に重要になる。サーバー 1 台の交換は容易かもしれない。冷却イベント、ネットワーク停止、ストレージ障害は、同時に数十のチケットを生成しうる。その場合、顧客はトリアージの規律、専門家へのアクセス、コミュニケーションの頻度、重要なサービスを優先するプロバイダーの能力に依存する。名目上の 24 時間ヘルプデスクは、午前 3 時にサービスを回復する権限と部品を備えた熟練したネットワークおよびシステムチームと同等ではない。

サポートはインフラコンポーネントとしてテストされるべきである。顧客は高重大度のテストケースを開き、電話エスカレーションを検証し、技術的に有能な担当者に到達するまでの時間を記録し、通常のポータルが利用できない場合にプロバイダーが通信できることを確認できる。ハードウェアについては、顧客は購入構成に関連するスペアパーツリストと最新の交換訓練を要求できる。マネージドソフトウェアについては、顧客はパッチ責任、再起動権限、およびアプリケーショントラブルシューティングが有償作業になる時点を特定できる。

コストモデルは、これらの詳細が無制限であることは稀である理由を説明する。アイドル状態のハードウェア、夜間のスペシャリスト、複数のキャリア契約にはコストがかかる。低価格のホスティングは、顧客がより長い復旧時間、共有容量、またはより限定的なサポートを受け入れる場合には合理的でありうる。リスクは、契約と運用上のエビデンスが裏付けないエンタープライズレベルのレジリエンスを前提として低価格サービスが購入された場合に発生する。

15 日間のスナップショットは必ずしも独立したバックアップではない

Infrazone のWindows 専用ページでは、スナップショットがサーバー全体をコピーし、毎日のバックアップが実行され、顧客のバックアップが 15 日間保持されるとしている。専用サーバーページでも同様の文言が使用され、OS、ファイル、データベースを復元できると述べている。VPS および Linux のページでは、毎日のスナップショットと高可用性の主張が説明されている。これらの記述は、バックアップが存在するというだけよりも有用だが、最も重要な復旧の詳細には答えていない。

スナップショットは、本番環境と同じストレージ、管理者資格情報、施設、障害ドメインを共有する可能性がある。その場合、誤ったファイル変更からは保護できるが、ストレージアレイ、顧客アカウントの侵害、サイト障害と共に機能しなくなる可能性がある。毎日のスケジュールは、アクティブなトランザクションシステムの復旧ポイントを定義しない。最後の成功したコピー以降に書き込まれたデータは失われる可能性がある。15 日間の保持は、毎日の各コピーが不変であるか、削除が伝播するか、または数テラバイトの復元がどれくらい速く完了できるかを指定しない。

公開されている主張では、「データ損失ゼロ」と毎日のスナップショットも組み合わされている。これらの考えは調整が必要である。ゼロデータ損失には通常、同期レプリケーション、アプリケーション認識のジャーナリング、またはその他の継続的な保護メカニズムが必要であり、1 日 1 回のコピーだけでは不十分である。正しい答えは製品によって異なる可能性がある。カスタムの負荷分散環境は、エントリーレベルの VPS よりも強力な保護を備えているかもしれない。ウェブサイトはこの区別をサービスごとに公開していない。

CISA のランサムウェアガイドは、オフラインの暗号化バックアップと、可用性および整合性の定期的なテストを推奨している。アクセス可能なバックアップは攻撃者によって削除または暗号化される可能性があると警告し、クラウド間の配置がプロバイダー依存を減らす可能性があると指摘している。Infrazone の顧客にとっての教訓は、保持期間だけでなく、管理的および物理的な独立性について問いただすことである。

信頼できる復旧声明は、バックアップの都市とプロバイダー、暗号化の所有者、不変期間、コピー頻度、アプリケーション整合性の方法、リストア優先度、テストされたスループットを明記するだろう。それは復旧ポイント目標と復旧時間目標を定義し、最近の復元結果を示すだろう。重要なデータを持つ顧客は、別の資格情報の下で、可能であれば Infrazone のビジネスアカウント外にもコピーを保持すべきである。これは技術的な障害と、プロバイダーとの請求、アクセス、契約紛争の両方から保護する。

請求とプロバイダー契約は、ハードウェアを壊さずにサービスを中断させる可能性がある

インフラストラクチャが健全であっても、管理者上の理由で顧客がオフラインになることがある。未払いの請求書がサーバーを停止させる可能性がある。帯域幅料金に関する紛争がサポートを遅らせる可能性がある。データセンターのリース問題がラックアクセスを削除する可能性がある。期限切れのドメインや証明書が、機能しているアプリケーションを見かけ上利用不可にする可能性がある。リセラー契約が終了し、すべてのディスクとルーターがまだ動作していても移行を余儀なくされる可能性がある。

Infrazone の公開ページは、詳細なオンライン料金表よりも見積もりと直接の連絡を重視している。これはカスタムホスティングには適切かもしれないが、署名された注文書の重要性を高める。顧客は、契約主体、請求間隔、税務処理、更新ルール、停止猶予期間、猶予期間、解約後のデータ保持期間、および一括復元または転送料金を知る必要がある。また、施設や上流契約が変更された場合に Infrazone がサービスを継続できるかどうかも知る必要がある。

パートナーモデルは二層のビジネス依存関係を生み出す。顧客は Infrazone に支払い、Infrazone は施設、キャリア、ライセンスプロバイダー、ハードウェアサプライヤーに支払う可能性がある。顧客は通常、これらの上流契約を直接執行することはできない。保護は Infrazone の契約、財務の継続性、代替プロバイダー、および出口計画にある。ウェブページ上の施設名は、顧客に建物に入る権利や機器を回収する権利を与えない。

コロケーションは、顧客がサードパーティサイト内のサーバーを所有する可能性があるため、問題をさらに深刻にする。契約は、資産の所有権、シリアル番号、撤去権限、および先取特権や未払い料金に関する条項を特定すべきである。仮想およびマネージドサービスについては、キャンセル後どのくらいの期間データにアクセス可能か、顧客が削除前に最終コピーを取得できるかどうかを示すべきである。

したがって、請求の耐障害性は技術的な耐障害性である。独立したアラート連絡先、複数の承認された支払者、文書化された猶予期間、読み取り専用のエクスポートパスは、管理上のイベントが停止に発展するのを防ぐことができる。顧客はこれらの管理策をバックアップ復元と同じ真剣さでテストすべきである。

移行はフォーマット、帯域幅、稼働中のソースシステムに依存する

Infrazone は一度限りの移行サポートを宣伝している。これにより参入時の摩擦は軽減されるが、退出は最も難しい耐障害性のテストである。顧客は、価格、容量、セキュリティポリシー、都市レベルのリスク、未解決のインシデント、またはプロバイダーの契約変更のために退出する必要が生じる可能性がある。サービスが健全なうちに移動する能力は、危機がすべての転送を遅らせる前に確立されるべきである。

移行パスは製品によって異なる。専用サーバーはディスクイメージング、アプリケーション再構築、または物理的な発送が必要な場合がある。VPS は標準の仮想ディスクとしてエクスポート可能かもしれないが、ハイパーバイザーの違いにより他での直接起動が妨げられる可能性がある。マネージドデータベースは論理コピーと最終変更のキャプチャが必要な場合がある。コロケーションハードウェアは、アクセス、請求、およびキャリア依存関係を明確にした後でのみ持ち運び可能になるかもしれない。Infrazone の公開ページは、サポートされるイメージ形式、エクスポート制限、エクスポート料金、または退出中のアカウント可用性期間を明記していない。

NIST のクラウドコンピューティング標準ロードマップは、アプリケーションとデータの可搬性を重要な要件として扱い、仮想マシンのパッケージングは依然としてプロバイダー間で異なる可能性があると指摘している。ワークロードは宛先で受け入れられなかったり、起動しなかったり、移動後に誤動作したりする可能性がある。したがって、可搬性は訓練された能力であり、ファイルが何らかの方法でダウンロードできるという約束ではない。

帯域幅は制限的な物理リソースとなりうる。100 メガビット毎秒の持続スループットで 10 テラバイトを移動するには、プロトコルオーバーヘッドと中断の前に 9 日以上かかる；持続的な 1 ギガビットでも約 1 日かかる。ソースストレージが劣化している場合や、アカウントがスロットルされている場合、ウィンドウは長くなる。顧客の復旧設計では、どのデータを最初に移動するか、シードメディアが利用可能か、転送中の変更をどのように同期するかを指定すべきである。

最良のエビデンスは試験的な退出である。代表的なサーバーをエクスポートし、別のプロバイダーで復元し、アイデンティティ、ネットワーク、アプリケーション状態を検証し、所要時間を測定する。現在の構成、ライセンス、およびシークレットを別途管理された場所に保持する。Infrazone はこれをうまくサポートできるかもしれないが、その公開ページはプロセスを示していない。テストされるまで、「無料移行」はデータ可搬性が保証されたものではなく、オンボーディング支援を意味する。

インド国内配置には価値があるが、局所性はコピーによって証明されなければならない

Infrazone のサービス地理はインドの顧客にとって重要である。デリー、ムンバイ、ベンガルールまたはその近郊でのホスティングは、遠隔地と比較してレイテンシを低減し、オンサイト訪問を容易にし、データを使い慣れた法的・商業的枠組みの下に置くことができる。VPS ページはインド国内ホスティングをローカルアクセスとサポートに明示的に関連付けている。しかし、ASN の国コードや都市のリストでは、顧客データの各コピーがどこに存在するかを確立できない。

局所性には複数の層がある：本番ディスク、レプリカ、スナップショット、ログ、監視記録、サポートチケット、アイデンティティサービス、管理者アクセス。ノイダのプライマリ仮想マシンはムンバイにバックアップするかもしれず、それによりインド国内に留まりながらレジリエンスが向上する可能性がある。また、監視やチケット管理のために外国のソフトウェアサービスに依存する可能性もある。顧客はラックの都市だけでなく、完全なロケーション声明を必要とする。

インドの法的文脈は、この正確さを実用的なものにしている。2022 年 4 月 28 日の CERT-In 指令は、サービスプロバイダーや関係組織に対し、ICT ログをインド管轄区域内で 180 日間のローリング期間にわたって安全に保持することを義務付けている。また、データセンター、VPS プロバイダー、クラウドサービスプロバイダーに対し、指定期間にわたって検証済みの加入者情報を維持することも義務付けている。これらの義務は、顧客がサービスが一時的であると想定している場合でも、プロバイダーが何を収集・保持しなければならないかに影響を与える。

2023 年デジタル個人データ保護法は、中央政府が通知された国や地域への転送を制限することを認めており、より厳格なセクター別規則を保持している。これは、民間部門のすべてのワークロードがインドに留まらなければならないという普遍的な声明ではない。政府契約はより厳格な場合がある：政府部門向けの MeitY ガイドラインは、関連するクラウドサービス契約条件がサービスデータのインド内常駐を保証しなければならないと示している。

顧客にとって、適切なデューデリジェンスはワークロード固有のものである。適用されるセクター規則を特定し、すべてのストレージおよびサポートの場所を Infrazone に指定させ、越境アクセスの承認を定義し、削除されたデータがスナップショットやログからどのように削除されるかを明示する。ローカルホスティングは、関連するコピーとオペレーターがコミットメントの対象となっている場合にのみ、実際の要件を満たすことができる。

障害はステータスページに到達する前に顧客に波及する

誰が影響を受けるかは、Infrazone が何をホストしているかによる。共有ホスティングアドレスは、多数の小規模ウェブサイトを単一のマシンの背後に配置する可能性がある。VPS ノードは無関係のビジネスをホストすることがある。専用サーバーは数百人のユーザーを持つエンタープライズアプリケーションを支えることができる。コロケーションリンクは、顧客所有の機器への唯一のパスである可能性がある。/24 のエッジでの停止は、基盤となるディスクが健全であっても、それらのアドレスを使用するすべてのサービスを到達不能にする可能性がある。

セカンダリ測定は共有エクスポージャーの指標を与えるが、過度に解釈すべきではない。IPinfo の AS151986 ページは、レビュー時点で少数のアドレスに数百のドメインがホストされていると推定していた。これらの推定は観測された DNS から組み立てられており、不完全、時代遅れ、またはプロキシによって歪められている可能性がある。少なくとも一部のアドレスが複数のドメインを集中させている可能性を示唆しているが、契約、ワークロードの重要度、現在の顧客数を特定することはできない。

影響メカニズムは停止の種類によって異なる。ラック電源イベントはコンピュートを停止させる。トランジット撤回は他の点では健全なサーバーを隔離する。ストレージ障害は破損したデータや古いデータを返す可能性がある。サポートの障害は、権限のある人が行動しないため、時間を延長させる。請求ブロックはコントロールパネルアクセスを遮断する。移行の失敗は、元のサービスが撤回される間、不完全なコピーだけを顧客に残す可能性がある。

顧客はビジネスプロセスをこれらのメカニズムにマッピングすべきである。公開ウェブサイトは 1 時間の停止を許容できるかもしれないが、決済システムは許容できない。コールセンターアプリケーションは、営業時間中は低レイテンシを必要とし、夜間は異なる復旧目標を必要とするかもしれない。内部アーカイブはより遅い復旧を許容できるが、データ損失は許容できない。顧客がその重要度を明示せずに単に汎用的な「クラウドサーバー」を購入するだけでは、プロバイダーはこれらのニーズを正直に価格設定したり保護したりすることはできない。

Infrazone の価値は、直接サポートを通じて中小規模の展開に適応することにあるかもしれない。このモデルは、実践的な支援を必要とする顧客にとって、セルフサービスの大規模プロバイダーを上回る可能性がある。それはまた、サービス品質を、アカウントの背後にいる正確な人々、パートナー契約、およびローカル在庫により依存させる。これらの依存関係が明示的であればリスクは管理可能である。大きな可用性パーセンテージがそれらに取って代わる場合には不透明になる。

エビデンスを「もっともらしい」から「証明された」に変えるもの

公開記録は、規律ある検証の要求を支持する。障害を想定することも、レジリエンスを想定することも正当化しない。以下のエビデンスは、機密性の高い顧客詳細の開示を要求することなく、主要な未解決の問題を解決するだろう。

空白部分に関する結論も同様に重要である。AS151986 では IPv6 アナウンスは可視されなかった。PeeringDB クエリはエントリを返さなかった。公開サービスステータス履歴、製品固有の利用規約、詳細なインシデント記録、または現在の容量在庫は企業サイトで見つからなかった。これらの公開情報源の不在は、能力が存在しないという証拠ではない。それは、購入者が公的検証に頼ることができず、契約上または技術上のエビデンスを取得しなければならないことを意味する。

非公式のホスティング指標や逆引き DNS サービスは、顧客密度、アクティブなアドレス、都市配置を示唆する可能性はある。しかし、ラックの場所、ビジネス関係、可用性履歴を証明することはできない。有用なシグナルは、運営者、施設、レジストリ、または再現可能な測定によって裏付けられた場合にのみエビデンスとなる。Infrazone にとって、レジストリとルーティングのエビデンスはすでに最低限のハードルを越えている：アクティブなネットワークが存在する。次のハードルはサービスの復旧可能性である。

控えめなネットワークでも、その限界が明示的であれば堅実なサービスとなりうる

Infrazone の公的イメージは、ハイパースケールクラウドでも空っぽの殻でもない。アクティブなインドの ASN、有効な Route Origin Authorization、割り当てられた /23、観測された /24 アナウンス、パートナーデータセンターを中心に構築されたサービスカタログを備えたホスティングプロバイダーである。これは企業を真剣に受け止めるのに十分な運用上のエビデンスである。それは、スペースを借りる可能性のある建物についてのすべての信頼性の主張を継承するのには十分ではない。

狭いネットワークエッジは、ターゲットを絞ったプロバイダーにとって適切かもしれない。/24 は多くのホスティング用途をサポートする。単一の堅実な上流は許容可能な到達可能性を提供できる。パートナー施設は多額の資本支出を回避し、小規模プロバイダーが単独で構築できるよりも優れた電力とセキュリティへのアクセスを顧客に提供できる。直接サポートは価値がありうる。これらの利点のいずれも、サービスが無限の容量や独立した障害ドメインを持っているふりをすることを要求しない。

決定的なリスクは、抽象化によって隠された集中である。経路は公的に AS18229 に依存している。サーバーはラック、施設、スペアパーツに依存している。日次スナップショットは同じストレージまたはアカウントに依存する可能性がある。複数都市のリストは、特定の顧客が他に進行中のコピーを持っていることを意味しないかもしれない。マネージドサービスは、応答する人々と、彼らが行動することを許可する契約に依存している。請求と退出権は、データが到達可能なままかどうかを決定しうる。

顧客にとって、合理的な対応は自動的な拒否ではない。ワークロードに見合ったレベルのエビデンスを購入することである。低リスクのサイトは、テスト済みの外部バックアップと明確なサポート連絡先だけを必要とするかもしれない。収益システムは、デュアルトランジット、測定されたフェイルオーバー、独立したコピー、契約上の復旧目標を必要とするかもしれない。規制対象システムは、完全な局所性と保持条件を必要とする。自前のサーバーを提供する顧客は、資産撤去権とリモートハンドの詳細を必要とする。

Infrazone は、機密性の高いアーキテクチャを明らかにすることなく、エビデンスのギャップの多くを埋めることができる。日付付きのネットワークページで、アクティブなプレフィックス、IPv6 計画、上流の多様性、ステータス履歴を公開できる。製品条件で可用性パーセンテージを調整できる。配置文書で、提供都市とアクティブなフェイルオーバーサイトを区別できる。復旧条件で、スナップショットの独立性とリストアパフォーマンスを定義できる。これらの開示は、一般的な主張を顧客がモデル化できるサービスに変えるだろう。

それまでは、最も強固な結論は意図的に狭いままである。Infrazone Hosting Solution は可視的なネットワークを運用し、インドのパートナー施設から実際のホスティングカテゴリを販売している。公衆インターネットは到達可能性とオリジン認証を示している。しかし、すべての宣伝されたサービスがラック、上流、プロバイダー、またはアカウントの障害を乗り越えられると結論付けるには、十分な独立パス、予約済みハードウェア、サイト間容量、テスト済み復旧が示されていない。クラウドの請求書は現実であり、その背後にあるラック、トランジット契約、修理窓口も同様である。