概要

分析に十分な可視性を持つ企業

Cloud9 Cloud 9 Ltd. は、複数の独立した公開記録が一致しているため、多くの小規模ホスティング エントリよりも具体的な評価に値します。同社サイトは、ジョージアのホスティングおよびデータセンター ビジネスに Cloud9 ブランドを使用しています。ホームページでは、Cloud9 をジョージアのプロフェッショナルな Web ホスティング プロバイダーおよび経験豊富なデータセンター オペレーターと説明しています。フッターには、営業所住所として 2 Akaki Tsereteli Ave., Dinamo Stadium, Gate 5, Tbilisi, Georgia 0112 が記載され、電話番号とサポート メールも掲載されています。利用規約では、"Cloud 9 LLC"、会社 ID 405063755 と特定され、トビリシの法定住所と契約およびサポートに関する連絡先メールが記載されています。名称は公開情報の表面上では完全に統一されていませんが、住所、ドメイン、レジストリの証拠は同じジョージアのホスティング オペレーターを示しています。

RIR の記録は、その同一性を Web サイトの主張以上のものにしています。AS57814 の RIPE RDAPでは、登録組織が Cloud 9 Ltd. と記載され、住所が 2 Tsereteli ave, 0112, Tbilisi, Georgia と示され、公開された管理担当、技術担当、不正利用担当の連絡先が提供されています。ORG-CL434-RIPE の RIPE RDAPでは、同じトビリシの住所、電話番号、連絡先メールで Cloud 9 Ltd. と表示されています。AS49297 の RIPE RDAPは、同じ組織と連絡先セットにもう一つの自律システムを結び付けています。

これが重要なのは、同社の可視化されたサービスがインフラストラクチャ サービスだからです。Cloud9 は、共有ホスティング、仮想サーバー、専用サーバー、コロケーション、メール、ドメイン、証明書、データセンター サービスといった顧客向け能力を販売しています。これらのサービスを購入する顧客は、単にブランドを購入しているのではありません。ラック スペース、電力、ルーティング、サポート労力、契約条件に依存しているのです。公開された証拠は、Cloud9 をそのカテゴリに位置付けるのに十分な強度があります。ただし、契約書や設計書なしに顧客の継続性に関するすべての疑問に答えるほどの強度はありません。

したがって、最も重要な枠組みは実用的なものです。Cloud9 は、稼働中のジョージアのホスティングおよびネットワーク プロバイダーとして可視化されています。また、顧客ストーリーの多くを、名前の付いたトビリシの施設に集中させています。この組み合わせは、地域サービスとデータ所在性にとって有用です。それはまた、顧客が各サービスが実際にどこで実行されているのか、どのように障害が発生するのか、どのように回復するのか、顧客が迅速に撤退する必要がある場合に何が起こるのかを尋ねるべきであることを意味します。

ネットワーク記録には2つの AS 番号があるが、可視的にアクティブなのは1つ

公開ルーティングの状況には明確な中心と一つの重要な注意点があります。AS57814 の RIPEstat AS 概要では、ホルダーが Cloud9 Cloud 9 Ltd. と表示され、2026 年 7 月 12 日の照会時点で AS がアナウンスされていると示されています。AS49297 の RIPEstat AS 概要では、同じホルダー文字列が表示されますが、同じ照会時点で AS はアナウンスされていません。AS57814 の RIPEstat アナウンス プレフィックス データでは、185.229.110.0/24、45.138.44.0/22、195.69.140.0/22 を含む広範な可視経路のセットがリストされていますが、AS49297 の同じエンドポイントはアナウンス プレフィックスを返しません。

この違いは保持されるべきです。Cloud9 に関連するすべての AS がトラフィックをアクティブに搬送していると言うのは誤りです。同社に可視ネットワークがないと言うのも誤りです。AS57814 は公開経路ビューで明らかにアクティブです。RIPE RIS プレフィックス カウントでは、2026 年 7 月 12 日の照会時点で AS57814 について IPv4 オリジネーティング プレフィックス 28 件、IPv4 トランジット プレフィックス 13 件、IPv6 オリジネーティング プレフィックス 3 件、IPv6 トランジット プレフィックス 2 件が示されています。これらのカウントは、アクティブな顧客数、プラットフォームの充足度、予備容量の量を証明するものではありませんが、単一の休眠経路よりも実質的に大きなネットワーク サーフェスを示しています。

経路の例も、現在のプレフィックス可視性を示しています。185.229.110.0/24 の RIPEstat プレフィックス概要では、プレフィックスが AS57814 によってアナウンスされ、185.229.108.0/22 に関連付けられています。185.229.110.0/24 の RIPEstat BGP 状態サンプルでは、数百の経路観測が返され、サンプル内で AS57814 に到達する経路は AS20771 や AS35805 などのアップストリームまたはピア AS を経由しています。AS57814 の BGP.toolsでは、Cloud 9 Ltd. を他のネットワークとピアリングし、アップストリーム キャリアを持つ長期運営ネットワークと説明しており、185.229.110.0/24 の BGP.toolsでは、このプレフィックスが AS57814 から発信されていることを示しています。

