PT. INDONESIA SUPER CORRIDOR - データセンターは、宣伝されているデータセンター容量が電力と通信事業者の制約に耐えられるかどうかを証明しなければならない

概況

• PT. INDONESIA SUPER CORRIDOR - データセンターは、今回のバッチにおいて異例なほど具体的な公開シグナルを持っている：ISC サイトでは Mampang Prapatan にある550ラックの Tier IV データセンター ISC MPR を宣伝しており、ISC の企業概要ページでは Cyber 1内でネットワークとデータセンター設備を構築したと述べ、Uptime Institute のクライアントページには ISC データセンター DPR、ISC データセンター Cyber-1 Building CBR Level 9、データセンター ISC MPR に対する発行済み認証が掲載されている。
• ルーティングの実態は本物だが範囲は限定的である。APNIC RDAPでは AS142379 が PT. INDONESIA SUPER CORRIDOR - データセンターの ISC-DC-AS-ID と命名されており、RIPEstatでは2026年7月12日時点で6件の現行 IPv4 /24アナウンスと完全な RIS IPv4 可視性が示されたが、現時点での IPv6 可視性はなく、観測された AS 隣接は1件のみだった。
• 主なデューデリジェンスのギャップは、ISC ブランドのデータセンター事業が存在するかどうかではない。宣伝されているラック、クラウド、ディザスタリカバリのサービスが、電力、通信事業者、設備の状況が不安定になった場合に、生産ワークロードを支えるのに十分な開示済みのユーティリティ供給、発電機稼働時間、冷却冗長性、接続拠点の多様性、顧客フェイルオーバーテスト、退出手順を備えているかどうかである。

ISC はディレクトリのプレースホルダー以上の存在

一部のインフラプロファイルは、薄いレジストリエントリから始まり、その後ほとんど発展しない。PT. INDONESIA SUPER CORRIDOR - データセンターは異なる。同社はBTW ディレクトリ、自社の公開サービルページ、Uptime Institute の認証データベース、自社のエクスチェンジや組織に関する PeeringDB レコード、そしてライブルーティング観測でその存在が確認できる。それだけでは運用ケースが完全とはいえないが、問いの質を変える。これは存在しないかもしれない建物を探す調査ではない。問題は、施設や製品パッケージに関する公開記録は強いが、測定された顧客の復旧実績が十分でない、マーケティングされたデータセンタープラットフォームに対する信頼性の評価である。

ISC のホームページは、「インドネシア、ジャカルタ、マンパン・プラパタンにある Tier IV データセンターISC MPR（5MW）で550ラック利用可能」という具体的な主張を掲げている。また、フルラックスタイルのオファーとして、100 Mbps の IIX と10 Mbps の IX、10A 電源、/29のパブリック IP 割り当て、2本の UTP と2本の光ファイバークロスコネクトを広告している。同じページには、施設は安全で、24時間有人、CCTV モーション検出で保護され、PIN とカードでアクセス制御されていると記されている。これらは曖昧なクラウドの形容詞ではない。ラック、電力、クロスコネクト、物理アクセスに関する具体的な主張である。

企業概要ページは、より古い Cyber 1の文脈を加えている。ISC は、ジャカルタの Cyber 1で自社ネットワークとデータセンターを構築したことに始まり、当初は高可用性を備えた信頼性の高いマルチホームマネージドネットワークを提供したと説明している。また、顧客のカード holder データを保管、処理、または伝送する際には PCI DSS の責任を維持しているとも述べている。同じページでは、ISC がインドネシアのインターネットエクスチェンジ環境の中心に位置し、独立した配電盤による二重電源の耐障害性を主張し、サービスを Tier III 施設品質に位置付けている。これもまた、立地、電力配分、ネットワークリーチ、コンプライアンス義務という物理インフラのストーリーである。

Uptime Institute は、完全な運用評価ではないものの、そのストーリーに独立した形を与えている。PT Indonesia Super Corridor のクライアントページには、認証が発行された3サイト（デンパサールの ISC データセンター DPR、ジャカルタの ISC データセンター Cyber-1 Building CBR Level 9、データセンター ISC MPR）が掲載されている。Uptime のインドネシア国別認証リストには、ISC が他の認定インドネシア施設と並んで掲載されている。バイヤーは、Uptime 自身のティア認証資料が設計、建設施設、運用認証を区別しているため、認証の種類と範囲を注意深く読むべきである。しかし、この認証データベースは、ISC が評価に値する施設を持っているという前提を裏付けており、単なるブランドページではない。

これにより、このアサインメントの運用ステータスに関する注意が一層有用になる。公開証拠が乏しい場合の答えはしばしば「信頼するな」である。公開証拠が具体的だが不均一な場合のより良い答えは「存在するものとサバイバビリティのあるものを区別せよ」である。ISC の公開記録は、施設の存在、サービスマーケティング、エクスチェンジに面したネットワーク役割、アクティブな IPv4 ルーティングを裏付けている。しかし、マーケティングされた容量の背後にあるすべての顧客クリティカルな詳細（実際に占有されているラック、予約済み電力、発電機燃料契約、多様なキャリア引き込み経路、冷却フェイルオーバーテスト、過去のインシデント対応、バックアップの独立性、ISC によって販売されたクラウド容量と単に ISC スペースにハウジングされた顧客機器の違い）を公的に証明しているわけではない。

