Valex Cloud LLC verkauft gehostete Kapazität, die noch von Racks, Transit und Reparaturfenstern abhängt

Zusammenfassung

• Valex Cloud LLC verfügt über glaubwürdige Nachweise für den aktuellen Betrieb unter dem Namen Elysia Cloud: einen aktiven Online-Verkaufskatalog, eine öffentliche Statusseite, einen ARIN-Eintrag für AS36744 und die Zuweisung 23.134.124.0/24 sowie RIPEstat-Sichtbarkeit für ein IPv4-Präfix und ein IPv6-Präfix, die von AS36744 stammen.
• Die Betriebsfläche ist klein. RIPEstat zeigt, dass AS36744 am 2026-07-12 23.134.124.0/24 und 2602:f76f::/44 angekündigt hat, während AS19468, ebenfalls unter derselben öffentlichen Identität registriert, nicht angekündigt war; PeeringDB listet keine Austausch- oder Einrichtungsdatensätze für das Netzwerk.
• Valex' eigene Dokumente machen die Anbietergrenze explizit: Die Unterauftragsnehmerliste nennt Cosmic Global für die Rechenzentrums-, Rechen-, Speicher- und Netzwerkinfrastruktur und Cloudflare Magic Transit sowie Cosmic Guard Enterprise für die DDoS-Mitigation.
• Das größte Kundenrisiko ist nicht, ob die Marke existiert. Es geht darum, ob eine bestimmte Arbeitslast einen Vorfall in einer Einrichtung in Los Angeles oder Dallas, eine Änderung des Upstreams oder der Mitigation, ein leeres Hardware-Regal, einen Abrechnungs- oder Steuerungsebenenausfall oder eine Migrationsfrist überstehen kann.
• Das Beweismaß ist Mittel für einen kleinen aktiven Anbieter von gehosteter Kapazität, aber nicht Hoch, da öffentliche Quellen kein getestetes Multi-Site-Failover, keine Ersatzhardwaretiefe, keine unabhängigen Transportpfade, keine Wiederherstellungsleistung oder Ergebnisse der Kundenportabilität belegen.

Ein kleiner Cloud-Anbieter mit Edge-Sichtbarkeit

Valex Cloud LLC ist für Kunden hauptsächlich unter der Marke Elysia Cloud sichtbar. Die offizielle Homepage beschreibt das Angebot als Hosting für Websites, virtuelle dedizierte Server und Spieleserver, mit NVMe-Speicher, DDoS-Schutz und Support; dieÜber-uns-Seitepräsentiert das Unternehmen als leistungsorientierten Hosting-Anbieter, der mit der Nachfrage nach Spieleservern begann und sich zu breiteren Cloud- und VDS-Diensten entwickelte. Das Unternehmen betreibt auch ein separates Abrechnungsportal unterbilling.elysiacloud.comund eine öffentliche Statusseite unterstatus.valexcloud.com. Das ist bereits eine größere öffentliche Präsenz als viele leichte Verzeichniseinträge: Potenzielle Kunden können Produktpaletten, Bestellschaltflächen, Richtliniendokumente, Kundenlogin, Netzwerk-IDs und Dienstmonitore sehen.

Die Frage ist, was diese öffentliche Präsenz beweist. Sie beweist, dass Valex gehostete Kapazität verkauft. Sie beweist nicht von selbst, wie viel Kapazität installiert ist, wie viel Reserve vorhanden ist, wie viele Racks sich unter direkter Kontrolle befinden, ob ein Kunde in einem anderen Gebäude wiederhergestellt werden kann oder ob ein Routingausfall auf ein Produktregal beschränkt oder auf die gesamte Domäne ausgedehnt würde. Für einen kleinen Anbieter sind diese Unterschiede wichtiger als Slogans. Ein VDS-Plan ist nicht nur eine Zeile in einem Warenkorb.

Es ist ein Teil CPU, RAM, Speicher, Paketverarbeitung, Strom, Kühlung und Support-Aufmerksamkeit, die alle gleichzeitig während eines Ausfalls knapp werden können.

Das Netzwerkregister unterstützt einen aktuellen Betrieb. ARIN listetAS36744als ELYSIA, mit der Organisation Elysia Cloud in Chino Hills, Kalifornien, und veröffentlichte NOC-Zeiten von 7:00 bis 21:00 Uhr Pazifik. ARIN listet auchAS19468als ELYSIA-2 für dieselbe Organisation. Die Unterscheidung zwischen den beiden ist wichtig, da die öffentlichen Route-Collectoren sie nicht im selben Zustand zeigen. DerRIPEstat AS36744-Überblickmeldete die ASN am 2026-07-12 angekündigt, während derAS19468-Überblickdie ältere oder sekundäre ASN zum gleichen Abfragezeitpunkt als nicht angekündigt meldete. DieAS19468-Seite von Hurricane Electric BGPfügt einen nützlichen historischen Hinweis hinzu, indem sie die ASN als seit dem 15. Juli 2025 nicht in der globalen Routingtabelle sichtbar markiert.

Für Kunden bedeutet dies, dass die Live-Internet-Grenze über AS36744 gelesen werden muss, nicht über jede mit Valex verbundene ASN, die in der Registerhistorie erscheint. DieAnsicht der angekündigten Präfixe für AS36744 von RIPEstatzeigte zwei im überprüften Fenster sichtbare Ressourcen: 23.134.124.0/24 und 2602:f76f::/44. Der ARIN-Eintrag für23.134.124.0/24nennt ELYSIA-NET-1 und Elysia Cloud. DerRIPEstat IPv4-Präfix-Überblickund derRIPEstat IPv6-Präfix-Überblickidentifizieren beide AS36744 als aktuellen Ursprung. Dies verleiht dem Unternehmen einen tatsächlichen, öffentlichen und aktuellen Routing-Fußabdruck, der jedoch kompakt ist.

Kompakt ist nicht automatisch schlecht. Ein /24 und ein IPv6-Aggregat können genau die richtige Größe für einen jungen Anbieter sein, der Upstream-Mitigation und Rechenzentrumspartner anstelle eines nationalen Backbones nutzt. Dies schränkt jedoch ein, was allein aus dem Routing abgeleitet werden kann. Ein einzelnes /24 IPv4 bedeutet nur 256 IPv4-Adressen vor Berücksichtigung von NAT, privater Adressierung, Shared Hosting und zusätzlichem Raum durch Upstream.

