cnh-primary CLOUD & HEAT Technologies GmbH が販売するホスティング容量は、ラック、トランジット、修理ウィンドウに依存している

概況

• cnh-primary は、RIPE に登録された自律システム AS203592（名称「cnh-primary」、登録先：CLOUD & HEAT Technologies GmbH）にマッピングされます。RIPE RDAP は AS がアクティブであることを示し、RIPEstat は2026年7月15日00:00 UTC にアナウンスされたことを示しました。
• ルートサーフェスは最新であり、このバッチとしては異常に文書化されています。RIPEstat は、AS203592 によってアナウンスされた185.128.116.0/22、94.198.185.0/24、2a0c:2c0::/29、2a0c:2c0:dd80::/44をリストし、観測された4つのすべてのオリジンに対して有効な RPKI を示しました。
• PeeringDB は、AS203592 を CLOUD & HEAT Technologies GmbH として記録し、リストされた1つの施設（IBH Dresden C2）と、IPv4 および IPv6 アドレスとルートサーバー参加を伴う10 Gbps の DD-IX 接続を1つ持っています。
• 同社のページは、IaaS、マネージド Kubernetes、OpenStack ベースのオンプレミスディストリビューション、GPU インスタンス、Ceph ストレージ、ドイツのデータセンターホスティング、ISO 27001および ISO 9001バッジ、SCS 互換のクラウド、および Scalytics、tracetronic、Nyris、elevait、alphaspeech、flow.d、N+P などの顧客を説明しています。
• エビデンスグレードは、ネットワークアイデンティティと製品の存在については強力、施設と相互接続のローカリティについては中程度、復元力については中程度のみです。これは、公開資料がラック数、電源トポロジ、スペアサーバープール、正確なアベイラビリティゾーンの配置、バックアップの証明、顧客エクスポートテスト、インシデント履歴を開示していないためです。

名前はルートとして始まるが、会社はルートよりも広い

ディレクトリエントリhttps://btw.media/en/directory/cnh-primary-cloud-heat-technologies-gmbhは、非常に特定の公開インフラアイデンティティを指しています。cnh-primary CLOUD & HEAT Technologies GmbH です。「cnh-primary」の部分はマーケティング上の飾りではありません。これは AS203592 の RIPE AS 名であり、RIPE データベース（https://rest.db.ripe.net/ripe/aut-num/AS203592.json）および RDAP（https://rdap.db.ripe.net/autnum/203592）に表示されています。AS は2015年12月4日に登録され、最終変更は2026年1月28日です。RDAP は登録者を CLOUD & HEAT Technologies GmbH と識別し、ドレスデンの住所は同社の連絡先ページにも表示されています。これにより、この記事は多くの小規模クラウドプロファイルよりも確固たる出発点を得ています。名前の付いた企業、名前の付いた AS、公開されたオフィスアイデンティティ、有効なインターネット番号登録があります。

2つ目のレイヤーは製品の証拠です。CLOUD & HEAT の英語ホームページ（https://www.cloudandheat.com/en/）は、同社をドレスデンのクラウドサービスおよびクラウドテクノロジープロバイダーと説明し、OpenStack、Proxmox VE、Kubernetes 上に構築された製品を提供しています。IaaS ページ（https://www.cloudandheat.com/en/products/cloud-services-in-germany/infrastructure-as-a-service/）は、コンピュートサイズ、ブロックおよびオブジェクトストレージ、GPU インスタンス、ドイツでホストされたクラウド容量を販売しています。マネージド Kubernetes ページ（https://www.cloudandheat.com/en/products/cloud-services-in-germany/managed-kubernetes-germany/）は、セルフマネージド、オンデマンド、ベーシック、フルサービスの Kubernetes モデルを説明しています。Patron ページ（https://www.cloudandheat.com/en/products/on-premises-cloud-infrastructures/on-premises-cloud-tailored/cloudandheat-a-ready-to-use-openstack-distribution/）は、OpenStack ディストリビューションとオプションの運用サポートを販売しています。これは単にシェルページに付属する休眠状態の AS ではありません。

ただし、同社には複数の運用レイヤーがあり、それらを混同すべきではありません。AS203592 はパブリックルーティングレイヤーです。IaaS および Kubernetes ページは製品ページです。Patron およびオンプレミスページはコンサルティング、ソフトウェア、マネージド運用サービスです。省エネページや OpenInfra プロファイルは、持続可能性とオープンソースのポジショニングを説明しています。仮想マシンを購入する顧客は、サポート付きの OpenStack ディストリビューションを購入する顧客とは異なる要素に依存しています。マネージド Kubernetes を使用する顧客は、API アクセス、クラスター、永続ボリューム、モニタリング、メンテナンスウィンドウに依存します。コンサルティングを購入する顧客は、AS203592 よりも人とプロセスに依存します。公開企業証拠は確かですが、各製品には異なる障害経路があります。

したがって、重要な質問は CLOUD & HEAT が存在するかどうかではありません。明らかに存在します。問題は、同社がホスティングされたインフラとして読まれる場合、公開証拠が何をサポートするかです。RIPE、RIPEstat、PeeringDB は AS203592 のネットワークマップをサポートします。同社サイトはパブリッククラウドおよびマネージドサービスカタログをサポートします。OpenStack マーケットプレイス（https://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-services）は、Cloud & Heat のクラウドサービスをリストし、製品が OpenStack Powered であると述べています。OpenStack のサポート企業プロファイル（https://www.openstack.org/community/supporting-organizations/profile/cloud-and-heat）は、Cloud & Heat をドレスデンのクラウドサービスおよびクラウドテクノロジープロバイダーと説明しています。しかし、これらのソースはいずれも完全な公開容量監査を提供していません。

