ZEROSPACE Christian Wittenberg trading as Zerospace Cloud は、依然としてラック、トランジット、修理ウィンドウに依存するホスティング容量を販売している

概況

• RIPE RDAP はAS201801を ZEROSPACE として識別し、オランダのフェルドホーフェンにある Christian Wittenberg trading as Zerospace Cloud に関連付けています。RIPEstat のAS 概要は、この AS が2026年7月15日にアナウンスされたと報告しています。
• ルーティングされた規模は小さいが可視的です。ルーティングステータスは1つの IPv4 プレフィックス、256の IPv4 アドレス、8つの IPv6 /48、および2つの観測されたネイバーを示し、アナウンスされたプレフィックスは185.140.53.0/24に加えて8つの可視の IPv6 /48をリストしています。
• ルートオリジンの衛生状態は強みです。RIPEstat は185.140.53.0/24および2a07:1a84::/48に対して有効な RPKI を返しました。IPv6 検証は2a07:1a84::/44上の ROA と最大長/48に依存しています。
• 運用の証明は弱いです。PeeringDBは Zerospace Cloud をリストしていますが、公開 IX 数とファシリティ数はゼロです。ジオフィードは10のメトロラベルにアドレススライスをマッピングしていますが、それらのメトロ内のローカルラック、電力、ハードウェア、サポート、または顧客移行能力を証明していません。

同社は実際のネットワークアイデンティティを持つが、そのアイデンティティは新しい

ノイズから分離する価値がある最初の事実は、Zerospace Cloud が単なるマーケティングフレーズではないということです。RIPE RDAP（https://rdap.db.ripe.net/autnum/201801）は AS201801 を ZEROSPACE として登録し、ステータスはアクティブ、登録イベントは2026年1月30日、最終変更は2026年3月13日です。同じ RDAP 応答の組織エンティティは Christian Wittenberg trading as Zerospace Cloud で、公開住所ラベルはオランダのフェルドホーフェンです。RDAP 応答はまた、管理連絡先および技術連絡先として Zerospace Cloud Network Operations を、不正使用連絡先として Zerospace Cloud Abuse Department を挙げています。小規模なクラウドまたはホスティングプロバイダーにとって、これは有用なベースラインです。名前のある組織、名前のあるネットワーク、名前のある運用連絡先の役割があります。

アドレスレコードは AS アイデンティティと一致しています。RIPE RDAP（https://rdap.db.ripe.net/ip/185.140.53.0/24）は185.140.53.0〜185.140.53.255を ZEROSPACE-CLOUD として識別し、割り当て PA、国 NL、ステータスアクティブ、注釈はhttp://download.zerospace.cloud/ipam/geofeed.csvのジオフィードを指しています。RIPE RDAP（https://rdap.db.ripe.net/ip/2a07:1a84::/44）は2a07:1a84::/44を ZEROCLOUD として識別し、LIR によって集約され、国 NL、ステータスアクティブ、同じ組織と同じジオフィード参照があります。RIPEstat のプレフィックス概要（https://stat.ripe.net/data/prefix-overview/data.json?resource=185.140.53.0/24）は AS201801 を IPv4 /24のオリジンホルダーとして識別しています。

これらの記録は成熟したホスティング環境を証明するものではありません。現在のルートホルダーがライブの登録リソースを持っていることを証明しているだけです。年数が重要です。自律システムと IPv6 アグリゲートは2026年1月下旬に登録され、IPv4 /24は2026年2月に登録されました。これは、顧客が公開運用証拠をまだ形成中として扱うべきほど最近です。新しいインフラプロバイダーは有能である可能性があります。また、ルーティング、ブランディング、サポートプロセス、物理サプライヤー契約がまだ強化されている段階にある可能性もあります。正しい質問は、AS201801 が存在するかどうかではありません。存在します。正しい質問は、その上にどの顧客サービスを安全に配置できるかです。

公開ルートシグナルはライブです。RIPEstat の AS 概要（https://stat.ripe.net/data/as-overview/data.json?resource=AS201801）は、ホルダーを ZEROSPACE Christian Wittenberg trading as Zerospace Cloud として報告し、AS は2026年7月15日のクエリでアナウンスされました。RIPEstat ルーティングステータス（https://stat.ripe.net/data/routing-status/data.json?resource=AS201801）は広範な公開可視性を報告しました。326の IPv4 RIS ピアのうち324、322の IPv6 RIS ピアのうち322がルーティングされたスペースを見ていました。これは未使用の登録の署名ではありません。これはグローバルルーティングシステムに見える小さなネットワークの署名です。

インフラ購入者にとって、ライブルート可視性は必要十分条件ではありません。プロバイダーは/24といくつかの IPv6 /48をルーティングしながら、リースされた仮想サーバー、リセラーのコロケーション、単一のリモートハンドサプライヤー、または少数のアップストリームに依存することができます。ルートはパケットがアナウンスされたプレフィックスを見つけられることを示します。ドライブ障害後に交換用ハードウェアを入手できること、時間的制約のある大規模データセットをエクスポートできること、ストレージ障害から回復できること、または電力インシデントを修正する権限を持つ人間に連絡できることを示すものではありません。ホスティング容量は、プレフィックスの背後にラック、電力、冷却、ハードウェア在庫、アクセス手順、サポートカバレッジ、出口パスがある場合にのみ、ルート可視性をサービスに変えます。

