asten-cloud-bretagne ASTEN CLOUD SAS verkauft eine gehostete Kapazität, die immer noch von Racks, Transit und Wartungsfenstern abhängt

Zusammenfassung

• Asten Cloud ist ein aktives französisches Cloud- und Hosting-Unternehmen in den öffentlichen Registern: Der französische Unternehmenssuchdienst führt ASTEN CLOUD als aktives Unternehmen in Gouesnou in der Verwaltung von IT-Einrichtungen, die Website von Asten beschreibt zwei Rechenzentren in der Region Brest, und die RIPE-Register zeigen ASTEN CLOUD SAS als Inhaber von autonomen Systemressourcen.
• Die stärksten physischen Belege sind aus erster Hand, aber konkret. Asten gibt an, dass seine private Cloud auf zwei französischen Rechenzentren, 300 Quadratmetern Reinraum-Hosting-Fläche, über 1.000 gehosteten physischen und virtuellen Servern und einem Housing-Angebot mit 48 Racks, redundanter Strom- und Kühlversorgung, freier Telekommunikationsanbieterwahl, Zutrittskontrolle und 24/7-Standortzugang basiert.
• Die Routing-Situation ist gemischt und nicht schwach. AS199727, das unter ASTEN CLOUD SAS gehalten wird, ist derzeit über RIPEstat mit sieben IPv4-/24- und einem IPv6-/31-Präfix sichtbar, während AS206308, die ASN mit dem Namen „asten-cloud-bretagne“, registriert, aber nicht angekündigt ist. Das öffentliche Netzwerksignal unterstützt daher den aktuellen Betrieb von Asten, aber nicht die einfache Behauptung, dass die ASN mit dem Namen Bretagne selbst Kundenverkehr transportiert.
• Backup und Wiederherstellung sind hier mehr als eine Marketing-Fußnote. Asten beschreibt ein auf Commvault basierendes Backup in zwei französischen Rechenzentren, lange Aufbewahrungsfristen, optionale Bandauslagerung über einen Roboter in einem Rechenzentrum, regelmäßige Wiederherstellungstests, eine Business-Impact-Analyse und einen formellen Disaster-Recovery-Plan-Service. Diese Behauptungen reduzieren einige Kundenrisiken, aber sie veröffentlichen keine RTOs, RPOs, Failover-Testergebnisse oder die verbleibende Kapazität nach einem Rechenzentrumsausfall.
• Das Evidenzniveau ist mittel. Die rechtliche Registrierung, Zertifizierungsseiten, das Live-Routing und die detaillierten Serviceseiten machen das Unternehmen materiell überprüfbar, aber das öffentliche Register gibt immer noch keine genauen Standortadressen, die tatsächliche Rackbelegung, die Trennung der Transportwege, die Generatorlaufzeit, die Kundenverteilung, die Tiefe des Supportpersonals oder die gemessenen Wiederherstellungsergebnisse preis.

Das Unternehmen ist sichtbar, aber die Anlage bleibt lokal

Es ist sinnvoll, asten-cloud-bretagne ASTEN CLOUD SAS nicht als Hyperscale-Plattform mit abstrakten Regionen zu betrachten. Es handelt sich um einen regionalen französischen Hosting-Betreiber, dessen öffentliches Wertversprechen genau darin besteht, dass die Kundensysteme in der Nähe der Bretagne, des französischen Rechts und der Supportbüros von Asten bleiben. Derfranzösische Unternehmenssuchdienstidentifiziert ASTEN CLOUD unter der SIREN-Nummer 323789990 mit einem aktiven Hauptsitz in Gouesnou und einem Tätigkeitscode für die Verwaltung von IT-Einrichtungen. Das Registersignal ist wichtig, da eine Cloud-Serviceseite ohne rechtliche Verankerung kaum mehr als ein kommerzielles Schaufenster sein kann. Hier verfügt das Unternehmen über eine registrierte operative Präsenz, die mit der bretonischen Cloud-Geschichte übereinstimmt.

DieCloud-Seitevon Asten ist für ein Cloud-Angebot ungewöhnlich physisch. Sie gibt an, dass Asten Cloud die Daten auf seiner eigenen Infrastruktur in Frankreich, speziell in der Bretagne, hostet und beschreibt zwei souveräne Rechenzentren in der Region Brest, 300 Quadratmeter Reinraum-Hosting-Fläche und über 1.000 gehostete physische und virtuelle Server. Sie präsentiert den Dienst auch als zertifizierte private Cloud und nicht als Wiederverkaufsverpackung um eine ausländische Public Cloud. Dies ist kein Beweis für jede Kunden-Workload, aber es ist eine Behauptung konkreter Vermögenswerte: Räume, Racks, Server und Betriebspersonal müssen hinter dem Servicekatalog existieren.

DieUnternehmensgeschichte-Seitehilft zu erklären, wie dieser Fußabdruck gewachsen ist. Asten gibt an, dass die Gruppe 1995 gegründet wurde, 2008 STTG kaufte, Eigentümerin ihres ersten Rechenzentrums wurde, 2013 das WhiteBox-Shelter-Rechenzentrum errichtete, 2018 ein neues Rechenzentrum in Brest für Colocation kaufte, 2019 die ISO-27001-Zertifizierung erlangte, 2020 die HDS-Zertifizierung erhielt und im selben Jahr Telekommunikationsbetreiber wurde. Es nennt auch Größenindikatoren: zwei Rechenzentren in der Bretagne, etwa 140 Experten, 350 Kunden und 16,5 Millionen Euro Umsatz. Diese Zahlen sind Erstanbieter-Aussagen und sollten daher nicht als geprüfte Kapazitätsauslastung behandelt werden, aber sie machen das Unternehmen weit weniger undurchsichtig als eine Briefkasteneintragung.

Das Servicegebiet ist in der Geschäftssprache national und in der Infrastrukturlogik regional. Asten gibt an, dass seine Expertise in ganz Frankreich und darüber hinaus eingesetzt wird, aber sein Hosting-Argument ist in den französischen Rechenzentren im Département Finistère verankert. DieHosting-Seitebeschreibt zwei französische Rechenzentren mit Standort im Finistère und präsentiert das Angebot als souveränes Hosting für Daten, die unter französischer und europäischer Rechtshoheit bleiben müssen. Für einen Kunden in der Bretagne kann ein naher Betreiber den Eskalationsweg verkürzen und Vor-Ort-Besuche plausibler machen. Für einen Kunden außerhalb der Region spielt die Lokalität immer noch eine Rolle, aber die Abhängigkeit verlagert sich auf Fernverbindungen, Remote-Support und die Ausfallsicherheit der Transit- und Kundenzugangswege von Asten.