資産マップには、単一の汎用データルームではなく、3つの名称付き施設が存在する

ISC のナビゲーション自体が、CBR、MPR、バリのディザスタリカバリページにデータセンターストーリーを分割している。データセンター Tier III CBR ページは、99.982%のサービスレベル数値を伴う U 単位、ハーフラック、フルラックのコロケーションオファーを宣伝し、IIX および IX 帯域幅、IP 割り当て、アクセス権、トラフィック監視、スマートハンドサポート、DCIM アカウントを提供している。そのページのフルラックパッケージは、100 Mbps IIX、10 Mbps IX、/29のパブリック IP 範囲、5回のデータセンターユーザーアクセス、2つの UTP クロスコネクトポート、2つのファイバーコアを宣伝している。これは ISC の Cyber 1に面したレガシーな部分である。

データセンター Tier IV MPR ページは、より高い可用性をアピールしている。U 単位、ハーフラック、フルラックのコロケーションパッケージに99.995%のサービスレベル数値を宣伝し、IIX/IX およびコンテンツキャッシュの文言を繰り返し、クラウドビジネスおよびクラウドエンタープライズのオファーを追加している。これらのクラウドパッケージは、1 Gbps の IIX、OIXP、Equinix IX 接続、最大4 GB または32 GB のメモリ、最大80 GB または640 GB のストレージ、1つのパブリック IP、1つの Linux OS、1 Gbps ポート、最大30 Mbps の国際帯域幅を主張している。このバンドルは、ISC をコロケーション専業から、顧客が自身の機器だけでなく ISC が運用するコンピュート、ネットワーク、ストレージに依存するホスト型インフラストラクチャプロバイダーに変えるという点で重要である。

DRC Tier III Bali ページはリカバリの視点を提供している。デンパサール施設をディザスタリカバリセンターとして位置付け、RPO と RTO の概念を宣伝し、複数のエクスチェンジへのギガビット接続、相互接続された光ファイバー設計、2つの異なる電圧源からの耐障害性電源、完全バックアップ発電機容量、床下および床上の FM200 煙検知、24時間365日の CCTV、カードおよび指紋アクセス、冗長システムを備えた精密空調について説明している。これらは、企業が顧客から質問される障害経路（一次インフラ障害、ファイバー断絶、電源障害、火災、冷却）を特定しているため、有用な主張である。

サードパーティの施設ディレクトリは、複数の ISC サイトの存在を裏付ける一方で、バイヤーが無視すべきでない容量ノイズをもたらす。Baxtel の ISC 企業ページは、ISC が1リージョンで2つのデータセンターを運営し、6 MW をリストしていると記載し、ISC Tower ページは、MPR サイトを南ジャカルタの Tier IV データセンター、550ラック、真の2N UPS デュアルパス耐障害性、ディーゼル発電機、IPv4/IPv6 サポートを備えると説明している。Datacenters.comは ISC のインドネシア3ロケーションをリストし、そのMPR ページは6,500平方フィート、1,791平方フィートの二重床面積、16.0 MW の電力を報告している。これらの数字は ISC 自身の5 MW というヘッドラインや、最大8 MW の IT 負荷を示す LinkedIn スタイルの市場シグナルとは一致しない。この不一致は虚偽記載の証拠ではない。サードパーティディレクトリは遅れたり、推定したり、建物電力と IT 負荷を混同したりする可能性がある。しかし、これは顧客が最新の容量スケジュールを要求すべき理由そのものである。

有用な結論は、ISC を単一の資産に矮小化すべきではないということである。CBR、MPR、バリ DRC は公開ストーリーの別個の構成要素として現れる。リスクは、公開ページがこれらの運用境界を曖昧にすることである。どのラックが Cyber 1にあるのか？どのクラウドパッケージが MPR から提供されるのか？どのワークロードが実際にバリにフェイルオーバーできるのか？宣伝されているエクスチェンジ接続は各ルームで利用可能なのか、それとも ISC のより広範なネットワークを通じてのみか？顧客が「Tier IV」サービスを購入した場合、サービスパス内のすべての依存関係がその Tier IV の範囲内にあるのか、それとも管理ポータル、サポートシステム、上流回線、課金、バックアップリポジトリが他のルームにあるのか？これらの質問が使用可能な耐障害性を定義する。

マーケティングされた容量には変換係数が必要

「550ラック利用可能」というヘッドラインは、具体的な規模を示すため強力である。バイヤーはケージ、キャビネット、クロスコネクト、電源ケーブル、顧客展開を想像できる。しかし、データセンター容量は決してラック数だけではない。使用可能な容量とは、オーバーサブスクリプションが障害リスクに変わらない範囲で販売可能なスペース、電力、冷却、ネットワークハンドオフの量である。