Ein einzelnes sichtbares IPv6-Aggregat zeigt an, dass der Anbieter IPv6-Erreichbarkeit veröffentlichen kann, aber nicht, inwieweit Kunden nativ IPv6 standardmäßig erhalten, wie IPv6 in der Mitigation gefiltert wird oder ob jede Produktebene gleichwertigen Support hat. Deshalb sollte die öffentliche Routingtabelle als Beweis für die Grenze behandelt werden, nicht als Beweis für die Tiefe der Kapazität.

Der Produktkatalog trennt Einzelhandelsversprechen vom verfügbaren Bestand

Der Elysia-Katalog ist für einen kleinen Anbieter breit. DieVDS-Produktseitebewirbt dedizierte vCPU-Ressourcen, vollständigen administrativen Zugriff, NVMe-Speicher, DDoS-Schutz, ein 10-Gbit/s-Netzwerk und eine Verfügbarkeits-SLA von 99,99 %. Der Abrechnungsshop untergliedert dies dann in Produktfamilien. DieStandard-Cloud-VDS-Reihebietet AMD-EPYC-Stufen von 1 vCPU und 2 GB RAM bis zu 16 vCPUs und 32 GB RAM, mit Speicher von 20 GB bis 320 GB. DieHigh-Speed-VDS-Reiheverwendete Ryzen 7- und Ryzen 9-Terminologie, aber die überprüfte Seite zeigte jedes Paket mit „0 Verfügbar". DieExtreme-Cloud-VDS-Reihebewarb Ryzen 9950X-Kapazität und Bestellschaltflächen in einer ähnlichen Paketskala.

Diese Mischung ist der beste öffentliche Hinweis auf installierte Kapazität im Verhältnis zur nutzbaren Kapazität. Die Website kann sagen, dass ein Anbieter über Hochgeschwindigkeitsrechenleistung verfügt; der Warenkorb kann dennoch null verfügbare Einheiten für eine bestimmte Reihe anzeigen. Die genaue Bestandsmenge kann sich schnell ändern, und ein öffentlicher Shop kann nicht alle internen Reservepools offenlegen, aber ein sichtbares „0 Verfügbar" auf jeder High-Speed-VDS-Stufe ist ein Signal, dass die Kapazität eingeschränkt oder bewusst begrenzt ist.

Kunden, die dringend Ersatzkapazität suchen, sollten die Produktseite nicht als Reservierung behandeln. Sie sollten die Verfügbarkeit bei der Bestellung überprüfen, nachfragen, ob der Zielknotentyp an mehr als einem Standort existiert, und bestätigen, ob ein ausgefallener Host durch dieselbe CPU-Klasse oder nur durch eine andere Stufe ersetzt werden kann.

Die Webhosting-Reihe weist auf ein anderes Modell hin. Die offizielleWebhosting-Seitelegt den Schwerpunkt auf cPanel-artiges Hosting mit NVMe-Speicher, SSL und Backups. DerWebhosting-Shoplistete Pläne mit NVMe-Zuweisungen von 10 GB, 25 GB, 50 GB und 100 GB und Bestellschaltflächen. Dies ist ein konventionelleres Shared-Hosting-Kapazitätsmodell: Viele kleine Kunden hängen weniger von einem einzelnen dedizierten Host ab als von Nameservern, Hosting-Bedienfeld, gemeinsam genutztem Speicher, E-Mail-Reputation, Backup-Jobs und der Reaktionsfähigkeit des Personals. Ein Ausfall im Webhosting kann sich daher betrieblich von einem VDS-Ausfall unterscheiden. Er blockiert möglicherweise nicht eine einzelne VM mit hohem Arbeitsspeicher; er kann viele kleine Websites blockieren, die von DNS, cPanel, SSL-Erneuerung und gemeinsam genutzter E-Mail-Verwaltung abhängen.

Spielehosting fügt eine dritte Form der Nachfrage hinzu. Die Elysia-Spieleseiten bewerben Minecraft-, Terraria- und Hytale-Hosting, während die Abrechnungsreihen inBudget-Gameserver,Standard-GameserverundPremium-Gameserverunterteilen. Die überprüfte Standardreihe zeigte eine einzelne Stufe mit einer verfügbaren Einheit, während mehrere andere Stufen null verfügbar anzeigten. Die Nachfrage nach Spieleservern ist sporadisch und latenzempfindlich. Ein Knoten, der für eine kleine ruhende Community akzeptabel ist, kann während abendlicher Spitzenzeiten, Modpack-Updates, DDoS-Angriffen auf öffentliche Communities oder Turnierereignissen inakzeptabel werden. Wenn Valex dieselben physischen Pools für Spieleserver und VDS-Produkte verwendet, kann der Bestandsdruck in einer Reihe Kunden über das gesamte Rack informieren, selbst wenn das Abrechnungsportal Produktreihen getrennt behandelt.

Dies ist der wirtschaftliche Kernpunkt: Ein kostengünstiger Anbieter von gehosteter Kapazität verkauft ein Versprechen, das einfacher zu bestellen als wiederherzustellen ist. Das beworbene Paket ist statisch. Das wiederherstellbare Paket hängt von Reserve-RAM, Reserve-NVMe-Kapazität, Reserve-IP-Adressen, verfügbarer Mitigationsbandbreite, funktionierender Automatisierung, Personalreaktionszeit und der Fähigkeit ab, einen Kunden zu verschieben, ohne dessen Lizenz- oder Datenresidenzauflagen zu verletzen.

Valex veröffentlicht genug, um als Betreiber ernst genommen zu werden, aber nicht genug, damit ein Kunde annehmen kann, dass jedes Produkt einen gleichwertigen Ersatzpfad hat.

Der physische Standort wird offengelegt, aber die Rack-Unabhängigkeit ist nicht nachgewiesen

Valex' eigenes Sicherheits- und Vertrauensdokument ist ungewöhnlich spezifisch in Bezug auf die Standortgeografie. Die öffentlicheSicherheits- und Vertrauensseiteidentifiziert eine primäre Einrichtung in Los Angeles, Kalifornien, beschrieben als anbieterbesessen, und eine sekundäre Einrichtung in Dallas, Texas, beschrieben als Colocation mit Cosmic Global, Inc. Sie charakterisiert beide als Tier-III-Einrichtungen. DieUnterauftragsnehmerlistenennt separat Cosmic Global, Inc. für Rechenzentrumshosting, Rechenleistung, Speicher und Netzwerkinfrastruktur in den USA. Diese Offenlegungen sind wertvoll, da sie „Cloud" in eine Karte verwandeln: Zumindest ein Teil des Kundenrisikos liegt in Südkalifornien und ein Teil in Nordtexas.