Diese Geographie ist die erste operative Einschränkung. Asten kann Cloud-Kapazität als Dienstleistung verkaufen, aber seine Bereitstellung ist an eine endliche regionale Vermögensbasis gebunden. Zwei Rechenzentren können ein signifikantes Resilienzdesign darstellen, wenn sie physisch, elektrisch und betrieblich unabhängig sind. Sie können aber auch ein Cluster mit gemeinsamem Schicksal sein, wenn beide Standorte vom gleichen Transportkorridor, dem gleichen Wartungsteam, der gleichen Kraftstoffversorgung, dem gleichen Änderungszeitplan oder dem gleichen Lieferantenbestand abhängen.

Die öffentlichen Seiten belegen, dass Asten zwei Standorte vermarktet; sie veröffentlichen keinen standortübergreifenden Fehlerbaum.

Die Racks machen die Cloud-Behauptung zu einem Kapazitätstest

Die spezifischste öffentliche Kapazitätsseite ist dasHousing-Angebotvon Asten. Sie besagt, dass Kunden physische Server in gesicherten Rechenzentren unterbringen können, zwischen einem Drittel Rack und vollen Racks wählen können, Racks mit den Maßen 800 mal 1200 Millimeter mit jeweils 48 HE nutzen und je nach Option eine Stromversorgung mit 1 kVA oder 3 kVA inbegriffen ist. Sie gibt außerdem an, dass das Rechenzentrum über 48 Racks, eine gesicherte und redundante Stromversorgung von 175 kVA, redundante Kühlung, biometrische Zutrittskontrolle, Zahlencodes, Schlösser, Branderkennung und -löschung, 24/7-Überwachung und 24/7-Kundenzugang verfügt. Diese Details sind genau die Art von Fakten, die eine „gehostete Kapazität“ in etwas Überprüfbares verwandeln.

Sie zeigen auch, warum installierte Kapazität und nutzbare Kapazität unterschiedlich sind. Achtundvierzig Racks sind ein Maß für die Stellfläche. Einhundertfünfundsiebzig kVA sind ein Maß für die elektrische Kapazität. Dreihundert Quadratmeter sind ein Raummaß. Über 1.000 gehostete Server sind eine Bestands- oder Service-Skalen-Aussage. Keine dieser Zahlen allein sagt dem Kunden, wie viel Reservekapazität heute noch vorhanden ist, wie viel der Kraftwerksleistung gebunden ist, wie viel Kühlmarge reserviert ist oder was passiert, wenn ein Standort ausfällt und die überlebende Kapazität die geschützten Workloads aufnehmen muss.

Ein Rack kann vorhanden, aber voll sein. Eine USV kann installiert, aber durch die Batterieautonomie eingeschränkt sein. Ein zweites Rechenzentrum kann existieren, aber nicht über genügend kalte Rechenkapazität verfügen, um alle Kunden-Workloads gleichzeitig zu übernehmen.

Die Hosting-Seite gibt an, dass das Rechenzentrum für verschiedene Telekommunikationsbetreiber offen ist. Das ist eine gute Formulierung für die Kundenwahl, denn ein einziger Carrier-Edge kann zum versteckten Single-Point-of-Failure in einem ansonsten redundanten Hosting-Design werden. Doch „offen für verschiedene Betreiber“ ist nicht dasselbe, wie die aktiven Carrier, diverse Gebäudeeinführungen, getrennte Leitungen, unabhängige Übergaberäume oder getestetes Failover zu benennen.

Die zentrale missionskritische physische Abhängigkeit liegt genau hier: Ein Kunde kann Server an Asten auslagern und bleibt dennoch der Rackverfügbarkeit, der Lieferzeit für Querverbindungen, der Carrier-Wartung, dem Router-Ausfall und dem praktischen Reparaturfenster für einen ausgefallenen Port ausgesetzt.

DasHosting-Portfoliovon Asten umfasst Housing, Shared Hosting, HDS-Hosting, Application Hosting und Container Hosting. Diese Vielfalt deutet auf mehr als ein Betriebsmodell hin. Ein Housing-Kunde kann eigene Server besitzen und Asten mit der Bereitstellung von Platz, Strom, Kühlung, Sicherheit und Netzzugang beauftragen. Ein Shared-Hosting-Kunde kann virtuelle Server auf der Infrastruktur von Asten nutzen. Ein Softwareanbieter kann für Hosting und Managed Operations auf Asten angewiesen sein. Ein Container-Kunde kümmert sich möglicherweise mehr um die Plattformorchestrierung und die Verfügbarkeit der Registry als um das physische Rack-Layout. Derselbe Ausfall eines Rechenzentrums oder Carriers wirkt sich auf jeden Kunden unterschiedlich aus, weil die Verantwortung auf jeder Ebene anders verteilt ist.

Die zentrale wirtschaftliche Spannung besteht darin, dass Asten die Erleichterung verkauft, keinen eigenen Serverraum bauen zu müssen, aber den gemeinsamen Raum finanzieren muss, der viele Kundenräume ersetzt. Das ist ein klassischer Hosting-Wirtschaftskompromiss: Kunden vermeiden Investitionsausgaben, Compliance-Aufwand und lokale Strom-/Kühlungsprobleme, während der Anbieter genügend Nachfrage bündelt, um gesicherte Räume, besetztes Betriebspersonal und redundante Systeme zu betreiben. Der Anbieter muss dann vermeiden, knappe Ressourcen zu überbuchen.

Die öffentlichen Belege ermöglichen einem Käufer präzise Fragen zu stellen, beantworten sie aber nicht vollständig: die aktuelle Rack-Auslastung, die gebundene versus Spitzenleistung, die Kühlungsredundanz bei extremen Außenbedingungen, der Ersatzteilbestand für Server, die Vorlaufzeiten für Ersatzhardware und die Kosten für die Vorhaltung leerer Wiederherstellungskapazität werden nicht veröffentlicht.

Die Zertifizierung schränkt das Versprechen ein, beseitigt aber nicht die Maschinerie

