cnh-primary CLOUD & HEAT Technologies GmbH verkauft gehostete Kapazität, die weiterhin von Racks, Transit und Reparaturfenstern abhängt

Zusammenfassung

• cnh-primary entspricht AS203592, dem bei RIPE registrierten autonomen System namens "cnh-primary", das CLOUD & HEAT Technologies GmbH zugewiesen ist. Das RIPE-RDAP zeigt das AS als aktiv, und RIPEstat hat es am 15. Juli 2026 um 00:00 UTC als angekündigt gezeigt.
• Die Routing-Oberfläche ist aktuell und für diesen Datensatz ungewöhnlich gut dokumentiert: RIPEstat hat 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29 und 2a0c:2c0:dd80::/44 als von AS203592 angekündigt gelistet, mit gültigem RPKI für alle vier beobachteten Ursprünge.
• PeeringDB führt AS203592 als CLOUD & HEAT Technologies GmbH, mit einem gelisteten Standort, IBH Dresden C2, und einer DD-IX-Anbindung mit 10 Gbps, IPv4- und IPv6-Adressen sowie Route-Server-Teilnahme.
• Die Unternehmensseiten beschreiben IaaS, Managed Kubernetes, On-Premises-OpenStack-Distribution, GPU-Instanzen, Ceph-Speicher, Hosting in deutschen Rechenzentren, ISO 27001- und ISO 9001-Zertifizierungen, SCS-kompatibles Cloud-Work und Kunden wie Scalytics, tracetronic, Nyris, elevait, alphaspeech, flow.d und N+P.
• Das Beweismittel ist Stark für die Netzidentität und die Produktexistenz, Mittel für den Standort und die lokale Interkonnektion, und nur Mittel für die Resilienz, da öffentliche Dokumente die Anzahl der Racks, die Stromtopologie, Ersatzserverpools, die genaue Platzierung der Verfügbarkeitszonen, Backup-Nachweise, Kundencxporttests oder den Vorfallverlauf nicht offenlegen.

Der Name beginnt wie eine Route, aber das Unternehmen ist breiter als eine Route

Der Verzeichniseintrag aufhttps://btw.media/en/directory/cnh-primary-cloud-heat-technologies-gmbhverweist auf eine sehr spezifische öffentliche Infrastrukturidentität: cnh-primary CLOUD & HEAT Technologies GmbH. Der Teil "cnh-primary" ist keine Marketing-Verzierung. Es ist der RIPE-AS-Name für AS203592, der in der RIPE-Datenbank unterhttps://rest.db.ripe.net/ripe/aut-num/AS203592.jsonund in RDAP unterhttps://rdap.db.ripe.net/autnum/203592angezeigt wird. Das AS wurde am 4. Dezember 2015 registriert und zuletzt am 28. Januar 2026 geändert. RDAP identifiziert den Inhaber als CLOUD & HEAT Technologies GmbH, wobei die Dresdner Adresse auch auf den Kontaktseiten des Unternehmens sichtbar ist. Dies gibt dem Artikel einen solideren Ausgangspunkt als vielen kleinen Cloud-Profilen: Es gibt ein benanntes Unternehmen, ein benanntes AS, eine öffentliche Büroidentität und eine aktive Internetnummernregistrierung.

Die zweite Schicht ist der Produktnachweis. Die englische Startseite von CLOUD & HEAT unterhttps://www.cloudandheat.com/en/beschreibt das Unternehmen als Cloud-Service- und Cloud-Technologie-Anbieter mit Sitz in Dresden und Produkten, die auf OpenStack, Proxmox VE und Kubernetes basieren. Die IaaS-Seite unterhttps://www.cloudandheat.com/en/products/cloud-services-in-germany/infrastructure-as-a-service/bietet Rechengrößen, Block- und Objektspeicher, GPU-Instanzen und gehostete Cloud-Kapazität in Deutschland. Die Managed-Kubernetes-Seite unterhttps://www.cloudandheat.com/en/products/cloud-services-in-germany/managed-kubernetes-germany/beschreibt selbstverwaltete, On-Demand-, Basis- und Full-Service-Kubernetes-Modelle. Die Patron-Seite unterhttps://www.cloudandheat.com/en/products/on-premises-cloud-infrastructures/on-premises-cloud-tailored/cloudandheat-a-ready-to-use-openstack-distribution/vertreibt eine OpenStack-Distribution und optionale Betriebsunterstützung. Dies ist nicht einfach ein ruhendes AS, das an eine leere Seite angehängt ist.

Allerdings hat das Unternehmen mehr als eine Betriebsebene, und diese Ebenen sollten nicht verwechselt werden. AS203592 ist die öffentliche Routing-Ebene. Die IaaS- und Kubernetes-Seiten sind Produktseiten. Die Patron- und On-Premises-Seiten sind Beratungs-, Software- und Managed-Operations-Angebote. Die Energieeffizienzseiten und OpenInfra-Profile beschreiben eine nachhaltige und Open-Source-Positionierung. Ein Kunde, der eine virtuelle Maschine kauft, ist von anderen Dingen abhängig als ein Kunde, der eine unterstützte OpenStack-Distribution für seine eigene Hardware kauft.

Ein Kunde, der Managed Kubernetes nutzt, ist von API-Zugriff, Clustern, persistenten Volumes, Überwachung und Wartungsfenstern abhängig. Ein Kunde, der Beratung kauft, ist mehr von Personen und Prozessen abhängig als von AS203592. Die öffentlichen Belege über das Unternehmen sind real, aber jedes Produkt hat einen anderen Ausfallpfad.

Die Kernfrage ist also nicht, ob CLOUD & HEAT existiert. Es existiert eindeutig. Die Frage ist, welche öffentlichen Belege das Unternehmen stützen, wenn es als gehostete Infrastruktur gelesen wird. RIPE, RIPEstat und PeeringDB stützen eine Netzwerkkarte AS203592. Die Unternehmenswebsite stützt einen Katalog öffentlicher Cloud- und Managed Services. Der OpenStack Marketplace unterhttps://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-serviceslistet die Cloud-&-Heat-Clouddienste auf und gibt an, dass das Produkt OpenStack Powered ist. Das OpenStack-Supporting-Organizations-Profil unterhttps://www.openstack.org/community/supporting-organizations/profile/cloud-and-heatbeschreibt Cloud & Heat als einen Dresdner Anbieter von Cloud-Diensten und Cloud-Technologien. Keine dieser Quellen liefert jedoch ein vollständiges öffentliches Audit der Kapazität.