運用上の推測はバランスが取れています。Cloud9 は、ネットワークを持たない根拠のない再販業者ではありません。同社はライブ AS、IPv4 と IPv6 の可視性、経路オブジェクト、公開ピアリング データを持っています。しかし、経路可視性は顧客保証と同じではありません。顧客は、ワークロードのどれが Cloud9 自身のプレフィックス上にあるのか、どれがベンダー プラットフォーム上にあるのか、どの経路がバックアップ サービスを搬送しているのか、フェイルオーバー イベントが通常の顧客負荷後に十分な余裕を持つのかを知る必要があります。

データセンターが提供の中核

Cloud9 のデータセンター ページは、物理的な依存度について珍しく率直です。同ページでは、Cloud9 が提供するサービスのほとんどは、自社のトビリシ拠点のデータセンターから提供されていると記載されています。また、キャリアニュートラルなデータセンター、エンジニアによる 24 時間 365 日の監視、セキュリティ制御、電力冗長性、火災検知および消火、空調管理、相互接続性について説明しています。さらに、この施設は 3 つの独立した電力変電所とバックアップの 630 kVA ディーゼル発電機から電力を供給されているとし、コロケーション ゾーンは N+N 冗長電源フィードと UPS を備えていると述べています。接続性については、Cloud9 は主要通信キャリアや小規模 ISP オペレーターと、複数の代替経路と総接続容量 250 Gbps の予約済みダークファイバーを介して接続されているとしています。

PeeringDB は、トビリシ施設の主張を別の方法で裏付けています。Cloud9 Dinamo Arena の PeeringDB 施設レコードでは、施設の所在地がジョージア、トビリシ 0112、A. Tsereteli Ave 2 と表示され、組織が Cloud9 LTD、事業内容としてジョージアでのデータセンター、ホスティング、クラウド、ISP サービスを提供していることが注記され、ネット数 7、エクスチェンジ数 1、キャリア数 1 と示されています。net_id 20057 の PeeringDB ネットワーク施設関連も、AS57814 を Cloud9 Dinamo Arena に結び付けています。この PeeringDB の公開証拠は、エンジニアリング設計を認証するものではありませんが、Cloud9 自身のページの住所パターンと一致する独立した施設アンカーを提供します。

重要な問題は、設置容量と利用可能容量の差です。データセンター ページでは変電所、UPS、発電機を挙げることができますが、顧客はメンテナンスや障害時にそれらの資産がどのように動作するかを知る必要があります。実際に構築され電力が供給されているラック数は？ラックあたりの電力許容量は？現在の負荷後に残っている予備の UPS および発電機容量は？長期間の停電時に契約されている燃料量は？電源パスは顧客ラックまで真に独立しているか、それとも障害点の前で共有されているのか？発電機の起動は負荷時にテストされているか？公開ページでは、これらの疑問に顧客レベルの深さで答えていません。

接続性にも同様の区別が適用されます。総相互接続容量 250 Gbps という記述は、特に地域市場では意味がありますが、障害時の顧客利用可能帯域幅と同じではありません。顧客は、自分のサービスが共有トランジット、IXP パス、プライベート クロスコネクト、ローカル ISP ルート、それとも Cloud9 バックボーン パスを使用しているのか、バックアップ パスが同じ建物を出るのか、帯域幅保証がファイバ断線やキャリア メンテナンス時にも生き残るのかを知る必要があります。Cloud9 の公開ページは、データセンターが本物であると確信するのに十分な自信を与えますが、顧客がストレス時に実際に消費できるものをテストする必要性を取り除くものではありません。

ホスティングはクラウドサービスになる前にラックサービスである

Cloud9 のリテール メニューは幅広く、Linux 共有ホスティング、Windows 共有ホスティング、VPS、VDS、専用サーバー、Zimbra メール、ドメイン、証明書、コロケーションを販売しています。利用規約では、ホスティング サービス、ドメイン登録、仮想サーバー レンタル、物理サーバー レンタル、メール サービス、データセンター サービス、セキュリティおよび DDoS 防御、サーバー インフラストラクチャ計画、DevOps サービス、クラウド サービスが説明されています。これらはすべて同じ依存関係ではありません。

共有ホスティングは、Web サーバー、コントロール パネル、DNS、ストレージ、サポート ポリシーに依存します。VPS は、物理ホスト、ハイパーバイザー、ストレージ、スナップショット、ノイジーネイバー制御に依存します。VDS はより強力な仮想サーバー製品として宣伝されていますが、それでも物理サーバーの割り当てとフェイルオーバー設計に依存します。専用サーバー レンタルは、Cloud9 所有のハードウェア、交換用ストック、リモート コンソール アクセス、スタッフの可用性に依存します。コロケーションは、顧客自身の機器、Cloud9 のラック サービス、および顧客の修理またはリモート ハンズの承認能力に依存します。メールは、メール サーバーの運用、スパム フィルタリング、DNS、ストレージ、バックアップ、移行ツールに依存します。

公開製品ページはリテール オファーを理解可能にしますが、それだけでリソースの可用性を証明することはできません。VPS プランは CPU、メモリ、ストレージをリストできますが、実際のパフォーマンスは競合、ストレージ レイアウト、障害容量に依存します。専用サーバーは購入可能かもしれませんが、マザーボード、ディスク、電源装置の障害は予備部品の在庫とスタッフの対応に依存します。共有ホスティング アカウントは安価かもしれませんが、リストア時間はバックアップの頻度、整合性、バックアップ システムが障害サーバーから隔離されているかどうかに依存します。ドメインやメール サービスはカスタマー ポータルを通じて管理できますが、顧客の回復は DNS とメールボックスのエクスポートを迅速に移動できるかどうかに依存する場合があります。