ISC 自身の MPR ページは、この変換問題を説明するのに役立つ。フルラックオファーには、10A 電源、/29パブリック IP 割り当て、トラフィック監視、スマートハンドサービス、2つの UTP ポート、2つのファイバーコアが含まれる。これはエンタープライズコロケーションにとって実用的なバンドルだが、550ラックすべてが継続的に10A を引き出せる、すべてのラックが同じ電力密度を持つ、あるいは最新の AI や高密度ストレージ負荷で各ラックを稼働させるのに十分な冷却と上流帯域幅が存在するという声明と同義ではない。従来のエンタープライズラックを低密度で使用するのと、GPU や高性能ストレージラックを使用するのでは大きく異なる。ISC の公開ページは、密度制限、PUE、冷却設計温度、電力使用上限、ブレーカーポリシー、フェーズごとの実際の販売可能 IT 負荷を公開していない。

同じ注意がクラウドパッケージにも当てはまる。MPR および CBR ページは、99.9%のサービスレベル数値、メモリとストレージの制限、1つのパブリック IP、1つの Linux OS、1 Gbps ポート文言、最大30 Mbps の国際帯域幅を備えた「Cloud Business」と「Cloud Enterprise」を宣伝している。これらの条件はラックオファーよりも小さく聞こえ、大規模コンピュートではなく通常のビジネスワークロードを対象としている可能性がある。クラウド VM は耐障害性のある施設からプロビジョニングできるが、顧客の耐障害性はホストクラスタリング、ストレージレプリケーション、バックアップ配置、ライブマイグレーション機能、スナップショットエクスポート、メンテナンスポリシー、ネットワークパスに依存する。公開製品ページはサービスパッケージングを示しているが、仮想マシンの下にあるアーキテクチャは示していない。

現在のデータセンター市場において、電力は最も重要な変換係数である。IEA の Energy and AI レポートは、データセンターの電力消費が2030年までに全体の電力需要よりもはるかに速く増加すると予測している。この圧力はグローバルだが、建物ごとにローカルに着地する。各建物は、ユーティリティ接続、配電盤、UPS 容量、冷却容量、発電機サポート、燃料ロジスティクス、拡張許可を必要とする。ISC の5 MW MPR ヘッドラインはその文脈では意味があるが、それだけでは不十分である。顧客は、その数値がユーティリティ容量、建物容量、IT 負荷、将来の設計容量、あるいは既存顧客、冗長マージン、メンテナンス余裕を差し引いた現在販売可能な確定容量なのかを知る必要がある。

ISC は、ユーティリティ総供給容量、確定 IT 負荷、利用可能販売可能負荷、平均および最大ラック密度、UPS トポロジー、発電機燃料稼働時間、燃料補給契約、メンテナンスバイパス設計、冷却冗長性、99.995% MPR 数値の背後にある仮定といった退屈な開示によって、曖昧さの多くを取り除くことができる。公開ページは、複数の場所でデュアルソース電源とバックアップ発電機を宣伝している。それは出発点である。1つのユーティリティソース、1つの UPS モジュール、1つの冷却ユニット、または1つの燃料供給経路が利用できない場合に何が起こるかを示す顧客対応の容量モデルと同じではない。

これが、運用テーゼを存在についてのみ「薄い公開フットプリント」からアップグレードすべき理由であり、耐障害性についてはそうでない理由である。ISC には可視的なフットプリントがある。ダウングレードは、マーケティングされた容量が監査済み容量にならなければならない地点で発生する。バイヤーが控えめな消費電力の通常のコロケーション機器を配置する場合、公開証拠はサイト訪問と提案依頼を正当化するのに十分かもしれない。バイヤーが遅延に敏感な金融システム、公共部門向けワークロード、ディザスタリカバリインフラ、高密度コンピュートを配置する場合、公開証拠は十分ではない。それらの顧客は、容量証明書、トポロジー文書、フェイルオーバー証拠、およびサービスレベルを使用する正確なルーム、ラック、ネットワークパスに結び付ける契約文言を必要とする。

ネットワーク証拠はライブだが、幅広くはない

AS142379 はディレクトリエンティティのルーティングアンカーである。AS142379 の APNIC RDAPは、自律システムを「ISC-DC-AS-ID」と命名し、保有者のコンテキストをインドネシアの PT. INDONESIA SUPER CORRIDOR - データセンターとしている。その管理および技術連絡先データは ISC のメールアドレスを示し、障害連絡先データは Cyber Building 所在地の ISC hostmaster アドレスを使用している。これは強力なレジストリアイデンティティ証拠である。

IP リソースの全体像は CNI グループの境界を示している。103.91.24.0の APNIC RDAPは、103.91.24.0 - 103.91.27.255ブロックを CNI-ID としてリストし、ジャカルタのインターネットサービスプロバイダーである PT Cyber Network Indonesia のポータブルアドレススペースとして割り当てている。123.253.248.0の APNIC RDAPも同様に、123.253.248.0 - 123.253.251.255を CNI-ID としてリストしている。これは ISC の公開記録やサードパーティ記録が繰り返し CNI Group コンテキスト内に ISC を位置付けているため、ISC の運用ケースを弱めるものではない。これは、顧客がどの法的主体および運用主体がアドレス空間、施設、エクスチェンジ、顧客契約を管理しているのかを理解すべきであることを意味する。