Dies ist die Unterscheidung, die für Käufer wichtig ist. Ein öffentliches AS kann gesund sein, während eine Verfügbarkeitszone keine Ersatzmaschinen hat. Eine OpenStack-Cloud kann gelistet sein, während eine bestimmte GPU-Klasse ausgeschöpft ist. Ein Managed-Kubernetes-Angebot kann Überwachung versprechen, während ein Kunde dennoch sein eigenes Backup, Deployment-Plan und Export benötigt. Ein Standorteintrag kann eine Präsenz in Dresden zeigen, ohne die Anzahl der Racks, die Stromversorgungsauslegung oder die Remote-Support-Bedingungen preiszugeben.

Die öffentliche Akte ist solide genug, um cnh-primary in eine Kategorie ernsthafter Infrastruktur einzuordnen, aber sie muss dennoch mit technischer Vorsicht gelesen werden.

Die Routing-Belege sind aktuell, sichtbar und klarer als eine einfache Unternehmensseite

Die AS-Übersicht von RIPEstat für AS203592 unterhttps://stat.ripe.net/data/as-overview/data.json?resource=AS203592identifiziert den Inhaber als "cnh-primary CLOUD & HEAT Technologies GmbH" und zeigte announced=true am 15.07.2026 00:00 UTC. Dies ist ein zeitlich spezifisches, aber wichtiges Signal: Das AS war nicht nur registriert; es war zum Veröffentlichungszeitpunkt in den öffentlichen Routingdaten sichtbar. Der Endpunkt für angekündigte Präfixe von RIPEstat unterhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS203592listete vier Routen im Zweiwochenfenster bis zum 15. Juli 2026: 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29 und 2a0c:2c0:dd80::/44.

Der Endpunkt des Routing-Status unterhttps://stat.ripe.net/data/routing-status/data.json?resource=AS203592verstärkte das Signal. Er meldete zwei IPv4-Präfixe, zwei IPv6-Präfixe, 1280 IPv4-Adressen, 524288 IPv6-/48-Einheiten, vier beobachtete Nachbarn und vollständige beobachtete Sichtbarkeit im gesamten RIPE-RIS-Peer-Set für IPv4 und IPv6 zum Zeitpunkt der Abfrage. Diese Zahlen sind nicht die Kundenkapazität. Sie zeigen, dass AS203592 von den Routenkollektoren aus weitgehend sichtbar war und keine Ein-Peer-Fußnote ist.

Die einzelnen Präfixansichten stimmen überein. RIPEstat zeigte 185.128.116.0/22 angekündigt von AS203592 unterhttps://stat.ripe.net/data/prefix-overview/data.json?resource=185.128.116.0/22und 94.198.185.0/24 angekündigt von AS203592 unterhttps://stat.ripe.net/data/prefix-overview/data.json?resource=94.198.185.0/24. Es zeigte auch das IPv6-Aggregat 2a0c:2c0::/29 unterhttps://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0::/29und das spezifischere 2a0c:2c0:dd80::/44 unterhttps://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0:dd80::/44. Die spezifischere IPv6-Beziehung ist wichtig, da sie eine segmentierte IPv6-Nutzung nahelegt und nicht eine einzige undifferenzierte Zuweisung.

Das RPKI ist ebenfalls ausgerichtet. RIPEstat gab für AS203592 und 185.128.116.0/22 unterhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=185.128.116.0/22gültig zurück, gültig für 94.198.185.0/24 unterhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=94.198.185.0/24, gültig für 2a0c:2c0::/29 unterhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0::/29und gültig für 2a0c:2c0:dd80::/44 unterhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0:dd80::/44. Die RPKI-Gültigkeit verhindert keinen Rack-Ausfall, reduziert jedoch eine Klasse von Routing-Ausfällen: Strenge Netzwerke lehnen diese Ursprünge seltener als ungültig ab.

Die RIPE-Datenbank zeigt auch administrative Kontinuität hinter den Präfixen. Der WHOIS-Eintrag von 185.128.116.0/22 unterhttps://stat.ripe.net/data/whois/data.json?resource=185.128.116.0/22zeigt netname DE-CLOUDANDHEAT-20151125, Land DE, Organisation ORG-CHTG1-RIPE und ein route-Objekt mit Ursprung AS203592. Der Eintrag von 94.198.185.0/24 unterhttps://stat.ripe.net/data/whois/data.json?resource=94.198.185.0/24zeigt netname DE-CLOUDANDHEAT-20081029, Land DE und ein route-Objekt mit Ursprung AS203592 nach einer Aktualisierung im Januar 2026. Der Eintrag von 2a0c:2c0::/29 unterhttps://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0::/29zeigt eine RIPE-Zuweisung von 2018 an dieselbe Organisation und route6-Objekte für AS203592. Der Eintrag von 2a0c:2c0:dd80::/44 unterhttps://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0:dd80::/44ist besonders interessant, da er IBH-DD8 heißt und ein Erstellungsdatum vom Dezember 2025 hat. Dies deutet auf ein neueres, in Dresden lokalisiertes Segment hin, offenbart aber immer noch nicht die dahinter liegenden Workloads.

Für einen Kunden ist das Fazit zum Routing einfach. AS203592 ist ein lebendiges Netzwerk, und die öffentlichen Routing-Belege sind solide. Die schwierigere Schlussfolgerung betrifft die Servicekapazität. Die Präfixe und ROAs sagen uns nicht, wie viele Hypervisoren installiert sind, wie viele Mandanten aktiv sind, welche Geschmacksrichtungen ausverkauft sind, wo sich der GPU-Pool physisch befindet oder wie oft Blockspeicher nach einem Knotenausfall getestet wird. Sie beantworten die Frage der Netzidentität. Sie beantworten nicht die Frage der Bereitstellung.

Der Standort und die Exchange-Registrierung in Dresden sind real, aber nicht die gesamte Cloud

