PT. Arupa Cloud Nusantara は、ラック、トランジット、メンテナンスに依存するホステッドキャパシティを販売

要約

• PT. Arupa Cloud Nusantara は、単なるウェブホスティングブランドではない。同社自身のページには、2017年設立のテクノロジーアグリゲーターであり、350以上の顧客、50以上の販売パートナー、20以上のサービスとしてのソリューション、南ジャカルタの South Quarter Tower A にある現在の公開連絡先住所が記載されている。
• 同社は複数のレイヤーにわたるホステッドキャパシティを販売している：Arupa Compute、Virtual データセンター、Virtual Server、Private Cloud、Backup、Arupa Backup、Zerto ディザスタリカバリ、オブジェクトストレージ、マネージドクラウド、クラウド移行、そして2026年の Civo 発表によるインドネシアのワークロード向けソブリン Kubernetes クラウド。
• ネットワークの証拠は可視だが狭い。APNIC は AS136102 と AS137286 を PT. Arupa Cloud Nusantara のリソースとして識別；RIPEstat は2026年7月11日時点で両方の ASN が IPv4 でグローバルに可視であることを確認；PeeringDB は AS136102 に1 Gbps の OpenIXP / NiCE ポート、AS137286 に1 Gbps の DCI-IX ポートを示している。いずれの ASN についても IPv6 のアナウンスは公的情報源から見つかっていない。
• 未解決の運用テストは、言語的なものではなく物理的なものである。公開ページには柔軟なキャパシティ、迅速な復旧、ローカルコンプライアンス、マネージドサポートが記載されているが、ラック数、データセンターのリース制限、電力・冷却トポロジー、ハードウェアスペアパーツポリシー、バックアップのリストアテスト、マルチサイトフェイルオーバー演習、あるいはワークロードを移動する必要がある顧客のための移出手順は公開されていない。

クラウドの約束は現実だが、難しい問題はブランドの下にある

Arupa は、中小規模のクラウドプロバイダーを同時に二つの角度から分析しなければならない理由の良い例である。第一の角度は商業的側面：プロバイダーは何を誰に提供しているのか？この観点から見ると、同社の公的な足跡は単なるホスティング再販業者よりもはるかに強固である。同社のホームページは、企業、中小企業、テクノロジーパートナーに対してクラウド、データ、サイバーセキュリティソリューションを提供しているとしている。会社概要ページでは、Arupa Cloud Nusantara が2017年以来信頼されるテクノロジーアグリゲーターとして運営されており、350以上の信頼できるクライアント、50以上の販売パートナー、20以上のサービスとしてのソリューション、100％ローカルの専門知識を有すると記載されている。パートナープログラムページでは、MSP、システムインテグレーター、再販業者、ISV パートナーに対し、クラウドおよびデータセキュリティサービスを中心とした成長するエコシステムへの参加を呼びかけている。

第二の角度は物理的側面：悪い日に商業的な約束を実現させる機器、建物、経路、人材、契約は何か？これらの証拠はより薄い。同じ公開ページは柔軟なクラウドインフラ、ローカルエンジニア、迅速な復旧、インドネシア国内に保存されたデータを説明しているが、データセンターの部屋、ラック占有面積、電気設計、上流の引き渡しポイント、ハードウェア在庫、あるいはサポートのエスカレーション経路をほとんど名指ししていない。購入者はサービスカテゴリーを見ることはできても、Arupa の請求書から電源ユニット、スイッチ、ディスクシェルフ、ハイパーバイザークラスター、バックアップリポジトリ、そして人間のインシデント管理者に至る依存関係の連鎖を完全に追跡することはできない。

アイデンティティ、住所、Zettagrid の境界

Arupa の公的アイデンティティには、いくつかの重なり合うラベルが存在する。AS136102およびAS137286の APNIC 登録は PT. Arupa Cloud Nusantara を名指しし、IDNIC のコーポレート/ダイレクトメンバーとして記述し、以前の登録住所を Eightyeight@Kasablanka Office Tower, 18階, Menteng Dalam, Tebet, Jakarta Selatan としている。PeeringDB の組織プロフィールも PT. Arupa Cloud Nusantara を名指しし、Eighty Eight Kasablanka の住所で Zettagrid Indonesia というエイリアスを使用している。しかし Arupa の現在のお問い合わせページには、South Quarter, Jalan R.A. Kartini Kav. 8, Tower A, 9階, Cilandak Barat, South Jakarta と、マーケティングおよびサポートのメールアドレスが記載されている。

住所の違いは信号であって矛盾ではない。企業登記、レジストリ、相互接続、マーケティングの住所はしばしばずれている。しかしクラウドプロバイダーにとって、住所の正確さは重要である。なぜなら顧客は、どの場所がオフィスで、どれがネットワーク登録住所で、どれが本番機材を収容しているのかを知る必要があるからだ。Arupa の公開オフィスページは、South Quarter のオフィスがデータセンターであるとは主張していない。APNIC と PeeringDB は企業とその番号資源を識別するものであり、物理的なラック配置ではない。したがって、同社はオフィスおよび登録住所を持つ事業者兼テクノロジーパートナーとして理解されるべきであり、ホスティング基盤は別の場所にある。

