要約

  • CV. RUMAH CLOUD INDONESIA は、ブランド検索だけでなく、インドネシアのインターネット番号記録に表示されます。公開アンカーは AS138868 であり、IDNIC-RUMAHCLOUD-AS-ID として登録され、APNIC 由来の記録では西ジャワ州バンドンの CV. RUMAH CLOUD INDONESIA として説明されています。
  • 現在のルーティング面は小規模です。RIPEstat は AS138868 がアナウンスされており、1 つの現在の IPv4 集約アドレス 103.140.54.0/23 (512 の IPv4 アドレスを表す) があり、2026 年 7 月 12 日のルーティングステータスビューでは IPv6 はアナウンスされていないことを示しました。
  • 主な依存関係のシグナルは、豊富さではなく集中です。RIPEstat は 1 つのネイバー AS147155 を観測しましたが、APNIC の aut-num テキストには古い経路ポリシーフィールドに AS56258 が依然としてリストされています。購入者は、そのギャップを、実際のアップストリームおよびフェイルオーバー構成を検証する理由として扱う必要があります。
  • ドメインの証拠は薄いです。APJII はブランド RUMAH CLOUD INDONESIA とドメイン RUMAHCLOUD.COM をリストしていますが、ライブドメインは現在、製品、サポート範囲、施設、またはデータ配置について説明するサービスカタログではなく、Cloudflare と LiteSpeed を介してインデックスページを表示しています。
  • 証拠グレードは中程度です。ASN とプレフィックスは重要であるのに十分なほどライブですが、公開記録はマルチサイト容量、ラックの場所、予備ハードウェアの深さ、サポートエスカレーション、経路の多様性、または顧客データの移植性を証明していません。

クラウドの名前は本物ですが、フットプリントは狭い

CV. RUMAH CLOUD INDONESIA の出発点として役立つのは、名前がクラウドプロバイダーのように聞こえるかどうかではありません。顧客が依存する可能性のある実際のインフラストラクチャエッジが公衆インターネットに表示されるかどうかです。その点について、記録は肯定的ですが控えめです。RIPEstat の AS138868 の AS 概要は、保持者を IDNIC-RUMAHCLOUD-AS-ID - CV. RUMAH CLOUD INDONESIA として識別し、ASN がアナウンスされているとマークしています。APNIC RDAPは、ハンドル AS138868、国 ID、AS 名 IDNIC-RUMAHCLOUD-AS-ID、および 2019 年 6 月の登録日を提供しています。APNIC Whois テキストは、組織を西ジャワ州バンドンの法人または直接の IDNIC メンバーとして説明しています。

この証拠により、Rumah Cloud はホスティングディレクトリ内の単なるラベル以上のものです。また、何が主張できるかについての境界も設定します。ライブ ASN は、サーバーの数、顧客のストレージの場所、サポート応答のスタッフの割り当て、またはサービスに第 2 のサイトがあるかどうかを証明することなく、ルーティング責任を識別できます。この違いは重要です。なぜなら、ホスト型容量の顧客は単に名前を購入するだけではないからです。顧客は、ラック、電力供給、クロスコネクト、アップストリーム契約、スペアパーツ、アカウント制御、およびサービスが壊れたときに修理できる人材に依存しています。

公開フットプリントは、同社の現在の Web プレゼンスが詳細なサービス説明を提供していないため、特に狭いです。APJII の Pengguna Nomor PI リストは、CV RUMAH CLOUD INDONESIA、登録番号 S1268、ブランド名 RUMAH CLOUD INDONESIA、法人メンバーシップ、ドメイン RUMAHCLOUD.COM、およびバンドンのオフィスアドレスをリストしています。しかし、ライブのrumahcloud.comページは現在、クラウド製品の公開カタログではなく、LiteSpeed と Cloudflare を介して提供される「Index of /」ビューを返します。Host.io のドメインページは、このドメインが Cloudflare アドレスでホストされており、Cloudflare のネームサーバーと SpamExperts のメールエクスチェンジャーをリストしていることを示しています。

これらのドメインの事実は慎重に読む必要があります。顧客のワークロードが Cloudflare で実行されていることを示しているわけではありません。公開 Web サイトが、同社のルーテッドインフラストラクチャの直接的な証拠ではないことを示しています。ネットワーク記録と Web 記録はアイデンティティによって関連していますが、同じ運用面ではありません。ルートテーブルは AS138868 についてあることを示し、Web サイトは同社が市場にどう見せているかについて別のことを示します。顧客は両方を必要とし、それらの間のギャップが厳しい質問の始まりです。

バンドンの記録は場所の手がかりであり、施設の証拠ではない

APJII と APNIC の記録はどちらも西ジャワ州バンドンを指しています。APJII のリストは、オフィスを Gateway Apartemen SB-LG1-7, Jl. Jend. Ahmad Yani No. 669, Padasuka, Cibeunying Kidul, Bandung, West Java としています。APNIC の番号資源記録は、組織とその abuse 連絡先にほぼ一致する住所を使用しています。これは有用な身元確認です。メンバーリスト、ドメイン、番号資源記録のすべてが同じ公開商業アイデンティティを指しています。

