要約
- Green Cloud Technologies,LLC には、休眠状態のホスティングラベル以上の運用証拠があります。ARIN は AS54155 を Green Cloud Technologies,LLC に紐付けており、RIPEstat の2026年7月時点のビューではアクティブな IPv4 アナウンス、広範なルーティング可視性、および6つの観測されたネイバーが示されています。ただし、ルーティングサーフェスは接続性の証明にはなりますが、サイトの多様性、ハードウェアスペアパーツの深度、または顧客のリカバリ能力を証明するものではありません。
- 最も強力な証拠は歴史的かつ取引的なものです。11:11 Systems は2021年12月に Green Cloud Defense の買収を完了したと発表し、Green Cloud を大規模なチャネル専用独立系 IaaS プロバイダーと説明し、アトランタ、グリーンビル、ヒューストン、ミネアポリス、ナッシュビル、フェニックスにデータセンターがあるとリストしました。この証拠は事実ですが、現在の顧客は買収時の都市リストだけでなく、現在の配置スケジュールを必要としています。
- Green Cloud のルーティングドメインは混合しているようです。ARIN の RDAP レコードでは、一部のプレフィックスは Green Cloud に直接リンクしていますが、現在アナウンスされている他のアドレスブロックは Cirrity、ipHouse、Advanced Network Solutions、または INAP によって割り当てられた Green Cloud レコードを指しています。これは買収、リース容量、レガシーインフラと整合性がありますが、所有権、施設アクセス、サポート責任を回復力の評価において分離する必要があることも意味します。
- パブリックインターコネクションの履歴は不完全です。RIPEstat は Cogent、Level 3、Zayo、Hurricane Electric、Megaport、Unitas を含むネイバーASN を観測していますが、PeeringDB は AS54155 のネットワークプロファイルを返さず、サンプルチェックした RPKI 検証は不明なステータスを返しています。これらのギャップ自体がサービスを脆弱にするわけではなく、契約によって証明される必要がある部分を示しています。
- 証拠の評価は「中程度」であり、「強力」ではありません。Green Cloud の公開記録はライブの運用クラウドとネットワークサーフェスを裏付けていますが、ブランドは11:11に統合され、Green Cloud 固有の運用マップは最新ではなく、リカバリは施設、トランジット、サポート、データエクスポートに関する詳細に依存しており、公開ページでは部分的にしか開示されていません。
クラウドブランドの裏にあるハードウェア運用
Green Cloud Technologies,LLC は、ホステッドキャパシティをラックから外側に向かって読み解くべき理由の一例です。同社はパートナーを通じてクラウドインフラストラクチャを販売していました。顧客は仮想マシン、デスクトップ、バックアップリポジトリ、リカバリターゲット、または管理されたセキュリティエンベロープを見ていました。その下にある運用上の義務はより具体的なものでした：建物、電力、冷却、キャビネット、ハイパーバイザー、ストレージアレイ、ルーター、相互接続、トランジット契約、監視システム、そして技術者。
公開されたアイデンティティの痕跡はデジタルリソースから始まります。ARIN の AS54155 に関する RDAP レコードは、GREENCLOUD という名前で、Green Cloud Technologies,LLC を登録者としてリストしています。RIPEstat の AS 概要は、ホルダーラベル「GREENCLOUD - Green Cloud Technologies,LLC」を使用し、2026年7月のビューで AS がアナウンスされていることを示しています。これは、古い Web サイトよりも強力な証拠であり、法人名にリンクされたインターネット制御プレーン上でのライブプレゼンスを示しているためです。
それでも、回復力を購入するには不十分です。自律システム番号は、グローバルルーティングに現れる起点を示します。それだけでは、顧客のワークロードがどの建物でホストされているか、2台のルーターが別々の防火区画にあるか、第2のトランジットがピーク負荷を処理できるか、またはスペアディスクや交換用サーバーがオンサイトにあるかはわかりません。AS54155 は境界を確立できますが、それだけではリカバリの約束を確立できません。
ブランドの歴史が重要なのは、Green Cloud が独立したチャネルクラウドから、より広範なマネージドインフラストラクチャプラットフォームの一部へと移行したためです。11:11 Systems は2021年12月に Green Cloud Defense の買収完了を発表し、Green Cloud をマネージドサービスプロバイダー、付加価値再販業者、IT コンサルタントにサービスを提供するチャネル専用 IaaS プロバイダーと説明しました。同じ発表では、これらのパートナーが2,000以上の企業にサービスを提供していると述べ、アトランタ、グリーンビル、ヒューストン、ミネアポリス、ナッシュビル、フェニックスにデータセンターをリストしました。購入者にとって、これらの事実は、爆発半径が Green Cloud の直接の顧客リストだけではないことを意味します。それは、サービス背後にあるインフラストラクチャオペレーターよりもローカル MSP をよく知っている可能性のある下流の企業にも及びます。
これにより、Green Cloud は依存関係の乗数となります。直接のクラウドプロバイダーが故障した場合、顧客は通常プロバイダー名を目にします。チャネルクラウドが故障した場合、最初に目に見える当事者は、サービスをパッケージ化した MSP、再販業者、またはコンサルタントである可能性があります。契約上のサポートパスは、ルートを変更したり、ハードウェアを交換したり、移行を承認したりできる人に到達するまでに、複数の層を通過する可能性があります。そのため、Green Cloud の真の運用サーフェスは AS54155 だけではありません。AS54155 に加えて、パートナーネットワーク、サポートキュー、レガシープラットフォームコンポーネント、そして11:11の現在の配置ポリシーが含まれます。
Green Cloud の現在の証拠は本物だが、単純ではない
最も有用なルーティングスナップショットは企業のスローガンではなく、公開ルーティングステータスです。RIPEstat の AS54155 ルーティングステータスは、ここで使用した2026年7月のビューで、30の IPv4 プレフィックス、8,192の IPv4 アドレス、この出力で報告された RIS ピア全体での完全な IPv4 可視性、可視の IPv6 アナウンスなし、6つの観測されたネイバーを示しました。RIPEstat のアナウンスプレフィックスビューには、162.218.104.0/22、198.71.76.0/22、207.200.176.0/23、45.42.134.0/24などのブロックや、個々の/24ルートが多数含まれていました。
これらは表面的な事実ではありません。30の現在の IPv4 プレフィックスは、テストするためのアクティブなルーティングサーフェスが存在することを意味します。コレクターの広範な可視性は、公開観測時点でルートが単なるローカルまたはプライベートなアナウンスではなかったことを意味します。同じビューで IPv6 が可視されないことも有用な制約です。デュアルスタックの準備状況をクラウドのラベルから推測すべきではありません。IPv6 到達性、IPv6 のみの監視、デュアルスタックフェイルオーバー、公共セクターの調達要件に依存する顧客は、現代のクラウドプロバイダーが当然持っているだろうという一般的な主張ではなく、現在の製品証拠を必要とします。
アドレスレコードは、単一の企業説明が誤解を招く理由も示しています。ARIN の162.218.104.0の RDAP レコードは Green Cloud ブロックを指しています。ARIN の198.71.76.0の RDAP レコードも Green Cloud を指しています。しかし、アナウンスされている他の範囲には異なる手がかりがあります。207.200.176.0は Advanced Network Solutions を指し、162.244.152.0は Cirrity を指し、INAP によって割り当てられたいくつかのレコードは Green Cloud ラベルを持っています。このパターンは、単一の均一なアドレスドメインを所有するプロバイダーではなく、買収、割り当て、リースされたインフラストラクチャを通じて蓄積または運用してきたプロバイダーと一致します。
Cirrity の手がかりは特に重要です。Green Cloud による Cirrity 買収に関する VMblog の公開報道では、Cirrity をアトランタのクラウドサービスプロバイダーと説明していました。現在 Green Cloud から発信されているアナウンスプレフィックスが Cirrity にたどり着く場合、それは現在のワークロードがどこにあるかを自動的に証明するものではありませんが、Green Cloud のキャパシティをレガシードメインとして精査する必要がある理由を説明します。買収されたプラットフォームは、別々のストレージ設計、別々のハイパーバイザーバージョン、別々のベンダー契約、別々の顧客義務、別々のメンテナンス慣行をもたらすことがよくあります。統合はサービスを改善する可能性がありますが、インシデント時にのみ現れる隠れた継ぎ目を残すこともあります。
6都市リストは有用だが、配置保証ではない
2021年の買収発表は、Green Cloud に関する最も明確な公開都市リストです。11:11は、アトランタ、グリーンビル、ヒューストン、ミネアポリス、ナッシュビル、フェニックスに Green Cloud データセンターをリストしました。BusinessWire の買収発表とTiger Infrastructure のポートフォリオ企業である11:11 Systems が Green Cloud を買収するという PRNewswire のリリースは、同じ戦略的ストーリーを補強しています。つまり、Green Cloud は、接続性、クラウド、セキュリティのより広範なプラットフォームに統合されつつあったのです。
都市リストは、漠然とした「米国クラウド」ラベルから具体的な物理的市場のセットへと分析を移行させるため、価値があります。アトランタは南東部の主要な接続ハブです。グリーンビルはサウスカロライナ州の本社と地域的な運用コンテキストを提供します。ヒューストン、ミネアポリス、ナッシュビル、フェニックスは、電力、暴風雨、人員、通信事業者の密度、顧客レイテンシーにとって実質的に異なるリスクゾーンです。6つの市場すべてに拠点を持つ単一のプロバイダーは、有用な配置選択肢を提供できます。また、それらの間で深度が均一でない可能性もあります。
リストは個別アカウントの配置保証ではありません。MSP の顧客仮想サーバーはある都市にあり、バックアップは別の都市にあるかもしれません。災害復旧ターゲットは予約されていても、過小設計かもしれません。Desktop-as-a-Service プールは、データ主権の好みよりもサポートの慣行によってローカライズされるかもしれません。セキュリティサービスは、計算ワークロードとは異なるプラットフォームにログやチケットを保存するかもしれません。現在の見積もり、サービススケジュール、またはアーキテクチャの補足資料がなければ、過去の都市リストは、検証すべき地理として扱われ、依存する約束ではありません。
現在の11:11のフットプリントはコンテキストを拡大します。クラウドリージョンページでは、同社が世界中で25以上の施設を運用しており、セキュリティ、安定性、データ主権がクラウドの姿勢の中心であると述べています。このページでは、アトランタ、シカゴ、ダラス、ロサンゼルス、ニューヨーク、サンノゼ、スコッツデール、トロントなどの大都市にある北米データセンターもリストされており、さらにバージニア州やニュージャージー州のような州の場所も含まれています。これは、Green Cloud の歴史的なマップよりも広範な親のフットプリントを示しています。
データ主権にとって、より大きいことが自動的に良いわけではありません。より広いプラットフォームは、より多くの復旧オプションとより多くのローカル配置選択肢を提供する可能性がありますが、Green Cloud の過去のどのコミットメントが現在の11:11のどのリージョンに依然として対応しているのかを曖昧にするかもしれません。顧客は正確な配置マトリックスを求めるべきです：本番コンピュート、複製ストレージ、バックアップ、スナップショット、管理プレーンログ、チケット記録、セキュリティテレメトリ、およびあらゆる国境を越えるサポートアクセス。関連する国は、企業の米国登録地だけではありません。それは、顧客データ、メタデータ、および運用アクセスが存在しうるすべての場所です。
サービス組み合わせは単なるネットワークではなくキャパシティベンダーを示す
Green Cloud の過去の公開説明と11:11の現在の製品ページは、単純な接続性ではなく、ホステッドキャパシティを指し示しています。2021年の買収資料では、Green Cloud をバックアップ、災害復旧、Desktop-as-a-Service、およびマネージドセキュリティサービスを備えた IaaS プロバイダーと説明していました。11:11のクラウド概要では、VMware ベースのパブリックおよびプライベートクラウドホスティング、移行サポート、セキュリティ、コンプライアンス、バックアップについて説明しています。11:11ホステッドプライベートクラウドは、シングルテナントのプライベートクラウド、移行サポート、事前構築済みおよびカスタム構成、専用サーバー、ストレージ選択、および N+1 レジリエンスモデルを強調しています。11:11フレキシブルクラウド環境とコロケーションは、ベアメタル、コロケーション、低遅延ネットワーキング、監視、および24時間サポートにまでこの表現を拡張しています。
これは物理的な資産の話です。プライベートクラウドには、コミットされたブロックを満たすのに十分な専用サーバー在庫が必要です。ベアメタルサービスには、実際のハードウェアスペア、ファームウェアの統制、およびマシンにアクセスできるサポート担当者が必要です。VMware サービスには、ライセンス、ハイパーバイザーライフサイクル管理、ストレージの互換性、および移行ツールが必要です。コロケーションの拡張には、施設、ケージまたはラック、相互接続の注文、リモートハンズ、および電力容量が必要です。顧客は抽象化を購入します。プロバイダーはハードウェアと契約ビジネスを管理します。
11:11のプライベートクラウドページにある N+1 という表現は有用ですが完全ではありません。N+1 は、クラスター内の追加コンポーネント、追加電源ユニット、追加ホスト、追加ストレージコントローラー、またはより広範な設計哲学を意味する場合がありますが、必ずしもデュアルサイトフェイルオーバー、あらゆるインシデント下での完全なライブマイグレーション、または都市全体の停止を吸収する能力を意味するわけではありません。顧客は、どの層に N+1 保護があるのかを尋ねるべきです：コンピュートホスト、ストレージコントローラー、アグリゲーションスイッチ、エッジルーター、電源、冷却、バックアップリポジトリ、およびサポート担当者。正しい答えはワークロードによって異なります。小さな Web サービスには、自動再起動と十分な帯域幅が必要かもしれません。規制されたデータベースには、同期または慎重に管理されたレプリケーション、監査証跡、保持保証、文書化された退出手順が必要かもしれません。
この区別は重要です。なぜなら、Green Cloud の過去のチャネルモデルは、キャパシティを実際以上に弾力的に見せる可能性があるからです。パートナーはサービスを迅速に販売できます。インフラオペレーターは、実際に所有しているものだけを展開、予約、修復できます。ハードウェア在庫、ラック電力、またはトランジット余力が不足すると、障害はマーケティングの失敗として見えません。それは、遅いプロビジョニング、遅延したアップグレード、制限された復旧ウィンドウ、延期されたメンテナンス、またはプラットフォームチームを必要とするサポートチケットとして現れます。
SLA が顧客の露出ポイントを示す
Green Cloud に関する最も有用な公開文書の1つは、過去のGreen Cloud Technologies のサービスレベル契約および保守ポリシーPDFです。これは日付が古く、確認なしに現在の契約として扱うべきではありませんが、Green Cloud が障害境界をどのように定めていたかについての実用的な窓口として残っています。この文書は、Green Cloud が所有するインフラストラクチャ周辺のサービス可用性、計画保守、災害復旧層、サポート優先度について説明しています。また、顧客側ネットワークやより広範なインターネットの依存関係など、プロバイダーの管理が及ばない部分も除外しています。
この構造はホステッドプロバイダーとして正常であり、まさにそのため、顧客は境界を注意深く読むべきです。Green Cloud の境界内ではサービスが到達可能でも、顧客の ISP パスが壊れている場合、クラウドは利用可能とカウントされる一方で、顧客はダウンしています。仮想環境は動作しているが、特定のアプリケーションが誤設定されている場合、インフラプロバイダーはアプリケーション停止の責任を負わないかもしれません。保守ウィンドウが計画されている場合、影響を受けるサービスは、計画外の障害と同じ救済策を生み出すことなく利用できなくなる可能性があります。実用的な問題は、SLA が高い可用性パーセンテージを使用しているかどうかではありません。どの障害がカウントされ、どの障害がカウントされないか、そしてその間の運用上の痛みを誰が負うかです。
同じ文書のサポートモデルは、労働力がキャパシティの一部であることを思い出させます。優先度1の問題は最も迅速な対応を受けます。重大度が低い問題は待つことがあります。時間外の緊急サポートは重要なインシデントに焦点を当てています。保守はサービスライフサイクルの通常の一部として扱われます。言い換えれば、サポートは無限のエンジニアプールではありません。重大度、スケジュール、資格によって配給されます。これは合理的ですが、復旧、移行、または相互接続の変更が、顧客のビジネスが圧迫されている場合でも最高の優先度を下回ると、顧客リスクになります。
11:11の現在のサポートページは、より大きなスケールでサポート境界というテーマを継続しています。グローバルサポート番号、アカウントとコンソールのリンク、クラウドサービス、セキュリティサービス、接続サービス、請求のための個別の連絡先がリストされています。この分離は運用上役立ちますが、顧客に対して、事前に障害の所有権をマッピングするようにも伝えています。Green Cloud 由来のワークロードは、コンピュート、セキュリティ、接続、請求、またはアクセス管理を通じて失敗する可能性があります。パスごとに異なるキューとエスカレーション慣行があるかもしれません。
請求パスが注目に値するのは、クラウド障害が技術的なものだけではないためです。アカウントの停止、契約上の紛争、ライセンスの不一致、前払い残高の枯渇、または決済方法の失敗は、エンドユーザーにとってインフラの問題のように見えるダウンタイムイベントを生み出す可能性があります。チャネルパートナーを持つプロバイダーは別の層を追加します：最終顧客は MSP に支払い、MSP は上流プラットフォームに支払う場合があり、ある層での紛争がサービスの継続性に影響を与える可能性があります。したがって、回復力の精査には、バックアップとルーティングの図だけでなく、請求とアカウント管理のエスカレーションルールも含めるべきです。
トランジットの多様性は示唆されているが証明されていない
AS54155 の RIPEstat ASN ネイバービューは、ここで使用した2026年7月のデータで6つのネイバーを観測しました。ASN は重要な、またはインフラ関連の名前に解決されます：Cogent、Level 3、Zayo、Hurricane Electric、Megaport、Unitasです。これは、公開ルーティングビューで単独の上流が1つだけ見えるよりも優れています。
しかし、BGP の隣接性と物理的な多様性は別物です。ルートコレクターはネイバーを見ることはできますが、それらのネイバーがフルトランジットか、部分ピアか、エクスチェンジルートか、プライベート相互接続か、レガシーセッションかは購入者に伝えません。表面上は異なる2つの上流が、同じミートミールームを通じて同じ建物に入っていたり、同じメトロファイバーの断線に依存していたりする可能性があります。Megaport セッションはソフトウェア定義の相互接続に価値があるかもしれませんが、それでも基盤となるファイバーパス、ポート、プラットフォーム、リモート終端に依存します。プロバイダーは複数の論理パスを持ちながら、施設の停止、相互接続の滞留、または変更管理の失敗に対して脆弱である可能性があります。
通常、PeeringDB は施設、エクスチェンジ、ピアリングポリシー、トラフィックの手がかりをリストするため、このギャップの一部を埋めるのに役立ちます。Green Cloud の場合、AS54155 の PeeringDB API 検索ではネットワークプロファイルが返されませんでした。PeeringDB の欠如はそれ自体が失敗ではありません。多くの正当なプロバイダーは最新のプロファイルを維持していません。それにもかかわらず、相互接続サイト、トラフィックポリシー、または施設添付を明確にできたはずの事業者保守のソースが削除されます。これは、証拠の評価が「強力」を下回るもう1つの理由です。
ルーティングの起点セキュリティも、公開チェックからは不完全です。AS54155 と162.218.104.0/22についてのサンプル RIPEstat RPKI 検証クエリは、この応答に検証 ROA が現れなかったため、不明なステータスを返しました。別の現在のプレフィックスに対する2回目のクエリも同じ種類の不明な結果を生み出しました。RPKI ステータスが不明だからといって、誤ったルーティングや使用不可を証明するものではありません。厳密なルーティング起点検証に依存する顧客は、実際に彼らのサービスを運ぶプレフィックスに対して ROA が存在するか、そうでなければ、オペレーターのルーティングセキュリティ計画は何かを尋ねるべきです。
BGP.tools for AS54155、Hurricane Electric BGP Toolkit、IPinfo AS54155 ページなどのネットワーク可視性ページは有用なクロスチェックですが、同じ制限があります。それらは到達性とルーティングメタデータを表示します。ラックの電力、ルートの多様性、復旧手順、または各セッションの下にあるビジネス上の義務を検証するものではありません。
買収により範囲は拡大したが統合リスクも増大
Green Cloud は11:11の前に静止していませんでした。同社は買収とセキュリティサービスの重ね合わせを通じて成長しました。Green Cloud が Cascade Defense を買収する最終合意に達した11:11のアーカイブページやGreen Cloud の買収およびブランド変更の発表は、同社が純粋なクラウドインフラを超えてマネージドセキュリティへと移行したことを示しています。MSSP Alert の Cascade に関する報道はこの取引をマネージドセキュリティサービスプロバイダー市場の中で位置づけ、MSSP Alert の11:11による買収報道は、Green Cloud のクラウドとセキュリティプラットフォームを11:11のより広範な戦略に結びつけました。
買収は本質的にリスクではありません。資本、自動化、新製品、より良いセキュリティ慣行、より深いサポートをもたらす可能性があります。11:11の買収発表は、この組み合わせが Green Cloud の全国チャネルパートナーネットワークに接続およびセキュリティ機能を追加すると述べました。また、取引後の技術とリーダーシップの継続性についても言及しており、これは運用上の引き継ぎにとって重要です。
リスクは、買収されたドメインが不均等に老朽化することが多いことです。買収されたクラウドは、異なるストレージレプリケーション、異なるチケットシステム、異なるファイアウォール標準、異なるバックアップスタック、または異なる施設契約セットを使用している可能性があります。セキュリティサービスは独自のロギングと監視の依存関係を持っているかもしれません。チャネルパートナーは、上流プラットフォームが合理化されている間も、古い習慣で販売を続けるかもしれません。単に「今は11:11か」とだけ尋ねる顧客は、より重要な質問を見逃す可能性があります：実際にこのワークロードをホストしているのはどのホステッドプラットフォームか？
これが、Cirrity と Cascade の歴史がレジリエンスレビューにとって重要である理由です。Cirrity はクラウドとアドレスの遺産の一部を説明します。Cascade はマネージドセキュリティ層を説明します。11:11は現在の親プラットフォームを説明します。これらの事実はどれも悪くありません。全体として、顧客がマップを要求すべきことを意味します。そのマップは、指名されたサービスを物理的なサイト、アドレスブロック、上流パス、バックアップターゲット、セキュリティ監視スタック、サポートキュー、および契約エンティティに結びつけるべきです。
ベンダーパートナーシップがプラットフォームの形を示す
Green Cloud の公開技術リファレンスは、現実のホステッドキャパシティプラットフォームのイメージを裏付けています。Green Cloud が Cisco UCS S-Series サーバーを使用して新規ビジネスを強化していることに関する Cisco データセンターブログでは、同社が新規ビジネスラインを支えるために Cisco サーバーインフラを使用していると説明されていました。Green Cloud Defense の VMware クラウドプロバイダーブログプロファイルは、同社を VMware クラウドプロバイダーエコシステムに位置づけました。11:11のクラウド概要は現在、この VMware ベースのフレーミングを継続しています。
これらのリファレンスは、議論を純粋に仮想的な言語から遠ざけるため重要です。VMware クラウドは、ホスト、クラスター、データストア、管理サーバー、ライセンス契約、パッチサイクル上で動作します。Cisco UCS 環境は、ファブリックインターコネクト、サーバープロファイル、ファームウェア依存関係、ストレージ選択を持ちます。Fortinet とマネージドセキュリティサービスには、センサー、ログ取り込みパス、アナリスト、エスカレーションルールがあります。各層は、適切に管理されればサービスを強化できます。各層はまた、独自のメンテナンスウィンドウや単一の運用障害点をもたらす可能性もあります。
公開されている技術パートナーの言及は能力監査ではありません。それらは、何台のサーバーが配備されているか、何台が予約されているか、特定の顧客に対してストレージがオールフラッシュかハイブリッドか、あるいは各都市で障害が発生したホストをどれだけ早く交換できるかを伝えません。しかし、購入者に何を尋ねるべきかを伝えます。顧客は、自分のワークロードが VMware Cloud Foundation、vCloud Director、レガシーVMware スタック、専用ベアメタル、またはコロケーションプラットフォームのいずれに依存しているかを尋ねるべきです。バックアップが本番と同じストレージファミリ上にあるかどうかを尋ねるべきです。管理アクセスが別の制御ネットワークに依存しているかどうかを尋ねるべきです。特に VMware エコシステムにおけるライセンスの変更が、価格や移行スケジュールをどのように変え得るかを尋ねるべきです。
同じことがセキュリティにも当てはまります。管理されたファイアウォール、SIEM、またはエンドポイントサービスは、人員が配置され統合されている場合、リスクを低減できます。また、セキュリティプラットフォーム自体の可用性への依存を生み出すこともあります。セキュリティ管理プレーンがダウンした場合、顧客はまだファイアウォールルールを変更できますか？SIEM 取り込みパスに遅延がある場合、誰がそれに気づきますか？サービスが MSP を通じて再販されている場合、誰がアラートを受け取り、誰が封じ込めを承認する権限を持っていますか？
チャネル顧客は重層的な責任を引き継ぐ
Green Cloud のチャネル専用志向は脚注ではありません。11:11の買収発表は、700を超える MSP、VAR、IT コンサルタントからなる全国のチャネルパートナーネットワークが、2,000を超える企業にサービスを提供していると説明していました。これは、影響を受ける多くのエンドユーザーが Green Cloud を直接のプロバイダーとして経験しない可能性があることを意味します。彼らは、地元のテクノロジープロバイダーのクラウド、バックアップ、またはセキュリティサービスとして経験するかもしれません。
チャネル流通はインシデントの振る舞いを変えます。下流の企業は MSP に電話するかもしれません。MSP は11:11またはレガシーGreen Cloud サポートパスでチケットを開くかもしれません。11:11は、クラウド、接続、セキュリティ、または請求チームを関与させる必要があるかもしれません。その後、施設プロバイダー、通信事業者、またはハードウェアベンダーが行動を起こす必要があるかもしれません。各引き継ぎには時間がかかります。各関係者が異なる可視性と異なる権限を持つ可能性があります。小規模なインシデントでは、この階層化は見えないかもしれません。地域的な停止、移行、または請求の行き詰まりでは、計測された回復と数日間の不確実性の違いを生む可能性があります。
このリスクを低減する最善の方法は、インシデント前にエスカレーションを定義することです。エンドカスタマーは、誰が復旧を承認できるか、誰がフェイルオーバーを許可できるか、誰がデータをエクスポートできるか、誰が DNS を変更できるか、誰が代替容量をプロビジョニングできるか、誰が影響を受けるユーザーと通信できるかを知るべきです。MSP は、コンソールアクセス、API アクセス、緊急電話アクセス、時間外の変更権限があるかどうかを知るべきです。プラットフォームオペレーターは、どのチャネルパートナーが重要なアカウントを持ち、どのアカウントが特別な復旧計画を必要とするかを知るべきです。
公開情報は、チャネルモデルが Green Cloud の成長の中心であったことを示唆しています。Green Cloud の Inc. 5000プロファイルとGreen Cloud が Inc. 5000最速成長企業リストに5回目の選出を祝う11:11のアーカイブページは、同社が静的なエンタープライズ IT 部門ではなく、成長段階のインフラベンダーであったことを補強します。成長はポジティブですが、インフラにおいてはキャパシティの疑問を提起します：サポート、ハードウェア在庫、自動化、復旧テストは、パートナー基盤の規模に追いついていたか？
メンテナンスウィンドウは製品の一部
ホステッドサービスはしばしば継続性を売りますが、メンテナンスを避けることはできません。ファームウェアの更新、ハイパーバイザーのパッチ、セキュリティ更新、ルーターのメンテナンス、ストレージコントローラーの変更、バックアッププラットフォームのアップグレード、物理的な修復はすべて計画的な作業を必要とします。Green Cloud の SLA およびメンテナンス文書は、メンテナンスウィンドウとサービス優先度の取り扱いを概説することで、これを可視化しています。繰り返しますが、この文書は現在の11:11の条件と照らし合わせて確認する必要がありますが、運用上の現実はどのプロバイダーにも当てはまります。
実用的な問題は、メンテナンスが顧客の復旧とどのように相互作用するかです。本番とバックアップが同じウィンドウでメンテナンスされる場合、変更の失敗が両方に影響する可能性があります。メンテナンス中にストレージレプリケーションが一時停止される場合、復旧ポイント目標（RPO）が長引く可能性があります。ネットワークの変更がプライマリパスとセカンダリパスの両方に影響する場合、隠れた共通依存関係が露呈するかもしれません。メンテナンスイベントが同様に影響を受けるポータルを通じて通知される場合、顧客はサービスとステータスの可視性の両方を失う可能性があります。
StatusGator の Green Cloud Technologies ページ、Rootly の外部ステータスページリスト、Netbeep の Green Cloud Technologies ステータスページなどの公開ステータスアグリゲーターは非公式なシグナルです。信頼できるインシデント履歴として扱うべきではありません。これらは、外部の観測者が Green Cloud の複数のサービスコンポーネントを追跡しており、メンテナンス/停止のコミュニケーションが顧客がサービスを体験する方法の一部であることを示唆しています。問題を解決する証拠は、オペレーターが管理するステータスアーカイブ、現在のメンテナンスポリシー、および顧客通知条件です。
メンテナンスは、データポータビリティの問題も生じさせます。顧客はシステムが正常なときにバックアップをテストし、インシデント時にエクスポートが予想よりも遅く、不完全で、または権限によって制限されていることを発見することがよくあります。Green Cloud または11:11の適切なレジリエンスレビューには、同じプラットフォーム内でのバックアップからの復元だけでなく、最大の重要なワークロードの時間指定エクスポートを含めるべきです。データの退出は物理的かつ運用上のタスクです：データはストレージから読み取られ、ネットワークを介して移動し、使用可能な形式にパッケージ化され、他の場所でそれを使用する権限を持つ誰かに引き渡されなければなりません。
データの所在地はレコード、ログ、リカバリコピーに依存
Green Cloud の米国サービスゾーンラベルは妥当ですが、データの所在地は国のラベルで止めるべきではありません。歴史的なデータセンターリストは米国ベースです。11:11の現在のクラウドフットプリントはグローバルです。同社はクラウド、バックアップ、災害復旧、マネージドセキュリティ、接続サービスを販売しています。各サービスは異なるデータを異なる場所に配置する可能性があります。
規制対象の顧客は、1つではなく6つの場所を尋ねるべきです。第一に、プライマリコンピュートインスタンスまたはベアメタルホストはどこにあるか？第二に、本番データを保持するストレージアレイはどこにあるか？第三に、バックアップとスナップショットはどこに保存されているか？第四に、災害復旧キャパシティはどこに予約または事前プロビジョニングされているか？第五に、ログ、監視記録、セキュリティテレメトリはどこに存在するか？第六に、サポートチケットとリモート管理セッションはどこから発信されるか？
答えが重要なのは、クラウドの所在地がカテゴリごとに失敗し得るからです。顧客はアトランタに本番データ、フェニックスにバックアップコピー、親会社のプラットフォームにセキュリティログ、別のシステムに請求データ、複数の国からのサポートアクセスを持っているかもしれません。これらはいずれも自動的に間違っているわけではありません。回復力にとって有用でさえあり得ます。しかし、顧客がその配置がプライバシー、契約、保険、顧客コミットメント、セクタールールに合致するかどうかを判断できるように、開示される必要があります。
11:11のクラウドリージョンページは、同社がセキュリティ、安定性、データ主権に焦点を当てており、物理的な所在地の保証を強調していることを示しています。これはテストすべき有用な約束です。購入者は書面によるメカニズムを求めるべきです：保証はリージョン、国、施設、クラウド製品、顧客契約ごとに適用されるか？バックアップを含むか？ログを含むか？マネージドセキュリティテレメトリを含むか？災害復旧フェイルオーバーを生き残るか？サポートエスカレーションを生き残るか？
障害パスはラック、ルーティング、修復、契約、そして退出
Green Cloud にとって最も重要な障害パスは、単一の破滅的なシナリオではありません。それは連鎖です。顧客のワークロードは物理的なプラットフォームに依存しています。それは AS54155 または親/パートナーのパスを介してユーザーに到達します。それはバックアップとストレージポリシーに依存しています。それはチャネルパスと11:11のサービスチームを通じてサポートされています。それはメンテナンス、請求、契約ステータスの影響を受ける可能性があります。サービスが要件を満たさなくなった場合に退出するのに十分な可搬性がなければなりません。
ラック層では、ホスト、ストレージ、ネットワークコンポーネントが支払われたサービスレベルに対して十分な冗長性を持っているかどうかが問題です。ルーティング層では、観測されたネイバーが実際の、多様で、十分な上流容量に変換されるかどうかが問題です。修復層では、スペアパーツと技術者がインシデントが発生している都市で利用可能かどうかが問題です。サポート層では、適切な人々がチャネルの引き継ぎを待たずに行動できるかどうかが問題です。契約層では、どのイベントがサービスコミットメントに対してカウントされ、どのイベントが除外されるかが問題です。退出層では、顧客が期限内にデータと設定の完全なセットを回復できるかどうかが問題です。
Green Cloud の公開証拠は、これらの質問を具体的に行うことを可能にします。AS54155 はアクティブです。一部のプレフィックスは Green Cloud に直接対応しています。他のものはレガシーまたは割り当てられた容量を示唆しています。11:11は現在のクラウド、プライベートクラウド、コロケーション、サポートページを公開しています。Green Cloud の歴史的な資料は、6つの米国データセンター市場、大規模なパートナーネットワーク、IaaS、バックアップ、DR、DaaS、セキュリティを含むサービスミックスを示しています。公開証拠が示さないものは、現在の製品別キャパシティマップ、監査されたフェイルオーバーテスト結果、現在の顧客エクスポート条件、サイト別トランジット図です。
そのため、正しい姿勢は拒否でも盲目的な信頼でもありません。単一のプレフィックスを持つ休眠シェルは、はるかに厳しい結論に値するでしょう。Green Cloud はそうではありません。しかし、完全な「強力」評価には、Green Cloud のレガシードメインを現在の11:11のクラウドリージョンにマッピングし、パスの多様性を証明し、RPKI ステータスを文書化し、買収したアドレスの管理を説明し、ストレス下で顧客がどのように回復または退出できるかを示す現在の運用証拠が必要です。
信頼する前に顧客が確認すべきこと
Green Cloud が支えるキャパシティを検討している顧客やチャネルパートナーは、配置スケジュールから始めるべきです。そのスケジュールには、実際のサービスについて、本番都市、セカンダリ都市、バックアップリポジトリ、セキュリティログの場所、サポート管轄区域を明記する必要があり、一般的なブランドについてではありません。アカウントがレガシーGreen Cloud、Cirrity のレガシーインフラ、INAP 割り当て環境、11:11のパブリッククラウド、11:11のプライベートクラウド、フレキシブルベアメタル、またはコロケーションのいずれに依存しているかを記述する必要があります。
第二に、顧客はルーティングおよび起点セキュリティの記述を要求する必要があります。AS54155 はアクティブな IPv4 アナウンスと観測されたネイバーを持っていますが、顧客はサービスに使用される実際のプレフィックス、上流またはピアリング設計、ルートフィルタリングポリシー、それらのプレフィックスの RPKI ステータスを必要とします。ROA が存在しない場合、プロバイダーはそれらが計画されているかどうか、そうでなければルートハイジャックやルートリークのリスクがどのように管理されているかを説明すべきです。
第三に、顧客は復旧文言を読むのではなく、フェイルオーバーをテストする必要があります。復旧テストでは、検出、許可、フェイルオーバー、アプリケーション検証、ユーザーアクセス、ロールバック、および請求への影響を測定する必要があります。チャネルパートナーを通じて購入する場合は、そのパートナーを含める必要があります。通信およびステータスパスを含める必要があります。ワークロードが全時間保護されているはずの場合、時間外サポートエスカレーションを含める必要があります。
第四に、顧客はデータ退出をテストする必要があります。エクスポートには、仮想マシンイメージまたはアプリケーションデータ、メタデータ、バックアップカタログ情報、ファイアウォールルール、DNS 依存関係、アクセス制御設定、監査に必要なログが含まれるべきです。エクスポートは、完了時間を測定しながら、現実的なネットワークパス上で実行されるべきです。同じプロバイダー内でのみ復元できるバックアップは多くのインシデントに有用ですが、プロバイダーの契約上の失敗や強制移行には不十分です。
最後に、顧客は契約を実際の障害パスと整合させる必要があります。SLA は単なる可用性パーセンテージとして読むべきではありません。含まれる依存関係と除外される依存関係のマップとして読むべきです：公共インターネット到達性、顧客設定、計画メンテナンス、セキュリティインシデント、サードパーティ通信事業者の障害、請求の行き詰まり、パートナーの誤り、不可抗力。顧客は、どの障害がクレジットを生み、どの障害が運用支援を生み、どの障害が何も生まないかを知るべきです。
要約
Green Cloud Technologies,LLC は、視覚的に現実的でありながら、運用上は重層的なキャパシティの形態を販売しています。公共インターネットは依然として AS54155 を認識しています。ARIN は依然として AS を Green Cloud Technologies,LLC に結びつけています。11:11の買収アーカイブと現在のクラウドページは、Green Cloud が消滅するのではなく、より広範なマネージドインフラストラクチャプラットフォームの一部となったという考えを支持しています。歴史的なサービス文書、買収アーカイブ、パートナーリファレンスは、同社が大規模なチャネルネットワークを通じて IaaS、バックアップ、DR、DaaS、セキュリティを販売していたことを示しています。
格下げも同様に重要です。Green Cloud 固有の都市とサービスの証拠は主に歴史的なものです。現在の公開ルーティングテーブルは、直接の Green Cloud アドレスレコード、買収されたもの、割り当てられたものが混在しています。PeeringDB は相互接続プロファイルを提供していません。サンプル RPKI チェックは不明です。サポートおよびメンテナンスモデルは、修復ウィンドウ、重大度キュー、除外された依存関係が重要であることを明確にしています。公開記録は、発表された、またはレガシーなすべての場所が同等の予備容量、同等のトランジット多様性、または同等の復旧深度を持つことを証明していません。
読者にとって、有用な結論は実用的なものです。Green Cloud を、単なるクラウドロゴとしてではなく、11:11の軌道の中のライブインフラ依存関係として扱ってください。重要なワークロードをその上に配置する前に、サイト配置、ルーティング多様性、復旧能力、サポート権限、メンテナンス慣行、データポータビリティの現在の証拠を要求してください。サービスの価値は、仮想マシンやバックアップリポジトリにあるだけではありません。それは、簡単な道がなくなったときに、まだ機能しなければならないラック、ルート、人々、契約にあります。