Zettagrid というラベルも慎重に扱う必要がある。いくつかのページやサードパーティプロフィールは Arupa、Zettagrid Indonesia、あるいはその両方を使用している。Broadcom パートナー表彰の投稿は PT Arupa Cloud Nusantara を Zettagrid Indonesia として言及し、2024年の同様の表彰に続き、Crayon Indonesia から2025年の Broadcom パートナー賞を受賞したと述べている。これは、Arupa が VMware/Broadcom 指向のクラウドサービスエコシステムの一部であるという考えを裏付ける。しかし、これ自体は、各 Arupa サービスが Arupa 所有のハードウェア、Zettagrid によって運用されるインフラ、コロケーション、パートナークラウド、あるいはこれらのレイヤーの混合で提供されているかどうかまでは示さない。

Arupa が販売するもの：まずコンピュート、しかしそれだけではない

Arupa Compute のページは、この製品ファミリーを企業の成長に対応する柔軟で拡張性のあるインフラとして紹介している。このファミリーの中で、Virtual データセンターは、物理サーバーを所有することなく、サーバー、ストレージ、ネットワークの容量を顧客が制御できる、インドネシアの VMware クラウドとして位置づけられている。Virtual Serverは、数分で利用可能な高速で信頼性が高く柔軟なサーバーという、よりシンプルな VPS タイプの約束である。Private Cloudは、特定の組織のための専用クラウドインフラとして提示され、強化された分離と完全な制御を誇る。

これらは、物理的に異なる運用上のコミットメントである。仮想サーバーの顧客は、主に動作中の VM、ネットワーク到達性、スナップショットまたはバックアップ、そして進化の道筋を必要とする。仮想データセンターの顧客は、リソースプール、テナント分離、ネットワークセグメンテーション、ストレージパフォーマンス、管理プレーンの可用性を必要とする。プライベートクラウドの顧客は、予約されたハードウェア、予測可能なメンテナンスウィンドウ、ハードウェア交換の明示的なリードタイム、ライセンスとアプライアンスの明確な所有モデルを必要とするかもしれない。これら3つが単一のクラウドストーリーの下で販売されるならば、プロバイダーは各製品のキャパシティ限界を可視化しなければならない。

バックアップとディザスタリカバリは、この限界をさらに鋭くする。Backup のページは、このサービスが企業データを自動的に保護し復元すると述べている。Arupa Backupは、ローカルバックアップとクラウドバックアップ、ディザスタリカバリ、管理運用を組み合わせたオールインワンサービスと説明されている。別の立ち上げ記事では、Arupa Backupがデータバックアップ、データ復旧、ディザスタリカバリ、セキュリティ、モニタリング、さらに顧客サイトのハードウェアまで含み、Arupa の専門チームによって管理されるとしている。Zerto SecondSiteは、リアルタイムレプリケーション、秒単位の RPO、分単位の RTO を約束する。Active-Active DRは、恒久的なビジネス継続性を目標として掲げている。

これらの主張はいずれも、最も遅いレイヤーが十分に高速である場合にのみ真実となり得る。秒単位の RPO はレプリケーションの宣言であり、アプリケーションの書き込みスループット、リンク品質、レプリケーション遅延、ストレージレイテンシ、障害検出に依存する。分単位の RTO は復旧の宣言であり、手順、DNS、ファイアウォール変更、アプリケーション依存関係、アイデンティティシステム、データベース整合性、サポート承認に依存する。公開製品ページは顧客が受け取るべきものを述べるが、特定の顧客がそれを受け取れることを示すテスト証拠は述べていない。

オブジェクトストレージと Kubernetes が依存関係の地図を広げる

Arupa のストレージの話は VM のバックアップにとどまらない。同社のArupa Object Storage のページは、アーカイブ、バックアップ、メディアコンテンツ、ログ向けのストレージについて説明し、データは暗号化と規制コンプライアンス言語を伴ってインドネシアの Tier III データセンターに安全に保管されると述べている。後の記事では、Arupa がインドネシアで認定 MinIO リセラーとして3年間活動しており、S3 互換ストレージ、AI/ML、生成 AI、データレイクハウス、クラウドネイティブワークロード向けに MinIO AIStor を推進していることが示されている。

これは Arupa の市場での立ち位置を説明する助けとなる。同社は単なる汎用コンピュートスロットを販売しているのではない。クラウド、バックアップ、ストレージソフトウェア、ライセンス、そしてローカル実装を組み合わせている。これは、遠隔のセルフサービス型クラウドではなくローカルパートナーを求めるインドネシア企業にとって価値がある可能性がある。しかし、オブジェクトストレージはまた、異なる運用テストを提起する。重要な問題は、耐久性、イレイジャーコーディングまたはレプリケーションのポリシー、障害ドメイン、削除保護、不変性、リストア帯域幅、S3 互換性の制限、エクスポート経路、そして移行時やインシデント発生時のデータエグレス料金の負担者である。『オブジェクトストレージ』と書かれたスペックシートは、これらの質問に答えない。