Die Offenlegungen schaffen auch die zentrale Unsicherheit. Eine anbieterbesessene Einrichtung in Los Angeles kann alles bedeuten, von einem substanziellen Standort mit unabhängiger Stromversorgung bis zu einem kleinen Raum oder einem Käfig, der in einer größeren Einrichtungsanordnung kontrolliert wird, je nachdem, wie der Begriff in seinem Kontext verwendet wird. Eine Colocation-Abhängigkeit in Dallas ist klarer: Cosmic Global ist ein externer Betreiber oder Infrastrukturanbieter für zumindest einen Teil der Rechen-, Speicher- und Netzwerkinfrastruktur.

Die hier überprüften öffentlichen Quellen zeigen nicht die Anzahl der Racks, die Schrankleistungsdichten, die Generatorautonomie, die Kühlungstopologie, die Interconnect-Bestände, die Speichercluster-Layouts, die Live-Auslastung, die Ersatzknotenbestände oder die getesteten Failover-Übungen zwischen Los Angeles und Dallas. Sie zeigen auch nicht, ob Kundendienste automatisch an beiden Standorten platziert werden oder ob ein Standort für ausgewählte Produkte, Backups, Mitigation, Überlauf oder zukünftige Erweiterung genutzt wird.

PeeringDB verstärkt diese Vorsicht. DerPeeringDB-Eintrag für AS36744identifiziert Valex Cloud LLC, auch bekannt als Elysia Cloud, als ein Netzwerk mit globaler Reichweite mit IPv6-Unterstützung und einem Verkehrsaufkommen von 5-10 Gbit/s, listet jedoch null Austausch- und null Einrichtungseinträge. PeeringDB wird von Benutzern gepflegt und ist unvollständig, daher beweist das Fehlen von Einrichtungseinträgen nicht das Fehlen von Einrichtungen. Es bedeutet, dass Kunden PeeringDB nicht verwenden können, um zu überprüfen, wo AS36744 Verbindungen herstellt, wo es Router hält oder ob es unabhängige Points of Presence hat. Wenn das eigene Whitepaper eines Anbieters angibt, dass es Einrichtungen gibt, und PeeringDB keine externe Bestätigung der Einrichtungen liefert, ist die vorsichtige Lesart: Die Standortbehauptungen sind plausibel und vom Unternehmen veröffentlicht, aber die Rack-Unabhängigkeit bleibt ungeprüft.

Dies ist bei einem Einrichtungsvorfall wichtig. Wenn der Standort Los Angeles die Stromversorgung, Kühlung, den Zugang oder die Upstream-Verbindung verliert, müssen Kunden wissen, ob ihre VDS in Dallas starten kann, ob der Speicher repliziert ist, ob IP-Adressen vom anderen Standort aus neu angekündigt werden können, ob DNS- und Steuerungsebenendienste erreichbar bleiben und ob das Supportpersonal über Fernhandabdeckung verfügt. Die gleiche Frage stellt sich umgekehrt für Dallas. Ein sekundärer Standort ist nicht automatisch ein Failover-Standort.

Er kann ein Backup-Standort, ein Überlaufstandort, ein anderer Produktpool oder eine vertragliche Einrichtung sein, die nur einen Teil der Domäne beherbergt. Das Kundenrisiko hängt von der tatsächlichen Platzierung seines Volumens, Images, seiner DNS-Zone, IP-Adresse und seines Backups ab.

Die Geschäftsbedingungen machen diesen Punkt expliziter als eine Marketingseite. Die SLA und die Bedingungen beschreiben Verfügbarkeitsgutschriften, Ausschlüsse, Wartung, Drittanbieterdienstgrenzen und Kundenverantwortlichkeiten, aber sie verwandeln kein allgemeines Verfügbarkeitsziel in eine Garantie für die Notfallwiederherstellung. Die öffentlichen Bedingungen legen auch die Planung von Backup und Notfallwiederherstellung stark auf den Kunden. Dies ist im Hosting nicht ungewöhnlich.

Es ist jedoch eine direkte Warnung davor, die Aussage des Anbieters über zwei Standorte als Ersatz für clientseitige Replikation und getestete Wiederherstellung zu behandeln.

Der Transitpfad hängt von Cloudflare, Cosmic und mindestens einem Nachbarn im öffentlichen Cloud-Bereich ab

Die Routingdaten liefern die klarste Sicht auf die öffentlichen Netzwerkabhängigkeiten von Valex. DieAS-Nachbarn-Ansicht von RIPEstatmeldete zum überprüften Zeitpunkt drei linke Nachbarn für AS36744: AS13335, AS20473 und AS30456. RIPEstat identifiziertAS13335als Cloudflare,AS20473als The Constant Company, besser bekannt über das Vultr-Netzwerk, undAS30456als Cosmic Global Networks. DieCAIDA-Ansicht von AS36744markiert das Netzwerk ebenfalls als gesehen, mit zwei Anbietern und einem sehr kleinen Cone. Dies ist eine upstream-abhängige Grenze, keine dichte Peering-Struktur.

Die offizielle Unterauftragsnehmerliste stimmt mit der Routingtabelle überein. Sie nennt Cloudflare Magic Transit und Cosmic Guard Enterprise für die DDoS-Mitigation und listet Cosmic Global und Cloudflare als Upstream-Transitanbieter. Der Abrechnungsshop wiederholt, dass Cloudflare Magic Transit und Cosmic Guard Enterprise den DDoS-Schutz über mehrere Produktreihen hinweg unterstützen. In der Praxis sollten Kunden die DDoS- und Routing-Resilienz von Valex als gemanagtes Upstream-Design betrachten.

Das Unternehmen kann geschütztes Hosting verkaufen, ohne jedes Mitigationssystem zu besitzen, aber der Wiederherstellungspfad eines Kunden hängt dann von den Beziehungen des Anbieters zu Cloudflare, Cosmic und allen anderen Upstreams ab, die den Datenverkehr transportieren oder filtern.

Dies ist an sich kein Mangel. Kleine Hosting-Anbieter kaufen oft Transit-, DDoS-Filter- und Einrichtungsdienste, weil deren Besitz in ihrem Maßstab irrational wäre. Das Risiko liegt im Abhängigkeitsstapel. Wenn eine DDoS-Mitigationsrichtlinie den Spielverkehr falsch klassifiziert, kann ein Kunde Latenz oder Paketverluste sehen, selbst wenn der Ursprungsserver gesund ist. Wenn sich eine Cloudflare- oder Cosmic-Routenrichtlinie ändert, kann ein Präfix neu konvergieren. Wenn sich ein Upstream-Pfad verschlechtert, kann der Kunde einen Ausfall erleiden, den der Anbieter anders unter SLA-Ausschlüssen einstuft.