RIPEstat の AS 概要は、2026年7月12日に AS142379 がアナウンスされていると報告し、保有者を ISC-DC-AS-ID - PT. INDONESIA SUPER CORRIDOR - データセンターと命名した。RIPEstat のアナウンスされたプレフィックスエンドポイントは、6つの現行 IPv4 /24：103.91.24.0/24、103.91.25.0/24、103.91.26.0/24、103.91.27.0/24、123.253.248.0/24、123.253.249.0/24を示した。RIPEstat のルーティングステータスデータは、クエリ時に325中325の IPv4 RIS ピアすべてがこのルートセットを観測し、1,536の IPv4 アドレスがアナウンスされ、現時点では RIS に可視な IPv6 アナウンスはないことを示した。

これは到達可能性の良い証拠であるが、完全な多様性のストーリーではない。RIPEstat の ASN 隣接データは、観測された隣接 AS が1つ（AS38496）のみであることを示した。AS38496 の APNIC RDAPは、その AS を PT Cyber Network Indonesia の CNI-AS-ID と識別している。これは、AS142379 がグローバル BGP で可視な複数の独立した外部上流プロバイダーを持っている証拠ではなく、内部またはグループ関連の上流/集約関係のように見える。施設顧客がキャリアの多様性を必要とする場合、問いは「ISC はアドレスをルーティングするか？」ではない。問いは「私のサービスが実際に使用できる物理的な引き込み経路、キャリアクロスコネクト、上流ポリシーはいくつあるか？」である。

ルートセキュリティは明るい点である。RIPEstat の103.91.24.0/24の RPKI 検証および123.253.248.0/24の RPKI 検証は、どちらもクエリ時に AS142379 に対して有効なステータスを返した。RPKI の有効性は障害を防ぐものではなく、施設の多様性を証明するものでもないが、実際のルーティング衛生シグナルである。これは、オリジン誤表記リスクの1つのクラスを低減し、CNI/ISC アドレス環境が完全に放置されたルーティング面ではないことを示す。

IPv6 は弱いシグナルである。Baxtel は ISC Tower が完全に IPv4 対応で IPv6 をサポートしていると記述し、ISCX は IPv4 と IPv6 のピアリングを宣伝している。しかし、RIPEstat の現在の AS142379 ビューでは、クエリ時に可視な IPv6 プレフィックスはなかった。これは、IPv6 が他の ASN、エクスチェンジ LAN、顧客ネットワークを通じて提供されているか、現在 AS142379 によってオリジネートされていない可能性があることを意味する。バイヤーにとって、実用的なポイントは単純である：マーケティング文言からデュアルスタックサービスを想定しないこと。どの ASN が顧客 IPv6 をオリジネートしているか、クラウドパッケージが IPv6 を含むか、RPKI がカバーしているか、IPv6 パスが IPv4 と同じ監視とサポートを受けているかを尋ねること。

ISCX は戦略的に有用だが、すべての顧客パスを証明するわけではない

ISC のエクスチェンジストーリーは真の資産である。ISCX サイトは、「インドネシアにおける Tier IV データセンターサポート付きコネクティビティインターネットエクスチェンジポイント」と説明し、IXP Manager アクセス、トラフィックステータス、MAC アドレスおよび IRR フィルター更新、監視ダッシュボード、ルートサーバーサポート、ルッキンググラス、BGP コミュニティ、IRR フィルタリング、RPKI を挙げている。PeeringDB の ISCX ページは、ジャカルタの PT. Indonesia Super Corridor の下で ISCX Internet Exchange をリストし、ウェブサイトhttp://iscx.isc.id、技術連絡先フィールド、2025年6月の更新タイムスタンプを掲載している。PeeringDB の PT. Indonesia Super Corridor 組織ページは、Cyber 1の住所コンテキストを提供し、エクスチェンジ対応レコードの背後にある組織を特定している。

データセンター事業者にとって、エクスチェンジは生のトランジットと同じくらい重要になり得る。国内レイテンシを低減し、トラフィックをローカルに保ち、コンテンツおよびアクセスネットワークを引き付け、キャリアが建物内に存在を維持する商業的理由を生み出すことができる。ISC のページは、サービスバンドルにおいて IIX、OIXP、Equinix IX を繰り返し言及している。そのクラウドオファーは IIX、OIXP、Equinix IX への1 Gbps アクセスを主張し、コロケーションページは IIX および IX 帯域幅をラックプランにパッケージ化している。これらの主張は、スペースと電力だけでなく、インドネシアの相互接続への近接性を販売する施設に適合する。

注意点は、エクスチェンジの存在と顧客冗長性は別物であるということだ。ルートサーバー、IXP Manager、ルッキンググラスは、メンバーがピアリングを管理するのを助ける。それだけでは、コロケーション顧客が2つのファイバー引き込み、2つのメットミールーム、2つの上流契約、隔離された建物内経路、または1つのキャリアから別のキャリアへのテスト済みフェイルオーバーを備えていることを証明するものではない。エクスチェンジは集中点であると同時に耐障害性ツールにもなり得る。多くの顧客が同じスイッチファブリック、電力ドメイン、メットミールーム、または上流集約パスに依存する場合、エクスチェンジは共通の故障ドメインの一部となる。

