DC West CloudSigma und der souveräne Cloud-Workload-Nachweis

Zusammenfassung

• Bei DC West CloudSigma geht es nicht darum, ob die Marke CloudSigma eine souveräne Cloud beschreiben kann, sondern ob ein Kunde den akzeptierten Zustand einer Workload über Standort, Compute, Speicher, Netzwerk, Zugriffskontrolle, Abrechnung und Support hinweg verifizieren kann.
• Die öffentliche Dokumentation von CloudSigma ist ungewöhnlich explizit in Bezug auf Standorte, rechtliche Trennung, API-Ressourcen, Verhalten von Netzwerkschnittstellen, Verfügbarkeitsgruppierung, Statusseiten und rechtliche Servicebeschränkungen – das hilft ernsthaften Käufern, eine Akzeptanz-Checkliste zu erstellen, anstatt sich auf Marketing-Behauptungen zu verlassen.
• Das verbleibende Risiko ist operationeller und nicht semantischer Natur: Die Lokalität kann mehrdeutig sein, wenn eine benannte Dienstoberfläche, ein Partnerlabel und ein Rechenzentrumsbetreiber in derselben Geschichte vorkommen, während Speicher, virtuelle Netzwerke, IAM, Abrechnung und Support-Eskalation weiterhin eine aktive Überwachung durch den Kunden erfordern.

Der Souveränitätsanspruch zählt erst nach der Abnahme

Der Begriff „souveräne Cloud“ ist heute leicht zu kaufen und schwer zu verifizieren. Er kann ein Rechenzentrum in einem Land bedeuten, eine lokale Betriebsgesellschaft, einen Vertrag nach lokalem Recht, ein Support-Team, das in der Landessprache erreichbar ist, eine isolierte Steuerungsebene, eine Hyperscaler-Region mit Residenzverpflichtungen, einen privaten Stack, der für einen einzelnen Kunden betrieben wird, oder einfach eine Marketinghülle um virtuelle Maschinen.

DC West CloudSigma gehört in diese Debatte, weil die CloudSigma-Oberfläche auf einer In-Country-Cloud-Bereitstellung, Service-Provider-Nutzung, flexibler Infrastruktur und rechtlicher Trennung nach Cloud-Standort aufbaut. Doch diese Behauptungen werden erst dann nützlich, wenn sie die routinemäßige Arbeit der Workload-Abnahme überstehen.

Ein akzeptierter Nachweis einer souveränen Cloud-Workload ist ein schlichtes operationelles Artefakt.

Er gibt an, welche Region ausgewählt wurde, welche rechtlichen Bedingungen gelten, welche Server existieren, welche Laufwerke angeschlossen sind, welcher Speichertyp gewählt wurde, welche öffentlichen und privaten Schnittstellen konfiguriert sind, welche IP-Adressen oder VLANs verwendet werden, welche Konten oder ACLs die Ressourcen ändern können, welche Abrechnungs- und Nutzungsdaten der Bereitstellung entsprechen, was die Statusseite für diesen Standort anzeigt und wie der Support erreicht wird, wenn sich die Steuerungsebene oder ein Upstream-Carrier in Wartung befindet.

Kann der Nachweis diese Fragen nicht beantworten, ist Souveränität zu einem Branding statt zu Kontrolle geworden.

Diese Unterscheidung ist für CloudSigma wichtig, weil seine öffentliche Positionierung nicht mit einem Hyperscaler-Katalog vergleichbar ist. Das Unternehmen beschreibt eine souveräne Cloud-Plattform für Service-Provider, einschließlich konfigurierbarer Compute-, Speicher-, Netzwerk-, Sicherheits-, Abrechnungs- und API-Automatisierung für die In-Country-Bereitstellung. Es beschreibt außerdem Cloud-Server mit frei wählbarer Ressourcengröße, KVM-Virtualisierung, benutzerdefinierten Images, Root-Zugriff, sekundengenauer Abrechnung in kurzen Abrechnungsintervallen, API-Automatisierung und Dutzenden von In-Country-Regionen.

Der kommerzielle Reiz liegt auf der Hand: Ein Service-Provider, ein Unternehmen oder eine regulierte Organisation kann starre Instanzfamilien vermeiden, einen lokalen Cloud-Standort wählen und mehr operative Kontrolle behalten, als ein einfacher Managed-Hosting-Vertrag erlauben würde.

Der Abnahmetest fragt, ob diese Flexibilität lesbar bleibt. Eine flexible Plattform kann eine Stärke sein, wenn der Kunde über diszipliniertes Infrastrukturpersonal verfügt. Sie kann aber auch zu einem Verstärker von Fehlern werden, wenn ein Benutzer davon ausgeht, dass eine Cloud-Plattform schlechte Entscheidungen stillschweigend korrigiert. Muss eine Workload in der Schweiz bleiben, muss ein Käufer den gewählten Schweizer Standort nachweisen können. Benötigt eine Workload eine statische öffentliche Adresse, muss die Netzwerkschnittstelle diesen Zustand widerspiegeln und sich nicht auf eine Annahme aus einem Ticket stützen.

Hängt die Anwendung von privatem Ost-West-Verkehr ab, sind der VLAN-Status und die NIC-Reihenfolge entscheidend. Erwartet der Kunde, dass der Support Probleme mit dem Gastbetriebssystem löst, können der Vertrag und der Support-Umfang etwas anderes besagen.

Diese Bewertung behandelt DC West CloudSigma daher als eine Betriebsfläche und nicht als ein allgemeines Anbieterprofil. Die öffentliche Evidenz rund um das Label DC West ist schmal, während die Service-Oberfläche von CloudSigma breit und gut dokumentiert ist. Das bedeutet, die richtige Haltung ist Grenzdisziplin: Erfinden Sie keinen spezifischen DC-West-Kunden, keinen Benchmark, keinen Vorfall und keine lokale Architektur; testen Sie stattdessen den CloudSigma-Cloud-Nachweis, den eine souveräne Workload hinterlassen müsste.

Standortevidenz: Lokalität ist eine Kette, kein Label

Die Standortdokumentation von CloudSigma bietet Kunden mehr als eine vage Regionskarte. Die öffentliche Standortseite listet Cloud-Standorte in ganz Europa, den Vereinigten Staaten, Nordamerika, dem Nahen Osten, APAC und Afrika auf, darunter Dublin, Frankfurt, Genf, London, Zürich, Düsseldorf, Honolulu, Washington DC, Monterrey, Johor, Clark, Manila, Perth, Riad, Tokio, Mumbai und Kairo. Sie gibt auch an, dass CloudSigma Standorte nach Konnektivität, Sicherheit und Zuverlässigkeit auswählt und dass die Standorte mindestens Tier III oder eine gleichwertige Rechenzentrumsbewertung erfüllen.