これが購入者にとって重要な違いです。パブリック AS は健全でも、1つのアベイラビリティゾーンに予備のマシンがない可能性があります。OpenStack クラウドはリストされていても、特定の GPU クラスが売り切れている可能性があります。マネージド Kubernetes はモニタリングを約束しても、顧客が独自のバックアップ、デプロイメント、エクスポート計画を必要とする場合があります。施設エントリはドレスデンの存在を示しても、ラック数、電源供給設計、リモートハンド条件を明らかにしません。公開記録は cnh-primary を本格的なインフラカテゴリに位置づけるには十分強いですが、エンジニアリング上の注意を払って読む必要があります。

ルートの証拠は最新で、単なる企業ページよりも明確でクリーン

AS203592 の RIPEstat AS 概要（https://stat.ripe.net/data/as-overview/data.json?resource=AS203592）は、ホルダーを「cnh-primary CLOUD & HEAT Technologies GmbH」と識別し、2026年7月15日00:00 UTC に announced=true を示しました。これは時間固有ですが重要なシグナルです。AS は単に登録されていただけでなく、公開日時点で公開ルーティングデータに可視でした。RIPEstat の announced-prefixes エンドポイント（https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS203592）は、2026年7月15日までの2週間のウィンドウで4つのルートをリストしました。185.128.116.0/22、94.198.185.0/24、2a0c:2c0::/29、2a0c:2c0:dd80::/44です。

ルーティングステータスエンドポイント（https://stat.ripe.net/data/routing-status/data.json?resource=AS203592）は、シグナルをさらに強固にしました。2つの IPv4 プレフィックス、2つの IPv6 プレフィックス、1,280の IPv4 アドレス、524,288の IPv6 /48ユニット、4つの観測されたネイバー、およびクエリ時点での IPv4 と IPv6 の両方で RIPE RIS ピアセットにおける完全な観測可視性を報告しました。これらの数値は顧客容量ではありません。しかし、AS203592 がルートコレクタから広く可視であり、単一ピアのプライベートな脚注ではないことを示しています。

個々のプレフィックスビューも一致しています。RIPEstat は、185.128.116.0/22が AS203592 によってアナウンスされていること（https://stat.ripe.net/data/prefix-overview/data.json?resource=185.128.116.0/22）、94.198.185.0/24が AS203592 によってアナウンスされていること（https://stat.ripe.net/data/prefix-overview/data.json?resource=94.198.185.0/24）を示しました。また、IPv6 アグリゲート2a0c:2c0::/29（https://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0::/29）とより具体的な2a0c:2c0:dd80::/44（https://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0:dd80::/44）も示しました。IPv6 のより具体的な関係は、単一の未分化な割り当てではなく、セグメント化された IPv6 使用を示唆するため重要です。

RPKI も整合しています。RIPEstat は、AS203592 と185.128.116.0/22に対して有効（https://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=185.128.116.0/22）、94.198.185.0/24に対して有効（https://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=94.198.185.0/24）、2a0c:2c0::/29に対して有効（https://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0::/29）、2a0c:2c0:dd80::/44に対して有効（https://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0:dd80::/44）を返しました。RPKI の有効性はラック障害を防ぎませんが、ルーティング障害の1つのクラスを減らします。厳格なネットワークはこれらの発信元を無効として拒否する可能性が低くなります。

RIPE データベースは、プレフィックス背後にある管理の継続性も示しています。185.128.116.0/22の WHOIS ビュー（https://stat.ripe.net/data/whois/data.json?resource=185.128.116.0/22）は、netname DE-CLOUDANDHEAT-20151125、国 DE、組織 ORG-CHTG1-RIPE、および AS203592 が発信するルートオブジェクトを示しています。94.198.185.0/24のビュー（https://stat.ripe.net/data/whois/data.json?resource=94.198.185.0/24）は、netname DE-CLOUDANDHEAT-20081029、国 DE、および2026年1月の更新後の AS203592 が発信するルートオブジェクトを示しています。2a0c:2c0::/29のビュー（https://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0::/29）は、2018年の RIPE 割り当てを同じ組織に、および AS203592 の route6 オブジェクトを示しています。2a0c:2c0:dd80::/44のビュー（https://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0:dd80::/44）は特に興味深く、IBH-DD8 という名前で、2025年12月の作成日を持っています。これはより最近のドレスデンローカルセグメントを示唆しますが、背後にあるワークロードは明らかにしません。

顧客にとって、ルートの結論は単純です。AS203592 はライブネットワークであり、公開ルーティング証拠は強力です。より難しい結論はサービス容量に関するものです。プレフィックスと ROA は、インストールされているハイパーバイザーの数、アクティブなテナントの数、在庫切れのフレーバー、GPU プールの物理的な場所、ノード障害後のブロックストレージのテスト頻度を教えてくれません。これらはネットワークアイデンティティの質問に答えます。調達の質問には答えません。