だからこそ、ホストされた容量は依然として顧客による物理的な監査を必要とします。問題は単にサービスが存在するかどうかではありません。サービスが、1 つのホスト、1 つのスイッチ、1 つのストレージ システム、1 つの冷却ユニット、1 つの電源パス、1 つのクロスコネクト、1 つのサポート シフトの障害後も使用可能なままであるかどうかです。Cloud9 の公開情報は、施設とネットワークを持つ実際のサービス プロバイダーを裏付けていますが、それらの障害モードそれぞれの下での顧客固有の生存可能性を推測するのに十分な詳細を公開していません。

コロケーションは明確な所有権境界を引く

コロケーション ページは、Cloud9 所有の容量と顧客所有の機器の境界を明示するため、最も価値のある公開情報源の 1 つです。Cloud9 は、1U、2U、タワー型コロケーション オプション、ハーフ ラック、フル ラック、カスタム ケージを販売しています。1U および 2U オファーには A/B デュアル電源、1 Gb/s リンク、管理リンクが含まれ、タワー型サーバー オファーは単一電源、1 Gb/s リンク、管理リンクと記載されています。このページでは、1 Gb/s 接続はジョージアの ISP に対して無制限で、顧客あたり 30 Mb/s のグローバル接続が含まれていると説明されています。また、管理リンクは IPMI、iLO、iDRAC、または BMC アクセス用で、内部 IP とセキュア VPN アクセスが提供されます。

これらの詳細は商業的に有用であると同時に、限界も明らかにします。コロケーションはマネージド専用ホスティングと同じではありません。Cloud9 の FAQ には、コロケーションでは機器は顧客の責任であり、Cloud9 は修正の迅速化を支援すると記載されています。Cloud9 にはリモート ハンズのために 24 時間 365 日対応可能なエンジニアがおり、大規模な移行を実施した実績があり、各移行はワークロードに依存すると述べています。また、見積もりと初回支払い後、スペースと IP アドレスは 24 時間未満で準備可能である一方、フル ラックとケージは部品と労力のためにさらに時間がかかる場合があるとしています。

顧客にとって、この境界は停止時に決定的です。コロケーションされたサーバーにディスク障害、電源障害、ファームウェアの問題が発生した場合、Cloud9 は顧客の契約と利用可能な予備部品または交換計画の範囲内でのみリモート ハンズを提供できます。顧客が予備ディスク、リモート コンソール資格情報、文書化されたブート メディア、移行ターゲットを持っていない場合、ラックは電源が入ったままでアプリケーションがオフラインのままになる可能性があります。ネットワーク変更についても同じことが言えます。管理リンクは、顧客がアクセス権、VPN の詳細、既知の資格情報、テスト済みのコンソール パスを持っている場合にのみ役立ちます。

価格と帯域幅の表現にも注意が必要です。ローカルの 1 Gb/s リンクと 30 Mb/s のグローバル接続は多くのジョージアのホスティング用途には十分かもしれませんが、グローバル クラウド帯域幅と同じではありません。海外ユーザーにサービスを提供する顧客、オフサイト バックアップ、大規模なデータ エクスポートには、通常の月間使用を超えてバースト トラフィック、課金、輻輳、緊急移行がどのように動作するかを知る必要があります。コロケーション ページは Cloud9 に境界を公開している点を評価できますが、重要なハードウェアをそこに配置する前に買い手が確認すべき条件も提供しています。

ピアリングと経路の多様性は最も弱い仮説よりも良好に見える

本件の初期リスク仮説は、公開情報の範囲が薄いと警告していました。実際の経路とピアリングの証拠はそれよりも強力です。PeeringDB の AS57814 ネットワーク レコードでは、Cloud9 が AS57814 のネットワーク サービス プロファイルとしてリストされており、Web サイトhttps://www.cloud9.ge/、IPv6 サポート、地域範囲、大量のアウトバウンド トラフィック、自己申告の 200 ～ 300 Gbps トラフィック、オープンな一般ピアリング ポリシー、1 つの施設、1 つのエクスチェンジ数が示されています。IRR AS セットは AS-SET-CLOUD9 と記載されています。このプロファイルは自己管理されており、監査された容量として扱うべきではありませんが、空白のページではなく、公開インフラストラクチャ プロファイルです。

PeeringDB の netixlan エントリでは、Cloud9 が IXP.ge 上に 10,000 Mb/s ポート、IPv4 アドレス 185.1.224.232、ルート サーバー ピア ステータス true、オペレーショナル ステータス true でリストされています。PeeringDB の IXP.ge レコードでは、エクスチェンジがトビリシとクタイシにあり、その施設エントリの中に Cloud9 Dinamo Arena が含まれていると説明されています。Cloud9 自身のデータセンター ページでは、同社がインターネット エクスチェンジ ポイント オペレーターでもあり、キャリアへのクロスコネクションを提供していると述べられています。これらを総合すると、これらの情報源は意味のあるローカル相互接続の役割を裏付けています。