Für einen Käufer, dem Lokalität wichtig ist, ist diese Seite keine Dekoration. Sie ist der erste Kontrollpunkt im akzeptierten Nachweis.

Die Schweizer Evidenz ist besonders wesentlich, weil CloudSigma in der Schweiz gegründet wurde, dort registriert ist und öffentlich eine rechtliche Trennung nach Ländern präsentiert. Die Schweizer Rechtsseite besagt, dass Cloud-Standorte rechtlich nach Ländern getrennt sind, und nennt Beispiele, bei denen Schweizer Cloud-Hosting dem Schweizer Recht, US-Clouds dem US-Recht und Perth-Hosting dem australischen Recht unterliegen. Dasselbe Rechtsmaterial identifiziert die CloudSigma AG als ein Schweizer Unternehmen mit Sitz im Kanton Zug, mit einer Registrierungsnummer und einem eingetragenen Firmensitz.

Das beweist nicht, dass jede Workload im strengen öffentlich-rechtlichen Sinne souverän ist, aber es gibt einem Käufer eine Vertragsgrenze, die er prüfen kann.

Der Kontext der Swiss Government Cloud zeigt, warum diese Grenze wichtig ist. Die Schweizer Public-Cloud-Politik unterscheidet zwischen Public Cloud, Public Cloud Schweiz und privater Bundes-Cloud. Die Stufe Public Cloud Schweiz wird mit Datenspeicherung und Datenverarbeitung in der Schweiz für erhöhte Souveränitätsanforderungen beschrieben, während die private Bundes-Cloud die Daten- und Betriebssouveränität in Bundesrechenzentren betont. CloudSigma wird weder durch den Schweizer Sitz noch durch die Nutzung von Schweizer Rechenzentren zu einer Bundes-Cloud.

Aber der politische Kontext verschärft die Frage des Käufers: Welches Maß an Souveränität ist erforderlich, und welcher Teil des CloudSigma-Nachweises unterstützt dies?

Die Evidenz zu Washington DC ist anders. Die Standortseite von CloudSigma führt einen Cloud-Standort in Washington DC mit einem Webanwendungslink unter dem WDC-Code auf und nennt einen Rechenzentrumsbetreiber und den IAD1-Campus. Sie beschreibt einen Konnektivitäts- und Hosting-Hub in Sterling, Virginia, mit Sicherheitsanforderungen von Unternehmen, Behörden und Finanzinstituten. Sie listet außerdem physische Eigenschaften, Stromversorgung, Kühlung, Brandschutz und Zertifizierungen auf. Dies ist eine nützliche Evidenz für eine Workload, die eine Cloud-Oberfläche an der US-Ostküste wünscht.

Es ist jedoch nicht dasselbe wie der Nachweis, dass eine Workload zu einer bestimmten lokalen DC-West-Unternehmenseinheit gehört, und es macht auch nicht jede Workload zu einer Bereitstellung auf Regierungsniveau.

Das ist die Identitätsgrenze, die ein Kunde einhalten muss. Die öffentliche Dokumentation untermauert CloudSigma als die relevante Cloud-Plattform und zeigt veröffentlichte Cloud-Standorte, einschließlich Washington DC und Schweizer Standorte. Sie zeigt auch die Positionierung als Partner und Service-Provider. Für sich allein beweist sie weder einen bestimmten Kunden, eine bestimmte DC-West-Workload noch eine private lokale Betriebsvereinbarung, es sei denn, der Käufer verfügt über zusätzliche vertragliche und abnahmebezogene Evidenz.

Die sicherere Schlussfolgerung ist, dass DC West CloudSigma anhand des akzeptierten Cloud-Zustands von CloudSigma bewertet werden sollte, mit einem Lokalitätsvorbehalt statt einer Lokalitätsannahme.

Die Standortabnahme sollte daher mehr als einen Screenshot umfassen. Sie sollte den von der Bereitstellung verwendeten Standortcode oder Endpunkt, das ausgewählte Portal oder die API-Basis, die für die ausgewählte Cloud geltenden rechtlichen Bedingungen, etwaige erforderliche Datenverarbeitungsvereinbarungen für personenbezogene Daten, den für den Standort benannten Rechenzentrumsbetreiber, die Statusseite für diesen Standort sowie eine Aufzeichnung darüber enthalten, ob Backup-, Remote-Snapshot-, Support- oder Abrechnungsvorgänge die beabsichtigte Hoheitsgrenze überschreiten.

Eine Workload, die all dies aufweist, kann über einen nützlichen Souveränitätsnachweis verfügen. Eine Workload, die lediglich das Wort „souverän“ in einem Angebot enthält, nicht.

Bereitstellungswahrheit: Freiform-Infrastruktur braucht trotzdem eine Quittung

Das Produktversprechen von CloudSigma stützt sich stark auf eine Freiform-Bereitstellung. Die öffentliche Cloud-Server-Seite besagt, dass Ressourcen unabhängig und ohne starre Instanzstufen erworben werden können und dass Kunden KVM-Virtualisierung, benutzerdefinierte Images, Root-Zugriff, API- und Terraform-Automatisierung nutzen können. Das ältere IaaS-Material bringt dasselbe Grundargument in anderer Sprache: Kunden stellen die von ihnen benötigte Kombination aus CPU, RAM, Speicher und Bandbreite zusammen, anstatt eine Standard-Servergröße auszuwählen. Das ist kommerziell attraktiv, weil es Verschwendung reduzieren kann.

Es ist aber auch betrieblich anspruchsvoll, denn es gibt keinen einzelnen Instanznamen, der das laufende System automatisch erklärt.

Der akzeptierte Nachweis muss die tatsächliche Serverdefinition erfassen. Die API-Dokumentation von CloudSigma legt Serverressourcen mit CPU, Arbeitsspeicher, Hypervisor, CPU-Typ, Laufwerken, NICs, Metadaten, Status, Besitzer, Laufzeit, öffentlichen Schlüsseln, Berechtigungen und Tags offen. Die Dokumentation beschreibt auch Serveraktionen wie Starten, Stoppen und Klonen. In der Praxis bedeutet dies, dass eine Workload nur dann akzeptiert werden kann, wenn der Käufer die beabsichtigte Gestalt mit der von der Steuerungsebene zurückgegebenen Gestalt vergleichen kann.

Eine Abweichung bei der Bereitstellung ist kein philosophisches Problem, sondern ein konkreter Unterschied zwischen der Bestellung, dem API-Status, der Gastkonfiguration und der Rechnung.

