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

Zusammenfassung

• Valex Cloud LLC hat glaubwürdige Belege für den aktuellen Betrieb unter dem Namen Elysia Cloud: einen aktiven Einzelhandelskatalog, eine öffentliche Statusseite, ARIN-Registrierung 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 Betriebsoberfläche ist klein. RIPEstat zeigt, dass AS36744 am 12.07.2026 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 wurde; PeeringDB listet keine Austausch- oder Standortaufzeichnungen für das Netzwerk.
• Valex's eigene Dokumente machen die Lieferantengrenze explizit: seine Unterauftragsnehmerliste nennt Cosmic Global für Rechenzentrums-, Compute-, Speicher- und Netzwerkinfrastruktur und nennt Cloudflare Magic Transit plus Cosmic Guard Enterprise für DDoS-Mitigation.
• Das wichtigste Kundenrisiko ist nicht, ob die Marke existiert. Es ist, ob eine bestimmte Arbeitslast ein Standortereignis in Los Angeles oder Dallas, eine Upstream- oder Mitigationsänderung, ein leeres Hardware-Regal, einen Ausfall der Abrechnung oder der Steuerungsebene oder eine Migrationsfrist überstehen kann.
• Der Beweisgrad ist Mittel für einen kleinen lebenden Hosting-Kapazitätsanbieter, aber nicht Stark, da öffentliche Quellen keinen getesteten Multi-Site-Failover, keine Tiefe der Ersatzhardware, keine unabhängigen Standortbetreiberpfade, keine Wiederherstellungsleistung und keine Ergebnisse zur Kundenportabilität nachweisen.

Ein kleiner Cloud-Anbieter mit sichtbarer Kante

Valex Cloud LLC ist für Kunden hauptsächlich durch die Marke Elysia Cloud sichtbar. Die eigene Homepage beschreibt das Angebot als Hosting für Websites, virtuelle dedizierte Server und Spieleserver mit NVMe-Speicher, DDoS-Schutz und Support; dieÜber-uns-Seitestellt das Unternehmen als leistungsorientierten Hosting-Anbieter dar, der aus der Nachfrage nach Spieleservern entstand und auf breitere Cloud- und VDS-Dienste ausgeweitet wurde. Das Unternehmen betreibt außerdem ein separates Abrechnungsportal unterbilling.elysiacloud.comund eine öffentliche Statusseite unterstatus.valexcloud.com. Das ist bereits mehr öffentliche Oberfläche als viele dünne Verzeichniskarten: Interessenten können Produktregale, Bestellbuttons, Richtliniendokumente, einen Kundenlogin, Netzwerkkennungen und Dienstmonitore sehen.

Die Frage ist, was diese öffentliche Oberfläche beweist. Sie beweist, dass Valex gehostete Kapazität verkauft. Sie beweist jedoch nicht von selbst, wie viel Kapazität installiert ist, wie viel davon Reserve ist, wie viele Racks unter direkter Kontrolle sind, ob ein Kunde in ein anderes Gebäude wiederhergestellt werden kann oder ob eine Routenunterbrechung auf ein Produktregal isoliert oder über das gesamte Anwesen verteilt wäre. Für einen kleinen Anbieter sind diese Unterschiede wichtiger als die Slogans. Ein VDS-Tarif ist nicht nur eine Position in einem Warenkorb.

Es ist ein Teil von CPU, RAM, Speicher, Paketverarbeitung, Strom, Kühlung und Support-Aufmerksamkeit, die alle bei einem Ausfall gleichzeitig knapp werden können.

Der Netzwerkeintrag bestätigt aktuelle Aktivität. ARIN listetAS36744als ELYSIA, mit der Organisation Elysia Cloud in Chino Hills, Kalifornien, und standardmäßigen NOC-Geschäftszeiten von 7:00 bis 21:00 Uhr Pazifikzeit. ARIN listet auchAS19468als ELYSIA-2 für dieselbe Organisation. Die Unterscheidung zwischen beiden ist wichtig, weil öffentliche Routensammler sie nicht im gleichen Zustand zeigen. RIPEstatsAS36744-Übersichtmeldete die ASN am 12.07.2026 als angekündigt, während dieAS19468-Übersichtdie ältere oder sekundäre ASN zum gleichen Abfragezeitpunkt als nicht angekündigt meldete. BGP Hurricane ElectricsAS19468-Seitefügt eine nützliche historische Warnung hinzu, indem sie die ASN seit dem 15.07.2025 als nicht in der globalen Routingtabelle sichtbar markiert.