Kubernetes レイヤーは別の依存関係を追加する。Arupa の2026年5月22日の記事は、同社がCivo との戦略的パートナーシップを結び、インドネシアに Kubernetes ベースのソブリンクラウドプラットフォームをもたらし、ローカルサポート、実装サービス、規制要件に関する支援を提供すると述べている。Civo のインドネシアページは、ジャカルタでホストされるインドネシアリージョンについて説明し、パブリッククラウドの自由とプライベートクラウドの制御を両立するように設計され、マネージド Kubernetes、コンピュート、マネージドデータベース、ロードバランサー、ローカルホスティング、インドネシアの個人データ保護法に準拠しているという。

Civo に関する証拠は、サービス意図（Kubernetes キャパシティ、ローカル法域、製品パートナーシップ）については強固である。しかし、本稿がテストする物理的な問いに対しては弱い。ジャカルタリージョンの背後にあるラック数、公開ページ上の施設のアイデンティティ、サイトのフェイルオーバー設計、オペレーターの組み合わせ、ハードウェアスペアパーツのプール、さらには Arupa の役割がリセラー、オペレーター、一次サポート、実装パートナー、あるいは顧客によって異なる組み合わせであるかどうかも公開されていない。慎重な解釈は、このパートナーシップが Arupa のクラウドネイティブな提供範囲を拡大する一方で、基盤となるサイト設計と復旧設計は顧客の契約文書で検証する必要があるというものである。

2つの ASN は運用ネットワークを示すが、完全なクラウドマップではない

ルーティング登録は、Arupa に最も強固な公的アンカーの一つを提供する。APNIC はAS136102を IDNIC-ARUPA-AS-ID として識別し、AS24538 と AS7717 からのインポートポリシー、AS23949 と AS7717 へのエクスポート、AS24538 へのデフォルトルートを登録している。また、AS137286を同じ AS 名で識別し、AS7717、AS17451、AS56258 からのインポート、これら3つの ASN へのエクスポート、AS17451 へのデフォルトルートを登録している。連絡先および不正利用報告の登録は Arupa を指している。

2026年7月11日時点でのAS136102 の RIPEstat ルーティングステータスデータは、利用可能な327の全 RIS IPv4 ピアがこの ASN を確認しており、可視 IPv4 プレフィックスは7つ、IPv4 アドレスは2,560、可視 IPv6 空間はなしを示していた。そのアナウンスプレフィックスデータは、2026年7月11日までの2週間の間に、103.10.148.0/22、103.90.250.0/23、103.90.250.0/24、103.90.251.0/24、103.145.194.0/23、103.145.194.0/24、103.145.198.0/23のプレフィックスを示していた。AS137286 の対応するルーティングステータスデータは、327ピア中327ピアが ASN を確認、可視 IPv4 プレフィックス3つ、IPv4 アドレス2,048、可視 IPv6 空間はなしを示し、そのアナウンスプレフィックスデータは49.128.188.0/22、103.90.248.0/23、103.145.196.0/23を示していた。

BGP.tools は独立してAS136102を4つの他ネットワークとピアリングし、2つの上流事業者（PT iForte Global Internet と Biznet Networks を上流として表示）を持つと表示している。AS137286は3つの他ネットワークとピアリングし、2つの上流事業者（Biznet Networks と PT PGAS Telekomunikasi Nusantara）を持つと表示している。同じページには、オリジネートされる IPv6 空間は表示されていない。これはネットワークが弱いことを意味しない。多くのインドネシアの企業/クラウドネットワークは現在も IPv4 優位である。これは、顧客の IPv6 に関する主張は、クラウド製品の存在から推定するのではなく、個別にテストされる必要があることを意味する。

ASN を完全なクラウドマップと混同してはならない。クラウドプロバイダーは、顧客のワークロードをパートナーの ASN、プライベート相互接続、トンネルサービス、パブリッククラウドリージョン、コンテンツネットワーク、あるいは顧客所有のプレフィックスの背後でホストすることができる。逆に、ASN はプロバイダー自身のプールではない下流または顧客のアドレス空間をオリジネートすることもある。AS 証拠は、Arupa がアクティブなインターネットルーティングを持っていることを示す。それは、すべてのテナント、ストレージクラスター、ハイパーバイザー構造、サポート経路を明らかにするものではない。

プレフィックスは Arupa 空間と顧客的な輪郭の両方を示す

プレフィックス証拠は重要なニュアンスを加える。APNIC は103.90.248.0/22を PT. Arupa Cloud Nusantara に割り当てられたポータブル空間として割り当てており、103.10.148.0/22および49.128.188.0/22の APNIC 登録は Arupa に割り当てられたポータブル資源である。これら3つのブロックは、企業資源の強力な証拠を構成する。

他の可視されるオリジン空間は、より慎重さを要する。103.145.194.0/23の APNIC 登録は、親割り当てが CV Qorner Organizer であることを示す一方、より詳細な IDNIC 103.145.194.0/24エントリは Arupa を名指している。APNIC の親割り当て103.145.196.0/23は CV Gweinity Elkalindo を名指し、より詳細な IDNIC /24は Arupa を名指している。APNIC の親割り当て103.145.198.0/23は CV Geowhan Multi Teknologi を名指し、より詳細な IDNIC /24は Arupa を名指している。