Der Capabilities-Endpunkt von CloudSigma macht dies noch wichtiger. Die Dokumentation sagt, dass Fähigkeiten dynamisch sind und je nach Cloud-Nutzung, Standort und anderen Parametern variieren können. Sie sagt auch, dass nicht unterstützte oder deaktivierte Funktionen aus der Antwort verschwinden können. Das ist ein entscheidender Punkt für Käufer, die annehmen, dass sich ein CloudSigma-Standort wie ein anderer verhält. Die Souveränitätsgeschichte mag von einer bestimmten Gerichtsbarkeit abhängen, aber die technische Geschichte hängt davon ab, was die Cloud dieser Gerichtsbarkeit zum Zeitpunkt der Bereitstellung tatsächlich liefern kann.

Ein akzeptierter Workload-Nachweis sollte daher vor der Abnahme des Builds die für die Workload relevanten Fähigkeiten erfassen.

Es gibt auch ein Timing-Problem. Langlaufende Operationen wie das Klonen von Laufwerken oder Servern können Jobs erzeugen, und die Job-Dokumentation besagt, dass diese Jobs den Fortschritt verfolgen. Für eine Migration oder die Einführung einer Workload reicht es nicht aus, dass eine Anfrage von der API akzeptiert wird. Der Kunde benötigt den Nachweis, dass der Job abgeschlossen wurde, dass die Zielressource existiert und dass der neue Server oder das neue Laufwerk dasjenige ist, das mit dem Dienst verbunden ist. Ein fehlgeschlagener oder teilweiser Klon kann wie ein Fortschritt aussehen, bis die Anwendung davon booten soll.

Das gleiche Wahrheitsproblem tritt bei Abonnements auf. Die Abonnement-API von CloudSigma unterscheidet aktive, inaktive und abgelaufene Abonnements und listet Ressourcen wie Festplatte, CPU, Arbeitsspeicher, Datenverkehr, IP und VLAN auf. Sie besagt auch, dass Abonnements für den Kunden nach der Erstellung – mit Ausnahme der automatischen Verlängerung – größtenteils unveränderlich sind. Das sollte Kunden zu einer strengeren Abnahmedisziplin zwingen.

Wenn eine reservierte Kapazität oder eine Netzwerkressource in falscher Menge, mit falschem Timing oder für die falsche Ressource erworben wird, ist die Korrektur möglicherweise keine einfache Bearbeitung. Es kann ein neues Abonnement, ein Gespräch zur Rechnungsanpassung oder eine Migration der Erwartungen sein.

Hierin unterscheidet sich der Dienst von einer vollständig abstrahierten Plattform. CloudSigma gibt dem Käufer granulare Kontrolle; der Käufer muss mit granularer Verifizierung antworten. Die nützliche Frage lautet nicht: „Hat die Cloud einen Server erstellt?“ Die nützliche Frage lautet: „Zeigt der akzeptierte Zustand den angeforderten Compute, Arbeitsspeicher, Hypervisor, Laufwerke, Speichertyp, NICs, Standort, Besitzer, Berechtigungen, Abonnement und abrechenbare Ressourcen?“ Wenn diese Felder übereinstimmen, hat der Souveränitätsanspruch betriebliche Substanz. Wenn nicht, hält der Kunde ein Versprechen statt eines Systems in den Händen.

Speicherstatus: Souveränität kann auf der Laufwerksebene scheitern

Beim Speicher wird Cloud-Kontrolle oft emotional greifbar. Ein Server kann neu erstellt, eine Route korrigiert und ein Support-Ticket eskaliert werden, aber der Speicherort der Daten und die Integrität der Laufwerke definieren den Punkt, an dem eine souveräne Workload entweder vertrauenswürdig bleibt oder streitig wird. Die öffentlichen Unterlagen von CloudSigma liefern hier mehrere nützliche Signale. Die API-Dokumentation behandelt Laufwerke als First-Class-Ressourcen, mit Auflistung, Detailauflistung, Erstellung, Bearbeitung, Größenänderung, Metadaten, Löschung, Klonen, Speichertypen, Snapshots, Remote-Snapshots und Backup-Schedulern.

Das ist die richtige Granularität für einen Akzeptanznachweis.

Der akzeptierte Nachweis muss mehr als die Existenz einer virtuellen Maschine belegen. Er sollte zeigen, welche Laufwerke erstellt wurden, deren Größe, deren Speichertyp, ob sie angeschlossen sind, ob Snapshots existieren, ob eine Richtlinie für Remote-Snapshots konfiguriert ist und ob ein Backup-Scheduler dort existiert, wo der Kunde ihn erwartet. Die Beispiele der Dokumentation legen Felder wie Mount-Status, Laufzeit, Speichertyp, Jobs, Metadaten, Tags und Besitzer offen.

Diese Felder sind keine Schreibkram, sondern die Speicherhälfte der Souveränität: Wem gehört das Laufwerk, wo befindet es sich, wie ist es angeschlossen, welchen Zustand meldet es und welche langlaufenden Operationen haben es berührt.

Die Verfügbarkeitsgruppierung und die „Avoid“-Funktionalität von CloudSigma sind ebenfalls für den Speicher von Bedeutung. Die Dokumentation erklärt, dass Ressourcen normalerweise zugewiesen werden, um die Leistung zu maximieren, dass aber redundante Konfigurationen geschwächt werden können, wenn Server denselben Compute-Host teilen oder Laufwerke denselben Storage-Host teilen. Sie besagt, dass Kunden Hinweise geben können, dass Ressourcen auf getrennten physischen Hosts platziert werden sollen, und dass sie die Gruppierungen über API-Aufrufe zur Verfügbarkeitsgruppe überprüfen können. Das ist eine ernüchternde Warnung.

Ein Kunde, der Redundanz benötigt, kann nicht davon ausgehen, dass zwei Ressourcen unabhängig sind, nur weil sie unterschiedliche Namen haben. Der akzeptierte Nachweis muss die Trennung nachweisen, wo die Trennung Teil des Designs ist.

Das rechtliche Material ist ebenso wichtig, denn es begrenzt die Vorstellung, dass die Speicherplattform eines Anbieters jegliche Kundenverantwortung aufhebt. Die Schweizer AGB von CloudSigma besagen, dass der Kunde dafür verantwortlich ist, mindestens eine aktuelle Sicherungskopie außerhalb des CloudSigma-Netzwerks aufzubewahren. Das Service Level Agreement bietet eine Gutschrift bei dauerhaftem Verlust gespeicherter Daten infolge eines Hardware- oder Softwarefehlers der CloudSigma-Systeme, aber die Gutschrift ist ein finanzieller Ausgleich und keine Datenwiederherstellung.

