S3NS Thales Cloud Securise SAS vermarktet gehostete Kapazität, die weiterhin von Racks, Transit und Reparaturfenstern abhängt

Zusammenfassung

• PREMI3NS ist kein bloßer zukünftiger Dienst mehr. S3NS hat ihn am 16. Oktober 2025 verfügbar gemacht, und die ANSSI hat den IaaS-, PaaS- und CaaS-Dienst gemäß SecNumCloud 3.2 am 17. Dezember 2025 qualifiziert; die Entscheidung gilt bis zum 17. Dezember 2028.
• Seine physische Geografie ist konzentriert, aber bewusst partitioniert: Die autonome Regionu-france-east1umfasst drei Zonen, die jeweils einem von drei unabhängigen Rechenzentren in Frankreich zugeordnet sind. Die öffentliche Produktdokumentation gibt an, dass Funktionen, die mehrere Regionen erfordern, nicht verfügbar sind.
• Thales Cloud Sécurisé ist der qualifizierte Anbieter und S3NS die Handelsmarke. Das Unternehmen unterliegt französischem Recht und wird von Thales kontrolliert; der Jahresabschluss 2024 weist eine Beteiligung von 95 % für Thales und 5 % für Google aus, während die aktuelle Satzung fünf stimmberechtigte Sitze im Verwaltungsrat für Vertreter von Thales und einen Beobachterposten ohne Stimmrecht für den anderen Aktionär vorsieht.
• Die öffentlichen Dokumente bestätigen eindeutig die französische Kontrolle, einen operativen Dienst, einen umfangreichen Katalog verwalteter Dienste und ein Zonendesign. Sie geben weder die drei Standortbetreiber noch die genauen Standorte, Energiequellen, Transportverträge, die Backbone-Topologie, Ersatzteilbestände oder Kunden-Support-Verpflichtungen preis.
• Das resultierende Beweismaß ist Mittel. S3NS verfügt über außergewöhnlich starke regulatorische und operative Belege für eine junge Cloud, aber ein Käufer kann allein aus der SecNumCloud-Qualifizierung oder einer Drei-Zonen-Karte keine regionsweite Notfallwiederherstellung, nutzbare Failover-Kapazität oder schnelle physische Reparatur ableiten.

Ein Cloud-Versprechen wird zum operativen Dienst

S3NS muss nun als operativer Infrastrukturanbieter bewertet werden, nicht als das Angebot, das Frankreich erstmals 2022 diskutierte. Der Zeitplan ist wichtig. Das Unternehmen öffnete im Januar 2025 ein Early-Access-Programm, gab bei dessen Abschluss bekannt, dass über 50 Kunden und Partner teilgenommen hatten, brachte PREMI3NS am 16. Oktober 2025 in dieallgemeine Verfügbarkeitund erhielt zwei Monate später einSecNumCloud 3.2-Sicherheitsvisum. Im April 2026 deutete eineAnkündigung von S3NS, SAP und Thalesan, dass das Unternehmen mehr als 60 Kunden bediente und 30 verwaltete Dienste anbot, mit 30 weiteren für das folgende Jahr geplant.

Diese Meilensteine klären eine Frage, die zuvor Vorsicht erforderte: PREMI3NS ist nicht nur eine Designkapazität oder ein zukünftiges Zertifizierungsziel. Es existiert ein Produktionsdienst, ein qualifizierter Umfang und eine Basis von Organisationen, die S3NS-Angebote nutzen. Die Unterscheidung zwischen den Angeboten bleibt wichtig. CRYPT3NS, das frühere Produkt für lokale Steuerungen, das um Standard-Google-Cloud herum aufgebaut war, wurde ausdrücklich ohne SecNumCloud-Qualifizierungsziel präsentiert. PREMI3NS ist die dedizierte und separate Umgebung, die die ANSSI qualifiziert hat.

Ein Kunde kann die Garantien nicht einfach von einem Produktnamen auf den anderen übertragen, nur weil beide von S3NS verkauft werden.

DieQualifizierungsentscheidung der ANSSIist präziser als eine Pressemitteilung. Sie bezeichnet den Anbieter als THALES CLOUD SÉCURISÉ und den Dienst als CLOUD DE CONFIANCE S3NS. Ihr Umfang umfasst Infrastruktur-, Plattform- und Containerdienste, keine Software as a Service. Der aktuelleKatalog der Agenturgibt die Qualifizierungsdaten vom 17. Dezember 2025 bis zum 17. Dezember 2028 an. Dies schafft eine klare Versicherungsgrenze: Verwenden Sie den qualifizierten Dienst, unter seinen qualifizierten Bedingungen, und überprüfen Sie, ob jedes abhängige Produkt tatsächlich in diesen Umfang fällt.

Der Dienstkatalog ist breit genug, um eine erhebliche Abhängigkeit zu schaffen. DiePREMI3NS-Produktseitelistet virtuelle Maschinen, Kubernetes, Objekt- und Blockspeicher, verwaltete relationale Datenbanken, BigQuery, VPN, Interconnect, DNS und Sicherheitsdienste auf. Dies sind keine Randwerkzeuge. Sie können Identitäts-, Transaktions-, Analyse-, Anwendungs- und Backup-Funktionen hosten, die schwer zu entwirren sind, sobald eine Organisation ihr Betriebsmodell um sie herum standardisiert hat.

Deshalb ist die physische Ebene jetzt wichtig. Eine Roadmap kann nach ihrer Plausibilität beurteilt werden. Eine Produktions-Cloud muss danach beurteilt werden, was nutzbar bleibt, wenn ein Rack die Stromversorgung verliert, eine Zone isoliert ist, ein Carrier ausfällt, ein Update blockiert ist, eine Support-Warteschlange voll ist oder ein Kunde aussteigen muss.

Der Anbieter ist Thales Cloud Sécurisé, keine abstrakte Allianz

Der Name S3NS beschreibt eine Partnerschaft und eine Marke, aber der rechtliche Anbieter ist konkret. Das französische Handelsregister identifiziert THALES CLOUD SECURISE, SIREN 908 211 980, als französische vereinfachte Aktiengesellschaft, die 2021 gegründet wurde. Ihr aktueller Hauptsitz befindet sich in der 26 rue de Montholon in Paris. Die aktualisierteSatzung des Unternehmensweist im April 2026 ein Kapital von 3,3 Millionen Euro aus.

Die Kontrolle ist aufschlussreicher als die vage Beschreibung „Thales und Google Cloud“. DieJahresabschlüsse 2024des Unternehmens zeigen, dass Thales am Ende des Geschäftsjahres 95 % der Anteile und Google 5 % hielt. Die Satzung von 2026 sieht fünf stimmberechtigte Verwaltungsratsmitglieder vor, die von Thales vorgeschlagen werden, und einen Beobachter ohne Stimmrecht, der vom anderen Aktionär ernannt wird. Sie schließt diesen Beobachter auch vom Zugang zu Kundendaten und sensiblen physischen und logischen Sicherheitsinformationen aus. In einer Anhörung vor einem französischen parlamentarischen Untersuchungsausschuss im Jahr 2026 beschrieb der Direktor für öffentliche Angelegenheiten von Google Google als einen Beobachterposten ohne Stimmrecht oder Vetorecht im Vorstand. Die Satzung ist der nützlichste Beweis, da sie die Struktur detailliert beschreibt, anstatt sie in einem Slogan zusammenzufassen.

