XSALTO35667 Alpilink Cloud S.A.S. verkauft gehostete Kapazität, die weiterhin von Racks, Transit und Wartungsfenstern abhängt

Zusammenfassung

• Das RDAP von RIPE registriertAS35667als XSALTO35667 für Alpilink Cloud S.A.S.; RIPEstat meldete das AS am 15. Juli 2026 angekündigt, mit94.143.216.0/21als sichtbare IPv4-Zuteilung undgültigem RPKIfür diesen Ursprung.
• Die öffentliche Route ist stabil, aber schmal: DerRIPEstat-Routing-Statuszeigte ein IPv4-Präfix, 2.048 IPv4-Adressen, kein sichtbares IPv6-Präfix und einen beobachteten Nachbarn, während dieRIPEstat-Nachbarschaftsdatendiesen Nachbarn als AS28768 identifizierten.
• Alpilinks eigeneCloud-Services-Seitebewirbt Hosting, IaaS, virtuelle Maschinen, Managed Services, Backups und ausgelagerte Notfallwiederherstellung, französischen 24/7-Experten-Support, drei verbundene Rechenzentren, garantierte 40 Gbit/s Bandbreite, über 1.500 gehostete Server und 3 PB gespeicherte Daten; dies sind operative First-Party-Aussagen, keine unabhängigen Kapazitätsaudits.
• Die aktuelle Beweisbewertung ist Mittel-stark für Identität und Routing-Kontrolle, aber nur Mittel für Kundenresilienz. Die öffentlichen Aufzeichnungen stützen einen echten französischen Cloud- und Hosting-Betreiber, aber Kunden benötigen noch aktuelle Nachweise über Rack-Standorte, nutzbare Kapazität, Strom- und Kühldesign, Routendiversität über das übergeordnete AS hinaus, Backup-Isolierung, Support-Eskalation und Migrationsrechte.

Öffentliche Aufzeichnungen deuten auf einen echten französischen Cloud-Betreiber hin, nicht auf einen Wegwerf-Hostnamen

Der wichtigste erste Schritt ist die Identität. Ein Käufer kann die gehostete Kapazität nicht bewerten, ohne zu wissen, welche Organisation die Adressen, Verträge, den Helpdesk und das physische Vermögen hinter dem Dienst kontrolliert. In diesem Punkt hat XSALTO35667 Alpilink Cloud S.A.S. nützliche öffentliche Nachweise. Das RDAP von RIPE unterhttps://rdap.db.ripe.net/autnum/35667nennt AS35667 als XSALTO35667 und verbindet es mit Alpilink Cloud S.A.S., wobei der Organisationseintrag eine Adresse in der 2 Rue de la Viscose, Le Rayon Vert, 38130 Échirolles, Frankreich, zeigt. Dieselbe RDAP-Antwort enthält administrative und Netzwerkbetriebs-Kontakte von XSALTO mit einer Adresse in Seyssinet-Pariset. Diese Details sind keine Leistungsgarantie, aber sie verankern das Unternehmen in einem echten französischen Betriebskontext.

Der Adressraum ist ebenfalls klar. Das RDAP von RIPE unterhttps://rdap.db.ripe.net/ip/94.143.216.0/21identifiziert 94.143.216.0 bis 94.143.223.255 als FR-XSALTO-20090310, PA zugeteilt, Land FR, aktiv und mit Alpilink Cloud S.A.S. verbunden. Die AS-Übersicht von RIPEstat unterhttps://stat.ripe.net/data/as-overview/data.json?resource=AS35667meldete das AS zum Zeitpunkt der Abfrage am 15. Juli 2026 als angekündigt. Sein Endpunkt für angekündigte Präfixe unterhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS35667zeigte 94.143.216.0/21 während des zweiwöchigen Fensters bis zum 15. Juli 2026. Seine Präfix-Übersicht unterhttps://stat.ripe.net/data/prefix-overview/data.json?resource=94.143.216.0/21bestätigte AS35667 als Ursprungsinhaber.

Das Netzwerk ist zudem durch ein Route-Origin-Authorization-Objekt geschützt. Der RPKI-Validierungs-Endpunkt von RIPEstat unterhttps://stat.ripe.net/data/rpki-validation/data.json?resource=35667&prefix=94.143.216.0/21gab einen gültigen Status zurück, mit einem validierenden ROA für das Ursprungs-AS 35667, das Präfix 94.143.216.0/21 und eine maximale Länge /21. Dies ist ein bedeutendes Hygienesignal. Es garantiert keine Verfügbarkeit, Sicherheitsabläufe oder Routendiversität, aber es reduziert eine vermeidbare Routing-Risikoklasse: Eine gültige Route-Origin-Authorization gibt Upstream-Providern und Route-Validatoren ein Mittel, um nicht autorisierte Ursprünge für das angekündigte /21 abzulehnen.

Diese technischen Fakten sind wichtig, weil das Unternehmen eine physische Abhängigkeit verkauft, die in einen Cloud-Dienst eingewickelt ist. Alpilinks eigene Cloud-Services-Seite unterhttps://www.alpilink.fr/services-cloud/listet Hosting, IaaS, virtuelle Maschinen, Managed Services, Backups und ausgelagerte Notfallwiederherstellung. Sie besagt, dass Alpilink Services Cloud die Expertise und Dienste eines souveränen Hosters in Frankreich bietet, mit einem erfahrenen französischen Team, das 24/7 verfügbar ist, einem Sicherheitsengagement und einer nachhaltigen Unternehmenspolitik. Sie nennt auch Skalenzahlen: drei verbundene Rechenzentren, garantierte 40 Gbit/s Bandbreite, über 1.500 gehostete Server und 3 PB gespeicherte Daten. Dies sind keine generischen Software-Behauptungen. Sie implizieren Racks, Strom, Kühlung, Speicher-Arrays, Netzwerkverbindungen, Backups, Support-Personal und Einrichtungen.

Die Herausforderung für den Käufer besteht darin, dass die öffentlichen Nachweise auf der Identitätsebene und der First-Party-Positionierung stark, auf der Live-Kapazitätsebene jedoch unvollständig sind. Wir können ein aktuelles AS, eine aktuelle Routensichtbarkeit, RPKI-Gültigkeit, PeeringDB-Facility-Einträge und eine detaillierte First-Party-Cloud-Seite sehen. Wir können kein kundenspezifisches Kapazitätsregister sehen: verfügbare Schränke, reservierte Leistung, freie Ports, Serverbestand, Ersatzfestplatten, Sättigung des Hypervisor-Clusters, Backup-Reserve, Remote-Hand-Verträge oder Support-Warteschlangentiefe.