Asten stützt sich stark auf Zertifizierungen, und die öffentlichen Seiten machen den Geltungsbereich klarer als ein einfaches Logo. DieZertifizierungsseitegibt an, dass Asten Cloud für Hosting, Managed Services und Benutzer-Support nach ISO 27001 zertifiziert ist. Sie beschreibt auch die HDS-Zertifizierung für das Hosting physischer Infrastruktur und Managed-Hosting-Aktivitäten, einschließlich der sechs HDS-Tätigkeitsbereiche, die physische Standorte, Hardware-Infrastruktur, virtuelle Infrastruktur, Anwendungsplattformen, Administration/Betrieb und ausgelagerte Backups abdecken. DieHDS-Hosting-Seitewiederholt das Rahmenwerk der sechs Bereiche und gibt an, dass der Dienst für Kunden und Softwareanbieter im Gesundheits- und Sozialwesen bestimmt ist.

Dies ist wichtig, weil HDS nicht nur ein Sicherheitsslogan ist. Es bindet die Hosting-Behauptung an sensible Workloads, bei denen Standort, Zugriffskontrolle, Nachvollziehbarkeit, Verwaltung und Backup zählen. Die HDS-Seite von Asten gibt an, dass ihr Hosting von Gesundheitsdaten die Übermittlung personenbezogener Gesundheitsdaten außerhalb des Europäischen Wirtschaftsraums vermeidet.

In Kundenbegriffen ist dies ein Lokalitätsversprechen, das dem Anlagenbetrieb überlagert ist: Die Daten müssen sich in französischen Rechenzentren unter europäischem Rechtsschutz befinden, durch zertifizierte Prozesse verwaltet und über kontrollierte Dienste gesichert werden. Wenn eine dieser Schichten abweicht, ändert sich der Wert des Dienstes.

Die Zertifizierung macht die Kapazität jedoch weder unendlich noch Ausfälle unmöglich. ISO 27001 weist auf ein Informationssicherheits-Managementsystem hin. HDS weist auf die Konformität für das Hosting von Gesundheitsdaten hin. Keine Seite veröffentlicht die Wiederherstellungszeit pro Kunde, die Anzahl der Bereitschaftsingenieure, die durchschnittliche Zeit zum Austausch eines ausgefallenen Storage-Arrays, den Wartungsplan für gemeinsam genutzte Switches oder die tatsächliche geografische Entfernung und Trennung der Transportwege zwischen den beiden Rechenzentren.

Die Zertifizierung verringert das Risiko von Improvisation; sie beseitigt nicht die physische Abhängigkeit von Strom, Kühlung, Hardware, Personal und Leitungen.

Das Angebot für den öffentlichen Sektor fügt ein weiteres Nachfragesignal hinzu. Die Seite von Asten fürGebietskörperschaften und öffentliche Einrichtungengibt an, dass die Gruppe für das regionale Los Bretagne des Cloud- und Hosting-Rahmenvertrags CANUT ausgewählt wurde. Sie präsentiert Colocation, Shared Hosting, Managed Hosting, Backup, Konnektivität und Telefonie für öffentliche Einrichtungen. Dies zählt, weil Kunden des öffentlichen Sektors oft formelle Beschaffungen, Kontinuitätsanforderungen und Präferenzen für Datensouveränität mitbringen. Es erhöht auch die Kosten eines schwachen Wiederherstellungsdesigns: Ein Ausfall könnte eine Kommune, eine Schule, eine öffentliche Einrichtung oder einen lokalen Dienstleister betreffen, nicht nur eine private Testumgebung.

Die richtige Schlussfolgerung ist daher weder Zynismus noch Leichtgläubigkeit. Die Zertifizierungen und die Positionierung von Asten im öffentlichen Sektor sind signifikante und quellenbasierte Signale einer ernsthaften Betriebshaltung. Sie rechtfertigen ein höheres Vertrauensniveau, als es bei einem Wiederverkäufer mit einer Ein-Seiten-Website angemessen wäre. Sie ersetzen jedoch nicht die Due Diligence des Kunden.

Der Käufer benötigt weiterhin die Geltungsbereichserklärung, die Gültigkeitsdaten der Zertifikate, ausgeschlossene Dienste, die Liste der Unterauftragnehmer, den Backup-Standort, das Verfahren zur Meldung von Vorfällen und den Nachweis, dass die vertraglich vereinbarte Workload im zertifizierten Bereich liegt.

Die Routing-Beweise trennen den Betrieb von Asten von der Bretagne-ASN

Die Netzwerkregistrierung weist eine merkwürdige, aber nützliche Unterscheidung auf. Die für den Auftrag benannte ASN, AS206308, ist im RIPE alsasten-cloud-bretagne ASTEN CLOUD SASregistriert. Die Inhaberinformationen verbinden sie mit ASTEN CLOUD SAS und Adressen in Gouesnou und der Region Brest. Doch dieRIPEstat-Übersicht für AS206308kennzeichnet sie als nicht angekündigt, und dieRouting-Status-Ansichtzeigt zum Recherchezeitpunkt keine sichtbaren IPv4- oder IPv6-Präfixe und keine beobachteten Nachbarn. Dies bedeutet nicht, dass Asten Cloud offline ist. Es bedeutet, dass die ASN mit dem Namen Bretagne in den verfügbaren Routing-Beweisen nicht der öffentliche Routenträger ist.

Die Live-Routing-Beweise verweisen stattdessen auf AS199727. RIPE RDAP listetAS199727als „asten-cloud-idf“ unter ASTEN CLOUD SAS, und dieRIPEstat-AS-Übersichtkennzeichnet sie als angekündigt. IhrRouting-Status-Ergebniszeigt eine vollständige IPv4-Sichtbarkeit über die RIPE-RIS-Peers und eine substanzielle IPv6-Sichtbarkeit. DasErgebnis der angekündigten Präfixezeigt sieben IPv4-/24- und ein IPv6-/31-Präfix, die im aktuellen Beobachtungszeitfenster sichtbar sind, während dieASN-Nachbardatenzwei beobachtete Nachbarn zeigen: AS174 und AS12645.

