サマリー
- レッドクラウドは、現在可視化されている実在のネットワーク ID を有している。APNIC は2024年11月に AS153394 を登録し、RIPEstat は2024年11月から現在の観測期間にわたり、同社が唯一アナウンスしているプレフィックス160.191.191.0/24を観測した。2026年7月12日のルーティングステータススナップショットでは、計325の全 IPv4 RIS ピアに対して当該経路が可視状態にあり、有効な経路起点認証（ROA）が存在していた。
- 可視化されたエッジは集中している。公開ルーティングビューでは、Afghan Telecom の Government Communications Network である AS55330 が、唯一観測された隣接ネットワークまたはアップストリームとして特定されている。AS153394 については PeeringDB のネットワークエントリーは返されず、IPv6 アドレス空間のアナウンスはなく、公開されたインターネットエクスチェンジやファシリティでのプレゼンスも確認されなかった。
- レッドクラウドのビジネスソリューションページでは、IaaS、仮想マシン、ストレージ、ネットワークのほか、複数のアベイラビリティゾーン、冗長化システム、オフサイトバックアップ、ディザスタリカバリをうたっている。しかし、ゾーン名、データセンター、ファシリティオペレーター、電源設計、サーバー資産、ストレージアーキテクチャ、サービスレベル、目標復旧時間、テスト済みフェイルオーバー結果のいずれも示していない。したがって、これらの主張は検証すべき提案と見なすべきであり、確立されたケイパビリティではない。
- 同社はクラウド事業者としてよりも、カブールにおけるインターネットアクセスおよびネットワークサービス提供事業者としての検証が容易である。同社の Web サイトでは、光ファイバー、ポイント・ツー・ポイントおよびポイント・ツー・マルチポイント無線、マイクロ波、WLAN、衛星、専用線、IP-VPN サービスをマーケティングしている。このアクセス基盤はクラウド顧客を支える可能性はあるものの、鉄塔、屋上、見通し、ラストマイル光ファイバー、アップストリームトランジット、電源、フィールドサポートへの物理的な依存関係も生み出している。
- 公開証拠グレードは弱い。レッドクラウドは、名前だけの企業よりは強力な運用証拠を有しているが、顧客データの所在地、独立した本番サイトが2つ存在するかどうか、障害時にどの程度の容量が生き残るか、サービスまたは契約関係が終了した場合に顧客がどのようにワークロードを取り戻せるかという点を、証拠は確立していない。
小規模で実在するネットワークに付随するクラウドの約束
レッドクラウドについて最も重要なことは、同社の Web サイトがクラウドコンピューティングの用語を使っていることではない。多くの IT コンサルティング企業がそうしている。重要なのは、同社が可視化されたインターネットルーティング ID を管理していることである。APNIC の自律システムレコードでは、AS153394 の保持者として RED CLOUD INFORMATION TECHNOLOGY SERVICES COMPANY を挙げ、国をアフガニスタンとし、リソースをアクティブとマークし、登録日を2024年11月5日と記録している。RIPEstat の現在の概要では、当該 ASN はアナウンスされていると示されている。これらは具体的な運用シグナルである。
それらは同時に限定的なシグナルでもある。自律システムはルーティング境界であり、クラウドリージョンではない。顧客アクセスアドレス、インフラアドレス、ホステッドサービス、オフィストラフィック、あるいはそれらの混合を起点にできる。IPinfo のプロファイルでは、このネットワークを ISP と分類し、コンシューマー向けのような日々のアクティビティパターンを観測している。また、1つのアップストリーム、ダウンストリームネットワークなし、現在のスキャンではホストされているドメインはないとレポートしている。この解釈は、レッドクラウドのアクセスプロバイダーのページとより自然に整合するが、サードパーティの分類では、プライベートまたはプロバイダーがアドレス指定するすべてのワークロードを明らかにできない。
レッドクラウドの自社サイトでは、ビジネスの両面が見えるようになっている。ホームページでは、アフガニスタン全域へのインターネットアクセス、企業向け接続、カブールにおける回復力のある無線・光ファイバーネットワークを宣伝している。ビジネスソリューションページでは、接続性、クラウド、オンプレミスシステム、マイクロソフトサービスへとスタックを上がっている。クラウドの下では、仮想マシン、ストレージ、ネットワーク、バックアップ、ディザスタリカバリ、プライベートおよびハイブリッド展開、移行をうたっている。
この組み合わせはもっともらしい。地元の接続プロバイダーがマネージドサーバーを追加したり、インフラを再販したりすることは可能であり、IT コントラクターがリースラックや別のプロバイダーのプラットフォーム上にクラウドサービスを構築することもできる。しかし、この組み合わせにより、所有権の境界が極めて重要になる。公開ページでは、レッドクラウドがサーバーを所有しているのか、キャビネットを借りているのか、別のクラウドを再販しているのか、顧客所有の機器を管理しているのか、あるいはこれらのモデルを組み合わせているのかは示されていない。その境界が開示されるまでは、顧客はレッドクラウドが修理を管理しているのか、単にそれを管理する当事者にチケットを発行しているのかを知ることができない。
したがって、正しい出発点は信頼でも却下でもない。それは分かれた所見である。ネットワークエッジは観測可能だが、ホストされた資産は観測できない。AS153394 はレッドクラウドが公開ルーティングに参加していることを証明するが、宣伝されているアベイラビリティゾーンに独立したコンピュートおよびストレージ容量が含まれていることや、ワークロードがそのうちの1つの損失を乗り越えられることは証明しない。
ルートテーブルが証明できること
レッドクラウドの公開アドレスフットプリントは、正確に説明できるほどコンパクトである。RIPEstat のルーティングステータスビューでは、2026年7月12日時点で、256アドレスを含むアナウンスされた IPv4 プレフィックスが1つあり、アナウンスされた IPv6 空間はなかった。そのプレフィックスは160.191.191.0/24である。APNIC のより広範なアドレス登録は160.191.190.0/23（512アドレスブロック）をカバーしているが、グローバルに可視化されている経路は、より限定的な上位/24である。公開ルーティングデータでは、下位/24が別の現在のアナウンスとして示されていなかった。
この区別は重要である。登録された空間はルーティングされた空間と同じではなく、ルーティングされた空間はサービス容量と同じではない。割り振りは、使用されずに放置されたり、将来の展開のために予約されたり、別のアレンジメントを通じて到達可能であったり、一部だけがオリジネートされている間に保持されたりする可能性がある。逆に、256の可視アドレスは、多くの変換されたアクセスユーザーや多くの仮想サービスをサポートできる。アドレス数だけでは、サーバー数、ストレージ容量、顧客数、収益は明らかにできない。
この経路は単なるレジストリエントリではない。RIPEstat は、2024年11月13日に初めて観測され、現在の2026年7月12日の観測で最後に観測されたと記録している。そのルーティング履歴シリーズには、最初の観測以降、コレクターの可視性は変化するものの、連続したアナウンス区間が含まれている。現在の時点では、325の IPv4 RIS ピアのうち325すべてがこの経路を観測した。BGP.toolsも同様に、AS153394 を、1つのアップストリームと1つのピアを持つアクティブな小規模ネットワークと説明しており、そのプレフィックスページでは、レッドクラウドを起点として特定している。
この経路は有用な起点保護も備えている。RIPEstat の検証結果は、AS153394 と160.191.191.0/24のペアを有効とマークした。実用的に言えば、経路起点検証を実施しているネットワークは、このプレフィックスの意図された起点としてレッドクラウドを受け入れる暗号的な認証を持つ。これにより、偶発的または悪意のある経路起点リスクの1カテゴリが低減される。
ただし、配送は保証されない。有効な経路は、過負荷のリンク、故障したルーター、電源が落ちたサーバー、または到達不能な顧客無線機につながる可能性がある。また、すべての顧客サービスがこの範囲を使用していることを証明するものでもない。経路起点認証は、誰がアドレスブロックをアナウンスしてよいかを問うものである。データがどこにあるか、トラフィックがどのようにラックに到達するか、ディスクがどれだけ迅速に交換されるか、第2のサイトが引き継げるかどうかは問わない。
肯定的な結論は、明確に述べる価値がある。レッドクラウドの公開ネットワークは約20か月間可視化されており、単にアナウンスされていない ASN というわけではない。否定的な結論も同様に重要である。ルーティングされた1つの/24は小さな観測面であり、特定のクラウド製品をその内部の特定のアドレスに結び付ける公開データは存在しない。
1つの観測された隣接ネットワークが外部経路を集中させる
最も鋭い公開レジリエンスシグナルは、隣接ネットワーク数である。RIPEstat の ASN 隣接ネットワーク結果は、1つのユニークな隣接ネットワーク AS55330 を示した。IPgeolocation の ASN ビュー、IPIP のレジストリミラー、および IPinfo は、独立して同じネットワークをレッドクラウドのアップストリームとして特定している。AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK である。公開されているダウンストリームネットワークはリストされていなかった。
観測された隣接ネットワークは、完全な契約目録ではない。レッドクラウドは、ルートコレクターが観測しないプライベートバックアップ、障害時にのみ使用される衛星パス、またはプロバイダーアドレス空間下で購入されたアクセスを持つ可能性がある。また、AS153394 の下で公開することなく、ローカルな交換アレンジメントに参加することもあり得る。公開ルーティングはアクティブな経路を観測するものであり、署名されたすべての契約を見ているわけではない。
そのような注意点を踏まえても、可視化されたトポロジーは集中している。もし AS55330 が160.191.191.0/24の運搬を停止した場合、公開記録上、同じレッドクラウド経路が伝播し続けるための第2の自律システムパスは存在しない。同じアップストリームからの第2の回線は、1つのケーブルまたはポート障害から保護できるが、アップストリームのルーティングポリシー、アカウント状態、メンテナンス判断、またはコアネットワークへの依存を取り除くわけではない。衛星バックアップは、プライマリパスが故障する前にプロビジョニングされ、電力供給され、ルーティングされ、適切にサイジングされている場合にのみ、限定的な運用を維持できる。
アップストリーム自体は些細なネットワークではない。IPinfo の AS55330 プロファイルは多数の外部ピアとダウンストリームネットワークをリストしており、APNIC のアフガニスタン国内交換に関する記事では、Afghan Telecom が交換のメンバーであったと述べている。これにより、AS55330 は複数の方向へアクセスできる可能性がある。とはいえ、Afghan Telecom 内部のアップストリーム多様性は、レッドクラウドにとってのサプライヤー多様性とは異なる。レッドクラウドの顧客は、依然としてレッドクラウドの AS55330 への接続と、両者間の商業的・運用的チェーンに依存している。
PeeringDB ネットワーク APIにはレッドクラウドのエントリーはない。これはレッドクラウドがピアリングやファシリティプレゼンスを欠いていることの証明ではない。PeeringDB は任意の自己メンテナンスによるものである。しかし、AS153394 について、交換、ファシリティ、相互接続ポリシー、トラフィックレベル、または連絡先を名指しした公共のプロバイダー提供プロファイルが存在しないことを意味する。Internet Society の2026年5月の NIXA ビューでは、16のメンバーASN がリストされており、レッドクラウドはその中に含まれていなかった。
購入者にとって、欠落している証拠は、冗長性という漠然とした約束を精密な質問に変える。デフォルト対応可能な第2のアップストリームは存在するか？ それは別のダクトまたは屋上経路を通って入るか？ 別のボーダールーターと電源供給か？ クリティカルな全負荷を運搬できるか？ フェイルオーバーは自動で、最後に実施されたのはいつか？ 答えが衛星回線である場合、競合下で残るスループットとレイテンシは？ 答えが第2の Afghan Telecom 回線である場合、どのような共通故障が残るか？
同社はコンピュートよりもアクセスについて公開面で明確である
レッドクラウドのアクセスページは、認識可能な物理的ビジネスを説明している。ポイント・ツー・ポイント無線ページでは、サイト調査、見通し分析、設計、設置、監視、サポートを提供している。リンクは、地形と見通しに応じて1 Gbps 以上、100 km 以上に達する可能性があると述べている。ポイント・ツー・マルチポイントページでは、中央基地局が複数のエンドポイントにサービスし、エンドポイントあたり最大500 Mbps、半径30 km 以上という主張を説明している。マイクロ波ページでは、屋上または鉄塔アンテナと、最大50 km 以上の距離のリンクを説明している。
これらの数値はベンダーの主張であり、ページ自体でも地形、見通し、設計によって留保が付いている。設置されたリンクの目録として読むべきではない。それらが確立しているのは、レッドクラウドが提供する作業の種類である。調査、無線機、アンテナ、鉄塔または屋上、顧客エンドポイント、フィールドメンテナンスである。ホームページでは、光ファイバー、衛星、WLAN、およびカブール、サマンガン、バルフ、カンダハル、ファーリヤーブ、ジョウズジャーンでの支店またはサービス拠点が追加されている。また、同社のカブールにおける無線および光ファイバーネットワークにレジリエンスが適用されるとも述べている。
このサービスの混合は、クラウド分析を変化させる。レッドクラウドの顧客は、仮想マシンだけを購入しているわけではないかもしれない。そのマシンに到達するためのアクセス回線、その前にあるマネージドファイアウォール、スタッフが使用するマイクロソフトアカウント、そして3つすべてを担当するサポートチームを購入する可能性がある。垂直統合は、同じプロバイダーが本当にレイヤーを管理している場合に説明責任を簡素化できる。しかし、レイヤーが1つのアップストリーム、オフィス、サポート名簿、請求システムを共有している場合、影響範囲を拡大する可能性もある。
無線アクセスには、クラウドの営業ページでは示されない故障モードがある。ポイント・ツー・ポイントリンクは、両方のエンドポイント、設置の安定性、妨げのない見通し、正確なアライメント、クリーンなスペクトラム、気象耐性、電源、および遠方無線機から広域ネットワークへのパスに依存する。ポイント・ツー・マルチポイント基地局は、複数の顧客を1つのサイトと共有無線容量に集中させる。マイクロ波バックホールはトレンチを回避できるが、依然として鉄塔アクセスと交換機器に依存する。光ファイバーは無線干渉を回避するが、切断されたり、経路変更されたり、共通の集約障害によって無効化される可能性がある。
衛星は地上ファイバーからの地理的独立性を提供し得るが、異なるサプライヤー、端末、電源、容量モデルを導入する。それは自動的に地上ビジネス回線のシームレスな代替にはならない。レッドクラウドのビジネスページでは、プール型および容量制限型の VSAT、およびポイント・ツー・ポイント衛星サービスについて説明しており、容量の問題が明確になる。共有または容量制限のあるバックアップは、メッセージングと制御トラフィックを維持できるが、通常の顧客需要を運搬できない可能性がある。
したがって、公開資料は物理的な作業が可視化されている部分で最も強く、抽象的な容量が始まるところで最も弱い。レッドクラウドは、無線リンクとは何か、設置に何が含まれるかを説明するが、自社のクラウドについての対応する物理的な説明（サイト名、ラック配置、ホスト数、ストレージレプリケーション設計、容量プール、障害ドメインマップ）を提供していない。
「複数のアベイラビリティゾーン」には独立した障害のマップが必要
レッドクラウドのビジネスソリューションページでは、同社の IaaS プラットフォームにより企業が仮想マシン、ストレージ、ネットワークを展開でき、複数のアベイラビリティゾーンと冗長化システムがクリティカルなアプリケーションの可用性を提供すると述べている。これらは重大な主張である。アベイラビリティゾーンは、顧客が何が独立して故障し得るかを理解できる場合にのみ有用である。
1つの建物内の2つの部屋は、ラックレベルのイベントから保護できるが、共有されたユーティリティ電源、発電機、冷却、セキュリティアクセス、キャリア引込口を共有する可能性がある。カブール内の2つの建物は、地元の火災を回避できるが、1つのアップストリーム、1つの市内ファイバーコリドー、または1つの制御システムを共有する可能性がある。1つのサーバールーム内の2つの論理クラスターは、ソフトウェアメンテナンスを分離できるが、同じ電源および物理アクセスイベントにさらされ続ける。別のプロバイダーのリージョンに保持されたリモートバックアップは、ライブコンピュートのフェイルオーバーを提供することなく、データ保護を改善できる。
公開サイトでは、どの解釈が適用されるかは示されていない。Afghanistan National Data Centre のプレゼンス、別のカブール施設、地方サイト、または外国のクラウドリージョンを名指ししていない。ゾーンがアクティブ-アクティブか、アクティブ-スタンバイか、バックアップのみか、あるいは単にサードパーティを通じて利用可能なオプションかを述べていない。いかなるファシリティのオペレーターも特定していない。レッドクラウドの公開ページと相互接続記録の検索では、会社の Taimani 連絡先住所を超えて、宣伝されているクラウドに関連付けられたファシリティ住所は見つからなかった。
連絡先の詳細自体にもばらつきがある。APNIC の組織レコードでは、Taimani Project Street #3, House No. 19と1つの電話番号を示している。Web サイトでは、22 Prozhae Taimani 3rd Street A と2つの異なる番号を示している。TechBehemothsは、Taimani Project Street 3, House 19をリストしている。これらは、同じ運営オフィスを異なる形式で説明している可能性があるが、いずれもデータセンターとしてラベル付けされてはいない。オフィス住所を想定によってラックの場所に変換すべきではない。
必要な証拠は単純明快で商業的に通常のことである。レッドクラウドは、各本番およびリカバリサイトの国と都市を特定し、自社所有の機器とリースまたは再販された容量を区別し、どのファシリティオペレーターが電源と物理アクセスを管理しているかを明示し、どの依存関係が共有されているかを説明することができる。顧客仮想ディスクが同期的にレプリケートされるか、非同期的にコピーされるか、スケジュールされたバックアップによってのみ保護されるかを開示できる。各ゾーンが生き残るように設計された障害を提供できる。
これらの事実がなければ、「複数のアベイラビリティゾーン」は製品意図の表明にとどまる。顧客が1つのサイトを失っても運用を継続できるという証拠にはまだならない。この省略は、可視化された公開経路がいまだに1つの観測されたアップストリームしか持たないことを考慮すると、特に重要である。単一の外部経路を共有する別々のコンピュートゾーンは、公開到達性を集中させたまま、サーバー障害から保護できるかもしれない。
設置済み容量は使用可能または復旧可能な容量ではない
クラウド経済はプールに依存する。プロバイダーはサーバー、ストレージ、ネットワークポート、電源、サポート容量を購入し、顧客全体に割り当てる。プールにより、ローカルインフラは各顧客のオフィスにあるサーバーよりも安価で、より良く管理できる可能性がある。また、設置済み容量と使用可能容量の違いを見えにくくする可能性もある。
設置済み容量とは、名目上存在する機器と接続性である。使用可能容量とは、通常の制約下で顧客が消費できるものである。生存容量とは、最大の信頼できる障害後に残るものである。復旧可能容量とは、顧客の時間およびデータ損失限度内で復旧できるものである。これら4つの数量が等しいことはまれである。
レッドクラウドは、それらを推定するために必要なインプットのいずれも公開していない。ホスト数、プロセッサ世代、メモリプール、ストレージ媒体、ストレージ冗長性レベル、オーバーサブスクリプションポリシー、予約済みヘッドルーム、公開帯域幅コミットメント、最大顧客割り当てのいずれもない。予備のサーバー、電源ユニット、ディスク、無線機、光モジュールがローカルにどれだけ保持されているかの指標もない。復旧容量の公開メンテナンスカレンダーや受付ポリシーもない。
単一の/24はそのギャップを埋めない。256の IPv4 アドレスは、少数の直接アドレス指定されたサーバー、はるかに大きな変換された顧客基盤、ネットワークアプライアンス、またはアクセス加入者をフロントできる。IPinfo は現在、この範囲でホストされているドメインを報告していないが、ドメインスキャンはコンテンツ配信ネットワーク、プライベート名、VPN、顧客管理 DNS の背後にあるサービスを見逃す。この観測は、当該プレフィックスが明らかな大量の Web ホスティング範囲ではないことを示唆するが、その背後で何が動いているかを確定することはできない。
同社の価格ページは、コンピュート、ストレージ、データ転送、サポートの経済的比較を可能にする形では公開されていない。ホームページでは、インタラクティブな推奨として月額 AFN 1,000で100 Mbps のリテール接続を示しているが、そのインタラクティブな推奨はクラウド価格ではなく、拘束力のあるサービス提案として扱うべきではない。TechBehemoths も同様に、プロジェクト価格は開示されていないと述べている。経済性は契約事項にとどまる。
本格的な容量の議論は、劣化状態に焦点を当てるべきである。1つのホストが故障した場合、予備容量はすでに別のゾーンに存在するのか、それとも機器を調達する必要があるのか？ 1つのストレージノードが再構築中の場合、どのようなパフォーマンスが残るのか？ プライマリアップストリームが故障した場合、代替パスで利用可能な帯域幅は？ 全国的なインシデントが一度に多数の顧客に影響を与える場合、チームは同時に何件のリストアとサポートコールを処理できるか？ 平均使用率はこれらの質問に答えられない。
これが本記事のタイトルの実用的な意味である。ホストされた容量は、顧客がそれを見えなくてもラックに依存する。サービスがローカルコンソールを通じて提示される場合でも、トランジットに依存する。修理ウィンドウに依存する。なぜなら、スペアパーツ、サイトアクセス、熟練労働が、設置済み容量が利用不能であり続ける時間を決定するからである。
電源とファシリティが最初のハード境界を設定する
すべての仮想マシンは最終的に物理的な部屋の中で熱になる。信頼性の高いサービスには、ユーティリティ供給、バックアップ発電またはバッテリー、電力分配、冷却、防火、アクセス制御、監視が必要である。レッドクラウドは、自社のクラウド製品について、これらのシステムのいずれも公開していない。
その不在は、システムが存在しないという主張に変換されるべきではない。小規模プロバイダーは、セキュリティまたは商業上の理由から、正確なサイト情報をしばしば差し控える。購入者は公開のフロアプランを必要としないが、障害ドメインと復旧権限を理解するために十分なプライベートな証拠を必要とする。
最初の質問は、誰が部屋を運営しているかである。レッドクラウドがファシリティを所有している場合、サイトメンテナンス、発電機燃料、スペア、物理アクセスを管理しているはずである。コロケーションをリースしている場合、ファシリティオペレーターが修理シーケンスの少なくとも一部を管理する。別のクラウドを再販している場合、基盤となるプロバイダーがハードウェアを管理し、ネットワーク、バックアップ、アカウント復旧も管理する可能性がある。各モデルは機能し得るが、サービスコミットメントはレッドクラウドが実際に持つ権限と一致しなければならない。
2番目の質問は、電源冗長性がどのようにテストされているかである。サーバー内の2つの電源ユニットは、それらが独立した配電経路に接続されている場合にのみ有用である。UPS は限られた時間を保護し、発電機はそれが起動し、負荷を運び、燃料がある場合にのみより長く保護する。第2のサイトは、故障したユーティリティ、発電機、開閉装置、または運用チームを共有しない場合にのみ、ファシリティ障害から保護する。冷却システムと防火システムは、独自の共通モードを生み出す。
3番目の質問は、物理的な到達可能性である。レッドクラウドの無線サービスは、複数拠点の屋上、鉄塔、顧客構内機器を暗示している。それらのサイトも電源を必要とする。基地局、中継、ファイバー引渡しポイント、または建物の電源供給が故障したために顧客アクセスが消失する一方で、クラウドラックは健全であり続けることができる。アクセスとホストされた容量の両方を購入する顧客は、個別の可用性尺度を求めるべきである。ホストされたワークロード用、アクセス回線用、エンドツーエンドサービス用である。
アフガニスタンのより広範な運用環境は、これを理論以上のものにする。Georgia Tech の Internet Outage Detection and Analysis プロジェクトは、2025年9月29日の全国的混乱中に BGP シグナルとアクティブプロービングが急激に低下したと報告した。Associated Pressは、報告されたファイバー制限の中で、ほぼ完全な全国的な通信混乱について説明した。これらの出来事はレッドクラウドの停止を確立するものではないが、アフガニスタンにおける復旧計画には、壊れたハードウェアだけでなく、政策と全国的なトランスポート障害を含めなければならないことを示している。
ルーティングセキュリティは範囲の狭い強み
レッドクラウドは、有効な経路起点認証の功績を認められるに値する。RPKI の展開は自動ではなく、認可された起点は、意図された経路を無効な経路から区別するのに役立つ。APNIC の記録と RIPEstat は、アナウンスされた/24の現在の有効な状態で一致している。
検証データには微妙な点がある。結果には、最大長/24の160.191.191.0/24に対する有効な認可が含まれている。また、最大長が/23である160.191.190.0/23のカバーする認可も見ており、そのカバーするレコードだけでは、より限定的な/24を認可するには短すぎる。観測された経路を有効にしているのは、専用の/24認可である。これは、アクティブなアナウンスがリソース管理層で考慮されているという肯定的な兆候である。
起点検証は残りの経路を保護しない。AS55330 に予備容量があること、フィルターがすべての経路漏洩を防止すること、顧客プレフィックスが保護されていること、または不正な変更後にルーター構成が復旧可能であることを保証しない。完全な AS パスを認証しない。また、唯一観測されたアップストリームがそれを取り下げた場合に経路を可視化し続けることはできない。
したがって、運用上の質問は、リソースセキュリティの実践がさらに拡張されているかどうかである。レッドクラウドは、最新の IRR ルートオブジェクトとプレフィックスフィルターを維持しているか？ ルートとファイアウォールの変更はレビューされているか？ ルーター構成はデバイスの外部にバックアップされているか？ 管理アクセスは顧客ネットワークから独立しているか？ 中断されたのと同じリンクに頼らずに、失敗した変更をロールバックできるか？
公開記録は、連絡先レイヤーで1つの警告を露呈している。APNIC の現在の RDAP 出力は、インシデント対応レコードにおいて、アドレス[email protected]を無効とマークしている。余分な「e」が、レジストラントレコードや Web サイトで使用されている有効な企業ドメインredcloudict.comと区別している。APNIC はまた、管理および abuse ロールがスペルミスのあるドメインを使用している一方で、レジストラント組織は正しくスペルされたアドレスを使用していることを示している。
これは顧客がサポートに連絡できないことを証明するものではない。レッドクラウドは、サイトで他の電話番号と正しくスペルされた E メールを公開している。これは、レジストリの衛生がレジリエンスに属する理由を示している。ルーティングの不正通報や緊急の調整イベント中、無効なインシデント連絡先は、ネットワークオペレーターに連絡しようとしている Red Cloud 外部の人々を遅らせる可能性がある。修正することは、小さいながらも測定可能な改善となるだろう。
サポート労働力はインフラの一部である
レッドクラウドは、自社のホームページおよびサービスページで年中無休のサポートをうたっている。無線ページには監視とメンテナンスが含まれている。クラウドページには、管理と監視が継続的であり得ると書かれている。これらの約束は、コンパクトなプロバイダーが広範な責任を持つ少数の人員に依存する可能性があるため、重要である。
公開情報は人員問題を解決しない。LinkedIn の企業ページでは、2022年創業の非公開企業と説明し、従業員数11～50人のサイズ帯を示し、公開ビューで1人の従業員を露呈している。TechBehemoths は同様に10～49人の範囲を示し、同社が年間1～5件のプロジェクトを実施するとプロファイルに書いている。これらは自己申告またはディレクトリの数値であり、監査済みの人員数ではない。LinkedIn ページでは、ネットワーク運用またはクラウド運用の名簿は特定されていない。
小規模チームは、サービスが適切に境界設定され、自動化が信頼でき、エスカレーション権限が明確である場合に優れたサポートを提供できる。彼らは、1人のエンジニアが排他的な知識を保持しているとき、複数のインシデントが同時に到着したとき、または修理がサードパーティに依存しているときに脆弱になる。関連する能力は総人員数ではない。それは機能別および時間帯別の有資格カバレッジである。誰が BGP を変更し、無線機を修理し、ストレージを復旧し、ファシリティに入り、緊急購入を承認し、顧客と通信できるかである。
レッドクラウドの連絡面は、テストする価値があるほど断片化されている。APNIC 組織レコード、APNIC インシデントロール、Web サイト、LinkedIn、TechBehemoths のプロファイルは、異なる電話番号または E メールの詳細を公開している。Web サイトの連絡先ページは、可視的に詳細なインシデントチャネルではなく、サブスクリプションフォームを提示している。これらのいずれもサポート障害を証明しない。これは、顧客が24時間対応の主張に頼る前に、実際のエスカレーションパスを検証すべきであることを意味する。
信頼できるサポートスケジュールは、緊急インシデントの対応チャネルを名指しし、受領確認と復旧を区別し、重大度レベルを定義し、電話エスカレーションが利用可能になる時点を明示するだろう。また、ファシリティ、アップストリーム、衛星、ファイバー、ハードウェア障害に関して、どのサプライヤーが関与するかも説明するだろう。本番ネットワークの外部でホストされたステータスページは、顧客が自社サービス内の障害と全社的なイベントを区別することを可能にするが、公開されたレッドクラウドのサービスステータスページは見つからなかった。
修理の時計は、エンジニアがラックに到着したときではなく、監視が障害を検知したときに始まる。検知、分類、権限、移動、建物の入館、スペアの可用性、サプライヤーの応答はすべて時間を消費する。顧客は、必要に応じて機密詳細を削除して、最近のインシデントまたは演習からの測定された例を要求すべきである。サポートの約束は、所有者と経過時間に結び付けられて初めてインフラ証拠となる。
ハードウェア在庫は障害が停止になるかどうかを決定する
クラウドのページは、顧客が物理ハードウェアのコストと複雑さを回避することを約束する。ハードウェアは消えるのではなく、その目録リスクはレッドクラウドまたはレッドクラウドのサプライヤーに移動する。この移転は、ホストされた容量を購入する主な経済的理由の1つであり、サプライヤーの証拠が重要である主な理由の1つである。
プロバイダーは本番機器と修理用ストックを必要とする。サーバーには電源ユニット、ファン、メモリ、ディスク、場合によっては特殊なコントローラーが必要である。ストレージには交換媒体と、障害後に再構築するのに十分な予備パフォーマンスが必要である。ネットワークエッジにはルーター、スイッチ、光モジュール、ケーブルが必要である。無線サービスには無線機、アンテナ、マウント、サージ保護、顧客宅内機器が追加される。衛星サービスには端末とプロバイダー固有の機器が追加される。
レッドクラウドは、ストックポリシーやハードウェア標準を公開していない。故障した部品がカブールの在庫から交換されるのか、別のプロジェクトから借りるのか、国際的に調達されるのか、またはファシリティや機器ベンダーによって処理されるのかは述べていない。コンピュートホストがワークロード移動のために十分に均質であるか、ストレージが同時障害に耐えられるか、ファームウェアと交換部品の互換性が管理されているかどうかも述べていない。
この不確実性は復旧の約束に影響を与える。バックアップコピーは無傷でありながら、それを実行するための予備コンピュートが存在しない可能性がある。仮想マシンは理論上移植可能でありながら、移行先にメモリ、ストレージパフォーマンス、ネットワークアドレスが不足している可能性がある。無線リンクは適切に設計されていながら、正確な交換モデルが入手できない可能性がある。いずれの場合も、顧客のデータは生き残るが、サービスは生き残らない可能性がある。
調達では、普遍的な稼働時間数ではなく、サービスレイヤーごとに証拠をレッドクラウドに要求すべきである。クラウドの場合：ホスト故障耐性、ストレージ故障耐性、予約された復旧ヘッドルーム、交換時間。アクセスの場合：予備の無線機と光在庫、鉄塔または屋上アクセスの手配、代替バックホール。エッジの場合：予備ルーター能力、構成復旧、アップストリームエスカレーション。マネージドオンプレミスシステムの場合：交換ハードウェアが顧客在庫か、レッドクラウド在庫か、障害後に注文されるか。
ここではプロバイダーとの契約境界が特に重要である。レッドクラウドの「クラウド」が別の公開プラットフォーム上に構築されている場合、物理部品のストックは基盤となるプロバイダーの責任かもしれない。その場合、レッドクラウドの義務はアーキテクチャ、サポートエスカレーション、アカウント継続性、顧客コミュニケーションとなる。顧客は誤った証明を要求すべきではなく、正確な責任明細書を要求すべきである。
請求とサプライヤー契約は、設備故障なしにサービスを停止させる可能性がある
インフラ障害は必ずしも機械的ではない。未払いのアップストリーム請求書、失効したドメイン、停止されたリセラーアカウント、枯渇したクォータ、または争われているサポート権利によって、健全な機器が到達不能になる可能性がある。レッドクラウドのサービスの組み合わせは、顧客からレッドクラウドへ、レッドクラウドから Afghan Telecom へ、レッドクラウドから衛星プロバイダーへ、レッドクラウドからファシリティへ、レッドクラウドからソフトウェアベンダーへ、そしておそらくレッドクラウドから基盤となるクラウドオペレーターへと、複数の可能な商業チェーンを生み出す。
公開 Web フットプリントは、そのような分離の一例を示している。同社のサイトは、レッドクラウド自身の160.191.191.0/24ではなく、66.45.255.122に解決される。その Web アドレスの ARIN レコードは、周囲のブロックを米国 InterServer に割り当てている。Verisign のドメインレコードは、ドメインが2023年2月に登録され、2N Business Consulting の下の名前空間に DNS を委任していることを示している。委任では DNSSEC 署名はされていない。公開 Web サイトをアウトソーシングすることは通常であり、AS153394 に障害が発生した場合に通信を利用可能に保つ可能性がある。また、Web サイトの継続性がレッドクラウド自身のネットワーク外部のサプライヤーと更新に依存することも意味する。
同社のクラウド製品は同様の外部依存関係を持つかもしれないが、公開ページではそれらを名指ししていない。レッドクラウドが仮想インフラを再販している場合、顧客はレッドクラウドが取引を停止するかアクセスを失った場合にアカウントを移管できるかどうかを知る必要がある。レッドクラウドがリーススペース内のハードウェアを所有している場合、顧客はコロケーション契約が終了したら何が起こるかを知る必要がある。マイクロソフトライセンスがバンドルされている場合、顧客は ID とサブスクリプションをサービス中断なく移行できるかどうかを知る必要がある。
契約の継続性は、私的な価格の要求ではない。運用上の権利の要求である。請求書が争われている間に現在のデータを入手できるか？ 停止前の猶予期間はあるか？ 終了後にバックアップは保持されるか、どのくらいの期間か？ ドメイン、アドレス、証明書、管理資格情報は移管できるか？ レッドクラウドは、顧客が基盤となるファシリティから機器またはメディアを回収できるようにする権利を持っているか？
最も回復力のある取り決めは、単一の管理キーを回避する。顧客は、自身のドメイン登録、クリティカルな DNS、暗号化キー、ID 管理者、最新のバックアップを管理するか、緊急アクセス権を持つべきである。どの公開 IP アドレスが移動可能で、どれがレッドクラウドに属するかを知るべきである。サービスはサーバー障害を生き残りながらも、1つのアカウントの外部の誰も必要な変更を行えないために完全に故障する可能性がある。
データの所在地は未検証のまま
レッドクラウドのアフガニスタン登録とカブール住所は、ホストされたデータの所在を確立しない。ASN の国はリソース保持者の経済圏を特定するものであり、すべてのサーバー、バックアップ、ログ、サポートセッションの場所を特定するものではない。同社自身の Web サイトが米国 InterServer のスペースでホストされているという事実は、この区別の有用なデモンストレーションである。カブールの企業は、何ら不適切なことなく、外国のインフラ上でサービスを運用できる。
クラウドページは、いくつかの可能な場所を生み出す。「オフサイト」バックアップは、少なくとも1つのコピーがプライマリサイトから分離されていることを意味するが、オフサイトが別のカブールの建物か、別のアフガニスタンの州か、別の国かをページは述べていない。プライベートクラウドおよびハイブリッドクラウドサービスは、一部のデータを顧客構内に、その他を別の場所に配置する可能性がある。Microsoft 365サービスは、マイクロソフト自身の場所とアカウント条件を導入する。移行サービスは、一時的に追加のコピーを作成する可能性がある。
主権または機密保持義務を持つ顧客にとって、配置単位はメインディスクよりも広い。スナップショット、バックアップコピー、オブジェクトストレージ、監視データ、セキュリティログ、サポートチケット、クラッシュダンプ、管理者アクセス、および任意の一時転送領域が含まれる。また、データを復号するために必要な鍵と、アクセスを認可できる ID も含まれる。
レッドクラウドは、データ所在地スケジュール、サブプロセッサー、保持期間、または国境を越えたサポートモデルを公開していない。サイトは、オンプレミスセキュリティページで現地のデータ規則と国際標準に一般的に言及しているが、特定の認証やクラウドコンプライアンスレポートを特定していない。ISO や GDPR へのマーケティング上の言及は、企業またはサービスが認定されていることや、特定の法制度が適用されることの証拠ではない。
これは、答えが未解決であるからこそ、管理されたトピック「データ主権と地域性」を支持する。購入者は、プライマリコンピュート、プライマリストレージ、レプリカ、バックアップ、ログ、サポートレコード、管理アクセスをカバーする所在地マトリックスを要求すべきである。マトリックスは、法的契約当事者と基盤となるプロバイダーを名指しするべきである。また、顧客が場所を選択できるかどうか、および移動がどのように記録されるかも記載すべきである。
所在地には可用性とのトレードオフがある。すべてのコピーを1つの都市に保持することは、ローカル管理を簡素化するかもしれないが、すべてのコピーを都市全体の電力、ファイバー、政策イベントにさらすことになる。復旧コピーを海外に保持することは、災害耐性を向上させるかもしれないが、管轄、レイテンシ、転送依存関係を変化させる。普遍的な正解はない。あるのは、顧客が意図的に選択できるように設計を開示する必要があることだけだ。
移行は復旧の一部であり、後付けではない
レッドクラウドは、クラウド移行をエンドツーエンドサービスとして宣伝している。その逆の操作も同様に重要である：顧客を移転させること。プロバイダーのレジリエンスは、顧客がスクリーンショットと記憶からビジネスを再構築せずに離脱できるかどうかによって部分的に判断されるべきである。
ポータビリティは、フォーマットと所有権から始まる。仮想マシンは標準イメージフォーマットで入手できるか？ ストレージはプロプライエタリな依存関係なしにコピーできるか？ ネットワークルール、ID 設定、証明書、ログ、バックアップ履歴は利用可能か？ 顧客は、別のプラットフォーム上でサービスを再構築するのに十分な構成情報を受け取るか？ マネージド Microsoft またはオンプレミスコンポーネントが含まれる場合、ライセンスと管理アカウントを誰が管理するか？
それは帯域幅にも依存する。大規模なデータ抽出は、制約のあるリンクでは数日かかる可能性があり、可視化された AS153394 エッジには観測されたアップストリームが1つしかない。インシデント中、同じパスが劣化しているか、通常運用に必要とされる可能性がある。ローカルに復旧できるが、現在のコピーを別の場所に配信できないプロバイダーは、部分的なポータビリティしか持たない。
したがって、顧客は緊急事態の前に退出時間を測定すべきである。小規模な代表的なワークロードを抽出し、検証し、独立した宛先で起動できる。テストには、データ整合性、アプリケーション構成、DNS 変更、ID アクセス、およびレッドクラウドのサポートに必要な時間を含めるべきである。元のサービスが健全であることに依存するステップがまだどれかを特定すべきである。
復旧目標には2つの数値が必要である：サービスが利用不能になる可能性がある時間と、失われる可能性がある最近のデータの量である。レッドクラウドの公開ディザスタリカバリのテキストでは、復旧は迅速でダウンタイムは最小化されると述べているが、数値目標は公開していない。値がなければ、顧客はそのサービスが給与システム、公開 Web サイト、アーカイブ、銀行支店に適しているかどうかを判断できない。
最も強力な証拠は、購入したサービスクラスの最近のリストアまたはフェイルオーバー結果だろう。それは、何が隔離されたか、ワークロードがどこで再開したか、どれだけ時間がかかったか、どのデータ区間が失われたか、どの手動アクションが必要だったかを明記すべきである。目標を下回った後の契約上の救済策は有用であるが、運用を復旧しない。テストされたポータビリティは、顧客に別の復旧ルートを提供する。
アフガニスタンの交換エコシステムは利用可能な代替手段を示す
レッドクラウドの単一ネイバーのビューは、アフガニスタンの発展中の相互接続エコシステムの文脈で理解されるべきである。APNIC は2022年に、National Internet Exchange of Afghanistan（NIXA）が2018年にカブールの Afghanistan National Data Centre に確立され、当時の国内64の登録 ISP の約半分を引きつけたと書いた。Internet Society の2026年5月のビューでは、16のリストされたメンバーASN があり、13がルートサーバーを使用しており、14が少なくとも1つの有効な経路起点認証を持っていると報告している。
ローカル交換への参加は、国内ネットワークやサービスに到達するために必要な距離、コスト、外部依存を削減できる。また、ローカルトラフィックの追加のルーティング関係を提供することもできる。国際トランジットを置き換えるものではなく、交換アタッチメント自体が共通のファシリティとスイッチ依存関係を持ち得る。それでも、NIXA の存在は、レッドクラウドの未開示の相互接続を評価できる具体的なベンチマークを提供する。
レッドクラウドのメンバーシップは、その現在の公開リストに現れなかった。同社は、Afghan Telecom を通じて間接的に接続しているか、AS153394 の下でリストされていないプライベートアレンジメントを使用しているか、直接の交換ポートを持っていない可能性がある。各可能性には異なる経済性と復旧動作がある。間接パスは小規模ネットワークにとって運用上理にかなっているかもしれないが、より多くのルーティングと商業的コントロールをアップストリームに委ねる。
Ministry of Communications and IT の公開 ISP リストは、別の不完全な比較である。58のプロバイダーをリストしており、レッドクラウドは含まれていない。一方、レッドクラウドの LinkedIn および TechBehemoths のプロファイルは、同社が通信当局に登録または認可されていると述べている。同省のページは古いか、不完全か、異なるライセンスカテゴリに基づいている可能性があるため、不在はレッドクラウドが権限を欠いていることを立証できない。それは、認可の主張がその公開リストによって独立して解決されていないことを意味する。
インターネットアクセスを購入する顧客は、現在のライセンス名、番号、範囲、満了日を直接要求すべきである。クラウドまたは IT サービス契約は、公共インターネットサービスと同じ権限を必要としないかもしれないが、無線リンク、スペクトラム使用、衛星サービス、国内 ISP 運用には異なる許可が関与し得る。ライセンス上の法的エンティティは、契約およびネットワークリソースレコード上のエンティティと一致すべきである。
これらの公開ギャップは告発ではない。それらは、レッドクラウドが運用上の開示がその提供の幅に追いついていない段階にある兆候である。PeeringDB プロファイルの公開、APNIC 連絡先の修正、交換参加の明示、ライセンス範囲の明確化は、ネットワークを顧客や他の事業者が評価するのを容易にするだろう。
顧客がモデル化すべき6つの障害経路
第1の経路はラックまたはファシリティの障害である。サーバー、ストレージノード、電力分配装置、冷却システム、または部屋全体が利用不能になる。重大な未知数は、レッドクラウドが他の場所に独立したコンピュートと最新データを持っているかどうか、そしてその容量がすでに予約されているかどうかである。バックアップ専用のコピーはアプリケーションをオンラインに保たない。それは、その期間が開示されていない復旧プロセスを開始する。
第2の経路はアップストリームまたはルーティングの障害である。AS55330 が経路を取り下げるか、レッドクラウドのボーダールーターが故障するか、リンクが切断されるか、ルーティング変更が拒否される。現在の公開トポロジーは第2のネイバーを露呈していない。顧客は、プライベートな代替手段が存在するかどうか、どのサービスがそれを使用するか、どれだけのトラフィックを運搬するか、レッドクラウドが160.191.191.0/24のフェイルオーバーをテストしたことがあるかどうかを知るべきである。
第3の経路はアクセスネットワークの障害である。クラウドサービスは健全なままであるが、光ファイバー、ポイント・ツー・ポイント無線、ポイント・ツー・マルチポイント基地局、マイクロ波中継、衛星端末、または顧客の電源供給が故障する。この経路は、レッドクラウドがワークロードと回線の両方を販売する場合に特に重要である。エンドツーエンドの可用性は、いずれかのコンポーネントの個別の数値よりも低くなる可能性があり、共有サイトは障害を相関させる可能性がある。
第4の経路はハードウェア在庫と労働力の障害である。壊れた部品は特定されているが、互換性のあるスペアがカブールになく、資格のあるエンジニアが不在であるか、屋上、鉄塔、ファシリティへのアクセスが遅れる。レッドクラウドの幅広いカタログは、サポートチームが多くの技術をカバーする可能性があることを意味する。顧客は、技術的経験の一般的な主張ではなく、購入した特定のサービスについてローカルストックとエスカレーションの証拠を必要とする。
第5の経路は請求またはプロバイダー契約の障害である。アカウントが停止されるか、ライセンスが失効するか、基盤となるサプライヤーが作業を拒否するか、レッドクラウドがプラットフォームやサイトへのアクセスを失う。ケーブルは切れていないが、顧客はサービスまたは管理上のコントロールを失う。猶予期間、独立した資格情報、最新のコピー、介入権はこのリスクを低減する。
第6の経路は移行の障害である。顧客は劣化中に退出を決定するが、データの抽出が遅い、アプリケーション状態が不完全である、アドレス空間が移動できない、またはクリティカルな ID をレッドクラウドだけが管理していることに気づく。ポータビリティは関係が健全な間に実施されなければならない。テストされていない退出は復旧計画ではない。
これらの経路は相互作用する。全国的なトランスポート混乱は、エンジニアが管理システムに到達すること、顧客がバックアップに到達することを妨げる可能性がある。ファシリティ障害はサポートを殺到させる可能性がある。アップストリーム障害は、移行に必要なデータ移動をブロックする可能性がある。商業紛争は、復旧のために意図されたまさにそのコピーへのアクセスを妨げる可能性がある。それらを個別にモデル化する目的は、それらが分離したままだと偽ることではない。各依存関係が独立したフォールバックを獲得するポイントを特定することだ。
グレードを引き上げる証拠は何か
レッドクラウドはすでに、より強力な保証ケースの始まりを持っている。登録された ASN、長期間可視化されている経路、有効な起点認可、企業管理のサービスページ、公開連絡先詳細、具体的な接続性カタログがある。これらは匿名のリセラーの主張よりも優れている。グレードが弱いままなのは、証拠が約束の高価な部分の手前で止まっているからだ。
最初の改善は、明確なサービス所有権の声明だろう。各クラウド製品について、レッドクラウドは、ハードウェアを所有しているか、コロケーションをリースしているか、別のプロバイダーを再販しているか、顧客の機器を管理しているかを述べることができる。契約当事者と物理的な修理権限を持つ当事者を名指しすることができる。これにより、顧客は正しい証拠を要求できるようになる。
2番目は、所在地と障害ドメインの声明だろう。公開開示には都市と国で十分である。正確なラックの場所は非公開のままでよい。声明は、本番、レプリカ、バックアップ、管理の場所を区別し、共有された電源、ファシリティ、ネットワーク依存関係を特定すべきである。レッドクラウドの提供において「アベイラビリティゾーン」が何を意味するかを定義すべきである。
3番目は、測定可能なサービスおよび復旧条件だろう。有用な数値には、サービス可用性、サポート応答、復旧目標、データ損失目標、バックアップ頻度、保持、抽出時間、劣化パス容量が含まれる。条件は、特にレッドクラウドがアクセスとホスティングの両方を提供する場合に、除外事項とサービス境界を明記すべきである。
4番目は、外部ネットワークの衛生だろう。最新の PeeringDB プロファイルにより、AS153394 のネットワークタイプ、トラフィックポリシー、ファシリティまたは交換接続、ネットワーク運用連絡先を開示できる。APNIC インシデント連絡先は正しいドメインを使用すべきである。AS153394 の外部にある公開ステータスページは、経路障害中も通信を維持するだろう。IPv6 展開は明らかなプロトコルギャップを取り除くだろうが、IPv4 と同じ運用サポートが必要になる。
5番目は、テスト証拠だろう。最近のホストフェイルオーバー、ストレージリストア、サイト隔離演習、アップストリームフェイルオーバー、サポートエスカレーション、顧客データ抽出は、ストレス下でシステムが何をするかを示すだろう。結果は顧客データを露呈する必要はない。日付、範囲、経過時間、データ成果、教訓は、リハーサルされた能力と意図を区別するのに十分である。
最後に、顧客は自身のコントロールを保持すべきである。AS153394 と160.191.191.0/24の独立した監視は、経路の取り下げや起点変更を示すことができる。顧客が保持するバックアップ、ドメイン管理、暗号化キー、管理者アクセスはロックインを低減できる。独立したサプライヤーからの第2のアクセスパスは、ローカルな到達可能性をレッドクラウド自身のエッジから分離することができる。プロバイダーの保証と顧客のレジリエンスは、代替品ではなく、補完物である。
評決：レジリエンスの証明を伴わない運用証拠
RED CLOUD INFORMATION TECHNOLOGY SERVICES COMPANY はペーパーオンリーのサブジェクトではない。AS153394 はアクティブである。160.191.191.0/24はグローバルに可視化されている。その経路起点認可は有効である。経路履歴は2024年11月までさかのぼる。同社はまた、アクセス、無線、ビジネス、クラウドの詳細な一連のサービスを公開している。これらの事実は、レッドクラウドをアフガニスタンにおける運用インフラ依存関係の候補として扱うことを正当化する。
同じ証拠は、そのクラウドの主張を独立して検証された容量として扱うことを正当化しない。公開経路フットプリントは、1つの IPv4 /24、1つの観測されたネイバー、IPv6 アナウンスなしである。PeeringDB プロファイルはなく、AS153394 下での NIXA メンバーシップのリストはなく、名指しされたファシリティはなく、開示されたゾーン所在地はなく、ホストまたはストレージの目録はなく、サービスレベルスケジュールはなく、復旧目標はなく、公開フェイルオーバー結果もない。同社自身の Web サイトが自社 ASN の外部でホストされており、企業所在地だけがサービス所在地についてほとんど示さないことを例証している。
この違いはいくつかのグループにとって重要である。小規模ビジネスは、インターネットアクセスとマネージドアプリケーションの両方をレッドクラウドに依存するかもしれない。銀行支店は地上または衛星リンクに依存するかもしれない。政府機関や NGO は、マネージド接続性、クラウドバックアップ、またはオンプレミスサポートを使用するかもしれない。リセラーはレッドクラウドのルーティングとエスカレーションに依存するかもしれない。システムが故障すると、影響は抽象的な「クラウドがダウンした」ではない。スタッフはアクセスを失い、トランザクションは待機し、バックアップは停止し、リモートサイトは隔離され、移行はまさに最も必要な瞬間にさらに困難になる。
証拠グレードは弱いであり、否定的ではない。可視化されたネットワークと詳細なサービスページは肯定的な運用シグナルである。グレードダウンは、それらのシグナルと、複数のアベイラビリティゾーン、冗長化システム、迅速な復旧の主張との間の距離を反映している。その距離を埋めるために必要な事実は知り得るものである：誰が機器を所有しているか、障害ドメインがどこにあるか、どのパスが独立しているか、どの容量が生き残るか、夜間に誰が応答するか、そして顧客がどのように自身のワークロードを取り出すか。
レッドクラウドの最も有用な次の一手は、シームレスなサービスについての別の広範な声明ではないだろう。それは、提供の背後にある物理的および契約上のシステムについての、コンパクトでテスト可能な説明だろう。それまでは、顧客は同社のクラウドを、外部エッジは可視化されているが、ラック、所在地、冗長性、復旧は直接的な証拠と契約の問題として残る、潜在的に実在するサービスとして扱うべきである。