PeeringDB fügt den klarsten öffentlichen physischen Hinweis hinzu. Die Netzsuche unterhttps://www.peeringdb.com/api/net?asn=203592listet CLOUD & HEAT Technologies GmbH als AS203592, mit regionalem Umfang, IPv6 aktiviert, offener Peering-Politik, einem Exchange und einem Standort. Das Netzobjekt unterhttps://www.peeringdb.com/api/net/40650zeigt den Standort auf IBH Dresden C2 und den Exchange auf DD-IX gesetzt. Der netfac-Endpunkt unterhttps://www.peeringdb.com/api/netfac?net_id=40650wiederholt die IBH Dresden C2-Zuordnung. Der netixlan-Endpunkt unterhttps://www.peeringdb.com/api/netixlan?asn=203592listet DD-IX, ein Geschwindigkeitsfeld von 10 Gbps, IPv4-Adresse 193.201.151.80, IPv6-Adresse 2001:7f8:79::3:1b48:1, route-server peer true und operational=true.

Diese Kombination ist ungewöhnlich nützlich. Sie platziert AS203592 in einer benannten Interkonnektionsumgebung in Dresden, anstatt die Leser nur mit einer Unternehmensadresse zurückzulassen. Der PeeringDB-Standorteintrag unterhttps://www.peeringdb.com/api/fac/14039identifiziert IBH Dresden C2 als eine Einrichtung von IBH connect GmbH in Dresden, mit dem öffentlichen Website-Pfad für Hosting und Rack-Space unterhttps://www.ibh.de/rechenzentrum/housing-rackpace. Der DD-IX-Exchange-Eintrag unterhttps://www.peeringdb.com/api/ix/4282identifiziert DD-IX als einen Exchange in Dresden, listet IBH Dresden C2 und das SachsenEnergieCenter Dresden in seinem Standortset und verweist aufhttps://dd-ix.net,https://dd-ix.net/statsundhttps://status.dd-ix.net. Die DD-IX-Website beschreibt den Exchange als eine nichtkommerzielle Plattform für Dresden, die dazu dient, lokalen Verkehr lokal zu halten und die Region Sachsen zu bedienen.

Die physische Lesart muss dennoch präzise bleiben. PeeringDB beweist, dass AS203592 eine gelistete Standortzuordnung zu IBH Dresden C2 und eine DD-IX-Verbindung hat. Es beweist nicht, dass sich die gesamte IaaS-Compute von CLOUD & HEAT in dieser einen Einrichtung befindet. Es beweist nicht das Speicherlayout. Es zeigt nicht, ob der DD-IX-Port direkt mit den Hypervisoren der Kunden, einem Border-Router, einem Lab-Segment, einem Management-Netzwerk oder einem Exchange-Border verbunden ist.

Es zeigt nicht die Vielfalt der Querkabel, Switch-Redundanz, Rack-Stromversorgung, Generatorabdeckung, Kühlungsredundanz oder Remote-Reparaturverpflichtungen.

Das Unternehmen selbst erweitert das Bild über einen einzelnen PeeringDB-Standort hinaus. Die IaaS-Seite gibt an, dass die öffentliche Cloud-Infrastruktur ausschließlich in Rechenzentren in Deutschland betrieben und Kundendaten gemäß DSGVO verarbeitet und gespeichert werden. Die Managed-Kubernetes-Seite gibt an, dass Kubernetes-Daten in ISO 27001-zertifizierten, DSGVO-konformen Rechenzentren in Deutschland verarbeitet und gespeichert werden. Der SCS-Artikel 2024 unterhttps://www.cloudandheat.com/en/news-press/strengthening-digital-sovereignty-new-ways-in-the-cloud-with-yaook-and-scs-compatibility/diskutiert ein Rechenzentrumsprojekt in Leipzig mit envia TEL, Yaook und SCS. Die Zertifizierungsneuigkeit von 2026 von derselben Website besagt, dass Cloud & Heat die Anerkennung "Certified SCS-compatible IaaS" erhalten hat und die Auszeichnung auf dem SCS Summit am 21. Juni 2026 überreicht werden sollte. Diese Punkte machen den Fußabdruck mehr als eine reine AS-Port-Geschichte, aber sie verwandeln nicht die gesamte Kapazitätskarte in öffentliches Wissen.

Strom und Kühlung sind Teil der physischen Abhängigkeit, nicht nur eine Nachhaltigkeitsbehauptung. Die IaaS-Seite gibt an, dass Cloud & Heat direkte Warmwasserkühlung und Integration in lokale Heizkreisläufe nutzt, um energieeffizienten Betrieb und Wiederverwendung von Serverabwärme zu ermöglichen. Die OpenStack-Marketplace-Seite beschreibt ebenfalls wassergekühlte Server und Wiederverwendung von Serverabwärme. Dies ist ein nützlicher Kontext: Wenn die Cloud um Wärmewiederverwendung herum konzipiert ist, werden das Gebäude, der Wasserkreislauf, der Wärmetauscher, die lokale Wärmeabnahme und die Wartungsfenster Teil der Serviceabhängigkeit.

Ein Kunde eines konventionellen Rechenzentrums fragt hauptsächlich nach Strom- und Kühlungsredundanz. Ein Cloud-&-Heat-Kunde sollte auch fragen, wie die Wartung der Wärmewiederverwendung von der Rechenverfügbarkeit isoliert ist.

Die Dresdner Belege stützen daher eine mittlere Behauptung. Es gibt öffentliche Belege für einen Interkonnektionspunkt in Dresden und öffentliche Unternehmensbelege für deutsches Cloud-Hosting. Es gibt nicht genügend öffentliche Belege, um jeden Kunden-Workload auf ein Rack, jede Verfügbarkeitszone auf ein Gebäude oder jede GPU-Instanz auf eine bestimmte Strom- und Kühlungskette abzubilden. Käufer können Dresden als bedeutendes Betriebszentrum betrachten, nicht als vollständiges Infrastrukturdiagramm.

Die Produktbelege sind für OpenStack und Kubernetes stärker als für Ersatzkapazität

Die Produktseiten von CLOUD & HEAT sind für einen regionalen Cloud-Anbieter ungewöhnlich konkret. Die IaaS-Seite listet Rechengrößen von 1 vCPU / 2 GB RAM / 15 GB SSD bis 8 vCPU / 30 GB RAM / 100 GB SSD, bietet Standard- und Memory+-Preisfamilien, bewirbt HDD-Block-/Objektspeicher und gibt an, dass die Speichercluster Ceph-Dreifachredundanzcluster für Objekt- und Blockspeicher sind. Sie listet auch GPU-Instanzklassen inklusive T4, A10, V100 und A100. Diese Seite gibt explizit an, dass ein dreifach replizierter NVMe-Pool in den verfügbaren Kapazitäten bereitgestellt werden kann.