ルーティングされた環境は小さく、可視的で、不均一にアドバタイズされている

IPv4 の状況はコンパクトです。RIPEstat のアナウンスされたプレフィックスデータ（https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS201801）は、2026年7月1日から7月15日までのウィンドウで185.140.53.0/24が継続的にアナウンスされていることを示しました。ルーティングステータスはそれを1つの IPv4 プレフィックスと256の IPv4 アドレスとしてカウントしました。ホスティングまたはクラウドサービスにとって、/24は運用上有用ですが、小規模です。焦点を絞ったエニーキャストのようなサービス、NAT ゲートウェイ、顧客管理エンドポイント、一連の VPS ノード、または限られた数の直接割り当て顧客アドレスをサポートできます。それ自体は大規模なコンピュート環境の証拠ではありません。

IPv6 の状況はアドレス計算でより広範で、現在の可視性でよりニュアンスがあります。RDAP レコードは2a07:1a84::/44をカバーし、16の可能な/48を含んでいます。PeeringDB のネットワークオブジェクト（https://www.peeringdb.com/api/net?asn=201801）は、プロファイルに1つの IPv4 プレフィックスと16の IPv6 プレフィックスをリストしています。ただし、RIPEstat のアナウンスされたプレフィックスエンドポイントは、レビューウィンドウ中に8つの IPv6 /48が可視であることを示しました：2a07:1a84::/48、:1::/48、:2::/48、:3::/48、:4::/48、:5::/48、:6::/48、:9::/48。RIPEstat の AS ルーティング一貫性ビュー（https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS201801）は、2a07:1a84::/44が whois にあるが BGP にはない一方、いくつかの/48は whois と BGP の両方にあり、他のいくつかの/48は whois にあるが BGP にはないという有用な詳細を追加しました。

その違いは、インストール済み容量と使用可能容量にとって重要です。インストール済みアドレス容量は登録された IPv6 /44と PeeringDB の16の IPv6 プレフィックスの表明です。使用可能ルーティング容量は、関連期間中に実際に BGP で可視なサブセットです。顧客使用可能容量はさらに狭くなります。顧客が契約でき、既知のサイトを通じてルーティングでき、RPKI で保護でき、監視でき、サポートでき、プロバイダー、ファシリティ、またはアップストリームが失敗した場合に移動できるプレフィックスです。/44は紙上では大きく見えますが、選択された/48のみが公開ルーティングでアクティブであり、さらに小さなサブセットのみが本番サービスに結びついています。

IPv6 のタイミングも、活発に変化しているネットワークを示しています。RIPEstat は2a07:1a84::/48と2a07:1a84:5::/48が7月初めから可視であり、:5::/48は7月3日から5日までの短いギャップを示しました。他のいくつかの/48は2026年7月12日に可視性を開始しました。これは顧客に影響を与える意味での不安定性を証明するものではありません。新しい IPv6 ロケーションやサービスノードはしばしば波のようにオンラインになります。これは顧客が、どの/48が本番と見なされるか、どの/48がテストまたはステージング割り当てか、どの/48が都市ラベルに結びついているか、どの/48がテスト済みのフェイルオーバーを持つかを尋ねるべきであることを意味します。

ルートオリジン検証は Zerospace 記録のより良い部分の一つです。RIPEstat は185.140.53.0/24（https://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=185.140.53.0/24）に対して有効状態を返し、オリジン AS201801、最大長/24です。2a07:1a84::/48（https://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=2a07:1a84::/48）に対しても有効状態を返し、2a07:1a84::/44上の ROA に対して最大長/48で検証しています。RPKI はサーバーを稼働させ続けるわけではありませんが、ルートフィルターが許可されたオリジンアナウンスを許可されていないものから区別する方法を提供します。新しい小規模ネットワークにとって、この衛生状態は重要です。

アップストリームの状況は可視的だが、ファシリティの状況はそうではない

アップストリーム記録はファシリティ記録よりも明確です。RIPEstat AS ネイバー（https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS201801）は2つの観測されたネイバーを示しました：AS57758 と AS63473。RIPEstat の AS 概要は AS57758 を CBWS Holding B.V.、AS63473 を HostHatch, LLC として識別します。whois ビュー（https://stat.ripe.net/data/whois/data.json?resource=AS201801）はまた、AS20473、AS63473、AS57758 のインポートおよびエクスポートポリシーエントリをリストしていますが、公開ネイバー観測はチェック時に AS57758 と AS63473 を示しました。AS20473 は RIPEstat の AS 概要で The Constant Company, LLC であり、AS 名で Vultr と一般的に関連付けられています。

これは依存関係の表面を説明するには十分ですが、多様性を認証するには十分ではありません。2つの観測されたネイバーは、顧客のサービスパスで実際に独立しており、別々のファシリティまたは障害ドメインに存在し、顧客のプレフィックスに対して両方が設定されている場合、1つより優れています。ただし、2つの ASN が同じ建物、同じミートミールーム、同じメトロファイバー、同じ電力イベント、または同じリモートメンテナンスウィンドウを共有する可能性があります。公開 BGP データは、Zerospace ルーターが1つのラックにあるのか複数のサイトにあるのかを教えてくれません。両方のネイバーがすべての本番プレフィックスを運んでいるかどうか、フェイルオーバーが自動かどうか、一方のネイバーがバックアップのみかどうか、顧客コントロールプレーンが同じ物理ハンドオフに依存しているかどうかを教えてくれません。