Diese Unterscheidung ist nicht feindselig gegenüber Alpilink. Es ist der normale Unterschied zwischen dem Nachweis, dass ein Anbieter existiert, und dem Nachweis, dass die spezifische Arbeitslast eines Kunden den nächsten Ausfall überleben wird.

AS35667 ist ordentlich registriert, aber es ist auch eine schmale öffentliche Routing-Oberfläche

Die Routing-Nachweise sind einerseits ermutigend und andererseits einschränkend. Der RIPEstat-Routing-Status unterhttps://stat.ripe.net/data/routing-status/data.json?resource=AS35667meldete ein IPv4-Präfix, 2.048 IPv4-Adressen, null IPv6-Präfixe in der sichtbaren Ansicht von AS35667, 326 RIS-IPv4-Peers, die die Route sehen, und einen beobachteten Nachbarn zum Zeitpunkt der Abfrage am 15. Juli 2026. Dies ist eine starke Sichtbarkeit für die einzige IPv4-Route. Es bedeutet, dass das AS nicht nur zugewiesen war; es wurde in den öffentlichen Routing-Daten weitgehend gesehen.

Die Einschränkung ist derselbe Datenpunkt, der aus Resilienzperspektive gelesen wird. Ein sichtbares Präfix und ein beobachteter Nachbar beweisen keine Multi-Pfad-Client-Architektur. Der RIPEstat-Nachbarschafts-Endpunkt unterhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS35667zeigte AS28768 als einzigen beobachteten Nachbarn in der Beobachtung vom 14. Juli 2026. Die RIPEstat-WHOIS-Ansicht unterhttps://stat.ripe.net/data/whois/data.json?resource=AS35667zeichnet ebenfalls Import von AS28768 und Export zu AS28768 auf. Der Konsistenz-Endpunkt unterhttps://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS35667fand 94.143.216.0/21 sowohl in BGP als auch WHOIS und AS28768 in den Import- und Export-Ansichten. Das ist sauber. Es ist auch konzentriert.

AS28768 ist kein unbedeutender Hintergrund. Das PeeringDB-Netzwerkobjekt fürhttps://www.peeringdb.com/api/net?asn=28768identifiziert XSALTO mit 10 IPv4-Präfixen, 10 IPv6-Präfixen, einer IX-Anzahl und drei Facility-Einträgen in seinem öffentlichen Profil, währendhttps://www.peeringdb.com/api/netixlan?asn=28768einen Peering-Eintrag France-IX AURA LyonIX auflistet. Die PeeringDB-Netfac-Daten unterhttps://www.peeringdb.com/api/netfac?net_id=9058zeigen AS28768 präsent in Cogent Grenoble, Orange Business - La Fabrique in Grenoble und XSALTO Grenoble in Seyssinet-Pariset. Dies deutet darauf hin, dass das breitere Netzwerk von XSALTO/Alpilink umfangreicher ist als AS35667 allein.

Aber die Zuordnung hier ist spezifisch XSALTO35667 Alpilink Cloud S.A.S., und die öffentliche Ansicht von AS35667 selbst zeigt nicht dieselbe Diversität. Das PeeringDB-Objekt für AS35667 unterhttps://www.peeringdb.com/api/net?asn=35667listet ein IPv4-Präfix, ein IPv6-Präfix in seinem Profil, ein Verkehrsaufkommen von 1 bis 5 Gbit/s, eine Reichweite Europa, ein ausgeglichenes Verhältnis, null IX-Anzahl und eine Facility-Anzahl. Der Netfac-Endpunkt unterhttps://www.peeringdb.com/api/netfac?net_id=13798zeigt diese Facility als XSALTO Grenoble in Seyssinet-Pariset. Der Netixlan-Endpunkt für AS35667 gab zum Zeitpunkt dieser Überprüfung keine öffentlichen IX-LAN-Zeilen zurück. Auch dies bedeutet nicht, dass keine betriebliche Diversität existiert; es bedeutet, dass der öffentliche Diversitätsnachweis für dieses AS begrenzt ist.

Dies ist wichtig, weil viele Kundenausfälle an der Grenze zwischen „die Gruppe hat Resilienz“ und „mein exakter Servicepfad hat Resilienz“ auftreten. Wenn die VMs eines Kunden aus 94.143.216.0/21 nummeriert sind und ihr Weg ins Internet über AS35667 via AS28768 führt, dann sollte der Kunde fragen, wie AS28768 aufgebaut ist, wo sich die Edge-Router befinden, ob die Route innerhalb des Gruppennetzwerks umschalten kann, welche Transit- und Peering-Pfade den Verkehr tatsächlich transportieren und ob DNS, Support, Backup und Zugriffskontrolle des Kunden von derselben Einrichtung abhängen.

Ein übergeordnetes oder benachbartes AS kann echte Redundanz bieten, aber nur, wenn es tatsächlich im Servicepfad des Kunden liegt.

Der physische Bestand konzentriert sich auf Grenoble, mit aktuellen und zukünftigen Schichten, die nicht verwechselt werden sollten

Die physische Seite der Nachweise zeigt auf Grenoble und seine umliegenden Gemeinden. Die RIPE-Register enthalten Échirolles und Seyssinet-Pariset. PeeringDB listet XSALTO Grenoble als Facility in Seyssinet-Pariset. Die First-Party-Cloud-Services-Seite gibt die Kontaktadresse im Le Rayon Vert, 2 rue de la Viscose, 38130 Échirolles an. Die HDS-Garantieseite unterhttps://www.alpilink.fr/services-cloud/garanties-hds/nennt ALPILINK CLOUD in der 6 Avenue Pierre de Coubertin, 38170 Seyssinet-Pariset, und nennt auch Orange - La Fabrique (EOLAS) in der 73 Rue Général Mangin, 38100 Grenoble, als Subunternehmer für zwei Racks. Dies ist ein ungewöhnlich konkretes öffentliches Detail für einen regionalen Cloud-Anbieter.

Dieselbe HDS-Seite ist auch wichtig für die Betreibergrenze. Sie besagt, dass Alpilink Cloud ein eigenes Rechenzentrum besitzt, das es ohne Untervergabe betreibt, mit Ausnahme des Colocation-Hostings in den in der Tabelle aufgeführten Rechenzentren. Sie beschreibt Alpilink Cloud als Hosting-Anbieter, Orange - La Fabrique als Subunternehmer für eine Aktivität mit zwei Racks und den 24/7-Produktsupport teilweise durch Personal in Tahiti mit verschlüsseltem Zugriff.