Das bedeutet nicht, dass Google unwichtig ist. Der Jahresabschluss 2024 zeigt, dass S3NS und Google im Dezember 2024 die Vereinbarung über die technischen und kommerziellen Beziehungen für die vertrauenswürdige Cloud unterzeichnet haben. Google stellt die zugrunde liegende Cloud-Technologie und deren Weiterentwicklung bereit. Das Wertversprechen von S3NS ist, dass Thales Cloud Sécurisé die dedizierte Umgebung, das Personal, die Schlüssel, den Betrieb und die Bereitstellung von Updates kontrolliert und gleichzeitig von Googles Softwareentwicklung profitiert.

Diese Grenze hat eine anspruchsvolle französische Qualifizierung bestanden. Sie bleibt eine Anbietergrenze. Wenn Software-Updates eingestellt werden, sich Lizenzbedingungen ändern, der Zugang zur Dokumentation eingeschränkt wird oder eine Hardware-Generation nicht mehr verfügbar ist, produziert die rechtliche Kontrolle der Ausführungsumgebung keinen Ersatz-Technologie-Stack. Umgekehrt impliziert die technologische Abhängigkeit nicht, dass Google Kundendaten lesen oder PREMI3NS verwalten kann.

Die relevante Bewertung hält beide Fakten gleichzeitig fest: S3NS kontrolliert den qualifizierten Dienst; Google bleibt ein strategischer Technologieanbieter.

Die Unternehmensakte liefert auch Belege für den Hochlauf. S3NS meldete Ende 2024 126 Mitarbeiter, nachdem es im Laufe des Jahres 51 Personen eingestellt hatte, darunter 40 in technischen Teams. Seine Bilanz wies 14,2 Millionen Euro an im Bau befindlichen Sachanlagen aus, gegenüber 3,7 Millionen ein Jahr zuvor. Der Umsatz erreichte 4,94 Millionen Euro, während das Unternehmen einen Jahresverlust von 942.293 Euro verbuchte. Diese Zahlen beschreiben einen Betreiber in der Investitionsphase vor der allgemeinen Verfügbarkeit und Qualifizierung.

Sie beweisen weder die Kundenkapazität noch die finanzielle Schwäche für sich allein, zeigen aber, dass der Dienst vor dem Start auf substanzielle Bau- und Einstellungsmaßnahmen angewiesen war.

Eine französische Region enthält drei physische Ausfallbereiche

PREMI3NS ist physisch enger, als das Wort Cloud vermuten lässt. Der aktuelleÜberblick über die Vertrauenswürdige Cloudgibt an, dass es sich um ein autonomes Cloud-Universum mit einer einzigen Region handelt,u-france-east1. Diese Region umfasst drei Zonen:u-france-east1-a,u-france-east1-bundu-france-east1-c. Das Verkaufsmaterial von S3NS gibt an, dass die Regiondrei unabhängige Rechenzentren in Frankreichumfasst. Frühere S3NS-Dokumente verorteten sie in der Region Paris und beschrieben dedizierte Räume in der Nähe der drei Google-Frankreich-Rechenzentren mit physisch und logisch isolierten Racks, Servern und Netzwerken.

Dies ist ein bedeutender physischer Beleg. Es deutet auf mehr als drei Etiketten auf einem einzelnen Serverraum hin. Der Anbieter behauptet, dass die Zonen unabhängigen Rechenzentren entsprechen, und seine Dokumentation weist die Kunden an, jede Zone als separate Ausfallzone zu betrachten. Anwendungen, die über Zonen verteilt sind, können daher so ausgelegt werden, dass sie bestimmte Hardware-, Strom-, Kühlungs- oder Netzwerkausfälle in einer Zone überleben.

Aber eine Zone ist nicht automatisch ein vollständiges Duplikat jedes Dienstes. Recheninstanzen und zonale Festplatten bleiben an eine Zone gebunden. Einige regionale Dienste replizieren sich über Zonen hinweg, während andere verwaltete Produkte ihre eigenen Haltbarkeits- und Verfügbarkeitssemantiken haben. Ein Kunde, der eine virtuelle Maschine startet und eine zonale Festplatte anhängt, hat nicht einfach durch die Wahl einer Drei-Zonen-Region eine Kontinuität über drei Standorte hinweg erhalten. Er hat zwei zonale Ressourcen in einer einzigen Ausfallzone platziert.

Die Architekturlast bleibt beim Kunden. Das Rechnen erfordert mindestens eine weitere Instanz in einer anderen Zone, Health Checks und einen Traffic-Failover-Mechanismus. Zustandsbehaftete Systeme benötigen ein Replikationsmodell, dessen Konsistenz- und Wiederherstellungsverhalten zur Anwendung passt. Identität, Geheimnisse, Protokollierung und Bereitstellungskontrollen müssen ebenfalls denselben Zonenausfall überleben. Backups müssen wiederherstellbar sein, wenn der primäre Dienst beeinträchtigt ist, anstatt nur als ein weiteres Objekt innerhalb der betroffenen Betriebsgrenze zu existieren.

S3NS veröffentlicht in den hier referenzierten Dokumenten weder die Adressen noch die Betreiber der drei Einrichtungen. Diese Zurückhaltung ist für eine Plattform, die für sensible Arbeitslasten entwickelt wurde, verständlich. Sie bedeutet auch, dass ein Käufer allein anhand der Zonennamen nicht unabhängig feststellen kann, ob die Standorte ein Überschwemmungsgebiet, ein Umspannwerk, einen Glasfaserkorridor, einen Eigentümer, einen Wartungsauftragnehmer oder einen Fernwartungsanbieter gemeinsam nutzen.

„Unabhängige Rechenzentren“ ist eine nützliche Behauptung; das Korrelationsrisiko bleibt eine Frage der Due Diligence, die unter Vertraulichkeit gestellt werden muss.

Drei Zonen ergeben keine zweite Region

Die wichtigste architektonische Einschränkung wird in der S3NS-Dokumentation explizit angegeben: Die Vertrauenswürdige Cloud hat derzeit nur eine Region, undFunktionen, die mehrere Regionen erfordern, sind nicht verfügbar. Dies macht den Unterschied zwischen Hochverfügbarkeit und Notfallwiederherstellung besonders wichtig.

Drei Zonen können vor einem Server-, Rack- oder Standortereignis schützen, wenn die Anwendung sie richtig nutzt. Sie schützen nicht vor allen Ereignissen, die die Region als Ganzes betreffen. Regionale Identitätsausfälle, Steuerungsebene, Software, Routing oder betriebliche Ausfälle können Zonengrenzen überschreiten. Ein schwerwiegendes städtisches Strom- oder Glasfaserereignis kann ebenfalls einen korrelierten Druck erzeugen, selbst wenn die Gebäude physisch getrennt sind. Gleiches gilt für eine Sicherheitsmaßnahme, die absichtlich einen gemeinsam genutzten Dienst in der gesamten Umgebung deaktiviert.

Die öffentliche Cloud von Google ermöglicht es einem Kunden normalerweise, Regionen zu paaren. PREMI3NS bietet dieses Modell derzeit nicht in seinem qualifizierten Universum an. Seine „globalen“ Ressourcen sind nur innerhalb der autonomen S3NS-Umgebung global und werden in die einzige französische Region aufgelöst; sie sind keine Repliken, die über die globale Google-Cloud verteilt sind. Dies ist eine notwendige Konsequenz einer strikten gerichtlichen und betrieblichen Trennung, ändert aber die Wiederherstellungsrechnung.