これはデータセンターの証拠ではありません。登録オフィス、abuse 連絡先住所、またはメンバーシップ住所は、事務処理、サポート管理、または法的な連絡が行われる場所である可能性があります。サーバーの設置場所、ルーターのマウント場所、バックアップの保管場所、または顧客の到達性を維持する電力とクロスコネクトがある建物を自動的に特定するものではありません。連絡先住所をラックアドレスとして扱うことは、公開証拠を過大評価することになります。

この区別はインドネシアのホスティングにとって重要です。プロバイダーは商業的にローカルでありながら、別のインドネシアの都市のコロケーションスペース、同じ建物内の部屋、別のキャリアからのリース容量、クラウドプラットフォーム、またはこれらの組み合わせを使用する可能性があります。公開番号資源データはサービスレイアウトを公開しません。それは資源の責任保持者を指名し、連絡先証拠を提供します。ワークロードがバンドン、ジャカルタ、別のインドネシアの都市圏、または契約書類でのみ開示されているサプライヤー施設にあるかどうかを示すものではありません。

購入者にとって、場所の問題はしたがってテストとして書かれるべきです。AS138868 を使用している顧客向けサービスはどれですか？ 103.140.54.0/23 ブロックは、ホスティング顧客、管理サービス、DNS、メール、顧客ポータル、またはその他の機能に割り当てられていますか？ それを発信する機器を保持している施設はどれですか？ それらのサイトは所有、賃貸、またはキャビネット単位で賃借されていますか？ 営業時間外に物理的にアクセスできるのは誰ですか？ 単一障害が発生した後も残る電力ドメイン、アップストリームポート、クロスコネクトはどれですか？

公開回答は保証には十分ではありません。それはサイトインタビューを具体的にするには十分です。公開記録はバンドンのアイデンティティとインドネシアのルーティングを指しています。顧客は、クラウドという言葉を回復力の主張として扱う前に、施設名、ラックの責任、回復エビデンスを必要とします。

ルートエッジは1つの IPv4 集約アドレスである

現在のルーティング証拠は明確です。RIPEstat ルーティングステータスは、AS138868 が 1 つのアナウンスされた IPv4 プレフィックス、512 の IPv4 アドレスを持ち、IPv6 はアナウンスされていないと報告しました。同じビューは、20219 年 10 月 30 日に 103.140.55.0/24 の First-Seen エビデンスを示し、2026 年 7 月 12 日に 103.140.54.0/23 の Last-Seen ルートを示しました。RIPEstat アナウンスプレフィックスは、2026 年 7 月 12 日で終了するクエリウィンドウの集約として 103.140.54.0/23 をリストしました。

これは、動作しているルート面を示すには十分です。幅広い容量を示すには十分ではありません。/23 は、割り当て、ネットワーク設計、管理、予約、顧客セグメンテーションによって実際に使用可能なアドレスが減少する前の 512 の IPv4 アドレスを提供します。特にネームベースの仮想ホスティング、NAT、公開フロントエンドの背後でのプライベートアドレッシング、または限られた顧客ベースを使用する場合、一部のホスト型サービスは小さなアドレスプール内で生産的に実行できます。しかし、/23 は公開アドレスの在庫を制約します。それにより、専用の IPv4 アドレスを受け取ることができる顧客の数、移行のために保持できる予備スペースの量、およびプロバイダーが不正使用、メンテナンス、DDoS 応答、または顧客固有のフィルタリングをどれだけ優雅に分離できるかが制限されます。

可視の IPv6 の欠如もビジネス上の問題であり、単なる技術的な脚注ではありません。IPv6 はすべての小規模なホスティングのユースケースに必須ではありませんが、公開ルーティングビューでの不在は、購入者がデュアルスタックの到達性を想定できないことを意味します。顧客が最新のアクセスネットワーク、モバイルユーザー、クロスボーダーパートナー、または IPv6 経由で到達可能であるべき公開サービスを持っている場合、購入者は直接の回答が必要です。IPv6 は別のネットワークで利用可能ですか？ 計画されていますか？ 顧客製品では欠落していますか？ サプライヤーを通じて提供される場合、サポートチームは IPv6 を個別に監視していますか？

公開ルーティングサービスは、AS138868 が空ではないことを確認できます。RIPEstat プレフィックス概要 (103.140.54.0/23)は、プレフィックスがアナウンスされているとリストし、AS138868 に関連付けています。Hurricane Electric の ASN ページとIPinfoは、同じ ASN の独立したルックアップを提供します。重要なのは、これらのサービスが表示できないことです。コンピューティング密度、ストレージの耐久性、顧客数、予備機器、またはテストされた復旧パス。

可視ネイバーが1つであることは依存シグナルである