ドレスデンの施設と交換記録は実在するが、クラウド全体ではない

PeeringDB は最も明確な公開物理的手がかりを追加します。ネットワークルックアップ（https://www.peeringdb.com/api/net?asn=203592）は、CLOUD & HEAT Technologies GmbH を AS203592 としてリストし、地域範囲、IPv6 有効、オープンピアリングポリシー、1つの交換、1つの施設を示しています。ネットワークオブジェクト（https://www.peeringdb.com/api/net/40650）は、施設セットを IBH Dresden C2、交換を DD-IX としています。netfac エンドポイント（https://www.peeringdb.com/api/netfac?net_id=40650）は、IBH Dresden C2 の関連付けを繰り返しています。netixlan エンドポイント（https://www.peeringdb.com/api/netixlan?asn=203592）は、DD-IX、10 Gbps の速度フィールド、IPv4 アドレス193.201.151.80、IPv6 アドレス2001:7f8:79::3:1b48:1、ルートサーバーピア true、operational=true をリストしています。

この組み合わせは異常に有用です。AS203592 を名前付きのドレスデン相互接続環境に配置し、読者を単なる企業住所だけに残しません。PeeringDB の施設記録（https://www.peeringdb.com/api/fac/14039）は、IBH Dresden C2 をドレスデンの IBH connect GmbH 施設と識別し、ハウジングとラックスペースの公開ウェブサイトパスを提供します（https://www.ibh.de/rechenzentrum/housing-rackpace）。DD-IX 交換記録（https://www.peeringdb.com/api/ix/4282）は、DD-IX をドレスデンの交換と識別し、施設セットに IBH Dresden C2 と SachsenEnergieCenter Dresden をリストし、https://dd-ix.net、https://dd-ix.net/stats、https://status.dd-ix.netを指しています。DD-IX サイトは、交換をドレスデン向けの非営利プラットフォームとして説明し、ローカルトラフィックをローカルに保ち、ザクセン地域にサービスを提供するために構築されています。

物理的な読み取りは依然として正確であるべきです。PeeringDB は、AS203592 が IBH Dresden C2 にリストされた施設関連付けと DD-IX 接続を持っていることを証明します。CLOUD & HEAT の IaaS コンピュートすべてがその1つの施設にあることを証明するわけではありません。ストレージレイアウトを証明しません。DD-IX ポートが顧客ハイパーバイザー、ボーダールーター、ラボセグメント、管理ネットワーク、または交換向けエッジに直接ケーブル接続されているかどうかは明らかにしません。クロスコネクトの多様性、スイッチの多様性、ラック電源、発電機カバレッジ、冷却冗長性、リモートハンド修理の取り組みも明らかにしません。

企業自体が1つの PeeringDB 施設を超えて全体像を広げています。IaaS ページは、パブリッククラウドインフラがドイツのデータセンターでのみ運用され、顧客データが GDPR 準拠の形で処理および保存されると述べています。マネージド Kubernetes ページは、Kubernetes データがドイツの ISO 27001認証データセンターで処理および保存されると述べています。2024年の SCS 記事（https://www.cloudandheat.com/en/news-press/strengthening-digital-sovereignty-new-ways-in-the-cloud-with-yaook-and-scs-compatibility/）は、envia TEL、Yaook、SCS とのライプツィヒデータセンタープロジェクトについて議論しています。2026年の認証ニュース（同じサイトから）は、Cloud&Heat が「Certified SCS-compatible IaaS」の認識を受け、その賞が2026年6月21日の SCS サミットで授与される予定であると述べています。これらの点は、フットプリントを単一の AS ポートストーリー以上にしますが、容量マップ全体を公開知識に変えるわけではありません。

電力と冷却は、持続可能性の主張だけでなく、物理的依存関係の一部です。IaaS ページは、Cloud&Heat が直接温水冷却と地域暖房回路への統合を使用して、エネルギー効率の高い運用とサーバー廃熱の利用を可能にすると述べています。OpenStack マーケットプレイスページも、水冷サーバーとサーバー廃熱の再利用を説明しています。これは有用なコンテキストです。クラウドが熱再利用を中心に設計されている場合、建物プラント、水ループ、熱交換器、地域熱消費、メンテナンスウィンドウがサービス依存関係の一部になります。従来のデータセンター顧客は主に電力と冷却の冗長性を尋ねます。Cloud&Heat の顧客は、熱再利用メンテナンスがコンピュート可用性からどのように分離されているかも尋ねるべきです。

したがって、ドレスデンの証拠は中間的なステートメントをサポートします。ドレスデン相互接続ポイントの公開証明と、ドイツのクラウドホスティングの公開企業証明があります。すべての顧客ワークロードをラックにマッピングしたり、すべてのアベイラビリティゾーンを建物にマッピングしたり、すべての GPU インスタンスを特定の電力および冷却チェーンにマッピングしたりするのに十分な公開証明はありません。購入者はドレスデンを完全なインフラ図ではなく、意味のある運用センターとして扱うことができます。

製品の証拠は OpenStack と Kubernetes で強力だが、スペア容量では強力でない