RIPEstat はまた、より広範なプレフィックスとピアのセットにわたる経路ポリシーの一貫性を示しています。AS57814 の AS ルーティング一貫性では、45.138.44.0/22、185.229.108.0/24、185.229.109.0/24、185.229.110.0/24、188.93.88.0/24、195.69.140.0/22 を含む多くのプレフィックスが BGP と whois ルーティング データの両方に存在するとリストされています。また、AS49628、AS20771、AS35805、AS16010、AS34797 を含む BGP と whois におけるいくつかのインポートおよびエクスポート ピア、ならびにチェックされた whois データには存在しない BGP 可視ピアも示されています。RIPEstat AS パス長データは、多くのコレクター拠点から AS57814 が可視であることを示しています。

これは、単一の観測可能なアップストリームを持つ 1 プレフィックス ホストのプロファイルではありません。それでも、ルーティング レイヤーでの多様性はサービス回復力に変換されなければなりません。経路は複数のパスを持つことができますが、顧客サービスは依然として 1 つのトップ オブ ラック スイッチ、1 つのストレージ アレイ、1 つの電力分配パス、または 1 つのサポート判断に依存する可能性があります。顧客は、自社のサービスにどのプロバイダーが使用されているか、経路がアクティブに監視されているか、メンテナンス イベント中に Cloud9 がトラフィックをシフトできるか、1 つのピアまたはトランジット プロバイダーが機能不全になった場合に国際的な到達可能性が許容可能なままであるかを尋ねるべきです。

ルーティング衛生は部分的だが可視化されている

ルーティング セキュリティは、Cloud9 に可視的な証拠がある分野ですが、プレフィックスごとに評価されるべきです。AS57814 と 185.229.110.0/24 の RIPEstat RPKI 検証は、185.229.110.0/24 と 185.229.108.0/22 をカバーするオリジン 57814 の検証用 ROA を含む有効なステータスを返します。これは、有効な経路オリジン認可が、ネットワークが誤ったオリジンからのそのプレフィックスに対するアナウンスを拒否するのに役立つため重要です。アプリケーションのダウンタイムを解決するわけではありませんが、ルーティングの誤りやハイジャックの一クラスを減らします。

AS ルーティング一貫性エンドポイントは、BGP と whois ルーティング データの両方に多数の Cloud9 プレフィックスが存在することを示しており、もう一つの肯定的な兆候です。PeeringDB プロファイルの AS セットも、ネットワークがルーティング ポリシーで使用する公開オブジェクトを提供します。これらは地域プロバイダーにとって良い兆候です。なぜなら、多くの運用インシデントは、ルート フィルター、古いオブジェクト、ROA の欠落、またはプロバイダーがアナウンスするものとアップストリームが搬送を許可するものとの不一致から始まるからです。

注意点は、この証拠が普遍的な認証ではないことです。上記の RPKI 検証リンクは、代表的なプレフィックス 1 つを検証するものであり、すべての経路を検証するものではありません。AS ルーティング一貫性の出力は、一部の whois 経路が現在 BGP に存在しないこと、および BGP にはあるがチェックされた whois ポリシーには存在しない一部のピアを示しています。これは多くのネットワークでは通常のことですが、顧客向けの主張は正確なプレフィックスまたはサービスに対して測定されるべきであることを意味します。特定のブロックのアドレスを使用する顧客は、そのブロックが有効な ROA、維持された経路オブジェクト、文書化されたアップストリーム フィルター、および経路リークや到達可能性の喪失に対応できる監視連絡先を持っているかを尋ねるべきです。

ルーティング衛生は、移行権利とも結びつけられるべきです。顧客のサービスが Cloud9 提供の IP アドレスを使用している場合、顧客はそれらのアドレスがワークロードとともに移動できるのか、それとも DNS、証明書、許可リスト、メールの評価を別の場所で再構築する必要があるのかを知る必要があります。Cloud9 のネットワーク証拠は、顧客サービスがそのアドレス空間に深く統合されている可能性があるほど強力です。そのため、クリーンなドキュメントがより重要になります。

電力と冷却の主張には顧客固有の証明が必要

Cloud9 の公開データセンターの主張は、使用するには十分詳細ですが、契約におけるエンジニアリング証拠を置き換えるほど詳細ではありません。データセンター ページでは、施設が 3 つの独立した電力変電所と 630 kVA ディーゼル発電機から供給されていると述べられています。コロケーション ゾーンには N+N 冗長電源フィードと UPS システムがあると記載されています。早期の温度、煙、火災検知、3M Novec 1230 消火システム、DX 冷却、温度湿度制御、サーバー ルームには窓や外向きの壁がなく、近くには消火配管のみと説明されています。また、すべての主要システムはエンジニアによって 24 時間 365 日監視されていると述べられています。

これらは、電力、火災、冷却、物理セキュリティ、監視という適切なカテゴリです。残る疑問は、通常のメンテナンス後や信頼できる障害イベント後に顧客が冗長サービスを受けられるかどうかです。顧客が A/B デュアル電源付きの 1U コロケーションを購入した場合、両方のフィードは本当に別々のアップストリーム電源パスに接続されているのか、それとも 1 つのアップストリーム コンポーネントが依然として両方に影響を与える可能性があるのか？顧客が単一電源のタワー型コロケーションを購入した場合、単一電源のリスクを価格に織り込んでいるか？顧客が専用サーバーをレンタルする場合、契約にはコンポーネント交換時間とハードウェア交換パスが含まれているか？仮想サーバーが Cloud9 ハードウェア上で実行されている場合、プラットフォームはダウンタイムなしでどのレベルのホストまたはストレージ障害を吸収できるか？