Wenn AS20473 für einige Pfade verwendet wird, kann ein Kunde auch dem Verhalten eines großen Infrastrukturnetzwerks ausgesetzt sein, dessen Richtlinien außerhalb der direkten Kontrolle von Valex liegen.

Die RIPEstat- und RPKI-Nachweise sind positiv für den aktuellen Ursprung. DerRouting-Status für 23.134.124.0/24zeigte das Präfix zuletzt von AS36744 am 2026-07-12 mit voller Sichtbarkeit der RIS IPv4-Peers gesehen. DerRouting-Status für 2602:f76f::/44zeigte das IPv6-Präfix zuletzt von AS36744 mit breiter IPv6-Sichtbarkeit. DasRPKI-Validierungsergebnis für 23.134.124.0/24war gültig für AS36744, und dasRPKI-Validierungsergebnis für 2602:f76f::/44validierte ebenfalls den aktuellen AS36744-Ursprung. Dieser Routing-Sicherheitsnachweis ist deutlich besser als eine nicht registrierte oder ungeschützte Grenze.

Doch dieselben Aufzeichnungen zeigen, warum Kunden nach Änderungskontrolle fragen sollten. Der RIPEstat-Routing-Verlauf zeigt beide Präfixe zuerst von AS19468 gesehen, bevor sie von AS36744 gesehen wurden. DieAS36744-Seite von Hurricane Electric BGPmeldet derzeit zwei Ursprungspräfixe, während die AS19468-Seite veraltet ist. Die Migration zwischen ASNs kann ein normales Management sein, aber Kunden benötigen Klarheit darüber, welche ASN in Produktion ist, welche Präfixe portierbar sind und was passiert, wenn Valex den Upstream oder die ASN-Richtlinie erneut ändert. Der validierte RPKI-Ursprung ist eine Grundlage. Es ist keine vollständige Antwort auf Konvergenz, Wartung oder Mitigationsverhalten.

Datenlokalität ist ein US-Versprechen, sofern der Kunde nichts Gegenteiliges nachweist

Die Zuordnungskategorie ist global, da der Dienst über das Internet bestellt werden kann und der PeeringDB-Eintrag eine globale Reichweite verwendet. Die physischen und rechtlichen Nachweise deuten jedoch hauptsächlich auf die USA hin. Die Sicherheits- und Vertrauensseite nennt Los Angeles und Dallas. Die ARIN-Einträge lokalisieren die Organisation in Kalifornien. Die Unterauftragsnehmerliste platziert Infrastruktur-, Zahlungs- und Mitigationsunterauftragnehmer in den USA.

Die Datenschutz- und DPA-Seiten beschreiben grenzüberschreitende Übermittlungsmechanismen und Datenresidenzverhalten, aber die hier überprüften öffentlichen Materialien etablieren keine Produktionseinrichtung in Europa, Asien oder Lateinamerika für Kundenworkloads.

Die Unterscheidung ist wichtig für die Datensouveränität. Ein Kunde außerhalb der USA kann einen scheinbar globalen Hosting-Dienst kaufen und seine Daten dennoch auf US-amerikanischer Infrastruktur, über US-amerikanische Unterauftragnehmer, mit US-amerikanischem Recht und vertraglichen Übermittlungsmechanismen platzieren, die Zugriff und Offenlegung gestalten. DasDatenverarbeitungsaddendumgibt an, dass die Verarbeitung Hosting, Speicherung, Berechnung, Übertragung, Backup und Notfallwiederherstellung von Kundeninhalten umfassen kann, und gewährt Kunden eine 30-tägige Wiederherstellungsfrist nach Kündigung, gefolgt von einer Löschfrist. DieDatenschutzrichtliniebehandelt Konto-, Abrechnungs-, Support-, Betriebs- und Sicherheitsdaten, einschließlich Infrastrukturtelemetrie und Supportkommunikation. Dies sind keine reinen Compliance-Texte. Sie definieren, wohin die Betriebsdaten eines Kunden während des normalen Betriebs, des Supports und der Vorfallreaktion gelangen können.

Valex' Bedingungen besagen, dass die ruhenden Kundendaten in dieser Region gespeichert werden, vorbehaltlich Ausnahmen, wenn ein Kunde eine bestimmte Region für die Datenresidenz auswählt. Dieser Satz ist nur nützlich, wenn der Kunde weiß, welche Regionen für das bestellte Produkt existieren. Die hier überprüften öffentlichen Shop-Seiten werden von US-West-Sprache und US-zentrierten Infrastrukturoffenlegungen dominiert. Die Statusseite überwacht „US West Standard Compute" und „US West High Speed Compute". Diese Status-Taxonomie deutet auf mindestens eine Betriebsregion hin, beweist jedoch kein breites regionales Menü.

Ein Kunde mit strengen Lokalitätsauflagen sollte sich nicht auf das Wort „global" in einer Netzwerkdatenbank oder auf global erreichbaren Routen verlassen. Er sollte produktspezifische Zusagen darüber einholen, wo Datenträger, Snapshots, Backups, Protokolle, Support-Exporte und Notfallwiederherstellungskopien gespeichert werden.

Hier unterscheidet sich gehostete Kapazität von Software als Dienstleistung. Ein SaaS-Kunde kann sich auf Anwendungsdaten und Benutzerkonten konzentrieren. Ein VDS- oder Spieleserver-Kunde muss an Blockgeräte, VM-Images, IP-Adressen, DNS-Einträge, Backups, Konsolenzugriff, SSH-Schlüssel, Missbrauchstickets und Zahlungsaufzeichnungen denken. Wenn Valex' Standort Dallas für Backups verwendet wird, kann dies für einen US-Kunden akzeptabel und für einen Kunden mit engeren regionalen Beschränkungen problematisch sein. Wenn ein Backup nicht anwendungskonsistent ist, ist die Region nur ein Teil des Wiederherstellungsrisikos.

Wenn ein Kunde innerhalb von 30 Tagen nach Kündigung exportieren muss, müssen die Bandbreite, Migrationssysteme und der alternative Host des Kunden bereit sein, bevor die Frist zu laufen beginnt.