CLOUD & HEAT の製品ページは、地域クラウドプロバイダーとしては異常に具体的です。IaaS ページは、1 vCPU / 2 GB RAM / 15 GB SSD から8 vCPU / 30 GB RAM / 100 GB SSD までのコンピュートサイズをリストし、標準および Memory+価格ファミリーを提供し、HDD ブロック/オブジェクトストレージを宣伝し、ストレージクラスターはオブジェクトおよびブロックストレージ用のトリプル冗長 Ceph クラスターであると述べています。また、T4、A10、V100、A100 を含む GPU インスタンスクラスもリストしています。そのページは、トリプレプリケートされた NVMe プールが利用可能な容量内で提供できると明示的に述べています。このフレーズは重要です。同社は有用なリソースを販売していますが、一部のストレージクラスが容量制限されていることも認めています。

マネージド Kubernetes ページも同様に具体的です。OpenStack 上のセルフマネージドオプション、オンデマンドサポート、9/5サポートと4時間応答時間の Managed Kubernetes Basic、および異なるサポートレベルの Managed Kubernetes Full Service を説明しています。両方のマネージドティアは、高可用性のために複数のアベイラビリティゾーンにわたるデプロイメント、VPN による API 保護、GitOps ベースのクラスター管理、ロードバランサーサービス、OpenStack Cinder 永続ボリューム、ローカル静的および動的ストレージ、ネットワークポリシーをリストしています。Full Service は、イングレス、Certmanager、Prometheus および Grafana モニタリングスタック、24/7クラスターモニタリングおよびアラート、GPU インスタンスを追加します。これらは単なるスローガンではなく、運用上の主張です。

Patron ページはストーリーの OpenStack 側を強化します。Cloud&Heat Patron はすぐに使える OpenStack ディストリビューションであり、Yaook によるオープンソースライフサイクル管理、エンタープライズグレードのコンポーネント、SCS 互換性、自動化、ベンダーロックインなし、サポートオプションに基づいていると述べています。このページは、顧客がクラウドを運用するモデルと、Cloud&Heat が運用とモニタリング、障害分析、障害修理、更新などのメンテナンスを提供するモデルを提供しています。9-5および24/7のサポート契約オプションに言及しています。これは、CLOUD & HEAT が仮想マシンを再販しているだけでなく、OpenStack 自体に関する運用知識を販売していることを示しています。

OpenInfra ソースは、オープンインフラストラクチャのポジショニングを裏付けています。OpenStack マーケットプレイスページ（https://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-services）は、Cloud & Heat のクラウドサービスをリストし、製品が OpenStack Powered であると述べています。OpenInfra サポート企業ページ（https://www.openstack.org/community/supporting-organizations/profile/cloud-and-heat）は、その技術スタックに OpenStack、Kubernetes、Yaook、Krake が含まれると説明し、同社が Sovereign Cloud Stack の取り組みに貢献していると述べています。SCS Standards Forum ページ（https://sovereigncloudstack.org/en/about-scs/forum-scs-standards/）は、Cloud&Heat Technologies GmbH を安全なクラウドインフラに取り組むメンバーとしてリストし、Open Infrastructure Foundation との協力に言及しています。

顧客シグナルも公開されています。IaaS ページは、Scalytics、tracetronic、Nyris、elevait、alphaspeech、flow.d を顧客として挙げています。マネージド Kubernetes ページは、N+P Informationssysteme GmbH と elevait GmbH & Co. KG を挙げています。ホームページには、N+P、elevait、STACKIT からの引用があります。N+P と elevait は Cloud&Heat をマネージド Kubernetes プロバイダーとして説明し、STACKIT は Cloud&Heat を OpenStack 知識で支援するクラウドテクノロジーパートナーとして説明しています。OpenStack マーケットプレイスページは、elevait、N+P、Nyris、flow.d の顧客事例にリンクしています。これらは意味のある影響を受ける当事者のシグナルですが、テナントインベントリではありません。

インストール済みと使用可能の区別は、分析が減速しなければならないポイントです。インストール済み容量は、サーバー、ストレージ、GPU、スイッチ、DD-IX ポート、上流、OpenStack クラスター、Kubernetes コントロールプレーン、および会社の管理下または管理下にあるサポートツールです。使用可能容量は、顧客が注文、割り当て、稼働継続、回復、および許容できないダウンタイムなしで離脱できる部分です。公開ページは、製品クラス、サポートモデル、顧客名、技術選択を示しています。現在の GPU 在庫、フレーバーごとのクォータ、総ハイパーバイザー数、Ceph 障害ドメイン設計、オーバーコミット比率、メンテナンスカレンダー、バックアップ保存期間、テスト済みクロスゾーン復旧は示していません。

NVMe ストレージ注意書きの「利用可能な容量内で」という留保は、小規模クラウド経済の現実への有用な窓です。クラウドプロバイダーはストレージクラスを宣伝しながらも、高性能ドライブが高価で、施設電力が有限で、ストレージレプリケーションが生の容量を消費し、顧客需要が変化するため、そのクラスを制限できます。これはオファーを弱くするわけではありません。物理的にするのです。購入者はすべてのサービスラインを容量の質問に変換する必要があります。どれだけインストールされているか、どれだけ予約されているか、今月どれだけ配達できるか、需要が急増したときに何が変わるか。

上流、サポート、修理リスクはマーケティング層の下に位置する