PeeringDB はその注意を深めます。Zerospace Cloud ネットワークレコード（https://www.peeringdb.com/api/net?asn=201801）は AS201801、ウェブサイトhttps://zerospace.cloud、IRR as-set AS201801:AS-ZEROSPACE-CLOUD、1つの IPv4 プレフィックス、16の IPv6 プレフィックス、ポリシー_general Open、ステータス ok、2022年10月の作成タイムスタンプと2026年2月8日の更新タイムスタンプをリストしています。ただし、PeeringDB のエクスチェンジ LAN エンドポイント（https://www.peeringdb.com/api/netixlan?asn=201801）は公開 IX LAN 行を返さず、そのファシリティエンドポイント（https://www.peeringdb.com/api/netfac?net_id=31374）は公開ファシリティ行を返しませんでした。PeeringDB はオペレーター維持であり不完全である可能性があるため、空のファシリティリストはファシリティ存在の欠如の証明ではありません。それは公開ファシリティ証明が欠如していることの証明です。

クラウド購入者にとって、ファシリティ証明の欠如は小さな詳細ではありません。ファシリティはルートの約束が運用の約束になるところです。顧客は、どのデータセンターがサーバーを収容しているか、どのエンティティがラックを契約しているか、どのリモートハンドチームがハードウェアに触れることができるか、冗長電源フィードがあるかどうか、キャビネットが契約電力制限内にあるかどうか、冷却がどのように供給されるか、どのクロスコネクトがどのアップストリームに到達するかを知る必要があります。公開ファシリティリストまたはファーストパーティのファシリティ声明なしでは、顧客は直接尋ね、契約上確認する必要があります。

これは、ジオフィードがグローバルである一方で可視の公開ファシリティ証拠が空であるため、Zerospace に特に当てはまります。ジオフィードはコンテンツローカリゼーション、不正対策、レイテンシルーティング、顧客期待に有用です。ファシリティ声明を置き換えることはできません。プロバイダーは、VM、トンネルエンドポイント、リセラーノード、クラウドインスタンス、またはパートナー展開があるため、小さなアドレスブロックを都市に地理的に配置する場合があります。それは所有ラック、スペアサーバー、スペアオプティクス、アウトオブバンド管理、バッテリーランタイム、発電機カバレッジ、またはローカルサポートを証明するものではありません。

ジオフィードは都市ラベルを記述するが、保証されたローカルインフラではない

https://download.zerospace.cloud/ipam/geofeed.csvのジオフィードは、Zerospace 記録の中で最も情報量の多い公開アーティファクトの1つです。185.140.53.0/29をアムステルダムに、185.140.53.8/29をロンドンに、185.140.53.16/29をストックホルムに、185.140.53.24/29をソウルに、185.140.53.32/29をシンガポールに、185.140.53.40/29を香港に、185.140.53.48〜185.140.53.55の選択された/32を東京に、185.140.53.56/29をシドニーに、185.140.53.64/29をニューヨークに、185.140.53.72/29をロサンゼルスにマッピングしています。IPv6 /48を同じ都市パターンにマッピングしています：2a07:1a84::/48をアムステルダムに、:1::/48をロンドンに、:2::/48をストックホルムに、:3::/48をソウルに、:4::/48をシンガポールに、:5::/48を香港に、:6::/48を東京に、:7::/48をシドニーに、:8::/48をニューヨークに、:9::/48をロサンゼルスに。

これはグローバルサービスエリアシグナルであり、グローバル容量証明ではありません。IPv4 では、ほとんどの都市エントリは/29で、それぞれ8アドレスです。東京の IPv4 エントリは個別の/32または非常に小さなグループであり、ジオフィードは/24のすべてのアドレスを明示的な名前の都市でカバーしていません。RIPEstat のジオロケーション（https://stat.ripe.net/data/geoloc/data.json?resource=185.140.53.0/24）および MaxMind GeoLite ビュー（https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=185.140.53.0/24）は同様の広がりを反映していましたが、IPv4 /24の大部分がクエリビューで都市なしのスウェーデンとして表示されることも示しました。これは、公開ジオロケーション画像が混在していることを意味します。一部のアドレススライスは正確な都市ラベルを持ちます。IPv4 アドレス空間の多くは詳細な都市別コンピュートマップとしては表示されません。

IPv6 のロケーションビューも注意深く読む必要があります。RIPEstat の2a07:1a84::/44のジオロケーション（https://stat.ripe.net/data/geoloc/data.json?resource=2a07:1a84::/44）および MaxMind GeoLite ビュー（https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=2a07:1a84::/44）は、/44がいくつかの都市ラベル付き/48に分割され、アグリゲートの大部分が都市なしのスウェーデンとして表示されることを示しました。ジオフィードは:7::/48をシドニーに、:8::/48をニューヨークにリストしていますが、アナウンスされたプレフィックスエンドポイントはこのレビューウィンドウ中にそれらの/48を8つの可視プレフィックスの中に表示しませんでした。これは必ずしも矛盾ではありません。ジオフィードエントリは意図されたまたは登録された局所性を記述することができ、ルーティング可視性は時間とともに変化します。それは、局所性の主張を現在のルート状態に結び付ける必要があるというリマインダーです。