Die öffentlichen Nachweise stützen daher das Thema „Datensouveränität und Datenlokalität" mit einer spezifischen Schlussfolgerung: Valex liefert genügend Offenlegungen, um die US-zentrierten Abhängigkeiten zu identifizieren, aber nicht genug, damit ein regulierter Kunde die Lokalität als selbstverständlich betrachten kann, ohne eine schriftliche Bestellung oder Supportbestätigung. Die wichtigsten Fragen sind nicht abstrakt. Welche Einrichtung wird die Workload beherbergen? Können Backups diese Einrichtung verlassen? Werden Snapshots nach Dallas repliziert? Kann das Supportpersonal von außerhalb der gewählten Region auf Kundendaten zugreifen?

Was passiert mit Protokollen und Missbrauchsnachweisen? Kann der Kunde vollständige Images (nicht nur Dateien) wiederherstellen, wenn er migrieren muss?

Die Statusseite sagt Kunden, was Valex als überwachbar betrachtet

Dieöffentliche Statusseiten-APIist klein, aber aufschlussreich. Sie gruppiert Monitore in Websites, Cloud-Compute-Dienste und DNS. Die Gruppe Websites umfasst die Valex Cloud-Website und die Valex Cloud-Compute-Plattform. Die Gruppe Compute umfasst US West Standard Compute und US West High Speed Compute. Die Gruppe DNS umfasst Web Hosting DNS 1 und Web Hosting DNS 2. Zum überprüften Zeitpunkt listete die öffentliche API keine aktiven Vorfälle und keine Wartungseinträge.

Statusseiten sind keine vollständigen Ausfallerkennungsinstrumente. Sie zeigen, was ein Anbieter offenzulegen wählt, nicht jede interne Abhängigkeit. Dennoch ist die Status-Taxonomie von Valex wichtig. Sie zeigt, dass der Anbieter zwischen der öffentlichen Website und der Compute-Plattform unterscheidet, zwischen Standard- und High-Speed-Compute unterscheidet und Webhosting-DNS als separaten überwachten Dienst behandelt. Wenn ein Kunde eine gehostete Website, eine VDS und eine Spielgemeinschaft betreibt, sind dies nicht dieselben Ausfallpfade. DNS kann ausfallen, während Compute weiterläuft.

High-Speed-Compute kann nicht verfügbar sein, während Standard-Compute bestellbar bleibt. Die öffentliche Website kann über Cloudflare erreichbar sein, während die Compute-Plattform oder das Ursprungsnetzwerk beeinträchtigt ist.

Die Statusseite verankert auch die operative Sprache „US West". „US West Standard Compute" und „US West High Speed Compute" sind engere Bezeichnungen als „globale Cloud". Sie implizieren, dass die sichtbarste Compute-Domäne regional gerahmt ist. Wenn ein Kunde niedrige Latenz aus Europa oder Asien erwartet, beweisen die öffentlichen Materialien keine lokale Region. Wenn ein Kunde ein Failover zwischen Einrichtungen in derselben Gerichtsbarkeit erwartet, zeigt die Statusseite dies nicht.

Wenn ein Kunde eine verwaltete Multi-Region-Datenbank oder einen Objektspeicher-Kontinuitätsplan erwartet, legt die Statusseite diese Dienste nicht als separate öffentliche Monitore offen.

Kunden sollten die Statusseite als Ausgangspunkt für operative Fragen nutzen. Veröffentlicht Valex historische Verfügbarkeit für jeden Monitor? Werden Vorfälle nach der Lösung ausgefüllt? Werden Wartungsfenster vor Kernel-, Hypervisor-, Router- oder Speicherarbeiten angezeigt? Sind die DNS- und Compute-Monitore extern zum überwachten Netzwerk oder werden sie aus der internen Umgebung des Anbieters gemessen? Reicht ein Ping-Monitor für Compute aus, um Speicherverschlechterung oder Paketverluste unter DDoS-Mitigation zu erfassen? Die öffentliche API beantwortet diese Fragen nicht, aber sie sagt Kunden, wo sie anfangen sollen.

Die Existenz einer Statusseite bleibt ein positiver Nachweis. Viele kleine Hosting-Anbieter bieten nur eine Support-Adresse. Valex gibt Kunden eine öffentliche Oberfläche für den Plattformstatus, und seine rechtlichen Bedingungen beschreiben Support-Ticket-Kanäle für SLA-Gutschriftsanfragen. Dies ist eine bessere Position als Schweigen. Der Nachteil ist, dass die Statusseite keinen clientseitig verwalteten Monitor von der eigenen Geografie und dem Workload-Pfad ersetzt.

Ein Ping zu einem Compute-Knoten beweist nicht, dass die Tickrate eines Minecraft-Servers gesund ist, dass ein Datenbank-Schreibpfad sicher ist oder dass ein cPanel-Backup wiederhergestellt wird.

Rack- und Hardwareausfall: Der Ausfall, den Kunden am wahrscheinlichsten spüren

Valex verkauft CPU-spezifische Pakete: EPYC für Standard-VDS und Budget-Gameserver, Ryzen 7 und Ryzen 9 für die High-Speed-Stufen und Ryzen 9950X für die Extreme- und Premium-Stufen. Diese Spezifität ist für Käufer attraktiv, da sie die Leistung in ein Kaufattribut verwandelt. Sie verwandelt auch den Hardwarebestand in eine Wiederherstellungsabhängigkeit. Wenn ein Ryzen 9950X-Knoten ausfällt und kein Ersatzteil in derselben Einrichtung vorhanden ist, kann der Kunde auf eine niedrigere Stufe zurückgesetzt werden, auf Ersatzhardware warten, eine andere Geografie akzeptieren oder manuell migrieren.

Die Signale „0 Verfügbar" im Shop für High-Speed-VDS und die meisten Standard-Game-Stufen sind daher nicht nur Verkaufsanekdoten. Sie sind Hinweise auf mögliche Spannungen im physischen Bestand.

Die Bedingungen erkennen dies in allgemeiner Form an. Die Sprache über dedizierte Server in den öffentlichen Bedingungen besagt, dass die Behebung von Hardwareausfällen von Ersatzteilen, der Komplexität und der physischen Zugänglichkeit der Rechenzentrumseinrichtung abhängt. Die Backup-Bedingungen besagen, dass Wiederherstellungszeiten von der Datengröße, der Zielressource, der Rechenzentrumsauslastung, den Netzwerkbedingungen und dem Speicherdurchsatz abhängen. Dies sind gewöhnliche Warnungen, aber sie treffen genau den Punkt, an dem Ausfälle kleiner Anbieter schmerzhaft werden. Ein Kunde fällt nicht in einen abstrakten Dienst um.