PeeringDB もまた興味深い分割を生み出している。ISCX と PT. Indonesia Super Corridor 組織は可視であり、PeeringDB には AS136825 のネットワークページがあり、それは CNI/ISC DC CBR、CNI DC MPR、CNI DC DPS を含む相互接続施設を持つ関連する Indonesia Super Corridor プロファイルである。しかし、AS142379 の直接の PeeringDB API クエリは、確認時点で AS142379 ネットワークプロファイルを返さなかった。その不在自体は問題ではない。多くの施設オペレーターは、施設、エクスチェンジ、サービス ASN を分離している。これは、顧客がどの AS、どのエクスチェンジファブリック、どの物理ポートを自身のサービスが使用しているかを尋ねる必要があることを意味する。

最も強力なバイヤーの質問はトポロジーに関するものである：「パスを描け」。MPR のフルラックについて、ユーティリティから UPS、ラック、冷却からラック、クロスコネクトからメットミールーム、キャリアから上流、エクスチェンジポートからルートサーバー、該当する場合は DRC へのバックアップネットワークを示せ。クラウド VM について、ハイパーバイザー、ストレージ、トップオブラックスイッチ、集約、ファイアウォール、トランジット、ピアリング、バックアップ、管理ポータルを示せ。ディザスタリカバリ顧客について、プライマリサイト、レプリケーションパス、RPO/RTO 測定、リストアターゲットを示せ。この図面がなければ、ISCX は魅力的なシグナルだが、保証ではない。

所有権と運用境界には依然として契約レベルの明確さが必要

ISC の公開証拠は CNI グループ環境と繰り返し重なる。ここでレビューされた APNIC の IP 割り当ては PT Cyber Network Indonesia に割り当てられている。RIPEstat のビューで観測された AS142379 の唯一の隣接 AS である AS38496 は CNI-AS-ID である。PeeringDB プロファイルは、PT. Indonesia Super Corridor、ISCX、CNI ブランドの施設名を同じ実用的な相互接続ランドスケープ内に配置している。サードパーティの施設ディレクトリは、ISC を CNI Group コンテキストの一部と説明している。このパターンは疑わしいものではない。データセンター、エクスチェンジ、ISP 事業が建物、コーポレートペアレント、IP リソース、運用チーム、ネットワーク資産を共有することは普通である。

しかし、共有コンテキストはデューデリジェンスを変える。顧客はウェブページ上のブランドで止まるべきではない。契約主体、施設オペレーター、IP リソース保有者、エクスチェンジオペレーター、リモートハンドプロバイダー、課金当事者、インシデントコミュニケーションの責任者を特定すべきである。ある会社が建物を所有し、別の会社がエクスチェンジを運営し、さらに別の会社がアドレス空間を保有し、また別の会社がサービス注文書に署名する場合、顧客は責任とエスカレーションがどこにあるかを知る必要がある。同じ質問が施設内部にも当てはまる：クラウドサービスは ISC によって ISC 所有の機器上で運用されているのか、CNI 系列会社によってか、ISC ラック内の顧客機器によってか、あるいは公開製品ページに名前が表示されていないパートナーによってか？

この答えは障害時に重要である。なぜなら、障害はマーケティング境界を尊重しないからだ。顧客は、あるエンティティとのコロケーション契約、別のエンティティからの IP 割り当て、エクスチェンジチームを通じたクロスコネクト、カスタマーポータルを通じたサポートチケット、さらに別のサービスを通じた DRC レプリケーションパスを持つ可能性がある。これらの機能が運用上統合されている場合、顧客は1つの調整された復旧チームの恩恵を受ける。それらが管理上分離されている場合、チームが誰が問題を所有しているかを決定する間に復旧が遅れる可能性がある。公開記録は、外部の読者がその境界を解消することを許さない。

調達にとって、最もクリーンな証拠は、すべての依存関係を責任当事者にマッピングしたサービススケジュールである。それは、誰がルームを管理し、UPS と発電機を保守し、冷却を運用し、顧客クロスコネクトを管理し、クラウドプラットフォームを所有し、顧客プレフィックスをアナウンスし、アビュースを処理し、緊急アクセスを承認し、インシデント中に顧客と話すのかを示すべきである。これは法的な瑣末事ではない。電力イベント、ルートリーク、アクセスカード故障、または DRC アクティベーションにおいて、境界がどれだけ早く実際の人間が意思決定できるかを決定する。

ディザスタリカバリページは正しい質問を投げかけ、難しい答えを未解決のままにしている

バリ DRC ページは、リカバリ概念を明示的に挙げているため有用である。RPO、RTO、ユニバーサルリストア、ビジネスアプリケーション保護、圧縮、重複排除、マルチエクスチェンジ接続、耐障害性電源、防火、監視、冗長精密空調について言及している。これらの語彙は、エンタープライズバイヤーがディザスタリカバリプロバイダーに期待すべきものそのものである。このページは単に「安全なデータ」と言うだけでなく、リカバリ時間、リカバリポイント、ネットワーク、電力、火災、冷却をオファーの構成要素として特定している。