Dieser Satz ist wichtig: Das Unternehmen verkauft nutzbare Ressourcen, erkennt aber auch an, dass bestimmte Speicherklassen eine begrenzte Kapazität haben.

Die Managed-Kubernetes-Seite ist ebenso spezifisch. Sie beschreibt eine selbstverwaltete Option auf OpenStack, On-Demand-Support, Managed Kubernetes Basic mit 9/5-Support und vierstündiger Reaktionszeit sowie Managed Kubernetes Full Service mit verschiedenen Support-Stufen. Beide verwalteten Stufen listen Deployment über mehrere Verfügbarkeitszonen für Hochverfügbarkeit, API-Schutz über VPN, GitOps-basierte Clusterverwaltung, Load-Balancer-Service, OpenStack Cinder persistente Volumes, statischen und dynamischen lokalen Speicher und Netzwerkrichtlinien auf.

Full Service fügt Ingress, Certmanager, einen Prometheus- und Grafana-Überwachungsstack, 24/7-Cluster-Überwachung und Benachrichtigungen sowie GPU-Instanzen hinzu. Dies sind operative Behauptungen, nicht nur Slogans.

Die Patron-Seite verstärkt den OpenStack-Aspekt der Geschichte. Sie gibt an, dass Cloud & Heat Patron eine sofort einsatzbereite OpenStack-Distribution ist, die auf dem Open-Source-Lebenszyklusmanagement mit Yaook basiert, mit Enterprise-Komponenten, SCS-Kompatibilität, Automatisierung, keinem Vendor-Lock-in und Support-Optionen. Die Seite bietet ein Modell, bei dem der Kunde die Cloud betreibt, und ein Modell, bei dem Cloud & Heat Betrieb und Überwachung, Fehleranalyse, Fehlerbehebung und Wartung wie Updates bereitstellt. Sie erwähnt 9-5- und 24/7-Supportvertragsoptionen.

Dies sagt uns, dass CLOUD & HEAT nicht nur virtuelle Maschinen weiterverkauft; es verkauft Betriebswissen rund um OpenStack selbst.

Die OpenInfra-Quellen bestätigen die Open-Infrastructure-Positionierung. Die OpenStack-Marketplace-Seite unterhttps://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-serviceslistet die Cloud-&-Heat-Clouddienste auf und gibt an, dass das Produkt OpenStack Powered ist. Das OpenInfra-Supporting-Organizations-Profil unterhttps://www.openstack.org/community/supporting-organizations/profile/cloud-and-heatbeschreibt den Technologie-Stack als OpenStack, Kubernetes, Yaook und Krake und gibt an, dass das Unternehmen zu den Bemühungen von Sovereign Cloud Stack beiträgt. Die SCS-Standard-Forum-Seite unterhttps://sovereigncloudstack.org/en/about-scs/forum-scs-standards/listet Cloud & Heat Technologies GmbH als ein engagiertes Mitglied für sichere Cloud-Infrastrukturen und notiert die Zusammenarbeit mit der Open Infrastructure Foundation.

Das Kundensignal ist ebenfalls öffentlich. Die IaaS-Seite nennt Scalytics, tracetronic, Nyris, elevait, alphaspeech und flow.d als Kunden. Die Managed-Kubernetes-Seite nennt N+P Informationssysteme GmbH und elevait GmbH & Co. KG. Die Startseite enthält Zitate von N+P, elevait und STACKIT: N+P und elevait beschreiben Cloud & Heat als ihren Managed-Kubernetes-Anbieter, während STACKIT Cloud & Heat als Cloud-Technologiepartner beschreibt, der bei OpenStack-Know-how hilft. Die OpenStack-Marketplace-Seite verweist auf Kundenfallstudien für elevait, N+P, Nyris und flow.d.

Dies sind bedeutende Signale von betroffenen Parteien, aber kein Mandanteninventar.

Die Unterscheidung zwischen installiert und nutzbar ist der Punkt, an dem die Analyse verlangsamt werden muss. Installierte Kapazität umfasst Server, Speicher, GPUs, Switches, DD-IX-Ports, Upstream-Anbieter, OpenStack-Cluster, Kubernetes-Control-Planes und Support-Tools unter der Kontrolle oder Verwaltung des Unternehmens. Nutzbare Kapazität ist der Teil, den ein Kunde bestellen, zuweisen, betreiben, wiederherstellen und ohne inakzeptable Ausfallzeit verlassen kann. Die öffentlichen Seiten zeigen Produktklassen, Support-Modelle, Kundennamen und Technologieentscheidungen.

Sie zeigen nicht den aktuellen GPU-Bestand, Quoten pro Geschmacksrichtung, die Gesamtzahl der Hypervisoren, das Ceph-Fehlerdomain-Design, Überbelegungsverhältnisse, Wartungspläne, Backup-Aufbewahrung oder getestete Wiederherstellung zwischen Zonen.

Die Erwähnung "in den verfügbaren Kapazitäten" in der NVMe-Speichernotiz ist ein nützliches Fenster zur Realität der kleineren Cloud-Ökonomie. Ein Cloud-Anbieter kann eine Speicherklasse bewerben und dennoch diese Klasse einschränken, weil Hochleistungsfestplatten teuer sind, die Standortstromversorgung begrenzt ist, die Speicherreplikation Bruttokapazität verbraucht und die Kundennachfrage schwankt. Das macht das Angebot nicht schwach. Es macht es physisch.

Ein Käufer sollte jede Servicezeile in eine Kapazitätsfrage übersetzen: Wie viel ist installiert, wie viel ist reserviert, wie viel kann diesen Monat geliefert werden und was passiert, wenn die Nachfrage steigt?

Das Upstream-, Support- und Reparaturrisiko liegt unter der Marketingebene

