TEMPLE Cloud Temple SAS verkauft gehostete Kapazität, die weiterhin von Racks, Transit und Reparaturfenstern abhängt

Zusammenfassung

• TEMPLE Cloud Temple SAS entspricht einem sichtbaren französischen Sovereign-Cloud-Geschäft: Die öffentlichen Seiten von Cloud Temple beschreiben SecNumCloud-qualifizierte IaaS, VMware IaaS, OpenSource IaaS, Objektspeicher, Bare Metal, VPC, privates Backbone, Housing und Support-Dienste für regulierte Sektoren.
• Offizielle Compliance-Seiten geben an, dass der IaaS Secure Temple-Umfang VMware IaaS, OpenSource IaaS, S3-Objektspeicher, HSM-KMS-Verschlüsselung und Bare Metal umfasst, mit einer SecNumCloud v3.2-Gültigkeit bis zum 30. Mai 2028; dieselbe Seite führt PaaS OpenShift separat auf.
• Das öffentliche Routing ist real und aktuell: RIPEstat zeigte AS33930 am 12. Juli 2026 mit sechs IPv4-Präfixen und zwei IPv6-Präfixen, vollständigen RPKI-gültigen Origin-Ergebnissen in der geprüften Ansicht und breiter RIS-Sichtbarkeit.
• Das Risiko besteht nicht darin, dass der Anbieter keine öffentlichen Betriebsnachweise hat; das Risiko besteht darin, dass Zertifizierung, AS-Sichtbarkeit und Produktbezeichnungen einem Kunden nicht genau sagen, welches Rack, welche Verfügbarkeitszone, welcher Wiederherstellungspfad, welche Support-Stufe oder welcher Ausstiegsprozess eine bestimmte Arbeitslast schützt.
• Käufer sollten die öffentlichen Nachweise von Cloud Temple als starken Ausgangspunkt für die Due Diligence betrachten und dann die Platzierung der Arbeitslast, die Support-Eskalation, die Hardware-Verfügbarkeit, Wiederherstellungstests, die Verantwortung für Kundenleitungen, Abrechnungseffekte und Grenzen der Datenportabilität überprüfen, bevor sie kritische Systeme migrieren.

TEMPLE Cloud Temple SAS ist die Art von Cloud-Unternehmen, das von einer Verzeichniskarte aus einfach aussehen kann und kompliziert wird, sobald ein Kunde fragt, was tatsächlich funktionieren muss. Der Name deutet auf einen Sovereign-Cloud-Anbieter mit sichtbaren französischen Büros, Compliance-Behauptungen, einem gerouteten autonomen System, einem öffentlichen Support-Angebot, einer offiziellen Statusseite und technischen Dokumenten hin, die Compute, Speicher, Netzwerk, physisches Hosting und Verantwortungsgrenzen beschreiben. Das reicht aus, um eine schwache Betriebsstatus-Lesart zurückzuweisen.

Es reicht nicht aus, um jede Verfügbarkeits- oder Souveränitätsbehauptung als selbstausführend zu behandeln. Das Unternehmen verkauft gehostete Kapazität, aber die Kapazität hängt immer noch von realen Einrichtungsflächen, Strom, Verkabelung, Routenauswahl, Anbieterplattformen, Support-Arbeitskräften, Kundenkonfiguration, Wiederherstellungstests und Vertragsbedingungen ab.

Die„Who are we?“-Seitedes Unternehmens positioniert Cloud Temple im Umfeld sensibler Sektoren und nennt Industrie, Finanzen, Gesundheitswesen und den öffentlichen Sektor als die Märkte, in denen sein Versprechen von Bedeutung sein soll. DieStandortseitelistet Büros in Paris / La Défense, Lyon, Tours, Caen und Nantes auf, mit der Adresse in Paris / La Défense: Le Belvedere - SPACES, 1-7 Cours Valmy, 92800 Puteaux. Das ist ein nützlicher Identitätsnachweis, aber die Karte der Büros ist nicht die Infrastrukturkarte. Ein Käufer sollte eine Büroadresse nicht mit dem Standort verwechseln, an dem eine virtuelle Maschine, ein Bare-Metal-Blade, ein S3-Bucket, ein VPC-Gateway oder ein physisches Rack betrieben wird.

Die stärkeren öffentlichen Belege sind die Compliance und der Produktumfang. DieCompliance-Verfahrensseitevon Cloud Temple gibt an, dass das Unternehmen seit 2018 über eine ISO 27001-Zertifizierung für die Infrastruktur und seit 2022 für Managed Services verfügt, eine HDS-Zertifizierung für Gesundheitsdatenaktivitäten, eine SecNumCloud v3.2-Qualifikation, ISAE 3402-Berichterstattung und andere europäische Compliance-Einträge. Dieselbe Seite enthält die konkreteste Umfangsangabe: „IaaS Secure Temple“ wird unter SecNumCloud v3.2 mit Gültigkeit bis zum 30. Mai 2028 aufgeführt, und die Fußnote besagt, dass dieser Umfang VMware IaaS, OpenSource IaaS, S3 Object Storage, HSM-KMS-Verschlüsselung und Bare Metal umfasst. Das macht nicht jedes Produkt identisch, ordnet jedoch die wichtigsten Infrastrukturprodukte in einen öffentlichen Qualifikationsbereich ein.

DieSecNumCloud-Ansatzseitevon Cloud Temple macht das strategische Versprechen: Die Cloud soll das Vertrauen von Unternehmen und öffentlichen Einrichtungen schützen, und das Produktdesign soll mit anspruchsvollen europäischen Sicherheitsstandards übereinstimmen. Die Seite sagt auch, dass die Qualifikation die Einhaltung von mehr als 700 ANSSI-Anforderungen und bewährten Verfahren in technischen, physischen, vertraglichen und betrieblichen Bereichen bedeutet. Diese Aussage ist für das Infrastrukturrisiko wichtig, da sie ausdrücklich über Cyberkontrollen hinausgeht. Sie betrifft die Art und Weise, wie ein Anbieter geführt wird. Dennoch ist selbst eine umfassende Qualifikation kein Dokument zur kundenspezifischen Architektur. Sie sagt einem Krankenhaus, einem Versicherer, einer öffentlichen Einrichtung oder einem Industriekunden nicht, ob sein eigenes Tenant zwei Compute-Hosts hat, welche Verfügbarkeitszone die passive Kopie enthält oder ob seine Firewall-Änderung von der geltenden Support-Stufe abgedeckt ist.