Ein Kunde, der den Verlust vonu-france-east1überleben muss, benötigt eine zweite Umgebung außerhalb von PREMI3NS. Dies könnte ein eigener Rechenzentrumspark, ein anderer qualifizierter französischer oder europäischer Anbieter, eine separat gesteuerte Kaltwiederherstellungsumgebung oder eine weniger sensible Dienstebene mit einer sorgfältig definierten Datengrenze sein. Jede Wahl bringt ihre eigenen Probleme mit sich: Datenreplikation, Schlüsselverwaltung, Softwarekompatibilität, Netzwerkkapazität, Betreiberzugriff und rechtlicher Status der Wiederherstellungskopie.

Dies ist kein Argument gegen PREMI3NS. Eine einzelne Region kann die richtige Grenze für sensible Daten sein, insbesondere wenn die Alternative einem ausländischen Anbieter direkte betriebliche Kontrolle gibt. Es ist ein Argument dagegen, drei Zonen mit geografischer Notfallwiederherstellung gleichzusetzen. Die Entscheidung liegt in der Geschäftsauswirkungsanalyse: Welche Arbeitslasten können einen regionalen Ausfall verkraften, welche müssen anderswo wiederhergestellt werden und wie viele Daten oder Funktionen können während dieser Verschiebung verloren gehen?

Die Anbieterdokumentation weist in die richtige Richtung, indem sie den Kunden rät, Anwendungen über Zonen zu verteilen. Ein ausgereifter Vertrag sollte diesen Gedanken fortsetzen. Er sollte definieren, ob S3NS einen regionalen Wiederherstellungsplan hat, wie die Konfiguration und Metadaten des Kunden nach einem katastrophalen Verlust wiederhergestellt werden und welche Unterstützung für den Wiederaufbau außerhalb der Plattform verfügbar ist, wenn die Region nicht innerhalb des Zeitrahmens des Kunden zurückkehren kann.

Die physische Isolation ändert, wer die Maschinen berühren kann

Die zentrale technische Behauptung von S3NS ist nicht nur, dass die Daten in Frankreich gespeichert sind. Es ist, dass die Ausrüstung isoliert ist und die Personen, die sie betreiben können, unter der Kontrolle von S3NS stehen. Das Unternehmen beschreibt dedizierte Racks, Server und Netzwerkausrüstung, physische Zugangskontrollen, Überwachung und Einbrucherkennung sowie separate Identitäten, Vertrauensanker, Verschlüsselung und Netzwerkgrenzen. DieQualifizierungsankündigunggibt an, dass nur S3NS-Mitarbeiter den Dienst verwalten und dass Googles Technologie und Updates zur Analyse und Validierung vor der Produktionsbereitstellung in eine Quarantänezone gelangen.

Diese Kontrollen adressieren mehrere reale Risiken. Ein von Google angestellter Remote-Administrator sollte nicht in die Umgebung gelangen können. Ein Software-Update soll nicht direkt vom Technologieanbieter in die Produktion gelangen. Die kryptografische Kontrolle und die Produktionsidentität liegen beim französischen Betreiber. Der qualifizierte Dienst muss auch die SecNumCloud-Anforderungen an physische Sicherheit, isolierte Verwaltung, Incident Management, Kontinuität, Unterauftragsvergabe und Schutz vor nicht-europäischem Recht erfüllen.

Die physische Trennung schafft jedoch einen Betriebspark, den S3NS selbst unterhalten muss. Jemand muss Server empfangen, Firmware validieren, Racks verkabeln, ausgefallene Festplatten ersetzen, Hardware-Sicherheitsmodule rotieren und die Arbeit im Rechenzentrum koordinieren. Eine Reparatur, die von der globalen Flotte eines Hyperscalers durchgeführt würde, wird zur Verantwortung von S3NS oder zu einer streng kontrollierten Unterauftragsaktivität. Der Betreiber benötigt Personal, Zugriffsrechte, Ersatzteile und Lieferantenverträge an allen drei Standorten.

Die öffentlichen Dokumente geben keine Auskunft über die Anzahl der Racks, Servergenerationen, Gesamtstromkapazität, Kühlungsreserve, Ersatzteilbestände oder die Abdeckung lokaler Techniker für jede Zone. Sie identifizieren auch nicht, welche Arbeiten von S3NS-Mitarbeitern und welche von den Standorteigentümern oder spezialisierten Subunternehmern ausgeführt werden. SecNumCloud stellt fest, dass die Kontrollen im qualifizierten Umfang bewertet wurden. Dies liefert den Kunden keinen Kapazitätsplan oder eine Garantie für die Reparaturzeit für jede Komponente.

Dieser verborgene Betriebspark ist die wirtschaftliche Substanz des Dienstes. Kunden zahlen an S3NS, um Ausrüstung, Mietverträge, Strom, Transit, Lizenzen, Sicherheitskontrollen und spezialisierte Arbeitskräfte in gemessene Cloud-Dienste umzuwandeln. Die Marge zwischen installierter Infrastruktur und Kundennachfrage bestimmt, ob ein ausgefallenes Rack zu einer routinemäßigen Evakuierung oder einer Kapazitätsknappheit führt. Der Teilevertrag bestimmt, ob ein ausgefallenes Netzwerk-Chassis in Stunden zurückkommt oder auf internationale Logistik wartet. Keines dieser Ergebnisse ist in einem Produktkatalog sichtbar.

Software-Souveränität hat eine Wartungsuhr

PREMI3NS ist so konzipiert, dass Google die Kundenumgebung nicht verwalten oder remote abschalten kann. Dies beseitigt nicht die Abhängigkeit von Googles Engineering. Verwaltete Datenbanken, Orchestrierung, Speicher und Analysedienste bleiben komplexe Softwaresysteme, die Sicherheitspatches, Kompatibilitätsarbeiten und Hardware-Ermöglichung benötigen. Die Frage ist daher nicht nur, ob S3NS den heutigen Code nach einem Anbieterausfall am Laufen halten kann. Es ist, wie lange es sicher laufen kann, während Schwachstellen, Zertifikate, Abhängigkeiten und Kundenanforderungen weitergehen.

DieSecNumCloud 3.2-Anforderungenbefassen sich explizit mit der betrieblichen Autonomie, wenn ein Anbieter von einem Dritten abhängt. Der Leiter der ANSSI hat später öffentlich betont, dass die Qualifizierung vor direktem nicht-europäischem Zugriff und einem kundenspezifischen Herunterfahren schützt, aber nicht bedeutet, dass es keine technologische Abhängigkeit gibt. Dies ist die richtige Unterscheidung. Souveränität über den Betrieb ist nicht dasselbe wie dauerhafte Unabhängigkeit von jedem Anbieter.

Google gibt an, dass sein Dedicated-Cloud-Design es dem lokalen Partner ermöglicht, Updates zu überwachen, zu blockieren und rückgängig zu machen, und dass es bis zu12 Monate nach dem Abbruch der Verbindung zu Googleweiter betrieben werden kann. Derselbe Google-Beitrag identifiziert PREMI3NS als die französische Implementierung. Dies ist eine bedeutende Aussage zur Kontinuität, aber die öffentliche Formulierung beschreibt eine Designfähigkeit eher als eine kundenspezifische Wiederherstellungsgarantie. Ein Käufer sollte feststellen, welche PREMI3NS-Dienste abgedeckt sind, was „Betrieb“ während des Zeitraums bedeutet, welche Sicherheitsupdates verfügbar bleiben und was am Ende passiert.

Der Quarantänemechanismus bringt seinen eigenen Kompromiss mit sich. Das Filtern von Updates reduziert das Risiko, dass eine kompromittierte oder ungeeignete Version in die vertrauenswürdige Umgebung gelangt. Es kann auch zu einer Funktionslücke und einer Warteschlange führen, wenn viele Upstream-Änderungen gleichzeitig eintreffen. S3NS benötigt ausreichende technische Tiefe, um Updates zu bewerten, zu testen, zu genehmigen oder abzulehnen, ohne kritische Schwachstellen ungelöst zu lassen.