RADB のルートオブジェクト検索は、ルーティングの多層的な性質を強化する。AS136102 オリジン集合には、Biznet による Arupa として記述されたオブジェクト、プロキシ登録オブジェクト、iForte のトランジット顧客ルート、複数の RPKI 派生ルートオブジェクトが含まれる。AS137286 オリジン集合には、Biznet による Arupa、PGAS ルートオブジェクト、Level 3/Biznet ルートオブジェクト、RPKI 派生エントリが含まれる。これは、トランジット事業者を利用し、下流資源を運ぶ可能性のあるプロバイダーにとって珍しいことではない。しかし、これは顧客に対し、すべての経路が同じ種類の資産であると仮定すべきでないことを示している。

顧客の問いは実務的である。ワークロードが Arupa によって割り当てられたアドレス空間を使用する場合、ルートオブジェクト、RPKI、逆引き DNS、プレフィックス移植性を誰が維持するのか？ワークロードが顧客所有またはサードパーティの資源を使用し、Arupa によってオリジネートされる場合、契約紛争や障害後に、これらの経路はどれだけ迅速に別のプロバイダーに移管できるのか？Arupa が上流を変更した場合、有効な ROA でカバーされるプレフィックスはどれで、他者によって維持されるプロキシルートオブジェクトに依存するのはどれか？アドレッシングとルーティングは、会計上の瑣末事ではなく、ホスティングの移植性の一部である。

相互接続は OpenIXP と DCI-IX で可視

PeeringDB は、2つの異なる Arupa ネットワークプロフィールを示している。Arupa-JKT / AS136102はエイリアス Zettagrid Indonesia を持ち、6つの IPv4 プレフィックス、IPv6 プレフィックスなし、1～5 Gbps の帯域幅、主に入力の比率、オープンポリシーを表示している。その PeeringDB 交換接続はOpenIXP / NiCEであり、IPv4 アドレス218.100.27.158、1 Gbps ポートである。PT. Arupa Cloud Nusantara / AS137286は、3つの IPv4 プレフィックス、IPv6 プレフィックスなし、オープンポリシーをリストしている。その交換接続はDCI Indonesia DCI-IXであり、IPv4 アドレス103.142.207.31、1 Gbps ポートである。

これらの記録は、Arupa を2つの異なるインドネシアの相互接続コンテキストに位置づけるため有用である。OpenIXP / NiCE は、2010年まで遡る PeeringDB 履歴を持つインドネシアの交換プロフィールである。DCI-IX は Bekasi にリストされ、PeeringDB のDCI-IX 施設接続データは、JK1、JK2、JK3、JK5、H2-01、H2-02、E1、E2 を含む DCI Indonesia の施設内に位置づけている。DCI 自身のサイトは、DCI Indonesiaがインドネシアのデータセンタープラットフォームを運営し、5つのロケーション、9つのデータセンター、132 MW の総容量、クラウドプロバイダー、金融機関、企業、ISP を含む接続エコシステムを有すると説明している。

相互接続記録はデータセンター記録とは同じではない。1 Gbps の交換ポートは、有用なローカルピアリング、経路到達性、運用上の多様性をサポートできる。しかし、Arupa のコンピュートクラスターが同じ施設内にあること、DCI-IX ポートがそれらのクラスターへの唯一の経路であること、Arupa が交換に接続された各 DCI 施設にラックスペースを持っていること、あるいは OpenIXP と DCI-IX が別個の本番障害ドメインを提供していることを証明するものではない。記録は、Arupa が特定の交換ファブリック上で可視であることを証明する。これらのファブリックと顧客ワークロード間のトポロジーは公開されていない。

ホステッドキャパシティは設置されたハードウェアと同じではない

Arupa の販売ページは、一貫して柔軟性を強調している。仮想サーバーは迅速にプロビジョニング可能；仮想データセンターのキャパシティは物理サーバーへの投資なしに拡張可能；プライベートクラウドは専用インフラを提供；マネージドクラウドは運用の複雑さを低減する。これらの主張はクラウドサービスとしては通常のものである。欠けている公開情報は、その約束を裏付ける物理的なプールである。

コンピュートにとって、重要な区別は設置容量と使用可能容量の間にある。設置容量は、サーバー、ストレージシェルフ、スイッチポート、ハイパーバイザーライセンス、サイトの利用可能電力の合計である。使用可能容量は、障害、保守、ノイジーネイバー制御、バックアップウィンドウ、スナップショット、レプリケーション、管理システム、すでに販売された成長コミットメントのためにマージンを確保した後に残るものである。プロバイダーは通常状態では利用可能な CPU を持つことができるが、ホスト、ストレージノード、ラック PDU、または上流経路を1つ失った後に十分なレジリエントキャパシティを欠く可能性がある。

公開ページは、Arupa のラック数、サーバー世代、ストレージアーキテクチャ、オーバーサブスクリプションポリシー、スペアホスト比率、保守のための分離、管理プレーンの冗長性、あるいはハードウェア交換目標を示していない。これは、企業がこれらを欠いていることを意味するのではなく、購入者が公開証拠からキャパシティモデルを検証できないことを意味する。GPU-AI や Kubernetes に関する主張についても同様である。GPU サービスは、カード在庫、電力密度、冷却、ドライバスタック、クラスタースケジューラ、イメージレジストリ、ストレージスループット、スペアパーツ供給によって制約される。Kubernetes サービスは、コントロールプレーンの冗長性、ノードプール設計、ロードバランサーキャパシティ、etcd バックアップ、イメージプル、CNI の動作、アップグレード手順によって制約される。