Für Kunden bedeutet dies, dass die aktive Internetkante über AS36744 abgelesen werden sollte, nicht über jede Valex-assoziierte ASN, die in der Registry-Historie erscheint. RIPEstatsAnsicht der angekündigten Präfixe für AS36744zeigte zwei sichtbare Ressourcen im untersuchten Zeitfenster: 23.134.124.0/24 und 2602:f76f::/44. Der ARIN-Eintrag für23.134.124.0/24nennt ELYSIA-NET-1 und Elysia Cloud. RIPEstatsIPv4-Präfix-ÜbersichtundIPv6-Präfix-Übersichtidentifizieren beide AS36744 als aktuellen Ursprung. Das verleiht dem Unternehmen einen echten, öffentlichen, aktuellen Routing-Fußabdruck, jedoch einen kompakten.

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 nutzt, anstatt ein nationales Backbone aufzubauen. Es schränkt jedoch ein, was allein aus dem Routing geschlossen werden kann. Ein einzelnes IPv4 /24 bedeutet nur 256 IPv4-Adressen, bevor NAT, private Adressierung, Shared Hosting und zusätzlicher vom Upstream bereitgestellter Raum berücksichtigt werden.

Ein einzelnes sichtbares IPv6-Aggregat sagt, dass der Anbieter IPv6-Erreichbarkeit veröffentlichen kann, aber nicht, wie breit Kunden standardmäßig natives IPv6 erhalten, wie IPv6 in der Mitigation gefiltert wird oder ob jede Produktstufe gleichwertigen Support hat. Deshalb sollte die öffentliche Routingtabelle als Beweis einer Kante behandelt werden, nicht als Beweis tiefer Kapazität.

Der Produktkatalog trennt Einzelhandelsversprechen von verfügbarem Bestand

Der Elysia-Katalog ist für einen kleinen Anbieter breit. DieVDS-Produktseitebewirbt dedizierte vCPU-Ressourcen, vollständigen Administratorzugriff, NVMe-Speicher, DDoS-Schutz, 10-Gbit/s-Netzwerk und eine Verfügbarkeitsgarantie von 99,99 %. Das Abrechnungs-Shopfrontend unterteilt dies dann in Produktfamilien. DasStandard-Cloud-VDS-Regalbot 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. DasHigh-Speed-VDS-Regalverwendete Ryzen-7- und Ryzen-9-Sprache, aber die überprüfte Seite zeigte jedes aufgeführte Paket mit „0 Verfügbar“. DasExtreme-VDS-Regalbewarb Ryzen-9950X-Kapazität und Bestellbuttons auf einer ähnlichen Paketleiter.

Diese Mischung ist der beste öffentliche Hinweis auf installierte versus nutzbare Kapazität. Die Website kann sagen, dass ein Anbieter High-Speed-Compute hat; der Warenkorb kann dennoch keine Einheiten für ein bestimmtes Regal anzeigen. Die genaue Bestandszahl kann sich schnell ändern, und ein öffentliches Shopfrontend zeigt möglicherweise nicht alle internen Reservierungspools an, aber ein sichtbares „0 Verfügbar“ auf jeder High-Speed-VDS-Stufe ist ein Signal, dass die Kapazität begrenzt oder bewusst eingeschränkt ist. Kunden, die dringend Ersatzkapazität suchen, sollten die Produktseite nicht als Reservierung betrachten.

Sie sollten die Bestellbarkeit prüfen, fragen, ob der gewünschte Knotentyp in mehr als einer Einrichtung existiert, und bestätigen, ob ein ausgefallener Host durch dieselbe CPU-Klasse oder nur durch eine andere Stufe ersetzt werden kann.

Das Webhosting-Regal weist auf ein anderes Muster hin. DieWebhosting-Seitedes Anbieters betont cPanel-ähnliches Hosting mit NVMe-Speicher, SSL und Backups. DerWebhosting-Shoplistete Pläne mit 10 GB, 25 GB, 50 GB und 100 GB NVMe-Zuweisungen und Bestellbuttons auf. Das ist ein eher konventionelles Shared-Hosting-Kapazitätsmodell: Viele kleinere Kunden hängen weniger von einem einzelnen dedizierten Host ab als von Nameservern, dem Hosting-Control-Panel, gemeinsam genutztem Speicher, Mail-Reputation, Backup-Jobs und Personalverfügbarkeit. Ein Ausfall im Webhosting kann sich daher betrieblich von einem VDS-Ausfall unterscheiden. Er kann nicht nur eine VM mit hohem Arbeitsspeicher lahmlegen, sondern viele kleinere Websites hinter DNS, cPanel, SSL-Erneuerung und gemeinsam genutzter Mail-Verarbeitung.

Spielhosting fügt eine dritte Nachfrageform hinzu. Die Spieleseiten von Elysia bewerben Minecraft-, Terraria- und Hytale-Hosting, während die Abrechnungsregale inBudget-Spieleserver,Standard-SpieleserverundPremium-Spieleserverunterteilt sind. Das überprüfte Standard-Spieleserver-Regal zeigte nur eine aufgeführte Stufe mit einer verfügbaren Einheit, während mehrere andere Stufen null verfügbar anzeigten. Die Nachfrage nach Spieleservern ist stoßartig und latenzempfindlich. Ein Knoten, der für eine kleine Gemeinschaft im Leerlauf akzeptabel ist, kann während abendlicher Spitzenzeiten, Modpack-Updates, DDoS-Angriffen auf öffentliche Communities oder turnierartigen Veranstaltungen inakzeptabel werden. Wenn Valex dieselben physischen Pools für Spieleserver und VDS-Produkte verwendet, kann der Bestandsdruck in einem Regal den Kunden etwas über das gesamte Rack verraten, auch wenn das Abrechnungsportal die Produktlinien getrennt behandelt.