Kunden benötigen eine Vorankündigung über Abweichungen von der Standard-Google-Cloud, damit Bereitstellungsskripte und Annahmen über verwaltete Dienste nicht stillschweigend abweichen.

Die S3NS-Dokumentation warnt bereits, dass die Vertrauenswürdige Cloud ein separates Produkt mit einer Teilmenge von Google Cloud-Produkten und anderen Endpunkten ist, einschließlichs3nsapis.frstattgoogleapis.com. Dies ist ein Beleg für die tatsächliche Trennung. Es ist auch ein Beleg dafür, dass die Migration kein einfacher Regionswechsel ist. Anwendungsbesitzer müssen Code, Bibliotheken, Identitätsannahmen, Dienstverfügbarkeit und Betriebsabläufe gegenüber dem S3NS-Universum selbst testen.

Konnektivität beginnt dort, wo der Kunde die Cloud betritt

Ein souveräner Server, der nicht erreichbar ist, ist kein Dienst. PREMI3NS unterstützt öffentlichen Internetzugang, Cloud VPN und Cloud Interconnect, und diese Pfade haben unterschiedliche Ausfall- und Vertrauensgrenzen. DieDokumentation zur Netzwerkkonnektivitätbeschreibt VPN als verschlüsselten Verkehr über das öffentliche Internet und Interconnect als dedizierte oder Partner-Konnektivität zwischen einem Kundennetzwerk und der Cloud.

Für einen Produktionspark muss das Zugriffsdesign dem Zonendesign entsprechen. Zwei virtuelle Maschinen in getrennten Zonen sind immer noch auf einen einzigen Kundenrouter angewiesen, wenn beide über einen einzigen Tunnel erreicht werden. Zwei Interconnect-Schaltungen können sich immer noch einen Gebäudeeingang, einen Carrier, ein optisches System oder einen städtischen Kabelkanal teilen. Ein resilientes Design erfordert Diversität an jedem Übergabepunkt: Kundenrouter, Transportanbieter, Interconnects, S3NS-Edge-Domänen, BGP-Sitzungen und ausreichende Failover-Bandbreite, um die kritische Last zu transportieren.

DieDokumentation zu Partner Interconnectvon S3NS verdeutlicht diesen Punkt. Sie gibt an, dass ein Design mit 99,9 % Verfügbarkeit zwei redundante Verbindungen in unterschiedlichen Edge-Verfügbarkeitsdomänen erfordert, während ihr generisches Modell mit 99,99 % vier Verbindungen erfordert, die auf zwei Ballungsraum-Zonen und zwei Regionen verteilt sind. Da PREMI3NS derzeit nur eine Region hat, kann dieses Zwei-Regionen-Modell nicht vollständig innerhalb des aktuellen S3NS-Universums implementiert werden. Kunden sollten nicht annehmen, dass der Kauf von vier Schaltungen innerhalb von Paris die gleiche Ausfallisolierung schafft.

HA VPN hat eine andere Topologie. S3NS dokumentiert eine Konfiguration mit 99,99 % Verfügbarkeit, wenn beide Schnittstellen des verwalteten Gateways über korrespondierende Tunnel zur Gegenstelle verbunden sind. Aber die End-to-End-Verbindungsverfügbarkeit hängt immer noch von den physischen Gateways des Kunden, Internetdienstanbietern oder Interconnects, der Routing-Policy und der gehosteten Arbeitslast ab. Eine Cloud-seitige Service-Level-Zahl deckt keinen einzelnen Router in den Räumlichkeiten des Kunden ab.

Der Durchsatz ist auch Teil der Wiederherstellung. Ein Interconnect, der für normale Datenbankreplikation dimensioniert ist, kann zu klein sein, um Speicher nach einem Ausfall neu zu befüllen. Ein VPN, das Verwaltungsverkehr bequem transportiert, kann zusammenbrechen, wenn es zum einzigen Pfad für Kundentransaktionen wird. Wiederherstellungsübungen müssen die Übertragungsraten in der degradierten Topologie messen und nicht die Portgeschwindigkeit als Indikator verwenden.

Die Transport- und Backbone-Ebene bleibt undurchsichtig

Die PREMI3NS-Dokumentation gibt an, dass sein Premium-Netzwerk den Verkehr über das Vertrauenswürdige Cloud-Netzwerk transportiert und BGP-Pfade zu Peering- oder Transitnetzwerken auswählt. Es ermöglicht Kunden auch, berechtigte IPv4- und IPv6-Bereiche mitzubringen, vorbehaltlich der Überprüfung des Eigentums und der Routenursprungsberechtigung. Dies sind ausgereifte Cloud-Netzwerkfunktionen. Sie offenbaren nicht die tatsächlichen Anbieter oder physischen Routen hinter der S3NS-Grenze.

Die in diesem Artikel verlinkten öffentlichen Dokumente nennen keine Transitcarrier, Interconnect-Gebäude, Internet-Austauschpunkte, Backbone-Glasfaseranbieter oder Route-Server-Beziehungen, die von PREMI3NS verwendet werden. Sie veröffentlichen weder eine Plattform-ASN, eine vollständige Liste der Anbieterprefixe noch eine Karte, die ein Kunde zur Feststellung der Pfaddiversität verwenden könnte. Die durch die Arbeitslast eines Kunden exponierten Adressen können auch davon abhängen, ob der Kunde den von S3NS zugewiesenen Raum nutzt, eigene Adressen mitbringt, über einen Partner eintritt oder den Dienst privat hält.

Die Undurchsichtigkeit ist kein Beweis für Zerbrechlichkeit. Sensible Anbieter schränken die Offenlegung der Topologie oft ein, und ein verteiltes virtuelles Netzwerk kann nicht auf ein Router-Symbol reduziert werden. Dies bedeutet, dass der Ausdruck „mehrere Pfade“ unter Vertraulichkeit nachgewiesen werden muss. Käufer sollten fragen, ob die drei Zonen physisch getrennte Glasfasereingänge haben, ob sich Inter-Zonen-Verbindungen Kabelkanäle teilen, wo dedizierte Interconnects enden und ob zwei benannte Carrier-Produkte letztlich dasselbe Großhandelsnetz nutzen.

Sie sollten auch fragen, wie S3NS die Routing-Sicherheit validiert. Vom Kunden bereitgestellte Prefixe erfordern korrekte Route-Origin-Authorizations, genaue Routing-Objekte und kontrollierten Failover. Der Anbieterraum erfordert eigene Ursprungssicherheit und Filterung. Eine fehlerhafte Routing-Policy kann einen gesunden Dienst aus dem Internet entfernen, selbst wenn jedes Rack mit Strom versorgt bleibt.

Die Grenze erstreckt sich über S3NS hinaus. Eine öffentliche Anwendung stützt sich auf DNS, Zertifikatsausstellung, Domain-Registrierung, Content Distribution, Identität und vorgelagerte Benutzernetzwerke. Einige dieser Dienste können außerhalb von PREMI3NS oder außerhalb Frankreichs liegen. Das Hosting der primären Arbeitslast in einer qualifizierten Region bringt nicht automatisch den gesamten Dienst in dieselbe Gerichtsbarkeit oder Ausfallzone.

Installierte Kapazität ist nicht Failover-Kapazität