Dies gibt Kunden eine echte Grenzkarte: Ein Teil des Dienstes wird direkt von Alpilink Cloud betrieben, eine Colocation-Abhängigkeit existiert, und der Supportzugriff kann die Geographie durchqueren, selbst wenn die Datenhosting-Behauptung französisch ist.

Dies ist eine wertvolle Offenlegung, aber sie lässt dennoch betriebliche Details offen, die ein Kunde überprüfen muss. Die öffentliche Seite sagt, dass ISO 27001 vorhanden ist und HDS gilt, aber sie veröffentlicht nicht den vollständigen Prüfumfang, die Standorte der Kundenracks, die Backup-Topologie, die genaue Trennung zwischen Alpilink-eigenen Einrichtungen und den von Orange gehosteten Racks oder welche Workloads sich an welchem Standort befinden. Für einen Kunden mit Gesundheitsdaten zählt die Unterscheidung zwischen Datenstandort, administrativem Zugriff, Backup-Repository, Überwachungstool und Helpdesk.

Für einen nicht im Gesundheitswesen tätigen Kunden zählt dieselbe Unterscheidung für Wiederherstellung und vertragliche Verantwortung.

Die Ankündigung des neuen Rechenzentrums von Alpilink fügt eine zukünftige Ebene hinzu. Der First-Party-Artikel vom Januar 2026 unterhttps://www.alpilink.fr/rechenzentrum-souverain-a-grenoble-alpilink-groupe-renforce-son-offre-dhebergement-avec-un-nouveau-site-opere-par-alpilink-cloud/besagt, dass die Alpilink-Gruppe ein neues souveränes Rechenzentrum in Grenoble baut, das von Alpilink Services Cloud betrieben wird, um seine Infrastruktur bis Sommer 2027 zu stärken. Er gibt an, dass der Standort in Saint-Martin-d'Hères sein wird, in einem erworbenen und für die Nutzung als Rechenzentrum umgebauten Gebäude. Er beschreibt eine modulare Multi-Room-Architektur, hohe Decken, Hochdichte-Design, elektrische und klimatische Redundanz, Notstromaggregate, verstärkte physische Sicherheit, Zugangskontrolle, Überwachung, Kompatibilität mit erweiterten Anforderungen an Notfallwiederherstellung und Geschäftskontinuität, einen angestrebten PUE von etwa 1,3 und einen Zeitplan mit Arbeiten im Jahr 2026, Auslieferung und Tests Anfang 2027 und schrittweiser Inbetriebnahme im Sommer 2027.

Die Projektseite unterhttps://www.alpilink.fr/services-cloud/nouveau-rechenzentrum-alpilink-cloud-a-grenoble/wiederholt denselben Rahmen: Der zukünftige Standort ist für höhere Dichte, Resilienz, Souveränität und Energieeffizienz ausgelegt; er zielt auf eine Tier-III-äquivalente Architektur ab; und er ist zum Zeitpunkt des veröffentlichten Zeitplans noch nicht in Betrieb. Dies ist eine wichtige Grenze zwischen installierter und nutzbarer Kapazität. Ein geplanter Standort kann Vorverkäufe, Reservierung und Architekturplanung unterstützen. Er kann keine Behauptung vom Juli 2026 stützen, dass zukünftige Räume, Strompfade, Kühlpfade und Kundenmigrationsverfahren bereits für Produktionsverkehr nutzbar sind.

Die richtige Sorgfaltsfrage ist daher doppelt. Für den aktuellen Dienst: Wo genau befindet sich der Workload des Kunden heute – bei Alpilink, bei Orange - La Fabrique, an einem anderen verbundenen Standort oder an einem nicht öffentlich genannten verwalteten Standort? Für das 2027-Projekt: Wann wird der reservierte Platz für den Kunden nutzbar sein, welche Abnahmetests müssen bestanden werden, wie werden die Kunden migrieren und was passiert, wenn der Zeitplan für den neuen Standort abrutscht? Die installierte Kapazität ist die Ausrüstung und Installation, die heute mit Strom versorgt, gekühlt, verbunden und unterstützt werden kann.

Die angekündigte Kapazität ist ein Versprechen auf zukünftige Ausrüstung oder Räume. Die nutzbare Kapazität ist die Teilmenge, die ein Kunde tatsächlich mit vertraglichen Bedingungen, Netzwerkerreichbarkeit, Backup-Richtlinie und Personalabdeckung verbrauchen kann.

Der aktuelle Servicekatalog ist breit genug, um viele Abhängigkeitspfade zu schaffen

Die Liste der Cloud-Services-Seite mit Hosting, IaaS, virtuellen Maschinen, Managed Services, Backups und ausgelagerter Notfallwiederherstellung ist wichtig, weil jeder Dienst eine andere Ausfallform hat. Hosting ist am nächsten an der physischen Einrichtung. Der Kunde kann die Hardware besitzen, aber Alpilink stellt Rack-Platz, Strom, Kühlung, Cross-Connects, physischen Zugang und etwas Remote-Hand bereit. IaaS und virtuelle Maschinen übertragen mehr Verantwortung auf den Anbieter: Hypervisoren, Speicher, Orchestrierung, Host-Wartung, Snapshots und manchmal Betriebssystemvorlagen. Managed Services fügen Personal und Verfahren hinzu.

Backup und Notfallwiederherstellung fügen ein separates Wiederherstellungsversprechen hinzu, das unabhängiger sein muss als die Produktionsumgebung, die es schützt.

Die First-Party-Zahlen geben eine Vorstellung vom Umfang: drei verbundene Rechenzentren, garantierte 40 Gbit/s Bandbreite, über 1.500 gehostete Server und 3 PB gespeicherte Daten. Diese Zahlen sind spezifisch genug, um nützlich zu sein. Sie sind auch First-Party-Zahlen. Der öffentliche Routing-Eintrag für AS35667 zeigt ein einzelnes sichtbares /21; das breitere Objekt von AS28768 auf PeeringDB deutet auf einen größeren Netzwerk-Fußabdruck hin; die Cloud-Services-Seite deutet auf eine Multi-Site-Infrastruktur hin; die HDS-Seite nennt ein eigenes Rechenzentrum und einen Subunternehmer-Rack-Standort bei Orange.