この区別の影響を受ける顧客は、それらの都市のエンドユーザーだけではありません。小規模クラウドプロバイダーは、VPN ゲートウェイ、エッジノード、マネージドホスティング、開発者ワークロード、バックアップターゲット、ゲームインフラ、テスト環境、小規模ビジネスサービス、または地域アクセスポイントを提供している可能性があります。アムステルダムラベルのスライスが失敗した場合、欧州の顧客はレイテンシと法的ロケーションを気にするかもしれません。香港またはシンガポールのスライスが失敗した場合、アジア太平洋のユーザーはより高いレイテンシまたは別のリージョンへのフェイルオーバーを見るかもしれません。ニューヨークまたはロサンゼルスのスライスが現在ルーティングされていない場合、北米展開を計画している顧客は、そのロケーションがライブか、予約済みか、一時停止中か、保留中かを知る必要があります。

したがって、正しいデューデリジェンスの質問は「ジオフィードは私の都市に言及していますか？」ではありません。それは「私の都市ラベルのアドレスを提供する物理的または仮想的なサイトはどれか、誰がそのサイトを運営しているか、どのアップストリームがそれを運んでいるか、背後にどの電力とハードウェアがあるか、どのように復旧または移行されるか？」です。都市ラベルは顧客が何を尋ねるかを決めるのに役立ちます。Zerospace が10の都市すべてに所有インフラを持っていることの証拠として使用されるべきではありません。

ウェブサイトと DNS レコードは別の可用性依存関係を明らかにする

メインウェブサイトも顧客インフラから分離して考える必要があります。RIPEstat の DNS チェーンエンドポイント（https://stat.ripe.net/data/dns-chain/data.json?resource=zerospace.cloud）は、zerospace.cloud が Cloudflare の権威ネームサーバー（ali.ns.cloudflare.com および rudy.ns.cloudflare.com）を使用し、A レコード172.67.142.47および104.21.87.70、AAAA レコード2606:4700:3035::ac43:8e2f および2606:4700:3036::6815:5746を2026年7月15日のクエリ時に示しました。https://stat.ripe.net/data/dns-chain/data.json?resource=download.zerospace.cloudの DNS チェーンエンドポイントは、ダウンロードホストに対して同じ Cloudflare フロントエンドアドレスを示しました。https://stat.ripe.net/data/dns-chain/data.json?resource=www.zerospace.cloudのエンドポイントは Cloudflare 権威ネームサーバーを返しましたが、www.zerospace.cloudの転送レコードはありませんでした。

2026年7月15日の直接 HTTPS チェック中、https://zerospace.cloudはこの環境から15秒の curl タイムアウト内で使用可能なページを返しませんでした。以前の Cloudflare フロントエンドチェックは、オリジンが Cloudflare に応答しない場合に522スタイルのオリジン到達可能性障害を表面化させる可能性があります。単一の一時的な HTTP 結果に依存しなくても、DNS 証拠は公開ウェブサイトパスが Cloudflare を介していることを示しています。これは一般的でしばしば賢明です。また、ウェブサイトの可用性は AS201801 のルート可用性と同じではないことを意味します。

ここには2つの別々の依存関係があります。第一に、Zerospace のマーケティングまたは制御ウェブプレゼンスは、Cloudflare DNS とプロキシ、および Cloudflare の背後にあるオリジンサービスに依存しています。第二に、Zerospace のルーティングされた顧客プレフィックスは、AS201801、そのアップストリームネイバー、およびそれらのプレフィックスを運ぶ物理的または仮想的なロケーションに依存しています。購入者は、ウェブサイトが Cloudflare の背後にあるからといって、顧客トラフィックが Cloudflare の背後にあると推測すべきではありません。また、AS201801 が BGP で可視であるからといって、カスタマーポータル、ドキュメント、ステータス通知、サポートパスがウェブサイトオリジン障害中も到達可能であり続けると推測すべきではありません。

ダウンロードホストは、チェック中にプライマリサイトが読み取り可能な公開サービスページではなかったにもかかわらず、ジオフィードを提供したため、興味深いです。これは、いくつかの Cloudflare フロントエンドパスは到達可能であるが、他はそうではないことを示唆しています。顧客運用にとって、重要なポータル、サポートフォーム、コントロールパネル、ステータスページ、ジオフィード、API エンドポイントが独立してホストされているか、同じオリジン依存関係を共有しているかが問題です。顧客サポートルートが脆弱なオリジンの背後にあるウェブフォームだけである場合、ネットワークまたはオリジン障害は、BGP ルートが稼働していても復旧を遅らせる可能性があります。