ホスティングの経済性はここに圧力を生む。顧客はクラウドの弾力性を求める。プロバイダーはインフラを効率的に共有することで利益を得る。レジリエンスは利益を消費する。なぜなら、何かが故障するまで未使用のキャパシティを残すからである。それゆえ、証拠は単に「拡張可能」であるだけでは十分ではない。証拠とは、通常使用率、縮退モードでのマージン、損失テスト済みの最大コンポーネントを示すキャパシティ報告書である。Arupa の公開ページは提供内容を示している。本格的な購入者に必要な証拠は、エンジニアリング計画表である。

ローカリティはセールスポイントだが、完全なコンプライアンス対応ではない

データ主権は Arupa の現在の物語の中心にある。オブジェクトストレージのページは、データがインドネシアの Tier III データセンターにあると述べている。Civo パートナーシップは、ソブリンクラウドがインドネシアの組織に規制ニーズに合致したローカルインフラを提供することを示している。Civo のインドネシアページは、このリージョンがジャカルタでホストされ、データをインドネシアの法域内に保持し、インドネシア個人データ保護法に準拠していると述べている。インドネシアの電子システム枠組みは、インドネシアの電子システムプロバイダー規則セットで引用される規制であるPP 71 Tahun 2019によっても基礎づけられている。

ローカリティは、特に規制対象の顧客にとって価値がある。それは、管轄の不確実性を減らし、レイテンシを改善し、データアクセスガバナンスを簡素化し、顧客にローカルサポート経路を提供できる。しかし、ローカリティは完全な制御ではない。顧客は依然として、どのデータがローカルに保存され、どのテレメトリやサポートのメタデータがインドネシアを離れるのか、どのベンダーサポートチームがシステムにアクセスできるのか、暗号化キーがどのように管理されるのか、バックアップがどこにレプリケートされるのか、国境を越えたインシデント対応時に何が起きるのかを知る必要がある。

同じ点が「ソブリンクラウド」にも当てはまる。主権は、リージョンページに表示される国名に還元されるものではない。それは、契約文言、運用管理、サポートアクセス、法的手続き、キー保管、監査可能性、下請業者の開示、災害復旧設計、そして退出権である。ローカルクラウドは、これらの管理が明示的であれば、強力なソブリンオプションとなり得る。管理が定義されていなければ、複雑な国際スタックへのローカルなフロントエンドに過ぎない可能性もある。

Arupa の利点は、インドネシアのオフィスプレゼンス、ローカルエンジニア、インドネシアのネットワーク資源、ローカルパートナーサポートを組み合わせられることである。未解決の問いは、サービス契約がこのローカルプレゼンスを強制力のある管理に変えるかどうかである。購入者は、データローカリティのスケジュール、処理者/下請業者リスト、バックアップロケーションのマッピング、キー管理オプション、侵害通知手順、監査証拠、テスト済みのデータエクスポート経路を求めるべきである。

第一の故障経路：ラックまたは施設契約が最初に破綻する

Arupa にとってのリスクはラックレベルから始まる。顧客は仮想データセンター、バックアップリポジトリ、または Kubernetes ノードプールを購入する。その下では、キャビネット、電源ユニット、冷却ユニット、スイッチ、ストレージアレイの集合が動作し続けなければならない。Arupa がハードウェアを所有しているがデータセンタースペースを賃借している場合、サービスは施設運営者の電力、冷却、アクセス、遠隔対応のパフォーマンスに依存する。Arupa がパートナープラットフォームを利用している場合、サービスはそのプロバイダーのキャパシティ、保守、エスカレーション経路に依存する。Arupa が複数サイトでホストしている場合、顧客はどの製品が真にマルチサイトであり、どれが追加コストでのみバックアップや災害復旧オプションを利用可能かを知る必要がある。

公開データは、各サービスの本番施設を特定していない。DCI-IX での可視性は、本番ラックの場所を証明しない。Civo のページはジャカルタでのホスティングについて述べるが、施設名や詳細なトポロジーは示していない。オブジェクトストレージのページはインドネシアの Tier III データセンターに言及するが、そのストレージプラットフォームがシングルサイトか、複数サイトにレプリケーションされているか、単一サイト内でのイレイジャーコーディングによって保護されているかは示していない。Arupa の連絡先ページはオフィスを示しているが、データルームではない。

ラック障害テストは明確にされるべきである。ハイパーバイザーホストが故障したらどうなるか？ストレージシェルフが故障したらどうなるか？ラック PDU が故障したらどうなるか？施設が緊急保守ウィンドウを必要としたらどうなるか？残りのクラスターを過剰予約することなく、どれだけの顧客ワークロードを他の場所で再起動できるか？データセンターへのアクセス制限がディスク交換をどれだけ遅延させるか？どのサービスレベルでクレジットが適用され、どの復旧ステップがベストエフォートサポートに委ねられるか？

顧客は、サービスごとの依存関係カレンダーを要求すべきである。それは、本番サイト数、データセンター事業者、主張されている場合は施設の等級や認証、ラックと電力の責任分担、遠隔対応 SLA、Arupa が管理するハードウェアの在庫、ベンダーサポートのカバレッジ、計画保守の予告を含むべきである。これなしでは、「クラウド」という言葉は最初の障害ドメインを隠蔽するだけで、除去しない。