Die öffentliche Routing-Policy in der RIPE-Datenbank listet AS3320, AS15372, AS6830 und AS8220 um AS203592 herum auf. Der Endpunkt der beobachteten Nachbarn von RIPEstat unterhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS203592sah am 14. Juli 2026 AS15372, AS3320, AS8220 und AS213973. RIPEstat identifiziert AS15372 als IBH connect unterhttps://stat.ripe.net/data/as-overview/data.json?resource=AS15372, AS3320 als Deutsche Telekom unterhttps://stat.ripe.net/data/as-overview/data.json?resource=AS3320, AS8220 als Colt unterhttps://stat.ripe.net/data/as-overview/data.json?resource=AS8220, AS6830 als Liberty Global unterhttps://stat.ripe.net/data/as-overview/data.json?resource=AS6830und AS213973 als BCIX Management unterhttps://stat.ripe.net/data/as-overview/data.json?resource=AS213973. Dies ist eine glaubwürdige Mischung aus lokalen, nationalen und kommerziellen Konnektivitätssignalen.

Der Vorbehalt ist, dass eine Liste öffentlicher Nachbarn keine vertragliche Karte ist. Sie sagt nicht, welcher Pfad bezahlter Transit, welcher Pfad Peering, welcher Pfad Backup ist, welche Präfixe wo akzeptiert werden, welche Routenfilter streng sind, welche Wartungsfenster sich überschneiden oder ob der Kundenverkehr an eine bestimmte Grenze gebunden ist. Sie beweist auch nicht, dass ein Kubernetes-API-Endpunkt und ein IaaS-Speicher-Backend denselben Netzwerkschutz haben. Die gute Nachricht ist, dass AS203592 öffentlich nicht als Ein-Nachbar-Insel sichtbar ist.

Die Bereitstellungsfrage ist, ob der relevante Kundendienst genügend tatsächliche Pfadvielfalt hat, um den spezifischen Ausfall zu überleben, der den Kunden betrifft.

Der Standortausfall ist die nächste Ebene. Wenn ein Workload in einem deutschen Rechenzentrum läuft, das mit AS203592 verbunden ist, hängt der Dienst von der Rack-Stromversorgung, Kühlung, aufwärtigen Querkabeln, Switches, Routern, Speichernetzwerken und Personalzugang ab. Der PeeringDB-Standort für IBH Dresden C2 listet diverse serving substations=true, was ein positives Zeichen auf Standortebene ist.

Es offenbart immer noch nicht die Stromversorgungsauslegung der Racks von CLOUD & HEAT, Dual-Cord-Abdeckung, Wartungsbypass, Batterieautonomie, Generator-Testverlauf oder ob eine bestimmte Kunden-VM während eines lokalen Vorfalls aus der betroffenen Einrichtung verschoben werden kann. Die DD-IX-Verbindung hilft beim lokalen Verkehrsaustausch, aber ein Exchange-Ausfall und ein Rechenzentrumsausfall sind unterschiedliche Ereignisse.

Der Support-Ausfall ist ebenso wichtig. Die Managed-Kubernetes-Seite gibt ein 9/5-Support-Level mit vierstündiger Reaktionszeit für Basic und 24/7-Überwachung und Benachrichtigungen für Full Service. Die Patron-Seite bietet 9-5- und 24/7-Supportvertragsoptionen für betriebene OpenStack-Umgebungen. Die IaaS-Seite verspricht persönliche, serviceorientierte Beratung von OpenStack- und DevOps-Experten. Dies sind nützliche öffentliche Zusagen, aber der Kunde braucht dennoch den Vertrag.

Die Seite offenbart nicht die Eskalationsziele für einen Speicherausfall, Hypervisor-Evakuierung, GPU-Austausch, Route-Leak, DNS-Ausfall, Missbrauchsticket, Abrechnungssperre oder Notfalldatenexport.

Der DNS-Nachweis fügt einen kleinen, aber nützlichen operativen Hinweis hinzu. Eine DNS-Abfrage während dieser Überprüfung löste www.cloudandheat.com über cloudandheat.com nach 185.128.119.78 auf, das sich im Präfix 185.128.116.0/22 von AS203592 befindet. Dieselbe Abfrage zeigte mail.cloudandheat.com als MX, Nameserver INWX und SPF-Einträge, die den Mail-Host und Google enthalten. Dies deutet darauf hin, dass die öffentliche Website vom gerouteten Raum des Unternehmens und nicht nur von einem großen CDN eines Drittanbieters bereitgestellt wird.

Dies ist positiv für die Netzidentität, bedeutet aber auch, dass die öffentliche Website des Unternehmens von seinem eigenen AS, seinem Webhost oder seinen Standortabhängigkeiten beeinflusst werden kann.

Der Kundenauswirkungspfad ergibt sich aus dem Produkt-Stack. Ein Netzwerkausfall kann die Erreichbarkeit der öffentlichen Cloud, der verwalteten Kubernetes-APIs, Load-Balancer, Kunden-Ingress, Softwareverteilungspunkte und möglicherweise die eigene Website oder Support-Oberflächen des Anbieters beeinträchtigen. Ein Speicherausfall kann Volumes und Objektspeicher beeinträchtigen. Ein Strom- oder Kühlungsvorfall kann Hypervisoren und GPU-Maschinen beeinträchtigen. Ein Support- oder Betriebsengpass kann die Wiederherstellungszeit verlängern, selbst wenn die Hardware reparierbar ist.

Ein Vertrags- oder Abrechnungsausfall kann Änderungen, Exporte oder dringende Skalierung blockieren. Das öffentliche Material beweist, dass das Unternehmen Erfahrung in diesen Bereichen hat; es beweist nicht, dass jeder Ausfallpfad geübt wurde.

Dies ist keine Kritik, die nur CLOUD & HEAT betrifft. Es ist die Normalform der regionalen Cloud-Abhängigkeit. Der Anbieter kann transparenter, stärker auf Open Source ausgerichtet und lokaler sein als eine Hyperscale-Plattform, während er dennoch denselben physischen Einschränkungen unterliegt: Platz, Strom, Kühlung, Optik, Ersatzteile, Routenfilter, Wartungsfenster und menschliche Verfügbarkeit.

Die Datenlokalität ist eine Stärke, aber Lokalität ist nicht automatische Wiederherstellbarkeit

Das stärkste Versprechen von CLOUD & HEAT an die Leser ist Lokalität und digitale Souveränität. Die IaaS-Seite gibt an, dass die öffentliche Cloud-Infrastruktur ausschließlich in Rechenzentren in Deutschland betrieben wird und Daten gemäß DSGVO verarbeitet und gespeichert werden. Die Managed-Kubernetes-Seite gibt an, dass Daten in ISO 27001-zertifizierten, DSGVO-konformen Rechenzentren in Deutschland verarbeitet und gespeichert werden. Die Startseite gibt an, dass Kunden die Infrastruktur von CLOUD & HEAT oder On-Premises-Deployments nutzen können.

