Cloud9 Cloud 9 Ltd.、ラック、トランジット、修理ウィンドウに依存するホスティング容量を販売

要約

• Cloud9 の公式サイトでは、ジョージアのホスティング、クラウド、データセンター事業者として、次のサービスを提供しているとしています：コロケーションとラック、VPS、VDS、専用サーバー、共有ホスティング、Zimbra メール、ドメイン、SSL、カスタマーポータルサービス。
• ネットワークの証拠は有意義です。RIPEstat は AS57814が Cloud9 Cloud 9 Ltd.のホルダーとして2026年7月12日にアナウンスされていることを示していますが、AS49297は同じホルダーに関連付けられているもののアナウンスされていません。AS57814 の RIPE RIS カウントは、28の発信元 IPv4 プレフィックス、13の転送 IPv4 プレフィックス、3つの発信元 IPv6 プレフィックス、2つの転送 IPv6 プレフィックスを示しています。
• 物理的な重心はトビリシです。Cloud9 のデータセンターページによると、ほとんどのサービスは自社のトビリシデータセンターから提供されており、PeeringDB には、トビリシの A. Tsereteli Ave 2にある Cloud9 Dinamo Arena 施設がリストされ、1つのエクスチェンジプレゼンスと公開サポート連絡先があります。
• 購入者のリスクは、Cloud9 が不可視であることではありません。公開証拠が、顧客固有のフェイルオーバー容量、スペアハードウェアの可用性、バックアップ復元パフォーマンス、サポートエスカレーション、または退出権をまだ証明していないことです。顧客は、Cloud9 でホストされた容量を自社の継続性設計の代替として扱う前に、これらの条件を確認する必要があります。

企業は分析に十分な可視性を持っている

Cloud9 Cloud 9 Ltd.は、多くの小規模ホスティング事業者よりも具体的な読み取りに値します。なぜなら、いくつかの独立した公開記録が一致しているからです。同社のサイトは、ジョージアのホスティングおよびデータセンタービジネスに Cloud9 ブランドを使用しています。ホームページでは、Cloud9 をジョージアのプロフェッショナルなウェブホスティングプロバイダーであり、経験豊富なデータセンター事業者であると説明しています。フッターには、ジョージア0112、トビリシ、ディナモスタジアム、ゲート5、アカキ・ツェレテリ通り2番地の営業住所、電話番号、サポートメールが記載されています。利用規約では、"Cloud 9 LLC"、会社 ID 405063755、トビリシの法的住所、契約およびサポート事項の連絡メールが特定されています。命名は公開面全体で完全に統一されているわけではありませんが、住所、ドメイン、レジストリの証拠は、同じジョージアのホスティング事業者を指しています。

RIR の記録は、そのアイデンティティをウェブサイトの主張以上のものにしています。AS57814 の RIPE RDAPは、登録者組織を Cloud 9 Ltd.とリストし、住所をジョージア、トビリシ、ツェレテリ通り2番地、0112と示し、公開の管理連絡先、技術連絡先、苦情連絡先を提供しています。ORG-CL434-RIPE の RIPE RDAPは、組織を Cloud 9 Ltd.、同じトビリシの住所、電話番号、連絡メールとしています。AS49297 の RIPE RDAPは、別の自律システムを同じ組織と連絡先セットに結び付けています。

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

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

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

公開ルーティングの図には、明確な中心と1つの重要な注意点があります。AS57814 の RIPEstat AS 概要は、ホルダーを Cloud9 Cloud 9 Ltd.と表示し、AS が2026年7月12日のクエリ時刻にアナウンスされているとマークしています。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 について28の発信元 IPv4 プレフィックス、13の転送 IPv4 プレフィックス、3つの発信元 IPv6 プレフィックス、2つの転送 IPv6 プレフィックスを示しています。これらのカウントは、アクティブな顧客数、プラットフォームの充足度、またはスペア容量の大きさを証明するものではありませんが、単一の休眠ルートよりも実質的に大きなネットワークサーフェスを示しています。

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

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

データセンターは提供の核心

Cloud9 のデータセンターページは、物理的な依存関係について異常に率直です。Cloud9 が提供するほとんどのサービスは、自社のトビリシ拠点のデータセンターから提供されると述べています。このページでは、キャリアニュートラルなデータセンター、エンジニアによる年中無休の監視、セキュリティ管理、電力冗長化、火災検知および消火、気候制御、相互接続性について説明しています。施設は3つの独立した変電所とバックアップの630 kVA ディーゼル発電機によって電力供給されていると述べています。また、コロケーションゾーンには UPS を備えた N+N 冗長電力供給があるとしています。接続性については、Cloud9 は主要な通信キャリアや小規模 ISP 事業者と、予約済みのダークファイバーを介して接続されており、いくつかの代替ルートと250 Gbps の総相互接続容量があると述べています。

PeeringDB は、別の方法でトビリシ施設の主張を支持しています。Cloud9 Dinamo Arena の PeeringDB 施設記録は、組織を Cloud9 LTD として、ジョージア0112、トビリシ、A. Tsereteli Ave 2の施設をリストし、事業がジョージアでデータセンター、ホスティング、クラウド、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 サービス、クラウドサービスを説明しています。これらはすべて同じ依存関係ではありません。