Die Produktlinie zeigt, warum diese Details wichtig sind. Das Compute-Angebot von Cloud Temple erstreckt sich über mehrere Nutzungsmuster. Die öffentliche Website beschreibtOpenSource IaaSfür virtualisierte Infrastruktur auf einer souveränen Plattform,VMware IaaSfür VMware-Umgebungen in einer qualifizierten Cloud-Umgebung,Bare Metalfür dedizierte physische Server und VM Instances in der Vorschau für stärker gemeinsam genutzte Cloud-ähnliche virtuelle Maschinen. Die öffentlichen Dokumente des Unternehmens für OpenSource IaaS beschreiben Cisco UCS Compute, IBM Spectrum Virtualize und IBM FlashSystem Block Storage, Dell ECS Object Storage, Juniper Networking, dedizierte Compute Blades und Storage Volumes, monatliche Verbrauchsabrechnung, Regions- und Verfügbarkeitszonenkonzepte, Backups, Replikationsoptionen und API- oder Terraform-Betrieb. Das ist kein leichtgewichtiger Hosting-Katalog. Es ist ein physischer und betrieblicher Stack.

Der Stack hat eine spezifische Implikation: installierte Kapazität und nutzbare Kapazität sind nicht dasselbe. Eine Seite kann Blade-Klassen, Speicherklassen und Konnektivitätszahlen zeigen, während ein Kunde dennoch fragen muss, ob die exakte Klasse in der gewünschten Region verfügbar ist, ob das Hinzufügen eines weiteren Hosts Hardwarebestand erfordert, ob ein GPU-Blade eine Lieferzeit hat, ob die zweite Verfügbarkeitszone übereinstimmende Speicherleistung bietet und ob die Lizenzierung des Kunden Live-Failover ermöglicht.

Die OpenSource IaaS-Konzepte von Cloud Temple listen Blade-Klassen von ECO bis PERFORMANCE 4 mit Angaben zu Arbeitsspeicher, Kernanzahl, 10 Gbit/s- oder 25 Gbit/s-Konnektivität und, für die Spitzenklasse, NVIDIA L40S-GPUs ab dem 1. Mai 2024 auf. Das ist nützliches Detail. Es sagt einem Käufer auch, dass Kapazität nicht abstrakt ist: Sie wird von bestimmten Hardwarefamilien mit begrenztem Bestand geliefert.

Bare Metal verschärft diesen Punkt. DieBare-Metal-Dokumentationbeschreibt dedizierte physische Server, die mit verteiltem Block Storage, Cisco UCS Blades, IBM Spectrum Virtualize Storage, Platzierung in Verfügbarkeitszonen, KVM-ähnlichem Konsolenzugriff, ISO-Mapping, Stromversorgungsoperationen, VLAN-Tagging und zwei Netzwerkschnittstellen, deren Geschwindigkeit von der Blade-Klasse abhängt, verbunden sind. Das Produkt ist gerade deshalb attraktiv, weil es Kunden mehr Kontrolle über die Betriebsumgebung gibt. Aber diese Kontrolle schiebt einen Teil des Risikos zurück zum Kunden. Wenn ein Kunde seinen eigenen Hypervisor oder sein eigenes Betriebssystem installiert, kann Cloud Temple das Blade, den Speicher und den Plattformzugriff bereitstellen, aber der Kunde bleibt für die Entscheidungen verantwortlich, die Hardware in eine resiliente Anwendung verwandeln.

Die VMware-Seite hat eine ähnliche Spannung. Das VMware IaaS-Material von Cloud Temple beschreibt dedizierte Blade-, Speicher- und Netzwerkressourcen, vSphere-Kompatibilität, L2-VLANs, Übertragung zwischen Verfügbarkeitszonen, Intra-AZ-Latenz unter 3 ms und Inter-AZ-Latenz unter 5 ms in der dokumentierten Ansicht sowie Hochverfügbarkeit, die nur funktioniert, wenn ein Cluster das erforderliche Host-Design aufweist. Die öffentlichen Dokumente weisen darauf hin, dass ein automatischer Neustart auf einem anderen Hypervisor nicht möglich ist, wenn eine Verfügbarkeitszone nur einen Hypervisor enthält.

Das ist die Art von Satz, die ein Cloud-Versprechen in technische Realität umwandelt. Ein Kunde kann Infrastruktur von einem qualifizierten Anbieter kaufen und dennoch eine fragile Einzelhost-Umgebung aufbauen, wenn er die falsche Form wählt oder den zweiten Knoten verschiebt.

Speicher erfordert ebenfalls Präzision. Die öffentlicheObjektspeicherseitevon Cloud Temple sagt, dass der Dienst auf Dell Elastic Cloud Storage basiert, hohe S3-Kompatibilität bietet, SecNumCloud-qualifiziert, HDS- und ISO 27001-zertifiziert ist, automatisch über drei Verfügbarkeitszonen repliziert, EC 12+4 Erasure Coding verwendet, TLS 1.2/1.3 mit serverseitigen Verschlüsselungsoptionen unterstützt, 99,99 Prozent Verfügbarkeit und 99,999999999 Prozent Haltbarkeit verspricht und keine Egress-Gebühren bewirbt. Das sind ernsthafte Ansprüche für Käufer von Backup-, Archiv- und Anwendungsspeicher. Sie müssen dennoch auf die eigene Pflicht des Kunden bezogen werden, Lebenszyklus, Unveränderbarkeit, Schlüssel- und Wiederherstellungsrichtlinien festzulegen. Objektspeicher über drei Zonen hilft bei der Plattformhaltbarkeit; er allein beweist nicht, dass ein Kunde die richtige Objektversion nach Ransomware, versehentlicher Löschung, schlechtem Aufbewahrungsdesign oder einer Kompromittierung des Zugriffsschlüssels wiederherstellen kann.

Die Aufteilung der Verantwortlichkeiten ist nicht versteckt. DieShared-Responsibility-Seitevon Cloud Temple verweist auf RACI-Matrizen für IaaS, VM Instances, Objektspeicher, Netzwerk und andere Dienste. DieIaaS-Verantwortungsmatrixbesagt, dass Cloud Temple für die Implementierung physischer Rechenzentren, Compute-Infrastruktur, Speicherinfrastruktur, Backbone-Konnektivität, wesentliche Plattformsoftwarelizenzen, grundlegende Tenant-Konfiguration und erste Backup-Einrichtung verantwortlich und rechenschaftspflichtig ist. Sie besagt auch, dass der Kunde für die Definition der Gesamtarchitektur, die Anzahl der Tenants, die Anzahl der Verfügbarkeitszonen, die Kontinuitäts- und Wiederherstellungsstrategie, die Dimensionierung von Compute, Speicher, Netzwerk und Backup, das Erstellen und Warten virtueller Maschinen, die Zuordnung jeder VM zu kohärenten Backup- und Wiederherstellungsplänen sowie die Durchführung regelmäßiger Backup- und Wiederherstellungstests verantwortlich und rechenschaftspflichtig ist.