現在の最も重要なルートの手がかりはネイバーリストです。RIPEstat ASN ネイバーは、AS138868 について 1 つの観測されたネイバーを示しました。AS147155 は、観測されたパスデータの左側にマークされています。RIPEstat の AS147155 の AS 概要は、その ASN を IDNIC-GATEWAYNET-AS-ID - PT Gateway Internet Indonesia として識別します。APNIC Whois for AS147155は、Gateway Internet Indonesia をバンドンに配置し、独自のアップストリームポリシーをリストしています。

これは自動的に悪いことではありません。多くの小規模ネットワークは、地域のオペレーターからトランジットを購入するのが合理的であり、うまく運営されている単一のアップストリームは、管理が不十分な 2 つよりも優れている場合があります。しかし、それは集中シグナルです。観測された公開パスが 1 つの隣接 AS に依存している場合、そのネイバー、建物へのアクセス、クロスコネクト、ルートポリシー、または商用アカウントに障害が発生した場合に、別の使用可能なルートがあるかどうかを顧客は知る必要があります。冗長性は、ASN がアナウンスされているという事実から推測することはできません。

また、古くなっているか分岐している記録を調査する必要があります。AS138868 の APNIC aut-num テキストは、RIPEstat がPGAS-AS-AS-ID - PT. PGAS TELEKOMUNIKASI NUSANTARAとして識別する AS56258 を含むルートポリシーフィールドをリストしています。しかし、現在の RIPEstat ネイバービューは AS147155 を表示しています。これは単に、プロバイダー変更後にレジストリルートポリシーが更新されなかったか、異なる公開ビューが構成の異なる部分を公開していることを意味する可能性があります。また、サービスが時間の経過とともにサプライヤーを変更したことを意味する場合もあります。

購入者は推測すべきではありません。プロバイダーは、現在のアップストリーム、デフォルトルート構成、コミットされた帯域幅、オーバーフロー容量、物理的なクロスコネクトパス、AS147155 のピアリングまたはトランジットの役割、および AS56258 がまだ何かに使用されているかどうかを明らかにできるはずです。契約は、論理的なルートの多様性と実際の物理的および商業的な多様性を区別する必要があります。1 つのサプライヤーキャビネットまたは 1 つの未払い請求書を通じて出る 2 つのルートは、独立した復旧パスではありません。

古い経路履歴は継続性と中断を示す

ここでは履歴が役立ちます。なぜなら、楽観論と警告の両方を和らげるからです。RIPEstat ルーティング履歴は、AS138868 が 2019 年に 103.140.54.0/23 の集約アドレスで現れ、その後異なる可視性レベルで後の期間に再発することを示しています。このパターンは、ASN が 1 日限りのプレースホルダーではなかったという考えを裏付けます。それは繰り返し公開の生活を送ってきました。

しかし、履歴は現在の回復力と同じではありません。ルート履歴ビューには、以前の /24 スペシフィックや、ピア可視性が変化した期間も示されています。可視性のある履歴は、通常のルーティングの変更、プロバイダーの移行、メンテナンス、ルート集約、コレクターのカバレッジ、または運用上のインシデントを反映している可能性があります。オペレーターの説明がなければ、公開ルートコレクターは、各日付にどの理由が適用されたかを判断できません。

教訓は、履歴を質問生成器として使用することです。ネットワークが /24 アナウンスから /23 集約アドレスに移行した場合、それはなぜですか？ ルートポリシーのクリーンアップ、プロバイダーの変更、容量移動、または到達可能性への一時的な対応でしたか？ 公開可視性が時点で低下した場合、顧客サービスは影響を受けましたか？ AS56258 が古い aut-num フィールドに表示され、AS147155 が現在の観測に表示される場合、現在のアップストリーム構成はいつ始まり、変更中に顧客はどのようなフェイルオーバーを利用できましたか？

ホスティング顧客にとって、これらの質問は履歴ラベルよりも重要です。クラウドサービスは数年存在したからといって回復力があるわけではありません。顧客のワークロードを閉じ込めることなく変更を吸収できる場合に回復力があります。ルート履歴は継続性への信頼を裏付けることができますが、復旧テストは現在のものでなければなりません。

RPKI は公開ビューでは未解決である

ルーティングセキュリティは別の注意事項を追加します。RIPEstat RPKI 検証 (オリジン AS138868 とプレフィックス 103.140.54.0/23)は、このプロファイルに使用されたクエリで検証 ROA がない不明なステータスを返しました。これはルートが無効であることを証明するものではありません。公開検証ビューでは、依存ネットワークがオリジンを有効としてマークできるようにする Route Origin Authorization が表示されなかったことを意味します。

小規模なホスティングプロバイダーにとって、これは重要です。なぜなら、ルートオリジン検証はますます基本的なルーティング衛生の一部になっているからです。RFC 6811は BGP プレフィックスオリジン検証を定義し、APNIC のリソース認証資料は、オリジンを認証する際の RPKI の役割を説明しています。有効なオリジンステートはサービスを冗長または高速にするわけではありませんが、予防可能なルーティングトラブルの 1 つのクラスを減らします。不明なステータスは、フィルタリングの違いや顧客の不確実性の余地を残します。

