要約
- 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 の Green Cloud ネットワークプロファイルがなく、サンプル RPKI チェックでは未知のステータスが返された。これらのギャップだけでサービスが弱いと判断できるわけではないが、それらは契約によって証明されるべき部分を示している。
- 証拠グレードは「中」であり、「強」ではない。Green Cloud の公開記録は、稼働中のクラウドとネットワーク運用面を裏付けているが、ブランドは 11:11 に統合されており、Green Cloud 固有の運用マップは古く、復旧は、公開ページが部分的にしか開示していない施設、トランジット、サポート、データエクスポートの詳細に依存する。
クラウドのラベルはハードウェア事業を隠している
Green Cloud Technologies,LLC は、ホステッドキャパシティをブランドからではなく、ラックから外側に向かって読むべき理由を示す一例である。同社はパートナを通じてクラウドインフラを販売していた。顧客が見るのは仮想マシン、デスクトップ、バックアップリポジトリ、復旧ターゲット、マネージドセキュリティラッパーだった。その下にある運用上の義務はより具体的だった：建物、電力、冷却、ラック、ハイパーバイザ、ストレージシェルフ、ルータ、クロスコネクト、トランジット契約、監視システム、技術者。
公開されたアイデンティティの痕跡は番号リソースから始まる。AS54155 の ARIN RDAP レコードは GREENCLOUD を指名し、登録者として Green Cloud Technologies,LLC を挙げている。RIPEstat の AS 概要はホルダーラベル「GREENCLOUD - Green Cloud Technologies,LLC」を使用し、2026年7月時点のビューで AS がアナウンスされているとマークしている。これは、ウェブサイトが古くても、法人名に結びついた稼働中のインターネット制御プレーンが存在することを示すため、古くなったウェブサイトよりも強力な証拠である。
これだけでは復旧力を購入するには十分ではない。自律システム番号は、グローバルルーティングにどのオリジンが現れるかを示す。それは、顧客のワークロードがどの建物でホストされているか、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 の現在の証拠は稼働中だが単純ではない
最も有用な経路スナップショットは企業のスローガンではなく、公開ルーティング状態である。AS54155 の RIPEstat ルーティングステータスは、ここで使用した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 のみの監視、デュアルスタックフェイルオーバー、または公共機関調達要件に依存する顧客は、現代的なクラウドプロバイダがそれを持っているという一般的な主張ではなく、現在の製品証拠を必要とする。
アドレスレコードは、クリーンな単一企業ストーリーがなぜ誤解を招くかを示している。162.218.104.0 の ARIN RDAP レコードは Green Cloud ブロックを指している。198.71.76.0 の ARIN 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 のキャパシティが継承された資産としてレビューされるべき理由を説明する。買収されたプラットフォームはしばしば、別々のストレージ設計、別々のハイパーバイザバージョン、別々のプロバイダ契約、別々の顧客義務、別々のメンテナンス伝統をもたらす。統合はサービスを改善しうるが、障害時にのみ現れる隠れた継ぎ目を残すこともある。
これが、「強」の評価からの第一の格下げである。Green Cloud はインターネット上で可視である。純粋なペーパーカンパニーではない。しかし、現在の経路表は複合的な地図であり、公開された証拠からは、外部の読み手が各顧客ワークロードを支えている都市、ラック、サプライヤ、またはクラウドクラスタを正確に特定できない。
6都市リストは有用だが、配置保証ではない
2021年の買収発表は Green Cloud にとって最も明確な公共の都市リストである。11:11 は Green Cloud のデータセンターをアトランタ、グリーンビル、ヒューストン、ミネアポリス、ナッシュビル、フェニックスに挙げた。BusinessWire の買収発表や、Tiger Infrastructure のポートフォリオ企業である 11:11 Systems による Green Cloud 買収に関する PRNewswire のリリースは、Green Cloud が、より大規模な接続性、クラウド、セキュリティプラットフォームに統合されつつあったという、同じ戦略的ストーリーを補強している。
都市リストは、分析を漠然とした「米国クラウド」ラベルから物理的な市場のセットへと進めるため貴重である。アトランタは主要な南東部接続ハブである。グリーンビルはサウスカロライナの本社と地域運用コンテキストを提供する。ヒューストン、ミネアポリス、ナッシュビル、フェニックスは、電力、暴風雨、人員配置、通信事業者密度、顧客レイテンシに関して実質的に異なるリスクゾーンである。これら 6 市場すべてに拠点を持つ単一のプロバイダは、有用な配置選択肢を提供するかもしれないが、それら全体で不均一な深さを持つかもしれない。
このリストは、個々のアカウントに対する配置保証ではない。MSP 顧客の仮想サーバはある都市にありながら、バックアップは別の都市にあるかもしれない。災害復旧ターゲットは予約されているが規模が不足しているかもしれない。デスクトップ・アズ・ア・サービス・プールは、データ主権の選好ではなくサポート慣行に従って配置されているかもしれない。セキュリティサービスは、ログやチケットをコンピュートサービスとは異なるプラットフォームに保存するかもしれない。現在の見積もり、サービススケジュール、またはアーキテクチャ展示なしでは、古い都市リストは検証すべき地理として扱われるべきであり、信頼すべき約束としてではない。
11:11 の現在のフットプリントは文脈を広げる。そのクラウドリージョンページは、同社が世界中で 25 以上の施設を運営し、データセキュリティ、安定性、主権がクラウド姿勢の中心であると述べている。このページはまた、アトランタ、シカゴ、ダラス、ロサンゼルス、ニューヨーク市、サンノゼ、スコッツデール、トロントなどの主要都市や、バージニア州、ニュージャージー州などの州にも北米データセンターがあることを挙げている。これは、歴史的な Green Cloud の地図よりも大きな親会社のフットプリントを示している。
データ主権にとって、より大規模であることは自動的により良いことではない。より広範なプラットフォームは、より多くの復旧オプションとより多くのローカル配置選択肢を提供しうるが、どのレガシー Green Cloud のコミットメントがどの現在の 11:11 リージョンにまだマッピングされているかを曖昧にすることもある。顧客は正確な配置マトリックスを求めるべきである：本番コンピュート、複製ストレージ、バックアップ、スナップショット、管理プレーンのログ、チケッティングレコード、セキュリティテレメトリ、および国境を越えるサポートアクセス。関連する国は、企業の米国登録地だけではなく、顧客データ、メタデータ、および運用アクセスが存在しうるあらゆる場所である。
サービスの組み合わせは単なるネットワークではなくキャパシティ販売者を示す
Green Cloud の古い公開説明と 11:11 の現在の製品ページは、単純な接続性ではなくホステッドキャパシティを指し示している。2021年の買収資料は Green Cloud を、バックアップ、災害復旧、デスクトップ・アズ・ア・サービス、マネージドセキュリティサービスを備えた IaaS プロバイダと説明した。11:11 のクラウド概要は現在、VMware ベースのパブリックおよびプライベートクラウドホスティング、移行サポート、セキュリティ、コンプライアンス、バックアップを説明している。11:11 Hosted Private Cloudは、シングルテナントプライベートクラウド、移行サポート、事前構築済みおよびカスタマイズ構成、専用サーバ、ストレージ選択肢、N+1 復旧力モデルを強調している。11:11 Flexible Cloud Environment and Colocationは、その表現をベアメタル、コロケーション、低レイテンシネットワーキング、監視、24時間サポートに拡張している。
これは物理的な資産のストーリーである。プライベートクラウドには、コミット済みブロックを満たすのに十分な専用サーバ在庫が必要である。ベアメタルサービスには、実際のハードウェア予備品、ファームウェア規律、マシンに手が届くサポートスタッフが必要である。VMware サービスには、ライセンス、ハイパーバイザライフサイクル管理、ストレージ互換性、移行ツールが必要である。コロケーション拡張には、施設、ケージまたはラック、クロスコネクト注文、リモートハンド、電力容量が必要である。顧客は抽象化を購入し、プロバイダはハードウェアと契約の事業を運営する。
11:11 プライベートクラウドページの N+1 表現は有用だが完全ではない。N+1 は、クラスタ内の追加コンポーネント、追加電源ユニット、追加ホスト、追加アレイコントローラ、またはより広範な設計思想を意味し得る。必ずしも、デュアルサイトフェイルオーバー、あらゆる障害下での完全なライブマイグレーション、または都市全体の停電を吸収する能力を意味するわけではない。顧客は、どの層が N+1 保護を持つべきか尋ねるべきである：コンピュートホスト、ストレージコントローラ、集約スイッチ、エッジルータ、電力フィード、冷却、バックアップリポジトリ、サポート人員。正しい答えはワークロードによって異なる。小規模なウェブサービスには自動再起動と十分な帯域幅が必要かもしれない。規制対象のデータベースには、同期または慎重に管理されたレプリケーション、監査証跡、保持保証、文書化された退出手順が必要かもしれない。
この区別が重要なのは、Green Cloud の歴史的なチャネルモデルが、キャパシティを実際よりも弾力的に感じさせる可能性があるためである。パートナはサービスを迅速に販売できる。インフラ事業者は、実際に所有するものだけを展開、予約、修理できる。ハードウェア在庫、ラック電力、またはトランジットヘッドルームが不足した場合、障害はマーケティング上の失敗としては見えない。それは、プロビジョニングの遅さ、アップグレードの遅延、復旧ウィンドウの制約、メンテナンス延期、またはプラットフォームチームを必要とするサポートチケットとして現れる。
SLA は顧客がどこで露出しているかを示す
Green Cloud にとって最も有用な公開文書の一つは、古いGreen Cloud Technologies サービスレベル契約とメンテナンスポリシー PDFである。それは日付が古く、確認なしに現在の契約として扱うべきではないが、それでも Green Cloud が障害境界をどのように枠付けていたかに関する実用的な窓である。この文書は、Green Cloud 所有のインフラ周りのサービス可用性、計画メンテナンス、災害復旧ティア、サポート優先度について記述している。また、顧客側のネットワークやより広範なインターネット依存関係など、プロバイダの制御外の部分を除外している。
その構造はホステッドプロバイダにとって標準的であり、まさに顧客が境界を注意深く読むべき理由である。サービスが Green Cloud のエッジ内で到達可能であるが、顧客の ISP パスが破損している場合、クラウドは利用可能と見なされるかもしれないが、顧客はダウンしている。仮想環境が稼働しているが特定のアプリケーションが誤設定されている場合、インフラプロバイダはアプリケーションの停止を所有しないかもしれない。メンテナンスウィンドウがスケジュールされている場合、影響を受けるサービスは、計画外の障害と同じ救済措置を生み出すことなく利用不可になるかもしれない。実際的な問題は、SLA が高い可用性パーセンテージを使っているかどうかではない。どの障害がカウントされ、どれがカウントされず、その中間で誰が運用上の痛みを負うかである。
同じ文書のサポートモデルは、労働人員がキャパシティの一部であることを思い出させる。優先度 1 の問題が最も早い対応を受け、より低い重要度の問題は待つことができる。標準時間外の緊急サポートは深刻なインシデントに焦点を当てる。メンテナンスはサービスの通常の一部として扱われる。言い換えれば、サポートは無尽蔵のエンジニアプールではない。それは重要度、スケジュール、権限によって配給される。それは合理的だが、顧客自身の事業がプレッシャー下にある場合でも、復旧、移行、またはクロスコネクト変更が最高優先度を下回る場合に顧客リスクとなる。
11:11 の現在のサポートページは、より大きなスケールでサポート境界のテーマを継続している。それはグローバルサポート番号、アカウントおよびコンソールリンク、そしてクラウドサービス、セキュリティサービス、接続サービス、請求に関する別々の連絡先をリストしている。この分離は運用上有用だが、顧客は障害所有権を事前にマッピングするようにとも伝えている。Green Cloud を起源とするワークロードは、コンピュート、セキュリティ、接続性、請求、またはアクセス管理を通じて失敗しうる。各経路は異なるキューとエスカレーション慣行を持つかもしれない。
クラウド障害は技術的なものだけではないため、請求経路は注目に値する。アカウント停止、契約紛争、ライセンス不一致、プリペイド残高の枯渇、または支払い方法の失敗は、エンドユーザにとってはインフラ問題に見えるダウンタイムイベントを生み出しうる。チャネルパートナを持つプロバイダは別の層を追加する：エンドカスタマは MSP に支払い、MSP はアップストリームプラットフォームに支払う可能性があり、いずれかの層での紛争がサービス継続性に影響しうる。したがって、復旧力レビューには、請求エスカレーションとアカウント管理規則が含まれるべきであり、バックアップやルーティング図だけではない。
トランジット多様性は示唆されているが証明されていない
RIPEstat のAS54155 の ASN ネイバービューは、ここで使用した2026年7月のデータで 6 つのネイバーを観測した。ASN は大規模またはインフラ関連の名前に解決される：Cogent、Level 3、Zayo、Hurricane Electric、Megaport、Unitas。これは、公開経路ビューで孤立した1つのアップストリームを見るよりも良い。
しかし、BGP 隣接性と物理的多様性は別物である。経路コレクタは、それらのネイバが完全なトランジットか、部分ピアか、エクスチェンジ経路か、プライベート相互接続か、継承セッションかを購入者に伝えることなく、ネイバを見ることができる。見かけ上異なる2つのアップストリームが、同じミートミールームを通じて、あるいは同じメトロファイバ切断にさえ依存して同じ建物に入るかもしれない。Megaport セッションはソフトウェア定義相互接続にとって価値があるが、それでも基礎となるアクセスパス、ポート、プラットフォーム、リモートエンドポイントに依存する。プロバイダは複数の論理パスを持ちながら、1つの施設停止、1つのクロスコネクトバックログ、または1つの変更管理エラーに対して脆弱でありうる。
PeeringDB は通常、施設、エクスチェンジ、ピアリングポリシー、トラフィックヒントをリストするため、そのギャップの一部を埋めるのに役立つだろう。Green Cloud の場合、AS54155 の PeeringDB API ルックアップはネットワークプロファイルを返さなかった。PeeringDB に不在であること自体は失敗ではない。多くの正当なプロバイダはプロファイルを最新に保っていない。それでも、相互接続サイト、トラフィックポリシー、施設アタッチメントを明確にできたかもしれない、事業者が維持する情報源を取り除くことになる。これが証拠グレードが「強」を下回るもう一つの理由である。
経路オリジンセキュリティも公開チェックから同様に不完全である。AS54155 と 162.218.104.0/22 の RIPEstat RPKI バリデーションクエリのサンプルは、そのレスポンスに検証用 ROA が現れなかったため、未知のステータスを返した。別の現在のプレフィックスに対する2つ目のクエリも同種の未知の結果を返した。RPKI ステータスが未知であることは、誤った経路であることを証明せず、経路が使用不能であることを意味しない。これは、厳格な経路オリジンバリデーションに依存する顧客が、実際にサービスを運ぶプレフィックスに対して ROA が存在するかどうか、もし存在しなければ、事業者の経路セキュリティ計画は何かを尋ねるべきであることを意味する。
AS54155 の BGP.tools、Hurricane Electric の BGP ツールキット、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 の公開されたテクノロジー参照は、実際のホステッドキャパシティプラットフォームの描写を裏付けている。Cisco UCS S-Series を使用して新規事業を立ち上げる Green Cloud に関する Cisco データセンターブログは、新規事業を支えるために Cisco サーバインフラストラクチャを使用していることを説明した。Green Cloud Defense の VMware Cloud Provider ブログプロファイルは、同社を VMware のクラウドプロバイダエコシステム内に位置づけた。11:11 のクラウド概要は現在、その VMware ベースの枠組みを継続している。
これらの参照が重要なのは、議論を純粋に仮想的な言葉から遠ざけるためである。VMware クラウドは、ホスト、クラスタ、データストア、管理サーバ、ライセンス契約、パッチサイクル上で実行される。Cisco UCS 環境には、ファブリックインターコネクト、サーバプロファイル、ファームウェア依存関係、ストレージ選択肢がある。Fortinet とマネージドセキュリティサービスには、センサ、ログ取込みパス、アナリスト、エスカレーションルールがある。各層は、適切に管理されればサービスを強化できる。各層はまた、独自のメンテナンスウィンドウや運用上の単一障害点を導入しうる。
公開されたテクノロジーパートナーへの言及はキャパシティ監査ではない。それらは、何台のサーバが設置されているか、何台が予約済みか、特定の顧客に対してストレージがオールフラッシュかハイブリッドか、各都市で障害が発生したホストをどれだけ早く交換できるかは示さない。しかし、それらは買い手に何を尋ねるべきかを伝える。顧客は、自分のワークロードが VMware Cloud Foundation、vCloud Director、レガシー VMware スタック、専用ベアメタル、またはコロケーションプラットフォームのいずれに置かれているかを尋ねるべきである。バックアップが本番と同じストレージファミリ上にあるかどうかを尋ねるべきである。管理アクセスが別の制御ネットワークに依存しているかどうかを尋ねるべきである。特に VMware エコシステムにおいて、ライセンス変更が価格や移行タイミングをどのように変更しうるかを尋ねるべきである。
同じことがセキュリティにも当てはまる。マネージドファイアウォール、SIEM、エンドポイントサービスは、人員配置され統合されていればリスクを低減できる。それはまた、セキュリティプラットフォーム自身の可用性に依存関係を作り出すこともある。セキュリティ管理プレーンが故障した場合、顧客は依然としてファイアウォールルールを変更できるだろうか？SIEM 取り込みパスが遅延した場合、誰が気づくのか？サービスが MSP を通じて再販される場合、誰がアラートを受信し、誰が封じ込めを承認する権限を持つのか？
チャネル顧客は階層化された説明責任を継承する
Green Cloud のチャネル専業指向は脚注ではない。11:11 の買収発表は、2,000 以上の企業にサービスを提供する 700 以上の MSP、VAR、IT コンサルタントからなる全国チャネルパートナーネットワークを説明した。これは、影響を受ける多くのエンドユーザが 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 条件に対して確認されるべきだが、運用上の現実はどのプロバイダにも当てはまる。
実際的な質問は、メンテナンスが顧客の復旧とどのように相互作用するかである。本番とバックアップが同じウィンドウでメンテナンスされる場合、失敗した変更は両方に影響しうる。メンテナンス中にストレージレプリケーションが一時停止される場合、復旧ポイント目標が延びるかもしれない。ネットワーク変更がプライマリとセカンダリの両方のパスに触れる場合、隠れた共通の依存関係が現れうる。メンテナンスイベントが影響を受けるポータルを通じて伝達される場合、顧客はサービスとステータス可視性の両方を失うかもしれない。
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、バックアップ、災害復旧、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、バックアップ、災害復旧、DaaS、セキュリティを大規模チャネルネットワークを通じて販売した企業を示している。
格下げも同様に重要である。Green Cloud 固有の都市とサービス証拠のほとんどは歴史的なものである。現在の公開経路表は、Green Cloud 直接、買収、割り当てアドレスレコードが混在している。PeeringDB は相互接続プロファイルを提供していない。サンプル RPKI チェックは未知である。サポートとメンテナンスモデルは、修復ウィンドウ、重要度キュー、除外される依存関係が重要であることを明らかにしている。公開記録は、アドバタイズされたまたは継承されたすべての拠点が同等の予備キャパシティ、同等のトランジット多様性、または同等の復旧深度を持つことを証明していない。
読者にとって、有用な結論は実用的である。Green Cloud を単純なクラウドロゴとしてではなく、11:11 軌道上の稼働中のインフラ依存関係として扱うこと。重要なワークロードを載せる前に、サイト配置、経路多様性、復旧キャパシティ、サポート権限、メンテナンス慣行、データポータビリティに関する現在の証拠を要求すること。サービスの価値は、仮想マシンやバックアップリポジトリだけにあるのではない。それは、容易なパスが失われたときに依然として機能しなければならないラック、経路、人々、契約にある。