Diese Aufteilung ist wahrscheinlich die wichtigste Tatsache im gesamten Datensatz. Sie bedeutet, dass das Unternehmen ein qualifizierter Infrastrukturanbieter sein kann und dennoch kritische Designentscheidungen beim Kunden belässt. Wenn der Kunde ein Tenant unterdimensioniert, Backup-Tests auslässt, Workloads nicht über Zonen verteilt, eine fehlerhafte Firewall-Regel beibehält, den Administratorzugriff verliert oder einen einzelnen Anwendungsknoten innerhalb einer ansonsten resilienten Plattform behält, wird sich der Ausfall nicht wie ein einfacher Anbieterausfall verhalten.

Es wird ein gemeinsamer Architekturfehler sein, bei dem nur einige Schichten durch Anbieterverpflichtungen abgedeckt sind. Die Risikofrage des Artikels lautet daher nicht: „Ist TEMPLE Cloud Temple SAS ein echtes Cloud-Unternehmen?“ Die Antwort ist ja. Die Frage lautet: „Welcher Teil dieses Kundensystems liegt innerhalb des verantwortlichen Bereichs von Cloud Temple und welcher Teil ist immer noch das eigene Design des Kunden?“

Dieselbe Aufteilung zeigt sich im Netzwerk. DiePrivate Backbone-Dokumentationvon Cloud Temple besagt, dass das Produkt L2-VPLS-private Netzwerke über Verfügbarkeitszonen, private Internetzugangskomponenten, IP-Adressierung, nativen Anti-DDoS-Schutz, Ports für externe Konnektivität, 1G/10G-Leitungen und private Verbindungen auf zwei diversifizierten optischen Pfaden für dedizierte Leitungsprodukte bereitstellt. DieInternet-Konzepte-Seitegibt an, dass Cloud Temple ein eigenes AS betreibt, zwei Transitpfade und zwei Pariser Austauschpunkte bietet, BGP4 unterstützt, öffentliche IPv4-Adressen pro Einheit und IPv6-Präfixe bereitstellt, Internetbandbreite in 100 Mbit/s-Schritten reserviert und auf Basis des 95. Perzentils anstatt nach Volumen-Egress abrechnet. Dies sind wesentliche Fakten zum Netzwerkdesign, keine dekorativen Behauptungen.

Aber auch hier ist die Abgrenzung wichtig. DieNetzwerk-Verantwortungsmatrixbesagt, dass der Kunde für das Abonnieren von Betreiberkonnektivität verantwortlich und rechenschaftspflichtig ist, um auf ein physisches Cloud Temple-Rechenzentrum zuzugreifen, sowie für das Management von Vorfällen, Problemen und Kapazitäten auf den eigenen Betreiberleitungen des Kunden. Cloud Temple übernimmt die Verantwortung für das Backbone, die Sammelpunkte und die Verbindungspunkte der Rechenzentren, und die physische Unterbringung beginnt mit der Verantwortung ab der Top-of-Rack-Ausrüstung. Diese Abgrenzung ist genau der Punkt, an dem viele Vorfälle schmerzhaft werden. Ein Workload mag innerhalb von Cloud Temple gesund sein, aber ein Kundenstandort kann dennoch durch eine Enterprise-MPLS-Verbindung, eine Carrier-Zugangsleitung, eine fehlerhafte IPsec-Änderung, eine lokale Firewall, einen DNS-Fehler oder eine Kapazitätsgrenze auf der Kundenseite ausfallen.

Öffentliche Routing-Nachweise unterstützen die Vorstellung, dass das Unternehmen ein reales Netzwerk betreibt. RIPE RDAP fürAS33930nennt CLOUD-TEMPLE und führt Cloud Temple SAS als registrierte Entität auf, mit der Organisationsadresse Le Belvedere, 1 Cours Valmy, 92800 Puteaux. DieAS-Übersichtvon RIPEstat identifizierte den Inhaber als CLOUD-TEMPLE Cloud Temple SAS und zeigte das AS zum Abfragezeitpunkt am 12. Juli 2026 als angekündigt an. DieAnnounced-Prefixes-Ansichtvon RIPEstat zeigte acht aktive Ankündigungen im Zeitfenster zum 12. Juli 2026: 91.223.207.0/24, 45.15.212.0/22, 185.56.204.0/22, 194.6.240.0/24, 93.187.40.0/21, 80.75.152.0/21, 2a02:668::/36 und 2a02:668:9000::/36.

Dieser Routing-Eintrag ist stärker als ein rein marketingorientierter Fußabdruck. DieRouting-Status-Ansichtvon RIPEstat zeigte sechs IPv4-Präfixe, zwei IPv6-Präfixe, 6.656 angekündigte IPv4-Adressen, 8.192 IPv6-/48er, 54 beobachtete Nachbarn und eine nahezu vollständige RIS-Sichtbarkeit im geprüften Schnappschuss. Die Routing-Consistency-Ansicht von RIPEstat zeigte, dass die angekündigten AS33930-Präfixe sowohl in BGP- als auch in RIPE-Route-Policy-Quellen vorhanden waren, ohne eine Liste inkonsistenter Präfixe in der geprüften Ausgabe. Die RPKI-Validierung lieferte „valid“ für die acht geprüften AS33930-Präfix-Ursprungspaare. Diese Fakten sagen einem Kunden nicht, wie redundant ein bestimmter Dienst ist, aber sie zeigen, dass die Netzwerkschicht sichtbar, gewartet und nicht nur ein Altlastenrest ist.