Die SCS- und OpenInfra-Quellen positionieren das Unternehmen rund um offene Standards, Portabilität und digitale Souveränität.

Diese Behauptungen zählen. Ein deutscher oder europäischer Kunde, der versucht, undurchsichtiges Offshore-Hosting zu vermeiden, hat ein anderes Risikomodell, wenn die öffentliche Cloud-Seite Deutschland, OpenStack und Open-Source-Stack anstelle einer generischen globalen Region angibt. Das SCS-bezogene Material ist wichtig für die Interoperabilität. Der Unternehmensartikel von 2024 gibt an, dass SCS-Standards darauf abzielen, die Interoperabilität und Portabilität von Cloud-Anwendungen zu erhöhen. Die Zertifizierungsneuigkeit von 2026 gibt an, dass Cloud & Heat die Anerkennung "Certified SCS-compatible IaaS" erhalten hat.

Das OpenInfra-Profil gibt an, dass das Unternehmen zu Standards wie SCS beiträgt. All dies ist für das Thema Souveränität und Datenlokalität relevant.

Lokalität sollte jedoch nicht mit Wiederherstellung verwechselt werden. Ein Kunde kann wissen, dass sich die Daten in Deutschland befinden, aber immer noch nicht wissen, ob sie zwischen Dresden und Leipzig, zwischen zwei Räumen in Dresden, über zwei Verfügbarkeitszonen in einem einzigen Gebäude oder innerhalb eines einzigen Speicherclusters mit Fehlerdomänen repliziert werden. Die Managed-Kubernetes-Seite gibt ein Deployment über mehrere Verfügbarkeitszonen für Hochverfügbarkeit an, definiert diese Zonen jedoch nicht öffentlich.

Die IaaS-Seite gibt Ceph-Dreifachredundanzcluster und einen optionalen, dreifach replizierten NVMe-Pool in der verfügbaren Kapazität an, offenbart jedoch nicht, ob die Repliken racklokal, raumlokal, gebäudelokal oder campusgetrennt sind. Die öffentlichen Seiten zeigen nicht den Backup-Standort oder die Wiederherstellungshistorie.

Dies ist wichtig für Kunden mit Compliance-Verpflichtungen. Wenn ein Workload deutschen Speicher benötigt, stützen die öffentlichen Seiten von CLOUD & HEAT die anfängliche Behauptung. Wenn der Workload ein bestimmtes deutsches Bundesland, eine bestimmte Stromzone, Verfügbarkeitszonentrennung, Backup-Segregation, Air-Gap-Export oder einen regulierten sektoralen Kontinuitätsplan benötigt, reichen die öffentlichen Seiten nicht aus.

Der Kunde sollte eine Erklärung zum Datenstandort, zu Unterauftragsverarbeitern, zum Backup-Standort, zum Speicherreplikationsumfang, zum Personalzugriff, zu Wartungsfenstern und zur getesteten Wiederherstellung anfordern. Wenn der Workload Managed Kubernetes verwendet, sollte der Kunde auch fragen, wo sich Control Plane, etcd, persistente Volumes, Image-Registry, Überwachungsdaten und Logs befinden.

Der Migrationspfad ist aufgrund der Technologieauswahl klarer. OpenStack, Kubernetes, Cinder-Volumes, Ceph-Speicher, GitOps und SCS-Kompatibilität können die Bindung verringern, wenn sie mit Exportrechten und getesteten Tools implementiert werden. Ein Kunde kann Infrastructure as Code ausführen, externe Backups pflegen, DNS unter eigener Kontrolle behalten, Anwendungen containerisieren und eine Ziel-OpenStack- oder Kubernetes-Umgebung vorbereiten. Aber die öffentlichen Seiten versprechen nicht, dass jedes Image, Volume, Snapshot, Objekt-Bucket, jede Floating-IP, jeder Load-Balancer oder GPU-Workload schnell exportiert werden kann.

Standardtechnologien machen Migration möglich; sie machen sie nicht automatisch.

Das richtige Fazit ist daher gemischt. CLOUD & HEAT hat eine glaubwürdige Souveränitätsgeschichte, da es deutsches Hosting, OpenStack, Kubernetes, SCS-Arbeit und lokale Interkonnektion kombiniert. Dieselbe Geschichte muss an der Servicegrenze getestet werden: Welcher Service wird in Deutschland gehostet, welcher Teil ist beim Kunden vor Ort, welcher Teil hängt von IBH oder DD-IX ab, welcher Teil hängt von E-Mail oder DNS Dritter ab, und welcher Teil kann sich während eines Anbieterausfalls bewegen? Souveränität betrifft nicht nur das Land. Sie betrifft die Kontrolle unter Stress.

Wer ist betroffen, wenn cnh-primary ausfällt?

Die erste betroffene Gruppe sind Public-Cloud- und IaaS-Kunden. Die IaaS-Seite nennt Kunden wie Scalytics, tracetronic, Nyris, elevait, alphaspeech und flow.d. Sie verkauft Compute-, GPU- und Speicherressourcen und positioniert die Cloud für deutschen Datenschutz und digitale Souveränität. Wenn AS203592 oder der relevante Standortpfad ausfällt, können Kunden-VMs eingeschaltet bleiben, aber unerreichbar werden. Wenn die Speicherebene ausfällt, werden Datenverfügbarkeit und Volume-Anbindung zum Problem. Wenn die Kapazität erschöpft ist, kann der Kunde möglicherweise nicht skalieren, selbst wenn bestehende Instanzen weiterlaufen.

Die zweite Gruppe sind Managed-Kubernetes-Kunden. Die Managed-Kubernetes-Seite nennt N+P Informationssysteme GmbH und elevait GmbH & Co. KG. Sie beschreibt API-Zugriff über VPN, OpenStack Cinder persistente Volumes, Load-Balancer, Überwachung, Ingress, Certmanager und Multi-Zonen-Deployment. Wenn die Cloud-Ebene des Anbieters ausfällt, kann Kubernetes Pods neu planen, aber Volumes, Ingress oder externe Erreichbarkeit verlieren. Wenn die Control Plane oder der VPN-Pfad ausfällt, können Entwickler den Verwaltungszugriff verlieren.