ウェブサイト証拠はまた、外部者が利用できるファーストパーティのサービス詳細の量を減らします。多くのプロバイダーは、ファシリティページ、製品条件、サービスレベル目標、サポート手順、データエクスポート条件、バックアップポリシー、法的文書をサイトに公開しています。メインサイトが確実に読み取れない場合、公開デューデリジェンスはレジストリとルーティング証拠により多く依存する必要があります。それはネットワークアイデンティティの記事には十分です。自信を持ったホスティング容量の購入には十分ではありません。

物理的依存関係のほとんどはネットワーク層の背後に隠れている

Zerospace の公開記録はルートリソースを提供しますが、完全な物理マップは提供しません。AS201801 の公開 PeeringDB ファシリティ行はありません。このレビューではメインウェブサイトから入手可能な公開ファシリティページはありません。公開されたキャビネットリスト、電力密度声明、冷却設計、リモートハンドプロバイダー、ハードウェア在庫ポリシー、バックアップアーキテクチャ、ステータスページ、または移行ガイドは、ここで入手可能な証拠にはありません。それらが存在しないという意味ではありません。それらが公に証明されていないという意味です。

顧客の物理的依存関係スタックは依然として具体的です。Zerospace がホスティング容量を販売する場合、何らかのサーバーまたは仮想インスタンスがどこかに存在する必要があります。そのどこかには、ラックまたはホストマシン、電源、冷却パス、管理ネットワーク、アップストリームポート、ストレージ依存関係、アクセスプロセスがあります。ディスクが故障した場合、誰かまたは何らかの自動化がワークロードを交換または移動する必要があります。ルーターが故障した場合、セカンドパスがプレフィックスを運ぶ必要があります。キャビネットブレーカーが落ちた場合、そのキャビネットの計画が必要です。ファシリティにメンテナンスウィンドウがある場合、プロバイダーはどの顧客サービスが影響を受けるかを知っている必要があります。都市ラベルのアドレスが実際にはより大きなクラウドリージョン内の仮想エンドポイントである場合、顧客もそれを知るべきです。

電力と冷却は Zerospace 記録の最も可視性の低い部分です。/24と/44は、非常に少ない物理インフラ、レンタル仮想マシン、パートナーホスト、または少数のコロケーションサーバーからアナウンスできます。したがって、IP アドレスの数は電力ヘッドルームについてほとんど何も言いません。顧客は、インストール済み電力割り当て、冗長性後の使用可能電力、ラックあたりの冷却密度、ファシリティの UPS および発電機の前提条件、単一の高密度展開がプロバイダーのローカルマージンを枯渇させる可能性があるかどうかを知る必要があります。その情報がなければ、購入者は都市エッジノードと回復力のあるホスティングリージョンを区別できません。

ハードウェア在庫も同様に不透明です。プロバイダーはアドレスをグローバルにルーティングできますが、限られたホストプールに依存する可能性があります。Zerospace が VPS またはマネージドサービスを提供する場合、購入者は各ロケーションの背後にいくつの本番ホストがあるか、ストレージがローカルか共有か、障害がどのように退避されるか、同じロケーションにスペアノードが存在するか、交換容量をサードパーティホストから注文する必要があるかを尋ねるべきです。小さい IPv4 割り当ては効率的なアドレス使用を意味します。また、公開 IP の不足が移行および拡張計画に影響を与える可能性があることも意味します。

サポートはネットワーク連絡先レベルでのみ可視です。RDAP はネットワーク運用および不正使用の役割を指定しており、これはルート運用および不正使用処理にとって重要です。顧客サポート時間、エスカレーションレベル、インシデント対応目標、有料サポートティア、言語、チケットツール、緊急権限を示すものではありません。インフラ容量を購入する顧客は、ネットワーク連絡先の存在をフロアと見なし、サポートの約束とは見なすべきではありません。本当の復旧質問は、ルーターセッションがダウンしたとき、ホストが故障したとき、都市エンドポイントが消えたとき、顧客が短期間でデータを退避する必要があるときに誰が行動できるかです。

障害パス：ルート、アップストリーム、ファシリティ、サポート、移行

最初の障害パスはアップストリーム到達可能性です。AS201801 には RIPEstat で2つの観測されたネイバー（AS57758 および AS63473）があり、whois ポリシーリストは AS20473 も指定しています。AS57758 または AS63473 がセッションを失った場合、結果は両方のネイバーが影響を受けるプレフィックスを運んでいるかどうか、トラフィックエンジニアリングがリターンパスに十分に対称的かどうか、障害が1つのアップストリームに隔離されているかどうかに依存します。両方のセッションが同じサイトで終了するか、同じローカルハンドオフに依存する場合、冗長性は AS カウントが示唆するほど有用でない可能性があります。顧客は、各本番プレフィックスを運ぶアップストリームとそれらのセッションがどこにあるかを示すルート図を要求すべきです。

2番目の障害パスはルート認証またはフィルタリングです。RPKI は IPv4 /24および IPv6 /44-to-/48 パターンに対して有効であり、これは良いことです。ただし、顧客は Zerospace がルートリーク、無効なアナウンス、最大長の間違い、ジオロケーションドリフトを監視しているかどうかを尋ねるべきです。有効な ROA は、プロバイダーが後で最大長を超えるより具体的なルートをアナウンスした場合、アップストリームが予期せずフィルタリングした場合、または一致するルート認証なしに都市固有の/48が追加された場合、運用上苦痛になる可能性があります。現在の RPKI 状態はポジティブなコントロールです。変更管理の代わりにはなりません。