冷却にも同様の隠れた制約があります。DX 冷却は施設に適しているかもしれませんが、顧客はラックレベルの密度制限、ホットアイルとコールドアイルの設計、センサー配置、ラックが高温になった場合のエスカレーション パスを知る必要があります。施設が冗長冷却設計を備えていても、特定の顧客ラックは依然としてエアフローまたは電力密度によって制約される可能性があります。火災抑制も、物理コロケーションと仮想サービスでは異なる影響を及ぼします。火災抑制イベントは機器をより大きな損傷から保護するかもしれませんが、それでも緊急アクセス制御、点検期間、復旧遅延を生じる可能性があります。

公開サイトでは、施設はサービスを中断することなくスケジュール メンテナンスを実行できるという意味で Tier 3 であるとされています。コロケーション FAQ では、Tier 3 を Uptime Institute の分類システムとして説明し、Cloud9 のデータセンターは Tier 3 であると述べています。顧客は、Cloud9 が現在の第三者認証を保持しているのか、それとも設計意図を説明するためにこの用語を使用しているのかを尋ねるべきです。この区別は学術的なものではありません。Tier III の概念に沿った設計は有用ですが、認定施設、監査されたメンテナンス記録、顧客固有の冗長性レターは、異なる証拠価値を持ちます。

ポータルはサービスを簡素化するが、課金とアクセスが依存関係になる

Cloud9 の利用規約は、顧客が実際にインフラストラクチャにアクセスする方法を示すため重要です。利用規約では、ユーザーは cloud9.ge に登録し、Cloud9 ポータル (my.cloud9.ge) で個人アカウントを受け取り、そこで新製品の購入、既存製品の管理、不要な製品のキャンセル、支払いの管理、サポート チケットの随時発行ができるとされています。また、ユーザーはアカウントの機密性と、アカウントで行われた行動に対して責任を負うと定められています。

このポータル設計は便利です。営業担当者とのやり取りを待たずにインフラストラクチャを管理できますが、同時にアカウント アクセスが継続的な依存関係になります。顧客の承認済みメール アカウントが失われた場合、資格情報が侵害された場合、スタッフが退職した場合、または請求連絡先が更新されていない場合、チケット発行、サービス キャンセル、支払い管理、緊急変更を行う能力が損なわれる可能性があります。利用規約は、連絡先担当者、登録データ、メール、電話の詳細を最新の状態に保つ責任をユーザーに負わせています。これは通常の法的文言ですが、停止時に運用上の問題となります。

請求も修理パスの依存関係です。請求書または決済期間の問題でサービスが無効になった場合、顧客は根本原因が管理上の問題である技術的な停止を経験する可能性があります。顧客は、Cloud9 がアカウント連絡先にどのように通知するか、停止または終了前にどの程度の通知があるか、支払い後に緊急復旧が可能か、危機時に誰が変更を承認できるかを知る必要があります。公開条件は一般的な契約を説明できますが、重要な顧客は依然としてアカウント ガバナンス、すなわちポータルの共有所有権、文書化された連絡先、オフボーディング ルール、テスト済みのサポート エスカレーションを必要とします。

データ保持と削除も重要です。Cloud9 の利用規約とプライバシーに関する文言では、個人データとサービス提供データは定義された法的およびサービス目的のために保存される可能性があり、データは関連する保持期間後に削除または破棄される可能性があると述べられています。顧客は、アカウント データ、ログ、バックアップ、メールボックス データ、ホスト ファイル、仮想マシン イメージを区別する必要があります。顧客が Cloud9 を離れる能力は、エクスポート形式、削除のタイミング、バックアップの可用性、およびキャンセル後にデータを取得できるかどうかに依存します。

実践的な教訓は単純です。ポータルはインフラストラクチャの一部です。顧客は本番アクセスと同様にそれを保護し、複数の承認済みメンテナーを割り当て、課金データを最新に保ち、最初のインシデントの前に緊急サポートの手順を確認する必要があります。

データ主権はサービスの配置が明示されて初めて強みとなる

Cloud9 の最も強力な所在地の主張はジョージアのプレゼンスです。同社サイト、利用規約、RIPE レコード、PeeringDB はすべてトビリシを示しています。ORG-CL434-RIPE の RIPE RDAPでは、トビリシに Cloud 9 Ltd. がリストされています。PeeringDB の施設レコードでは、トビリシに Cloud9 Dinamo Arena がリストされています。185.229.110.0/24 の RIPEstat ジオロケーションでは、2026 年 7 月の結果時点でその代表的なプレフィックスがトビリシに配置されています。Cloud9 のデータセンター ページでは、ほとんどのサービスが自社のトビリシ データセンターから提供されていると述べられています。

ジョージアのホスティング、ローカル サポート、ジョージア ネットワークへの低遅延アクセスを必要とする顧客にとって、これは価値があります。多くの企業は、顧客サポート、規制上の要求、言語、ローカル インターネット パスが重要な場合、特にすべてのワークロードを別の法域のハイパースケール リージョンに送りたくありません。したがって、Cloud9 のコロケーションと仮想サーバー オファーは、ローカル容量戦略として読むことができます。顧客は近接性、地元企業、ローカル キャリア アクセス、ローカル施設を購入するのです。