Dies ist der entscheidende wirtschaftliche Punkt: Ein Billiganbieter von Hosting-Kapazität verkauft ein Versprechen, das einfacher zu bestellen als wiederherzustellen ist. Das beworbene Paket ist statisch. Das wiederherstellbare Paket hängt von freiem RAM, freier NVMe-Kapazität, freien IP-Adressen, verfügbarem Mitigationsdurchsatz, funktionierender Automatisierung, Personalreaktionszeit und der Fähigkeit ab, einen Kunden zu verschieben, ohne dessen eigene Lizenzierungs- oder Datenresidenzbeschränkungen zu verletzen.

Valex veröffentlicht genug, um als Betreiber ernst genommen zu werden, aber nicht genug, damit ein Kunde davon ausgehen 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 Vertrauensmaterial ist ungewöhnlich genau in Bezug auf die Standortgeografie. Die öffentlicheSicherheits- und Vertrauensseiteidentifiziert eine primäre Einrichtung in Los Angeles, Kalifornien, die als anbietereigen beschrieben wird, und eine sekundäre Einrichtung in Dallas, Texas, die als Colocation mit Cosmic Global, Inc. beschrieben wird. Beide werden als Tier-III-Einrichtungen charakterisiert. DieUnterauftragsnehmerlistenennt separat Cosmic Global, Inc. für Rechenzentrumshosting, Compute, Speicher und Netzwerkinfrastruktur in den Vereinigten Staaten. Diese Offenlegungen sind wertvoll, weil 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 anbietereigene Einrichtung in Los Angeles kann alles bedeuten, von einem substanziell unabhängig betriebenen Standort bis zu einem kleinen Raum oder einem kontrollierten Käfig in einer breiteren Einrichtungsvereinbarung, je nachdem, wie der Begriff im Kontext verwendet wird. Eine Dallas-Colocation-Abhängigkeit ist klarer: Cosmic Global ist ein externer Betreiber oder Infrastrukturanbieter für zumindest einige Compute-, Speicher- und Netzwerkinfrastrukturen.

Die hier geprüften öffentlichen Quellen zeigen keine Rack-Zahlen, Cabinet-Stromdichten, Generatorlaufzeiten, Kühltopologie, Cross-Connect-Bestände, Speichercluster-Layout, Live-Auslastung, Ersatz-Knoten-Bestand oder getestete Failover-Übungen zwischen Los Angeles und Dallas. Sie zeigen auch nicht, ob Kundendienste automatisch über beide Standorte verteilt werden oder ob ein Standort für ausgewählte Produkte, Backups, Mitigation, Überlauf oder zukünftige Erweiterungen genutzt wird.

PeeringDB verstärkt diese Vorsicht. DerPeeringDB-Eintrag für AS36744identifiziert Valex Cloud LLC, auch bekannt als Elysia Cloud, als globales Netzwerk mit IPv6-Unterstützung und 5-10 Gbit/s Verkehr, listet aber null Austausch- und null Standorteinträge. PeeringDB wird benutzergepflegt und ist unvollständig, daher beweist das Fehlen von Standorteinträ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 unterhält oder ob es unabhängige Zugangspunkte hat. Wenn das eigene Whitepaper eines Anbieters besagt, dass es Einrichtungen gibt, und PeeringDB keine externe Standortbestätigung liefert, ist die vernünftige Lesart: Standortangaben sind plausibel und vom Unternehmen veröffentlicht, aber die Rack-Unabhängigkeit bleibt unbestätigt.

Das ist während eines Standortereignisses wichtig. Wenn der Standort in Los Angeles Strom, Kühlung, Zugang oder Upstream-Übergabe verliert, müssen Kunden wissen, ob ihre VDS in Dallas booten kann, ob Speicher repliziert wird, ob IP-Adressen vom anderen Standort neu angekündigt werden können, ob DNS und Control-Plane-Dienste erreichbar bleiben und ob Support-Mitarbeiter Fernzugriff haben. Dieselbe Frage gilt umgekehrt für Dallas. Ein sekundärer Standort ist nicht automatisch ein Failover-Standort.

Es kann ein Backup-Standort, ein Überlauf-Standort, ein anderer Produktpool oder eine vertragliche Einrichtung sein, die nur einen Teil des Anwesens beherbergt. Das Risiko des Kunden hängt von der tatsächlichen Platzierung des Volumens, des Images, der DNS-Zone, der IP-Adresse und des Backups dieses Kunden ab.