S3NSkündigte im Februar 2026 30 verwaltete Dienste anund listet H100-GPU-VMs unter seinen Rechenoptionen auf. Dies demonstriert die Bandbreite, nicht die Menge. Die öffentlichen Dokumente geben nicht an, wie viele CPUs, GPUs, Speichergeräte oder Netzwerk-Ports in jeder Zone installiert sind, wie viele reserviert sind oder wie viel Spielraum nach dem Verlust einer Zone verbleibt.

Dies ist wichtig, denn Cloud-Kapazität wird in der Vorstellung des Kunden zweimal verkauft. Der erste Verkauf ist die Elastizität: Ressourcen erscheinen auf Abruf. Der zweite ist die Redundanz: Eine andere Zone scheint bereit zu sein, wenn die erste ausfällt. Beide Versprechen schöpfen aus demselben physischen Inventar. Wenn viele Kunden während eines Zonenereignisses Ersatzinstanzen anfordern, kann die Reservekapazität schnell schwinden. Ein Kontingent, das unter normalen Bedingungen eine Ressource erlaubt, garantiert nicht, dass die entsprechende Hardware während einer regionalen Belastung verfügbar ist.

Spezialausrüstung verschärft die Einschränkung. GPU-Arbeitslasten können von einem bestimmten Beschleuniger, Treiber und einer bestimmten Maschinenfamilie abhängen, die nicht gleichmäßig über die Zonen verteilt sind. Große speicherintensive Datenbanken und Hochdurchsatzspeicher haben ähnliche Platzierungsbeschränkungen. Ein Kunde kann ein nominales Multi-Zonen-Design erstellen, das nicht tatsächlich mit derselben Form an anderer Stelle neu starten kann.

Das richtige Maß ist die nutzbare Kapazität nach dem gewählten Ausfall, nicht die installierte Kapazität davor. Für kritische Dienste benötigen Kunden reservierte oder vertraglich priorisierte Kapazität, Bestätigung der Platzierung und regelmäßige Nachweise, dass die Backup-Zone die Arbeitslast aufnehmen kann. Sie benötigen auch eine vereinbarte Degradationsstrategie: kleinere Instanzen, reduzierte Analysen, ausgesetzte Batch-Jobs oder einen minimalen Transaktionsdienst, wenn die volle Kapazität nicht wiederhergestellt werden kann.

S3NS hat gute Gründe, die Maschinenanzahl nicht zu veröffentlichen. Konkurrenten und Angreifer würden die Information schätzen, und die Zahlen ändern sich schnell. Eine vertrauliche Zusicherung kann Käufern dennoch geben, was sie brauchen: Kapazitätsklassen, getestete Evakuierungsgrenzen, Vorlaufzeiten für seltene Hardware und die Prioritätsregeln, die bei Konflikten verwendet werden. Ohne diese Belege beschreiben „drei Zonen“ Standorte, nicht das Ausmaß des Dienstes, der nach dem Verlust einer Zone verfügbar ist.

Support-Personal ist Teil der Infrastruktur

Das Early-Access-Programm enthüllte ein nützliches Detail über das Betriebsmodell von S3NS. Das Unternehmen gab an, dass Site-Reliability-Ingenieure, Cybersicherheitsteams, Rechenzentrumspersonal, Support, technische Kundenbetreuer und Kundenentwickler alle teilnahmen. Dies ist ein glaubwürdiger Beleg für eine Organisation, die dazu bestimmt ist, mehr als ein Self-Service-Portal zu betreiben. Der aktuelle Plattformüberblick gibt auch an, dass S3NS und nicht Google Cloud für die Verwaltung und den Support der Infrastruktur verantwortlich ist.

Diese lokale Verantwortung steht im Kern des Souveränitätsanspruchs. Ein Kundenereignis sollte nicht erfordern, dass ein Google-Administrator die Umgebung betritt. Es konzentriert die Eskalation auch auf S3NS. Wenn ein Fehler in einer verwalteten Datenbank Upstream-Expertise erfordert, muss S3NS das Problem reproduzieren, kontrollieren, welche Informationen die Umgebung verlassen, sich mit Google koordinieren und einen sicheren Fix zurückspielen. Der Kunde ist auf die Qualität dieser Übersetzungsschicht angewiesen.

Die öffentlichen Dokumente liefern keine vollständige Support-Matrix mit Schweregraddefinitionen, anfänglichen Reaktionszeiten, Wiederherstellungszielen, telefonischen Eskalationsbedingungen und Service-Level-Gutschriften. Die Ankündigung der allgemeinen Verfügbarkeit gibt an, dass vertragliche Service-Level-Agreements den Start begleiteten, reproduziert sie aber nicht. Käufer benötigen daher den Vertrag, nicht die Startsprache.

Die Reparaturuhr sollte heruntergebrochen werden. Erkennung ist die Zeit, bis S3NS oder der Kunde einen Ausfall bemerkt. Übernahme ist die Zeit, bis jemand mit Autorität ihn akzeptiert. Diagnose identifiziert, ob das Problem zur Kundenkonfiguration, zum verwalteten Dienst, zum S3NS-Netzwerk, zu einer Einrichtung oder zu einem Technologie-Update gehört. Zugang ist die Zeit, bis ein Ingenieur den betroffenen Standort betreten kann. Reparatur umfasst Teile, Änderungsfreigabe und Validierung. Wiederherstellung ist erst abgeschlossen, wenn die Anwendung, Daten und die Warteschlangenarbeit wieder verwendbar sind.

Ein gemischtes Wiederherstellungsziel verbirgt diese Übergänge. Es verbirgt auch Dritte. Remote-Hands-Einrichtungen, Glasfasertechniker, Hardware-Anbieter und Google-Spezialisten können alle involviert sein, ohne die Kundenumgebung direkt zu bedienen. Ein Kunde sollte wissen, welcher Teil die Uhr anhalten kann, welcher Teil während eines schwerwiegenden Vorfalls mit ihm spricht und ob der Statuskanal erreichbar bleibt, wenn die Identität oder Konsole von S3NS beeinträchtigt ist.

Ein Service-Level-Agreement baut keine resiliente Anwendung

S3NS hat die allgemeine Verfügbarkeit als Beginn formaler Service-Level-Agreements und Produktionsbereitschaft beschrieben. Dies ist ein notwendiger kommerzieller Beleg. Ein SLA bleibt ein begrenztes Versprechen um eine definierte Dienstmetrik herum. Es kann keine zonale virtuelle Maschine regional machen, keine zweite PREMI3NS-Region hinzufügen oder eine Kundenarchitektur reparieren, die jeden Pfad durch ein einzelnes Gateway leitet.

Der Unterschied wird bei einem zusammengesetzten Vorfall deutlich. Angenommen, eine Zone verliert den Strom, die Anwendung failt über, und die überlebende Datenbank erreicht ein vom Kunden auferlegtes Verbindungslimit. Der Infrastrukturdienst kann sein Verfügbarkeitsmaß erfüllen, während die Anwendung nicht verfügbar ist. Wenn der Kunde Identität, Geheimnisse oder Überwachung nicht verteilt hat, kann der Anbieter die Infrastruktur wiederherstellen, bevor das Unternehmen den Dienst wiederherstellen kann.

Service-Gutschriften sind ebenfalls begrenzt. Sie passieren eine Rechnung nach einem qualifizierten Ausfall. Sie erstatten keine verlorenen öffentlichen Dienste, verzögerte medizinische Arbeiten, verpasste Finanztransaktionen oder Notfallmigrationsarbeit. Für sensible Systeme deckt die nützliche Vertragssprache Incident-Kommunikation, Datenintegrität, Unterstützung, Beweissicherung, Wiederherstellungsprioritäten und Kündigungsunterstützung ab, nicht nur einen monatlichen Verfügbarkeitsprozentsatz.