RIPE データベースの公開ルーティングポリシーは、AS203592 の周りに AS3320、AS15372、AS6830、AS8220 をリストしています。RIPEstat の observed-neighbours エンドポイント（https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS203592）は、2026年7月14日に AS15372、AS3320、AS8220、AS213973 を観測しました。RIPEstat は、AS15372 を IBH connect として、AS3320 を Deutsche Telekom として、AS8220 を Colt として、AS6830 を Liberty Global として、AS213973 を BCIX Management として識別します（https://stat.ripe.net/data/as-overview/data.json?resource=AS15372、https://stat.ripe.net/data/as-overview/data.json?resource=AS3320、https://stat.ripe.net/data/as-overview/data.json?resource=AS8220、https://stat.ripe.net/data/as-overview/data.json?resource=AS6830、https://stat.ripe.net/data/as-overview/data.json?resource=AS213973）。これは、ローカル、国内、商用の接続シグナルの信頼できるミックスです。

注意点は、公開ネイバーリストは契約マップではないことです。どのパスが有償トランジットで、どのパスがピアリングで、どのパスがバックアップで、どのプレフィックスがどこで受け入れられ、どのルートフィルターが厳格で、どの保守ウィンドウが重複し、顧客トラフィックが特定のエッジに固定されているかは示しません。また、Kubernetes API エンドポイントと IaaS ストレージバックエンドが同一のネットワーク保護を持っていることも証明しません。良いニュースは、AS203592 が単一ネイバーの島として公開可視ではないことです。調達の質問は、関連する顧客サービスが、顧客が気にする特定の障害を生き残るのに十分な実際のパス多様性を持っているかどうかです。

施設障害は次のレイヤーです。ワークロードが AS203592 に接続されたドイツのデータセンターで実行されている場合、サービスはラック電力、冷却、上流クロスコネクト、スイッチ、ルーター、ストレージネットワーク、スタッフアクセスに依存します。IBH Dresden C2 の PeeringDB 施設は、diverse serving substations=true をリストしており、これは肯定的な施設レベルの手がかりです。それでも、CLOUD & HEAT のラック電力設計、デュアルコードカバレッジ、メンテナンスバイパス、バッテリーランタイム、発電機テスト履歴、または特定の顧客 VM がローカルインシデント中に影響を受ける施設から移動できるかどうかは開示しません。DD-IX 接続はローカルトラフィック交換に役立ちますが、交換の停止とデータセンターの停止は異なるイベントです。

サポート障害も同様に重要です。マネージド Kubernetes ページは、9/5サポートティア（ベーシックは4時間応答時間）とフルサービスの24/7モニタリングおよびアラートを提供します。Patron ページは、運用される OpenStack 環境向けに9-5および24/7のサポート契約オプションを提供します。IaaS ページは、OpenStack および DevOps の専門家からのパーソナルなサービス指向アドバイスを約束します。これらは有用な公開コミットメントですが、顧客は依然として契約を必要とします。このページは、ストレージ障害、ハイパーバイザー退避、GPU 交換、ルートリーク、DNS 停止、不正使用チケット、請求ロックアウト、緊急データエクスポートのエスカレーションターゲットを開示しません。

DNS 証拠は、小さくて有用な運用上の手がかりを追加します。このレビュー中の DNS クエリは、cloudandheat.com を介して www.cloudandheat.com を185.128.119.78に解決しました。これは、AS203592 によってアナウンスされた185.128.116.0/22プレフィックス内にあります。同じクエリは、mail.cloudandheat.com を MX として、INWX ネームサーバー、およびメールホストと Google を含む SPF レコードを示しました。これは、公開ウェブサイトが大規模なサードパーティ CDN からのみではなく、同社自身のルーテッドスペースから提供されていることを示唆しています。これはネットワークアイデンティティにとって肯定的ですが、同社の公開サイトが自身の AS、ウェブホスト、または施設依存関係の影響を受ける可能性があることも意味します。

顧客影響経路は、製品スタックに従います。ネットワーク障害は、パブリッククラウドの到達可能性、マネージド Kubernetes API、ロードバランサー、顧客イングレス、ソフトウェア配布エンドポイント、そしておそらくプロバイダー自身のウェブサイトやサポートサーフェスに影響を与える可能性があります。ストレージ障害は、ボリュームとオブジェクトストレージに影響を与える可能性があります。電力または冷却インシデントは、ハイパーバイザーと GPU マシンに影響を与える可能性があります。サポートまたは運用の不足は、ハードウェアが修理可能であっても復旧時間を延長する可能性があります。契約または請求の障害は、変更、エクスポート、または緊急のスケーリングをブロックする可能性があります。公開資料は、同社がこれらのドメインで経験豊富であることを証明しますが、すべての障害経路がリハーサルされていることは証明しません。

これは CLOUD & HEAT に固有の批判ではありません。地域クラウド依存関係の通常の形状です。プロバイダーは、ハイパースケールプラットフォームよりも透明性が高く、オープンソースに準拠し、ローカルでありながら、同じ物理的制約（スペース、電力、冷却、光学機器、スペアパーツ、ルートフィルター、保守ウィンドウ、人の可用性）の対象となります。

データローカリティは強みだが、ローカリティは自動的な復旧可能性ではない