Die Nachweise sind konsistent mit einem reifen regionalen Cloud-Anbieter, aber sie erlauben einem externen Beobachter nicht, die Behauptung von 1.500 Servern auf die Einrichtungen, Kunden, Diensttypen oder verfügbare Kapazität zu verteilen.

Das Risiko besteht nicht darin, dass die Zahlen falsch sind. Das Risiko besteht darin, dass Käufer die aggregierte Skala als individuellen Schutz lesen könnten. Ein Anbieter kann 1.500 Server hosten und dennoch den Workload eines Kunden in einem einzigen Rack konzentriert haben. Er kann drei verbundene Rechenzentren haben und dennoch einen bestimmten Backup-Plan verkaufen, der keine standortübergreifende Wiederherstellung beinhaltet. Er kann 40 Gbit/s auf Netzwerkebene garantieren und dennoch Kundenports, Firewalls oder Speicherarrays als Engpass haben.

Er kann 24/7-Support versprechen und dennoch einen Hardware-Austauschpfad haben, der durch Teileverfügbarkeit oder Zugriffsfenster begrenzt ist. Die aggregierte Kapazität ist ein nützlicher Ausgangspunkt; das Service-Design auf Workload-Ebene ist die Kaufentscheidung.

Dies gilt insbesondere für Backup und Notfallwiederherstellung. Alpilink bewirbt ausgelagerte Notfallwiederherstellung, und die HDS-Seite verwendet französische Begriffe für Kontinuität und regulatorische Garantien.

Ein Kunde sollte fragen, ob sich die Backup-Repositories in einer separaten Einrichtung mit separaten administrativen Anmeldeinformationen befinden, ob Backup-Netzwerke durch eine andere Fehlerdomäne verlaufen, ob Wiederherstellungstests dokumentiert sind, wie lange eine vollständige Wiederherstellung dauert, ob Snapshots unveränderlich sind und wie Ransomware-Szenarien, Bedienerfehler oder Abrechnungsstreitigkeiten behandelt werden.

Ein Backup-Dienst, der vom selben Konto, derselben Speichermatrix und derselben Support-Warteschlange wie die Produktion abhängt, kann versehentlichen Datenverlust reduzieren, aber bei einem größeren Ausfall scheitern.

Managed Services schaffen eine weitere versteckte Abhängigkeit: Menschen. Alpilinks öffentliche Seiten betonen die Verfügbarkeit französischer Experten, 24/7-Abdeckung und lokalen Support. Die HDS-Seite gibt an, dass ein Teil des Supportpersonals in Tahiti und ein Teil des Unternehmens ansässig ist. Dies kann eine Stärke sein, da der Zeitzonenunterschied die Abdeckung außerhalb der Geschäftszeiten verbessern kann. Es erfordert jedoch auch Klarheit. Welches Team kann einen Stromzyklus an einem Gerät durchführen? Welches Team kann auf Verwaltungsnetzwerke zugreifen? Welche Vorfälle erfordern Personal in Grenoble?

Wie werden Berechtigungen kontrolliert? Wie werden Zugriffsbeschränkungen für Gesundheitsdaten durchgesetzt? Was passiert, wenn ein Supportvorfall gleichzeitig den Anlagenbetreiber, das Netzwerkteam und einen Kundenadministrator erfordert?

Routing- und DNS-Nachweise sollten als Kontrollnachweise gelesen werden, nicht als vollständige Servicekarte

Die öffentlichen Routing-Nachweise beweisen die Kontrolle über eine nutzbare Internetressource. Sie sagen uns nicht, wo jeder Dienst lebt. Die RIPEstat-Geolokalisierung unterhttps://stat.ripe.net/data/geoloc/data.json?resource=94.143.216.0/21und MaxMind GeoLite unterhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=94.143.216.0/21platzieren das /21 in der abgefragten Ansicht in Frankreich. Die DNS-Kettenabfrage unterhttps://stat.ripe.net/data/dns-chain/data.json?resource=xsalto.comzeigte, dass xsalto.com nach 81.200.40.205 aufgelöst wird, mit den Nameservern ns01.xsalto.net, ns02.xsalto.net und ns03.xsalto.net. Diese Webadresse xsalto.com liegt außerhalb des /21 von AS35667, sollte also nicht als Beweis für den Standort oder die Kapazität von 94.143.216.0/21 verwendet werden.

Dies ist ein normales Muster. Die Marketing-Website eines Unternehmens kann sich auf einer separaten Plattform, einem vererbten Adressbereich, einem Gruppennetzwerk, einem Webhoster oder einem Content-Delivery-Netzwerk befinden. Der Standort der öffentlichen Website ist nur nützlich, wenn es um die Erreichbarkeit der Website geht. Es ist keine direkte Karte des Kunden-Computes. Umgekehrt ist ein geroutetes /21 ein nützlicher Kontrollnachweis, aber kein Servicekatalog. Es kann Verwaltungssysteme, Kunden-VMs, DNS, Überwachung, Backup-Gateways und interne Schnittstellen hosten.

Ohne eine öffentliche Servicekarte können externe Beobachter nicht sagen, welche Adressen welchem Produkt entsprechen.

PeeringDB fügt eine weitere Ebene hinzu, hat aber auch Einschränkungen. Der PeeringDB-Eintrag von AS35667 unterhttps://www.peeringdb.com/api/net?asn=35667listet XSALTO 2, Websitehttp://www.xsalto.com, AS-Set AS-XSALTO, ein IPv4-Präfix, ein IPv6-Präfix im Profil, Reichweite Europa, Verkehr 1-5 Gbit/s, null öffentliche IX-Anzahl und eine Facility-Anzahl. Die Facility-API unterhttps://www.peeringdb.com/api/fac/7114identifiziert XSALTO Grenoble in Seyssinet-Pariset, mit zwei Netzwerken und null IX-Anzahl in diesem Facility-Eintrag. PeeringDB wird von den Betreibern gepflegt und kann unvollständig sein, aber es bleibt ein nützlicher öffentlicher Nachweis, dass das AS nicht nur ein abstrakter Eintrag ist.

Das breitere Profil von AS28768 unterhttps://www.peeringdb.com/api/net?asn=28768ist der Ort, an dem die breitere Interkonnektionsgeschichte sichtbar wird. Es listet einen IX und drei Einrichtungen auf, und der Netixlan-Endpunkt listet France-IX AURA LyonIX. Dies kann die Hypothese stützen, dass Alpilinks breiteres Netzwerk mehr Pfade hat als AS35667 allein. Es beweist nicht ohne ein kundenspezifisches Netzwerkschema, dass der Kundenverkehr von AS35667 unabhängige Upstream-Provider, unabhängige Edge-Router, unabhängige Glasfaserwege oder automatisches Failover zwischen Standorten hat. Die öffentliche Route von AS35667 erscheint hinter AS28768; Kunden sollten fragen, welche Diversität hinter dieser Grenze existiert.