Transit- und Peering-Nachweise sind ebenfalls nützlich, müssen jedoch sorgfältig gelesen werden. Die RIPE RDAP-Bemerkungen für AS33930 erwähnen Peering-Anfragen sowie France-IX- und Equinix Paris-Austauschdetails. DieCloud Temple Netzwerkseitevon PeeringDB führt das Netzwerk als Cloud Temple, mit dem älteren aka Namen Intrinsec von Cloud Temple, einer offenen allgemeinen Peering-Richtlinie und einem Aktualisierungsdatum im April 2025. Die öffentliche Exchange-Ansicht von PeeringDB zeigt Einträge für France-IX Paris und Equinix Paris IX mit 10 Gbit/s, während die Facility-Ansicht Telehouse Paris 2, Telehouse Paris 3, Equinix PA6, Digital Realty Paris PAR7 und DATA4 Paris Marcoussis - PAR1 als mit dem Netzwerkprofil verbundene Einrichtungen auflistet. Dies bestätigt die Interkonnektivität im Pariser Markt, ist aber dennoch ein öffentliches Peering-Profil und keine verbindliche Karte der Kunden-Workload-Platzierung.

Die öffentliche Statusseite fügt eine weitere Perspektive hinzu. DieStatusseitevon Cloud Temple stellt Komponenten unter FR1 dar, einschließlich AZ-Bezeichnungen wie PA6, PAR7, TH3, PAR7S, TH3S und AZ07, zusammen mit Kategorien für OpenIaaS, Object Storage, PaaS OpenShift, Bare Metal, VPC, Edge Services und öffentliche Schnittstellen. Eine Statusseite ist wertvoll, weil sie Kunden einen öffentlichen Ort bietet, um Vorfälle und Wartungsarbeiten zu beobachten. Sie beantwortet jedoch nicht die tiefergehende Frage von selbst: Welche dieser Verfügbarkeitszonen, Dienste und Komponenten nutzt dieser Kunde tatsächlich, und überlebt die eigene Anwendung des Kunden, wenn eine davon beeinträchtigt ist?

Die Ausfallpfade werden klarer, wenn die Produktlinie als ein System gelesen wird. Ein Rack- oder Einrichtungsausfall betrifft Compute, Speicher, Netzwerk und Housing je nach Platzierung unterschiedlich. Ein Upstream- oder Routenausfall betrifft internetseitige Dienste, Kundenpräfixe, VPN-Zugang und Support-Sichtbarkeit je nach BGP-Design unterschiedlich. Ein Ausfall des Hardwarebestands ist für Bare Metal, GPU-Blades, Speichererweiterung, Firewall-Appliances und Ersatzhosts relevant. Ein Support-Ausfall ist je nach Standard-, Premium- und Company-Stufe unterschiedlich.

Ein Abrechnungs- oder Bestellfehler kann die Bereitstellung oder Erweiterung verzögern. Ein Migrationsfehler kann Workloads stranden lassen, selbst wenn die Plattform gesund ist. Keines dieser Risiken bedeutet, dass der Anbieter schwach ist. Sie bedeuten, dass der Cloud-Vertrag als Infrastruktur gelesen werden muss und nicht als magische Abstraktion.

Die Support-Bedingungen sind Teil dieser Infrastruktur. DieSupport-Stufen-Seitevon Cloud Temple listet Standard-, Premium- und Company-Support mit monatlichen Sätzen von 5, 7 und 10 Prozent der Servicerechnung, monatlichen Mindestabrechnungsstufen, unterschiedlichem Technical Account Manager-Zugang, P1-Reaktionszielen von 2 Stunden, 30 Minuten und 15 Minuten sowie 24/7-Überwachung und -Intervention bei Cloud-Vorfällen auf. Sie sagt auch, dass Ingenieure bei Cloud-Vorfällen rund um die Uhr verfügbar sind, während Support-Anfragen während der Geschäftszeiten bearbeitet werden, mit in Frankreich ansässigem Support auf Französisch und Englisch. Der Unterschied ist wichtig. Ein Produktionsvorfall, für den Cloud Temple verantwortlich ist, ist nicht dasselbe wie eine allgemeine Hilfsanfrage, eine Konfigurationsänderung auf Kundenseite, eine Migrantenplanungsfrage oder eine Anfrage für eine nicht im Katalog aufgeführte Aufgabe.

Die Support-Seite verweist auch auf die Verantwortungsmatrix für Vorfälle mit Produktionsauswirkung, für die Cloud Temple verantwortlich ist. Diese Einschränkung ist in der Praxis kein Kleingedrucktes. Wenn die VM eines Kunden auf der Hypervisor-Ebene aktiv ist, die Anwendung jedoch aufgrund eines defekten Gastbetriebssystems ausfällt, ändert sich der Support-Pfad. Wenn die VPC eines Kunden intakt ist, die standortgebundene Carrier-Leitung jedoch ausgefallen ist, ändert sich der Support-Pfad. Wenn ein Backup existiert, der Kunde jedoch niemals Wiederherstellungstests durchgeführt hat, ändert sich der Support-Pfad.

Guter Support kann in all diesen Fällen helfen, aber die Vertragsgrenze und die bezahlte Stufe bestimmen Geschwindigkeit, Kanal und Verantwortlichkeit.

Die veröffentlichten SLA-Dokumente machen denselben Punkt mit Zahlen. DasVM Instances SLAdefiniert eine monatliche Verfügbarkeitsverpflichtung von 99,95 Prozent für jede aktive und abgerechnete VM Instance, was 21,9 Minuten erlaubter monatlicher Nichtverfügbarkeit entspricht. Es misst die Nichtverfügbarkeit jedoch auf der zugrunde liegenden Cloud Temple-Infrastrukturebene und schließt Gastbetriebssystem, Kundensoftware, Kundennetzwerkkonfiguration, Anwendungsausfälle, geplante Wartung, fehlende Verwaltungskomponenten, missbräuchliches Verhalten und höhere Gewalt aus und erfordert ein Support-Ticket innerhalb von 30 Kalendertagen, um Servicegutschriften zu beanspruchen. Das ist eine normale Cloud-Struktur. Es ist auch eine Warnung: Das SLA ist keine Garantie für die Anwendungsverfügbarkeit.

DasVPC SLAist ähnlich spezifisch. Es bietet eine monatliche Verfügbarkeit von 99,99 Prozent für die VPC-Datenebene und 99,9 Prozent für die Steuerungsebene, wobei fünf Minuten als Schwelle für die gezählte Nichtverfügbarkeit gelten. Es deckt von Cloud Temple verwaltete VPC-Komponenten wie den Router, private Netzwerke, das externe Gateway, NAT, DNAT und Floating IPs ab. Es schließt Kundenfilterregeln, fehlerhafte Adressierung, Ausfälle verbundener Compute-Ressourcen, externe Internetkonnektivität jenseits der Demarkation von Cloud Temple, geplante Wartung, missbräuchliches Verhalten und höhere Gewalt aus. Diese Ausschlüsse sind keine Fehler im Dokument; sie zeigen, wie die reale Betriebsgrenze gezogen wird.