Diese beiden Fakten müssen zusammen gehalten werden. Einerseits verfügt Asten über eine live geroutete Infrastruktur. Andererseits ist die ASN, deren Name „bretagne“ enthält, stumm. Ein einfacher Artikel könnte diesen Unterschied verwischen und sagen: „Asten Cloud hat eine ASN.“ Eine bessere Infrastruktur-Lesart fragt, warum die benannte regionale ASN registriert, aber nicht sichtbar ist, ob sie für ein Design reserviert ist, das derzeit nicht genutzt wird, ob der Kundenverkehr hinter AS199727 liegt und ob das Zwei-ASN-Setup Standort-, Legacy-, Produkt- oder Traffic-Engineering-Entscheidungen widerspiegelt.

Die öffentlichen Routensammler beantworten diese Frage nicht.

Die Präfixnamen deuten ebenfalls auf Servicefunktionen hin, ohne die Kundenplatzierung zu beweisen. RIPE RDAP identifiziert185.189.172.0/24als „HEBERGEMENT“,185.189.173.0/24als „HEBERGEMENT_SEC2“,185.189.174.0/24als „HEBERGEMENT_SEC“,185.37.43.0/24als „HEBEGEMENT-SEC“,185.37.41.0/24als „K8S“ und185.37.42.0/24als „HORS-VDOM-INTERNET“. Diese Labels sind nützliche öffentliche Hinweise: Hosting, sicheres Hosting und Kubernetes-ähnliche Benennungen erscheinen im von Asten kontrollierten Adressraum. Sie geben keinen Aufschluss über den Datenraum, den Kundenmieter, das VLAN, die Firewall-Zone oder die Ausfallsicherheitsebene hinter einer bestimmten IP.

Das Risiko der Routing-Abhängigkeit besteht also nicht darin, ob Asten im Internet sichtbar ist. Das ist es. Das Risiko besteht darin, ob die Kunden den tatsächlichen Carrier, den Pfad und die Failover-Anordnung kennen, die für ihre Workload verwendet werden. Zwei beobachtete Routing-Nachbarn sind besser als einer, aber BGP-Nachbar-Vielfalt ist nicht dasselbe wie Glasfaser-Pfad-Vielfalt. Zwei Sessions können sich dennoch ein Kabelrohr, einen Gebäudeeingang, einen Router, ein Wartungsfenster oder eine geschäftliche Abhängigkeit teilen.

Ein hochverfügbarer Kunde sollte nach den Carrier-Namen, den Übergabeorten, der Pfaddiversität, der Failover-Richtlinie, den Wartungsvorankündigungsfristen, dem DDoS-Management, der RPKI/IRR-Haltung und dem Nachweis einer kürzlich durchgeführten Failover-Übung fragen.

Backup reduziert das Datenverlustrisiko, aber die Wiederherstellung hat immer eine Uhr

DieBackup- und Disaster-Recovery-Seitevon Asten ist eine der stärksten Seiten im Beweismaterial, denn sie benennt sowohl den Mechanismus als auch das Ausfalldenken. Sie gibt an, dass Asten Backup Commvault nutzt, Backups in zwei französischen Rechenzentren speichert, eine anpassbare lange Aufbewahrung bietet, optional ein Band-Backup über einen Roboter in einem Rechenzentrum hinzufügen kann und entkoppelte oder isolierte Backup-Konzepte verwendet, um Cyberangriffen zu widerstehen. Sie gibt auch an, dass das Angebot regelmäßige Wiederherstellungstests in einer isolierten Umgebung, Disaster-Recovery-Plan-Services, eine Business-Impact-Analyse und einen schriftlichen, von Sicherheitsexpertise geleiteten Wiederherstellungsplan umfasst.

Dies ist ein guter Ausgangspunkt für die Redundanzaufgabe. Backup ist nicht einfach ein weiteres Storage-Volume neben der Produktion; Asten beschreibt mehrere Medien, eine externe Logik, Wiederherstellungstests und Wiederherstellungsplanung. Die optionale Bandschicht ist besonders relevant für Ransomware, da eine Online-Replik Korruption, Verschlüsselung oder Löschung getreu replizieren kann. Eine lange Aufbewahrung hilft, wenn die Kompromittierung Wochen oder Monate nach dem ersten Eindringen entdeckt wird. Wiederherstellungstests zählen, weil ein Backup, das nicht wiederhergestellt werden kann, keine Wiederherstellungsfähigkeit darstellt.

Die verbleibende Lücke ist die Service-Uhr. Die Seite veröffentlicht keine standardmäßigen RPO- oder RTO-Ziele für jede Workload-Klasse. Sie gibt nicht an, wie viele gleichzeitige Kundenwiederherstellungen während eines regionalen Vorfalls durchgeführt werden können, wie der Backup-Verkehr gedrosselt wird, ob die Backup-Repositories denselben Storage-Anbieter wie die Produktion nutzen oder ob der Bandroboter alle Kunden oder nur diejenigen schützt, die eine Option kaufen. Sie erklärt auch nicht, wie eine Wiederherstellung priorisiert wird, wenn viele Kunden während desselben Ausfalls anrufen.

Ein Kunde könnte glauben, dass „Backup in zwei Rechenzentren“ schnelle Kontinuität bedeutet; das tatsächliche Ergebnis hängt vom Vertragsumfang, der Automatisierung, dem Netzwerkdurchsatz, der Reinraumkapazität, der Personalverfügbarkeit und den Anwendungsabhängigkeiten ab.

Der Unterschied zwischen Datenschutz und Servicekontinuität ist leicht zu übersehen. Wenn ein physischer Server ausfällt, kann ein Backup die Daten wiederherstellen, aber nicht die exakte Rechenumgebung, den Lizenzstatus, die Firewall-Regel, die DNS-Einstellung oder die Anwendungsabhängigkeit. Wenn ein Rechenzentrum ausfällt, kann ein Backup an einem zweiten Standort die Daten bewahren, erfordert aber dennoch Compute, Storage, IP-Erreichbarkeit und eine Anwendungssequenz, bevor die Benutzer zurückkehren.

Wenn ein Cyberangriff die Identitätssysteme kompromittiert, können die Backup-Daten vorhanden sein, aber der privilegierte Zugriff und die Vertrauensentscheidungen werden zum Engpass. Ein resilienter Wiederherstellungsplan muss Personen und Abhängigkeiten choreografieren, nicht nur Blöcke kopieren.