しかし、リカバリ言語はテストに結び付けられて初めて証拠となる。公開 DRC ページは、銀行、政府機関、e コマースオペレーター、SaaS 企業に対し、そのワークロードが約束されたウィンドウ内で再起動するかどうかを伝えることができない。その答えは、レプリケーションモード、ストレージ一貫性、アプリケーション依存関係、DNS とルーティングのカットオーバー、アイデンティティシステム、データベース書き込み順序、バックアップの不変性、テスト頻度、顧客スタッフのアクセスに依存する。「複数のエクスチェンジへのギガビット接続」は有用な主張だが、負荷時の測定されたレプリケーション帯域幅と同じではない。「完全バックアップ発電機容量」は心強いが、地域緊急時の燃料稼働時間と同じではない。

DRC ページは、施設分離の問題も提起している。バリはジャカルタから物理的に離れており、地域災害復旧にとって価値があり得る。しかし距離はレイテンシを増加させ、ネットワーク依存関係を変え、データ一貫性設計を複雑にする可能性がある。一部のワークロードにとって、バリはバックアップまたはウォームスタンバイとして優れているかもしれない。低レイテンシのトランザクションシステムにとっては、慎重な非同期レプリケーションとデータ損失ウィンドウの受け入れが必要になるかもしれない。顧客は、ISC の DRC オファーがバックアップ＆リストア、パイロットライト、ウォームスタンバイ、アクティブ-アクティブ、あるいは単にセカンドサイトのコロケーションのどれであるかを知る必要がある。各パターンは異なるコストと障害動作を持つ。

これは、「DRC」が市場で過大販売される可能性があるため重要である。電力と冷却を備えた第二の部屋だけでは不十分である。ディザスタリバカリセンターは訓練されなければならない。顧客は、最後のテスト日、テスト範囲、達成された RPO と RTO、障害想定、ランブックの所有権、人員計画、顧客通知プロセス、テスト後の証拠を尋ねるべきである。リストア容量が予約されているのかベストエフォートなのかを尋ねるべきである。DRC ネットワークパスが、障害が発生したのと同じジャカルタの集中点を経由するかどうかを尋ねるべきである。災害が建物の停電ではなく、サイバーインシデント、課金ロックアウト、クラウドコントローラー障害、または誤削除である場合に何が起こるかを尋ねるべきである。

ISC の公開 DRC 資料はこれらの質問を正当化するのに十分な強さであり、それらに答えるには十分な強さではない。同社は明らかに重要な概念をマーケティングしている。Uptime のクライアントリストや Datacenters.com/DatacenterMap 形式のディレクトリに名前付きのバリ施設がある。公的に欠けているのは、顧客レベルのリカバリ証明である。コロケーションでは、多くの詳細が提案書や契約書に記載されるため、これは珍しいことではない。しかし、公開読者は「RPO」と「RTO」の見出しを、測定された証拠を求めることなく信頼に変換すべきではないことを意味する。

プラットフォーム障害時の影響を受けるのは誰か

影響を受ける当事者はラックテナントよりも広範である。従来のコロケーション顧客は、電力、冷却、アクセス制御、またはスマートハンドが失敗した場合、ホスト機器へのアクセスを失う可能性がある。クラウド顧客は、ISC が運用する仮想インフラが失敗した場合、コンピュート、ストレージ、パブリック IP サービス、または管理アクセスを失う可能性がある。エクスチェンジ参加者は、ISCX またはそのサポート施設サービスが失敗した場合、ピアリングまたはローカルトラフィック管理の可視性を失う可能性がある。DRC 顧客は、レプリケーション、ルーティング、人員配置、または燃料ロジスティクスが失敗した場合、復旧計画が紙の上には存在するが必要な速度で実行できないことを発見する可能性がある。同じ建物が、一度に複数の異なるリスクプロファイルをサポートする可能性がある。

最も敏感な顧客は、インドネシアのローカリティと継続性のために ISC を使用する顧客である。国内企業、金融セクターのサプライヤー、政府関連システム、メディアプラットフォーム、コンテンツネットワーク、地域 SaaS プロバイダーは、ジャカルタ到達可能性、ローカルエクスチェンジアクセス、インドネシアのサポートチャネル、データ所在地の信頼性を気にするかもしれない。彼らにとって、この施設は単に安価なラックではない。それは、顧客がレイテンシ、コンプライアンス、継続性の期待を満たすために使用するサービス境界の一部である。

第二の影響を受けるグループは、ピアリングのために ISCX または ISC ホストのインフラを使用する可能性のある小規模ネットワークおよびコンテンツプロバイダーである。ルートサーバー、スイッチファブリック、または施設電力ドメインが障害を起こした場合、ローカルトラフィックはより長いパスに再ルーティングされるか、バックアップピアリングのないネットワークでは失敗する可能性がある。IXP ポータルまたは監視システムが失敗した場合、パケット転送が継続していても、メンバーは運用可視性を失う可能性がある。公開 ISCX 資料は監視ダッシュボードとルートサーバー機能を宣伝している。顧客は、それらのシステムが監視対象のエクスチェンジファブリックとは独立してアウトオブバンドで冗長化されて運用されているかどうかを尋ねるべきである。