Die RPKI-Gültigkeit ist der stärkste Routing-Hygienepunkt in den aktuellen Nachweisen von AS35667. Sie reduziert das Risiko eines versehentlichen oder bösartigen Ursprungskonflikts. Sie löst nicht alle Routing-Probleme. Wenn AS28768 ausfällt, eine Einrichtung Strom verliert, ein Cross-Connect unterbrochen wird, eine Firewall mit Schließen ausfällt, ein DDoS-Ereignis die Schnittstelle überflutet oder das Kunden-DNS von einem einzigen Providerpfad abhängt, kann RPKI die Anwendung nicht wiederherstellen. Es ist eine Routing-Authentifizierungskontrolle, kein betrieblicher Wiederherstellungsplan.

Stromversorgung, Kühlung und Dichte sind Bereiche, in denen die angekündigte Kapazität mit Vorsicht zu behandeln ist

Die Seiten des neuen Rechenzentrums von Alpilink sind bemerkenswert, weil sie direkt von Leistungsdichte und thermischem Design sprechen. Der Artikel vom Januar 2026 besagt, dass der zukünftige Standort für steigende Anwendungslasten, kritische Informationssysteme und Daten-/KI-Workloads ausgelegt ist. Er erwähnt eine modulare Multi-Room-Architektur, hohe Decken, elektrische Redundanz, klimatische Redundanz, Notstromaggregate, physische Sicherheit, Zugangskontrolle, Überwachung, Kompatibilität mit erweiterter Notfallwiederherstellung und Geschäftskontinuität und einen angestrebten PUE von etwa 1,3.

Die Projektseite sagt dasselbe: Das zukünftige Rechenzentrum zielt auf eine Tier-III-äquivalente Architektur ab, vollständige elektrische Redundanz, modulares Multi-Room-Design, Energiedichte und effizientes Warm-/Kaltluftmanagement.

Diese Behauptungen sind kommerziell bedeutsam. Sie zeigen, dass Alpilink das Problem versteht, mit dem viele regionale Cloud-Anbieter jetzt konfrontiert sind: Die Dichte pro Rack steigt schneller, als vererbte Räume dafür ausgelegt sind. Ein Serverraum, der für bescheidene Virtualisierung gebaut wurde, kann zur Einschränkung werden, wenn Kunden dichten Speicher, Analyse, KI, Sicherheitsappliances oder speicherintensive Hosts anfordern.

Die Kapazitätseinschränkung ist nicht mehr nur die Anzahl der Racks; es ist die Leistung pro Schrank, der Kühlpfad, das Kabelmanagement, die USV-Kapazität, die Laufzeit der Notstromaggregate, die Selektivität der Leistungsschalter, die Überwachung und die menschliche Fähigkeit, ausgefallene Komponenten zu ersetzen, ohne benachbarte Lasten zu stören.

Das Timing ist wichtig. Dieselben Seiten setzen die Arbeiten und die Einrichtung im Jahr 2026, die Auslieferung und Tests Anfang 2027 und die schrittweise Inbetriebnahme im Sommer 2027. Zum Veröffentlichungsdatum dieses Artikels müssen diese zukünftigen Räume als geplant oder in Entwicklung behandelt werden, nicht als bereits nachgewiesene nutzbare Kapazität. Ein Käufer, der Platz reserviert, kann vom Projekt profitieren; ein Käufer, der sofortige Produktionswiederherstellung benötigt, kann nicht auf diesen zukünftigen Standort zählen, bis er in Betrieb genommen, getestet, verbunden, vertraglich vereinbart und akzeptiert ist.

Die aktuellen Behauptungen zu grünem Hosting müssen ebenfalls mit Vorsicht gelesen werden. Der Nachhaltigkeitsartikel vom Juli 2024 unterhttps://www.alpilink.fr/alpilink-cloud-notre-engagement-envers-un-hebergement-durable/besagt, dass Alpilink einen Teil seiner Infrastruktur in einem umweltfreundlichen Rechenzentrum mit 100 % erneuerbarem Strom, Kühlung durch Grundwasserwärme ohne Wasserverbrauch, Einhaltung des europäischen Verhaltenskodex für die Energieeffizienz von Rechenzentren und einer Energieeffizienz unter 1,30 PUE nutzt. Der Artikel vom Juni 2024 unterhttps://www.alpilink.fr/un-rechenzentrum-peut-il-etre-vert/besagt, dass das Rechenzentrum von Alpilink Cloud in der Nähe von Grenoble so tugendhaft wie möglich gestaltet ist und Wasserkraft nutzt.

Diese Nachhaltigkeitsbehauptungen können betriebliche Stärken sein. Effiziente Kühlung und lokale erneuerbare Energie können Betriebskosten und Risikoexposition senken. Aber PUE und grüne Energie beweisen nicht von selbst eine Reservekapazität. Eine Einrichtung mit niedrigem PUE kann voll sein. Ein Standort mit erneuerbaren Energien kann dennoch Einschränkungen bei Notstromaggregaten, USV, Kühlung, Wartung oder Personal haben. Ein nachhaltiger Lebenszyklus der Ausrüstung kann Abfall reduzieren, aber das Bedürfnis erhöhen, das Alter der Hardware, die Ersatzteilpolitik und die Erneuerungsplanung zu verstehen.

Kunden sollten daher die aktuelle Kapazität pro Rack, den Stromverbrauch, die Kühlungszuweisung und das Servicelevel erfragen, anstatt sich nur auf die Nachhaltigkeitssprache zu verlassen.

Datenlokalität ist eine Stärke, muss aber dienstspezifisch angegeben werden

Alpilinks Positionierung ist um die französische Souveränität herum aufgebaut. Die Cloud-Services-Seite besagt, dass das Unternehmen souveränes Hosting in Frankreich und französischen Support anbietet. Der Artikel über Tech & Fest 2026 unterhttps://www.alpilink.fr/techfest-2026-alpilink-services-cloud-au-coeur-des-enjeux-de-souverainete-numerique/rahmt Alpilink Services Cloud um Souveränität, Cloud und Geschäftskontinuität in Grenoble. Die HDS-Garantieseite spricht explizit das Hosting von Gesundheitsdaten, Datenlokalität, Zertifizierung, die Rollen der Subunternehmer und das Risiko des Zugriffs durch ein Drittland an. Dies ist eine nützlichere Offenlegung als ein einfaches „sichere Cloud“-Abzeichen.