Er fällt auf eine verfügbare Festplatte, verfügbaren RAM, eine Ersatz-IP, eine Routenankündigung und einen Ingenieur oder einen Fernwartungsprozess, der die Reparatur durchführen kann.

Es gibt mehrere praktische Ausfallszenarien zu testen. Erstens, ein einzelner Host-Ausfall: Kann Valex das VM-Image oder die Spieleserverdateien auf einen anderen Host verschieben, ohne die IP-Adresse zu ändern? Zweitens, ein Speicherpool-Ausfall: Sind Backups unabhängig vom ausgefallenen Pool und werden sie überprüft? Drittens, ein Einrichtungszugriffsereignis: Kann die Ersatzarbeit fortgesetzt werden, wenn das Personal den primären Standort nicht betreten kann?

Viertens, eine Kapazitätsknappheit: Wenn die High-Speed-Stufen ausverkauft sind, reserviert Valex versteckte Wiederherstellungskapazität für bestehende Kunden, oder bedeutet ausverkaufte Verkaufskapazität auch keine gleichwertige Ersatzhardware? Fünftens, eine Wartungskollision: Wenn ein Host während eines Upstream-Ereignisses gepatcht wird, welcher Dienst erhält zuerst die Support-Aufmerksamkeit?

Kunden sollten auch die Existenz von Backups von der Wiederherstellungsgarantie trennen. Die Elysia-Webhosting-Seite bewirbt Backups, und ihre Backup-Bedingungen beschreiben Backup-Funktionen, aber die öffentlichen Bedingungen legen eine erhebliche Überprüfungsverantwortung auf den Kunden. Ein abgeschlossener Backup-Job ist nicht dasselbe wie eine anwendungskonsistente Wiederherstellung. Für einen Webshop kann ein wiederhergestellter Dateibaum ohne konsistente Datenbank unbrauchbar sein.

Für eine Spielgemeinschaft kann ein World-Backup, das während eines Schreibvorgangs erstellt wurde, einen Rückfall oder eine Beschädigung des Zustands verursachen. Für einen VDS-Kunden enthält ein Block-Snapshot möglicherweise keine externen DNS, Firewall-Regeln, API-Schlüssel oder Drittanbieterlizenzen. Das Ergebnis ist ein gehosteter Kapazitätsbetrieb, bei dem der Kunde nicht nur die Verfügbarkeit, sondern auch die Wiederherstellungssemantik testen muss.

Die Kundengruppe, die diesem Ausfallpfad am stärksten ausgesetzt ist, ist diejenige, die Valex als einzigen Infrastrukturanbieter nutzt. Ein Gelegenheitsspieleserver kann einen Wiederaufbau tolerieren. Eine kleine Geschäftswebsite kann das nicht. Ein SaaS-Startup, das eine Budget-VDS für die Produktion nutzt, sollte annehmen, dass anbieterseitige Redundanz nicht dasselbe ist wie ein Geschäftskontinuitätsplan. Es sollte anbieterunabhängige Backups aufbewahren, wissen, wie DNS woanders wiederhergestellt wird, und vermeiden, von einem anbieterspezifischen Image-Format abhängig zu sein.

Valex kann ein rationaler kostengünstiger Hosting-Anbieter für viele Workloads sein, aber je wichtiger die Workload, desto weniger akzeptabel ist es, den gesamten Wiederherstellungspfad an eine öffentliche SLA-Gutschrift auszulagern.

Upstream-, Mitigations- und Routingausfall: Wenn der Server gesund, aber nicht erreichbar ist

Der zweite große Ausfallpfad ist der Upstream- oder Mitigationsausfall. Da Valex' Grenze Cloudflare, Cosmic und mindestens einen weiteren beobachteten Nachbarn nutzt, kann der Kunde die Erreichbarkeit verlieren, selbst wenn der Ursprungsserver und der Speicher gesund sind. DDoS-Mitigation kann den Durchsatz drosseln oder Datenverkehr filtern. BGP-Änderungen können langsam neu konvergieren oder asymmetrische Pfade erzeugen. Ein Upstream kann eine Route zurückziehen. Ein Präfix kann global sichtbar bleiben, während eine bestimmte Region oder ein bestimmter Betreiber Paketverluste sieht.

Öffentliche Route-Collectoren sind hervorragend geeignet, um Makro-Erreichbarkeit nachzuweisen, aber sie können keine Kundenerfahrung von jedem Zugangsnetzwerk garantieren.

Valex' Routing-Sicherheitslage ist ein positiver Ausgangspunkt. Die aktuelle RPKI-Validierung für AS36744 auf beiden sichtbaren Präfixen reduziert das Risiko, dass Route-Leaks oder nicht autorisierte Ursprünge von Netzwerken akzeptiert werden, die RPKI anwenden. DieRIPEstat-Sichtbarkeitsdaten für 23.134.124.0/24zeigten am 2026-07-12 breite IPv4-Sichtbarkeit von den Collectoren, und dieSichtbarkeitsdaten für 2602:f76f::/44zeigten breite IPv6-Sichtbarkeit mit einem Peer mit voller Tabelle, der in den Stichprobenergebnissen nicht als sehend aufgeführt war. Hurricane Electric BGP meldet auch die Ursprungspräfixe von AS36744 als RPKI-gültig. Für einen kleinen Hosting-Anbieter ist dies eine signifikante Basis.

Die Einschränkung ist die Diversität. RIPEstat zählte drei beobachtete Nachbarn, während CAIDA AS36744 mit einem Grad von zwei Anbietern und einem Cone von einem Präfix meldete. PeeringDB listete keine Austauschpunkte. Dies bedeutet, dass Kunden keine dichte Routenoptionalität annehmen sollten. Wenn Cloudflare der primäre Mitigationspfad für Kundenverkehr ist und Cosmic sowohl Rechenzentrums- oder Colocation-Partner als auch Upstream-/Mitigationspartner ist, kann ein Richtlinienereignis bei Cosmic oder Cloudflare mehr als ein einzelnes Anbieterproblem sein.

Es kann eine kombinierte Abhängigkeit von Einrichtung, Transit, Mitigation und Support sein.