Dieselben Bedingungen unterscheiden die Verantwortung des Anbieters von der Software, die innerhalb der virtuellen Server des Kunden läuft. Für regulierte Käufer ist diese Unterscheidung kein Kleingedrucktes, sondern das Betriebsmodell.

Die Release Notes fügen eine praktische Warnung hinzu. Die API-Release-Notes von CloudSigma für Ende 2025 erwähnen Korrekturen bei der Abrechnung von Objektspeicher, Speicher-Tiers für Objektspeicher sowie Verbesserungen beim Gast-Klonen und der Startleistung. Diese Notizen zeigen eine lebendige Plattform, was gut ist, aber sie erinnern die Kunden auch daran, dass Speicherverhalten, Abrechnung und Klon-Leistung keine statischen Hintergrundfakten sind. Sie ändern sich, und der Akzeptanznachweis muss an das Datum, den Standort und den Funktionsumfang der Bereitstellung gebunden sein.

Ein Speichervorfall muss nicht dramatisch sein, um teuer zu werden. Es kann ein Laufwerk sein, das im falschen Speicher-Tier erstellt wurde, ein Klon-Job, der noch nicht abgeschlossen ist, eine angenommene, aber nicht konfigurierte Backup-Richtlinie, ein Laufwerk, das an den falschen Server angeschlossen ist, ein Snapshot, der außerhalb des gewünschten Standorts aufbewahrt wird, eine Diskrepanz bei der Abrechnung von Objektspeicher oder eine falsche Annahme, dass der Anbieter das Gast-Dateisystem unterstützt. CloudSigma bietet die Kontrollen, um einen großen Teil dieses Zustands zu inspizieren.

Der Nutzen hängt davon ab, ob der Kunde sie nutzt, bevor er die Workload für akzeptiert erklärt.

Netzwerkstatus: Öffentlich, privat und Upstream sind getrennte Fragen

Die Netzwerkabnahme ist der andere Ort, an dem die Sprache der Souveränität zu weit gefasst werden kann. Eine Workload mag im richtigen Land sein, aber dennoch nicht erreichbar, überexponiert, von einem Upstream-Carrier in Wartung abhängig oder an das falsche private Netzwerk angeschlossen sein. Die Dokumentation von CloudSigma ist nützlich, weil sie diese Bedenken trennt. Server-Netzwerkschnittstellen können privat über VLANs oder öffentlich über IPv4- und IPv6-Konfigurationen sein.

Öffentliche Adressierung kann dynamisch, statisch oder manuell erfolgen, und die Dokumentation erklärt, dass die Änderung der NIC-Konfiguration Vorsicht erfordert, weil MAC-Adressen bestehende NICs identifizieren und die Reihenfolge der NICs der VM präsentiert wird.

Das ist genau die Art von Detail, die in einen echten Workload-Nachweis gehört. Wenn ein Kunde statische öffentliche Adressierung erwartet, sollte der akzeptierte Zustand die statische Konfiguration und die IP-Ressource zeigen. Wenn ein Kunde ein privates Netzwerk erwartet, sollte der akzeptierte Zustand das VLAN zeigen und welche NIC angeschlossen ist. Wenn ein Kunde erwartet, dass der Gast die Adressierung manuell verwaltet, muss der Kunde die gastseitige Konfiguration und das damit verbundene Risiko selbst verantworten.

Die öffentliche Dokumentation sagt auch, dass die Cloud-Firewall den Verkehr zu und von IPs blockiert, die nicht der VM gehören oder ihr zugewiesen sind, außer im Fall der manuellen Konfiguration, bei der abonnierte Adressen verwendet werden dürfen. Das bedeutet, dass der Netzwerkstatus teils eine Frage der Cloud-Steuerungsebene und teils eine Frage der Gast-Administration ist.

Die Netzwerk-API liefert zusätzliche Evidenz. VLANs sind Ressourcen, die aufgelistet, detailliert, erstellt, bearbeitet und an Server angeschlossen werden können. IP-Ressourcen können ebenfalls verwaltet werden. Die API macht das Netzwerkdesign nicht von sich aus sicher, aber sie macht den Netzwerkstatus inspizierbar. Für eine souveräne Workload ist Inspizierbarkeit nützlich, weil ein Kunde genau aufzeichnen kann, welche privaten und öffentlichen Pfade existieren und welches Konto sie besitzt.

Statusseiten vervollständigen das Bild. CloudSigma veröffentlicht eine zentrale Statusseite, die auf Statusseiten nach Standort verlinkt, darunter Zürich, Genf, Frankfurt, Düsseldorf, Perth, Dublin, Tokio, Manila, Clark, Riad, Honolulu, Washington DC, Kairo, Johor Bahru und Monterrey. Dasselbe Statusmaterial zeigt Wartungsbeispiele, bei denen API- oder Weboberflächenaufrufe für einen Zeitraum nicht verfügbar sein können, während bestehende virtuelle Maschinen und die Netzwerkerreichbarkeit voraussichtlich unbeeinträchtigt bleiben, sowie Netzwerkwartungsbeispiele, bei denen der Verkehr über andere Leitungen umgeleitet wird.

Diese Aufteilung ist wichtig. Eine Workload kann weiterlaufen, während die Steuerungsebene vorübergehend eingeschränkt ist, oder sie kann erreichbar sein, während die Fähigkeit des Kunden, sie zu ändern, beeinträchtigt ist.

Der akzeptierte Nachweis sollte daher die Laufzeitverfügbarkeit von der Steuerungsebenenverfügbarkeit unterscheiden. Wenn ein Änderungsfenster von API-Aufrufen abhängt, ist eine API-Wartung ein Hindernis, selbst wenn die VMs weiterlaufen. Wenn ein Kunde während eines Vorfalls die Netzwerkrichtlinie ändern muss, kann eine Portalunterbrechung betrieblich bedeutsam werden. Wenn ein Upstream-Carrier gewartet wird, muss der Kunde wissen, ob der Verkehr umgeleitet, beeinträchtigt oder einfach außerhalb der Garantien des Anbieters liegt.

Das Service Level Agreement von CloudSigma schließt einige Ausfälle außerhalb seiner Kontrolle aus, einschließlich Upstream-Provider und des Internets. Das ist für Cloud-Verträge normal, sollte aber im Risikomodell des Käufers erscheinen.