「ほとんど」という言葉には依然として注意が必要です。Cloud9 の公開ページは、すべてのサービス、バックアップ コピー、メール レコード、ポータル機能、DNS サービス、セキュリティ サービス、サポート データセットがジョージアのみに保存されていることを証明していません。プライバシー ポリシーでは個人データ処理とサービス提供について論じていますが、公開テキストはすべての製品を保存場所に対応付けていません。利用規約には、ドメイン、証明書、メール、セキュリティ、DDoS 防御、クラウド サービスを含む幅広いサービス ポートフォリオが記載されており、その一部にはサードパーティ システムが関与する可能性があります。これはホスティング ビジネスでは通常のことですが、データ所在地はサービスごとに明示する必要があることを意味します。

したがって、主権要件を持つ顧客は、Cloud9 に対してサービス配置に関する声明を求めるべきです。主要ワークロードはどこにあるか？バックアップはどこにあるか？ログはどこにあるか？サポート チケットはどこにあるか？どの外部レジストリ、認証局、メール セキュリティ システム、支払い処理業者が顧客データに触れるか？すべてのデータは定義されたスケジュールでエクスポートおよび削除できるか？顧客がジョージアのみの処理を必要とする場合、どの Cloud9 製品が対象で、どれが対象外か？Cloud9 の公開証拠はトビリシを強力な重心として裏付けていますが、すべてのデータ主権問題を自動的に解決するものではありません。

DNS とドメインサービスは Cloud9 を顧客のコントロールプレーンの一部にする

Cloud9 はドメイン登録、DNS 関連のホスティング、メール サービスを販売しているため、その役割はコンピュートを超えて広がる可能性があります。同サイトのネームサーバー パネルには、Linux、Windows、VPS ホスティング用の cPanel ネームサーバーがリストされています。Linux ホスティングには ns1.cpanel.ge と ns2.cpanel.ge、Windows ホスティングには ns5.cpanel.ge と ns6.cpanel.ge、VPS ホスティングには ns3.cpanel.ge と ns4.cpanel.ge です。公開 DNS 観測では、cloud9.ge が権威ネームサーバーとして ns1.cpanel.ge と ns2.cpanel.ge を使用し、cloud9.ge が 188.93.90.171 に解決され、MX レコードが tbs01-mail02.cpanel.ge を指していることが示されています。これらの名前は、リテール Web、ホスティング、メール オファーをプロバイダー自身のサービス名前空間に再び結び付けています。

これは重要です。なぜなら、DNS は装飾ではなくコントロール プレーンだからです。顧客が Web サイト、メール ドメイン、アプリケーションを Cloud9 上でホストし、Cloud9 が管理するネームサーバーを使用する場合、基盤となるサーバーが正常であっても、DNS インシデントが移行、フェイルオーバー、復旧に影響を与える可能性があります。逆に、顧客が DNS を独立したプロバイダーに保持し、Cloud9 をコンピュートまたはコロケーションのみに使用する場合、Cloud9 のサービス問題時にトラフィックをより迅速にリダイレクトできる可能性があります。適切な選択は、顧客のリスク許容度とスキル レベルに依存します。

ドメイン登録は別の層を追加します。Cloud9 を通じてドメインを購入する顧客は、レジストリ アクセスがどのように機能するか、顧客が迅速に転送コードを取得できるか、誰が更新通知を受け取るか、ドメイン ロックが設定されているか、請求問題が更新と重なった場合に何が起こるかを知る必要があります。ドメインはどのホスティング プロバイダーよりも長く存続できますが、それは顧客が資格情報、登録者の詳細、転送権利を管理し続ける場合に限ります。

メールはさらに重要な意味を持ちます。Zimbra メールは、ローカルなホスト メールボックス製品を求める企業にとって便利ですが、メール復旧は DNS、メールボックス バックアップ、エクスポート形式、スパム対策レピュテーション、ユーザー パスワード、サポート タイミングに依存します。顧客は、メールボックスをどのようにエクスポートできるか、DNS レコードをどのように復元するか、削除されたメールがどのくらいの期間復元可能か、メール停止時にどのようなサポート コミットメントが適用されるかを尋ねるべきです。Cloud9 のドメインとメール サービスは、そのオファーの正当な部分です。同時に、Cloud9 は、単にサーバーを購入しているだけと思っているかもしれない顧客にとって、コントロール プレーン プロバイダーにもなります。

主な故障パスは普通のもので、珍しいものではない

Cloud9 の最も信頼できる故障パスは、SF 的な出来事ではありません。それらは、ラックの電源問題、冷却インシデント、ハードウェア障害、経路リーク、アップストリーム キャリア障害、DDoS イベント、課金停止、ポータル アクセス問題、バックアップ失敗、遅いスペアパーツ交換、移行失敗、またはスタッフが処理できるよりも速く増加するサポート キューといった、よく知られたインフラストラクチャの問題です。Cloud9 はホスト サービスとコロケーションの両方を提供しているため、顧客への影響は顧客が何を購入したかによって異なります。