Wenn der Überwachungsstack Teil des Full-Service-Angebots des Anbieters ist, kann die Sichtbarkeit von Vorfällen gleichzeitig mit dem Dienst selbst abnehmen.

Die dritte Gruppe sind Kunden, die CLOUD & HEAT eher als OpenStack-Betriebspartner denn als Host nutzen. Die Startseite zitiert STACKIT mit der Aussage, dass Cloud & Heat die Entwicklung und Erweiterung der Cloud-Infrastruktur mit OpenStack-Know-how unterstützt. Die Patron-Seite vertreibt eine OpenStack-Distribution, Installation, Inbetriebnahme, Betrieb, Überwachung, Fehleranalyse und Updates. Ein AS203592-Ausfall kann eine kundenbetriebene Cloud möglicherweise nicht direkt betreffen, aber ein Support-Ausfall kann bei Upgrades, Vorfällen oder dringenden Änderungen dennoch erfolgen.

Beratungs- und Managed-Operations-Kunden sind von der Personalverfügbarkeit, dem Remote-Zugriff, der Dokumentation und der Eskalation betroffen, nicht unbedingt von cnh-primary-Routen.

Die vierte Gruppe sind regionale Netzwerke und lokale Verkehrsteilnehmer. Die PeeringDB- und DD-IX-Belege platzieren AS203592 auf DD-IX in Dresden. Ein lokaler Exchange-Pfad kann die regionale Latenz und Ausfallsicherheit verbessern, wenn er funktioniert; er kann auch zu einer Abhängigkeit werden, wenn Kunden davon ausgehen, dass lokaler Verkehr lokal bleibt. DD-IX selbst ist ein breiterer Exchange mit mehreren Entitäten und Standorten, ein Problem von CLOUD & HEAT ist also nicht automatisch ein Problem von DD-IX.

Aber Kunden, die Dienste in Dresden nutzen, sollten sowohl den Status von AS203592 als auch von DD-IX überwachen, da der lokale Interkonnektionspfad Teil der Leistungsgeschichte ist.

Die fünfte Gruppe ist die öffentliche Präsenz des Anbieters selbst. DNS hat www.cloudandheat.com in 185.128.116.0/22 platziert. Wenn dasselbe Netzwerk oder derselbe Hosting-Stack die öffentliche Website des Unternehmens unterstützt, kann ein Infrastrukturvorfall die Produktseiten und einige Kundeneingangspunkte unerreichbar machen, genau dann, wenn Kunden Informationen benötigen. Der öffentliche DNS-Nachweis beweist nicht, dass das Ticket-System auf demselben Stack läuft, und der SPF-Eintrag enthält Google, sodass E-Mail möglicherweise einen anderen Abhängigkeitspfad hat.

Dennoch sollte die öffentliche Kommunikation Teil der Due Diligence des Kunden sein: Wo befindet sich die Statusseite, was passiert, wenn die Hauptwebsite nicht erreichbar ist, und welche Notfallkontakte bleiben erreichbar?

Deshalb muss die Sprache des betroffenen Gebiets konservativ sein. Die Betroffenheit markiert die Region als Global, da Cloud- und gehostete Dienste weltweit zugänglich sind und die Verzeichniskategorie globaler Cloud-Dienst lautet. Die stärkste Betriebsregion in den öffentlichen Belegen ist Deutschland, insbesondere Dresden und Sachsen, mit einer dokumentierten DD-IX-Anbindung und Behauptungen deutscher Rechenzentren. Kunden außerhalb Deutschlands können die Dienste dennoch nutzen, aber die physische Abhängigkeit ist nicht global im Hyperscale-Sinn. Es ist ein deutscher Cloud- und Cloud-Technologie-Anbieter mit globaler Reichweite.

Die Redundanzbelege sind am Netzwerkrand gut und auf Serviceebene unvollständig

Es gibt mehrere positive Redundanzsignale. AS203592 hat vier beobachtete Nachbarn in RIPEstat, nicht einen. Es hat zum Zeitpunkt der Abfrage öffentliche Routingsichtbarkeit im gesamten beobachteten RIS-Peer-Set für IPv4 und IPv6. Es hat gültige RPKI-Ursprünge für alle vier beobachteten Präfixe. PeeringDB zeigt Route-Server-Teilnahme an DD-IX. Die Managed-Kubernetes-Seite verspricht Multi-Zonen-Deployment für Hochverfügbarkeit. Die IaaS-Seite erwähnt Ceph-Dreifachredundanzcluster und eine optionale dreifach replizierte NVMe-Option. Die Patron-Seite bietet Betriebs- und Überwachungsverträge, einschließlich 24/7-Optionen.

Die Lücken sind ebenso wichtig. Die öffentliche Routingsichtbarkeit offenbart kein Traffic-Engineering. Der 10-Gbps-DD-IX-Port von PeeringDB zeigt keine Auslastung oder Failover. Die RPKI-Gültigkeit beweist keine Vorbereitung auf Routenänderungen. "Mehrere Verfügbarkeitszonen" definiert keine Explosionsradius-Trennung. "Ceph-Dreifachredundanz" gibt keine Replikplatzierung an. "24/7-Überwachung" offenbart kein Antwortpersonal, keine Eskalationsbefugnis oder Wiederherstellungsziele. ISO-Zertifikate und OpenStack-Powered-Status zeigen eine Prozess- und Technologiehaltung, aber dies sind keine Vorfallaufzeichnungen.

Ein Käufer sollte diese öffentlichen Behauptungen nicht in eine pauschale Hochverfügbarkeitsgarantie übersetzen.

Der stärkste praktische Redundanzbeleg, den ein Käufer anfordern kann, ist kein Prospekt. Es ist ein durchgeführter Wiederherstellungstest: Nehmen Sie eine repräsentative VM, ein Volume, einen Objekt-Bucket, einen Kubernetes-Workload und eine Datenbank; simulieren Sie einen Zonenausfall; messen Sie die Wiederherstellungszeit; testen Sie den DNS-Wechsel; exportieren Sie Images und Volumes; bauen Sie bei einem zweiten Anbieter oder Kundenstandort wieder auf; und überprüfen Sie die Anwendungskonsistenz.