Objektspeicher hat ein anderes Ausstiegs- und Wiederherstellungsprofil. Die öffentliche Produktseite sagt, dass Kunden Objekte über S3-kompatiblen Zugriff wiederherstellen können und dass Cloud Temple keine Egress-Gebühren erhebt. DieS3-Verantwortungsmatrixbesagt, dass Cloud Temple für die Wartung und Sicherung der S3-Plattform, den Zugriff auf den Dienst, Protokolle, Überwachung, Vorfälle, Probleme, Kapazität und Dienständerungen verantwortlich ist. Sie besagt, dass der Kunde für die Erstellung von Objekten, die Erstellung von Zugriffsschlüsseln, die Verwaltung des Objektlebenszyklus, die Verwaltung von Objektrechten, die logische Sicherheit, Backups der Daten, regelmäßige Wiederherstellungstests, Anwendungskontinuitätspläne und die Durchführung der Reversibilität verantwortlich ist. Das bedeutet, dass keine Egress-Gebühr hilfreich ist, aber die Portabilität erfordert dennoch Planung, Berechtigungsnachweise, Bandbreite, Aufbewahrungslogik und ein getestetes Ziel seitens des Kunden.

Migration ist der Punkt, an dem gehostete Kapazität oft ihre wahren Kosten offenbart. Die Produkte von Cloud Temple sind ausdrücklich mit vertrauten Ökosystemen kompatibel: VMware-Umgebungen, S3-Zugriff, OpenStack-ähnliches OpenSource IaaS, API-basierter Betrieb, Terraform-basierte Bereitstellung und BGP für Kundenpräfixe. Das sind Interoperabilitätssignale. Sie reduzieren die Abhängigkeit im Vergleich zu einem geschlossenen proprietären Stack.

Dennoch ist ein Auszug aus der Plattform ein Projekt: Serverabbilder, Speichervolumes, Objekt-Buckets, Firewall-Regeln, Zugriffsrechte, Routing, Schlüssel, DNS, Überwachung, Support-Vereinbarungen und Rollback-Fenster müssen alle aufeinander abgestimmt werden. Die IaaS-RACI besagt, dass der Kunde für die Planung der Reversibilität, die Auswahl der Zielinfrastruktur, die Durchführung von Übergangsoperationen und das Management der Servicequalitätseffekte während des Transfers verantwortlich ist, während Cloud Temple die Demontage von Konfigurationen und die sichere Löschung nach Vertragsende übernimmt.

Abrechnung und Bestellung sind keine Nebenaspekte. Die Support-Seite gibt an, dass die Mindestabrechnung für Support beginnt, wenn Ressourcen bereitgestellt werden. Die Netzwerkdokumentation besagt, dass öffentliche IPv4-Adressen nur im Rahmen des verfügbaren Bestands geliefert werden, Internetbandbreite in 100 Mbit/s-Schritten reserviert wird, private Leitungen 36-monatige Verpflichtungen mit sich bringen können und dedizierte Housing- oder Hands-and-Eyes-Dienste je nach Posten Laufzeiten von 12 oder 36 Monaten haben können.

Die Preise für Objektspeicher sind nutzungsorientiert, während Bare Metal und Housing an physische Einheiten gebunden sind. Diese Mischung beeinflusst die Resilienz. In Eile kann ein Kunde feststellen, dass die Notfallmaßnahme nicht nur ein technischer Befehl ist, sondern eine neue Bestellung, eine Support-Anfrage, ein Leitungsangebot, eine bestandsabhängige Lieferung oder eine Vertragsänderung sein kann.

Beschaffungskanäle fügen eine weitere betriebliche Ebene hinzu. Die IaaS- und Bare-Metal-Seiten von Cloud Temple verweisen Käufer aus dem öffentlichen Sektor und dem Gesundheitswesen auf öffentliche Beschaffungswege wie UGAP und CAIH. Das ist wichtig, weil es den Anbieter für Organisationen leichter annehmbar machen kann, die keine Infrastruktur durch Ad-hoc-Verhandlungen kaufen können. Es bedeutet auch, dass die Resilienzplanung durch Rahmenbedingungen, vorab genehmigte Katalogeinträge, Bestellformulare, Mindestverpflichtungen und den Zeitplan der öffentlichen Beschaffung beeinflusst werden kann.

Ein öffentlicher Käufer kann möglicherweise einen qualifizierten Dienst sauberer bestellen, muss aber dennoch wissen, ob eine spätere Kapazitätserweiterung, eine dringende Leitung, eine Premium-Support-Änderung oder eine Migrationsunterstützung in denselben Beschaffungsweg passt.

Dies ist ein Grund, warum die Wirtschaftlichkeit gehosteter Kapazität nicht auf einen monatlichen Stückpreis reduziert werden sollte. Ein Kunde, der von seinem eigenen Serverraum zu TEMPLE Cloud Temple SAS wechselt, verlagert Kapitalkosten, Personalaufwand und Einrichtungsrisiko auf einen Anbieter mit spezialisierter Infrastruktur. Das kann rational sein, insbesondere für regulierte Kunden, die nicht ohne weiteres allein Steuerungen auf SecNumCloud-Niveau aufbauen können.

Aber der Kunde akzeptiert auch eine neue Kostenstruktur: reservierte Bandbreite, Support-Stufen-Prozentsätze, Speicherverbrauch, IP-Adressen, private Leitungen, Hands-and-Eyes-Zeit, professionelle Unterstützung, physische Housing-Bedingungen und Ausstiegsbandbreite. Die Cloud-Rechnung umfasst nicht nur Compute und Speicher. Sie ist auch der Preis für Entscheidungen, die vor einem Ausfall getroffen wurden.

Die Behauptung der Egress-Gebührenfreiheit beim Objektspeicher ist ein gutes Beispiel für eine kundenfreundliche Bedingung, deren betriebliche Bedeutung vom Kontext abhängt. Wenn ein Kunde alle Objekte über S3-kompatiblen Zugriff ohne Egress-Gebühren wiederherstellen kann, ist die kommerzielle Hürde für den Ausstieg niedriger als bei vielen Hyperscale-Arrangements. Aber das Verschieben vieler Terabytes oder Petabytes verbraucht dennoch Zeit, Bandbreite, Zugriffsschlüsselkontrolle, Zielkapazität, Objektbenennungsdisziplin und Kenntnis der Aufbewahrungsrichtlinien.