共有ホスティングの顧客にとって、障害は Web サイトのオフライン、データベースの利用不可、DNS エラー、コントロール パネルのログイン問題、またはバックアップ リストアの遅延である可能性があります。VPS や VDS の顧客にとって、障害はホスト競合、ストレージ障害、ハイパーバイザー メンテナンス、到達不能な管理コンソール、またはネットワーク喪失である可能性があります。専用サーバーの顧客にとって、障害は在庫と手作業の交換を必要とする物理コンポーネントである可能性があります。コロケーションの顧客にとって、障害は顧客所有のハードウェアであり、Cloud9 はアクセスを支援できますが所有していません。ドメインの顧客にとって、障害はサーバーではなく名前の制御喪失である可能性があります。メールの顧客にとって、障害はメールボックス アクセス、DNS ルーティング、メール キューイング、またはスパム レピュテーションである可能性があります。

経路ビューは、Cloud9 が小規模なシングルホーム プロバイダーよりも多くのネットワーク多様性を持っていることを示唆していますが、それはサービスの集中を排除するものではありません。多くの顧客サービスが 1 つの施設内にある場合、複数のキャリアがあっても施設レベルのイベントは依然として重要です。バックアップが同じサイトに保存されている場合、本番環境がオフラインになる同じインシデントによって復旧が遅れる可能性があります。サポート チケットと課金アクセスがポータルに依存している場合、アカウントまたはポータルの問題が技術的な修復を複雑にする可能性があります。顧客がコロケーション機器を所有しているがローカルなスペアパーツを持っていない場合、顧客のワークロードがダウンしている間も施設は正常に動作し続ける可能性があります。

これが、Cloud9 の公開証拠をデューデリジェンスの代替ではなく、出発点として読むべき理由です。顧客は何が一緒に障害を起こすかを尋ねるべきです。ホスト サーバー、DNS、ポータル、バックアップ ターゲットは同じ建物を共有しているか？サービスにセカンド サイトはあるか？スナップショットはプライマリ ストレージ システムの外に保存されているか？経路変更はテストされているか？顧客は紛争や緊急時にドメイン、メールボックス、サーバー イメージを移動できるか？各回答は、「データセンターでホストされている」と「データセンター、ネットワーク、アカウント パスがストレス下にあるときに回復可能」との間のギャップを減らします。

移行は安価な容量の隠れたコストである

Cloud9 のコロケーション ページでは、同社が大規模な移行を実施したことがあり、顧客のデータセンターへの移動計画と実行を支援すると述べられています。移行スキルは地域ホスティングで重要であるため、これは肯定的な兆候です。しかし、すべての移行には、プロバイダーへの参入と退出の二つの側面があります。顧客は最初の側面を注意深く交渉し、停止、価格変更、コンプライアンス要求、または事業売却が問題を強制するまで二番目の側面を無視します。

退出の問題は、Cloud9 の各サービスで異なります。共有ホスティングの顧客は、Web サイト ファイル、データベース、DNS ゾーン、メール アカウント、ログを必要とします。VPS の顧客は、VM イメージ、スナップショット、または再現可能なサーバー ビルドを必要とします。VDS および専用サーバーの顧客は、OS アクセス、データ コピー パス、ファイアウォール ルール、イメージ、ライセンス、IP 再番号付け計画を必要とします。コロケーションの顧客は、物理アクセス、発送期間、リモート ハンズ調整、ケーブル配線図、機器リストを必要とします。ドメインの顧客は、転送コードとロック解除された登録者レコードを必要とします。メールの顧客は、メールボックス エクスポート、DNS 変更、ユーザー再構成を必要とします。複数のサービスを同時に使用する顧客は、マップ全体を必要とします。

帯域幅が制限要因になる可能性があります。Cloud9 のコロケーション ページでは、標準的な顧客接続にはジョージアの ISP への無制限 1 Gb/s と、顧客あたり 30 Mb/s のグローバル接続が含まれていると述べられています。これは通常のローカル ワークロードには十分かもしれませんが、別の国への一括エクスポートは非常に異なる動作をする可能性があります。顧客がテラバイト単位の仮想マシン、バックアップ、またはメールボックスを移動する必要がある場合、一時的な帯域幅アップグレードが利用可能か、コストはいくらか、移行トラフィックが本番トラフィックと競合するかを知る必要があります。

IP アドレス指定も隠れたコストです。顧客のサービスが Cloud9 提供の IP アドレスを中心に構築されている場合、移行には DNS 変更、証明書の再発行、ファイアウォール許可リストの更新、メール レピュテーションの再構築、顧客コミュニケーションが必要です。顧客がプロバイダー非依存のアドレスを持っているか、DNS を短命で独立した状態に保っている場合、移行は容易です。Cloud9 のネットワーク プレゼンスは有用ですが、現在使用しているアドレス空間が明日サービスとともに移動できると想定すべきではありません。

最も安全な買い手の姿勢は、最初の移行計画と退出計画を一つの文書として扱うことです。Cloud9 が適切なプロバイダーであっても、顧客がデータ、ドメイン、メールボックス、サーバー イメージ、機器を自分の管理下に戻す方法を定義できるべきです。

重要なワークロードを配置する前に顧客が確認すべきこと