Der Servicekatalog von Asten erkennt dies teilweise an, indem er Backup mit Managed Services und Disaster-Recovery-Planung verknüpft. Die Aufgabe des Käufers zur Überprüfung besteht darin, den Katalog in Belege umzuwandeln: Datum des letzten erfolgreichen Wiederherstellungstests, Liste der getesteten Workloads, gemessene Wiederherstellungsdauer, Abhängigkeitskarte, Wiederherstellung der Authentifizierung, Netzwerk-Failover-Schritte, Validierung nach der Wiederherstellung und einen benannten Entscheider für die Notfallerklärung. Die öffentliche Seite unterstützt die Behauptung, dass die Wiederherstellung Teil des Angebots von Asten ist.

Sie erlaubt es Außenstehenden nicht, zu berechnen, wie schnell ein bestimmter Kunde zurückkehrt.

Die Support-Arbeit ist ebenfalls eine Kapazitätsressource

Cloud-Ausfälle werden oft als technische Ereignisse beschrieben, aber die Reparatur wird von Menschen durchgeführt. DieManaged-Services-Seitevon Asten gibt an, dass ihr Angebot die Kundeninfrastruktur vor Ort, im Rechenzentrum von Asten oder auf gemeinsam genutzten Plattformen abdecken kann. Sie beschreibt Überwachungssysteme, kontinuierliche Überwachung, Echtzeitwarnungen, die Behebung von Warnungen, Sicherheitsupdates und Notfall-Patches für kritische Schwachstellen. Sie gibt auch an, dass der Service Vor-Ort-Support mit ausgelagerten Ressourcen kombinieren kann, die auf den Servern von Asten gehostet werden. Dies ist die operative Schicht, die einen Serverraum in einen Managed Service verwandelt.

DieSupportvertragsseitefügt ein banaleres, aber wichtiges Detail hinzu: Anfragen außerhalb des Managed-Services-Umfangs können über einen punktbasierten Supportvertrag bearbeitet werden, bei dem Level-1-Techniker an Level-2- und Level-3-Ingenieure und -Experten eskalieren. Dies zählt im Fehlerfall, denn nicht alle Ausfälle beginnen im Kern von Asten. Eine Kundenanwendungsänderung, ein Zertifikatsablauf, eine Firewall-Anforderung, eine kleine Konfigurationsaufgabe oder ein Hardware-Eingriff können an der Grenze zwischen eingeschlossenen Operationen und kostenpflichtigem Support liegen. Wenn diese Grenze während eines Ausfalls unklar ist, verlangsamt sich die Reparatur.

Die Support-Arbeit hat dasselbe Auslastungsproblem wie die Racks. Die Unternehmensgeschichte von Asten gibt an, dass die Gruppe etwa 140 Experten umfasst, aber das öffentliche Register gibt keine Aufschlüsselung nach Cloud-Betrieb, Sicherheit, Außendienst, Helpdesk, Anwendungsspezialisten, Managern oder administrativen Funktionen. Ein normaler Tag mag ausreichend Personal für Warnungen, geplante Änderungen und Kundentickets haben. Ein gleichzeitiger Vorfall bei Hosting, Backup, Netzwerk und Kundensystemen kann Spezialisten schneller verbrauchen, als das Rechenzentrum Strom verbraucht.

Kunden sollten Support daher als vertragliche Ressource behandeln. Die Frage ist nicht nur „Ist Support verfügbar?“, sondern ob der Vertrag Reaktionszeiten, Eskalationsauslöser, Schweregrade, Bereitschaftsabdeckung, Änderungssperren, Notfallwartungsfenster, Kundenverantwortlichkeiten und das Recht definiert, nach einem Vorfall Nachweise zu verlangen. Die öffentlichen Seiten von Asten unterstützen die Erwartung von Managed Operations und mehrstufigem Support. Sie veröffentlichen nicht die genaue Warteschlangentiefe oder den Personalplan hinter dieser Erwartung.

Dies ist besonders wichtig für öffentliche Einrichtungen und gesundheitsbezogene Workloads. Die HDS-Seite von Asten beschreibt eine 24/7-Überwachung und schnelle Reaktion für Gesundheitsdatenumgebungen. Eine Kommune oder ein Softwareanbieter im Gesundheitswesen benötigt möglicherweise mehr als eine Ticketantwort; er benötigt möglicherweise eine dokumentierte Incident Bridge, eine Wiederherstellungsprioritätsreihenfolge, Unterstützung bei der Benachrichtigung über Datenschutzverletzungen und den Nachweis, dass die Daten während der Notfallarbeit im genehmigten Hosting-Bereich bleiben.

Die öffentliche Marketingsprache geht in diese Richtung, aber nur der Vertrag und die Betriebshandbücher würden zeigen, ob es betrieblich durchsetzbar ist.

Souveränität ist eine operative Grenze, kein dekoratives Etikett

Die stärkste Marktbehauptung von Asten ist die Lokalität. Die Haupt-Cloud-Seite gibt an, dass die Daten auf der eigenen Infrastruktur von Asten in Frankreich, in der Bretagne, ohne US-Cloud und ohne Untervergabe in dieser Cloud-Behauptung gehostet werden. Die Hosting-Seite gibt an, dass die Cloud souverän ist und unter französischem und europäischem Recht steht. Die HDS-Seite gibt an, dass Gesundheitsdaten nicht außerhalb des Europäischen Wirtschaftsraums übermittelt werden. Die Seite für den öffentlichen Sektor verkauft dieselbe Logik an bretonische öffentliche Einrichtungen.

Diese Behauptungen machen Datensouveränität und -lokalität zu einem der kontrollrelevanten Themen des Artikels.

Aber Souveränität ist nicht dasselbe wie Einfachheit. Eine lokale Cloud hat immer noch Hardwarelieferanten, Softwareanbieter, Telekommunikationsbetreiber, Backup-Technologien, Sicherheitsprodukte und Kundenzugangsnetze. Die Managed-Services-Seite von Asten gibt an, dass sie für SecNumCloud-Anforderungen auf OUTSCALE, eine Marke von Dassault Systèmes, in einem hybriden souveränen Ansatz zurückgreift. Dies kann ein kluges Design für Kunden sein, die eine qualifizierte souveräne Cloud-Option benötigen.

Es bedeutet aber auch, dass ein Käufer fragen muss, welche Workloads in den eigenen bretonischen Rechenzentren von Asten laufen, welche in einer OUTSCALE-Umgebung, welche Daten zwischen ihnen fließen und welche vertraglichen Kontrollen für jeden Punkt gelten.