CLOUD & HEAT の最も強力な読者向けの約束は、ローカリティとデジタル主権です。IaaS ページは、パブリッククラウドインフラがドイツのデータセンターでのみ運用され、データが GDPR に準拠して処理および保存されると述べています。マネージド Kubernetes ページは、データがドイツの ISO 27001認証データセンターで処理および保存されると述べています。ホームページは、顧客が CLOUD & HEAT のインフラまたはオンプレミスデプロイメントを使用できると述べています。SCS および OpenInfra のソースは、同社をオープンスタンダード、ポータビリティ、デジタル主権の周りにフレーム化しています。

これらの主張は重要です。不透明なオフショアホスティングを避けようとするドイツまたはヨーロッパの顧客は、パブリッククラウドページがドイツ、OpenStack、オープンソーススタックを一般的なグローバルリージョンではなく示している場合、異なるリスクモデルを持っています。SCS 関連の資料は、相互運用性にとって重要です。2024年の企業記事は、SCS 標準がクラウドアプリケーションの相互運用性とポータビリティを高めることを目的としていると述べています。2026年の認証ニュースは、Cloud&Heat が Certified SCS-compatible IaaS の認識を受けたと述べています。OpenInfra プロファイルは、同社が SCS などの標準に貢献していると述べています。これらはすべてデータ主権とローカリティのトピックに関連しています。

しかし、ローカリティを復旧可能性と誤解すべきではありません。顧客はデータがドイツにあることを知ることができますが、ドレスデンとライプツィヒの間、2つのドレスデンルーム間、1つの建物内の2つのアベイラビリティゾーン間、または障害ドメインを持つ1つのストレージクラスター内にレプリケートされているかどうかはわかりません。マネージド Kubernetes ページは、高可用性のために複数のアベイラビリティゾーンにわたるデプロイメントを約束しますが、これらのゾーンを公開で定義していません。IaaS ページは、トリプル冗長 Ceph クラスターと利用可能な容量内のオプションのトリプレプリケート NVMe プールを述べていますが、レプリカがラックローカル、ルームローカル、建物ローカル、またはキャンパス分離されているかどうかは開示していません。公開ページは、バックアップ場所や復元履歴を示していません。

これは、コンプライアンス義務を持つ顧客にとって重要です。ワークロードがドイツのストレージを必要とする場合、CLOUD & HEAT の公開ページは最初の主張をサポートします。ワークロードが特定のドイツの州、電源ゾーン、アベイラビリティゾーン分離、バックアップ分離、エアクッションエクスポート、または規制対象セクターの継続性計画を必要とする場合、公開ページだけでは不十分です。顧客は、データの場所、サブプロセッサー、バックアップ場所、ストレージレプリケーション範囲、スタッフアクセス、メンテナンスウィンドウ、テスト済み復元についての声明を求めるべきです。ワークロードがマネージド Kubernetes を使用する場合、顧客はコントロールプレーン、etcd、永続ボリューム、イメージレジストリ、モニタリングデータ、ログがどこにあるかも尋ねるべきです。

移行パスは、技術選択により明確です。OpenStack、Kubernetes、Cinder ボリューム、Ceph バッキングストレージ、GitOps、SCS 互換性はすべて、エクスポート権とテスト済みツールで実装されれば、ロックインを減らすことができます。顧客はインフラストラクチャをコードとして実行し、外部バックアップを維持し、DNS を自社管理下に置き、アプリケーションをコンテナ化し、宛先の OpenStack または Kubernetes 環境を準備できます。しかし、公開ページは、すべてのイメージ、ボリューム、スナップショット、オブジェクトバケット、フローティング IP、ロードバランサー、GPU ワークロードが迅速にエクスポートできることを約束していません。標準技術は移行を可能にしますが、自動的にはしません。

したがって、正しい結論は混合です。CLOUD & HEAT は、ドイツのホスティング、OpenStack、Kubernetes、SCS 作業、ローカル相互接続を組み合わせているため、信頼できる主権ストーリーを持っています。同じストーリーは、サービス境界でテストされなければなりません。どのサービスがドイツでホストされているか、どの部分が顧客のオンプレミスか、どの部分が IBH または DD-IX に依存しているか、どの部分がサードパーティのメールまたは DNS に依存しているか、どの部分がプロバイダーの停止中に移動できるか。主権は国だけではありません。それはストレス時の制御です。

cnh-primary が障害を起こした場合、誰が影響を受けるか？

最初の影響グループは、パブリッククラウドおよび IaaS の顧客です。IaaS ページは、Scalytics、tracetronic、Nyris、elevait、alphaspeech、flow.d などの顧客を挙げています。コンピュート、GPU、ストレージリソースを販売し、ドイツのデータ保護とデジタル主権のためにクラウドを位置づけています。AS203592 または関連する施設パスが障害を起こした場合、顧客の仮想マシンは電源は入ったままでも到達不能になる可能性があります。ストレージレイヤーが障害を起こした場合、データ可用性とボリュームアタッチメントが問題になります。容量が枯渇した場合、既存のインスタンスは稼働し続けても、顧客はスケーリングできない可能性があります。