公開証拠は Cloud9 を実際のジョージアのインフラストラクチャ プロバイダーとして裏付けています。したがって、顧客の疑問は「存在するのか？」よりも高度なものです。最初のセットは施設と容量に関するものです。どの正確な施設がサービスをホストしていますか？それは Cloud9 Dinamo Arena ですか、別の Cloud9 ルームですか、それともサードパーティ プラットフォームですか？特定の顧客サービスに、何台のラック、何本の電源フィード、冷却経路、ネットワーク経路が関与していますか？顧客の電力密度、帯域幅割り当て、フェイルオーバー容量は何ですか？セカンド サイトはありますか？それはアクティブですか、ウォームですか、バックアップ専用ですか？

2 番目のセットはネットワーク運用に関するものです。顧客のサービスはどのプレフィックスを使用しますか？それらは有効な RPKI ROA と最新の経路オブジェクトでカバーされていますか？どのアップストリームとピアが顧客のトラフィックを搬送していますか？顧客は経路多様性の保証を受けられますか？IXP.ge、1 つのアップストリーム、1 つのファイバー経路、1 つのビル ハンドオフが故障した場合、何が起こりますか？経路リーク、DDoS イベント、国際的な到達可能性の問題はどのように処理されますか？インシデント発生中に顧客はどのような可視性を得られますか？

3 番目のセットはデータ復旧に関するものです。バックアップはどのくらいの頻度で取得されますか？どこに保存されますか？それらは不変ですか、または本番資格情報から隔離されていますか？リストア テストはどのくらいの頻度で行われますか？完全な仮想サーバー、メールボックス、データベースはどのくらいの速さで復元されますか？Cloud9 の主要ポータルが利用できなくても顧客はリストアできますか？バックアップ エクスポートは料金に含まれていますか？緊急エクスポートは帯域幅によってレート制限されますか？

4 番目のセットはサポートと管理に関するものです。営業時間外に誰が応答しますか？どの問題がリモート ハンズでカバーされ、どれが課金対象ですか？コロケーション、専用サーバー交換、経路変更、ドメイン移転、メール停止のサポート エスカレーション パスは何ですか？顧客は何人の承認済み連絡先を維持できますか？請求連絡先が退職した場合、どうなりますか？顧客は請求連絡先とは別の緊急連絡先を指定できますか？

5 番目のセットは退出に関するものです。顧客は要求に応じて、現在の資産リスト、DNS ゾーン ファイル、メールボックス エクスポート、VM イメージ、バックアップ コピー、ドメイン転送コード、アクセス レコードを受け取れますか？どのくらいの通知が必要ですか？紛争中はどうなりますか？削除またはキャンセルされたサービスはどのくらいの期間回復可能ですか？どのデータがいつ破棄されますか？これらの質問は敵対的なものではありません。ホスト サービスを責任ある依存関係に変えるための最低条件です。

結論

Cloud9 Cloud 9 Ltd. は、信頼できる公開インフラストラクチャ証拠を持つ、稼働中のジョージアのホスティングおよびデータセンター プロバイダーとして理解されるべきです。同社自身のページが関連サービスを販売しています。RIPE レコードは Cloud 9 Ltd. を AS57814 と AS49297 に結び付け、RIPEstat は AS57814 がアナウンスされている一方で AS49297 は BGP で可視でないことを示しています。AS57814 は IPv4 と IPv6 にわたって意味のある経路サーフェスを持ち、発信およびトランジット可視性を備えています。PeeringDB は Cloud9 をトビリシの Cloud9 Dinamo Arena に配置し、IXP.ge プレゼンスを示しています。Cloud9 のデータセンター ページは、電力、冷却、火災抑制、監視、キャリア相互接続に関する具体的な施設の主張を提供しています。

これは最も弱い解釈を超えるのに十分です。Cloud9 は単なるディレクトリ上の名前ではありません。ジョージアの企業、開発者、公共機関、地域サービス プロバイダーにとって重要になり得る、施設中心のオファー、公開ルーティング プレゼンス、およびリテール製品を持つローカル インフラストラクチャ プロバイダーです。価値提案は明確です。ジョージアのネットワークに近い、ローカル サポートとキャリアニュートラルと自称するデータセンター オペレーターによるホストまたはコロケーション容量を購入することです。

残るリスクは、すべての地域クラウドおよびホスティング プロバイダーに伴うリスクと同じです。クラウドというラベルは、ラック、トランジット、電力、ハードウェア、DNS、課金、アカウント アクセス、移行を消し去るものではありません。公開ページは、コンポーネント障害時の予備容量、バックアップ インシデント後のリストア速度、顧客のエクスポート権限、時間外のエスカレーション、ある施設から別の施設へのクリーンなフェイルオーバーを証明しません。顧客は、これらの条件を文書化すれば Cloud9 をうまく利用できます。ブラック ボックスとして使用すべきではありません。

重要なワークロードに対しては、Cloud9 の容量は現実的だが契約依存であると扱うべきです。同社は真剣に受け止めるのに十分な公開インフラストラクチャ証拠を持っています。顧客の安全性は、その証拠を具体的な回答に変換することにかかっています。ワークロードがどこで実行され、それと一緒に何が故障し、経路がどのように存続し、バックアップがどのように復元され、誰がハードウェアを修理し、誰が時間外に応答し、請求書やアカウント連絡先が誤った場合に何が起こり、顧客がデータや制御を失うことなくどのように退出するか。