Die AGB des Unternehmens machen diesen Punkt deutlicher als eine Marketingseite. Seine SLA und AGB beschreiben Verfügbarkeitsgutschriften, Ausschlüsse, Wartung, Grenzen von Drittanbieterdiensten und Kundenverantwortlichkeiten, verwandeln jedoch kein allgemeines Verfügbarkeitsziel in eine Notfallwiederherstellungsgarantie. Die öffentlichen AGB legen die Planung von Backups und Notfallwiederherstellung stark in die Hände des Kunden. Das ist beim Hosting nicht ungewöhnlich. Es ist jedoch eine direkte Warnung davor, die Zwei-Standort-Aussage des Anbieters als Ersatz für eine kundenseitige Replikation und getestete Wiederherstellung zu behandeln.

Der Transitpfad hängt von Cloudflare, Cosmic und mindestens einem benachbarten Rohstoff-Cloud-Anbieter ab

Routing-Daten geben den klarsten Einblick in Valex‘ öffentliche Netzwerkabhängigkeiten. RIPEstatsAS-Nachbarn-Ansichtmeldete zum überprüften Zeitpunkt drei linke Nachbarn für AS36744: AS13335, AS20473 und AS30456. RIPEstat identifiziertAS13335als Cloudflare,AS20473als The Constant Company, besser bekannt durch Vultrs Netzwerk, undAS30456als Cosmic Global Networks. CAIDAsAS36744-Ansichtmarkiert das Netzwerk ebenfalls als gesehen, mit zwei Anbietern und einem sehr kleinen Cone. Das ist eine von Upstream abhängige Kante, kein dichtes Peering-Gewebe.

Die unternehmenseigene Unterauftragsnehmerliste passt zur Routingtabelle. Sie nennt Cloudflare Magic Transit und Cosmic Guard Enterprise für DDoS-Mitigation und listet Cosmic Global und Cloudflare als Upstream-Transitanbieter. Das Abrechnungs-Shopfrontend wiederholt, dass Cloudflare Magic Transit und Cosmic Guard Enterprise den Anti-DDoS-Schutz auf mehreren Produktregalen antreiben. Praktisch gesehen sollten Kunden Valex‘ DDoS- und Routenresilienz als verwaltetes 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 Datenverkehr transportieren oder filtern.

Das ist an sich kein Makel. Kleine Hosting-Anbieter kaufen oft Transit-, DDoS-Scrubbing- und Einrichtungsdienste, weil es in ihrer Größenordnung irrational wäre, sie zu besitzen. Das Risiko liegt im Abhängigkeitsstapel. Wenn eine DDoS-Mitigationsrichtlinie Spielverkehr falsch klassifiziert, kann ein Kunde selbst bei gesundem Ursprungsserver Latenz oder Paketverlust sehen. 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 erleben, den der Anbieter im Rahmen der SLA-Ausschlüsse anders einstuft.

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

RIPEstat- und RPKI-Belege sind positiv für den aktuellen Ursprung. DerRouting-Status für 23.134.124.0/24zeigte das Präfix zuletzt von AS36744 am 12.07.2026 mit voller IPv4-RIS-Peer-Sichtbarkeit. 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 für AS36744 gültig, und dasRPKI-Validierungsergebnis für 2602:f76f::/44validierte ebenfalls den aktuellen AS36744-Ursprung. Diese Routensicherheitsnachweise sind deutlich besser als eine nicht registrierte oder ungeschützte Kante.

Aber dieselben Aufzeichnungen zeigen, warum Kunden nach Änderungskontrolle fragen sollten. RIPEstats Routing-Status-Verlauf zeigt beide sichtbaren Präfixe zuerst von AS19468 gesehen, bevor sie später von AS36744 gesehen wurden. BGP Hurricane ElectricsAS36744-Seitemeldet derzeit zwei stammende Präfixe, während seine AS19468-Seite veraltet ist. Die Migration zwischen ASNs kann normale Hausarbeit sein, aber Kunden benötigen Klarheit darüber, welche ASN in Produktion ist, welche Präfixe portabel sind und was passiert, wenn Valex erneut Upstreams oder die ASN-Richtlinie ändert. RPKI-valider Ursprung ist eine Grundlage. Er ist keine vollständige Antwort auf Konvergenz-, Wartungs- oder Mitigationsverhalten.

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

Die Zuordnungskategorie ist global, weil der Dienst über das Internet bestellt werden kann und der PeeringDB-Eintrag einen globalen Umfang verwendet. Die physischen und rechtlichen Belege weisen jedoch hauptsächlich auf die Vereinigten Staaten hin. Die Sicherheits- und Vertrauensseite nennt Los Angeles und Dallas. ARIN-Aufzeichnungen lokalisieren die Organisation in Kalifornien. Die Unterauftragsnehmerliste platziert Infrastruktur-, Zahlungs- und Mitigations-Unterauftragsnehmer in den Vereinigten Staaten.

Die Datenschutz- und DPA-Seiten beschreiben grenzüberschreitende Übermittlungsmechanismen und das Verhalten bei Datenresidenz, aber das hier geprüfte öffentliche Material belegt keine Produktionseinrichtung in Europa, Asien oder Lateinamerika für Kundenarbeitslasten.