購入者は、現在の ROA ステータスとルートセキュリティ声明を求める必要があります。保持者は集約アドレスの ROA を維持していますか？ そうでない場合、なぜですか？ バックアップ条件下でサプライヤーがルートをアナウンスする場合、そのオリジンは認証されていますか？ インシデント中に誰がルートオブジェクトと ROA を更新できますか？ 会社は無効または不明なオリジンの変更を監視していますか？

同じ規律が IRR データにも適用されます。RIPEstat プレフィックスルーティング一貫性は、ライブ BGP にはないオブジェクトを含む、103.140.54.0/23 空間周辺の RADB ルートオブジェクトを示しました。IRR レコードはネットワークがフィルターを構築するのに役立ちますが、ライブルートプランに遅れをとる可能性もあります。購入者はすべてのレジストリの詳細を必要としませんが、プロバイダーのルート認証レコードがライブサービスと復旧設計に一致しているかどうかを知っておく必要があります。

PeeringDB プロファイルがないことで公開マップが狭まる

相互接続の証拠は薄いです。PeeringDB API クエリ (ASN 138868)は、チェックされた公開応答でネットワークプロファイルを返しませんでした。その不在は失敗として扱うべきではありません。多くの小規模プロバイダーは PeeringDB にリストされておらず、公開相互接続ディレクトリエントリを維持せずにサービスを提供できます。

それは、公開マップが PeeringDB がしばしば提供する詳細、つまり施設、交換アタッチメント、トラフィックレベル、ピアリングポリシー、連絡先の役割、Looking Glass リンク、およびオペレーターによって維持されるプレフィックス数を欠いていることを意味します。その層がなければ、購入者は、会社がどこで相互接続するか、交換に参加するか、地域的にピアリングするか、またはすべての公開到達可能性がトランジットを経由するかについての公開の手がかりが少なくなります。

Rumah Cloud にとって、この結果はより多くの作業を直接検証に押し込みます。AS138868 エッジをホストするのはどの施設ですか？ 2 台目のルーターと 2 番目のアップストリームはありますか？ 会社は IP トランジットのみを購入し、Gateway Internet Indonesia とローカルネットワークを共有するか、または別のプロバイダーの集約の背後に機器を配置しますか？ 顧客トラフィックはインターネット交換ルートサーバーを使用しますか？ 交換スイッチまたはセッションに障害が発生した場合に顧客サービスに影響を与えるほどクリティカルなトラフィックを運ぶピアリングパスはありますか？

PeeringDB の不在は、「クラウド」のイメージをより自明でなくします。プロバイダーは小さなプライベート構成で有効なホスティングサービスを実行できますが、顧客は沈黙から中立施設の多様性を推測すべきではありません。この場合、可視の相互接続ストーリーは 1 つの現在のネイバーであり、公開 PeeringDB プロファイルはありません。これは狭いサービスには十分かもしれません。広範な回復力の主張には十分ではありません。

公開ドメインはホスティング製品を説明していない

最も人間向けの記録はドメインであり、それはサービスに関する質問に答えるのではなく、提起します。APJII は、メンバードメインとして RUMAHCLOUD.COM をリストしています。ライブサイトは現在、製品ページではなくインデックスページを表示しており、Host.io はドメインが Cloudflare でホストされていると報告しています。したがって、DNS と Web サイトのプレゼンテーションは、Rumah Cloud が現在 VPS、共有ホスティング、ベアメタル、マネージドサーバー、コロケーション、DNS、Web デザイン、バックアップ、リセラーサービス、またはそれらの組み合わせを販売しているかどうかを説明していません。

それが、記事のタイトルの「ホステッドキャパシティ」というフレーズを広く理解すべき理由です。会社の名前、APJII リスト、および ASN は、クラウドまたはホスティング指向のインフラストラクチャ対象を示唆しています。公開証拠は、どの容量が販売されているか、どのようにパッケージ化されているか、または顧客がどのようにサポートされているかを十分に詳細に定義していません。責任ある読み方は、これらの 2 つの考えを一緒に保持する必要があります。ネットワークは本物であり、顧客向けの提供物は完全には可視化されていません。

調達にとって、カタログの欠落は単に不便なだけではありません。製品ページは、オペレーティングシステム、ストレージティア、帯域幅の割り当て、バックアップオプション、サポート時間、不正使用ルール、返金条件、移行支援、データ保持ポリシーなどのサービス制約を明らかにすることがよくあります。それらが公開されていない場合、購入者は重要なものを移動する前に書面でそれらを必要とします。公開詳細の欠如は、弱いサービスの証拠ではありませんが、独立した保証を減らします。