Virtuelle Netzwerke werden oft als einfach verkauft, weil die Cloud Kabel versteckt. Der akzeptierte Nachweis sollte sie auf die richtige Weise wieder anspruchsvoll machen. Er sollte den Standort, die öffentlichen IPs, die privaten VLANs, die NIC-Reihenfolge, den DHCP- oder statischen Modus, die Firewall-Erwartung, die Routenabhängigkeit, die Statusseite und den Support-Pfad benennen. Wenn diese Details fehlen, wird ein Netzwerkfehler nicht nur ein Ausfall sein, sondern ein Streit darüber, was tatsächlich aufgebaut wurde.

Kundenkontrolle ist real, und damit auch die Kundenlast

Die stärksten Behauptungen von CloudSigma zur Kundenkontrolle sind eindeutig. Es beschreibt vollen Root- oder Administratorzugriff, benutzerdefinierte Images, jedes kompatible Betriebssystem, freie Ressourcengröße und API-Automatisierung. Die rechtlichen Datenschutzerklärungen besagen, dass der Kunde den alleinigen Root- oder Administratorzugriff auf Dateisystemebene auf seine Daten behält und dass das Auftragnehmersystem keinen Zugang oder Einblick in Cloud-Server oder Laufwerksdaten hat. Das ist eine bedeutsame Kontrollaussage für Kunden, die Infrastrukturautonomie wünschen.

Aber Kontrolle ist nie kostenlos. Voller Root-Zugriff bedeutet, dass der Anbieter nicht für das Gastbetriebssystem in der Weise verantwortlich ist, wie es ein Managed-Service-Provider sein könnte. Die Bedingungen besagen, dass CloudSigma keine Unterstützung für Betriebssysteme oder andere Software leistet, die Kunden innerhalb virtueller Server ausführen. Diese Grenze schützt den Anbieter davor, für jeden Anwendungsfehler verantwortlich zu werden, aber sie verlagert operative Arbeit zurück zum Kunden. Ein Käufer sollte Souveränität nicht als Reduzierung des technischen Aufwands interpretieren.

In diesem Modell bedeutet Souveränität oft, dass der Kunde mehr von der Betriebslast trägt, weil er mehr von der Kontrolle behält.

Die Aufzeichnung der Zugriffskontrolle verdient besondere Aufmerksamkeit. Die ACL-Dokumentation von CloudSigma besagt, dass einem anderen Benutzer Berechtigungen zur Verwaltung von Ressourcen erteilt werden können, einschließlich des Startens oder Stoppens von Servern, des Anschließens von Ressourcen, des Öffnens von VNC, des Klonens, des Auflistens und des Bearbeitens. Sie erklärt auch, dass Ressourcen Besitzerfelder und Berechtigungen unterstützen. Dies ist nützlich für Service-Provider und Unternehmensteams, weil es gemeinsame Administration ermöglicht. Es ist aber auch eine Risikofläche.

Eine schlechte ACL kann eine kontrollierte Cloud in ein Problem geteilter Änderungen verwandeln.

Ein akzeptierter Workload-Nachweis sollte daher enthalten, wem die Server, Laufwerke, VLANs und IPs gehören; welche ACLs welche Rechte gewähren; welche Benutzer Ressourcen starten, stoppen, klonen oder anschließen können; welche öffentlichen Schlüssel hinterlegt sind; welche Metadaten vorhanden sind; und ob Audit-Logs die erwartete Akteurshistorie zeigen. Die Audit-Log-API von CloudSigma verfolgt Änderungen, die vom Kunden oder von anderen Parteien wie CloudSigma-Mitarbeitern oder berechtigten Personen an Ressourcen vorgenommen werden. Das ist ein bedeutendes Rechenschaftsmerkmal, aber nur, wenn es genutzt wird.

Ein Käufer, der niemals Logs inspiziert, wird von deren Existenz nicht profitieren.

Die Kundenkontrollgeschichte umfasst auch die Abrechnung und Nutzung. Die API von CloudSigma legt Kontostand, Preisgestaltung, Nutzung, aktuelle Nutzung und Abonnements offen. Das öffentliche Preismaterial positioniert transparente Ressourcenstückpreise für direkte Endnutzer und nutzungsbasierte Umsatzbeteiligung für Service-Provider-Partner. Das ist attraktiv, wenn ein Kunde Ressourcen eng an die Nachfrage anpassen möchte. Es macht Abrechnungsüberraschungen aber auch zu einem bekannten Fehlermodus.

Eine Freiform-Cloud kann Verschwendung weniger verbergen als ein Katalog fester Instanzen, aber sie kann auch viele kleine abrechenbare Posten erzeugen, die niemand prüft, bis die Rechnung eintrifft.

Eine gute Abnahmepraxis verbindet den technischen Zustand mit dem Kostenstand. Die Anzahl der Server, Laufwerke, Speicher-Tiers, IPs, VLANs, Verkehrsressourcen, Abonnements und Lizenzressourcen sollte mit den Abrechnungs- und Nutzungsendpunkten abgeglichen werden. Wenn eine Workload einen akzeptierten technischen Zustand, aber einen ungeprüften Abrechnungsstand aufweist, hat der Kunde nur das halbe System akzeptiert. Souveränität ohne Kostenbeobachtbarkeit ist ein schlechtes Geschäft.

Support-Kontinuität ist ein Workflow, kein Versprechen

Die öffentlichen Seiten von CloudSigma machen starke Support-Behauptungen. Das IaaS-Material besagt, dass Support rund um die Uhr per Chat und E-Mail verfügbar ist, mit schneller Reaktion und Eskalation. Das Cloud-as-a-Service-Material besagt, dass CloudSigma die gesamte Cloud verwalten kann, einschließlich Infrastruktur, Netzwerk, Abrechnungs-Gateway-Bereitstellung, Vorfallsmanagement und Kunden-Support, für Service-Provider-Partner. Diese Support-Haltung ist zentral für das Produkt.

Ein Service-Provider, der eine In-Country-Cloud in Betracht zieht, möchte nicht nur Software; er möchte Kontinuität, wenn etwas an der Schnittstelle von Plattform, Rechenzentrum, Netzwerk, Abrechnung und Kundendruck schiefgeht.

Die rechtlichen Bedingungen sind vorsichtiger, wie rechtliche Bedingungen es meist sind. Sie besagen, dass CloudSigma angemessene Anstrengungen unternehmen wird, um auf Support-Anfragen zu reagieren und Fehler zu beheben, dass geplante Wartungen angekündigt werden können und dass Notfallwartungen ohne gewöhnliche Vorankündigung erfolgen können, wenn dies kommerziell erforderlich ist. Das Service Level Agreement bietet Gutschriften für bestimmte Verfügbarkeits-, Netzwerk- und Datenverlustfehler, aber Gutschriften sind keine operative Wiederherstellung.