共有ホスティングは、ウェブサーバー、コントロールパネル、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 のグローバル接続を含むと述べています。また、管理リンクは内部 IP とセキュア VPN アクセスを使用した IPMI、iLO、iDRAC、または BMC アクセスのためのものであると述べています。

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

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

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

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

課題の初期リスク仮説は、薄い公開フットプリントを警告していました。実際のルートとピアリングの証拠はそれよりも強力です。PeeringDB の AS57814 ネットワーク記録は、Cloud9 を AS57814、ウェブサイト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つのサポート判断に依存する可能性があります。顧客は、自社のサービスにどのプロバイダーが使用されているか、ルートが積極的に監視されているか、Cloud9 がメンテナンスイベント中にトラフィックをシフトできるか、そして1つのピアまたはトランジットプロバイダーが障害を起こした場合に国際的な到達可能性が許容可能かどうかを尋ねるべきです。

ルーティング衛生は部分的だが可視的である

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

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

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

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

電源と冷却の主張は顧客固有の証明を必要とする

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

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

冷却にも同様の隠れた制約があります。DX 冷却は施設に適切かもしれませんが、顧客はラックレベルの密度制限、ホットアイル/コールドアイル設計、センサー配置、ラックが高温になった場合のエスカレーション経路を知る必要があります。施設に冗長冷却設計があっても、特定の顧客ラックは依然として気流や電力密度によって制約される可能性があります。火災抑制も、物理コロケーションと仮想サービスでは異なる意味を持ちます。火災抑制イベントは機器をより深刻な損傷から保護するかもしれませんが、それでも緊急アクセス制御、検査ウィンドウ、復旧遅延を引き起こす可能性があります。

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

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

Cloud9 の利用規約は、顧客が実際にどのようにインフラに触れるかを示すため重要です。規約では、ユーザーは cloud9.ge に登録し、my.cloud9.ge の Cloud9 ポータルで個人アカウントを受け取り、そこで新しい製品の購入、既存製品の管理、不要な製品のキャンセル、支払いの管理、サポートチケットの開封をいつでも行うことができると述べています。規約はまた、ユーザーがアカウントの機密性を維持し、アカウントで行われたアクションに対して責任を負うと述べています。

そのポータル設計は有用です。顧客は営業担当者との会話を待つことなくインフラを管理できます。また、アカウントアクセスを継続性の依存関係にします。顧客の認可されたメールアカウントが失われたり、資格情報が漏洩したり、スタッフが退職したり、課金連絡先が更新されなかったりすると、顧客のチケット開封、サービスのキャンセル、支払いの管理、緊急変更の実施能力が損なわれる可能性があります。規約は、ユーザーに連絡担当者、登録データ、メール、電話番号の詳細を最新に保つ責任を課しています。それは通常の法的文言ですが、障害時には運用上の問題になります。

課金も別の修復経路の依存関係です。請求書や決済期間の問題でサービスが無効になると、顧客は管理的な根本原因を持つ技術的障害を経験する可能性があります。顧客は、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 のコロケーションと仮想サーバーの提供は、ローカルキャパシティプレイと見なすことができます：顧客は近接性、地元企業、ローカルキャリアアクセス、ローカル施設を購入します。

"ほとんどの"という言葉は依然として重要です。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 を指していることを示しています。これらの名前は、小売ウェブ、ホスティング、メール提供をプロバイダー自身のサービス名前空間にリンクしています。

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

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

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

主な障害経路は普通であり、異例ではない

最も信頼できる Cloud9 の障害経路はサイエンスフィクションの出来事ではありません。それらはおなじみのインフラ問題です：ラック電力問題、冷却インシデント、ハードウェア障害、ルート漏洩、アップストリームキャリア障害、DDoS イベント、課金停止、ポータルアクセス問題、バックアップ失敗、スペア部品交換の遅さ、移行失敗、またはスタッフが処理できるよりも速く成長するサポートキュー。Cloud9 はホスト型サービスとコロケーションの両方を提供しているため、顧客への影響は顧客が購入したものに依存します。

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

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

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

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

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

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

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

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

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

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

公開証拠は、Cloud9 を実際のジョージアのインフラプロバイダーとして支持しています。したがって、顧客の質問は「それは存在しますか？」よりも高度です。最初のセットは施設と容量に関するものです。正確にどの施設がサービスをホストしていますか？それは Cloud9 Dinamo Arena、別の Cloud9 ルーム、またはサードパーティプラットフォームですか？特定の顧客サービスに対して、いくつのラック、電力供給、冷却経路、ネットワーク経路が関与していますか？顧客の電力密度、帯域幅割り当て、フェイルオーバー容量はどのくらいですか？第2のサイトはありますか、それはアクティブ、ウォーム、またはバックアップのみですか？

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 の容量は現実的であるが契約に依存するものとして扱われるべきです。同社は、真剣に受け止められるのに十分な公開インフラ証拠を持っています。顧客の安全性は、その証拠を具体的な回答に変えることに依存します：ワークロードがどこで実行されるか、それとともに何が障害を起こすか、ルートがどのように生き残るか、バックアップがどのように復元されるか、誰がハードウェアを修理するか、誰が時間外に対応するか、請求書やアカウント連絡先に問題が発生した場合に何が起こるか、そして顧客がデータや制御を失うことなくどのように退出するか。