Web ドメインの分離は、インシデント中にも重要です。顧客サポートポータル、請求ページ、またはステータスページが Cloudflare の背後にあり、ホスト型ワークロードが AS138868 上にある場合、一方は他方が到達可能なまま失敗する可能性があります。これは役立ちます。なぜなら、外部にホストされたステータスチャネルはネットワーク停止を乗り切ることができるからです。それはまた、公開 Web サイトが生き残りながら、ホストされたサービスがその背後で失敗すると、顧客を混乱させる可能性があります。プロバイダーは、サービスパスの内側にあるシステムと外側にあるシステムを説明する必要があります。

小さなアドレスプールは経済性を変える

ホスティングの経済性は、/23 と大規模なマルチリージョンプラットフォームでは異なって見えます。IPv4 アドレスは希少で価値があります。512 アドレスを持つプロバイダーは、ルーター、サーバー、顧客割り当て、NAT プール、制御システム、監視、隔離、予備スペース、および将来の成長にいくつ使用するかを決定する必要があります。専用のパブリック IPv4 を必要とするすべての顧客は、隔離や拡張にも使用できないリソースを消費します。

それはサービスを悪くするものではありません。限定的な顧客ベースにサービスを提供するローカルプロバイダーにとって、それはまさに適切な規模かもしれません。小規模プロバイダーは、大規模プラットフォームにはないパーソナルなサポート、ローカルの商習慣、および実用的な地域知識を提供できます。しかし、その経済性は正直であることを要求します。顧客がワークロードごとに 1 つの IP、不正使用対応中の迅速なアドレス変更、専用管理ネットワーク、または大規模な移行容量を期待する場合、アドレスプールは制約になる可能性があります。

ルート集約アドレスは復旧にも影響します。障害時には、プロバイダーは再構築されたホスト、交換用ファイアウォール、一時的なプロキシ、顧客の移行、テスト復元、または DDoS 緩和のために予備のパブリックアドレスを必要とする場合があります。すべてのアドレスが既に割り当てられている場合、復旧はネットワークの問題であると同時にスケジューリングの問題になります。顧客は、インシデント作業のためにどのくらいのアドレス在庫が予約されているか、およびプライベートアドレス設計を公開エンドポイントを変更せずに移動できるかどうかを尋ねる必要があります。

ここで、ホステッドキャパシティは物理的および商業的な約束になります。請求書には月額ホスティングプランが表示される場合がありますが、プロバイダーはアドレスリソース、アップストリーム帯域幅、施設スペース、電力、ハードウェア、ライセンス、スタッフ、およびサポートシステムの費用を支払う必要があります。価格が低い場合、顧客は回復力スタックのどの部分が意図的にスリムであるかを尋ねる必要があります。安価なサービスは低リスクのワークロードには合理的です。価格とフットプリントが裏付けないエンタープライズグレードの復旧を顧客が暗黙のうちに想定した場合にのみ危険です。

設置済み容量は使用可能容量ではない

公開ルートは、アナウンスされているものを読者に伝えますが、何かが壊れた後に利用可能なままであるものを伝えません。設置済み容量とは、プロバイダーが通常の運用中に説明できる量です。アドレススペース、サーバー、帯域幅、ストレージ、ラックスペース、顧客パネル、サポートチャネル。使用可能容量とは、ルーターがダウンしているとき、サプライヤーリンクが劣化しているとき、ストレージノードが再構築されているとき、サポートエンジニアが別のインシデントで忙しいとき、または顧客が迅速に移動する必要があるときにまだ機能するものです。2 番目の数値は、悪い日に重要なものです。

Rumah Cloud にとって、公開記録はその 2 番目の数値を測定できません。1 つの /23 は、プロバイダーが予備のパブリックアドレス、予備のサーバー、および静かなサポートキューを保持している場合、狭いサービスには十分かもしれません。同じ /23 は、多くの顧客が専用アドレスを必要とする場合、不正使用処理がアドレススペースを消費する場合、一時的な再構築に並列システムが必要な場合、または障害が発生したアップストリームがトラフィックを小さなバックアップパスに強制する場合、逼迫する可能性があります。開示された容量ポリシーがなければ、購入者は可視プレフィックスをサービス保証に変換すべきではありません。

同じ区別がコンピューティングとストレージにも当てはまります。サーバーフリートは設置されているがオーバーコミットされている可能性があります。バックアップシステムは存在するが顧客の期限には遅すぎる復元を提供する可能性があります。2 番目のパスは構成されているがサイズが不足している可能性があります。サポートチャネルは開いているが、実際の修正を承認できない可能性があります。公開ルーティングデータはこれらの制限を公開しません。テストされた復旧エビデンスだけができます。

したがって、顧客は通常状態の主張ではなく、障害状態の数値を尋ねる必要があります。一度に復元できるワークロードの数は？ 緊急移動のためにどれだけのパブリックアドレススペースが保持されていますか？ メインパスに障害が発生した場合に残りのアップストリームが運べるトラフィック量は？ 障害が発生したホストの交換にかかる時間は？ 地域的なインシデント中にサポートスタッフが処理できる顧客の数は？ これらの回答は、自らの限界を知っている小規模プロバイダーと、最初の深刻な停止がそれを明らかにする小規模プロバイダーの違いを生みます。