2番目のグループは、マネージド Kubernetes の顧客です。マネージド Kubernetes ページは、N+P Informationssysteme GmbH と elevait GmbH & Co. KG を挙げています。VPN 経由の API アクセス、OpenStack Cinder 永続ボリューム、ロードバランサー、モニタリング、イングレス、Certmanager、マルチゾーンデプロイメントを説明しています。プロバイダーのクラウドレイヤーが障害を起こした場合、Kubernetes はポッドを再スケジュールするかもしれませんが、ボリューム、イングレス、外部到達可能性を失う可能性があります。コントロールプレーンまたは VPN パスが障害を起こした場合、開発者は管理アクセスを失う可能性があります。モニタリングスタックがプロバイダーのフルサービスオファーの一部である場合、インシデント可視性はサービス自体とともに低下する可能性があります。

3番目のグループは、ホストとしてではなく、OpenStack 運用パートナーとして CLOUD & HEAT を使用する顧客です。ホームページは、STACKIT が Cloud&Heat を OpenStack 知識でクラウドインフラの開発と拡張をサポートするとして引用しています。Patron ページは、OpenStack ディストリビューション、インストール、試運転、運用、モニタリング、障害分析、更新を販売しています。AS203592 の障害は、顧客が運用するクラウドを直接ダウンさせないかもしれませんが、サポートの停止はアップグレード、インシデント、緊急変更時に依然として重要です。コンサルティングおよびマネージド運用の顧客は、cnh-primary ルートを介さずに、スタッフの可用性、リモートアクセス、ドキュメント、エスカレーションを通じて影響を受けます。

4番目のグループは、地域ネットワークとローカルトラフィック参加者です。PeeringDB および DD-IX の証拠は、AS203592 をドレスデンの DD-IX に配置しています。ローカル交換パスは、機能するときに地域のレイテンシと復元力を改善できます。また、顧客がローカルトラフィックがローカルに留まると想定する場合、依存関係になることもあります。DD-IX 自体は複数の参加者と施設を持つより広範な交換であるため、CLOUD & HEAT の問題はデフォルトで DD-IX の問題ではありません。しかし、ドレスデン近くのサービスを使用する顧客は、AS203592 と DD-IX ステータスの両方を監視する必要があります。ローカル相互接続パスはパフォーマンスストーリーの一部だからです。

5番目のグループは、プロバイダー自身の公開プレゼンスです。DNS は www.cloudandheat.com を185.128.116.0/22内に配置しました。同じネットワークまたはホスティングスタックが会社の公開サイトをサポートしている場合、インフラインシデントにより、顧客が情報を必要とする瞬間に製品ページと一部の顧客エントリポイントが利用できなくなる可能性があります。公開 DNS 証拠は、サポートチケットシステムが同じスタック上にあることを証明しておらず、SPF レコードに Google が含まれているため、メールは異なる依存パスを持つ可能性があります。それでも、公開コミュニケーションは顧客のデューデリジェンスの一部であるべきです。ステータスページはどこか、メインウェブサイトが利用できない場合はどうなるか、どの緊急連絡先が到達可能か。

このため、影響を受ける地域の表現は控えめにする必要があります。割り当ては、クラウドおよびホスティングサービスがグローバルに到達可能であり、ディレクトリカテゴリがグローバルクラウドサービスであるため、地域をグローバルとマークしています。公開証拠で最も強い運用地域はドイツ、特にドレスデンとザクセンであり、文書化された DD-IX 接続とドイツのデータセンターの主張があります。ドイツ国外の顧客もサービスを使用できますが、物理的な依存関係はハイパースケールの意味でグローバルではありません。これは、グローバルな到達可能性を持つドイツのクラウドおよびクラウドテクノロジープロバイダーです。

冗長性の証明はネットワークエッジでは良好だが、サービスレイヤーでは不完全

いくつかの肯定的な冗長性シグナルがあります。AS203592 は、RIPEstat で1つではなく4つの観測されたネイバーを持っています。クエリ時点で、IPv4 および IPv6 の観測されたすべての RIS ピアにわたる公開ルーティング可視性を持っています。4つの観測されたすべてのプレフィックスに対して RPKI 有効な発信元を持っています。PeeringDB は DD-IX でのルートサーバー参加を示しています。マネージド Kubernetes ページは、高可用性のためのマルチアベイラビリティゾーンデプロイメントを約束しています。IaaS ページは、トリプル冗長 Ceph クラスターとトリプレプリケート NVMe オプションに言及しています。Patron ページは、24/7オプションを含む運用およびモニタリング契約を提供しています。

ギャップも同様に重要です。公開ルーティング可視性はトラフィックエンジニアリングを開示しません。PeeringDB の10 Gbps DD-IX ポートは、使用率やフェイルオーバーを開示しません。RPKI 有効性はルート変更への準備を証明しません。「複数のアベイラビリティゾーン」は爆発半径の分離を定義しません。「トリプル冗長 Ceph」はレプリカ配置を述べません。「24/7モニタリング」は応答人員、エスカレーション権限、復旧目標を明らかにしません。ISO 証明書と OpenStack Powered ステータスはプロセスと技術の姿勢を示しますが、インシデント記録ではありません。購入者はこれらの公開主張を包括的な高可用性保証に変換すべきではありません。