Die Lücke zwischen Produkt-Supportsprache und rechtlichem Rechtsbehelf ist nicht ungewöhnlich. Es ist genau der Grund, warum ein ernsthafter Käufer einen Support-Abnahmenachweis benötigt.

Dieser Nachweis sollte die Support-Kontaktwege, Eskalationskontakte, standortspezifische Statusseiten, Wartungsbenachrichtigungskanäle, die Schweregradsprache, die Grenze zwischen Cloud-Plattform und Gastsoftware sowie den Prozess zur Geltendmachung eines Service-Level-Anspruchs definieren. Er sollte auch definieren, was der Kunde tut, wenn das Problem nicht direkt von CloudSigma verschuldet ist: Wartung eines Upstream-Providers, Fehlkonfiguration durch den Kunden, Ausfall des Gastbetriebssystems, unzureichendes Guthaben, abgelaufenes Abonnement oder ein ACL-Fehler.

Ohne diesen Workflow wird Support eher zu einer Erwartung als zu einem System.

Die zentrale Statusseite ist hilfreich, weil sie es Kunden ermöglicht, nach Standort zu überwachen. Das Risiko besteht darin, dass Kunden Statusseiten als Ersatz für ihre eigene Beobachtbarkeit behandeln. Ein Cloud-Anbieter kann melden, dass laufende VMs von einer API-Wartung nicht betroffen sind, während die Anwendung des Kunden aufgrund eigener Abhängigkeiten immer noch ausfällt. Ein Anbieter kann den Verkehr während einer Carrier-Wartung umleiten, während eine latenzempfindliche Anwendung dennoch eine geschäftliche Auswirkung erfährt.

Eine Standort-Statusseite kann Unsicherheit verringern, aber sie beseitigt nicht die Notwendigkeit von kundenseitigem Monitoring, Vorfallklassifizierung und Rollback-Planung.

Support-Kontinuität ist auch eine Personalfrage. Das Modell von CloudSigma kann den Aufwand verringern, einen Cloud-Stack von Grund auf neu aufzubauen, insbesondere für Service-Provider, die ein markengebundenes In-Country-Angebot wünschen. Aber es beseitigt nicht den Bedarf an Personal, das sich mit virtuellen Netzwerken, Speicher-Backups, IAM, Abrechnung, Standortanforderungen und Lieferanteneskalation auskennt. Tatsächlich kann eine flexible Cloud diszipliniertere Infrastrukturbetreiber erfordern als eine stärker vorschreibende Plattform.

Der Personalaufwand verschiebt sich von der Hardwarebeschaffung hin zu Abnahme, Überwachung, Änderungskontrolle und Evidenzerhaltung.

Diese Verschiebung kann gut sein. Ein regionaler Service-Provider zieht es vielleicht vor, Personalaufwand in Kundenbeziehungen, Migrationsunterstützung und Service-Design zu investieren, anstatt eine Cloud-Plattform zu entwickeln. Ein reguliertes Unternehmen möchte vielleicht lieber Cloud-Status-Evidenz aufbewahren, anstatt jede Schicht an einen Hyperscaler auszulagern. Aber keiner dieser Käufer sollte Plattform-Management mit Anwendungsverantwortung verwechseln. Der Anbieter kann die Cloud am Laufen halten; der Kunde muss immer noch die Workload lesbar halten.

Stückkostenökonomie: Flexibilität konkurriert mit Skalierung

Das kommerzielle Argument von CloudSigma lautet nicht, dass es größer als die Hyperscaler ist. Es besagt, dass Flexibilität, Lokalität und Service-Provider-Ausrichtung für einige Workloads wichtiger sein können als Hyperscale-Breite. Die Preisseite legt verschiedene Wege für Service-Provider-Partner, Endnutzer und Empfehlungspartner dar. Die Cloud-Server-Seite betont den unabhängigen Erwerb von Ressourcen und kurze Abrechnungsintervalle.

Die Partnerseite besagt, dass das Unternehmen nicht mit lokalen Service-Provider-Partnern in Ländern konkurriert, in denen ein solcher Partner existiert, und leitet Direktkunden- und Empfehlungsumsätze an den CloudSigma-Service-Provider der lokalen Region weiter. Das ältere Cloud-as-a-Service-Material beschreibt geteilte Umsätze, Managed Operations und ein Partnernetzwerk.

Das ist eine kohärente Marktposition. Es ist aber auch eine engere Marktposition als die eines globalen Hyperscalers. Der Wert von CloudSigma ist dort am größten, wo der Käufer Wert auf lokale Bereitstellung, White-Label- oder partnergeführte Cloud, Flexibilität auf Ressourcenebene, Root-Zugriff, API-Kontrolle und eine Support-Beziehung legt. Er ist schwächer, wo der Käufer einen tiefen Managed-Service-Katalog, globale Managed Databases, native Analytik, spezialisierte KI-Infrastruktur, proprietäre serverlose Dienste oder breite Marktplatz-Ökosysteme wünscht.

Eine souveräne Cloud-Workload kann gut passen; eine Cloud-native Anwendung, die rund um Hyperscaler-Plattformdienste entworfen wurde, möglicherweise nicht.

Die Stückkosten drehen sich daher um Substitution. Der Ersatz ist nicht immer AWS, Azure oder Google Cloud. Es kann ein lokaler Virtualisierungscluster, ein lokaler Colocation-Anbieter, ein Managed-Service-Provider, eine VMware-basierte private Cloud, eine regionale Cloud mit einem schmaleren Produktangebot oder eine Hyperscaler-Region mit vertraglichen Datenresidenzverpflichtungen sein. Jeder Ersatz verschiebt Kosten zwischen Kapital, Betrieb, Migration, Support und Lock-in.

Die Ressourcengranularität von CloudSigma kann die Überbereitstellung für einige Workloads reduzieren, während sein kleineres Ökosystem den Integrationsaufwand für andere erhöhen kann.

Die öffentliche Marktevidenz ist auf nützliche Weise gemischt. Bewertungsseiten zeigen eine kleine Anzahl allgemein positiver Nutzersignale in Bezug auf Flexibilität, Zuverlässigkeit und Support, aber der Stichprobenumfang ist klein. SoftwareReviews klassifiziert CloudSigma in Cloud-Infrastruktur als Service und zeigt ein Produktprofil, das auf Service-Provider ausgerichtet ist. Trustpilot zeigt ein beanspruchtes Profil mit einer bescheidenen Anzahl von Bewertungen und warnt, dass Bewertungen möglicherweise nicht repräsentativ sind.