第二の故障経路：トランジットと IX の多様性は有用だが不完全

ルーティング登録は、Arupa に論理レベルでの多様性を与えている。BGP.tools では、AS136102 は iForte および Biznet の経路で可視であり、AS137286 は Biznet および PGAS の経路で可視である。PeeringDB は両方の ASN を異なる交換に配置している：AS136102 は OpenIXP / NiCE、AS137286 は DCI-IX である。これは単一の孤立したトランジットフローよりも優れている。

残る問題は物理的な多様性である。2つの ASN は依然として、建物、相互接続ルーム、都市圏ファイバー導管、光通信事業者、上流保守ウィンドウ、ルートオブジェクトメンテナ、あるいは顧客ファイアウォールを共有している可能性がある。Arupa の経路多様性を精査する顧客は、3つの地図を必要とする。第一は論理地図：上流 ASN、IX ピア、BGP ポリシー、受信プレフィックス、フェイルオーバー優先順位。第二は光地図：通信事業者名、接続タイプ、波長または Ethernet 回線、そして第一の復旧プロバイダー。第三は物理地図：建物進入点、垂直配線、導管、最初の多様化された合流点、共有される公共工事。

AS136102 と AS137286 の分離は、運用上有用である可能性がある。Arupa に異なるサービス、リージョン、顧客グループ、またはパートナープラットフォーム向けの別個のルーティングプレーンを提供できる。また、歴史的な変遷や異なる上流経済を反映している可能性もある。公開データからは、どちらの解釈が正しいか判断できない。実際的なテストは、ASN、IX ポート、上流、または施設経路の1つがサービスから外れた場合に、顧客ワークロードが到達可能な状態を維持できるかどうかである。

公的な IPv6 の不在も、顧客にとっての問題である。現在のインドネシアの多くのワークロードには重要でないかもしれないが、一部の規制された、エンタープライズ、またはクラウドネイティブ環境では、デュアルスタックがますます要求されている。RIPEstat と BGP.tools は、検証時点でいずれの ASN についても可視の IPv6 オリジンを示していなかった。Arupa が顧客向け IPv6 接続を販売している場合、購入者は、それが他の ASN、トンネル、パートナープラットフォーム、プライベートアドレッシングを介して提供されているのか、それとも現在はサービスの一部ではないのかを尋ねるべきである。

第三の故障経路：バックアップは、リストア帯域幅と権限次第でのみ価値がある

バックアップ製品は、無言のうちに失敗する可能性がある。バックアップは存在していても、復元が遅すぎるかもしれない。レプリカは最新でも、一貫性がないかもしれない。災害復旧計画は、復旧テストに含まれていないファイアウォール、ライセンスキー、DNS 変更、アイデンティティプロバイダー、ストレージマウントに依存しているかもしれない。Arupa のバックアップと災害復旧のページは商業的には明確である：ハイブリッドバックアップ、クラウドバックアップ、マネージドサービス、ランサムウェア対策、リアルタイムレプリケーション、秒単位の RPO、分単位の RTO を強調している。公開証拠は、リストアテストを示していない。

Arupa Backup にとって、難しい問題はリストアの範囲と権限である。顧客データがオンプレミスと Arupa クラウドの両方にある場合、誰がいつフェイルオーバーするかを決めるのか？ランサムウェアが疑われる場合、誰がリカバリポイントを検証するのか？ローカルハードウェアがサービスに含まれている場合、誰が交換在庫とサポートを所有するのか？顧客がインシデント後に Arupa を離れたい場合、マネージドサービスのチケットを待たずに、標準フォーマットで完全なバックアップをエクスポートできるか？バックアップリポジトリが単一のインドネシアのデータセンターでホストされている場合、施設規模の停止からそれを保護するものは何か？

Zerto タイプのレプリケーションにとって、主要な変数は、ジャーナル履歴、帯域幅、書き込み順序の忠実性、テストネットワーク分離、フェイルバック、アプリケーション依存関係のマッピングである。単一の VM は迅速に復旧できる。データベース、アプリケーションサーバー、ファイルストレージ、アイデンティティ、VPN、サードパーティ API 依存関係からなるビジネスサービスは復旧できないかもしれない。公開ページは、製品の能力と、特定の顧客の復旧検証を区別していない。

最良の証拠は、匿名化されたテスト証跡であろう。Arupa は、一般的なデータサイズのリストアベンチマーク、計測されたフェイルオーバー演習、輻輳時の最大サポートレプリケーション遅延、バックアップの不変性オプション、顧客が実行する復旧テスト手順、本番フェイルオーバーを承認できる者を示すカレンダーを公開することができる。これらの開示は顧客の秘密を明かすものではない。復旧の約束が単なるパンフレット以上のものであることを示すであろう。

第四の故障経路：サポート要員と移行もキャパシティである