Wenn Entität Lock aktiviert ist, muss ein Kunde auch seine eigenen Unveränderbarkeitsentscheidungen respektieren. Das Fehlen einer Egress-Gebühr beseitigt nicht die Notwendigkeit eines Migrationsfensters, eines Zieldesigns und eines verifizierten Kopiervorgangs.

Die öffentliche Statusseite sollte auf dieselbe praktische Weise genutzt werden. Sie ist wertvoll, weil sie Komponenten benennt, die Kunden während eines Vorfalls überwachen können, und signalisiert, dass Cloud Temple einen Teil seines Betriebsstatus sichtbar gemacht hat. Dennoch ist eine Statuskomponente nur nützlich, wenn der Kunde weiß, wie sie seinem Dienst zugeordnet ist. Wenn ein Kunde einen Eintrag für FR1 Object Storage oder eine bestimmte Verfügbarkeitszonenbezeichnung sieht, kann er dann erkennen, ob sein Bucket, sein Tenant, sein VPC-Gateway oder sein Bare-Metal-Blade betroffen ist?

Umfasst die eigene Incident-Bridge des Kunden jemanden, der diese Bezeichnungen versteht? Hat die Support-Stufe einen Kommunikationskanal für die vorliegende Schwere zugesagt? Sichtbarkeit hilft nur, wenn sie mit dem Runbook und den Eigentumsnachweisen des Kunden verbunden ist.

Es gibt auch eine stille Abhängigkeit in der eigenen öffentlichen Präsenz des Anbieters. Eine punktuelle DNS-Abfrage ergab cloud-temple.com auf dem Adressraum von Cloud Temple, Gandi-Nameserver, Microsoft-Mail-Schutz, die Konsole auf einer anderen Cloud-Temple-Adresse und den Status-Hostnamen über Atlassian Statuspage und CloudFront. Dies sind normale Entscheidungen, und sie schwächen die Kernbelege der Plattform nicht. Sie zeigen jedoch, dass die Kundenkommunikation von Schichten jenseits von AS33930 abhängen kann.

In einem schwerwiegenden Vorfall können die Anbieterwebsite, die Konsole, die Statusseite, der Mailpfad, der Telefonsupport und das Kundentenant in unterschiedlichen Kombinationen ausfallen oder überleben. Kunden sollten mehr als einen Eskalationskanal bereithalten und nicht bis zu einem Ausfall warten, um sie zu testen.

Die diesem Artikel zugewiesene globale Kategorie erfordert ebenfalls Nuancen. Cloud-Dienste können global gekauft und erreicht werden, und AS33930 hat weltweite Routingsichtbarkeit. Aber die öffentliche Souveränitätserzählung von Cloud Temple ist in erster Linie französisch und europäisch, mit FR1-Produktsprache, französischen Büros, französischen Support-Teams, ANSSI-Qualifikation, HDS-Relevanz, Pariser Peering und Signalen des französischen Einrichtungsmarktes. Für einen Kunden außerhalb Frankreichs kann die Abhängigkeit dennoch attraktiv sein, wenn das Ziel die französische oder europäische Datenlokalität ist.

Es bedeutet auch, dass Latenz, Kundenzugangsleitungen, rechtliche Erwartungen und betriebliche Support-Zeiten anhand der realen Nutzerbasis bewertet werden sollten. Eine globale Nutzerpopulation, die von einer französischen Sovereign Cloud bedient wird, benötigt möglicherweise zusätzliches Caching, regionales Zugangsdesign oder Anwendungstoleranz.

Souveränität kann auch ein falsches Gefühl der Vollständigkeit erzeugen, wenn der Kunde sie als Ersatz für Architektur behandelt. Ein qualifizierter französischer Anbieter kann die Anfälligkeit für bestimmte rechtliche, betriebliche und sicherheitstechnische Bedenken verringern, aber er kann nicht die Datenklassifizierung des Kunden, das Routen-Failover, das Anwendungs-Clustering, die Tenant-Rechte, die Schlüsselrotation, die Wiederherstellungshäufigkeit oder die Ausstiegspriorität entscheiden. Die öffentliche Dokumentation von Cloud Temple ist ungewöhnlich klar darin, dass viele dieser Punkte beim Kunden verbleiben.

Diese Klarheit ist eine gute Nachricht. Sie gibt Käufern die Möglichkeit, die Aufteilung vor der Produktion explizit zu machen. Das Risiko besteht darin, dass ein Käufer die Zertifikatsschlagzeile liest und die Verantwortungstabelle ignoriert.

Die sauberste Beschaffungsfrage ist daher eine Tabelle mit Abgrenzungen, nicht eine Ja-oder-Nein-Vertrauensfrage. Für jeden Workload sollte der Kunde den Compute-Dienst, den Speicherdienst, den Netzwerkdienst, die Verfügbarkeitszonen, das Backup-Ziel, den Wiederherstellungsverantwortlichen, die Support-Stufe, die Kundenleitung, das öffentliche Präfix, den Identitätsadministrator, den Schlüsseleigentümer, den Abrechnungseigentümer, den Wartungskontakt und das Ausstiegsziel aufschreiben.

Dann sollte er TEMPLE Cloud Temple SAS bitten zu bestätigen, welche Elemente vom Anbieter betrieben werden, welche vom Kunden betrieben werden, welche im SecNumCloud-Umfang liegen, welche HDS-relevant sind, welche außerhalb qualifizierter Bereiche liegen, welche in der Vorschau sind und welche separate professionelle Unterstützung erfordern. Diese Übung ist banal, aber sie ist der Punkt, an dem Cloud-Resilienz sichtbar wird.

Physisches Housing ist die konkreteste Erinnerung daran, dass die Cloud Kanten hat. DieHousing-Dokumentationvon Cloud Temple beschreibt die physische Unterbringung nach Rack-Einheit in gemeinsam genutzten Racks oder in dedizierten 42U-Racks, zwei Stromkreise für gemeinsam genutzte Racks, Strombegrenzungen pro HE, serverorientierte 2U-Einheiten mit C19-Stromanschluss, dedizierte Racks mit 3 kW über zwei 16A-Stromkreise, zusätzliche 2-kW-Erweiterungen, eine maximale Gerätemasse von 1.000 kg, überwachte PDUs, Kupfer- oder Glasfasernetzwerkanschlüsse, Meet-Me-Room-Konnektivität und Hands-and-Eyes-Dienste. Es heißt auch, dass dedizierte Racks sich im gemeinsam genutzten Housing-Bereich außerhalb des SecNumCloud-Bereichs befinden. Diese letzte Unterscheidung ist wichtig: „Cloud Temple Housing“ und „qualifiziertes IaaS Secure Temple“ sind keine austauschbaren Begriffe.