ラック、電力、修理アクセスが依然として復旧を左右する

ルートテーブルはラックを表示できません。それがこのプロファイルの中心的な制限です。公開記録は AS138868 と 103.140.54.0/23 を表示できます。サーバーが 1 つのキャビネット、1 つの部屋、1 つの施設、または複数のサイトに設置されているかどうかを表示できません。二重化された電力供給、予備スイッチ、ホットサーバー、テストされたバックアップ、交換ディスク、アウトオブバンドアクセス、または市全体の混乱時に機能するリモートハンズ契約があるかどうかを表示できません。

これが、顧客がすべてのクラウドの約束を物理的な質問に変換すべき理由です。ルーターに障害が発生した場合、誰がそれにアクセスできますか？ ディスクアレイに障害が発生した場合、スペアパーツはどこにありますか？ AS147155 へのアップストリームセッションがドロップした場合、どのルートが残っていますか？ 建物が停電した場合、どのワークロードが稼働し続けますか？ コントロールパネルが利用できない場合、サポートはまだ顧客インスタンスにアクセスできますか？ 請求システムが誤ってアカウントをロックした場合、サービスインシデント中に誰がそれを上書きできますか？

サポート労働力はインフラの一部です。小規模プロバイダーは顧客をよく知っているかもしれませんが、休暇中、夜間メンテナンス中、または重複するインシデント中に利用できるエンジニアが少ない可能性もあります。公開記録はチームの規模やサポート時間を開示しません。つまり、顧客は測定可能なエスカレーションに焦点を当てる必要があります。緊急サポートとして何が適格ですか？ どのチャネルが時間外に監視されていますか？ 応答する人はルーティング、サーバー、またはアカウントの変更を行うことができますか？ 電話、メールシステム、またはチケットシステムが同じ停止の影響を受けた場合、何が起こりますか？

修理時間枠は抽象的ではありません。顧客が注文枠、給与期限、学校登録期間、または政府提出を逃すかどうかを決定します。可視ルートエッジが 1 つしかないプロバイダーは、数分以内に復旧可能な障害、サプライヤーのアクションが必要な障害、および顧客の移行が必要な障害について特に明確でなければなりません。正直な答えはブランド名よりも狭いかもしれません。顧客がサービスに依存する前にそれを理解していれば、それは許容されます。

データの所在地は配置の問題である

Rumah Cloud は公開記録ではインドネシアの会社であり、AS138868 はインドネシアで登録されており、RIPEstat の地理的位置データは 103.140.54.0/23 を ID に配置しています。RIPEstat 地理的位置とRIPEstat 経由の MaxMind GeoLiteはどちらも、チェックされたビューでプレフィックスに対してインドネシアを返しました。これは有用な所在地証拠です。

これは完全なデータ主権の回答ではありません。IP プレフィックスの国証拠は、すべての顧客ファイル、バックアップ、ログ、スナップショット、チケット添付ファイル、請求記録、または管理者資格情報がどこに存在するかを証明するものではありません。プロバイダーはプライマリワークロードをある場所に、バックアップを別の場所に、メールをサードパーティサービスに、サポート記録を別のシステムに保存する場合があります。公開ドメインの Cloudflare と SpamExperts のレコードは、少なくとも一部の Web およびメール関連機能が外部サービスを含むことを既に示しています。これは、顧客のワークロードがインドネシアを離れることを意味するものではありません。国コードだけからデータ配置を推測できないことを意味します。

所在地要件を持つ顧客は、配置マトリックスを求める必要があります。ライブワークロードはどこにありますか？ バックアップはどこにありますか？ スナップショットはどこにありますか？ ログはどこにありますか？ コントロールパネルはどこにありますか？ 顧客の身元はどこに保存されていますか？ どのサプライヤーがサポート記録にアクセスできますか？ どの管轄区域が契約を管理しますか？ 顧客が退出した場合、またはサービスが低下した場合、どのデータを取得できますか？

回答はワークロードに合わせる必要があります。パンフレットサイト、テストサーバー、または低リスクのコミュニティサイトは、厳格な所在地証明を必要としない場合があります。規制対象の顧客、医療機関、金融サービス、政府サプライヤー、または機密のクライアント記録を持つ企業は、はるかに多くを必要とします。それらの購入者にとって、ここでの公開証拠は出発点にすぎません。インドネシアのアイデンティティ、インドネシアの登録リソース、およびインドネシアの地理的位置シグナル。サービス契約は残りを埋める必要があります。

エッジに障害が発生した場合に影響を受けるのは誰か

小規模なホスティングネットワークの影響は、プレフィックス数が示唆するよりも大きい可能性があります。/23 は、Web サイト、メール関連サービス、DNS、顧客パネル、API、リモート管理エンドポイント、リセラーインフラストラクチャ、またはビジネスアプリケーションをホストできます。短い停止は一般的なインターネットには見えないかもしれませんが、依存する特定の顧客にとっては依然として痛みを伴います。インフラリスクはアドレス数だけで測定されるものではありません。アドレス上に何があり、誰にフォールバックがないかによって測定されます。