Die Unterscheidung ist wichtig für die Datensouveränität. Ein Kunde außerhalb der Vereinigten Staaten kann einen global wirkenden Hosting-Dienst kaufen und dennoch Kundendaten auf US-Infrastruktur, über US-Unterauftragsnehmer, mit US-Recht und vertraglichen Übermittlungsmechanismen platzieren, die Zugriff und Offenlegung prägen. DasDatenverarbeitungs-Anhängselbesagt, dass die Verarbeitung Hosting, Speicherung, Compute, Übertragung, Backup und Notfallwiederherstellung von Kundeninhalten umfassen kann, und gewährt Kunden eine 30-tägige Abruffrist nach Kündigung, gefolgt von einer Löschfrist. DieDatenschutzrichtliniebehandelt Konto-, Abrechnungs-, Support-, Betriebs- und Sicherheitsdaten, einschließlich Infrastrukturtelemetrie und Support-Kommunikation. Dies sind nicht nur Compliance-Texte. Sie definieren, wohin die betrieblichen Abgase eines Kunden während des normalen Dienstes, Supports und der Incident-Response gelangen können.

Valex‘ AGB besagen, dass Kundendaten im Ruhezustand in der ausgewählten Region gespeichert werden, vorbehaltlich Ausnahmen, wenn der 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 geprüften öffentlichen Shop-Seiten werden von US-West-Sprache und US-orientierten Infrastrukturoffenlegungen dominiert. Die Statusseite überwacht „US West Standard Compute“ und „US West High Speed Compute“. Diese Status-Taxonomie deutet auf mindestens eine Betriebsregion hin, belegt aber kein breites regionales Menü.

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

Hier unterscheidet sich gehostete Kapazität von Software-as-a-Service. Ein SaaS-Kunde kann sich auf Anwendungsdaten und Benutzerkonten konzentrieren. Ein VDS- oder Spieleserver-Kunde muss über Blockgeräte, VM-Images, IP-Adressen, DNS-Einträge, Backups, Konsolenzugriff, SSH-Schlüssel, Missbrauchstickets und Zahlungsaufzeichnungen nachdenken. Wenn Valex‘ Standort in Dallas für Backups genutzt wird, kann das 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 eigene Bandbreite, Migrationssysteme und der alternative Host bereit sein, bevor die Uhr zu ticken beginnt.

Die öffentliche Evidenz stützt daher das Thema „Datensouveränität und -lokalität“ mit einer spezifischen Schlussfolgerung: Valex bietet genug Offenlegung, um US-zentrierte Abhängigkeiten zu identifizieren, aber nicht genug für einen regulierten Kunden, um die Lokalität ohne schriftliche Bestellung oder Support-Bestätigung als geklärt zu betrachten. Die wichtigsten Fragen sind nicht abstrakt. Welche Einrichtung wird die Arbeitslast hosten? Können Backups diese Einrichtung verlassen? Werden Snapshots nach Dallas repliziert? Können Support-Mitarbeiter von außerhalb der gewählten Region auf Kundendaten zugreifen?

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

Die Statusseite sagt Kunden, was Valex für überwachbar hält

Die öffentlicheStatusseiten-APIist klein, aber aufschlussreich. Sie gruppiert Monitore in Websites, Cloud-Compute-Dienste und DNS. Die Website-Gruppe umfasst die Valex-Cloud-Website und die Valex-Cloud-Compute-Plattform. Die Compute-Gruppe umfasst US West Standard Compute und US West High Speed Compute. Die DNS-Gruppe umfasst Webhosting-DNS 1 und Webhosting-DNS 2. Zum überprüften Zeitpunkt listete die öffentliche API keinen aktiven Vorfall und keinen Wartungseintrag.

Statusseiten sind keine umfassenden Fehlerdetektoren. Sie zeigen, was ein Anbieter offenlegen möchte, nicht jede interne Abhängigkeit. Dennoch ist die Valex-Status-Taxonomie wichtig. Sie besagt, dass der Anbieter die öffentliche Website von der Compute-Plattform unterscheidet, Standard-Compute von 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 der gleiche Fehlerpfad. DNS kann ausfallen, während Compute lä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 Betriebssprache „US West“. „US West Standard Compute“ und „US West High Speed Compute“ sind engere Bezeichnungen als „globale Cloud“. Sie implizieren, dass das sichtbarste Compute-Anwesen regional gerahmt ist. Wenn ein Kunde niedrige Latenz aus Europa oder Asien erwartet, belegt das öffentliche Material keine lokale Region. Wenn ein Kunde Standort-Failover innerhalb derselben Gerichtsbarkeit erwartet, zeigt die Statusseite dies nicht.

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

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

Die Existenz einer Statusseite ist dennoch ein positiver Beleg. Viele kleine Hosts bieten nur eine Support-Adresse. Valex gibt Kunden eine öffentliche Oberfläche für den Plattformstatus, und seine rechtlichen AGB beschreiben Support-Ticket-Kanäle für SLA-Gutschriftsanfragen. Das ist eine bessere Position als Schweigen. Der Nachteil ist, dass die Statusseite keinen Ersatz für einen kundeneigenen Monitor aus der eigenen Geografie und Arbeitslastperspektive darstellt.