Arupa は、製品の一部としてローカル専門知識を販売している。会社概要ページはローカルエンジニアを強調している。マネージドクラウドサービスは、Arupa が実装、保守、セキュリティを管理することで、パートナーが自らのビジネスに集中できると述べている。クラウド移行は、パブリッククラウド、プライベートクラウド、ハイブリッド環境から、構造化され低リスクなアプローチ、ローカルコンプライアンス、透明性のあるコストでワークロードを移行するとしている。実装サポートは、専門的な実行、リスク低減、ローカル技術サポートに焦点を当てている。

これは、多くの顧客が自分たちでクラウドインフラストラクチャーを運用したくない市場において、真のサービス上の利点である。しかし、サポート要員も有限の資源である。通常の移行時には、同じ専門家チームが発見、カットオーバー、最適化、文書化を導くことができる。地域的なインシデント時には、同じチームが同時に多くの顧客から求められる可能性がある。製品が高度なサポートに依存している場合、顧客は Arupa がどのようにインシデントに優先順位をつけるか、時間外のエスカレーションを担当するエンジニアの数、自動化されているタスク、主要ベンダーも会議ブリッジに参加しなければならない場合に何が起きるかを尋ねるべきである。

移行は別の種類のロックインを生み出す。Arupa は顧客の自社環境への移行を支援できるが、それだけで顧客が迅速に退出できることを自動的に証明するわけではない。退出は、データフォーマット、VM エクスポート、ネットワーク再アドレッシング、DNS、オブジェクトストレージ互換性、バックアップの回復、ライセンス移植性、依存関係の文書化、エグレス帯域幅に依存する。顧客の現在の唯一のバックアップが Arupa のマネージドサービス内にある場合、紛争や停止中にプロバイダーを離れることは、入るよりも難しいかもしれない。

したがって、公開ページはサービスへの招待として読まれるべきであり、退出の保証としてではない。真剣な顧客は、契約前に移行および逆移行のランブックを要求すべきである。この要求は対立的なものではない。これは、クラウドプロバイダーが自らの運用に対する自信を証明する方法である：顧客の参入を支援できるのは、顧客がどのように回復または退出できるかも知っているからである。

影響を受ける顧客はしばしばパートナーの顧客である

Arupa のパートナーとしてのポジショニングは、影響範囲を変える。直接のエンタープライズ顧客は、自分が Arupa のコンピュート、バックアップ、またはマネージドサービスを購入していることを知っているかもしれない。MSP、システムインテグレーター、再販業者の下流の顧客は、管理されたアプリケーション、バックアップポータル、災害復旧条項、または他社の関係の下で販売されたプライベートクラウドパッケージを通じて、間接的にのみ Arupa を体験するかもしれない。パートナープログラムページは、Arupa がエコシステム内に MSP、システムインテグレーター、再販業者、ISV パートナーを求めていることを明示している。このモデルは商業的に理にかなっている。それはまた、インシデント時のコミュニケーションが複数の組織を経由しなければならないことを意味する。

単純なホスティング障害では、サービスの所有者とインフラプロバイダーは同一企業である。パートナー駆動のクラウドスタックでは、影響を受ける最終顧客は再販業者に連絡し、再販業者は Arupa に連絡し、Arupa はデータセンター事業者、通信事業者、Civo、MinIO、VMware/Broadcom、Veeam、Zerto、あるいは他のベンダーに対応を要請する必要が生じるかもしれず、顧客はどの依存関係が制約要因かを知らないかもしれない。これはチャネル販売への批判ではない。サポートの連鎖がキャパシティ上の制約であることを再認識させるものである。同じインシデントで多数のパートナーが連絡してきた場合、Arupa のエンジニアリングベンチ、チケットトリアージ、ベンダーエスカレーション権限、顧客コミュニケーションモデルがインフラの一部となる。

課金もまた故障経路の一部となり得る。クラウドプロバイダーはしばしば、コンピュート、ストレージ、バックアップ保持、IP アドレス、マネージドサポート、データエグレスを個別の課金要素として扱う。Civo のインドネシアページは、マネージド Kubernetes の予測可能な料金を強調し、グローバルハイパースケーラーとの月額リソースコストを比較している。Arupa の移行ページは、顧客がコストの透明性を得られると述べている。これらは前向きなシグナルである。しかし顧客は、災害復旧テスト中、長期復旧中、緊急リストア、データエクスポート、移行失敗、課金停止、ライセンス権利の失効、または契約解除の際に、料金がどのように発生するかを知る必要がある。技術的には利用可能であっても、金銭的に復旧コストが高いバックアップサービスは、依然として不十分な復旧ツールである可能性がある。

ハードウェア在庫は第三の静かな制約である。Arupa のページはローカル専門知識とマネージド実装を説明しているが、スペアのサーバー、ディスク、コントローラー、光学機器、ファイアウォール、バックアップアプライアンス、または GPU カードを開示していない。プロバイダーは優れたエンジニアを抱えていながらも、ベンダーRMA、通関手続き、パートナー承認、施設アクセス枠を待たなければならないかもしれない。プライベートクラウドやオンサイトバックアップハードウェアを購入する顧客は、交換部品がインドネシアに保管されているか、Arupa がそれを所有しているか、顧客が所有しているか、そして故障がサポートチケット問題ではなくベンダー調達問題である場合に SLA が変わるかどうかを尋ねるべきである。