Eine StorPool-Fallstudie präsentiert CloudSigma als Kunden einer Service-Provider-Speicherplattform und enthält Behauptungen über verbesserte Marge und Leistung, aber das ist eine Anbieter-Fallstudie und sollte eher als kommerzielles Signal denn als unabhängige Prüfung behandelt werden.

Die OCRE- und GEANT-Partnerschaftsankündigung ist ebenfalls als Kontext von Bedeutung. CloudSigma gab öffentlich bekannt, als offizieller Cloud-Partner für das Open Clouds for Research Environments-Projekt ausgewählt worden zu sein, das auf die Einführung europäischer Forschungsclouds abzielt. Das zertifiziert nicht jede souveräne Workload, aber es zeigt, dass CloudSigma Märkte gesucht hat, in denen institutionelle Käufer Wert auf Cloud-Wahlfreiheit, Forschungsworkloads und europäische Bereitstellung legen. Es ist eine Marktsignalquelle, kein pauschaler Nachweis der Eignung.

Für einen Käufer ist die wirtschaftliche Frage einfach zu formulieren und schwer zu beantworten: Übersteigt der Wert der passenden Rechtsordnung, der flexiblen Dimensionierung, der Service-Provider-Ausrichtung und der Kundenkontrolle die zusätzliche Überwachung, den Migrationsaufwand, den schmaleren Managed-Service-Katalog, mögliche Ausgangskosten, die Abrechnungsüberwachung und die Support-Koordination?

Die Antwort kann für einen regionalen Service-Provider, eine kontrollierte IaaS-Workload, eine regulierte Anwendung mit standardmäßigen Compute- und Speicheranforderungen oder einen Kunden, der Infrastrukturautonomie auf Root-Ebene wünscht, „Ja“ lauten. Die Antwort kann für Teams, die den größten Teil der betrieblichen Beurteilung an einen Plattformanbieter auslagern möchten, „Nein“ lauten.

Die Fehlermodi sind betrieblich spezifisch

Die bekannten Fehlermodi für DC West CloudSigma sind nicht exotisch. Es sind die gewöhnlichen Fehler, die teurer werden, wenn ein Käufer erwartete, dass Souveränität sie vereinfachen würde.

Bereitstellungsabweichung ist der erste. Ein Server kann mit der falschen CPU, falschem Arbeitsspeicher, falschem Hypervisor, falscher Festplatte, falscher NIC, falscher Region oder falschem Besitzer erstellt worden sein. Die API von CloudSigma macht diese Felder sichtbar, was ein Vorteil ist, aber Sichtbarkeit hilft nur, wenn der Kunde sie überprüft. Ein guter Akzeptanznachweis vergleicht den beabsichtigten Build mit dem zurückgegebenen Build, bevor der Datenverkehr fließt.

Speichervorfälle sind der zweite. Der Vorfall mag ein Datenverlustereignis sein, aber häufiger handelt es sich um ein Problem niedrigerer Stufe: falscher Speichertyp, fehlender Snapshot, noch laufender Klon-Job, an den falschen Server angeschlossenes Laufwerk, keine Sicherungskopie außerhalb des Anbieternetzwerks, unklare Richtlinie für Remote-Snapshots oder unverstandene Abrechnung von Objektspeicher. Die rechtlichen Unterlagen und das SLA machen deutlich, dass Gutschriften und Datenwiederherstellung verschiedene Dinge sind.

Fehler im virtuellen Netzwerk sind der dritte. Eine NIC kann privat sein, wenn öffentlich erwartet wurde, dynamisch, wenn statisch erforderlich war, manuell im Gast konfiguriert, wenn das Team DHCP erwartete, oder anders geordnet, als die Gastkonfiguration annimmt. Ein VLAN kann existieren, ohne dass die Workload es korrekt nutzt. Eine IP kann abonniert, aber nicht in der von der Anwendung erwarteten Weise angeschlossen sein. Dies sind keine Anbieterskandale, sondern Abnahmefehler, es sei denn, die Steuerungsebene des Anbieters selbst verursachte die Abweichung.

Lokalitätsunklarheit ist die vierte. Der Kunde verwendet möglicherweise die Marke CloudSigma, ein Standortlabel, ein Partnerlabel und einen Rechenzentrumsbetreibernamen austauschbar. Sie sind nicht austauschbar. Eine Workload hat einen ausgewählten Standort, einen rechtlichen Vertrag, einen Rechenzentrumsstandort, einen Steuerungsebenen-Endpunkt, einen Support-Weg und möglicherweise eine lokale Service-Provider-Beziehung. Der Akzeptanznachweis sollte jeden für sich getrennt halten.

IAM- und ACL-Fehlkonfiguration ist die fünfte. ACLs können Zusammenarbeit ermöglichen, aber sie können auch Änderungen autorisieren, die der Workload-Besitzer nicht beabsichtigte. Ein Kunde, der Start-, Stopp-, Klon-, Anschluss- oder Bearbeitungsrechte vergibt, benötigt einen Audit-Trail und eine regelmäßige Überprüfung. Root-Zugriff innerhalb der VM schützt die Workload nicht vor einer fehlerhaften Cloud-Ressourcenberechtigung außerhalb der VM.

API- und Steuerungspaneel-Drift ist die sechste. Die Beispiele der Statusseiten machen deutlich, dass die Verfügbarkeit von API und Weboberfläche während Wartungen von der Verfügbarkeit laufender VMs abweichen kann. Eine Workload kann gesund sein, während die Änderungskontrolle eingeschränkt ist. Ein Bereitstellungsplan, der von Last-Minute-API-Aufrufen abhängt, sollte den Status der Steuerungsebene des entsprechenden Standorts überwachen.

Support-Eskalationsverzögerung ist die siebte. Öffentliche Support-Versprechen sind hilfreich, aber die Vertragssprache und die betrieblichen Grenzen sind weiterhin wichtig. Ein Kunde muss wissen, was CloudSigma unterstützt, was es innerhalb des Gasts nicht unterstützt, wie ein Plattformfehler eskaliert wird und wie Upstream-Provider-Probleme klassifiziert werden. Der Support-Nachweis sollte so explizit sein wie der Server-Nachweis.

Abrechnungsüberraschung ist die achte. Freiform-Ressourcenverbrauch, Abonnements, Datenverkehr, IPs, VLANs, Speicher und Lizenzen sind nützlich, wenn sie nachverfolgt werden, und teuer, wenn sie ignoriert werden. CloudSigma legt APIs für Kontostand, Preise, Nutzung und aktuelle Nutzung offen. Der Käufer sollte sie mit der Workload-Abnahme und mit laufenden Änderungsaufzeichnungen abgleichen.