AS138868 がルートを引き出すと、影響を受けるサービスは単に公衆の到達可能性から消える可能性があります。ルートは残っているがアップストリームパスが輻輳またはフィルタリングされている場合、顧客は部分的な障害を見る可能性があります。1 つのネットワークからは到達可能で、別のネットワークからは遅く、海外からは壊れており、キャッシュされた DNS と古いセッションを介してのみアクセス可能です。Web ドメインが Cloudflare を通じて稼働し続け、AS138868 の背後でホストされたサービスが失敗した場合、顧客がダウンタイムを経験している間、同社の公開の顔は生きているように見えるかもしれません。

管理的な障害もあります。請求紛争、期限切れのドメイン、ブロックされたメールルート、悪用された IP、過負荷のサポートチャネル、またはアカウントロックは、BGP 停止がなくても顧客に損害を与える可能性があります。これらは二次的な問題ではありません。ホスト型容量では、管理の継続性はサービス継続性の一部です。顧客は、ストレス時にアカウント、記録、サポート、および復旧手順を使用可能に保つプロバイダーの能力に依存しています。

最も影響を受ける人々はネットワークエンジニアではないかもしれません。オンラインストアにアクセスできない中小企業の経営者、修正を展開しようとしている開発者、エンドカスタマーの苦情に応答するリセラー、ポータルを待っている学校管理者、または言語とサポートの理由で近隣のプロバイダーを選択した地元組織かもしれません。これが、薄い公開証拠が真剣で、否定的ではない読み方を必要とする理由です。小規模プロバイダーは実際の依存関係を運びます。

AS147155 の隣接関係は復旧パスとしてテストすべきである

現在の公開ネイバーが AS147155 であるため、Gateway Internet Indonesia との関係は直接の質問に値します。AS147155 の APNIC 記録は、Gateway Internet Indonesia をバンドンにリストし、Rumah Cloud の AS 記録よりも詳細なアップストリームセットを示しています。これは、GatewayNet が Rumah Cloud の公開エッジのルートプロバイダーであることを意味する場合もあれば、ルートコレクターから可視性の高いより限定的な関係を反映している場合もあります。公開記録は商業的な境界を解決しません。

違いは実用的です。GatewayNet がアップストリームである場合、Rumah Cloud の復旧は、GatewayNet の電力、アップストリーム、フィルター、ルートポリシー、請求関係、およびサポート応答に部分的に依存します。両社が同じ住所記録内またはその周辺で運営されている場合、購入者はそれが共有の場所、共有のオフィス、共有の施設アクセス、サプライヤー関係、または管理上の近接性のみを意味するのかどうかを理解する必要があります。共有された地理は調整を改善できますが、電力、建物アクセス、またはローカル接続に障害が発生した場合、共通モードリスクも生み出す可能性があります。

顧客は、平易な言葉でのパス図を求める必要があります。AS138868 からの最初のアップストリームは何ですか？ 別のものはありますか？ 別々のクロスコネクトはありますか？ それらのクロスコネクトは別々の Meet-Me Room にあるのか、1 つのパッチパスを介しているのか？ AS147155 に問題が発生した場合、AS138868 にはテストされた代替ルートがありますか？ 代替ルートが存在する場合、どれだけの顧客トラフィックを運ぶことができますか？ フェイルオーバーはどのくらいの頻度でテストされますか？

回答には技術的権限と商業的権限の両方を含める必要があります。プロバイダーは紙の上ではバックアップパスを持っているが、自動ルートフェイルオーバー、十分なコミットメント、またはサプライヤーとの緊急チケットを開く権限を欠いている可能性があります。復旧はチェーン全体に依存します。観測されたネイバーは、顧客にその責任連鎖レビューを開始するための名前付きの場所を提供します。

信頼性を高めるにはどのような証拠が必要か

証拠グレードは、いくつかの公開または顧客向けの開示によってすぐに改善される可能性があります。現在のネットワークページでは、AS138868、現在のプレフィックス、アップストリーム、abuse 連絡先、サポート時間、ルートセキュリティステータスを指定できます。サービスページでは、Rumah Cloud が VPS、共有ホスティング、マネージドサーバー、ストレージ、バックアップ、リセラーホスティング、またはその他のサービスを提供しているかどうかを定義できます。ステータスページでは、機密の詳細を公開せずに監視している公開サービスをリストできます。ピアリングまたは施設の概要では、サービスが 1 つのサイトを使用しているか、複数のサイトを使用しているかを示すことができます。

顧客向けの文書はさらに重要です。購入者は、最近のバックアップ復元エビデンス、測定された復旧時間、メンテナンス通知ルール、インシデント通信の例、サポートエスカレーションパス、データ取得条件、および顧客データとバックアップがどこに存在するかに関する明確な声明を求める必要があります。プロバイダーが施設名を公に共有できない場合でも、リスクを理解するのに十分な契約上の詳細を顧客に提供できます。