Die Faustregel ist immer dienstspezifisch. Die Produktions-VM eines Kunden kann sich in Alpilinks eigener Einrichtung befinden. Eine Backup-Kopie kann in einem anderen verbundenen Rechenzentrum liegen. Eine Rack-Abhängigkeit für Gesundheitsdaten kann Orange - La Fabrique betreffen. Der Supportzugriff kann Personal in Tahiti über verschlüsselten Zugriff beinhalten. DNS kann in einem System, Rechnungen in einem anderen und Kundendokumentation in einem weiteren sein.

Ein Souveränitätsanspruch ist am stärksten, wenn jede dieser Oberflächen kartiert ist: Compute, Speicher, Backups, Protokolle, Tickets, Überwachung, E-Mail, Anmeldeinformationen, Administration und Notfallwiederherstellungs-Runbooks.

Die HDS-Seite gibt Kunden einen Vorsprung, indem sie die Rollen nennt und sagt, dass in diesem Zusammenhang keine Übermittlung personenbezogener Gesundheitsdaten in ein Drittland außerhalb des Europäischen Wirtschaftsraums durch Alpilink Cloud erfolgt. Sie gibt auch an, dass Alpilink Cloud in der angezeigten Tabelle nicht SecNumCloud 3.2 qualifiziert ist. Diese Unterscheidung ist wichtig.

HDS und ISO 27001 können starke Kontrollen für bestimmte Verwendungen sein, aber sie sind nicht identisch mit der SecNumCloud-Qualifikation, noch ein Nachweis vollständiger Resilienz, noch eine Garantie, dass jedes Produkt, jeder Kunde oder jede untervergebene Komponente im selben Umfang ist.

Für nicht gesundheitsbezogene Workloads gilt dieselbe Sorgfalt mit unterschiedlichen Kennzeichnungen. Wo sind die Daten? Wer kann darauf zugreifen? Welches Land regelt den Vertrag? Welche Subunternehmer stellen Rack, Netzwerk, Strom, Überwachung oder Support bereit? Wie schnell kann der Kunde seine Daten exportieren? Werden Backups in derselben rechtlichen und betrieblichen Domäne wie die Produktion gespeichert? Werden Protokolle in Frankreich aufbewahrt? Werden Verschlüsselungsschlüssel vom Kunden, vom Anbieter oder gemeinsam gehalten?

Wenn ein Kunde gehen muss, kann er Festplatten-Images, Datenbank-Dumps, Objektspeicher-Exports und DNS-Kontrolle erhalten, ohne auf eine manuelle Support-Warteschlange zu warten?

Die stärkste Version des Alpilink-Angebots ist lokal, spezifisch und betrieblich: Personal mit Schwerpunkt Grenoble, französische Einrichtungen, namentliche Zertifizierungen, konkrete Racks, bekannte Netzwerkressourcen und zugängliche Migrationspfade. Die schwächere Version wäre ein breiter Souveränitätsslogan ohne dienstspezifische Kartierung. Die öffentlichen Aufzeichnungen sind näher an der starken Version als viele Anbieter, aber ein Käufer benötigt noch den genauen Zeitplan und den Produktumfang für seine eigene Bereitstellung.

Ausfallpfade: Was zuerst kaputt geht und wer betroffen ist

Der offensichtlichste Ausfallpfad ist ein Rack- oder Facility-Problem. Hosting-Kunden können Strom, Kühlung, Cross-Connects oder Remote-Hand-Zugriff verlieren. IaaS-Kunden können einen Host-, Speicher- oder Netzwerkausfall erleiden. Managed-Services-Kunden können auch die Personalbetriebssequenz verlieren, die zur Diagnose von Vorfällen erforderlich ist. Wenn der betroffene Standort Alpilinks eigenes Rechenzentrum ist, kontrolliert der Anbieter die Reaktion mehr. Wenn der betroffene Gegenstand ein untervergebenes Colocation-Rack ist, muss sich der Anbieter mit dem Colocation-Betreiber koordinieren.

Diese Unterscheidung zählt bei einem Nacht- oder Wochenendausfall.

Der Routing-Ausfallpfad ist schmaler, aber sichtbar. AS35667 transitiert in den beobachteten Daten öffentlich über AS28768. Wenn die interne Grenze zwischen AS35667 und AS28768, die Router des übergeordneten AS oder die Upstream-/Peering-Provider-Fabric hinter AS28768 Probleme haben, können Kunden, die aus 94.143.216.0/21 nummeriert sind, Erreichbarkeitseffekte sehen. Die RPKI-Gültigkeit wird nicht helfen, wenn der autorisierte Pfad physisch oder betrieblich außer Betrieb ist.

Kunden sollten fragen, ob Kundenpräfixe verschoben werden können, ob mehrere Edge-Geräte existieren, wo sich die Geräte befinden und ob Pfaddiversität getestet und nicht nur konfiguriert wird.

Der Support-Ausfallpfad ist menschlich. Alpilinks 24/7-Support-Behauptung ist wertvoll, und der Verweis auf den in Tahiti ansässigen Support auf der HDS-Seite kann die Abdeckung verbessern. Aber Kunden sollten wissen, was dieser Support tatsächlich tun kann. Kann das Nachteam einen Host neu starten? Kann es eine Festplatte ersetzen? Kann es auf die Einrichtung zugreifen? Kann es Routing-Änderungen genehmigen? Kann es ein Backup wiederherstellen? Kann es in der vom Kunden geforderten Sprache kommunizieren? Kann es handeln, wenn gesundheitsdatenbezogene Einschränkungen gelten?

Der Unterschied zwischen „wir haben die Warnung gesehen“ und „wir haben den Dienst wiederhergestellt“ ist der Unterschied zwischen Überwachung und Wiederherstellung.

Der Migrations-Ausfallpfad ist der leiseste und oft teuerste. Die aktuellen Cloud-Dienste von Alpilink und das zukünftige Rechenzentrumsprojekt machen Migration zu einer zentralen Frage. Kunden müssen möglicherweise von einem bestehenden Alpilink-Raum zum neuen Standort Saint-Martin-d'Hères wechseln, von einem vererbten Rack zu einem Hochdichterraum, von physischen Servern zu IaaS oder von Alpilink zu einem anderen Anbieter. Jeder Umzug hängt von Netznummerierung, DNS-TTL, Backup-Export, Speicherreplikation, Wartungsfenstern, Anwendungsabhängigkeiten und Personalverfügbarkeit ab.