Migrations-Rollback-Fehler ist der neunte. Eine souveräne Cloud-Migration ist nicht abgeschlossen, wenn eine VM startet. Sie ist abgeschlossen, wenn Daten, Routen, Identität, Backup, Überwachung, Kosten, Support und Rollback ausreichend getestet wurden, um das Geschäftsrisiko zu tragen. Die Plattform von CloudSigma gibt den Kunden viele direkte Kontrollen; sie macht den Rollback nicht automatisch.

Was ein seriöser Kunde akzeptieren sollte

Der praktische Wert von DC West CloudSigma zeigt sich am deutlichsten, wenn der Kunde vor der Migration aufschreibt, was Abnahme bedeutet. Der Nachweis sollte mit der Identität beginnen: CloudSigma-Konto, ausgewählter Standort, Endpunkt, rechtliche Bedingungen, gegebenenfalls Datenverarbeitungsbedingungen, Service Level Agreement und Support-Kontakte. Dann sollte er zum Compute übergehen: Servernamen, UUIDs, Hypervisor, CPU, Arbeitsspeicher, angeschlossene Laufwerke, öffentliche Schlüssel, Metadaten, Status und Besitzer.

Dann Speicher: Laufwerks-UUIDs, Größen, Speichertypen, Snapshot- und Backup-Richtlinie, Klon-Jobs, Verfügbarkeitsgruppierung und etwaige Remotekopien. Dann Netzwerk: öffentliche IPs, private VLANs, NIC-Reihenfolge, statischer oder dynamischer Adressmodus, Firewall-Erwartung und Standort-Statusseite. Dann Kontrolle: Benutzer, ACLs, Audit-Logs, Kontostand, Abonnements, Preisannahmen und Nutzungsprüfung. Dann Betrieb: Überwachung, Wartungskanäle, Eskalation, Rollback und Besitzverhältnisse.

Das sieht nur schwer aus, wenn Souveränität als ein Label behandelt wird. Für regulierte oder rechtsordnungsempfindliche Workloads ist es das absolute Minimum an Nachweis. Ohne ihn weiß der Kunde nicht, ob die Workload am beabsichtigten Ort, auf den beabsichtigten Ressourcen, unter dem beabsichtigten Zugriffsmodell und mit dem beabsichtigten Wiederherstellungspfad liegt. Mit ihm wird die dokumentierte Flexibilität von CloudSigma zu einer Stärke und nicht zu einer Quelle von Mehrdeutigkeit.

Derselbe Nachweis schützt CloudSigma auch vor unfairen Erwartungen. Wenn ein Kunde nicht unterstützte Software in einer VM ausführt, es versäumt, externe Backups zu unterhalten, weitreichende ACLs gewährt, Nutzungsaufzeichnungen ignoriert oder sich auf manuelle Gastnetzwerke ohne Dokumentation verlässt, kann der Anbieter daraus keine saubere souveräne Workload machen. Ein flexibler IaaS-Anbieter ist kein Managed-Application-Operator, es sei denn, der Vertrag besagt dies.

Für Service-Provider-Partner hat der Akzeptanznachweis eine weitere Rolle: Er bewahrt das Vertrauen der Kunden. Das Partnermodell von CloudSigma verspricht einen Weg für Systemintegratoren, VARs, MSPs, Rechenzentrumsbetreiber und Telekommunikationsunternehmen, um In-Country-Cloud-Dienste zu starten. Dieses Modell kann leistungsstark sein, weil der lokale Anbieter die Kundenbeziehung besitzt und CloudSigma die Plattform und den operativen Betrieb liefert. Aber der lokale Anbieter benötigt dann Evidenz, die gut genug für seine eigenen Kunden ist. Ein gebrandetes Portal reicht nicht aus.

Der Anbieter muss die Bereitstellungswahrheit, Lokalität, den Speicherstatus, den Netzwerkstatus und die Support-Kontinuität in einer Form nachweisen, die die Kunden verstehen können.

Für Unternehmen ist die Entscheidung direkter. Wenn die Workload hauptsächlich virtuelle Maschinen, Festplatten, private und öffentliche Netzwerke, transparente Abrechnung, Root-Zugriff und lokale Rechtsordnung benötigt, verdient CloudSigma Beachtung. Wenn die Workload von einem großen Managed-Service-Ökosystem, proprietären Plattformdiensten oder globaler betrieblicher Einheitlichkeit abhängt, sollte der Käufer vorsichtig sein. Souveränes IaaS ist nicht automatisch ein Drop-in-Ersatz für jedes Hyperscaler-Design.

Fazit: Nützlich, wo Evidenzdisziplin besteht

Der akzeptierte Nachweis einer souveränen Cloud-Workload von DC West CloudSigma sollte nach Evidenz beurteilt werden, nicht nach Adjektiven. Die öffentliche CloudSigma-Dokumentation liefert nützliche Bausteine: benannte Standorte, Sprache zur rechtlichen Trennung, Schweizer Unternehmensidentität, Datenverarbeitungs- und Service-Level-Bedingungen, explizite API-Ressourcen, Server- und Laufwerkszustand, Regeln für Netzwerkschnittstellen, Verfügbarkeitsgruppierung, ACLs, Audit-Logs, Abrechnungs- und Nutzungsendpunkte, Standort-Statusseiten und partnerorientierte kommerzielle Positionierung.

Diese Bausteine sind stärker als eine generische Regional-Cloud-Broschüre.

Sie beseitigen keine Unsicherheit. Die öffentliche Dokumentation beweist keine spezifische DC-West-Kundenworkload, kein privates Leistungsergebnis, keine versteckte Architektur, keinen Kundenvorfall und keine lokale Betriebsvereinbarung jenseits dessen, was CloudSigma veröffentlicht. Sie beseitigt auch nicht den Unterschied zwischen einer vom Anbieter verwalteten Plattform und einer vom Kunden verwalteten Gastumgebung. Käufer müssen weiterhin die Bereitstellung, den Speicher, das Netzwerk, den Zugriff, die Abrechnung, den Support und den Rollback überwachen.

Das ist die richtige Balance. Der Wert von CloudSigma ist real, wenn ein Käufer Kontrolle will und bereit ist, mit Kontrolle zu arbeiten. Er ist schwächer, wenn ein Käufer möchte, dass Souveränität weniger Entscheidungen bedeutet. Der akzeptierte Nachweis ist die Trennlinie. Wenn DC West CloudSigma einen sauberen Nachweis über Standort, Compute, Speicher, Netzwerk, Kontrolle, Support und Kosten hinterlassen kann, kann es souveränitätssensible Workloads bedienen, die zu einem IaaS-Modell passen. Fehlt der Nachweis, rettet die Souveränitätssprache die Bereitstellung nicht.