3番目の障害パスはファシリティの喪失または隠れたファシリティ集中です。PeeringDB は公開ファシリティ行をゼロとリストするため、顧客は複数の都市が複数のファシリティ、1つのアップストリームオーバーレイ、またはリセラー環境を表すかどうかを独立して判断できません。アムステルダムラベルのアドレスとロンドンラベルのアドレスが両方とも1つのプロバイダーアカウント、1つの請求関係、1つのリモートサポートチーム、または1つのトンネルコンセントレーターに依存している場合、そのプロバイダー関係の障害が複数の見かけのリージョンに影響を与える可能性があります。マルチシティジオフィードエントリは、独立したファシリティ、サプライヤー、ルーティング証拠に対して検証されるべきです。

4番目の障害パスは制御およびサポートプレーンです。プライマリドメインの Cloudflare フロントエンド DNS、空の www レコード、およびチェック中の利用不可のメインサイトはすべて、障害中に顧客がサポートに到達する方法を知ることの重要性を指しています。カスタマーポータル、ステータス通知、ドキュメント、サポートフォームが脆弱なオリジンを共有する場合、プロバイダーはネットワーク問題がまだ展開している間に通信を失う可能性があります。インフラ復旧はコンタクトパスにパケットと同じくらい依存します。購入者は、ウェブフォームだけでなく、帯域外のインシデント連絡先を要求すべきです。

5番目の障害パスは移行です。新しいネットワークは変化します。Zerospace の2026年の登録日、2026年7月の IPv6 可視性の変化、都市ジオフィードレイアウトは、まだ拡大または調整中のプラットフォームを示唆しています。それは有望である可能性がありますが、出口権と移行パスを不可欠にします。顧客は、ディスクイメージ、スナップショット、データベースダンプ、ログ、DNS レコードをエクスポートできるかどうか、移動中に IPv4 アドレスを保持できるかどうか、IPv6 /48割り当てが Zerospace ロケーション内で移植可能かどうか、データエクスポートにかかる時間、ロケーションが廃止または再ルーティングされた場合の対処を知る必要があります。

インストール済み容量、使用可能容量、購入容量は異なる概念

Zerospace の証拠は、クラウド容量に3つの層がある理由の有用な例です。インストール済み容量は、プロバイダーが所有または制御すると主張できるものです：AS201801、185.140.53.0/24、2a07:1a84::/44、登録ルートポリシー、PeeringDB プロファイル。使用可能ネットワーク容量は、公開ルーティングに現れ、有効なオリジン認証で到達できるものです：1つの IPv4 /24、レビューウィンドウで8つの可視 IPv6 /48、2つの観測されたネイバー、広範な RIPE RIS 可視性。購入容量は、顧客が実際に契約に基づいて消費できるものであり、コンピュート、ストレージ、帯域幅、サポート、移行条件が付随します。

これらの層の間の距離にリスクが隠れています。顧客は10のジオフィード都市を見て10の本番リージョンを想定するかもしれません。証拠はその想定をサポートしません。顧客は PeeringDB で16の IPv6 プレフィックスを見て、すべてがライブであると想定するかもしれません。RIPEstat はこのウィンドウ中に8つの可視/48を示し、whois リストされた/48の一部は BGP に存在しませんでした。顧客は2つの観測されたアップストリームネイバーを見てルート冗長性を想定するかもしれません。それは、2つのネイバーが顧客のプレフィックスと障害ドメインに対して独立している場合にのみ真実です。顧客は有効な RPKI を見て運用回復力を想定するかもしれません。RPKI はルートの信頼性を助けますが、サーバー修理は助けません。

これは Zerospace が使えないという意味ではありません。それは、狭い証拠モデルで購入されるべきプロバイダーであるということです。小さなルーティングサービス、IPv6 ラボ、エッジ実験、または重要でないホスティングエンドポイントを必要とする開発者は、商業条件がリスクに一致すれば、公開フットプリントが十分であると感じるかもしれません。本番ワークロード、顧客データ、決済関連システム、健康データ、または規制対象記録を移行する企業は、公開ルーティング証拠以上のものを要求すべきです。ファシリティ詳細、サポートコミットメント、バックアップ分離、顧客出口条件、購入している都市またはリージョンが実際にライブであることの証明を要求すべきです。

公開ファシリティ行の欠如はまた、冗長性証明の考え方を変えます。冗長性は都市名の数ではありません。それは、2つの障害が同じ原因を共有しないことの証明です。Zerospace の場合、その証明は少なくとも以下を示す必要があります：アップストリーム独立、ファシリティ独立、電力独立、ストレージまたはバックアップ独立、管理プレーン独立、サポートエスカレーション独立。これらのいずれかが欠けている場合、ラベル付けされた第2のリージョンは依然として最初のリージョンと共に失敗する可能性があります。