Kunden sollten Valex mehrere routing-spezifische Fragen stellen, bevor sie kritische Dienste platzieren. Welche Präfixe werden für jedes Produkt verwendet? Kann ein Kunde seinen eigenen IP-Raum mitbringen? Werden Kundenpräfixe akzeptiert, und wenn ja, welche RPKI- und IRR-Anforderungen gibt es? Kann Valex den Kundenraum von Los Angeles und Dallas aus ankündigen? Gehen DDoS-geschützte Pfade immer über Cloudflare und Cosmic Guard, oder wählt der Kunde? Misst die SLA die Erreichbarkeit von den Monitoren des Anbieters oder von verschiedenen externen Sonden? Wie werden Routenänderungen kommuniziert?

Gibt es einen Looking Glass oder eine Routenrichtlinienseite über den PeeringDB-Eintrag hinaus?

Die Antwort kann für viele Käufer völlig ausreichend sein. Ein Webhosting-Kunde hinter Cloudflare DNS und einem CDN kann sich weniger um den rohen AS-Pfad kümmern als um cPanel, E-Mail und Website-Verfügbarkeit. Eine latenzempfindliche Spielgemeinschaft kann sich intensiv um mitigationsinduzierten Jitter kümmern. Ein VDS-Kunde, der APIs ausführt, kann sich um eine stabile Ausgangsreputation und Kontinuität der Kunden-IP kümmern. Deshalb sollte Valex' gehostete Kapazität workload-spezifisch bewertet werden, nicht mit einem einzigen Etikett wie Cloud, Hosting oder Spieleserver.

Ein Ausfall von Abrechnung, Support und Steuerungsebene kann zu einem Infrastrukturausfall werden

Kleine Infrastrukturanbieter lassen Kunden oft über die Steuerungsebene im Stich, bevor die Server ausfallen. Valex' Abrechnungsportal ist ein WHMCS-artiges Kundensystem, das für Bestellung, Anmeldung, Rechnungen, Tickets und Dienste verwendet wird. DieAbrechnungs-Anmeldeseitepräsentiert Kontoverwaltung, Hosting, Abrechnung, Tickets und Dienstzugriff. Die öffentliche Datenschutzrichtlinie identifiziert Supportdaten, Abrechnungsdaten und Betriebsdaten als vom Anbieter verarbeitete Kategorien. Dies bedeutet, dass die Steuerungsebene eine echte Abhängigkeit ist: Wenn das Portal nicht erreichbar ist, kann ein Kunde möglicherweise nicht bezahlen, Tickets öffnen, Rechnungen abrufen, Diensteinstellungen ändern oder eine Wiederherstellung anfordern.

Die Statusseite enthält „Valex Cloud Compute Platform" als Website-Monitor, was darauf hindeutet, dass der Anbieter die Compute-Steuerungsebene als separate von der öffentlichen Marketing-Website betrachtet. Dies ist gut, da ein Kundenausfall die Plattform betreffen kann, selbst wenn bestehende VMs weiterlaufen. Ein fehlgeschlagener Zahlungsvorgang kann den Dienst aussetzen. Ein Support-Rückstand kann Reparaturfenster verlängern. Ein Konsolenausfall kann einen Kunden daran hindern, seinen eigenen Server zu diagnostizieren. Ein DNS-Steuerungsproblem kann Webhosting-Kunden beeinträchtigen, deren Ursprungsmaschinen gesund sind.

Ein Kunde, der auf Rechnungen nicht zugreifen oder bei einem Abrechnungsstreit eine Zahlung nicht nachweisen kann, kann einen Infrastrukturausfall als administratives Problem erleiden.

Die rechtlichen Dokumente machen dies konkreter. Die SLA verlangt von Kunden, Servicegutschriftsanfragen über Support-Kanäle innerhalb einer Frist einzureichen, und behandelt die Überwachung des Anbieters als maßgebliche Grundlage, es sei denn, ein Kunde kann einen Hardwarefehler nachweisen. Dies schafft eine praktische Belastung: Kunden benötigen ihre eigenen Überwachungsdaten, aber sie benötigen auch Zugang zum Ticket-System des Anbieters, um Gutschriften zu beantragen. Eine Gutschrift ist keine Wiederherstellung. Es ist eine zukünftige Rechnungsanpassung, gedeckelt und an die Vereinbarung gebunden.

Für einen Produktionskunden ist der wirtschaftliche Rechtsbehelf weitaus geringer als der operative Bedarf, Datenverkehr, Daten und Dienst wiederherzustellen.

Die Support-Zeiten verdienen Aufmerksamkeit. ARIN listet Standard-NOC-Zeiten von 7:00 bis 21:00 Uhr Pazifik. Die Marketingseiten sagen, dass Support rund um die Uhr verfügbar ist, aber die NOC-Angabe im Register ist enger. Diese Aussagen können koexistieren, wenn der First-Level-Support jederzeit verfügbar ist und die vollständige NOC-Eskalation nach einem Zeitplan erfolgt, oder wenn die ARIN-Daten vorsichtig sind. Kunden sollten den Unterschied klären. Für einen globalen Käufer kann ein Support-Fenster an der US-Westküste eine erhebliche Wiederherstellungseinschränkung sein. Für einen US-West-Kunden kann es akzeptabel sein.

Für einen europäischen oder asiatischen Kunden, der eine Spielgemeinschaft zur lokalen Abendzeit betreibt, kann dies einen kurzen Vorfall in eine nächtliche Wartezeit verwandeln.

Das sicherere Betriebsmodell ist anzunehmen, dass Valex routinemäßigen Hosting-Support und Eskalation bieten kann, aber der Kunde bleibt für unabhängige Überwachung, anbieterunabhängige Backups, dokumentierte Wiederherstellungsschritte und eine Zahlungsmethode verantwortlich, die nicht stillschweigend ausfällt. Dies ist keine Kritik, die nur Valex betrifft. Es ist der normale Kompromiss kostengünstiger gehosteter Infrastruktur: Der Anbieter senkt die Einstiegskosten und die Komplexität, während der Kunde einen größeren Anteil der Kontinuitätsplanung behält als auf einer verwalteten Premium-Plattform.

Was die offenen Fragen klären würde

Die öffentlichen Nachweise reichen aus, um die schwächste Hypothese zu widerlegen, dass Valex Cloud nur ein Name ohne Live-Betrieb ist. Sie reichen nicht aus, um die stärkste Hypothese zu beweisen, dass Valex einen Rack-, Upstream-, Hardwarebestands- oder Anbietervertragsausfall ohne sichtbare Auswirkungen auf den Kunden verkraften kann. Die fehlenden Nachweise sind spezifisch und testbar.