Wartungsausschlüsse verdienen gleiche Aufmerksamkeit. Ein Betreiber, der eine Software-Lieferkette unter Quarantäne betreibt, muss patchen und upgraden. Kunden müssen wissen, welche Vorankündigung gilt, ob Zonen sequenziell gewartet werden, was passiert, wenn eine dringende Änderung nicht warten kann und ob ein Rollback technisch möglich ist. Sie sollten Anwendungen so entwerfen, dass sie das Wartungsverhalten tolerieren, das der Vertrag erlaubt.

Der Statuskanal ist eine weitere Abhängigkeit. Die S3NS-Dokumentation verweist Kunden auf ein Health-Dashboard für den Vertrauenswürdigen Cloud-Dienst, aber ein nützlicher Heavy-Outage-Kanal muss außerhalb der Konsole und des ausgefallenen Identitätsplans funktionieren. Benannte Kontakte, unabhängige Benachrichtigungspfade und eine Kadenz für Updates sind eine betriebliche Fähigkeit: Sie bestimmen, wie schnell Kunden zwischen Warten, Failover und Ausrufen eines regionalen Wiederherstellungsplans wählen können.

SecNumCloud ist eine starke, aber keine universelle Versicherung

Die SecNumCloud-Qualifizierung ist der stärkste öffentliche Beleg, der PREMI3NS stützt. Der ANSSI-Rahmen deckt weit mehr als den Datenstandort ab. Seine Anforderungen umfassen physische Sicherheit, Zugangskontrolle, isolierte Verwaltung, Protokollierung, Schwachstellenmanagement, Kryptografie, Kontinuität, Lieferantenmanagement, Reversibilität und Schutz vor nicht-europäischem Recht. DieFAQ zur Qualifizierungder Agentur erklärt, dass Kundendaten, Administrationsverzeichnisse, Benutzerverzeichnisse, Protokolle, Root-Zertifizierungsstellen und Backups territorialen Kontrollen unterliegen müssen und dass die fortlaufende betriebliche Autonomie bewertet wird.

Die Entscheidung gibt auch an, dass S3NS die Empfehlung R9 der Cloud-Doktrin des französischen Staates erfüllt und Schutz vor nicht-europäischem Recht bietet. Dies ist ein wichtiges Ergebnis für öffentliche Stellen und regulierte Organisationen. DieCloud-au-Centre-Doktrinin Frankreich lenkt besonders sensible staatliche Arbeitslasten zu qualifizierten kommerziellen Clouds, die vor unbefugtem Zugriff durch Behörden aus Drittländern geschützt sind.

Die Qualifizierung bedeutet nicht, dass jede Nutzung von S3NS automatisch konform oder widerstandsfähig ist. Die ANSSI-Entscheidung macht die Nutzung von den Empfehlungen des Rahmens abhängig. Kunden konfigurieren weiterhin Identitäten, Netzwerke, Speicher, Verschlüsselung, Protokollierung und Anwendungen. Sie können eine Einzelzonen-Datenbank erstellen, einen unsicheren Dienst bereitstellen oder Daten in ein nicht qualifiziertes externes System kopieren.

Das Visum deckt auch nicht jedes Produkt ab, das unter dem Namen S3NS verkauft wird. Es deckt den genannten CLOUD DE CONFIANCE-Dienst als IaaS, PaaS und CaaS ab. CRYPT3NS wurde ausdrücklich als Sprungbrett vermarktet, das nicht die SecNumCloud-Qualifizierung anstrebte. Partner-SaaS-Anwendungen, die auf PREMI3NS laufen, erfordern ihre eigene Umfangsanalyse. Ein qualifiziertes Substrat qualifiziert nicht automatisch die Software und die Betriebspraktiken darüber.

Schließlich hat das Visum ein Ablaufdatum. Es ist drei Jahre gültig und von der fortlaufenden Konformität abhängig. Wesentliche rechtliche, organisatorische oder technische Änderungen müssen im Rahmen der Qualifizierungsverpflichtungen behandelt werden. Einkäufe sollten die Entscheidungsnummer, den Umfang, das Ablaufdatum und etwaige nachfolgende Bedingungen erfassen, anstatt „SecNumCloud“ als zeitloses Abzeichen zu verwenden.

Kundenankündigungen zeigen Nachfrage, nicht getestete Wiederherstellung

S3NS hat Kunden in den Bereichen Versicherung, Gesundheit, Finanzen, Industrie und Dienstleistungen genannt. Seine Qualifizierungsankündigung nannte MGEN, Matmut, AGPM, Thales, Birdz, Qonto, BConnect und Club Med. DerMGEN-Fallist besonders bedeutsam, da der Versicherer eine Plattform beschrieb, die bis zu sechs Millionen Menschen aufnehmen soll. Eine Ankündigung vom April 2026 gab an, dass SAP RISE Private Cloud Edition im zweiten Halbjahr 2026 auf PREMI3NS für Thales bereitgestellt wird und Kernbereiche wie Finanzen, Lieferkette, Fertigung und Beschaffung abdeckt.

Diese Namen stützen die Schlussfolgerung, dass S3NS reale Arbeitslasten bedient oder vorbereitet. Sie zeigen auch, wer die Folgen eines Ausfalls trägt: Versicherte, Nutzer von Gesundheitsdiensten, Mitarbeiter, Lieferanten, Finanzteams und Industriebetriebe. Diese Konsequenz erhöht den Wert einer starken französischen Kontrolle, während sie gleichzeitig den Bedarf an praktischer Wiederherstellung erhöht.

Eine Kundenankündigung ist keine Vorfallhistorie. Sie gibt selten an, welche Arbeitslasten bereits in Produktion sind, wie viele Daten sie enthalten, ob sie sich über drei Zonen erstrecken, welche Wiederherstellungszeit demonstriert wurde oder ob eine regionale Evakuierung durchgeführt wurde. „Ausgewählt von“ kann einen Vertrag, ein Migrationsprogramm, einen Early-Adopter-Test oder einen Produktionspark beschreiben. Jedes hat ein unterschiedliches Beweisgewicht.

Die richtige Verwendung dieser Ankündigungen ist daher bescheiden. Sie validieren die Marktdynamik und zeigen, dass anspruchsvolle Organisationen ihre eigenen Bewertungen durchgeführt haben. Sie übertragen nicht die nicht offengelegte Versicherung dieser Organisationen auf einen anderen Käufer. Ein neuer Kunde muss seine eigene Anwendung, sein Netzwerk, seine Daten und seine Support-Kette testen.

S3NS ist auch selbst Kunde von Anbietern. Rechenzentrumsbetreiber, Versorgungsunternehmen, Carrier, Serverhersteller, Komponentendistributoren und Google stehen hinter dem Dienst, auch wenn sie ihn nicht verwalten können. Das Vertrauensmodell ist stärker, wenn jede Abhängigkeit eingeschränkt, ersetzbar und getestet ist. Es ist schwächer, wenn der Kunde den S3NS-Vertrag als Endknoten der Kette behandelt.

Datenlokalität erfordert eine Karte jeder Kopie

PREMI3NS bietet ein klares Primärstandortangebot: Daten und Arbeitslasten bleiben in Frankreich in einer dedizierten S3NS-Umgebung. Dies ist stärker, als den Standort aus einer Rechnungsadresse oder einem IP-Geolokalisierungsergebnis abzuleiten. Die Architektur hält auch Produktionsidentität, Schlüsselkontrolle, Verwaltung und Support unter der Autorität des französischen Betreibers.