Ein zukünftiger Rechenzentrumsbau verbessert die Resilienz erst nach der Umsetzung des Migrationsplans.

Die betroffenen Parteien sind breiter als der direkte Käufer. Alpilinks Cloud-Dienste bedienen Organisationen, die sich um Souveränität, Hosting von Gesundheitsdaten, Managed Operations, Geschäftskontinuität und lokalen Support kümmern. Wenn ein Rack, eine Route, ein Speichercluster oder ein Supportprozess ausfällt, können Endbenutzer öffentliche Websites, Tourismus- oder Handelssysteme, interne zahlungsbezogene Anwendungen, interne Unternehmensdienste, Gesundheitsdaten-Workflows, Backup-Wiederherstellungen oder Notfallwiederherstellungsschritte verlieren.

Die öffentlichen Artikel rund um Tech & Fest beschreiben IT-Leiter, CISOs und Geschäftsteams auf der Suche nach regionalen und souveränen Cloud-Modellen. Dies sind genau die Benutzer, für die Wiederherstellungszeit, Datenlokalität und Support-Eskalation keine abstrakten Bedenken sind.

Was würde die Beweisbewertung steigen oder fallen lassen

Die aktuelle Beweisbewertung ist Mittel-stark für Identität und Netzwerkhygiene, da RIPE RDAP, RIPEstat und PeeringDB sich auf das Unternehmen, das AS, den Adressblock, die Routensichtbarkeit und den Kontext der französischen Einrichtung einigen. Sie ist Mittel für Kundenresilienz, da die öffentlichen Nachweise die Live-Servicekarte hinter den aggregierten Behauptungen nicht zeigen. Alpilink veröffentlicht mehr betriebliche Details als viele kleine Anbieter, aber Kunden benötigen noch eine direkte Bestätigung des aktuellen Rack-Standorts, der nutzbaren Kapazität, des Stromversorgungsdesigns, der Backup-Isolierung und der Support-Befugnis.

Die Bewertung würde sich verbessern, wenn Alpilink eine datierte Infrastrukturerklärung veröffentlichen würde, die aktuelle Dienste den Einrichtungen zuordnet, erklärt, welche Rechenzentren durch die optische Schleife verbunden sind, angibt, wo sich die Edge-Geräte von AS35667 und AS28768 befinden, die aktuellen Upstream-/Transit-Vereinbarungen auf Serviceebene nennt, eine öffentliche Status- oder Vorfallsverlaufseite bereitstellt, die Backup-Trennung beschreibt und die aktuelle Kapazität vom Standort 2027 unterscheidet.

Sie würde sich verbessern, wenn das Unternehmen kundenlesbare Migrationsleitfäden für den Bau von Saint-Martin-d'Hères veröffentlichen würde, einschließlich Abnahmetests, Rollback, Routing-Pläne und Support-Fenster.

Die Bewertung würde sinken, wenn AS35667 eine breite Routensichtbarkeit verlieren würde, der gültige RPKI-Status ohne Erklärung verschwinden würde, die PeeringDB-Facility-Informationen veraltet oder widersprüchlich werden würden, die First-Party-Seiten aufhören würden, aktuelle Dienste von zukünftiger Kapazität zu unterscheiden, die HDS/ISO-Erklärungen unklar werden würden oder Kunden die aktuellen Fakten zur Einrichtung und Wiederherstellung im Rahmen des Vertrags nicht erhalten könnten.

Sie würde auch sinken, wenn das zukünftige Rechenzentrumsprojekt als nutzbare Produktionsredundanz vermarktet würde, bevor es in Betrieb genommen und getestet wurde.

Der wichtigste Punkt ist, dass Alpilinks öffentliche Aufzeichnungen nicht leer sind. Sie sind substanziell. Die Vorsicht kommt von der Genauigkeit, nicht von der Abwesenheit. Ein Käufer hat genügend Beweise, um eine ernsthafte Bewertung zu rechtfertigen. Er hat noch nicht genügend öffentliche Beweise, um die technische Sorgfalt zu überspringen.

Was Kunden verlangen sollten, bevor sie die Kapazität zählen

Der praktischste Weg, bei Alpilink zu kaufen, besteht darin, eine Workload-Karte zu verlangen, bevor eine globale Zahl als verfügbare Kapazität behandelt wird. Die Karte sollte die Einrichtung nennen, in der der Produktions-Compute heute läuft, die Einrichtung, in der Backups ruhen, den Routing-Pfad, der von den öffentlichen Adressen des Kunden verwendet wird, die Speicherschicht hinter den virtuellen Maschinen, das Support-Team, das außerhalb der Geschäftszeiten handeln kann, und die Migrationsmethode, wenn der Kunde zum geplanten Standort Saint-Martin-d'Hères umzieht. Diese Anfrage ist keine Sonderbehandlung.

Es ist die minimale Übersetzung der öffentlichen Infrastrukturbehauptungen in einen kundenspezifischen Betriebsplan.

Für die Routing-Resilienz sollte die Karte AS35667 vom breiteren Kontext von AS28768 trennen. Die öffentlichen RIPEstat-Nachweise zeigen AS35667 mit einem einzigen sichtbaren IPv4-/21 und einem beobachteten Nachbarn, während PeeringDB AS28768 mit einem breiteren Facility- und Exchange-Fußabdruck zeigt. Dieser Unterschied kann innerhalb einer Anbietergruppe vollkommen vernünftig sein, aber ein Kunde sollte nicht annehmen, dass jeder Pfad von AS28768 jeden Dienst von AS35667 schützt.

Der Vertrag sollte sagen, welches AS die Adressen des Kunden originiert, wo sich die Edge-Router befinden, welche Upstream- oder Peering-Pfade den Verkehr transportieren, ob das Failover getestet wurde und ob DNS und Steuerungszugriff des Kunden vom selben Standort abhängen.

Für die Facility-Resilienz sollte die Karte den Betrieb von Alpilinks eigenem Rechenzentrum von der Rack-Abhängigkeit bei Orange - La Fabrique unterscheiden, die in der HDS-Garantieseite genannt wird. Ein Kunde, dessen Workload in einem von Alpilink betriebenen Raum gehostet wird, hat ein Antwortmodell; ein Kunde, dessen Workload von untervergebenen Racks abhängt, hat ein anderes.