Erstens könnte Valex eine klarere Standort- und Regionsmatrix veröffentlichen. Die aktuelle Vertrauensseite nennt Los Angeles und Dallas, aber Kunden benötigen eine Produkt-Standort-Zuordnung. Standard-VDS, High-Speed-VDS, Extreme-VDS, Webhosting, DNS, Backups und Spieleserver teilen sich möglicherweise nicht dieselbe Platzierung oder dasselbe Failover-Verhalten. Eine einfache Tabelle, die zeigt, wo jedes Produkt laufen kann, ob Backups lokal oder entfernt sind und ob das Failover automatisch oder manuell ist, würde das Beweismaß deutlich verbessern.

Zweitens könnte Valex Netzwerkrichtlinie und Routing-Transparenz offenlegen. PeeringDB hat den Unternehmenseintrag, aber keine Austausch- oder Einrichtungseinträge. Ein öffentlicher Looking Glass, eine aktuelle Upstream-Liste, eine IRR-as-set-Richtlinie, eine RPKI/ROA-Erklärung und eine Kundenpräfix-Richtlinie würden Kunden helfen zu verstehen, ob ihr Datenverkehr von einem einzelnen Mitigationspfad abhängt oder alternative Ausgänge hat.

Das Unternehmen veröffentlicht bereits genügend rechtliche Details, um Cloudflare, Cosmic und die Upstream-Abhängigkeiten zu nennen; die Veröffentlichung operativer Netzwerkdetails würde dieser Offenheit entsprechen.

Drittens könnte das Unternehmen den Einzelhandelsbestand von der Wiederherstellungsreserve unterscheiden. Eine Produktreihe mit null verfügbaren Einheiten sagt einem bestehenden Kunden nicht, ob gleichwertige Ersatzkapazität für Ausfälle reserviert ist. Eine kurze Erklärung, ob Valex Ersatz-Hosts pro Stufe vorhält, ob ausverkaufte Reihen noch Notfallmigrationskapazität haben und welche Ersatzleistungen bei Hardwareknappheit angeboten werden, würde die wichtigste Frage der Hosting-Ökonomie direkt beantworten.

Viertens könnte Valex Wiederherstellungstests oder zumindest Wiederherstellungsziele pro Produkt veröffentlichen. Die aktuellen Bedingungen beschreiben Backups und Einschränkungen, aber Kunden benötigen operative Erwartungen. Wie lange dauert normalerweise eine Webhosting-Wiederherstellung für Pläne mit 10 GB, 50 GB oder 100 GB? Kann ein VDS-Image in Dallas wiederhergestellt werden, wenn Los Angeles ausfällt? Sind Snapshots anwendungskonsistent oder absturzkonsistent? Können Kunden Images in einem Standardformat exportieren? Repliziert sich der Objektspeicher zwischen den Einrichtungen?

Wenn die Antworten je nach Plan variieren, sollte diese Variation explizit sein.

Fünftens könnte Valox eine Vorfallhistorie führen und veröffentlichen. Die Status-API war zum überprüften Zeitpunkt still, aber der Nachweis einer ausgereiften Infrastruktur ergibt sich aus der Art und Weise, wie ein Anbieter Störungen aufzeichnet, nicht nur aus einer grünen Seite zwischen Vorfällen. Post-Incident-Notizen, Wartungshistorien und Verfügbarkeitszusammenfassungen der Monitore würden Kunden helfen, Reparaturfenster und Kommunikationsqualität zu bewerten. Ohne diese Historie müssen potenzielle Nutzer die Resilienz aus Routingdaten, Richtlinientext und Shop-Bestand ableiten.

Die praktische Käuferperspektive

Valex Cloud LLC ist als ein kleiner, aktiver Anbieter von gehosteter Kapazität mit einer bestellbaren Elysia Cloud-Produktoberfläche, aktuellen AS36744-Routing, gültiger RPKI für sichtbare Präfixe, US-zentrierten Standortoffenlegungen und einer expliziten Abhängigkeit von Cosmic- und Cloudflare-Infrastruktur zu lesen. Dies ist ein signifikanter Fußabdruck. Er ist stärker als eine ruhende ASN und stärker als eine Wiederverkäuferseite ohne Routing-Identität.

Er ist auch materiell dünner als eine Multi-Region-Cloud mit unabhängig überprüfbaren Einrichtungen, reichem Peering, öffentlichen Post-Mortems und Wiederherstellungszusagen auf Produktebene.

Für leichte Workloads kann dies ein akzeptabler Kompromiss sein. Eine kleine Website, eine Testumgebung, ein Community-Spieleserver oder eine nicht kritische Anwendung kann geringe Reibung und Hardware pro Dollar mehr schätzen als formelles Failover. Für Produktionsworkloads sollte der Käufer Valex als Komponente in einem breiteren Kontinuitätsplan behandeln. Pflegen Sie anbieterunabhängige Backups. Testen Sie Wiederherstellungen. Führen Sie externe Überwachung durch. Halten Sie DNS portabel. Vermeiden Sie anbieterspezifische Images, soweit möglich. Bestätigen Sie, ob ein ausgewähltes Produkt in Los Angeles, Dallas oder beiden ist.

Fragen Sie, wie viele gleichwertige Ersatzknoten existieren. Fragen Sie, ob die High-Speed- und Extreme-Stufen bei einem Host-Ausfall ersetzt werden können. Fragen Sie, was passiert, wenn Cloudflare Magic Transit, Cosmic Guard oder ein Upstream-Pfad beeinträchtigt ist.

Das Beweismaß ist daher Mittel. Das Unternehmen hat einen Live-Dienst, einen Live-Route-Ursprung, sichtbare Präfixe, RPKI-Validierung, eine Statusseite, Abrechnungsreihen und substanzielle Richtliniendokumente. Der Nachteil ist ebenso konkret: Die öffentliche Live-Grenze ist klein; AS19468 ist veraltet; PeeringDB bestätigt keine Einrichtungen oder Austauschpräsenz; Produktreihen zeigen Kapazitätseinschränkungen in mehreren Hochleistungskategorien; und öffentliche Quellen belegen kein getestetes Multi-Site-Failover, keine Ersatzhardware, keine Speicherunabhängigkeit, keine Support-Eskalation oder Ergebnisse der Kundenmigration.

Valex Cloud kann gehostete Kapazität verkaufen. Die Aufgabe des Kunden ist es zu überprüfen, ob diese Kapazität wiederherstellbar ist, wenn das Rack, der Upstream, der Hardwarebestand oder der Support-Pfad unter Druck gerät.