Diese Unterscheidung ist keine Kritik; sie ist die praktische Definition von Lokalität. Kauft ein Kunde gewöhnliches Hosting, kann der erwartete Vermögenswert die Infrastruktur von Asten in der Region Brest sein. Kauft ein Kunde einen hybriden souveränen Dienst, kann die Vermögensgrenze die von Asten verwalteten Kundenstandorte, die Rechenzentren von Asten und die OUTSCALE-Ressourcen umfassen. Kauft ein Kunde Backup für Microsoft-365-Daten, kann der Produktionsdienst in der Microsoft-Umgebung verbleiben, während die Backups in den französischen Rechenzentren von Asten landen.

Das Wort „souverän“ kann erst bewertet werden, wenn der tatsächliche Servicepfad nachgezeichnet ist.

Gleiches gilt für die rechtliche Gerichtsbarkeit. In Frankreich nach französischen und europäischen Regeln gespeicherte Daten sind ein bedeutender Schutz, aber der operative Zugriff hängt immer noch von Administratoren, Support-Anbietern, Überwachungssystemen, der Verwaltung von Verschlüsselungsschlüsseln und Notfallverfahren ab. Die HDS- und ISO-Seiten von Asten unterstützen die Vorstellung, dass diese Prozesse in formalen Sicherheitsrahmen verwaltet werden.

Sie zeigen nicht, welche Protokolle geführt werden, wo Schlüssel aufbewahrt werden, wie Kundenadministratoren authentifiziert werden oder wie grenzüberschreitender Lieferantensupport eingeschränkt wird.

Eine gute Kundenprüfung sollte Souveränität daher als eine Reihe praktischer Beweispunkte und nicht als Slogan behandeln. Wo werden die Produktionsdaten gespeichert? Wo werden die Backups gespeichert? Wo werden die Überwachungsprotokolle gespeichert? Wer kann auf jede Schicht zugreifen? Werden die Verschlüsselungsschlüssel vom Kunden, vom Anbieter oder gemeinsam kontrolliert? Was passiert, wenn Hardware zurückgegeben, repariert oder zerstört wird? Welche Unterauftragnehmer können auf Daten oder Metadaten zugreifen?

Die öffentlichen Beweise machen Asten zu einem glaubwürdigen lokalen Anbieter; der Vertrag muss noch beweisen, dass die tatsächliche Kunden-Workload dem lokalen Pfad folgt.

Die Fehlerpfade konvergieren in fünf praktischen Engpässen

Der erste Fehlerpfad ist ein Rack- oder Hardwarebestandsproblem. Housingkunden können die Ausrüstung besitzen, aber Asten stellt weiterhin Raum, Rack, Strom, Kühlung, Zugang und möglicherweise praktische Eingriffe bereit. Ein Shared-Hosting-Kunde ist direkter vom Serverbestand und den Ersatzteilen von Asten abhängig. Die Zahl von 48 Racks auf der Housing-Seite gibt eine sichtbare Kapazitätsgrenze an. Ein Hardwareausfall auf einem Kundenserver ist eng; ein Ausfall von Kühlung, Stromverteilung, Storage-Array oder gemeinsam genutztem Switch kann sich schnell ausweiten.

Die Wiederherstellung hängt von Ersatzteilen, Lieferantensupport, der Verfügbarkeit von Remote-Hilfe und der Fähigkeit des Kunden ab, Änderungen zu genehmigen.

Der zweite Fehlerpfad ist die Stromversorgung. Die Housing-Seite gibt an, dass das Rechenzentrum über eine gesicherte, USV-gestützte und redundante Stromversorgung von 175 kVA mit Generatoren im Hintergrund verfügt. Diese Formulierung unterstützt eine Behauptung der elektrischen Ausfallsicherheit auf Anlagenebene. Sie veröffentlicht nicht die Batterieautonomie, die Kraftstoffautonomie des Generators, den Wartungsplan, die Lasttestergebnisse, die Topologie der Stromkette oder die verbleibende Marge, wenn die Racks beladen sind.

Wenn Asten sowohl Produktions- als auch Wiederherstellungs-Hosting in derselben Stromhülle verkauft, wird die verfügbare Marge nach einem Standortausfall zu einer wirtschaftlichen und technischen Frage.

Der dritte Fehlerpfad ist ein Carrier- oder Routing-Ausfall. RIPEstat sieht AS199727 als aktiv und AS206308 als inaktiv. Wenn der Kundenverkehr auf AS199727 beruht, zählen seine Upstream-Diversität und physischen Pfade. Wenn ein Produkt eine Carrier-Übergabe nutzt, die im öffentlichen BGP nicht sichtbar ist, muss die Due Diligence des Kunden über die ASN-Seiten hinausgehen. Ein sichtbares Präfix kann aufgrund eines Router-Ausfalls, eines Routing-Richtlinienfehlers, einer Wartung, eines DDoS-Abwehrproblems, eines Carrier-Ausfalls oder eines geschäftlichen Streits verschwinden.

Ein Cloudkunde spürt all dies als Anwendungsausfall, selbst wenn jeder Server gesund bleibt.

Der vierte Fehlerpfad ist die Support-Eskalation. Asten beschreibt Überwachung, Warnungsbehebung, Sicherheitspatches und Support-Level. Während eines größeren Ereignisses kann der Engpass die Anzahl der Spezialisten sein, die sicher Firewalls, Hypervisoren, Storage, Backups, DNS, Identität und Kundenanwendungen anfassen können. Wenn Kunden des öffentlichen Sektors oder des Gesundheitswesens Priorität erhalten, muss die Prioritätsreihenfolge explizit sein.

Wenn ein punktbasierter Supportvertrag Arbeiten außerhalb des Umfangs abdeckt, sollte die Notfallrichtlinie angeben, ob die Punktezählung während Vorfällen pausiert oder wie gewohnt weiterläuft.

Der fünfte Fehlerpfad ist Migration und Portabilität. Das Wertversprechen von Asten verlangt von den Kunden, Daten und Systeme in seine Rechenzentren oder verwalteten Umgebungen zu verlagern. Ein späterer Ausstieg kann den Export von virtuellen Maschinen, Datenbanken, Backups, Firewall-Regeln, DNS-Zonen, Anwendungsgeheimnissen, Überwachungsverlauf und Zugangsdokumentation erfordern. Die öffentlichen Seiten von Asten betonen Schutz, Kontinuität und französische Lokalisation. Sie veröffentlichen keine Standard-Exportformate, Massenexportgebühren, Migrationsfristen oder Unterstützung für die Notfallrückführung.