Der Käufer sollte wissen, wer den physischen Zugang kontrolliert, wer die Ausrüstung ersetzen kann, wer für die Reaktion auf Stromausfälle zuständig ist, welche Wartungsfenster gelten und welche Serviceguthaben oder Ausstiegsrechte gelten, wenn einer der beiden Standorte nicht verfügbar ist. Ohne dieses Detail bleibt der Satz „drei verbundene Rechenzentren“ ein nützlicher Marketing-Kontext, aber kein Nachweis von Redundanz auf Kundenebene.

Für installierte vs. nutzbare Kapazität sollte der Käufer aktuelle Zahlen anstelle von Projektzahlen verlangen. Die 1.500 gehosteten Server, 3 PB gespeicherte Daten und 40 Gbit/s Bandbreite auf der Cloud-Services-Seite beschreiben einen aggregierten Maßstab. Die Seiten des Projekts Grenoble 2027 beschreiben zukünftige Hochdichteräume, Resilienz mit Notstromaggregaten und PUE-Ziele. Keiner dieser Zahlensätze sagt einem bestimmten Kunden, wie viel CPU, RAM, Speicher, Schrankleistung, Cross-Connect-Kapazität oder Supportzeit heute verfügbar sind.

Ein Kunde, der eine kritische Bereitstellung plant, sollte fragen, welche Kapazität frei, reserviert, überbucht ist, welche einen Hardwarekauf erfordert und welche vom Inbetriebnahmezeitplan 2027 abhängt.

Für die Wiederherstellung sollte die Karte einen Wiederherstellungsnachweis enthalten. Backups und ausgelagerte Notfallwiederherstellung sind nur wert, wenn der Backup-Pfad ausreichend vom Produktionsausfall getrennt ist. Kunden sollten aktuelle Nachweise von Wiederherstellungstests verlangen, den Backup-Standort, Backup-Zugriffskontrollen, Eigentum an Verschlüsselungsschlüsseln, Schätzungen der Wiederherstellungszeit, Prioritäten der Wiederherstellungsreihenfolge und eine Datenexportroute, die nicht von einer einzigen überlasteten Support-Warteschlange abhängt.

Ein Anbieter kann echte regionale Stärken haben und dennoch einen Kunden exponiert lassen, wenn der Wiederherstellungsprozess manuell, nicht dokumentiert oder an dasselbe ausgefallene Speichersystem gebunden ist.

Diese Fragen machen Alpilink nicht zu einem schwachen Kandidaten. Es sind die Fragen, die ein glaubwürdiger regionaler Anbieter beantworten können sollte. Die öffentlichen Nachweise zeigen bereits einen routbaren französischen Cloud-Betreiber mit sichtbarer Infrastrukturinvestition. Das fehlende Stück ist nicht die Identität; es ist der kundenspezifische Resilienznachweis. Sobald die Workload-Karte existiert, können Alpilinks lokale Präsenz, seine Compliance-Behauptungen, sein Grenoble-Fokus und sein zukünftiges Rechenzentrumsprojekt anhand eines realen Ausfallmodells bewertet werden, nicht anhand einer Broschüre.

Fazit für abhängige Betreiber

XSALTO35667 Alpilink Cloud S.A.S. sollte als echter regionaler französischer Cloud- und Hosting-Betreiber behandelt werden, mit öffentlichen Identitätsnachweisen, die stärker als der Durchschnitt sind. AS35667 ist bei Alpilink Cloud S.A.S. registriert, sein wichtigstes sichtbares IPv4-/21 wird weitgehend angekündigt, RPKI ist gültig, PeeringDB listet XSALTO Grenoble, und Alpilinks eigene Cloud-Seiten beschreiben Hosting, IaaS, virtuelle Maschinen, Managed Services, Backups, Notfallwiederherstellung, Zertifizierungen, Gesundheitsdaten-Garantien und eine Multi-Rechenzentrums-Geschichte. Das betriebliche Bild ist spezifisch genug, um zu zählen.

Das Abhängigkeitsbild ist ebenfalls spezifisch genug, um in Frage gestellt zu werden. Die öffentliche Routing-Oberfläche von AS35667 ist schmal. Das breitere Netzwerk von AS28768 erscheint diversifizierter, aber der genaue Kundenpfad muss überprüft werden. Die Skalenbehauptungen der Cloud-Services sind First-Party und aggregiert. Das neue Rechenzentrumsprojekt in Grenoble ist für 2027 geplant und sollte nicht als nutzbare Produktionskapazität im Juli 2026 gezählt werden.

Die HDS-, ISO 27001- und Nachhaltigkeitsbehauptungen sind wertvoll, aber sie müssen auf die tatsächliche Einrichtung, den Dienst und den Supportpfad des Kunden abgebildet werden.

Für einen aktuellen Kunden sind die praktischen Fragen direkt. Welche Einrichtung hostet meinen Workload heute? Welches AS und Präfix tragen ihn? Welche Upstream-Provider und Router sind in meinem Pfad? Sind Backups außerhalb der Produktionsausfalldomäne? Welches Personal kann außerhalb der Geschäftszeiten handeln? Wie ist meine Wiederherstellungszeit für einen ausgefallenen Host, ein Speichersystem, ein Rack-Stromereignis, ein Routing-Problem oder einen Standortausfall? Wenn ich zum neuen Rechenzentrum migrieren muss, was muss sich ändern und wer besitzt jeden Schritt?

Für einen neuen Käufer unterstützen die öffentlichen Aufzeichnungen ein qualifiziertes Gespräch, keinen blinden Kauf. Alpilink hat die sichtbaren Zutaten eines glaubwürdigen regionalen Cloud-Anbieters: echte Routing-Ressourcen, einen benannten Facility-Kontext, lokale Abläufe, Compliance-Behauptungen und einen Infrastrukturinvestitionsplan. Die Kaufentscheidung sollte auf aktuellem Nachweis nutzbarer Kapazität, Fehlerisolierung und Ausstiegsrechten basieren. Gehostete Kapazität löst sich immer in physische Abhängigkeiten auf.

Im Fall von Alpilink sind diese Abhängigkeiten sichtbar genug, um bessere Fragen zu stellen: Racks in Grenoble, Routing-Kontrolle über AS35667 und AS28768, Strom- und Kühlungsgrenzen, 24/7-Support-Befugnis, Backup-Trennung und der Migrationspfad von den heutigen Räumen zum versprochenen Standort von morgen.