ルートセキュリティの証拠も簡単です。AS138868 と 103.140.54.0/23 の現在の ROA は、公開ルーティングセキュリティの状況を改善します。ライブアナウンスと一致するクリーンで最新のルートオブジェクトは、あいまいさを減らします。AS56258 ポリシーテキストと現在観測されている AS147155 ネイバーとの違いを説明する声明は、アップストリームの変更に関する不確実性を減らします。

重要なのは、地域プロバイダーにハイパースケールの開示を要求することではありません。主張と証拠を一致させることです。Rumah Cloud が控えめなワークロードのために控えめなホスティングを販売する場合、購入者は控えめなフットプリントを受け入れることができます。クリティカルなアプリケーションをサポートしたい場合、名前の背後にあるテストされた復旧チェーンを示す必要があります。公開記録は現在、その会話の最初のステップをサポートしており、最終的な保証ではありません。

顧客が依存関係を監視する方法

Rumah Cloud に依存する顧客は、Web サイトのアップタイム以上のものを監視する必要があります。AS138868 が 103.140.54.0/23 をアナウンスし続けているかどうか、観測されたネイバーが変更されるかどうか、ルートオリジン検証が不明のままであるか改善されるかどうか、顧客ドメインの DNS が Rumah Cloud プレフィックスを指しているか外部サービスを指しているかどうか、およびインシデント中にサポートチャネルが到達可能なままであるかどうかを監視する必要があります。これらのチェックは複数のネットワークから行う必要があります。

監視は層を分離する必要があります。ルートの引き出しはサーバー障害とは異なります。Cloudflare が提供する Web サイトが稼働し続けても、ホスティングサービスが正常であることを証明するものではありません。到達可能な IP は、データベース、メールキュー、またはバックアップジョブが機能していることを証明しません。サポート電話回線が応答しても、その人がルートを復旧できることを証明するものではありません。各層には、独自の予想される動作とエスカレーション担当者が必要です。

顧客はまた、退出のリハーサルを行う必要があります。それはプロバイダーを放棄することを意味するものではありません。ホストされた環境が不適切または利用不能になった場合に、サイトファイル、アプリケーションデータ、構成、DNS レコード、ログ、およびアカウント情報を取得する方法を知ることを意味します。公開フットプリントの薄い小規模プロバイダーにとって、これが最終的な回復力のテストです。顧客は、逼迫したサポートキューを待たずに別の場所で再構築できますか？

リハーサルは控えめで実際的であるべきです。1 つの代表的なワークロードを復元します。計画的な DNS 変更を通じて 1 つのドメインを移動します。バックアップを取得して検証します。請求またはサポートアクセスが損なわれた場合に誰がアカウントのロックを解除できるかを確認します。顧客は、どのステップがセルフサービスで、どのステップがプロバイダーのアクションを必要とするかを知っておく必要があります。障害時には、その違いが顧客が計画を持っているか、希望だけを持っているかを決定します。

証拠グレード

CV. RUMAH CLOUD INDONESIA は中程度のネットワーク証拠グレードを獲得します。肯定的な証拠は具体的です。APJII は会社とドメインをリストし、APNIC と RIPEstat は AS138868 を CV. RUMAH CLOUD INDONESIA に結び付け、ASN はアナウンスされ、103.140.54.0/23 は現在可視であり、公開ルーティングサービスはネットワークエッジを観測できます。これらの事実は、同社を実際のインフラ依存性候補として扱うのに十分です。

限界も同様に具体的です。公開記録は、現在の 1 つの IPv4 集約アドレス、可視の IPv6 なし、1 つの観測されたネイバー、不明な RPKI 状態、PeeringDB プロファイルなし、およびまばらな公開 Web プレゼンスを示しています。公開記録は、製品範囲、施設の場所、マルチサイト容量、予備ハードウェア、サポートスタッフ、ルートフェイルオーバー、バックアップ配置、顧客データの取得、または復旧テストを証明していません。

実用的な結論は狭いです。Rumah Cloud は、可視ネットワーク面はライブだが集中している小規模なインドネシアのホスト型容量プロバイダーとして評価されるべきです。顧客はそのプロファイルを拒否する必要はありません。目を開いて購入する必要があります。適切なデューデリジェンスの質問は「これはクラウドですか？」ではありません。適切な質問は「最初の依存関係に障害が発生した場合、どのラック、ルート、サポートチャネル、およびデータパスが私のサービスを生かし続けるのか？」です。

ここで、同社の公開証拠は現在読者を残します。それは主題を特定し、アクティブなルートを示し、現在の公開ネイバーを指名し、不足している回復力の証明を強調します。残りは、重要なワークロードが約束に依存する前に、プロバイダーの開示、顧客契約、およびテストされた復旧エビデンスから来なければなりません。