購入者が要求できる最も強力な実用的冗長性証明は、パンフレットではありません。それはテストされた復旧実行です。代表的な VM、ボリューム、オブジェクトバケット、Kubernetes ワークロード、データベースを取り、ゾーン障害をシミュレートし、復旧時間を測定し、DNS 変更をテストし、イメージとボリュームをエクスポートし、セカンドプロバイダーまたは顧客サイトで再構築し、アプリケーションレベルの一貫性を検証します。Kubernetes の場合は、etcd、永続ボリューム、イングレスコントローラー、ロードバランサー、レジストリ依存関係がどのように復旧するかを尋ねます。OpenStack の場合は、ストレージノード、ハイパーバイザー、ルーター、施設リンクが障害を起こしたときに、Nova、Neutron、Cinder、Glance、Keystone、Ceph、外部 DNS がどのように動作するかを尋ねます。

移行証明も製品固有であるべきです。IaaS 顧客は、イメージエクスポート、ボリュームスナップショット/エクスポート、オブジェクトデータ転送、アドレス変更計画、クォータ解放を必要とします。Kubernetes 顧客は、マニフェスト、Helm チャート、GitOps リポジトリ、シークレット処理、永続ボリューム移行、外部バックアップを必要とします。GPU 顧客は、代替ハードウェアの可用性とドライバ互換性を必要とします。オンプレミスの Patron 顧客は、ドキュメント、ラン ブック、更新パス、サポートが変更されても運用を継続する権利を必要とします。これらは異なるテストであり、公開ページはそれらすべてに答えているわけではありません。

同社はオープンソースの選択によって助けられています。OpenStack と Kubernetes は、プロプライエタリのみのプラットフォームと比較して、一部のロックインを削減します。SCS 互換性は、相互運用性とポータビリティを高めるように設計されています。Yaook と Tarook は、自動化されたライフサイクル管理を指しています。しかし、オープンスタンダードの価値は、顧客がその構成、バックアップ、認証情報、ビルド指示を制御している場合にのみ現れます。オープンソースは終了計画の代わりではありません。より良い終了計画の基礎です。

最終的な依存関係グレード

cnh-primary CLOUD & HEAT Technologies GmbH は、最初の「薄いフットプリント」の疑念からアップグレードされるべきです。公開証拠は薄くありません。AS203592 はライブです。RIPE は現在のアナウンス、有効な発信元、ドイツの番号リソースを示しています。PeeringDB はドレスデンの施設と DD-IX 接続を示しています。同社サイトは、意味のある技術的詳細を伴って IaaS とマネージド Kubernetes を販売しています。OpenStack および OpenInfra のソースは、オープンクラウドインフラにおける同社の役割を裏付けています。SCS 関連のソースは、主権と相互運用性のストーリーをサポートしています。顧客紹介も可視です。

ダウングレードは存在に関するものではありません。それは復元力の証明に関するものです。公開証拠は、総インストールコンピュート、GPU 在庫、ストレージ生容量、テナント数、ゾーンごとの設計、ラック数、施設契約条件、電源トポロジ、リモートハンド手順、バックアップ場所、復元履歴、インシデント履歴、正確なサポート人員配置、テスト済み顧客終了を開示していません。IaaS ページの「利用可能な容量内で」という表現は、使用可能容量が有限であることを思い出させる有用なものです。購入者は、すべての公開容量フレーズを在庫、クォータ、復旧パスを検証する招待として扱うべきです。

最も有用なグレードは分割です。ネットワークアイデンティティとルート証拠：強力。製品と顧客証拠：強力。施設とローカル相互接続証拠：中強度。ドレスデンと DD-IX は可視ですが、クラウドフットプリント全体が公開マッピングされているわけではありません。ホスティング容量の復元力証拠：中程度。公開ページは具体的な可用性、サポート、ストレージの主張をしていますが、確固たる証明には至っていません。移行証拠：中程度。OpenStack、Kubernetes、SCS によって助けられていますが、契約条件と顧客の準備に依存します。

実用的なテストは、顧客がこれらの公開の強みを運用管理に変えられるかどうかです。Cloud&Heat を戦略的なドイツのクラウドプロバイダーとして扱う購入者は、サービスカタログだけでなく、現在の容量ステートメントを要求する必要があります。サイトまたはアベイラビリティゾーンごとの利用可能な CPU、メモリ、GPU、ブロックストレージ、オブジェクトストレージ、バックアップストレージ、ネットワーククォータです。部分的なストレージイベント中に新しい仮想マシンをプロビジョニングできるか、プロバイダー保有のシークレットなしで Kubernetes クラスターを再構築できるか、ルーターメンテナンス中にフローティング IP を再割り当てできるか、オブジェクトデータをスロットリングなしでエクスポートできるか、公開サイトまたはピアリングパスが障害を起こしたときにサポートが緊急変更を実行できるかを尋ねるべきです。これらは、本格的なホスティング容量に対する通常の質問です。それらは会社のストーリーを弱めるのではなく、強力な公開証拠を使用可能にします。

モニタリングについては、AS203592、185.128.116.0/22、94.198.185.0/24、2a0c:2c0::/29、2a0c:2c0:dd80::/44、DD-IX ポート、cloudandheat.com サイト、公開ステータスまたはサポートパスを追跡します。調達については、施設声明、アベイラビリティゾーンの定義、ルート多様性の証拠、サポート応答条件、バックアップおよびエクスポートの証明、テスト済み移行計画を要求します。同社は信頼できるインフラを持っています。決定点は、顧客が購入する特定のサービスが、すべてのホスティング容量が最終的に直面する物理的障害を生き残るのに十分な使用可能容量と十分にリハーサルされた復旧を持っているかどうかです。