第三の影響を受けるグループは、スペースではなくクラウドを購入する顧客である。クラウド購入者は、しばしば自身のワークロードがどこにあるかについての可視性が低い。彼らには、VM プラン、メモリ、ストレージ、パブリック IP、帯域幅パッケージが見えるかもしれないが、ホストクラスター、ストレージレプリケーション、ハイパーバイザーメンテナンスポリシー、バックアップスケジュール、サポートエスカレーションパスは見えない。ISC のクラウドサービスがコンパクトなリソースプール上に構築されている場合、実用的なリスクは、ノイジーネイバーコンテンション、ホストメンテナンス、ストレージ障害、限られた国際帯域幅、または施設インシデント中の遅いサポートである。公開プランは価格と範囲にとって有用だが、プロダクションアーキテクチャには十分ではない。

第四の影響を受けるグループは、ISC を依存関係として露出させることなく、ISC 内部に顧客システムを配置する可能性のあるリセラーまたはマネージドサービスプロバイダーである。ホワイトラベル化またはリセラーホストのサービスが失敗した場合、エンドユーザーはしばしば直接のベンダーのみを見る。根本的なデータセンター障害は、復旧が停滞するまで不可視であり得る。これらのチェーンにとって、ISC の運用証拠は、エンドカスタマーが ISC と直接契約しなくても重要である。

テストすべき障害経路は平凡で容赦がない

第一の障害経路は商用電力である。ISC のページは、デュアルソース電源、独立した配電盤、2つの電圧源からの耐障害性電源、発電機について言及している。これらは正しいコンポーネントである。顧客は依然として、単線結線図、両方のソースが独立したユーティリティフィードか内部配電パスか、発電機容量がフル IT 負荷と冷却を一緒にサポートするかどうか、確定負荷で燃料がどれくらい持つか、全市的なイベント中に燃料補給が契約されているか、顧客負荷を冗長性低減状態に移行させることなくメンテナンスを実行できるかどうかを確認すべきである。

第二の障害経路は冷却である。ISC の DRC ページは、冗長システムを備えた精密空調について言及し、メンテナンスページは冷却システム作業に言及している。それは良いスタートだ。リスクは、冷却と電力の制約が相互作用することである。ラックは10A で販売されるかもしれないが、高密度機器はホットスポットを作り出す可能性があり、冷却冗長性は平均負荷ではなく実際の負荷をサポートしなければならない。顧客は、コールドアイル/ホットアイル封じ込めの詳細、温度と湿度の範囲、冷却ユニットの冗長性、チラーまたは DX 設計、メンテナンス履歴、DCIM を通じて可視なアラームを尋ねるべきである。

第三の障害経路はキャリアメットミー回線の中断である。ISC の公開資料は、クロスコネクト、IIX/IX 帯域幅、ISCX、ルートサーバー、OIXP、Equinix IX、マルチエクスチェンジ文言を宣伝している。AS142379 の BGP ビューは、依然として1つの観測された隣接 AS（AS38496）を示し、その AS からの現行 IPv6 ルートは見られない。それはエクスチェンジストーリーと矛盾しないが、公開 AS レベルの証拠が幅広いトランジットの多様性を示していないことを意味する。顧客は、キャリアリスト、パス多様性ステートメント、メットミールーム設計、クロスコネクト SLA、および顧客のラックまたは仮想ネットワークからフェイルオーバーがテストされたことの証明を要求すべきである。

第四の障害経路は施設の火災、洪水、またはアクセス中断である。バリページは、床下および床上の FM200 煙センサー、CCTV、カード/指紋ラックアクセスについて言及している。ホームページは、有人セキュリティとモーション検出器について言及している。これらは物理的制御だが、顧客は水の浸入、屋根と排水のリスク、床荷重、防火区画分離、緊急アクセス、インシデント中の顧客アクセス、保険や建物管理の制約が修理を遅らせる可能性があるかどうかについて尋ねるべきである。データセンターは優れた制御を備えていても、通常の建物依存関係にさらされる可能性がある。

第五の障害経路は建設または容量の不一致である。公開記録は複数の容量数値を伝えている：ISC の5 MW MPR ヘッドライン、Baxtel の6 MW 企業マーカー、Datacenters.com の MPR に関する16.0 MW の数値、その他の最大8 MW IT 負荷への市場参照。異なる数値の存在自体は驚くべきことではないが、一枚のスライドの数値から購入することに対する警告である。顧客は、どの数値が最新か、それがユーティリティ、グロス、クリティカル、IT、または計画容量のどれか、そして自分の契約が容量を予約するのか、それとも利用可能な限り容量へのアクセスを提供するだけなのかを尋ねるべきである。

第六の障害経路は管理上のものである。DCIM アカウント、顧客ポータル、サポートデスク、課金システム、アクセス許可はインフラの一部である。ポータルがダウンしている場合、顧客はトラフィックを監視したり、チケットを開いたり、クラウド容量をプロビジョニングしたり、ネットワークフィルタを調整したり、メンテナンスイベントが計画されているかどうかを確認したりできない可能性がある。ISCX は IXP Manager と監視ダッシュボードを宣伝している。ISC は顧客 DCIM アカウントを宣伝している。バイヤーはこれらのシステムを運用依存関係として扱い、どのようにバックアップ、監視、サポートされているかを尋ねるべきである。