Ein Kunde sollte diese Fragen vor einem Anbietervertragsausfall klären, nicht während eines solchen.

Wer ist betroffen, wenn dieses System ausfällt

Die betroffenen Parteien sind breiter, als das Wort „Kunde“ impliziert. Ein Housingkunde kann ein lokales Unternehmen sein, das seine eigenen Server in den Racks von Asten platziert hat, um die Verwaltung eines privaten Raums zu vermeiden. Ein Shared-Hosting-Kunde kann ein KMU sein, dessen Buchhaltungs-, Bestell-, Identitäts- oder Kollaborationssysteme auf von Asten verwalteten Servern laufen. Ein Softwareanbieter kann das Hosting von Asten nutzen, um seine eigenen Kunden zu bedienen, wodurch ein Asten-Vorfall zu einem nachgelagerten Anwendungsausfall wird.

Eine öffentliche Einrichtung, die das CANUT-gebundene Angebot nutzt, kann für Bürger- oder Verwaltungsdienste von Asten abhängig sein. Ein Akteur im Gesundheits- oder Sozialwesen, der HDS-Hosting nutzt, kann Verpflichtungen hinsichtlich der Verfügbarkeit und Vertraulichkeit von Patientendaten haben.

Die Auswirkungen unterscheiden sich auch je nach Art des Ausfalls. Ein kurzer Carrier-Flap kann den Webzugang unterbrechen, ohne Daten zu beschädigen. Ein Storage-Ausfall kann Anwendungen online, aber inkonsistent lassen. Ein Backup-Ausfall kann unsichtbar bleiben, bis eine Wiederherstellung erforderlich ist. Ein Support-Rückstau kann einen beherrschbaren Vorfall in einen längeren Ausfall verwandeln. Ein Anlagenwartungsfenster kann für Batch-Systeme akzeptabel, für ein öffentliches Service-Portal, ein Klinikplanungssystem oder einen Einzelhändler während der Stoßzeiten jedoch inakzeptabel sein.

Die beste Kundenposition ist es, die Abhängigkeiten vor dem Abschluss oder der Verlängerung zu kartieren. Welche Dienste sind produktionskritisch? Welche laufen in den Rechenzentren von Asten, auf dem Kundengelände oder in einer hybriden Umgebung? Welche werden in das zweite Rechenzentrum gesichert? Welche haben getestete Wiederherstellungen? Welche benötigen feste IP-Adressen, VPNs, Firewall-Regeln oder DNS-Änderungen während der Wiederherstellung? Welche Benutzer werden Asten direkt anrufen und welche müssen den eigenen Servicedesk des Kunden anrufen?

Diese Fragen erscheinen prozessual, aber sie entscheiden, ob ein Wiederherstellungsversprechen zu einem nutzbaren Plan wird.

Die öffentlichen Beweise von Asten sind detailliert genug, damit Kunden diese Fragen präzise stellen können. Ein vager Cloud-Anbieter kann sich mit Abstraktionen verteidigen. Asten hat genügend Informationen über Racks, Rechenzentren, Backup, HDS-Umfang, Support und Routing veröffentlicht, damit Käufer die Behauptung testen können. Die fehlenden Teile sind keine Anzeichen dafür, dass der Dienst nicht ernsthaft ist; es sind die privaten operativen Details, die ein seriöser Käufer verlangen sollte.

Der Käufertest ist eine Abhängigkeitskarte

Die nützlichste Übung für den Kunden besteht darin, die öffentlichen Behauptungen von Asten in eine Abhängigkeitskarte für das spezifische System umzuwandeln, das verschoben oder geschützt wird. Beginnen Sie mit dem Geschäftsdienst, nicht mit der virtuellen Maschine. Ein Kommunalportal kann von einem Web-Frontend, einem Content-Store, einer Identität, DNS, E-Mail, einem Zahlungskonnektor und einem Helpdesk-Kontakt abhängen.

Eine Gesundheitsanwendung kann von HDS-Hosting, verschlüsselten Backups, Identitätsföderation, Audit-Protokollen, VPN-Zugang und einem Anbieter abhängen, der die Anwendung unterstützen kann, nachdem Asten die Basisplattform wiederhergestellt hat. Ein Einzelhändler kann von einer Point-of-Sale-Datenbank, einem Bestandssystem, Zahlungsterminals, Internetzugang aus den Filialen und nächtlichen Integrationen abhängen. Jeder Dienst hat einen anderen Bruchpunkt.

Für jede Abhängigkeit sollte der Käufer fragen, ob Asten die Schicht besitzt, verwaltet, lediglich hostet oder keine Kontrolle darüber hat. Diese Unterscheidung ist zentral für den Titel des Artikels. Die gehostete Kapazität kann ausfallen, weil die eigene Infrastruktur von Asten ausfällt. Sie kann auch ausfallen, weil der Server eines Kunden außerhalb der Garantie ist, eine Drittanbieteranwendung nicht wiederhergestellt werden kann, ein Glasfaseranbieter ein Reparaturziel verfehlt, eine Domain-Registrierungsstelle eine DNS-Änderung blockiert oder ein Sicherheitsvorfall eine manuelle Vertrauensentscheidung erzwingt.

Asten kann in jedem Fall der richtige Partner sein, aber der Vertrag sollte die Grenze vor dem Vorfall sichtbar machen.

Die Karte sollte auch den normalen Support von der Notfallautorität trennen. Im Routinebetrieb kann ein Kunde eine Firewall-Änderung, eine Storage-Erweiterung oder eine Wiederherstellung über einen Ticketpfad anfordern. Während eines größeren Vorfalls benötigt derselbe Kunde möglicherweise eine benannte Person, die eine Wiederherstellungserklärung genehmigen, ein DNS-Failover autorisieren, reduzierte Leistung akzeptieren, nicht wesentliche Dienste aussetzen und mit Benutzern kommunizieren kann.

Die Support-Seite von Asten zeigt eine strukturierte Support-Aufstellung, aber der Käufer benötigt dennoch Namen, Rollen, Eskalationsfristen und Schweregraddefinitionen. Ein Wiederherstellungsplan ohne Entscheidungsautorität ist nur ein Inventar.