Ein Ping zu einem Compute-Knoten beweist nicht, dass die Taktfrequenz 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 ehesten spüren

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

Die „0 Verfügbar“-Signale des Shopfrontends für High-Speed-VDS und die meisten Standard-Spieleserver-Stufen sind daher nicht nur Verkaufsnebensächlichkeiten. Sie sind Hinweise darauf, wie knapp das physische Regal sein könnte.

Die AGB erkennen dies in allgemeiner Form an. Die Dedicated-Server-Sprache in den öffentlichen AGB besagt, dass die Behebung von Hardwarefehlern von Ersatzteilen, Komplexität und physischer Zugänglichkeit der Rechenzentrumseinrichtung abhängt. Backup-Bedingungen besagen, dass Wiederherstellungszeiten von Datengröße, Zielressource, Rechenzentrumsauslastung, Netzwerkbedingungen und Speicherdurchsatz abhängen. Das sind gewöhnliche Einschränkungen, aber genau hier werden Ausfälle kleiner Anbieter schmerzhaft. Ein Kunde fällt nicht in einen abstrakten Dienst aus.

Er fällt auf verfügbaren Speicher, verfügbaren RAM, eine Ersatz-IP, eine Routenankündigung und einen Ingenieur oder einen Remote-Hands-Prozess, der die Reparatur durchführen kann.

Es gibt mehrere praktische Fehlerabläufe 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 verifiziert? Drittens ein Zugangsereignis zur Einrichtung: Kann die Ersatzarbeit fortgesetzt werden, wenn Mitarbeiter den primären Standort nicht betreten können?

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

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

Für eine Spielgemeinschaft kann ein Weltspeicherstand, der während eines Schreibvorgangs aufgenommen wurde, einen Rollback oder eine Beschädigung des Zustands verursachen. Für einen VDS-Kunden kann ein Block-Snapshot keine externen DNS, Firewall-Regeln, API-Schlüssel oder Drittanbieterlizenzen enthalten. Das Ergebnis ist ein Hosting-Kapazitätsgeschäft, bei dem der Kunde nicht nur die Verfügbarkeit, sondern auch die Wiederherstellungssemantik testen muss.

Die Kundengruppe, die diesem Fehlerpfad am meisten ausgesetzt ist, ist diejenige, die Valex als einzigen Infrastrukturanbieter nutzt. Ein Hobby-Spieleserver kann einen Wiederaufbau tolerieren. Eine kleine Unternehmenswebsite möglicherweise nicht. Ein SaaS-Startup, das einen Budget-VDS für die Produktion verwendet, sollte davon ausgehen, dass die Redundanz auf Anbieterseite nicht dasselbe ist wie ein Geschäftskontinuitätsplan. Es sollte anbieterunabhängige Backups unterhalten, wissen, wie DNS woanders wiederhergestellt wird, und vermeiden, sich auf ein einzelnes anbieterspezifisches Image-Format zu verlassen.

Valex mag für viele Arbeitslasten ein rationaler Billiganbieter sein, aber je wichtiger die Arbeitslast, desto weniger akzeptabel ist es, den gesamten Wiederherstellungspfad an eine öffentliche SLA-Gutschrift auszulagern.

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

Der zweite Hauptfehlerpfad ist der Upstream- oder Mitigationsausfall. Da Valex‘ Kante Cloudflare, Cosmic und mindestens einen weiteren beobachteten Nachbarn nutzt, kann der Kunde die Erreichbarkeit verlieren, selbst wenn Ursprungsserver und Speicher gesund sind. DDoS-Mitigation kann Datenverkehr drosseln oder 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 Paketverlust sieht.

Öffentliche Routensammler sind hervorragend geeignet, Makro-Erreichbarkeit nachzuweisen, aber sie können die Kundenerfahrung aus jedem Zugangsnetzwerk nicht garantieren.

Valex‘ Position zur Routensicherheit ist ein positiver Ausgangspunkt. Die aktuelle RPKI-Validierung für AS36744 auf beiden sichtbaren Präfixen verringert das Risiko, dass Routenlecks oder nicht autorisierte Ursprünge von Netzwerken akzeptiert werden, die RPKI durchsetzen. DieRIPEstat-Sichtbarkeitsdaten für 23.134.124.0/24zeigten am 12.07.2026 breite IPv4-Sammler-Sichtbarkeit, und dieSichtbarkeitsdaten für 2602:f76f::/44zeigten breite IPv6-Sichtbarkeit mit einem aufgeführten nicht sehenden Full-Table-Peer in den Stichprobenergebnissen. BGP Hurricane Electric meldet ebenfalls, dass die von AS36744 stammenden Präfixe RPKI-gültig sind. Für einen kleinen Host ist das eine bedeutende Basislinie.