インストール済み対使用可能容量は価格にも影響します。小規模プロバイダーは柔軟で手頃で技術的に直接的であるため魅力的です。しかし、低コストのオファーは、より大きなクラウド購入者が想定するスペアパーツ、スタッフ時間、トランジットヘッドルーム、バックアップ保持を除外する場合があります。顧客は欠けている部分を明示的に価格設定すべきです。ワークロードが高速復旧を必要とする場合、顧客はその復旧に対して支払い、テストすべきです。ワークロードが公開エンドポイントのみを必要とし、他の場所で再構築できる場合、顧客はより軽いサービスを受け入れ、自身の移植性を維持できます。

データ局所性はジオフィードを通じて宣言されているが、法的および運用上の局所性は未解決のまま

ジオフィードはデータ局所性シグナルを提供しますが、データ主権契約ではありません。それはジオロケーションコンシューマーに Zerospace がアドレススライスをどのように解釈してほしいかを伝えます。ディスクがどこにあるか、バックアップがどこにあるか、どの会社がホストを運営しているか、サポートスタッフがどこにいるか、どの法律がサービスを統治するか、どの下請け業者が顧客データにアクセスできるかは述べていません。その区別は、アムステルダム、ロンドン、香港、東京、ニューヨークをコンプライアンスまたはレイテンシステートメントとして読む可能性のある欧州、アジア太平洋、北米の顧客にとって不可欠です。

欧州の顧客にとって、オランダの組織記録とアドレスレコードの国コード NL は有用ですが、すべての顧客データがオランダまたは欧州経済領域に残ることを証明するものではありません。ジオフィード自体はいくつかのスライスで欧州外を指しています。アジア太平洋の顧客にとって、ソウル、シンガポール、香港、東京、シドニーのラベルはレイテンシに有用かもしれませんが、顧客はデータがローカルで処理されているか、別の国を経由してプロキシされているか、他の場所にバックアップされているか、サードパーティのホスティングサプライヤーによって運営されているかを知る必要があります。米国の顧客にとって、ニューヨークとロサンゼルスのラベルは同じ質問を必要とします。

最も安全な読み方は、Zerospace がアドレスブロックに対してネットワーク局所性を宣言しており、データレジデンシー保証ではないということです。顧客は、ホスティングサプライヤーまたはファシリティクラスを指定し、顧客データとバックアップがどこにあるかを定義し、サポートアクセスロケーションを特定し、ログ、スナップショット、エクスポートがどのように処理されるかを説明するリージョン固有の条件を要求すべきです。サービスがネットワークオーバーレイまたは小さなエッジプレゼンスに過ぎない場合、契約はそれを明確に述べるべきです。Zerospace がローカル物理インフラを持っている場合、契約は運用境界を述べるべきです。

局所性は障害対応とも交差します。香港ラベルのアドレスが香港のパートナーによって提供されている場合、修復パスはそのパートナーのサポートキューに依存する可能性があります。グローバルクラウドプロバイダーからの仮想ノードによって提供されている場合、修復はそのプロバイダーアカウントとリージョンステータスに依存する可能性があります。別のロケーションからのトンネルを通じて提供されている場合、ジオフィードラベルはアプリケーションには有用かもしれませんが、物理的独立性には有用ではありません。これらのモデルのいずれも自動的に間違っていません。重要なのは開示です。顧客は都市名が実際に何を意味するかを知らない限り、都市名を中心に回復力を設計できません。

サービスが失敗した場合、誰が影響を受けるか

影響を受けるユーザーは、Zerospace が実際に何を販売しているかに依存します。公開証拠はクラウドまたはホスティングスタイルのネットワークアイデンティティをサポートしますが、ここで独立して読むことができる製品カタログを公開していません。それでも、依存関係クラスは明確です。ホスティングエンドポイント、VPS インスタンス、エッジノード、VPN ゲートウェイ、DNS 関連サービス、小規模ビジネスサイト、アプリケーションバックエンドに Zerospace を使用する顧客は、ルート撤回、アップストリーム障害、サーバー障害、ストレージ損失、サポート遅延、ウェブサイト制御障害の影響を受けるでしょう。

地域のエンドユーザーは最初にジオフィード層に気づくでしょう。アムステルダム、ロンドン、ストックホルム向けのトラフィックがより遠いロケーションにシフトした場合、レイテンシに敏感なアプリケーションは劣化する可能性があります。ソウル、シンガポール、香港、東京のスライスが利用できない場合、アジア太平洋のユーザーはより長いパスまたはサービス障害を見る可能性があります。ニューヨークまたはロサンゼルスのスライスが予想時にルーティングされていない場合、北米のユーザーは商業設計で約束された局所性を得られない可能性があります。したがって、ジオフィードマップは容量を証明しなくても期待を生み出します。

顧客はアドレス不足の影響も受けるでしょう。可視の IPv4 /24は1つだけであるため、IPv4 割り当ては有限リソースです。顧客がより多くの公開 IPv4 アドレス、高速拡張、または別のプロバイダーへのクリーンな移行を必要とする場合、限られた IPv4 プールは実用的な制約になります。IPv6 はより豊富ですが、IPv6 採用は依然として顧客のユーザー、ネットワーク、アプリケーションに依存します。IPv6 でうまく機能するサービスは、顧客、メール、レガシーシステム、サードパーティ統合のために IPv4 を依然として必要とする場合があります。