Kunden müssen dennoch jede Informationskategorie kartieren. Primärdaten, Replikate, Backups, Snapshots, Protokolle, Support-Anhänge, Abrechnungsaufzeichnungen, Telemetrie, Schlüssel und Identitätsmetadaten teilen nicht unbedingt denselben Lebenszyklus. SecNumCloud erlegt innerhalb des qualifizierten Dienstes territoriale Anforderungen auf, aber ein Kunde kann Protokolle an eine externe Plattform senden, einen Support-Fall mit sensiblen Daten eröffnen oder eine Datenbank in eine andere Gerichtsbarkeit replizieren.

Das Einzelzonen-Design macht die Backup-Platzierung besonders wichtig. Ein Backup, das auf drei Zonen kopiert wird, kann einen Geräte- oder Standortausfall überleben, bleibt aber innerhalb vonu-france-east1. Eine Kopie außerhalb der Region verbessert die Notfallwiederherstellung, kann aber die genaue qualifizierte Grenze verlassen, die die Organisation gewählt hat. Einige Arbeitslasten können eine verschlüsselte Kaltlagerung bei einem anderen qualifizierten Anbieter rechtfertigen; andere können gesetzlich oder betrieblich verpflichtet sein, in der S3NS-Umgebung zu bleiben. Die Antwort hängt von den Daten und dem Wiederherstellungsziel ab.

Das Schlüsselmanagement muss derselben Karte folgen. Eine Wiederherstellungskopie ist nutzlos, wenn ihre Schlüssel in der ausgefallenen Region gefangen sind. Ein anderswo kopierter Schlüssel kann einen neuen Zugriffspfad schaffen, der die ursprüngliche Kontrolle gefährdet. Das Wiederherstellungsdesign erfordert daher unabhängige Verfügbarkeit für Schlüssel, Identitäten, Konfiguration und autorisierte Personen, mit Kontrollen, die mindestens so bewusst sind wie die um die Daten herum.

Die Lokalität ändert auch die Latenz und die Servicezone. Die drei Rechenzentren befinden sich in Frankreich, frühere S3NS-Beschreibungen verorten sie in der Region Paris. Europäische Benutzer können von guter Latenz profitieren, aber eine französische Region ist nicht automatisch nahe an jeder Niederlassung, Fabrik oder Überseegebiet. Das Zugangsnetzwerk und das Anwendungsdesign bestimmen die wahrgenommene Leistung. Eine multinationale Organisation muss auch entscheiden, ob alle Benutzer und Daten unter französische Gerichtsbarkeit fallen oder ob PREMI3NS nur die sensible Teilmenge enthalten soll.

Migration ist der ultimative Wiederherstellungsmechanismus

S3NS wirbt mit Kontinuität zur Google-Cloud-Technologie, was den Migrationsaufwand für Kunden, die bereits vertraute APIs und verwaltete Dienste nutzen, reduzieren kann. Dies macht die Plattformen nicht identisch. Das dedizierte Universum hat andere Endpunkte, einen eingeschränkteren Dienstesatz, eine einzige Region und durch die Qualifizierung vorgegebene Betriebskontrollen. Die Migration zu PREMI3NS ist ein geplantes Engineering-Programm; die Migration weg davon wird es auch sein.

Ein S3NS-Migrationsleitfaden stellt fest, dass die Übertragungszeit vom Datenvolumen und der Netzwerkbandbreite abhängt. Diese einfache Aussage wird während eines Ausfalls ernst. 500 Terabyte über einen Pfad mit einer anhaltenden Datenrate von 5 Gigabit pro Sekunde zu verschieben, dauert mehr als neun Tage vor Protokoll-Overhead, Wiederholungen, Validierung und Anwendungs-Failover. Wenn der Quelldienst beeinträchtigt ist, kann der tatsächliche Durchsatz viel geringer sein. Wenn das Ziel eine andere verwaltete Datenbank verwendet, kann die Konvertierung das Kopieren dominieren.

Französische und europäische Regeln stärken die Position des Kunden. Artikel 28 desfranzösischen SREN-Gesetzesverlangt, dass Cloud-Dienste sichere Interoperabilität, Portabilität von exportierbaren Daten und digitalen Vermögenswerten sowie die dafür erforderlichen Schnittstellen und Informationen unterstützen. DieArcep-Empfehlung von 2025konzentriert sich auf Wechseltransparenz und stabile Schnittstellen. Die europäische Datenverordnung schreibt Wechselverpflichtungen vor und schafft Wechselgebühren schrittweise ab.

Gesetzliche Portabilität garantiert keine betriebliche Gleichwertigkeit. Exportierbare Daten können das geistige Eigentum des Anbieters ausschließen. Eine Kubernetes-Anwendung lässt sich möglicherweise einfacher verschieben als eine Arbeitslast, die um BigQuery, Cloud SQL-Verhalten, Anbieteridentität und proprietäre Überwachung herum aufgebaut ist. Selbst wenn die Aufzeichnungen korrekt exportiert werden, können Richtlinien, Warteschlangen, Ereignisverlauf, kryptografischer Status und Betriebs-Dashboards möglicherweise nicht migrieren.

Kunden sollten daher eine kleine vollständige Wiederherstellungsbereitstellung an anderem Ort unterhalten. Sie sollte reale Daten wiederherstellen, Identität und Vernetzung neu erstellen und beweisen, dass das Unternehmen auf einem definierten Mindestniveau arbeiten kann. Die Übung sollte die Übertragungsgeschwindigkeit, Konvertierungsfehler, fehlende Metadaten und benötigte Personen aufzeichnen. Ein Exit-Plan, der nur als Vertragssprache existiert, ist keine Reservekapazität.

Glaubwürdige Ausfallpfade sind gewöhnlich

S3NS erhält Aufmerksamkeit aufgrund geopolitischer und rechtlicher Fragen, aber die wahrscheinlichsten Ausfälle sind vertraute Infrastrukturereignisse. Eine Stromversorgungskomponente fällt aus. Ein Speichergerät erzeugt Fehler. Eine Glasfaser wird durchtrennt. Eine BGP-Route wird zurückgezogen. Ein Zertifikat läuft ab. Ein Update eines verwalteten Dienstes ändert das Verhalten. Ein Support-Ticket wird falsch kategorisiert. Die Zahlung oder der Kontostatus eines Kunden unterbricht den Zugriff. Eine Migration dauert länger als ihr genehmigtes Fenster.

Ein Rack- oder Serverausfall sollte durch lokale Redundanz aufgefangen werden, aber nur, wenn der Dienst und die Kundenplatzierung dies unterstützen. Ein Zonenausfall sollte durch eine Multi-Zonen-Architektur und ausreichende Überlebenskapazität abgefangen werden. Ein regionaler Ausfall hat keine zweite PREMI3NS-Region und ruft daher das externe Wiederherstellungsdesign des Kunden auf. Ein Upstream- oder Interconnect-Ausfall ruft diversifizierte Netzwerkpfade auf. Eine Unterbrechung der Softwareversorgung ruft die Autonomie und Update-Strategie von S3NS auf.

Ein vertraglicher oder abrechnungstechnischer Streit ruft administrative Kontinuität und Exportrechte auf.

Jeder Pfad betrifft eine andere Population. Ein isolierter Analysedienst kann interne Berichte verzögern. Ein Identitätsausfall kann jede Anwendung am Start hindern, selbst wenn die Rechenleistung gesund bleibt. Der Verlust einer Gesundheitsplattform kann die Patientenversorgung und den Zugang beeinträchtigen. Der Verlust eines industriellen ERP-Systems kann Einkauf, Fertigung und Versand blockieren. Die Abhängigkeit sollte nach Geschäftsfunktion klassifiziert werden, nicht nach der scheinbaren Bedeutung des Cloud-Ressourcennamens.