Die Einschränkung ist die Vielfalt. RIPEstat zählte drei beobachtete Nachbarn, während CAIDA AS36744 mit einem Zwei-Anbieter-Grad und einem Ein-Präfix-Cone meldete. PeeringDB listete keine Austausche. Das bedeutet, dass Kunden nicht von dichter Routenoptionalität ausgehen sollten. Wenn Cloudflare der Hauptmitigationspfad für kundenorientierten Verkehr ist und Cosmic sowohl Rechenzentrums- oder Colocation-Partner als auch Upstream-/Migrationspartner ist, kann ein Cosmic- oder Cloudflare-Richtlinienereignis mehr als ein einzelnes Lieferantenproblem sein.

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

Kunden sollten Valex mehrere routenspezifische 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 gelten? Kann Valex Kundenraum sowohl von Los Angeles als auch von Dallas aus ankündigen? Sind DDoS-geschützte Pfade immer über Cloudflare und Cosmic Guard, oder wählt der Kunde? Misst die SLA die Erreichbarkeit über Anbietermonitore oder über verschiedene externe Sonden? Wie werden Routenänderungen kommuniziert?

Gibt es ein 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 kümmert sich möglicherweise weniger um den rohen AS-Pfad als um cPanel, E-Mail und Website-Verfügbarkeit. Eine latenzempfindliche Spielgemeinschaft kümmert sich möglicherweise intensiv um mitigationsinduzierte Jitter. Ein VDS-Kunde, der APIs betreibt, kümmert sich möglicherweise um stabile Egress-Reputation und Kunden-IP-Kontinuität. Aus diesem Grund sollte Valex‘ gehostete Kapazität nach Arbeitslast beurteilt werden, nicht nach einem einzigen Etikett wie Cloud, Hosting oder Spieleserver.

Abrechnung, Support und Ausfall der Steuerungsebene können zu Infrastrukturausfällen werden

Kleine Infrastrukturanbieter lassen Kunden oft über die Steuerungsebene im Stich, bevor die Server ausfallen. Valex‘ Abrechnungsportal ist ein WHMCS-ähnliches Kundensystem, das für Bestellung, Login, 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. Das 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 beantragen.

Die Statusseite enthält „Valex Cloud Compute Platform“ als Website-Monitor, was darauf hindeutet, dass der Anbieter die Compute-Steuerungsebene als getrennt von der öffentlichen Marketing-Website betrachtet. Das ist gut, denn ein Kundenausfall kann die Plattform betreffen, selbst wenn vorhandene VMs weiterlaufen. Ein Zahlungsausfall 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 treffen, deren Ursprungsmaschinen gesund sind.

Ein Kunde, der während eines Abrechnungsstreits nicht auf Rechnungen zugreifen oder eine Zahlung nachweisen kann, kann Infrastrukturverfügbarkeit als administratives Problem erleben.

Die rechtlichen Dokumente machen dies konkreter. Die SLA verlangt, dass Kunden Service-Gutschriftsanfragen über Support-Kanäle innerhalb einer Frist einreichen, und behandelt die Überwachung durch den Anbieter als maßgeblich, sofern der Kunde keinen wesentlichen Fehler nachweisen kann. Das schafft eine praktische Belastung: Kunden benötigen ihre eigenen Überwachungsdaten, aber sie benötigen auch Zugang zum Ticketsystem des Anbieters, um Gutschriften zu beantragen. Eine Gutschrift ist keine Wiederherstellung. Es ist eine zukünftige Rechnungsanpassung, die durch die Vereinbarung gedeckelt und konditioniert ist.

Für einen Produktionskunden ist die wirtschaftliche Abhilfe weitaus schwächer als der betriebliche Bedarf, Verkehr, Daten und Dienst zurückzubekommen.

Die Supportzeiten verdienen Aufmerksamkeit. ARIN listet standardmäßige NOC-Geschäftszeiten als 7:00 bis 21:00 Uhr Pazifikzeit. Die Marketingseiten sagen, dass Support rund um die Uhr verfügbar ist, aber die Registry-NOC-Angabe ist enger. Diese Aussagen können koexistieren, wenn Frontline-Support jederzeit verfügbar ist und die vollständige NOC-Eskalation einem Zeitplan folgt, oder wenn die ARIN-Daten konservativ sind. Kunden sollten den Unterschied klären. Für einen globalen Käufer kann ein Support-Fenster in der Pazifikzeit eine bedeutende Wiederherstellungseinschränkung sein. Für einen Kunden an der US-Westküste mag es akzeptabel sein.

Für einen europäischen oder asiatischen Kunden, der eine Spielgemeinschaft zur lokalen abendlichen Spitzenzeit betreibt, kann es 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. Das ist keine Kritik, die nur Valex betrifft. Es ist der normale Deal kostengünstiger gehosteter Infrastruktur: Der Anbieter senkt Einstiegskosten und Komplexität, während der Kunde einen größeren Anteil der Kontinuitätstechnik behält, als er es bei einer Premium-Managed-Plattform tun würde.

Was die offenen Fragen klären würde

