要約
- Global Cloud Ltd は、ディレクトリ上の単なる名称ではなく、RIPE を通じて確認できる真のネットワーク事業者です。ORG-GCL12-RIPE の RIPE 組織エンティティには Global Cloud Ltd が記載されており、イスラエルの会社番号
514919729、組織タイプLIR、住所 HaMasik St 4, Emek Hefer, Israel、および同社ウェブサイトに記載されているものと同じ電話番号が示されています。 - 同社は AS61365 に関連付けられており、そのRIPEstat AS 概要にはホルダーが
GC-5222 Global Cloud Ltdと記載され、クエリ日時 2026年7月11日時点で AS がアナウンスされていることが示されています。RIPEstat ルーティングステータスビューでは、4つの IPv4 プレフィックス、1,024 の可視 IPv4 アドレス、可視の IPv6 プレフィックスなし、2つの観測されたネイバーが表示されました。 - 同社のアドレス空間は独立した第三者ブロックではありません。185.184.16.0/22 の RIPE RDAP プレフィックス登録およびRIPEstat whois ビューでは、
IL-GLOBAL-20170102、国 IL、組織ORG-GCL12-RIPE、ステータスALLOCATED PA、および /22 と各 /24 を Emek Hefer に関連付ける geofeed ファイルgeofeed.xprsit.netが特定されています。 - 経路起点保証は、多くの小規模ホスティングフットプリントよりも優れています。185.184.16.0/24、185.184.17.0/24、185.184.18.0/24、185.184.19.0/24に対する RIPEstat RPKI 検証応答は、いずれも最大長 24 の ROA 185.184.16.0/22 の下で
validを返しました。 - トランジットプロバイダーの状況は、まだ顧客によるテストが必要です。RIPE aut-num エンティティには AS1680、AS212616、AS8551 のポリシーがリストされていますが、RIPEstat ASN ネイバービューでは、観測されたネイバーとして AS1680 と AS212616 が表示され、AS ルーティング整合性ビューでは、AS8551 が whois ポリシーには存在するものの、クエリ時点では BGP に存在しないことが示されました。
- エビデンスレベルは中程度です。公開情報源は、法的アイデンティティ、ネットワークリソース管理、現在の IPv4 到達可能性、経路起点検証を強く支持しています。ただし、ラック数、施設所有権、予備ハードウェアの深度、テスト済みのマルチサイト復旧、実際の顧客ワークロードの範囲、契約上のサポート応答時間、データポータビリティの制限は証明されていません。
公的記録は具体的だが、クラウド容量は未証明
Global Cloud Ltd は、集約リストにのみ表示される中空のホスティング名とは異なる扱いに値します。同社は公的なネットワークアイデンティティ、公式ウェブサイト、RIPE LIR ステータス、RIPE 組織エンティティ内のイスラエル会社番号、アクティブな自律システム、登録された IPv4 割り当てを有しています。AS61365 の RIPE aut‑num RDAP レコードは AS をGC‑5222と命名し、組織エンティティとして Global Cloud Ltd をリストし、住所 HaMasik St 4, Emek Hefer, Israel を繰り返しています。同社の英語のホームページには、連絡先として Hamasek 4, Emek Hefer Industrial Park と記載され、電話番号 072‑274‑3030 が公開されており、開発、ストレージ、セキュリティに関連するサービスが説明されています。
この組み合わせにより、同社は分析可能な十分な観測可能性を備えています。しかし、サービスが外部から完全に検証可能になるわけではありません。クラウド、ホスティング、仮想デスクトップ、またはマネージドサービスを購入する顧客は、単に AS 番号を購入しているわけではありません。彼らはラック、回線、光学機器、ルーター、ハイパーバイザー、ストレージ、バックアップジョブ、ライセンス、サポートチーム、電源、アクセス制御、請求システム、移行手順に賭けています。パブリックインターネットは AS61365 が到達可能であることを示せますが、特定の顧客ワークロードがストレージシェルフ障害、プロバイダー紛争、停電、ルーティング変更後に復旧できるかどうかは示せません。
したがって、Global Cloud を最も有用に解釈する方法は、十分な公開証拠により推測を回避しつつ、十分な運用詳細が欠けているためデューデリジェンスを要求する、中規模のインフラ面と見なすことです。同社サイトの英語のクラウドサービスページには、データセンターとクラウドサービス、DaaS、PaaS、Infrastructure as a Service、コラボレーションサービス、IT サービス、ソフトウェアサービスを提供すると記載されています。また、サポートチームは 24 時間 365 日対応し、Global Cloud はセキュリティと生存性を重視しているとも述べています。これらは関連するサービスの主張であり、復旧可能性テストに代わるものではありません。
証拠には、小さな手がかりとなる編集上の痕跡も含まれています。英語のクラウドページの一部では「Xpress Technologies」に言及している一方、ドメイン、RIPE レコード、フッターは Global Cloud を指しています。これは、過去のコンテンツ、テンプレートの残骸、関連ブランド、翻訳の産物である可能性があり、公開証拠では判断できません。顧客にとってのリスクポイントは、この名前の不一致が何か否定的なことを証明するということではありません。むしろ、広範なクラウドの約束は、古いまたは一貫性のないウェブコンテンツから推測されるのではなく、現在のサービス契約、現在のプラットフォーム概要、現在のサポート制限と整合させる必要があるということです。
本記事では、運用上のテーゼは単純です：Global Cloud Ltd は実際のイスラエルのネットワークフットプリントと、顧客依存を生み出すのに十分な広さの公開サービスカタログを持っています。バイヤーの仕事は、そのカタログのうちどの程度がインストールされているか、物理的にどこでホストされているか、経路がどのようにフェイルオーバーするか、営業時間外にスタッフがどのように対応するか、サービスがもはや適さなくなった場合にワークロードをどのように移行できるかを検証することです。
AS61365 により Global Cloud は測定可能な優位性を得る
最も強力な企業固有の証拠は AS61365 から始まります。RIPEstat AS 概要にはホルダーがGC‑5222 Global Cloud Ltdと記載され、2026年7月11日 08:00 UTC に AS がアナウンスされたことが示されています。RIPEstat ルーティングステータスエンドポイントでは、4つの IPv4 プレフィックス、1,024 の IPv4 アドレス、IPv6 プレフィックスなし、326/327 のフルフィード RIS IPv4 ピアが経路を認識し、IPv6 の可視性はゼロと表示されました。アナウンスされたプレフィックス応答で現在アナウンスされている4つのプレフィックスは、185.184.16.0/24、185.184.17.0/24、185.184.18.0/24、185.184.19.0/24 でした。
これは意味のあるネットワークエントリポイントです。また、ハイパースケールフットプリントではありません。/22 を4つの /24 アナウンスに分割することで、顧客サービス、ホスト型プラットフォーム、VPN、メール、デスクトップサービス、管理ネットワーク、静的アクセス顧客、またはそれらの組み合わせをサポートできます。それ自体で広範囲のパブリッククラウド資産を証明するわけではありません。アナウンスされた IPv4 アドレスの数は、サーバー、仮想マシン、テナント、バックアップリポジトリ、復旧ターゲットの数ではありません。RIPEstat で IPv6 が見えないことも重要です。これは、IPv6 対応が多くのバイヤーのネットワーク計画の一部となっているためです。
RIPEstat プレフィックス数エンドポイントは有用な履歴を追加します。これは、2026年7月11日のクエリ期間中に、以前の可視性の変化を経た現在の4つの IPv4 プレフィックスパターンと、IPv6 プレフィックス数ゼロを示しています。ルーティング履歴エンドポイントは、2012-2014 年の 94.30.220.0/24 における AS61365 の以前の可視性と、2017 年以降の 185.184.16.0/22 ファミリーを示しています。この履歴はルーティングレベルでは肯定的な兆候です：AS61365 は1週間の実験ではありません。
しかし、経路継続性はサービス継続性ではありません。94.30.220.0/24 の古い履歴から 185.184.16.0/22 ファミリーへの移行は、プロバイダー、サービス、アドレスリソースの取得、顧客の変更、または単に異なるプレフィックスの可視登録を反映している可能性があります。パブリック BGP は商業的な理由を説明しません。AS が異なる期間に観測された経路を持ち、現在のルーティングフットプリントが 185.184.16.0/22 の下の4つの /24 で構成されていることのみを示します。
したがって、顧客は AS61365 を強力な出発点かつ弱い最終証明として扱うべきです。これは詳細な質問を正当化できますが、回答に代わるものではありません。Global Cloud が仮想サーバーを販売する場合、バイヤーはホストアーキテクチャとストレージを必要とします。デスクトップ as a Service を販売する場合、バイヤーはユーザーセッション容量、アイデンティティ依存関係、リンクパフォーマンスを必要とします。マネージドアプリケーションを販売する場合、バイヤーは運用所有権とバックアップ詳細を必要とします。IaaS を販売する場合、バイヤーはスタックのどの部分が自動化され、どの部分が手動管理のホスティング資産かを知る必要があります。
/22 割り当ては制御をサポートするが、無制限の規模ではない
アドレス空間の証拠は、ルーティングされたプレフィックスが完全に別個のアドレス貸主ではなく Global Cloud に結び付けられているため、特に有用です。185.184.16.0/22 の RIPE RDAP プレフィックスレコードは、ハンドル185.184.16.0 – 185.184.19.255、名前IL‑GLOBAL‑20170102、タイプALLOCATED PA、国 IL、組織エンティティ Global Cloud を示しています。RIPE REST inetnum エンティティは同じ割り当てを繰り返し、geofeed URL を追加しています。組織エンティティは Global Cloud Ltd を LIR として提示しています。これは、単に他人のブロックをアナウンスする小規模プロバイダーよりも強力なアイデンティティポジションであるため重要です。
より具体的なレジストリラベルは、顧客の使用を証明することなく色彩を加えます。RIPEstat アドレス空間階層応答は、185.184.16.0/24 をSHVDOM‑1‑Subnet、185.184.17.0/24 をSHVDOM‑Core‑Subnet、185.184.18.0/24 をLNS‑Static‑Subent、185.184.19.0/24 をSHVDOM‑Subnetとしてリストしています。これらの名前は内部セグメンテーションと少なくとも1つの静的またはネットワークサービスのラベルを示唆しています。これらは、各サブネットからどの製品が販売されているか、どの顧客がそれらを使用しているか、ラベルが現在の運用説明なのか管理上の名前なのかを証明するものではありません。
この区別はホスティングの経済性の中心です。プロバイダーはアドレス割り当てを所有または運用していても、その背後に限られたインストール済みサーバー容量しか持たない場合があります。プロバイダーは1つの /24 を静的顧客サービスに、別のものを管理またはコア機能に、さらに別のものをホスト型ワークロードに使用できます。また、コントロールプレーンやウェブサイトが異なるネットワークにあるサービスを販売することもできます。公開アドレスマップは、バイヤーにどこから始めるかを示すのであって、すべての依存関係の終点を示すわけではありません。
同社の公開ウェブサイトがこの点を示しています。調査中に簡単な DNS ルックアップにより、globalcloud.meおよびwww.globalcloud.meが 212.29.210.119 に解決され、212.29.210.119 の RIPEstat whois ビューはそのアドレスをIL‑NETVISION‑980831に配置しており、Global Cloud の 185.184.16.0/22 割り当て内ではありません。これは珍しいことではありません。多くのプロバイダーはマーケティングウェブサイトを別のキャリアまたは別のプラットフォームでホストしています。ポイントは、ウェブサイトのエンドポイントを顧客のクラウドワークロードが存在する場所の証明と見なすべきではないということです。
顧客にとっての正しい質問は、したがって「Global Cloud はアドレスを所有しているか？」ではありません。所有しています。より良い質問は、それらのアドレスがサービスにどのように割り当てられているか、顧客の IP アドレス割り当てが移植可能か、逆 DNS とレピュテーションがどのように管理されているか、リナンバリングがどのように機能するか、Global Cloud がトランジットプロバイダー、サブネット、またはサービスプラットフォームを変更した場合にバイヤーが十分な通知を受け取るかです。
RPKI は現在の公開証拠において真の強み
経路起点検証は、Global Cloud のフットプリントが情報不足のベースラインよりも強く見える数少ない公開チェックの1つです。RIPEstat RPKI 検証エンドポイントは、AS61365 に対してクエリされた場合、185.184.16.0/24、185.184.17.0/24、185.184.18.0/24、185.184.19.0/24 に対してvalidを返しました。各応答は、起点 AS61365、最大長 24 の 185.184.16.0/22 に対する検証 ROA を指していました。これは、4つの現在の /24 アナウンスがクエリ時点で公開された経路起点認証と一致することを意味します。
技術的価値は狭いですが現実的です。RFC 6811は、BGP プレフィックス起点検証を、ルーターがプレフィックスをアナウンスすると主張する AS がプレフィックスホルダーによって許可されているかどうかを判断する方法として説明しています。RPKI はパケットを暗号化せず、すべての経路リークを防ぐわけでも、経路が最適であること、データセンターが回復力を持つこと、アプリケーションセキュリティを解決することを証明するわけでもありません。ただし、ネットワークが検証ポリシーを適用する場合、誤った起点アナウンスのリスクの一種を低減します。
Global Cloud にとって、これはルーティングされたフットプリントがコンパクトであるため重要です。プロバイダーが現在可視の /24 を4つ持ち、IPv6 が可視でない場合、経路起点エラーは公開サービス面の大部分に影響を与える可能性があります。現在の /24 アナウンスに対する有効な ROA は、unknownまたはinvalidの結果よりも顧客に強力な出発点を提供します。また、アドレスホルダーと起点の関係に少なくとも1つの最新のルーティングセキュリティ制御が導入されていることも示します。
ただし、RPKI は顧客 SLA ではありません。AS1680、AS212616、またはその他のトランジット経路が障害後にトラフィックを運ぶのに十分な容量を持っているかどうかは示しません。ルーターが冗長かどうか、アンチ DDoS フィルタリングがアクティブかどうか、顧客のバックアップが復旧可能かどうか、すべての運用経路オブジェクトが整っているかどうかも示しません。RIPEstat プレフィックスルーティング整合性応答は、集約経路オブジェクト 185.184.16.0/22 が whois に存在し、185.184.19.0/24 が BGP と whois の両方に存在し、アナウンス 185.184.16.0/24、185.184.17.0/24、185.184.18.0/24 がその特定の整合性ビューで一致する whois 経路オブジェクトなしで BGP に存在することを示しました。RIPEstat AS ルーティング整合性応答は同じ乖離を示しています。
この乖離は、RPKI ステータスが有効で集約経路オブジェクトが存在するため、危機ではありません。依然として有用な運用証拠です。顧客は、Global Cloud が意図的に /24 に対して集約経路オブジェクトと RPKI に依存しているかどうか、トランジットプロバイダーが使用する IRR フィルターが現在のアナウンスを受け入れているかどうか、ROA と経路エンティティの更新を保護する変更管理プロセスは何かを尋ねるべきです。レジストリビューにおける小さな不一致は、メンテナンス中にプロバイダーフィルター、ルートサーバー、またはトランジットプロバイダーが異なる解釈をした場合、重大なインシデントになり得ます。
要約：RPKI は強みです。現在の制御として認識され、適切な位置に保たれるべきです。
トランジット多様性は可視だが、フェイルオーバーのシナリオは未完了
最も重要な運用上の質問は、ポリシーエンティティにいくつのキャリア名が表示されるかではありません。経路、ルーター、相互接続、または商業契約が失敗した場合に、どの経路がトラフィックを運ぶことができるかです。Global Cloud の公開記録は、その質問を正確に行うのに十分な証拠を提供します。
AS61365 の RIPE aut-num エンティティには、AS1680、AS212616、AS8551 のポリシーエントリが含まれています。RIPEstat はAS1680を Cellcom Fixed Line Communication L.P、AS212616を K.M.A ADVANCED TECHNOLOGIES LTD、AS8551を Bezeq International Ltd として識別します。これらは真剣なイスラエルのネットワーク名です。ASN ネイバーエンドポイントは、最後に利用可能なクエリ時間で2つの観測されたネイバーを示しました：AS1680 と AS212616。AS ルーティング整合性エンドポイントは、AS1680 と AS212616 が BGP と whois の両方に存在し、AS8551 は whois には存在するがその時点では BGP には存在しないことを示しました。
経路サンプルは状況を明確にします。185.184.16.0/24 の場合、サンプリングされた BGP 経路は AS1680 AS61365 で終了しました。185.184.17.0/24 および 185.184.18.0/24 の場合、支配的な可視ラストホップパターンも AS1680 AS61365 で終了しました。185.184.19.0/24 の場合、可視パターンは AS1680 AS212616 AS61365 で終了しました。これは完全なキャリアマップではなく、公開コレクターはプライベートまたは低可視性セッションを見逃す可能性があります。それでも有用な手がかりです：異なる /24 は異なる隣接または準隣接経路を取る可能性があり、AS212616 は少なくとも 185.184.19.0/24 ビューで経路パスに可視です。
顧客はこれを、さらなる証拠なしに「シングルホーム」または「完全冗長」と読むべきではありません。むしろ「部分的に可視のマルチホーミングまたはプロバイダーポリシーの複雑さ」と読むのが良いでしょう。顧客は、どの ASN がアクティブなプロダクショントランジットか、どれがバックアップか、どれが歴史的か、どれが特定の顧客サービスを運ぶかを尋ねるべきです。回答には、帯域幅のコミットメント、ルーター多様性、物理相互接続多様性、メンテナンスウィンドウ、DDoS 管理、エスカレーション連絡先、最近のフェイルオーバーテストを含める必要があります。
障害経路は具体的です。AS1680 が地域インシデントまたは経路フィルター問題を被った場合、4つの /24 は AS212616 または別の経路を介して継続できますか？AS212616 が 185.184.19.0/24 経路の一部である場合、どの顧客サービスがその /24 に依存していますか？AS8551 がポリシーエンティティにあるが現在 BGP で可視でない場合、それはスタンバイセッション、非アクティブな歴史的取り決め、計画された経路、またはポリシーアーティファクトですか？障害後にトラフィックがフェイルオーバーする場合、プロバイダーはパケット損失を避けるために十分なアップストリーム容量とクリーンな経路プリファレンスを持っていますか？
これらの質問は非難するものではありません。それらはサービスカタログと運用設計の違いです。ホスティングプロバイダーは、テストされた経路、バックアップ容量、明確なエスカレーションがあれば、コンパクトな公開エッジから回復力のあるサービスを正直に販売できます。また、最初の主要なラックまたはプロバイダーインシデントまではうまく機能する狭い依存関係チェーンから広範なカタログを販売することもできます。公開データは Global Cloud をこれら2つの結論の間に位置づけます。直接の顧客デューデリジェンスが、現実がどちらに近いかを決定します。
Emek Hefer は強い地域性シグナルだが、ラック証明書ではない
Global Cloud には、複数の重複するイスラエルの地域性シグナルがあります。RIPE 組織エンティティは HaMasik St 4, 3877701, Emek Hefer, Israel をリストしています。RDAP aut-num エンティティは住所を繰り返しています。Global Cloud ホームページは Hamasek 4, Emek Hefer Industrial Park と同じ電話番号を記載しています。RIPE inetnum エンティティで参照されている geofeed ファイルは、185.184.16.0/22 と4つの /24 のそれぞれをIL, IL‑HA, Emek Heferにマッピングしています。
これは、同社とそのアドレス空間の支配的な公開ロケーションシグナルとしてイスラエルと Emek Hefer を議論するのに十分です。ただし、すべての顧客ワークロード、バックアップ、ログ、管理セッション、災害復旧コピーが物理的に Emek Hefer にあると言うには不十分です。IP レジストリの住所、geofeed の地域性、連絡先詳細は施設監査を構成しません。プロバイダーは1つのサイトでラックを運用し、別のサイトで容量を借り、リモートバックアップサービスを使用し、クラウドプラットフォームを通じてサポートツールを実行し、一部の公開サービスを他の事業者でホストする場合があります。
地理位置情報は、なぜ注意が必要かを示しています。RIPEstat 地理位置情報ビューおよびMaxMind GeoLite ビューは /22 をイスラエル内ではあるが Ar Rayna に配置しており、Emek Hefer ではありません。この矛盾は geofeed を否定するものではありません。IP 地理位置情報データベースはしばしば異なり、geofeed データは事業者の意図または自己公開の地域性を表すことができます。これは、バイヤーが IP 地理位置情報ルックアップを物理的な配置の保証として使用すべきでないことを証明しています。
地域性が重要なのは、Global Cloud のサービスカタログにデータセンター型、クラウド、デスクトップ、プラットフォーム、ソフトウェア、バックアップサービスが含まれているためです。イスラエルプライバシー保護庁のデータセキュリティに関するページは、民間および公共部門に適用され、データベースセキュリティに関する組織的メカニズムを定めるデータセキュリティ規制について説明しています。同じ政府ポータルは、欧州経済領域からイスラエルに転送されるデータに関する規制上のプライバシー文書を公開しています。これらの公式ページは、どの Global Cloud 顧客が個人データを処理するか、Global Cloud が特定の契約下で処理者として行動するかを教えてくれません。これらは、バイヤーがデータの所在地を単なるマーケティングフレーズとして放置できない理由を説明しています。
顧客にとっての実践的な質問は単純です。プライマリワークロードはどこでホストされていますか？バックアップはどこに保存されていますか？バックアップは暗号化され、テストされていますか？どの従業員、下請け業者、またはサプライヤーがイスラエル国外からシステムにアクセスできますか？ログ、モニタリングストリーム、サポートチケット、またはアイデンティティシステムは外国のプラットフォームで処理されていますか？顧客がイスラエル、EEA、またはセクター固有のデータ取り扱いを証明する必要がある場合、Global Cloud はどのような契約上の文書と技術的管理を提供しますか？
Global Cloud の公開証拠は、同社がイスラエルのネットワークとオフィスフットプリントを持ち、クラウド隣接サービスを販売しているため、データ主権とデータ地域性のテーマを支持しています。ただし、グローバルなコンプライアンスステートメントを支持するものではありません。
サービスカタログは深刻な顧客依存を生み出すのに十分広い
Global Cloud の英語のクラウドページは、単純なウェブホスティングの提案に限定されていません。データセンターとクラウドサービス、エンタープライズシステムとエンドポイントの統合、継続的な監視とメンテナンス、VMware および KVM/XEN/Hyper‑V タイププラットフォーム上の仮想化、安全なインターネット接続、安全なストレージ、DaaS、PaaS、Infrastructure as a Service、コラボレーションサービス、IT as a Service、Software as a Service を説明しています。英語のホスティングページはデータセンターとクラウドのテーマを繰り返し、ホスティング、DaaS、テレフォニーサービスをリストしています。アバウトページはヘブライ語で、Global Cloud Ltd が 2013 年に設立され、地元の専門家によるパーソナライズドサービスを中心に据えていると述べています。
これらの主張は、Global Cloud をコモディティ化されたドメイン名層ではなく依存層に位置づけるため重要です。DaaS を使用する企業は、セッションブローカー、アイデンティティ、ストレージ、エンドポイントパフォーマンス、サポートに依存します。IaaS を使用する企業は、コンピュート、ストレージ、ネットワーキング、イメージ管理、復旧に依存します。コラボレーションまたはテレフォニーサービスを使用する企業は、可用性、コールフロー、ディレクトリ、ユーザープロビジョニング、設定エクスポートに依存します。マネージドソフトウェアを使用する企業は、パッチ適用、バックアップ、アクセス制御、変更承認に依存します。
公開ネットワークフットプリントはそのようなサービスをサポートできますが、それらのインストール深度を開示しません。4つの可視 /24 は、特にターゲットを絞ったイスラエルのプロバイダーにとって、意味のある地域プラットフォームをサポートできます。また、サービスがサードパーティプラットフォームまたはレンタル容量を通じて提供される場合、はるかに狭い資産を隠すこともできます。セキュリティ、生存性、24/7 サポートに関するウェブサイトの主張は、測定可能なコミットメントに変換される必要があります：サポートチャネル、応答時間、インシデント通知、バックアップ頻度、復旧時間、復旧ポイント、データエクスポート、顧客側フェイルオーバー、終了支援。
ウェブサイトの証拠における実践的な緊張は、サポート時間に関するものです。英語のホームページヘッダーには、日曜日から木曜日 09:00–18:00、金曜日と土曜日は休業と記載されています。クラウドページはサポートチームが 24/7 対応と述べています。単純な説明があるかもしれません：営業時間と技術サポートカバレッジが異なる。バイヤーはその区別を契約で明確にすべきです。何が 24/7 で保証されていますか？何がオンコールですか？どの重大度レベルが即時応答を受けますか？ネットワーク障害時にどの連絡先パスが機能しますか？サポートポータルは影響を受ける環境の外部でホストされていますか？通常の営業時間外に緊急変更を承認できるのは誰ですか？
サービスカタログはまた、ライセンスとプラットフォーム依存を生み出します。クラウドページは、VMware、XEN、Microsoft タイプのインフラストラクチャサポートに言及しています。顧客は、自分のサービスが専用か、マルチテナントか、下請けか、プラットフォームライセンスが含まれているか、スナップショットが移植可能か、仮想マシンイメージが標準形式でエクスポート可能か、アイデンティティ、テレフォニー、またはコラボレーションデータが長い手動プロジェクトなしで移行できるかを尋ねるべきです。
顧客リスクに関する中心的な教訓は、Global Cloud の公開証拠が真剣に受け止めるのに十分信頼できる一方で、バイヤーが単一の一般的な「クラウド」保証を受け入れるべきではないほど広いということです。カタログ内の各サービスには異なる障害モードがあります。
インストール容量と使用可能容量は急速に乖離する可能性がある
クラウドバイヤーはしばしば、インストール容量と使用可能容量を混同します。インストール容量とは、プロバイダーが通常の条件下で構築、レンタル、または構成したものです。使用可能容量とは、何かが失敗したとき、顧客が成長したとき、プロバイダーが条件を変更したとき、または制約下で移行が行われなければならないときに残っている容量です。Global Cloud の可視フットプリントは、真のホスト型サービスには十分な大きさであり、顧客がその背後にどの程度のヘッドルームがあるかを尋ねるべきほど小さいです。
/22 は 1,024 の IPv4 アドレスを保持します。パブリック IPv4 は希少であり、/22 の制御は地域のホスティングプロバイダーにとって価値があります。しかし、アドレス数はコンピュート数ではありません。一部のアドレスがインフラストラクチャ、静的顧客アクセス、NAT、管理、メール、VPN、デスクトップゲートウェイ、またはネットワーク機器に使用されている場合、新しいホスト型サービスに利用可能なパブリックアドレスのプールは、生の数値よりも小さい可能性があります。一部のサービスがゲートウェイの背後でプライベートアドレス指定されている場合、パブリックアドレスプールはコンピュート容量を過小評価する可能性があります。パブリック BGP だけではこれを解決できません。
より具体的なサブネットラベルは疑問を追加します。SHVDOM‑Core‑Subnetはコアインフラストラクチャのように見えます。LNS‑Static‑Subentは静的アクセスまたはサブスクライバー機能を示唆します。SHVDOM‑SubnetおよびSHVDOM‑1‑Subnetはサービス固有のセグメンテーションを示唆します。これらは単なるレジストリラベルですが、バイヤーは購入したサービスを実際の依存関係にマッピングするきっかけとすべきです。DaaS 顧客は1つの /24 上のデスクトップファームからサービスを受けていますか？静的アクセスまたは LNS 機能は顧客接続に結び付けられていますか？クラウド管理と顧客ワークロードは分離されていますか？バックアップネットワークは可視ですか、それともプライベートですか？
使用可能容量はハードウェア在庫にも依存します。サーバーが故障した場合、Global Cloud はローカルで交換できますか、それとも修理はベンダーの在庫と輸入リードタイムに依存しますか？ルーターまたはファイアウォールが故障した場合、現在の設定でサイトにスペアユニットはありますか？ストレージシェルフが劣化した場合、パフォーマンスを損なわずに再構築するのに十分なマージンがありますか？ハイパーバイザークラスターがノードを失った場合、残りのホストは N+1 に対応しているか、平均負荷のみに対応していますか？
これらの質問のいずれも、RIPE レコードやウェブサイトの主張によって回答されるものではありません。だからこそ、それらは尋ねられなければなりません。公開記録は実際の事業者の存在と現在の到達可能性を証明します。契約はサービス容量と復旧容量を証明しなければなりません。
ラック、トランジットプロバイダー、ハードウェア、サポート、請求が実際の障害経路
この資料における主な障害経路は理論的なものではありません。Global Cloud にとって、最も可能性の高い公開障害経路は、ラックまたは施設の停止、トランジットプロバイダーまたは経路フィルターの問題、ハードウェア不足、サポートエスカレーションの失敗、請求またはサプライヤー契約の紛争、移行制限です。
ラックまたは施設の障害は物理的アクセスをテストします。Global Cloud のクラウド容量が単一の部屋または単一のデータセンタープロバイダーに集中している場合、電力、冷却、ファイバー、アクセス制御、またはリモートハンドの問題がサービス停止につながる可能性があります。同社のウェブサイトはセキュリティと生存性を主張し、ヘブライ語のクラウドコンテンツは複数の地理的に分離されたデータセンターと災害復旧オプションを主張しています。公開記録はそれらのサイトの数、アイデンティティ、独立性を検証しません。顧客は必要に応じて機密保持契約のもとでサイトリストを要求すべきですが、回答は依然としてプライマリ、バックアップ、管理システムが共通の障害ドメインを共有しているかどうかを示すべきです。
トランジットプロバイダーの障害は、AS1680 と AS212616 への依存をテストします。公開ネイバーと整合性レコードは2つの観測されたピアを示し、AS8551 はポリシーにはあるがクエリ時点では BGP に可視ではありません。顧客は、各ルーティングされた /24 に少なくとも2つのアクティブな経路があるか、それらの経路が異なるルーターと建物を通って入っているか、すべての経路がフェイルオーバーに対応しているか、DDoS 緩和が単一のキャリアに依存しているかを尋ねるべきです。回答は現在のネットワーク設計であるべきであり、単なるレジストリエンティティではありません。
ハードウェア在庫の不足は、サービスの背後にある経済性をテストします。小規模プロバイダーは、慎重なローカルスペアと明確なベンダーカバレッジで優れたサービスを提供できます。また、故障したディスク、電源、ルーターモジュール、またはファイアウォールエンクロージャをインシデント後に調達しなければならない場合、問題に直面する可能性があります。顧客は、サービス種類ごとの交換目標を尋ねるべきです：仮想ホスト、専用サーバー、ストレージシェルフ、トップオブラックスイッチ、エッジルーター、ファイアウォール、バックアップアプライアンス、該当する場合は顧客宅内機器。
サポート障害は、24/7 というフレーズと実際のエスカレーションの違いをテストします。ウェブサイト上の 24/7 サポートの主張は有用ですが、顧客は重大度レベル、チケットチャネル、電話エスカレーション、言語カバレッジ、時間外の権限、インシデントコミュニケーションを定義すべきです。サポートサイトやメールが同じプロバイダーネットワークに依存している場合、顧客は帯域外の経路を知っておくべきです。
請求またはサプライヤー契約の障害は停電ほど劇的ではありませんが、同様に混乱を招く可能性があります。Global Cloud は LIR であり、独自のアドレス空間を保持しているため、アドレスリソースの依存関係はレンタルブロックをアナウンスするプロバイダーよりも管理されているように見えます。それでも、アップストリームトランジット、ソフトウェアライセンス、データセンターリース、バックアップサービス、Microsoft タイプのサービスはすべて契約上の依存関係を生み出す可能性があります。顧客は、価格、IP アドレス、プラットフォーム、またはサプライヤーの変更が影響する前にどのような通知が適用されるかを尋ねるべきです。
移行障害は最も静かなリスクです。顧客が離脱したい場合、仮想マシンイメージ、デスクトッププロファイル、メールデータ、ソフトウェアデータベース、テレフォニー設定、ファイアウォールポリシー、DNS ゾーン、ログ、バックアップを使用可能な形式でエクスポートできますか？Global Cloud は有料のオーバーラップウィンドウを提供しますか？顧客の IP アドレスを移動できますか、それとも DNS 名のみですか？これらの質問に答える適切な時期は、サービスが重要になる前です。
このタイプのプロバイダーが失敗した場合、誰が影響を受けるか
影響を受けるユーザーは、抽象的なハイパースケール顧客である可能性は低いです。Global Cloud のウェブサイトは、統合、仮想デスクトップ、ソフトウェアシステム、テレフォニー、コラボレーション、ホスティング、マネージド IT を必要とする企業に語りかけています。これは、中小企業、コールセンター、開発チーム、小売業者、専門サービス企業、および独自のインフラストラクチャを運用したくない地域のビジネスを指します。これらの顧客にとって、プロバイダーは単なるベンダーではありません。従業員が毎朝ログインし、アプリケーションが実行され、バックアップが保存され、テレフォニーとコラボレーションツールがアイデンティティとネットワークアクセスに依存する場所かもしれません。
したがって、障害の運用上の影響はサービスに依存します。ウェブホスティングの顧客は、公開された利用不能と DNS 変更に直面する可能性があります。DaaS 顧客は従業員の作業セッションを失う可能性があります。マネージドアプリケーションの顧客はビジネスプロセスの継続性を失う可能性があります。テレフォニー顧客はコールルーティングを失う可能性があります。IaaS 顧客はサーバー復旧、ストレージ整合性、ファイアウォール再構築に直面する可能性があります。ソフトウェアサービスの顧客はデータエクスポートとライセンスの問題に直面する可能性があります。
これが、Global Cloud の広範なサービスカタログがデューデリジェンスの負担を増加させる理由です。静的ウェブホスティングのみを販売するプロバイダーは、単一のチェックセットで評価できます。データセンター、クラウド、デスクトップ、プラットフォーム、ソフトウェア、コラボレーション、IT サービスを販売するプロバイダーは、サービスごとのリスクマップを必要とします。同じ AS61365 エッジが複数の製品に関連する可能性がありますが、各製品には異なる状態、復旧、移行要件があります。
影響はデータの機密性によっても異なります。従業員記録、健康関連情報、財務記録、または欧州の個人データを扱う顧客は、公開ブローシャーサイトを運営する顧客よりも検証すべきことが多くなります。前述のイスラエルの公式プライバシー文書は、データベースセキュリティと国境を越えたデータ処理が規制されたトピックであることを明確にしています。バイヤーは、責任の分割（どの当事者が管理者または処理者か、誰がアクセスを管理するか、バックアップがどのように保護されるか、インシデントがどのように通知されるか、データがどこに転送されるか）を文書化するよう要求すべきです。
Global Cloud は、地域のサポートとイスラエルのルーティングを求める顧客にとって便利な地域プロバイダーになり得ます。公開証拠はその可能性を支持しています。しかし、プロバイダーが事業継続の単一障害点になる前に障害経路をテストする必要性を排除するものではありません。
何がエビデンスレベルを改善するか
現在の公開証拠は中程度のレベルに値します。ネットワークリソース層は強い一方、サービス容量層は文書化が不十分だからです。Global Cloud がいくつかのタイプの検証可能な運用証拠を公開または提供すれば、レベルは改善されるでしょう。
第一に、現在の施設とプラットフォームの概要を提供できます。これは機密性の高いフロアプランを公開する必要はありません。プライマリサイトとセカンダリサイト、サイトが所有かコロケーションか、地理的および電力ドメイン的に独立しているか、どのサービスがどこで実行されているか、バックアップがどのように分離されているかを特定すべきです。複数のデータセンターと災害復旧に関するウェブサイトの主張は、現在のサイトの役割とサービス種類と一致すれば、はるかに説得力を持つでしょう。
第二に、現在のルーティングとトランジットの概要を提供できます。AS1680 と AS212616 は BGP で可視であり、AS8551 はポリシーにあります。プロバイダーは、どれがアクティブ、スタンバイ、または履歴か、各 /24 がアクティブな経路多様性を持っているか、フェイルオーバーがテストされているか、顧客がメンテナンス中に何を期待すべきかを述べることができます。また、PeeringDB プロファイルを公開することもできます。研究時点でのASN 61365 の PeeringDB API クエリは 404 エンティティ未検出応答を返し、公開 PeeringDB ネットワークプロファイルがその API クエリを通じて利用できなかったことを意味します。PeeringDB は任意であるため、不在は不在の証拠ではありません。それでも、相互接続、施設、連絡先情報の開示機会を逃しています。
第三に、各製品のバックアップと復旧目標を文書化できます。DaaS、IaaS、ホスティング、ソフトウェア、テレフォニーは、単一の一般的なバックアップの約束を共有すべきではありません。それぞれに、最後にテストされた復旧日、復旧時間目標、復旧ポイント目標、除外事項、顧客の責任があってしかるべきです。復旧が顧客が購入したバックアップオプションに依存する場合、それは明確でなければなりません。
第四に、移行権利を文書化できます。ホスト型サービスへの信頼は、顧客がどのように離脱できるかを知っているときに向上します。エクスポート形式、DNS および IP 移行ウィンドウ、イメージポータビリティ、データベース抽出、プロファイルエクスポート、メールエクスポート、テレフォニー設定エクスポート、ログ保存期間は、紛争や障害の前に明確にすべきです。
第五に、公開サービスの文言を整理し、統一できます。英語のサービスページは使用可能ですが、Global Cloud と Xpress Technologies の表記の混在、スペルミス、部分的に翻訳されたコンテンツにより、第三者がどの主張が現在有効かを知ることが難しくなっています。よりクリーンなサービスカタログは回復力を証明しませんが、曖昧さを減らします。
これらの改善は表面的なものではありません。信頼できるルーティングフットプリントを、より検証可能な顧客依存関係に変えるでしょう。
バイヤーの実践的な質問
Global Cloud を検討している顧客は、すでに良好な事実から始めるべきです。同社に、AS61365 と 185.184.16.0/22 が購入したサービスの現在のプロダクションエッジであることを確認するよう依頼してください。185.184.16.0/24、185.184.17.0/24、185.184.18.0/24、185.184.19.0/24 のうちどれがサービスに使用されているかを尋ねてください。RPKI ROA が引き続き有効かどうか、経路変更を誰が承認するかを尋ねてください。経路エンティティと IRR の状態がすべてのトランジットプロバイダーフィルターにとって十分かどうかを尋ねてください。
次に、物理的な質問をしてください。プライマリサービスはどこでホストされていますか？ラック、ケージ、データホールは所有、リース、または下請けですか？どのような電力供給、UPS、発電機、冷却システム、リモートハンドプロセスが関与していますか？サイトにはどのようなスペアパーツがありますか？時間外に入室できるのは誰ですか？どのサービスが同じ建物を共有し、どれが分離されていますか？
次に、ネットワークの質問をしてください。現在、どのトランジットプロバイダーがプロダクショントラフィックを運んでいますか？どれがスタンバイですか？AS1680 または AS212616 は単独で全負荷をサポートできますか？AS8551 の現在の役割は何ですか？別個のルーターと相互接続はありますか？アンチ DDoS 制御はキャリア固有ですか？BGP 変更はピアレビューおよびテストされていますか？
次に、サポートの質問をしてください。24/7 は実際には何を意味しますか？電話サポート、エンジニア対応、監視、緊急変更、顧客コミュニケーションをカバーしていますか？公的な営業時間の電話回線が閉鎖されている金曜日または土曜日には何が起こりますか？プロバイダー自身のネットワークがダウンしている場合の帯域外連絡先経路は何ですか？
次に、データの質問をしてください。プライマリデータ、バックアップ、ログ、サポートチケットデータはどこにありますか？アイデンティティ、メール、監視、またはコラボレーションデータを処理するプラットフォームはどれですか？顧客が満たさなければならない規制はどれで、Global Cloud はどのような証拠を提供できますか？バックアップはどのように暗号化、復旧、削除されますか？
最後に、出口の質問をしてください。顧客はシステム、データ、設定をどのようにエクスポートできますか？IP アドレスを保持できますか、それともリナンバリングする必要がありますか？オーバーラップウィンドウはどのくらいですか？どのような支援が含まれていますか？請求紛争、サービスインシデント、またはサプライヤー変更後に終了した場合はどうなりますか？
これらの質問は、Global Cloud が弱いと仮定するものではありません。ホスト型容量は、クラウドとして販売される場合でも、物理的、契約的、運用可能であると仮定しています。
結論：信頼できるネットワーク、不完全な復旧可能性の証明
Global Cloud Ltd は、薄い資料のフットプリントの仮定よりも公開記録においてはるかに実質的です。同社は RIPE LIR 組織エンティティ、アクティブな AS、明確な IPv4 割り当て、現在可視の4つの /24 アナウンス、有効な RPKI 経路起点カバレッジ、イスラエルの地域性シグナル、クラウド、ホスティング、デスクトップ、ソフトウェア、コラボレーション、マネージド IT に関する正式なサービスカタログを持っています。これは、信頼できるインフラストラクチャ企業の主題を確立するのに十分です。
残る不確実性は、名前の存在についてではありません。その名前の背後にどれだけの復旧可能なサービスがあるかです。公開データは、ラック数、サイト数、サーバー数、ストレージシステム数、サポートエンジニア数、フェイルオーバーテスト数、顧客ワークロード数を証明しません。広範なサービスカタログが Global Cloud 所有のインフラストラクチャ、コロケーションインフラストラクチャ、パートナープラットフォーム、またはそれらの混合から提供されているかどうかを証明しません。顧客がストレス下でクリーンに移行できるかどうかを証明しません。
これが、この記事のタイトルが意図的に物理的である理由です。Global Cloud はホスト型容量を販売していますが、その容量の価値は依然としてラック、トランジット、修理ウィンドウに依存しています。AS61365 は可視でありながら、顧客が依然として復旧問題に直面する可能性があります。/22 は適切に登録されていても、バイヤーがまだ予備ハードウェアの証明を必要とする可能性があります。有効な ROA は起点検証を保護できますが、トランジットプロバイダーのインシデントがフェイルオーバーをテストする可能性があります。24/7 サポートの主張は真実であり得ますが、顧客が依然としてエスカレーション詳細を必要とする可能性があります。
Global Cloud またはその顧客が施設の独立性、経路フェイルオーバー、サポートエスカレーション、バックアップ復旧、移行権利を検証できるまで、エビデンスレベルは中程度に留まるべきです。公開ネットワーク層は現実的で比較的よく文書化されています。サービス回復力層はデューデリジェンスタスクのままです。