Für einige Kunden ist Housing eine Brücke. Ein Altsystem, ein mainframenahes System, eine proprietäre Storage Box, ein HSM, eine Firewall oder ein Migrations-Staging-Server müssen möglicherweise in der Nähe von Cloud-Ressourcen platziert werden, während ein regulierter Workload verschoben wird. Das kann sinnvoll sein. Es kann auch eine Zwei-Perimeter-Architektur schaffen: teils qualifizierte Cloud, teils nicht qualifiziertes physisches Housing, teils kundeneigene Ausrüstung, teils von Cloud Temple verwaltetes Netzwerk, teils Carrier-Leitung.

Wenn der Kunde annimmt, dass alles dieselbe Qualifikation, Support-Reaktion und Wiederherstellungsmechanik hat, kann das Design irreführend werden. Die Housing-Dokumente sind gerade deshalb hilfreich, weil sie den Käufer zwingen, über Rack-Einheiten, Watt, Ports, optische Pfade, Hands-and-Eyes-Reaktion und Support-Eskalation zu sprechen.

Das Argument der Datensouveränität ist daher am stärksten, wenn es konkret gehalten wird. Die Seiten von Cloud Temple erheben einen glaubwürdigen Souveränitätsanspruch durch den französischen Betrieb, die SecNumCloud-Qualifikation, HDS, ISO 27001, Support-Teams in Frankreich und Produkte, die für regulierte Sektoren entwickelt wurden. Die Objektspeicherseite betont die französischen und europäischen Regulierungsanforderungen. Die Support-Seite gibt an, dass die Support-Teams in Frankreich ansässig sind und von Frankreich aus arbeiten. Die Compliance-Seite listet offizielle Gültigkeitsdaten und -umfänge auf.

Aber Souveränität ist nicht nur eine nationale Kennzeichnung. Sie ist auch Platzierung, Support-Zugang, Nachweise von Subunternehmern, Schlüsselverwahrung, Vorfallkommunikation, Exportweg, Löschennachweis und Offenlegung von Restrisiken. Ein Kunde sollte fragen, wo sich jede Datenkopie, jedes Backup, jeder Protokollstrom, jedes Support-Artefakt und jede Support-Intervention befindet.

Der öffentliche Netzwerk-Fußabdruck liefert eine ähnliche Lektion. AS33930 hat sichtbare Präfixe, gültige Routenursprungsautorisierung in der geprüften Ansicht, Austauschbeteiligung und Einrichtungslistungen. Das ist besser, als nur ein Reseller-Frontend auf dem Netzwerk eines anderen zu sehen. Es bedeutet, dass Cloud Temple über eine direkte Routing-Oberfläche und eine öffentliche Interkonnektivitätsgeschichte verfügt.

Dennoch verrät der Routing-Nachweis nicht, welches Kundentenant welches Präfix nutzt, wie die DDoS-Abwehr während eines Angriffs gesteuert wird, ob alle Pfade während der Wartung gleichermaßen verfügbar sind, welche Routenpräferenzen für kundeneigene Präfixe gelten oder wie schnell ein Kunde die IP-Identität von der Plattform wegbewegen kann. Ein starkes BGP-Protokoll ist für einige Workloads erforderlich, für alle jedoch nicht ausreichend.

Die am stärksten betroffenen Kunden sind die, die Cloud Temple selbst anvisiert: öffentliche Einrichtungen, Gesundheitsdienstleister, Finanzunternehmen, Industriebetreiber, Softwareverlage und andere Organisationen, die sowohl Compliance-Sicherheit als auch Betriebskontinuität benötigen. In diesen Umgebungen ist ein Cloud-Ausfall selten nur eine Unannehmlichkeit. Er kann die Pflege verzögern, regulierte Berichterstattung einfrieren, anlagennahe Systeme stoppen, Bürgerdienste blockieren, den Identitätszugriff unterbrechen oder einen Softwareverlag daran hindern, nachgelagerte Kunden zu bedienen.

Die richtige Due-Diligence-Frage lautet nicht: „Kann Cloud Temple eine VM hosten?“ Das kann es offensichtlich. Die Frage lautet: „Entspricht das gewählte Dienstdesign dem betrieblichen Schaden, wenn diese Anwendung ausfällt?“

Für eine öffentliche Einrichtung kann die Antwort den SecNumCloud-Umfang, die Tenant-Segregation, die Support-Stufe, die Vorfallkommunikation und die Reversibilität umfassen. Für einen Gesundheitsdienstleister kann sie den HDS-Umfang, Backup-Wiederherstellungstests, Support-Zugang, Entität-Lock-Aufbewahrung und die Frage umfassen, ob die Subunternehmernachweise jeden Pfad abdecken. Für ein Finanzteam kann sie Prüfnachweise, Wegdiversität, unveränderliche Archive, Verschlüsselung, Schlüsselverwahrung und eine Ausstiegsplanung nach DORA-Art umfassen.

Für ein Industrieunternehmen kann sie latenzarme Verbindungen, Standortnähe, privates Backbone-Design, Wartungsfenster und lokale betriebliche Rückfallebene umfassen. Ein einzelnes Produktetikett kann diese Fragen nicht beantworten. Der Kunde muss die öffentlichen Nachweise in eine workloadspezifische Entwurfsprüfung umwandeln.

Der Ausfallpfad, der sich am meisten zu testen lohnt, ist der zusammengesetzte: ein Vorfall, der Anbieterinfrastruktur, Kundenkonfiguration und Support-Prozess kreuzt. Stellen Sie sich einen Kunden vor, der VMware IaaS über zwei Verfügbarkeitszonen mit einem Firewall-Paar, S3-Backup-Kopien, einem kundeneigenen Präfix, einer standortgebundenen Glasfaserstrecke und einer Premium-Support-Stufe betreibt. Wenn eine Zone beeinträchtigt wird, kann die Anwendung von der HA-Konfiguration, der Speicherreplikation, dem Firewall-Status, dem DNS-Verhalten, der Routenkonvergenz, der S3-Verfügbarkeit und einem korrekt klassifizierten Ticket abhängen.

Wenn auch die eigene Carrier-Leitung des Kunden Probleme hat, ist das Backbone von Cloud Temple möglicherweise nicht der Engpass. Wenn die Backup-Richtlinie des Kunden fehlerhaft gestaltet war, kann der Objektspeicher über drei Zonen die falschen Daten bewahren. Deshalb muss die geteilte Verantwortung vor dem Ausfall ausgeübt und nicht nur währenddessen zitiert werden.