Die öffentliche Evidenz reicht aus, um die schwächste Hypothese zu verwerfen, dass Valex Cloud nur ein Name ohne aktiven Betriebsfußabdruck ist. Sie reicht nicht aus, um die stärkste Hypothese zu beweisen, dass Valex einen Rack-, Upstream-, Hardwarebestands- oder Anbietervertragsausfall ohne kundensichtbare Auswirkungen absorbieren kann. Die fehlende Evidenz ist spezifisch und testbar.

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

Zweitens könnte Valex Netzwerkrichtlinie und Routentransparenz offenlegen. PeeringDB hat den Unternehmenseintrag, aber keine Austausch- oder Standorteinträge. Ein öffentliches Looking Glass, eine aktuelle Upstream-Liste, IRR-as-set-Richtlinie, RPKI/ROA-Erklärung und Kundenpräfix-Richtlinie würden Kunden helfen zu verstehen, ob ihr Verkehr von einem Mitigationspfad abhängt oder alternative Ausgänge hat. Das Unternehmen veröffentlicht bereits genügend rechtliche Details, um Cloudflare, Cosmic und Upstream-Abhängigkeiten zu nennen; die Veröffentlichung betrieblicher Netzwerkdetails würde dieser Offenheit entsprechen.

Drittens könnte das Unternehmen zwischen Einzelhandelsbestand und Wiederherstellungsreserve unterscheiden. Ein Produktregal 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 unterhält, ob ausverkaufte Regale 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 AGB beschreiben Backups und Einschränkungen, aber Kunden benötigen betriebliche Erwartungen. Wie lange dauert eine Webhosting-Wiederherstellung normalerweise für 10-GB-, 50-GB- oder 100-GB-Pläne? 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 der Objektspeicher über Einrichtungen hinweg?

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

Fünftens könnte Valox die Vorfallhistorie aufbewahren und veröffentlichen. Die Status-API war zum überprüften Zeitpunkt ruhig, aber reife Infrastrukturnachweise stammen davon, wie ein Anbieter Störungen aufzeichnet, nicht nur von einer grünen Seite zwischen Vorfällen. Post-Incident-Notizen, Wartungshistorien und Monitor-Verfügbarkeitszusammenfassungen würden Kunden helfen, Reparaturfenster und Kommunikationsqualität zu bewerten. Ohne diese Geschichte müssen potenzielle Benutzer Resilienz aus Routingdaten, Richtlinientext und Shopfrontend-Bestand ableiten.

Die praktische Lesart für den Käufer

Valex Cloud LLC sollte als kleiner lebender Hosting-Kapazitätsanbieter mit einer bestellbaren Elysia-Cloud-Produktoberfläche, aktuellem AS36744-Routing, gültiger RPKI für sichtbare Präfixe, US-zentrierten Einrichtungsoffenlegungen und expliziter Abhängigkeit von Cosmic- und Cloudflare-bezogener Infrastruktur gelesen werden. Das ist ein bedeutender Fußabdruck. Es ist stärker als eine ruhende ASN und stärker als eine Wiederverkäuferseite ohne Routenidentität.

Es ist auch wesentlich dünner als eine Multi-Region-Cloud mit unabhängig überprüfbaren Einrichtungen, reichem Peering, öffentlichen Postmortems und produktbezogenen Wiederherstellungszusagen.

Für leichte Arbeitslasten kann das ein akzeptables Angebot sein. Eine kleine Website, Testumgebung, Community-Spieleserver oder nicht kritische Anwendung schätzen möglicherweise niedrige Reibung und Hardware-pro-Dollar mehr als formales Failover. Für Produktionsarbeitslasten sollte der Käufer Valex als eine Komponente in einem breiteren Kontinuitätsplan betrachten. Halten Sie anbieterunabhängige Backups vor. Testen Sie Wiederherstellungen. Führen Sie externe Überwachung durch. Halten Sie DNS portabel. Vermeiden Sie anbieterspezifische Images, wo praktikabel. 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 High-Speed- und Extreme-Stufen während eines Host-Ausfalls ersetzt werden können. Fragen Sie, was passiert, wenn Cloudflare Magic Transit, Cosmic Guard oder ein Upstream-Pfad beeinträchtigt ist.

Der Beweisgrad ist daher Mittel. Das Unternehmen hat Live-Dienst, Live-Routenursprung, sichtbare Präfixe, RPKI-Validierung, eine Statusseite, Abrechnungsregale und umfangreiche Richtliniendokumente. Die Herabstufung ist ebenso konkret: Die Live-Public-Edge ist klein; AS19468 ist veraltet; PeeringDB bestätigt keine Einrichtungen oder Austauschpräsenz; Produktregale zeigen Kapazitätsengpässe in mehreren Hochleistungskategorien; und öffentliche Quellen belegen keine getestete Multi-Site-Wiederherstellung, Ersatzhardware, Speicherunabhängigkeit, Support-Eskalation oder Ergebnisse der Kundenmigration.

Valex Cloud kann gehostete Kapazität verkaufen. Die Aufgabe des Kunden besteht darin, zu überprüfen, ob diese Kapazität wiederherstellbar ist, wenn das Rack, der Upstream, das Hardware-Regal oder der Support-Pfad unter Stress steht.