Die Datenlokalität sollte auf derselben Karte erscheinen. Wenn die Produktion in den bretonischen Rechenzentren von Asten läuft, die Backups sich in zwei französischen Rechenzentren befinden und ein SecNumCloud-gebundener Dienst OUTSCALE unter Asten-Management nutzt, dann sind dies drei verschiedene Lokalitätsbehauptungen. Jede verdient eine separate Zeile: wo die Produktion lebt, wo die Backups leben, wo die Protokolle leben, von wo aus sich Administratoren verbinden, wo die Verschlüsselungsschlüssel aufbewahrt werden und wo Notfallkopien erstellt werden können.

Je stärker die Souveränitätsgeschichte von Asten wird, desto wichtiger ist der Nachweis, dass jede Komponente des tatsächlichen Dienstes derselben Richtlinie folgt.

Die Abhängigkeitskarte sollte die Kapazität nach einem Ausfall enthalten, nicht nur die Kapazität an einem normalen Tag. Ein Zwei-Standort-Design kann hervorragend sein, wenn jeder Standort über genügend Rechen-, Storage-, Lizenz- und Netzwerkkapazität verfügt, um die geschützten Dienste zu übernehmen. Es kann schwächer sein, wenn der zweite Standort hauptsächlich für Backup-Storage, einige kritische Workloads oder eine langsamere Wiederherstellung ausgelegt ist.

Die öffentliche Backup-Seite von Asten erwähnt regelmäßige Wiederherstellungstests und ein zweites Rechenzentrum; der Vertrag sollte angeben, ob die Umgebung des Kunden dort betrieben werden soll, wie lange die Umschaltung dauert, wie viel Leistung reserviert ist und welche anderen Kunden um denselben Notfallpool konkurrieren.

Schließlich sollte der Käufer einen Ausstiegspfad verlangen. Dies ist keine feindselige Haltung; es ist Teil der Resilienz. Ein Kunde, der einen Anbieter während eines Geschäftsstreits, eines Strategiewechsels oder eines anhaltenden Ausfalls nicht verlassen kann, hat seine Abhängigkeit nicht reduziert, sondern konzentriert. Für Asten sollte der Ausstiegstest den Export von virtuellen Maschinen, Backup-Export, Datenbank-Dumps, Verschlüsselungsschlüssel, Firewall- und VPN-Konfiguration, Änderungen der öffentlichen IP, DNS-Zonen, Support-Dokumentation und den Nachweis der Löschung nach dem Ausstieg abdecken.

Ein wirklich gut verwalteter Dienst sollte beschreiben können, wie ein Kunde eintritt, einen Vorfall übersteht und geht, ohne die Kontrolle über seine Daten zu verlieren.

Was die Beweislage verbessern würde

Das öffentliche Register unterstützt heute eine mittlere Vertrauensbewertung. Es würde stärker, wenn Asten kundensichere Belege für das Zwei-Standort-Design veröffentlichen oder teilen würde: die nicht-sensible Standorttrennung, Carrier-Diversität, unabhängige Stromversorgungswege, getestete Failover-Ergebnisse, Backup-Wiederherstellungsmetriken, RTO/RPO-Bänder, Notfalleskalationsverfahren und standardmäßige Ausstiegsunterstützung. Es wäre auch hilfreich, die Rolle von AS206308 im Verhältnis zu AS199727 zu erläutern.

Wenn die ASN mit dem Namen Bretagne reserviert, historisch oder nur in privaten Vereinbarungen genutzt wird, würde eine solche Aussage Außenstehende davon abhalten, ihren inaktiven öffentlichen Status falsch zu interpretieren.

Für einen Kunden sollte die Anforderung von Belegen konkret sein. Fordern Sie den letzten Umfang der ISO- und HDS-Zertifikate, die Servicematrix, die zeigt, welche Angebote enthalten sind, die Datenlokalisierungserklärung für Produktion und Backup, die Liste der Unterauftragnehmer, die den Dienst beeinflussen können, und die Kundenverantwortlichkeiten während einer Wiederherstellung. Fragen Sie, wie viele Carrier-Pfade in jeden Standort führen und ob sie physisch divers sind. Fragen Sie, wie Backup-Tests geplant werden, wie Ausfälle gemeldet werden und ob der Kunde dabei zusehen oder das Ergebnis erhalten kann.

Fragen Sie, was passiert, wenn ein Rechenzentrum für eine Woche und nicht nur für eine Stunde ausfällt.

Gleiches gilt für die Kosten. Die Hosting-Ökonomie von Asten hängt von gemeinsam genutzter Infrastruktur ab, weshalb sie für Kunden attraktiv sein kann, die keinen eigenen gesicherten Raum bauen wollen. Aber Resilienz verbraucht reservierte Kapazität. Ein billiger Dienst ohne reservierte Wiederherstellungsmarge ist nicht gleichwertig mit einem teureren Dienst mit getestetem Failover und freier Rechenkapazität. Käufer sollten Basis-Hosting, Backup, Disaster Recovery, Managed Operations, Support-Punkte und Migrationsunterstützung trennen, anstatt anzunehmen, dass sie gebündelt sind.

Das endgültige Urteil lautet, dass die Kapazität von Asten Cloud real genug ist, um unter die Lupe genommen zu werden. Seine öffentlichen Unterlagen ähneln nicht denen eines verschwundenen Anbieters oder eines reinen Vermittlers. Sie zeigen ein rechtmäßiges französisches Unternehmen, bretonische Rechenzentrumsbehauptungen, einen Zertifizierungsumfang, einen live gerouteten Adressraum, Hosting-Produkte, Backup-Tools und die Ausrichtung auf den öffentlichen Sektor. Die Vorsicht des Artikels ist enger gefasst: Die operative Abhängigkeit des Kunden wird nicht durch das Wort Cloud gelöst.

Sie verlagert sich auf die Racks, das Kraftwerk, die Routing-Entscheidungen, die Backup-Repositories, die Support-Warteschlange und die Wiederherstellungsverträge von Asten. Dies ist nur dann ein respektables Infrastrukturangebot, wenn diese physischen und vertraglichen Abhängigkeiten vor dem Ausfall gemessen und nicht während des Reparaturfensters entdeckt werden.