Zusammengesetzte Ausfälle verdienen besondere Aufmerksamkeit. Ein Zonenausfall während der Wartung hinterlässt weniger Reservekapazität. Ein Cybervorfall kann die Automatisierung deaktivieren und gleichzeitig die Nachfrage nach manuellem Support erhöhen. Ein regionales Netzwerkproblem kann die Backup-Übertragung verlangsamen, selbst wenn sie für die Wiederherstellung vorgesehen ist. Ein Streit mit einem Anbieter kann mit einer dringenden Sicherheitslücke zusammenfallen. Resilienz ist die Fähigkeit, durch diese Kombinationen zu arbeiten, nicht das Vorhandensein von drei Kästchen in einem Architekturdiagramm.

S3NS hat eine außergewöhnlich starke Kontrolle um eine französische Cloud auf Basis nicht-französischer Technologie herum aufgebaut. Diese Errungenschaft beseitigt einige Ausfallpfade, insbesondere direkte ausländische Verwaltung und kundenspezifisches remote Herunterfahren durch den Technologieanbieter. Sie beseitigt nicht die Physik, Softwarealterung, menschliches Versagen oder Kundenkonzentration.

Welche Belege ein Käufer einholen sollte, bevor er eine kritische Arbeitslast überträgt

Der erste Beleg sollte die Platzierung beschreiben. S3NS kann unter angemessener Vertraulichkeit bestätigen, dass die ausgewählten Dienste die drei Rechenzentren nutzen, welche Komponenten zonal bleiben, welche regional sind und welche Steuerungsebenenabhängigkeiten Zonen überspannen. Der Kunde kann dann jede Rechen-, Speicher-, Identitäts-, Schlüssel-, Protokollierungs- und Bereitstellungskomponente einer Ausfallzone zuordnen.

Der zweite Beleg sollte die Überlebensfähigkeit beschreiben. Für jede kritische Maschine und jeden verwalteten Dienst muss der Kunde wissen, ob eine äquivalente Kapazität reserviert ist oder wahrscheinlich nach dem Verlust einer Zone verfügbar ist. Spezielle CPUs, große Arbeitsspeicherformen, Speicherleistung und öffentliche Adressen sollten eingeschlossen sein. Ein erfolgreicher Test, bei dem Arbeitslasten in einer anderen Zone neu starten, ist wertvoller als ein Verfügbarkeitsadjektiv.

Der dritte Beleg sollte die physische und Netzwerkdiversität beschreiben, ohne sensible Details öffentlich preiszugeben. Das unabhängige Risiko von Einrichtungen und Versorgungsunternehmen, getrennte Eingänge, Inter-Zonen-Pfade, Carrier-Eigentum, Interconnect-Terminierung und Failover-Bandbreite können in einem kontrollierten Versicherungsrahmen validiert werden. Die Antwort sollte gemeinsame Abhängigkeiten identifizieren, nicht nur Verträge zählen.

Der vierte Beleg sollte Reparatur und Eskalation beschreiben. Der Kunde sollte wissen, wer zu jeder Stunde antwortet, wann S3NS-Personal vor Ort involviert ist, welche Reparaturen von Einrichtungs- oder Hardware-Anbietern abhängen, welche Teile vor Ort gehalten werden und wie ein Problem ohne Preisgabe von Kundendaten an Google gelangt. Die Kommunikation bei schwerwiegenden Vorfällen sollte einen Out-of-Band-Weg haben.

Der fünfte Beleg sollte eine regionale Wiederherstellungsübung sein. Da es nur eine PREMI3NS-Region gibt, sollte der Kunde einen repräsentativen Dienst außerhalb dieser Region wiederherstellen, einschließlich Daten, Schlüssel, Identität, Konfiguration und Netzwerkeingang. Das gemessene Ergebnis sollte mit dem Wiederherstellungsziel des Unternehmens verglichen werden. Jeder Schritt, der davon ausgeht, dass die Quellkonsole verfügbar bleibt, sollte ohne diese Annahme erneut getestet werden.

Schließlich sollte der Vertrag mit dem technischen Ergebnis übereinstimmen. Der Qualifizierungsumfang, Service Level, Wartung, Support bei Vorfällen, Datenstandort, Subunternehmer, Kontinuität der Softwareversorgung, Portabilität, Löschung und Kündigungsunterstützung sollten alle denselben Dienst beschreiben, der von den Ingenieuren getestet wurde. Ein Vertrag kann keine Kapazität schaffen, aber er kann Verantwortlichkeit und Beweise vor einem Ausfall verfügbar machen.

Das Beweismaß ist Mittel

S3NS hat die Schwelle vom plausiblen Projekt zum attestierten Betreiber überschritten. PREMI3NS ist allgemein verfügbar, hat einen benannten rechtlichen Anbieter, beschäftigt ein substanzielles französisches Team, betreibt eine dokumentierte autonome Region, stellt einen breiten Katalog verwalteter Dienste bereit, hat öffentliche Kundenprogramme und besitzt eine aktuelle SecNumCloud 3.2-Qualifizierung für IaaS, PaaS und CaaS. Dies sind stärkere Signale als eine Marketingkarte, eine ruhende Unternehmensakte oder ein ungeprüftes Cloud-Label.

Die Herabstufung von Stark spiegelt wider, was öffentlich nicht verfügbar bleibt. Die drei Rechenzentrumsbetreiber und genauen Standorte werden nicht genannt. Die Diversität von Versorgungsunternehmen, Carriern, Backbone und Interconnects wird nicht beschrieben. Es gibt keine öffentliche Bestandsaufnahme der Flotte, Zonenevakuierungsgrenzen, Ersatzteilpläne oder vollständigen Kunden-Support-Reaktionsbedingungen. Am wichtigsten ist, dass PREMI3NS eine einzige Region hat. Seine drei Zonen verbessern die Verfügbarkeit, bieten aber keine interne Wiederherstellung bei Verlust der Region.

Die richtige Schlussfolgerung ist daher weder „französische Kontrolle löst alles“ noch „Google-Technologie macht Souveränität bedeutungslos“. Die ANSSI hat festgestellt, dass Thales Cloud Sécurisé die qualifizierte Umgebung kontrolliert und sie unter den festgelegten Bedingungen vor nicht-europäischem rechtlichem Zugriff schützt. Die Plattform bleibt dennoch von Google-Technologie, französischer Rechenzentrumsinfrastruktur, Strom, Glasfaser, Hardware-Beschaffung und S3NS-Personal abhängig.

Diese Abhängigkeiten können gemanagt werden, weil sie identifizierbar sind; sie können nicht gemanagt werden, indem man so tut, als ob sie verschwunden wären.

Für einen Käufer könnte das wertvollste Merkmal von S3NS die Klarheit seiner Grenze sein. Der Dienst ist eine autonome französische Cloud-Region mit drei physischen Zonen, betrieben von einem französischen Unternehmen unter Kontrolle von Thales unter Verwendung von Google-Cloud-Technologie in einem qualifizierten Kontrollmodell. Bauen Sie über Zonen hinweg. Beweisen Sie die Kapazität an den überlebenden Standorten. Holen Sie vertrauliche Nachweise über physische und Routing-Diversität ein. Halten Sie eine getestete Wiederherstellungsumgebung außerhalb der Region bereit.

Dann wird das Souveränitätsversprechen zu einer operativen Fähigkeit, nicht zu einem Abzeichen, das an die Racks eines anderen geheftet ist.