したがって、実務的なデューデリジェンスの問いは、単に「Arupa はチケットに対応するか？」ではない。「サービスが復旧するまでに他に誰が行動しなければならないか、技術インシデントがまだ進行中の場合にビジネス関係が緊張したらどうなるか？」である。チャネル志向のプロバイダーは、これらの引き継ぎを可視化することで信頼を獲得する。重大度レベル、顧客対パートナーの通知義務、ベンダーエスカレーション権限、時間外の連絡先、復旧コストルール、データエクスポート料金、交換在庫の前提、インシデント発生前の退出支援を定義すべきである。公的な主張がローカルサポートとパートナーの成功に大きく依拠する Arupa にとって、これらの運用詳細は二義的ではない。これらは、キャパシティが不足したときに顧客が最初に感じるクラウドの一部である。

どのような証拠が評価を改善するか

Arupa は、機密の顧客データを開示することなく、公的な運用イメージを大幅に強化できる。第一に、高レベルのサービスロケーションマトリックスを公開することができる：どの製品がどのインドネシアの地域または施設クラスで動作するか、どれがシングルサイトか、どれがレプリケートされているか、どれがオプションの災害復旧を持つか、どれがパートナープラットフォームを使用するか。このマトリックスはラック数を示す必要はない。オフィス、レジストリ、交換、本番コンピュート、バックアップの場所を分離すべきである。

第二に、各製品ファミリーのキャパシティとレジリエンスの概要を公開することができる。コンピュートについては、ハイパーバイザークラスターの冗長性、ストレージ保護方式、通常マージン、縮退モードマージン、保守ポリシーを意味する。バックアップについては、リポジトリの場所、保持オプション、不変性、リストア帯域幅、テストされたリストア時間を意味する。オブジェクトストレージについては、データ配置ポリシー、耐久性モデル、S3 互換性の制限、キー管理、エクスポート手順を意味する。Kubernetes については、コントロールプレーン設計、ノードプールの障害ドメイン、ロードバランサーモデル、アップグレードウィンドウ、クラスターバックアップを意味する。

第三に、顧客に適した用語でネットワークの説明を整理することができる。AS136102 と AS137286 が分離されている理由は？どのサービスがどの ASN を使用するか？いずれかが顧客向け IPv6 を提供しているか？OpenIXP と DCI-IX は、本番トラフィック、管理トラフィック、ピアリング最適化、バックアップ経路のいずれに使用されるか？どのプレフィックスが Arupa に属し、どれが顧客または下流のプレフィックスか、RPKI/ルートオブジェクトの保守はどのように行われるか？

第四に、インシデントおよび移行手順の例を公開することができる。これには、サポートのエスカレーション、顧客通知、保守予告、データエクスポートオプション、停止中の課金継続性、Arupa または顧客がフェイルオーバーを開始できる条件を含めるべきである。最も信頼できるクラウドプロバイダーは、退屈な手順を可視化する。そこに信頼が宿るからである。

現在の証拠の評価は、否定的というよりは混合である。Arupa の公開製品幅、ネットワーク可視性、ローカルポジショニングは、多くの小規模ホスティングプロバイダーよりも強固である。物理キャパシティの開示は、サービスの幅よりも弱い。このギャップこそが、まさに顧客のデューデリジェンスが集中すべき点である。

有用なローカルクラウドは可視化された制約に依存する

インドネシアはより多くの信頼できるローカルインフラの選択肢を必要としている。すべてのワークロードがグローバルなハイパースケールモデルに閉じ込められるべきではないし、すべての企業が自前でバックアップ、Kubernetes、ストレージ、移行、コンプライアンスサポートを組み立てたいわけではない。Arupa の公的プロフィールは、この需要に応えるものである。ローカルな販売とサポート、クラウドコンピュート、バックアップ、オブジェクトストレージ、災害復旧、MinIO 販売、Broadcom/VMware エコシステムシグナル、ソブリンクラウドとしての Civo ポジショニングを組み合わせている。また、同社が単なる製品パンフレットだけの抜け殻ではないことを示す、アクティブなインドネシアのルーティング資源も有している。

次の敷居は、より多くの製品名ではない。それは制約の可視化である。ホステッドキャパシティを購入する顧客は、キャパシティがどこにあり、どのラックを占有し、どの上流がそれを運び、どの程度のマージンが障害に耐え、誰が交換部品を持ち、誰が施設に入ることができ、どの復旧テストが合格し、関係やプラットフォームが破綻した場合にデータをどのように移動できるかを知る必要がある。これらの問いは、Arupa のビジネスケースを弱めるものではない。これらは、ワークロードが重要な顧客にとって、投資可能なものとするのである。

Arupa の最良の公的テーゼは、インドネシア企業がローカルサポート付きでローカルクラウドキャパシティを購入できるというものである。その公開証拠は、企業、製品、ルーティングの各レベルでこのテーゼを支持している。しかし、独立して検証可能なマルチサイトレジリエンスの主張はまだ十分に支持していない。施設と復旧に関するより多くの証拠が公開されるまで、PT. Arupa Cloud Nusantara は、顧客価値が公開クラウドの約束の背後にある非公開の計画表—ラック、トランジット、ハードウェア在庫、サポート要員、バックアップテスト、移行権利—に依存する、運用上のインドネシアのクラウドおよびテクノロジーサービスプロバイダーとして扱われるべきである。