Fragen Sie für Kubernetes, wie etcd, persistente Volumes, Ingress-Controller, Load-Balancer und Registry-Abhängigkeiten wiederhergestellt werden. Fragen Sie für OpenStack, wie sich Nova, Neutron, Cinder, Glance, Keystone, Ceph und externes DNS verhalten, wenn ein Speicherknoten, Hypervisor, Router oder Standortlink ausfällt.

Der Migrationsnachweis sollte ebenfalls produktspezifisch sein. Ein IaaS-Kunde benötigt Image-Export, Snapshot/Volume-Export, Objektdatentransfer, Adressänderungsplanung und Quotenfreigabe. Ein Kubernetes-Kunde benötigt Manifeste, Helm-Charts, GitOps-Repos, Secret-Management, persistente Volumes-Migration und externes Backup. Ein GPU-Kunde benötigt alternative Hardwareverfügbarkeit und Treiberkompatibilität. Ein On-Premises-Patron-Kunde benötigt Dokumentation, Runbooks, Update-Pfade und das Recht, bei Supportwechsel weiterzubetreiben. Dies sind unterschiedliche Tests, und die öffentlichen Seiten beantworten nicht alle.

Das Unternehmen profitiert von seinen Open-Source-Entscheidungen. OpenStack und Kubernetes reduzieren einige Lock-ins im Vergleich zu rein proprietären Plattformen. Die SCS-Kompatibilität soll die Interoperabilität und Portabilität erhöhen. Yaook und Tarook deuten auf automatisiertes Lebenszyklusmanagement hin. Aber der Wert offener Standards zeigt sich nur, wenn der Kunde seine Konfiguration, Backups, Anmeldeinformationen und Build-Anweisungen kontrolliert. Open Source ist kein Ersatz für Exit-Planung. Es ist die Grundlage für einen besseren Exit-Plan.

Die endgültige Abhängigkeitsstufe

cnh-primary CLOUD & HEAT Technologies GmbH sollte vom anfänglichen Verdacht eines "dünnen Fußabdrucks" aufgewertet werden. Die öffentlichen Belege sind nicht dünn. AS203592 lebt. RIPE zeigt aktuelle Ankündigungen, gültige Ursprünge und deutsche Nummernressourcen. PeeringDB zeigt einen Standort in Dresden und eine DD-IX-Anbindung. Die Website des Unternehmens verkauft IaaS und Managed Kubernetes mit erheblichen technischen Details. OpenStack- und OpenInfra-Quellen bestätigen die Rolle des Unternehmens in der offenen Cloud-Infrastruktur. SCS-bezogene Quellen stützen die Souveränitäts- und Interoperabilitätsgeschichte.

Kundenreferenzen sind sichtbar.

Die Herabstufung betrifft nicht die Existenz. Sie betrifft den Resilienznachweis. Die öffentlichen Belege offenbaren nicht die gesamte installierte Rechenleistung, den GPU-Bestand, die Bruttospeicherkapazität, die Anzahl der Mandanten, das Zonendesign, die Rack-Anzahl, die vertraglichen Standortbedingungen, die Stromtopologie, die Remote-Support-Verfahren, den Backup-Standort, die Wiederherstellungshistorie, die Vorfallhistorie, die genauen Support-Mitarbeiterzahlen oder getestete Kundenausstiege. Die Formulierung "in den verfügbaren Kapazitäten" auf der IaaS-Seite ist eine nützliche Erinnerung daran, dass die nutzbare Kapazität endlich ist.

Ein Käufer sollte jeden öffentlichen Kapazitätssatz als Einladung betrachten, den Bestand, die Quoten und die Wiederherstellungspfade zu überprüfen.

Die nützlichste Stufe ist geteilt. Netzidentität und Routing-Belege: Stark. Produkt- und Kundenbelege: Stark. Standort- und lokale Interkonnektionsbelege: Mittel-Stark, da Dresden und DD-IX sichtbar sind, aber der gesamte Cloud-Fußabdruck nicht öffentlich kartiert ist. Belege für die Resilienz der gehosteten Kapazität: Mittel, da die öffentlichen Seiten konkrete Behauptungen zu Verfügbarkeit, Support und Speicher aufstellen, aber vor harten Beweisen haltmachen. Migrationsbelege: Mittel, unterstützt durch OpenStack, Kubernetes und SCS, aber abhängig von Vertragsbedingungen und Kundenbereitschaft.

Der praktische Test ist, ob ein Kunde diese öffentlichen Stärken in operative Kontrolle umwandeln kann. Ein Käufer, der Cloud & Heat als strategischen deutschen Cloud-Anbieter in Betracht zieht, sollte einen aktuellen Kapazitätsstatus anfordern, nicht nur einen Servicekatalog: CPU, Arbeitsspeicher, GPU, Blockspeicher, Objektspeicher, Backupspeicher und Netzwerkquotient pro Standort oder Verfügbarkeitszone.

Er sollte fragen, ob eine neue VM während eines partiellen Speicherereignisses provisioniert werden kann, ob ein Kubernetes-Cluster ohne anbietereigene Secrets neu aufgebaut werden kann, ob Floating-IPs während der Routerwartung neu zugewiesen werden können, ob Objektdaten ohne Einschränkung exportiert werden können und ob der Support dringende Änderungen durchführen kann, wenn die öffentliche Website oder ein Peering-Pfad beeinträchtigt ist. Dies sind gewöhnliche Fragen für eine ernsthafte gehostete Kapazität. Sie schwächen die Geschichte des Unternehmens nicht; sie machen die soliden öffentlichen Belege nutzbar.

Für die Überwachung: Verfolgen Sie AS203592, 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29, 2a0c:2c0:dd80::/44, den DD-IX-Port, die Website cloudandheat.com und die öffentlichen Status- oder Support-Pfade. Für die Bereitstellung: Fordern Sie Standorterklärungen, Verfügbarkeitszonendefinitionen, Routing-Diversitätsnachweise, Support-Reaktionsbedingungen, Backup- und Exportnachweise und einen getesteten Migrationsplan an. Das Unternehmen hat eine glaubwürdige Infrastruktur.

Der Entscheidungspunkt ist, ob der spezifische Dienst, den ein Kunde kauft, über ausreichende nutzbare Kapazität und wiederholte Wiederherstellung verfügt, um die physischen Ausfälle zu überleben, die jede gehostete Kapazität irgendwann trifft.