Wartungsfenster verdienen dieselbe Aufmerksamkeit. Die SLA-Sprache schließt geplante Wartungen aus, die unter dem Support-Vertrag des Kunden angekündigt wurden. Das ist normal, verlagert aber die praktische Planung auf den Kunden. Wer erhält Wartungsankündigungen? Werden sie an das Team weitergeleitet, das die Anwendung besitzt? Weiß der Kunde, ob ein Hypervisor-Update einen Neustart auslösen kann? Versteht er, dass einige Hypervisor-Betriebssystem-Updates eine Kundenentscheidung sein können, weil Cloud Temple nicht über jede workloadspezifische Einschränkung informiert ist?

Sind Backup-, Überwachungs- und Firewall-Teams während des Fensters anwesend? Ein Wartungsereignis ist für den Anbieter nur dann Routine, wenn es auch für den Kunden Routine ist.

Reparaturfenster und Hardwarebestand sind aus öffentlichen Quellen schwerer zu überprüfen. Die Dokumente zeigen Klassen von Blades, Speichergrenzen, Netzwerkports und physische Housing-Einheiten, veröffentlichen jedoch keine Ersatzblattanzahl, Speichercontroller-Ersatzteile, GPU-Bestand, Lieferzeiten nach Klasse oder genaue Ersatzpraxis nach Verfügbarkeitszone. Das bedeutet nicht, dass der Bestand fehlt. Es bedeutet, dass die öffentliche Recherche ihn nicht beweisen kann. Die richtige Kundenanfrage ist einfach: Zeigen Sie den Prozess zur Kapazitätsreservierung, -erweiterung und -ersetzung für den gewählten Dienst.

Wenn die Anwendung während eines Notfalls vier weitere GPU-Blades benötigt oder einen Ersatzhost nach einem Blade-Ausfall oder zusätzlichen Objektspeicherdurchsatz während einer Wiederherstellung, sollte der Kunde wissen, ob die Antwort sofort, geplant, bestellabhängig oder angebotsabhängig ist.

Dasselbe gilt für den Wiederherstellungsbeweis. Die qualifizierte Plattform, S3-Redundanz und Backup-Architektur von Cloud Temple schaffen einen stärkeren Ausgangspunkt als ein generischer Host. Aber die IaaS- und S3-Verantwortungsmatrizen legen die Kohärenz des Backup-Plans und die regelmäßigen Wiederherstellungstests wiederholt in die Verantwortung des Kunden, manchmal mit Konsultation von Cloud Temple. Das sollte die Beschaffungssprache ändern.

Käufer sollten nicht nur fragen: „Ist Backup enthalten?“, sondern: „Wer schreibt den Wiederherstellungsplan, wer führt den Test durch, wer zeichnet das Ergebnis auf, was passiert, wenn die Wiederherstellung das Ziel verfehlt, und welche Support-Stufe gilt während einer realen Wiederherstellung?“ Ein ungetesteter Wiederherstellungsversuch bleibt eine Hoffnung, auch wenn der darunter liegende Speicher gut gebaut ist.

Die Beweisnote für TEMPLE Cloud Temple SAS sollte daher besser sein als die Vorsicht der Zuweisung bei dünnem Fußabdruck, aber dennoch nicht absolut. Die öffentliche Aufzeichnung ist breit, aktuell und spezifisch: Offizielle Seiten identifizieren die Positionierung im regulierten Sektor, französische Büros, SecNumCloud- und HDS-Umfang, Produktfamilien, Support-Stufen, Objektspeicherarchitektur, privates Backbone-Design, VPC- und VM-SLA-Bedingungen, physische Housing-Grenzen, AS33930-Routing, RPKI-Gültigkeit, Austauschpunkte und öffentliche Statuskomponenten. Das ist ein substanzieller Fußabdruck.

Die fehlenden Beweise sind enger, aber entscheidend: kundenspezifische Platzierung, genaue Zuweisung des Einrichtungsbetreibers für jeden Workload, Ersatzbestand, Support-Leistungshistorie, Ergebnisse von Wiederherstellungstests, Kundenkonzentration, Wartungskommunikation und reale Ausstiegsdurchführung.

Für Käufer lautet die praktische Schlussfolgerung, TEMPLE Cloud Temple SAS als glaubwürdige Sovereign-Cloud-Abhängigkeit zu behandeln, die dennoch einen Workload-spezifischen Nachweis benötigt. Fordern Sie ein Diagramm an, das die Region, die Verfügbarkeitszonen, die Compute-Hosts oder -Klassen, die Speicherklassen, die S3-Buckets, die Backup-Richtlinien, die VPC-Gateways, die Internet-Ausgänge, die Kundenleitungen, die Support-Kontakte und die Eskalationspfade benennt.

Fragen Sie, welche Verpflichtungen unter den SecNumCloud-Umfang fallen, welche HDS-relevant sind, welche gewöhnliches Housing sind, welche in der Vorschau sind und welche kundeneigen sind. Fragen Sie, wie Servicegutschriften beansprucht werden und was sie nicht abdecken. Fragen Sie, wie ein Workload die Plattform verlässt, wie Daten gelöscht werden, wie Schlüssel gehandhabt werden und wie sich der Support außerhalb der Geschäftszeiten verhält.

Für Infrastrukturleser ist die Lektion breiter. Ein Sovereign-Cloud-Anbieter kann sowohl wirklich betriebsbereit sein und dennoch von der banalen Physik der Kapazität abhängen. TEMPLE Cloud Temple SAS verkauft eine attraktive Kombination: qualifizierte französische Infrastruktur, anerkannte Unternehmensplattformen, sichtbares Routing, Objektspeicher über drei Verfügbarkeitszonen, Support in Frankreich und explizite Verantwortungsmatrizen. Aber der Kunde kauft nicht „Souveränität“ im Abstrakten.

Er kauft ein bestimmtes Tenant, eine Blade-Klasse, eine Speicherstufe, einen Netzwerkpfad, eine Ticket-Stufe, einen Wartungskalender und eine Ausstiegsvereinbarung. Das sind die Teile, die entscheiden werden, ob die gehostete Kapazität ein Rack-Ereignis, ein Upstream-Ereignis, einen Hardware-Engpass, eine Support-Warteschlange, Reibungsverluste bei der Abrechnung, Migrationsdruck oder ein Versagen des Anbietervertrags überlebt.