最も露出度の高い顧客は、復旧をテストせずに Zerospace を完全なクラウドプラットフォームとして扱う顧客です。サービスが重要でないエッジ実験に使用される場合、顧客は他の場所で再構築できます。プライマリデータベース、顧客向け本番サービス、または代替不可能なバックアップを保持する場合、顧客はより強力な証明を必要とします。公開記録は、AS201801 をデフォルトで成熟したマルチリージョンプラットフォームとして扱うことを正当化するにはまだ十分ではありません。

証拠グレードを上げるもの

Zerospace は、日付入りのインフラストラクチャ声明を公開することで、証拠グレードを迅速に上げることができます。最も有用な公開声明は、所有インフラ、レンタルコロケーション、仮想化ノード、パートナー拠点を区別するものです。ジオフィードの各都市をそこでの展開タイプにマッピングし、顧客コンピュートがその場所で利用可能かどうかを指定し、IPv4 と IPv6 の両方が本番かどうかを述べ、各プレフィックスを運ぶアップストリームを説明します。機密詳細を明らかにする必要はありません。マーケティング地理と運用依存関係を分離する必要があります。

次の改善点はファシリティとサポートの証明です。PeeringDB ファシリティ行、公開ステータスページ、カスタマーサポートページ、帯域外緊急連絡先、バックアップと復元ポリシー、移行またはデータエクスポートガイドは、購入者の信頼を実質的に向上させます。小規模プロバイダーはすべてのサプライヤー名を公開しなくても信頼性を得られますが、ホスト、ルート、ファシリティ、アカウントが失敗した場合に顧客がどのように復旧するかを示すべきです。現在の公開記録は、レジストリと BGP 証拠に大きく偏っています。

RPKI は強みであり続けるべきです。Zerospace はレビューされた IPv4 および IPv6 ルートに対してすでに有効なルートオリジン認証を持っています。将来の公開証拠は、新しい/48が現れるにつれてその規律を維持すべきです。:7::/48および:8::/48がライブの都市ロケーションになることを意図している場合、ルート可視性と検証はジオフィードと一致する必要があります。いくつかのジオフィードエントリが予約済みまたは計画中である場合、プロバイダーは顧客がアドレスロケーションファイルから本番局所性を推測するのではなく、そのように述べるべきです。

AS201801 が広範なルート可視性を失った場合、RPKI が無効になった場合、ジオフィードが説明なしにルーティングされないロケーションを宣伝し続けた場合、ウェブサイトが別のサポートパスなしに断続的に読み取り不能なままである場合、または顧客がファシリティと復旧詳細を入手できない場合、証拠グレードは低下します。また、プロバイダーが単一アカウント、単一ファシリティ、単一サポートキュー、または単一アップストリーム障害ドメインに依存しながらマルチリージョン回復力を販売した場合も低下します。

依存する運用者への結論

Zerospace Cloud は、実際のルーティングされたネットワークとして扱われるのに十分な公開証拠を持っていますが、実証済みのグローバルホスティングプラットフォームとして扱われるには十分ではありません。RIPE 記録は AS201801、185.140.53.0/24、2a07:1a84::/44を Christian Wittenberg trading as Zerospace Cloud に結び付けています。RIPEstat は AS が広範な IPv4 および IPv6 可視性でアナウンスされていることを示しています。RPKI はレビューされた IPv4 および IPv6 オリジンに対して有効です。PeeringDB は Zerospace Cloud ネットワークオブジェクトをリストしています。ジオフィードは詳細で現在のものであり、地理的サービス設計について真剣な質問をサポートするのに十分です。

注意も同様に明確です。IPv4 環境は1つの/24です。IPv6 可視性はレビューウィンドウで8つの/48をカバーし、/44とプロファイルが示唆するすべての/48ではありません。PeeringDB は公開ファシリティまたは IX 行を示していません。メインウェブサイトはチェック中にサービス詳細の信頼できるソースではありませんでした。ジオフィードは都市をマッピングしますが、それらの都市のラック、電力、冷却、ハードウェア、サポート、移行能力を証明しません。現在のアップストリーム画像は2つの観測されたネイバーを示していますが、公開ルーティングデータは独立した障害ドメインを証明しません。

したがって、実用的な購入者は、購入される正確なサービスに対する明示的な証拠がある場合にのみ Zerospace を使用すべきです。ワークロードがどこで実行されるか、誰がファシリティまたはホストを運営するか、どのアップストリームがプレフィックスを運ぶか、IPv4 と IPv6 の両方が要求されたロケーションでライブかどうか、電力およびハードウェア障害がどのように処理されるか、ウェブサイト障害中にサポートにどのように到達するか、バックアップがどのように分離されるか、データをどのようにエクスポートできるかを尋ねてください。ジオフィードを主張されたアドレス局所性のマップとして扱い、保証されたクラウドリージョンのマップとして扱わないでください。

重要でないワークロードの場合、公開記録はテストを正当化するのに十分かもしれません。本番サービスの場合、欠けている証拠は無視するには重要すぎます。ホスティング容量は常に物理的依存関係に戻ります。Zerospace の場合、公開インターネットはルートを見ることができます。顧客はまだ背後にあるラック、アップストリーム独立、サポート権限、移行パスの証明を必要としています。