グレードを変えるもの

ISC は、機密性の高い顧客データを公開することなく、公開リスクグレードを改善できる。短いネットワークページが役立つだろう：施設、クラウド、エクスチェンジサービスに使用される ASN；現在の IPv4 および IPv6 プレフィックス；上流/トランジットプロバイダー；エクスチェンジファブリック；ルートサーバーポリシー；RPKI ステータス；ルッキンググラスリンク；PeeringDB レコード；アビュースおよび NOC 連絡先；メンテナンス通知チャネル。同社はすでにそのようなページをサポートするのに十分な公開資料を持っている。それを統合すれば曖昧さが減るだろう。

施設容量ページはもっと役立つだろう。それは CBR、MPR、バリ DRC を区別し；設計ティアと認証範囲をリストし；グロス電力、確定 IT 負荷、利用可能販売可能負荷を述べ；ラック密度帯域を説明し；ユーティリティフィードと発電機の前提を特定し；冷却冗長性を開示し；クラウドサービスが1つまたは複数のサイトで実行されているかを説明すべきである。個々の顧客を公開する必要はない。マーケティングされた容量をテスト可能にする必要がある。

リカバリ証拠ページはさらに価値があるだろう。利用可能なディザスタリカバリパターンを説明し、サンプル RPO/RTO カテゴリを公開し、リストアテスト頻度を説明し、バックアップとレプリケーションのオプションをリストし、DRC 容量が予約済みかベストエフォートかを述べ、ステータスまたはインシデント履歴チャネルを提供できる。顧客は完璧を求めているのではない。企業が、自らが保護を販売している障害を訓練したことがあるかどうかを知る必要がある。

ネットワークの信頼性のために、AS142379 が直接プロダクション顧客にサービスを提供することを意図しているなら、より広範な公的多様性を示すべきである。複数の可視上流、AS142379 PeeringDB ネットワークプロファイル、現在の顧客使用可能な IPv6、全可視プレフィックスにわたるクリーンな RPKI カバレッジ、公開ルッキンググラスはすべて信頼性を高めるだろう。AS142379 が単に内部または施設固有の ASN であり、顧客の多様性が AS136825、AS38496、または他の CNI/ISC ASN の下にある場合、ISC はそれを明確に述べるべきである。曖昧さは、顧客にどの公開ルート証拠が自分のサービスに適用されるかを推測させる。

調達の信頼性のために、ISC は市場容量の主張を整合させるべきである。異なる公開場所で5 MW、6 MW、8 MW、16 MW を見るバイヤーは、どの数値が支配的かを知ることができない。答えは単純かもしれない：サイト電力、IT 負荷、計画拡張、建物容量、またはディレクトリの誤り。しかし、公的不一致は摩擦を生み出す。データセンター購入において、クリーンな容量ステートメントは表面的なものではない。顧客が3〜5年間スペースと電力を予約できるかどうかを決定する。

運用グレード

PT. INDONESIA SUPER CORRIDOR - データセンターは、強力な施設存在コンポーネントを伴う中程度のネットワークおよび運用証拠グレードを獲得する。強い部分は当然である：ISC は公式施設ページ、名前付きの CBR/MPR/バリ資産、Uptime Institute 発行認証記録、公開ラック・クラウドオファー、ISCX エクスチェンジ面、APNIC AS アイデンティティ、最新の RIPEstat IPv4 可視性、サンプル可視プレフィックスに対する有効な RPKI を有している。これは休眠中のシェルや未検証のホスティングブランドよりもはるかに優れている。

ダウングレードもまた当然である。公開証拠は、宣伝された規模での使用可能容量をまだ証明していない。競合する電力数値を調整していない。AS142379 の現在の IPv6 を示していない。その AS の観測された BGP 隣接は1つである。キャリアリスト、ユーティリティ単線結線図、燃料稼働時間、冷却テスト証拠、顧客リストア結果、ステータス履歴、インシデントコミュニケーション、クラウドアーキテクチャ、またはサイト固有のフェイルオーバールールを公開していない。同社は正しい材料をマーケティングしているが、顧客は依然としてレシピを検証しなければならない。

実用的な結論は ISC を避けることではない。慎重に購入することである。控えめなコロケーション、エクスチェンジ隣接プレゼンス、インドネシアローカリティ、またはジャカルタ・バリ間のリカバリ会話にとって、ISC はデューデリジェンスリストに載る。中断のない電力、多様なキャリアパス、証明されたリカバリに依存するプロダクションワークロードにとって、バイヤーはサイトツアー、エンジニアリング文書、ライブルートテスト、フェイルオーバードリル、およびマーケティングされたサービスを特定の施設と依存関係パスにマッピングする契約文言を要求すべきである。データセンターにおいて、「利用可能なラック」と「生存可能な容量」の違いこそが、真のリスクが存在する場所である。