SIMPLE CLOUD SOLUTION LLC verkauft gehostete Kapazität, die noch von Racks, Transit und Reparaturfenstern abhängt

Zusammenfassung

• SIMPLE CLOUD SOLUTION LLC ist kein leerer Routing-Name. Die ARIN-Einträge AS63008 / SIMPLE-ASN und AS397968 / BBC-ASN sind aktive, auf den Namen des Unternehmens registrierte Ressourcen, und RIPEstat hat beide zum Zeitpunkt der Routenbeobachtung vom 14. Juli 2026 als angekündigt gesehen.
• Der öffentliche Netzfußabdruck ist schmal aber aktuell: RIPEstat listete 23.169.168.0/24, 2602:f9a9:201::/48 und 2602:f9a9:102::/48 unter AS63008 sowie 23.169.169.0/24 plus 2602:f9a9:301::/48 unter AS397968. Mehrere dieser Routen wurden unter RPKI validiert.
• PeeringDB führt AS63008 als SIMPLE CLOUD SOLUTION LLC, auch bekannt als HaeImAlan Network, mit einer NRIX-Exchange-Verbindung, einer IPv6-Schnittstelle mit 10 Gbit/s, Asien-Pazifik-Reichweite, offener Peering-Policy und keinen gelisteten Einrichtungen. Es ist ein Interkonnektivitätssignal, keine Rack-Karte.
• Die Hauptwebsite des Unternehmens und eine Geofeed-URL auf der Domain haeimalan.com haben in dieser Prüfungsumgebung Cloudflare-403-Sperrantworten zurückgegeben, während das DNS die Website hinter Cloudflare und die E-Mail hinter Microsoft 365 platzierte. Die öffentliche Unternehmenspräsenz ist daher dünner als die Routing-Nachweise.
• Der Beweiswert ist Mittel für die Netzidentität und öffentliche Routensichtbarkeit, aber Niedrig für die Resilienz der gehosteten Kapazität. Käufer sollten die tatsächlichen Einrichtungen, Racks, Stromversorgung, Transit, Support, Lagerbestand und Migrationsbedingungen prüfen, bevor sie das Unternehmen als zuverlässige Cloud-Infrastruktur betrachten.

Das Unternehmen ist in den Routen sichtbar, bevor es als Cloud sichtbar ist

Die erste nützliche Tatsache über SIMPLE CLOUD SOLUTION LLC ist, dass der öffentliche Routing-Eintrag klarer ist als die Produktgeschichte. Das BTW-Verzeichnis unterhttps://btw.media/en/directory/simple-cloud-solution-llcidentifiziert die Verzeichnisentität. ARIN gibt dem Unternehmen dann zwei aktive Einträge für autonome Systeme: AS63008 unterhttps://rdap.arin.net/registry/autnum/63008und AS397968 unterhttps://rdap.arin.net/registry/autnum/397968. Beide Einträge nennen SIMPLE CLOUD SOLUTION LLC als Antragsteller. Die in diesen Einträgen angegebene Adresse des Unternehmens lautet 2020 N Academy Blvd Ste 261, Colorado Springs, Colorado. Das reicht aus, um die rechtliche Identität hinter den Netzressourcen zu verankern.

Die zweite nützliche Tatsache ist, dass diese Nummern zum Zeitpunkt der Überprüfung für diesen Artikel keine ruhenden Registereinträge waren. Die AS-Übersicht von RIPEstat für AS63008 unterhttps://stat.ripe.net/data/as-overview/data.json?resource=AS63008identifizierte den Inhaber als "SIMPLE-ASN - SIMPLE CLOUD SOLUTION LLC" und zeigte die AS als angekündigt für das Abfragefenster vom 14. Juli 2026. Die entsprechende AS397968-Seite unterhttps://stat.ripe.net/data/as-overview/data.json?resource=AS397968identifizierte "BBC-ASN - SIMPLE CLOUD SOLUTION LLC" und zeigte ebenfalls announced=true. Die Routing-Statusansichten unterhttps://stat.ripe.net/data/routing-status/data.json?resource=AS63008undhttps://stat.ripe.net/data/routing-status/data.json?resource=AS397968zeigten im selben Fenster eine vollständig beobachtete IPv4-Sichtbarkeit und eine erhebliche IPv6-Sichtbarkeit.

Dies ist wichtig, da kleine Cloud- und Hosting-Unternehmen oft eine irreführende Spur hinterlassen. Eine Unternehmensseite kann online bleiben, während die Routen verschwinden. Eine Planseite kann Kapazität ankündigen, während das Bestellsystem keinen Bestand hat. Eine Domain kann geparkt sein, während ein Netzwerk noch Kunden transportiert. In diesem Fall ist der öffentliche Routennachweis lebendig. Er unterstützt eine engere und technischere Aussage: SIMPLE CLOUD SOLUTION LLC kontrolliert oder betreibt sichtbare Internet-Routing-Ressourcen.

Er unterstützt keine breitere Aussage, dass das Unternehmen über einen großen Bestand an gehosteter Rechenleistung, eine öffentliche Cloud-Region, mehrere Einrichtungen, Ersatzhardwarepools, Kunden-Failover-Optionen oder Unternehmens-Supportabdeckung verfügt.

Der Unterschied ist der gesamte Artikel. Der beabsichtigte Gegenstand ist ein Cloud-Service-Unternehmen, aber die öffentlichen Beweise, die wir nachweisen können, sind hauptsächlich Netzressourcennachweise. Eine verantwortungsbewusste Infrastrukturbewertung sollte daher vermeiden, die fehlende Produktebene durch Annahmen zu ersetzen. „Cloud" kann virtuelle Maschinen, Bare-Metal-Server, Reseller-Plattform, VPN-Dienste, Netzwerklabor-Dienste, Adressvermietung, Transit-angrenzendes Routing, Colocation-Support oder eine kleine Mischung dieser Aktivitäten bedeuten.

Die öffentliche Akte zu SIMPLE CLOUD SOLUTION LLC gibt nicht genug preis, um jede Serviceeinheit in eine dieser Kategorien einzuordnen.

PeeringDB fügt einen zweiten Namen und einen Hinweis auf die kommerzielle Positionierung hinzu. Die PeeringDB-Netzwerk-API unterhttps://www.peeringdb.com/api/net?asn=63008listet den Netzwerknamen als SIMPLE CLOUD SOLUTION LLC, den alternativen Namen als HaeImAlan Network, die Website alshttps://haeimalan.com, den Netzwerktyp als Cable/DSL/ISP und eine Notiz, die es als kleinen Endbenutzer-ISP und MVNO in den USA und Taiwan beschreibt. Diese Notiz ist nützlich, da sie die öffentliche Oberfläche über das konventionelle virtuelle Server-Hosting hinaus erweitert. Sie deutet auf eine Access-Netzwerk- und Mobilservice-Sprache sowie auf cloudorientierte Kapazität hin. Aber PeeringDB wird von den Betreibern gepflegt, und seine kommerziellen Notizen stellen kein geprüftes Kundeninventar dar.

Die Hauptdomain ist weniger nützlich. Eine direkte Anfrage anhttps://haeimalan.com/gab bei dieser Überprüfung eine Cloudflare-403-Sperrseite zurück, und die Geofeed-URL unterhttps://geofeed.haeimalan.com/geofeed.csvgab dieselbe Art von Sperrseite zurück. Das DNS für haeimalan.com löste zu Cloudflare-Adressen auf, seine Nameserver waren Cloudflare-Nameserver, und sein MX-Eintrag zeigte auf Microsoft 365. Das ist normal für einen kleinen Betreiber, der eine öffentliche Website schützt und die E-Mail auslagert. Es bedeutet auch, dass die öffentliche Website hier nicht verwendet werden kann, um Live-Hosting-Produkte, Service-Level-Bedingungen, Kapazitätsgeografie, Support-Fenster oder Kundenbestellungen nachzuweisen.

Die grundlegende Schlussfolgerung ist daher ausgewogen. SIMPLE CLOUD SOLUTION LLC hat echte öffentliche Netzwerknachweise. Es hat aktuelle Routensichtbarkeit. Es hat ARIN-Ressourcen. Es hat einen Interkonnektivitätsverzeichniseintrag. Es hat eine geschützte öffentliche Domain. Was es nicht hat, in der hier geprüften öffentlichen Akte, ist ein transparentes Katalog der gehosteten Dienste, der zeigt, wo Workloads laufen, welche Einrichtungen genutzt werden, wie viele Server inventarisiert sind, wie der Support eskaliert, welche Wiederherstellungszusagen gelten oder wie Kunden im Fehlerfall aussteigen können.

AS63008 ist das stärkste aktuelle Betriebssignal

AS63008 ist das sauberere der beiden öffentlichen Netzwerkprofile. ARIN nennt es SIMPLE-ASN. RIPEstat sah es im Beobachtungsfenster vom 14. Juli 2026 angekündigt. Der Endpunkt der angekündigten Präfixe unterhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS63008listete drei Routen: 23.169.168.0/24, 2602:f9a9:201::/48 und 2602:f9a9:102::/48. Die Präfixübersicht unterhttps://stat.ripe.net/data/prefix-overview/data.json?resource=23.169.168.0/24zeigte das /24 IPv4 von AS63008 angekündigt. Die RPKI-Validierungsseite unterhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS63008&prefix=23.169.168.0/24gab gültig zurück. Die RPKI-Seite für 2602:f9a9:201::/48 unterhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS63008&prefix=2602:f9a9:201::/48gab ebenfalls gültig zurück, ebenso 2602:f9a9:102::/48 unterhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS63008&prefix=2602:f9a9:102::/48.

Dies sind gute Hygiene-Signale. Sie zeigen, dass die Präfix-Ursprungsbeziehung nicht nur sichtbar, sondern auch mit den autoritativen Routenursprungsdaten zum Zeitpunkt der Abfrage abgeglichen ist. In einem kleinen Netzwerk zählt das. Die RPKI-Gültigkeit verringert das Risiko, dass eine Route von strengen Upstreams oder Exchange-Route-Servern abgelehnt wird. Es verhindert nicht alle Ausfälle, senkt aber einen häufigen Fehlermodus: Eine gültige Route verschwindet weniger wahrscheinlich, weil ein Upstream oder Route-Server sie als ungültig filtert.

Die Routing-Status-Antwort von RIPEstat für AS63008 ist ebenfalls stärker als ein bloßer Registereintrag. Sie zeigte ein IPv4-Präfix, zwei IPv6-Präfixe, vier beobachtete Nachbarn und vollständige Sichtbarkeit über die RIS IPv4- und IPv6-Peer-Sets im abgefragten Snapshot. Der ASN-Nachbarn-Endpunkt unterhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS63008listete AS216211, AS32595, AS40792 und AS46475 als beobachtete Nachbarn, wobei letzterer IPv4- und IPv6-Peer-Sichtbarkeit zeigte und die anderen in überwiegend IPv6-Beobachtungen auftauchten. Dies ist ein Nachweis für Upstream- oder benachbarte Routing-Pfade. Es identifiziert immer noch nicht die Einrichtung, in der sich ein Server befindet, aber es zeigt, dass die AS nicht von der öffentlichen Routenerfassung isoliert war.

Die ARIN-Adressressourceneinträge fügen eine weitere Ebene hinzu. Die IPv4-Zuteilung unterhttps://rdap.arin.net/registry/ip/23.169.168.0heißt SIMPLE-CLOUD-GLOBAL-01 und ist bei SIMPLE CLOUD SOLUTION LLC registriert. Die übergeordnete IPv6-Ressource unterhttps://rdap.arin.net/registry/ip/2602:f9a9:: heißt ebenfalls SIMPLE-CLOUD-GLOBAL-01 und ist beim Unternehmen registriert. Ein spezifischerer IPv6-Eintrag unterhttps://rdap.arin.net/registry/ip/2602:f9a9:102:: heißt HAEIMALAN-V6 und wird unter HaeImAlan Network angezeigt. Diese Mischung ist konsistent mit einem kleinen Betreiber, der die juristische Person, die öffentliche Netzwerkmarke und die IPv6-Delegationen gemeinsam nutzt.

Für einen Kunden ist die praktische Frage jedoch nicht nur, ob die AS lebt. Die Frage ist, was dahinter steckt. Ein /24 kann eine Vielzahl von Diensten transportieren: Kunden-VMs, Testendpunkte, Tunnelrouter, VPN-Konzentratoren, mobile Kernnetz-Supportsysteme, DNS, Management-Hosts, Reseller-Zuweisungen oder ein kleines Labor. Ein /48 kann geroutete Kundennetzwerke, interne Verbindungen, Tunnelendpunkte oder Exchange-orientierte Dienste unterstützen. Öffentliches BGP zeigt Erreichbarkeit.

Es zeigt nicht die Anzahl der Maschinen, den Servertyp, die Speicherkapazität, das Festplatteninventar, die Virtualisierungsplattform, das Backupsystem, die Ticket-Warteschlange oder ob heute ein Einzelhandelsserver bestellt werden kann.

Deshalb sollte AS63008 als starkes Signal für Netzidentität und schwaches Signal für Kapazität behandelt werden. Es beantwortet besser „Ist dieses Netzwerk sichtbar?" als „Wie viel Cloud-Service kann es verkaufen?". Es reicht für die Überwachung. Es reicht für eine Netzwerkkarte. Es reicht nicht für die Bereitstellung. Ein Käufer sollte eine aktuelle Servicebestellung, eine Einrichtungserklärung, eine Upstream-Liste, eine Wartungsrichtlinie, eine Missbrauchsrichtlinie, ein Backup-Modell, ein Support-Fenster und eine Migrationsklausel verlangen, bevor er sich auf die von AS63008 gehostete Kapazität verlässt.

AS397968 fügt Kapazitätssignale hinzu, aber auch Mehrdeutigkeit

AS397968 ist beim selben Unternehmen registriert, aber seine öffentliche Form ist anders. ARIN nennt es BBC-ASN, und RIPEstat zeigt es im selben Beobachtungsfenster vom Juli 2026 angekündigt. Der Endpunkt der angekündigten Präfixe unterhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS397968listete 23.169.169.0/24 und 2602:f9a9:301::/48. Die Routing-Status-Antwort unterhttps://stat.ripe.net/data/routing-status/data.json?resource=AS397968zeigte ein IPv4-Präfix, ein IPv6-Präfix, einen beobachteten Nachbarn und vollständige IPv4-Sichtbarkeit. Der ASN-Nachbarn-Endpunkt unterhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS397968listete AS400810 als beobachteten Nachbarn.

Der RPKI-Beweis ist ebenfalls positiv. RIPEstat gab gültig zurück fürhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS397968&prefix=23.169.169.0/24und gültig fürhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS397968&prefix=2602:f9a9:301::/48. Das bedeutet, dass der öffentliche Ursprung und die veröffentlichte Routenursprungsautorisierung zum Zeitpunkt der Abfrage übereinstimmten. Wiederum ist dies ein Signal für Routing-Qualität, keine Aussage über die Plattformgröße.

Die Mehrdeutigkeit zeigt sich in den Adresseinträgen. Bei Abfrage über ARIN RDAP gabhttps://rdap.arin.net/registry/ip/23.169.169.0einen untergeordneten Eintrag namens STEALTHBYTE-NETWORK-LTD zurück, mit einem Antragsteller, der als privater Kunde in North Kansas City, Missouri, angegeben ist. Dies widerspricht nicht der Tatsache, dass AS397968 bei SIMPLE CLOUD SOLUTION LLC registriert ist. Es deutet darauf hin, dass mindestens eine angekündigte IPv4-Route auf der Adresseintragsebene einer anderen Partei zugeordnet, delegiert oder anderweitig gekennzeichnet sein kann. Die öffentliche Akte erklärt die geschäftliche Vereinbarung nicht. Sie sollte nicht in eine Behauptung einer dauerhaften Beziehung umgewandelt werden. Sie sollte als Beweis dafür behandelt werden, dass das Unternehmen einen Dritt- oder kundenmarkierten Raum im Rahmen seines Betriebs routen kann.

Dies ist wichtig für das Risiko des gehosteten Dienstes. Wenn das Netzwerk nur die eigenen Dienste des Unternehmens transportiert, betrifft die Ausfallanalyse hauptsächlich seine eigenen Racks, Verträge und Support. Wenn das Netzwerk auch kundenmarkierte oder delegierte Netzwerke transportiert, umfasst die Ausfalloberfläche die Routenabhängigkeit des Kunden, die Genauigkeit der Neuzuweisung, das Missbrauchsmanagement, Reverse-DNS, Reputation, Upstream-Filterung und Kundenmigration.

Wenn eine Route von einem kleinen Betreiber und einem beobachteten Nachbarn abhängt, sollte ein Kunde wissen, ob der Dienst schnell verlagert werden kann, wenn sich der Upstream-Pfad ändert.

AS397968 macht den öffentlichen Fußabdruck des Unternehmens also größer, aber nicht einfacher. Es unterstützt die Idee, dass SIMPLE CLOUD SOLUTION LLC aktiv sichtbare Routing-Ressourcen betreibt. Es beweist keine konventionelle „Cloud-Region". Es beweist nicht, dass AS397968 Einzelhandels-VMs hostet. Es zeigt nicht, ob die betreffenden Maschinen in Kansas City, Colorado, Taiwan, einem entfernten Colocation-Schrank, einer gemieteten Serverumgebung oder einer kundenkontrollierten Umgebung sind. Es zeigt keine Backup-Standorte oder Failover-Mechanismen.

Die sicherste öffentliche Schlussfolgerung ist, dass die zweite AS Abhängigkeitsfragen aufwirft. Warum gibt es zwei ASNs unter demselben Unternehmen? Welche Kunden oder Dienste basieren auf welcher? Werden die Präfixe für gehostete Kapazität, Zugangsdienste, Tunnel-Dienste, Kundennetzwerke oder Experimente genutzt? Hat jede AS unabhängige Upstreams oder ist eine eine engere Route-Instanz? Ist AS397968 wiederherstellbar, wenn AS400810 ausfällt? Keine dieser Fragen ist feindselig. Sie sind normale Überprüfungen für ein kleines cloudorientiertes Netzwerk.

PeeringDB zeigt auf NRIX, nicht auf eine vollständige Einrichtungskarte

PeeringDB ist die einzige hier geprüfte öffentliche Quelle, die einen einrichtungsbezogenen Hinweis für das AS63008-Netzwerk gibt. Der vonhttps://www.peeringdb.com/api/net/35390zurückgegebene Netzwerkeintrag listet SIMPLE CLOUD SOLUTION LLC, alias HaeImAlan Network, als AS63008. Er meldet einen Exchange, null Einrichtungen, keinen gelisteten Looking Glass, keine gelisteten Route-Server, ARIN::AS-NOVEMBER als IRR-AS-Set, „Cable/DSL/ISP" als Typ, „50-100Gbps" als Verkehrsband, „Balanced" als Verhältnis, „Asia Pacific" als Reichweite, IPv6 aktiviert und eine allgemein offene Peering-Policy. Die Notiz gibt an, dass es sich um einen kleinen Endbenutzer-ISP und MVNO in den USA und Taiwan handelt.

Diese Details sind nützlich, aber jedes erfordert eine Einschränkung. PeeringDB ist ein selbstverwaltetes Interkonnektivitätsverzeichnis. Betreiber aktualisieren es oft für Peering, nicht für vollständige Serviceoffenlegungen. Das Verkehrsband „50-100Gbps" kann ein breiter Verzeichniswert sein und muss nicht den nachhaltigen Kundenverkehr darstellen. Die Reichweite „Asia Pacific" bedeutet nicht, dass jede Kunden-Workload in Asien ist. Das Feld „null Einrichtungen" ist besonders wichtig.

Es bedeutet, dass das öffentliche PeeringDB-Profil kein Rechenzentrum, keinen Rack-Standort, keinen Colocation-Anbieter, keinen Cloud-Host, keinen Schrank, keine Stromtopologie oder keinen Remote-Hand-Vertrag für dieses Netzwerk nennt.

Der Exchange-spezifische Eintrag unterhttps://www.peeringdb.com/api/netixlan?asn=63008ist konkreter. Er listet eine NRIX-Verbindung, Geschwindigkeit 10000, IPv6-Adresse 2001:ded:c000::37, Route-Server-Peer true, betriebsbereit true und einen Zeitstempel der Aktualisierung vom März 2026. Dies ist das beste aktuelle Interkonnektivitätssignal. Es zeigt, dass das Netzwerk bei NRIX mit einer IPv6-Schnittstelle mit 10 Gbit/s registriert ist. Es zeigt keine IPv4-Adresse an diesem Exchange. Es zeigt keine Verkehrsdiagramme. Es zeigt nicht das physische Rack, das verwendet wird, um den Exchange zu erreichen. Es beweist nicht, dass sich die Kundenberechnung im selben Raum wie der Exchange befindet.

Der NRIX-Exchange-Eintrag unterhttps://www.peeringdb.com/api/ix/4299identifiziert NRIX als NiceRoute Internet Exchanges in Taipei City, Taiwan. Sein Einrichtungsset umfasst Chief HD Building Taipei, eine Einrichtung von Chief Telecom Inc. im Bezirk Neihu in Taipei. Der Exchange-Eintrag gibt auch ein Best-Effort-Service-Level an und verweist aufhttps://nrix.org, das bei dieser Überprüfung auf die öffentliche Dokumentationsseite unterhttps://docs.nrix.org/weiterleitete. Diese Quellen reichen aus, um zu sagen, dass der Exchange einen Einrichtungskontext in Taipei hat. Sie reichen nicht aus, um zu sagen, dass SIMPLE CLOUD SOLUTION LLC ein Rack, einen Serverraum, eine Stromverpflichtung oder einen Kundenberechnungsschrank in dieser Einrichtung hat.

Dies ist eine klassische Grenze in der Internet-Infrastruktur. Ein Exchange-Port kann über viele Arrangements erreicht werden: direkte Colocation, gesponserter Port, Remote-Peering, Transport von einer anderen Einrichtung, ein Wiederverkäufer, ein Labornetzwerk, eine von einem befreundeten Betreiber unterstützte Mitgliedsverbindung oder eine virtualisierte Routing-Umgebung. Der öffentliche PeeringDB-Eintrag verrät nicht, welches Arrangement zutrifft. Er erfasst auch keinen netfac-Eintrag für das Netzwerk, und die netfac-API unterhttps://www.peeringdb.com/api/netfac?net_id=35390gab einen leeren Datensatz zurück. Dies ist die Linie, die der Artikel nicht überschreiten sollte.

Die präziseste Aussage ist: SIMPLE CLOUD SOLUTION LLC hat einen öffentlichen AS63008-Interkonnektivitätseintrag bei NRIX mit IPv6-Route-Server-Teilnahme und einem Geschwindigkeitsfeld von 10 Gbit/s, aber es hat keine öffentliche PeeringDB-Einrichtungsliste. Der NRIX-Exchange selbst ist mit einer Einrichtung in Taipei verbunden, aber diese Verbindung ist kein Beweis für ein eigenes Rack oder die Workload-Lokalität des Unternehmens. Für Cloud-Käufer bedeutet dies, dass Taiwan Teil der Betriebsgeschichte des Netzwerks sein kann, während der genaue Standort der Berechnung und Daten ein Punkt bleibt, der überprüft werden muss.

Gehostete Kapazität hängt immer noch von nicht in BGP gezeigten Elementen ab

Der Auftrag für dieses Unternehmen fragt, ob die gehostete Kapazität von Racks, Transit und Reparaturfenstern abhängt. Die Antwort ist ja, auch wenn die öffentlichen Quellen die genauen Racks nicht offenlegen. Internet-Routing ist der Weg, nicht die Plattform. Ein kleiner Anbieter kann Präfixe sauber ankündigen und dennoch ein begrenztes Serverinventar, einen Remote-Hand-Pfad, einen Zahlungsabwickler, eine Person, die Tickets bearbeitet, eine einzige Upstream-Konzentration oder keine Ersatzhardware im Raum haben, in dem der Kunde sie benötigt.

Wenn SIMPLE CLOUD SOLUTION LLC virtuelle Server, VPN-Knoten, Bare-Metal-Kapazität, verwaltete Netzwerkendpunkte oder Reseller-Hosting verkauft, hängt die Kundenerfahrung von einem Stapel physischer und vertraglicher Abhängigkeiten ab. Server benötigen Strom, Kühlung und Festplattenaustausch. Router benötigen Schnittstellen, Optiken und Konfigurationskontrolle. Upstream-Transit benötigt Verträge und Zahlungsfähigkeit. Exchange-Konnektivität benötigt Kompatibilität mit dem Route-Server und Peering-Filtern. DNS benötigt Kontozugriff. Missbrauchsabteilungen benötigen Reaktionszeiten. Backups benötigen separaten Speicher.

Migration benötigt Dokumentation, Images, Exporte und Adressänderungsplanung.

Keines dieser Elemente ist von der RIPEstat-Routing-Tabelle aus sichtbar. Die Routensichtbarkeit kann ausgezeichnet sein, während ein bestimmter Server nicht auf Lager ist. RPKI kann gültig sein, während ein Festplatten-Array keine Ersatzfestplatten hat. Ein Exchange-Port kann betriebsbereit sein, während die Kunden-VMs woanders sind. Eine Cloudflare-geschützte Homepage kann laden oder blockieren, ohne dem Leser etwas über das eigene Hosting-Netzwerk des Anbieters zu verraten. Ein ARIN-Adresseintrag kann aktiv sein, während der tatsächliche Kundenservice manuell, privat, unterbrochen, experimentell oder mit begrenzter Kapazität ist.

Die öffentliche Akte gibt jedoch Hinweise auf das Betriebsmodell. Das Unternehmen hat direkte ARIN-Ressourcen und zwei ASNs. Es hat mindestens eine Exchange-orientierte Präsenz. Es nutzt Cloudflare für seine öffentliche Domain und Microsoft 365 für E-Mail. Es registriert eine Marke HaeImAlan Network in PeeringDB. Es beschreibt sich dort als kleinen Endbenutzer-ISP und MVNO in den USA und Taiwan. Diese Signale deuten auf einen Netzwerkbetreiber hin, der mit BGP, IPv6 und der Verwaltung öffentlicher Register vertraut ist. Sie deuten nicht auf eine konventionelle Hyperscale-Cloud hin.

Das wahrscheinliche Risikoprofil ist das einer kleinen Anbieterinfrastruktur, nicht eines regionalen Unternehmensausfalls.

Kleine Anbieterinfrastruktur kann durchaus nützlich sein. Sie kann Nischenkunden gut bedienen, besonders wenn diese Kunden das Netzwerk verstehen, eine spezifische IPv6-Routing benötigen, manuellen Support akzeptieren oder eine bestimmte Geografie oder Gemeinschaftsbeziehung schätzen. Das Risiko entsteht, wenn Käufer das Wort „Cloud" auf Unternehmensannahmen projizieren: sofortiger Ersatz, Multi-Zonen-Haltbarkeit, große Ersatzpools, dokumentierte Incident-Response, öffentliche Statusseiten, geprüfte Kontrollen und personell besetzte Support-Warteschlangen.

Die öffentlichen Beweise für SIMPLE CLOUD SOLUTION LLC unterstützen diese Annahmen nicht.

Das macht das Unternehmen nicht schwach. Es macht das Ziel der Due Diligence spezifisch. Fragen Sie, wo die Server sind. Fragen Sie, ob der Service virtuell, Bare-Metal, reines Netzwerk oder zugangsnetzgebunden ist. Fragen Sie, wem die Hardware gehört. Fragen Sie, ob die Stromversorgung auf Rack-Ebene oder nur auf Einrichtungsebene redundant ist. Fragen Sie, ob AS63008 und AS397968 betrieblich unabhängig sind. Fragen Sie, welche Upstreams bezahlter Transit sind, welche Exchange-Peers und welche Route-Server-Pfade sind. Fragen Sie, welche Daten exportiert werden können, wie schnell und in welchem Format.

Fragen Sie, ob ein Kunde vom Anbieter zugewiesene Adressen erhält, die bei der Migration geändert werden müssen.

Mit anderen Worten, der öffentliche Routennachweis ist der Beginn des Gesprächs, nicht die Antwort. Er kann Überwachung, Bedrohungsmodellierung, Beschaffungsfilterung und Abhängigkeitskartierung unterstützen. Er kann keinen Serviceauftrag, kein Architekturschema, keinen Supportvertrag oder keine getestete Wiederherstellung ersetzen.

Ausfallpfade sind gewöhnlich, deshalb sind sie wichtig

Der erste Ausfallpfad ist der Einrichtungszugang. PeeringDB sagt uns, dass AS63008 bei NRIX erscheint, und der PeeringDB-Exchange-Eintrag platziert den Exchange in einem Einrichtungskontext in Taipei. Aber SIMPLE CLOUD SOLUTION LLC listet keine Einrichtung für sein eigenes Netzwerkprofil.

Wenn eine Kunden-Workload von physisch nahe diesem Exchange befindlicher Ausrüstung abhängt, sind die Unbekannten praktisch: Wer hat einen Zugangsausweis, wer kann Optiken austauschen, wie wird Remote-Hand bestellt, ob Support außerhalb der Geschäftszeiten existiert, wie Cross-Connect-Fehler eskaliert werden und ob der Anbieter die Workload bei einem Gebäude- oder Schrankereignis verlegen kann.

Der zweite Ausfallpfad ist die Upstream-Konzentration. RIPEstat sah vier Nachbarn für AS63008 und einen für AS397968. Die Anzahl der Nachbarn ist keine vollständige Vertragskarte; Routensammler können einige Beziehungen sehen und andere verpassen. Dennoch ist der AS397968-Eintrag in der öffentlichen Ansicht eng. Wenn diese AS eine kundenmarkierte Route oder eine Produktklasse transportiert, könnte ein Ausfall auf der Ebene des beobachteten Nachbarn... Wenn AS63008 stark auf einen Exchange-Route-Server-Pfad für IPv6 angewiesen ist, könnten die Route-Server-Richtlinie, RPKI-Filter oder Exchange-Wartung...

Der Kunde muss wissen, ob bezahlter Transit, Exchange-Peering und Backup-Routing tatsächlich diversifiziert sind.

Der dritte Ausfallpfad ist die Präfixpolitik. RPKI-Gültigkeit ist gut, aber sie bedeutet auch, dass Routenänderungen mit den ROAs abgestimmt bleiben müssen. Wenn ein Präfix auf eine Backup-AS oder einen anderen Upstream ohne entsprechende Autorisierung verschoben wird, können strenge Netzwerke es ablehnen. Dies ist eine lösbare betriebliche Aufgabe, aber sie muss während eines Ausfalls verwaltet werden. Die öffentlichen Quellen zeigen gültige Ursprünge für mehrere aktuelle Routen. Sie zeigen nicht den Notfall-Autorisierungsprozess des Anbieters, der ROAs ändern kann, oder wie schnell eine Route verschoben werden kann.

Der vierte Ausfallpfad ist die Adressabhängigkeit. Kunden, die vom Anbieter zugewiesene Adressen verwenden, können diese normalerweise nicht woandershin mitnehmen. Wenn ein Server auf 23.169.168.0/24 oder ein über AS397968 geroutetes Netzwerk migriert werden muss, müssen DNS, Firewall-Regeln, Whitelists, Zertifikate, E-Mail-Reputation und Missbrauchsverlauf möglicherweise alle aktualisiert werden. Wenn der Dienst stark IPv6 ist, müssen Kunden auch wissen, ob der Zielanbieter die Präfixdelegation bewahren kann oder ob die Anwendungen stabile IPv6-Adressen voraussetzen.

Der fünfte Ausfallpfad ist der Hardwarebestand. Nichts in der öffentlichen Akte sagt, wie viele Server, Router, Switches, Optiken, Stromversorgungen, Speichergeräte oder Ersatzmaschinen das Unternehmen besitzt. Eine öffentliche AS kann von einem bescheidenen Gerät aus betrieben werden. Ein VPS-Host benötigt Rechenleistung und Speicher. Ein Bare-Metal-Angebot benötigt Ersatzmaschinen. Ein Netzwerklabor benötigt Router und Fernzugriff. Ohne öffentliche Produktseiten oder Statusseiten können Käufer nicht ableiten, welcher Hardwarepool existiert. Wenn Hardware ausfällt, hängt die Austauschzeit von Inventar, Zugang und Geld ab.

Der sechste Ausfallpfad ist die Supporttiefe. Ein kleiner Netzwerkbetreiber kann technisch kompetent sein, aber dennoch wenig Personal haben. PeeringDB zeigt auf ein Profil eines kleinen Endbenutzer-ISP und MVNO, nicht auf eine große Managed-Services-Abteilung. Die öffentliche Domain nutzt Cloudflare-Schutz, und die Homepage war aus dieser Prüfungsumgebung nicht direkt lesbar. Kein öffentlicher Support-Zeitplan, Eskalationspfad, Incident-Verlauf, Verfügbarkeitsversprechen, Serviceguthaben oder Reparaturziel war im geprüften Material sichtbar.

Das bedeutet, dass Kunden explizite Support-Bedingungen verlangen sollten, bevor sie sich für Produktions-Workloads auf den Dienst verlassen.

Der siebte Ausfallpfad ist Abrechnung und Kontinuität. Kleine Anbieter arbeiten manchmal mit manuellen Rechnungen, Gemeinschaftsvereinbarungen, delegierten Netzwerkressourcen oder privaten Verträgen. Wenn Zahlung, Missbrauchsmanagement oder Kundenkommunikation abbrechen, kann das Routing unterbrochen werden, auch wenn die Hardware noch funktioniert. Die öffentliche Akte hier bietet kein Standardbestellformular, keine Kündigungsbedingungen oder keine Datenrückgabeverpflichtung. Für jeden Kauf von gehosteter Kapazität ist diese fehlende Vertragsebene genauso wichtig wie die Routing-Tabelle.

Installierte Kapazität und nutzbare Kapazität sind unterschiedlich

Die öffentliche Routing-Tabelle kann den Eindruck erwecken, dass ein kleiner Anbieter größer oder kleiner ist als die Kundenerfahrung. AS63008 hat ein sichtbares /24 IPv4 und zwei sichtbare /48 IPv6. AS397968 hat ein weiteres sichtbares /24 IPv4 und /48 IPv6. Dies ist ein bedeutender Adressraum, besonders für ein kleines junges Netzwerk. Aber Adressraum ist keine installierte Rechenkapazität. Ein /24 kann viele kleine Dienste unterstützen, aber es kann auch weitgehend ungenutzt, delegiert, reserviert, gefiltert oder der Netzwerkinfrastruktur zugewiesen sein.

Ein /48 kann viele Subnetze unterstützen, sagt aber nichts über die Anzahl der Maschinen aus.

Installierte Kapazität ist die Ausrüstung, die der Anbieter unter Kontrolle hat. Nutzbare Kapazität ist die Ausrüstung, die mit Strom versorgt, erreichbar, unterstützbar, mit sauberen Festplatten ausgestattet, einem Produkt zugewiesen, mit den richtigen Upstreams verbunden und unter einem Vertrag verfügbar ist, auf den der Kunde zählen kann. Ein Router kann installiert sein, aber nicht für Kundenverkehr geeignet. Ein Server kann mit Strom versorgt, aber vollständig alloziert sein. Ein Präfix kann angekündigt, aber keinen neuen Workloads zugewiesen sein. Eine Einrichtung kann einen Exchange-Port beherbergen, aber nicht die Kundenberechnung.

Deshalb ist der einrichtungslose PeeringDB-Eintrag so wichtig. Wenn das Unternehmen mehrere Einrichtungen und aktuelle Exchange-Ports auflisten würde, könnten wir zumindest die öffentliche Einrichtungsgeschichte kartieren. Stattdessen sehen wir die Exchange-Verbindung, aber nicht den Berechnungsstandort. Wenn das Unternehmen eine öffentliche Bestellseite mit Plänen und Bestand betreiben würde, könnten wir die Routennachweise mit der kommerziellen Kapazität vergleichen. Stattdessen war die öffentliche Domain hier nicht direkt lesbar.

Wenn das Unternehmen eine Statusseite veröffentlichen würde, könnten wir Vorfälle und Wartungshinweise einsehen. In den geprüften Quellen wurde keine öffentliche Statusseite gefunden.

Das Fehlen dieser Details bedeutet nicht, dass dem Unternehmen Kapazität fehlt. Es bedeutet, dass die Kapazität nicht öffentlich überprüfbar ist. Ein kleiner Betreiber kann die Kapazität absichtlich privat halten. Er kann durch Empfehlung verkaufen. Er kann eine enge Gemeinschaft bedienen. Er kann Zugangsdienste statt Einzelhandels-Hosting betreiben. Er kann Cloud- oder Colocation-Partner nutzen, die nicht offengelegt werden. Jede dieser Möglichkeiten ändert das Risikomodell. Die öffentlichen Beweise können nicht zwischen ihnen wählen.

Für die Abhängigkeitskartierung weist der Artikel daher unterschiedliche Vertrauensniveaus zu. Identitätsvertrauen ist hoch: ARIN und PeeringDB stimmen beim Firmennamen und AS63008 überein, und ARIN verbindet AS397968 mit demselben Antragsteller. Aktuelles Routing-Vertrauen ist mittel-hoch: RIPEstat sieht angekündigte Routen und RPKI validiert die Schlüsselursprünge. Einrichtungsvertrauen ist niedrig: PeeringDB listet null Einrichtungen für das Firmenprofil, auch wenn der NRIX-Exchange einen Einrichtungskontext in Taipei hat.

Vertrauen in gehostete Kapazität ist niedrig: Die öffentlichen Quellen legen keine Produkte, Bestände, Serveranzahl, Support-Bedingungen oder Wiederherstellungszusagen offen.

Diese Vertrauenskarte ist nützlicher als ein Ja-Nein-Etikett. Sie ermöglicht es dem Leser, die positiven Beweise zu nutzen, ohne sie zu überinterpretieren. SIMPLE CLOUD SOLUTION LLC ist als Netzwerkbetreiber sichtbar. Es kann gehostete Kapazität verkaufen oder unterstützen. Es kann nicht als vollständig dokumentierte öffentliche Cloud-Plattform auf der Grundlage der hier verfügbaren Beweise behandelt werden.

Datenlokalität ist eine ungelöste betriebliche Frage

Die Analyse der Datensouveränität ist für kleine Infrastrukturunternehmen besonders schwierig, da Netzwerkgeografie, rechtliche Geografie und Daten-Geografie oft auseinanderfallen. Die ARIN-Einträge von SIMPLE CLOUD SOLUTION LLC platzieren den rechtlichen Antragsteller in Colorado Springs. PeeringDB listet die Stadt der Organisation als Kansas City, Missouri. Die PeeringDB-Netzwerknotiz erwähnt die USA und Taiwan. Der NRIX-Exchange ist in Taipei City. Die öffentliche Website löst zu Cloudflare-Adressen auf, und die E-Mail wird von Microsoft 365 verwaltet.

Keine dieser Tatsachen sagt einem Kunden allein, wo sich Anwendungsdaten, Backups, Protokolle oder Support-Zugang befinden.

Wenn das Unternehmen Zugangsdienste oder mobilitätsbezogene Dienste bereitstellt, kann der Verkehr durch Taiwan geleitet werden, ohne dass Kundendaten dort gespeichert werden. Wenn es einen VPS- oder Bare-Metal-Dienst bereitstellt, ist der physische Standort des Servers direkt wichtig. Wenn es Kundennetzwerke routet, kann der Standort der Kundenausrüstung vom AS-Inhaber getrennt sein. Wenn es Drittanbieter-Hosting für Verwaltung, Tickets, Abrechnung, DNS oder Überwachung nutzt, können diese Systeme zusätzliche Rechtsordnungen einführen. Die öffentlichen Quellen geben keine vollständige Karte des Datenflusses.

Für einen Kunden mit Lokalitätsanforderungen muss „Global" als Servicezone daher als Erreichbarkeit gelesen werden, nicht als Speicher. Das Internet kann einen Server von überall erreichen; das macht den Server nicht global. Ein Unternehmen kann eine US-amerikanische Rechtsadresse, einen Exchange-Port in Taiwan und Cloudflare als Fassade für eine Website haben. Die Daten könnten dennoch in einer einzigen Einrichtung, auf einem gemieteten Server, in der eigenen Umgebung des Kunden oder in einer nicht offengelegten Drittanbieter-Cloud liegen. Die einzig verantwortungsbewusste öffentliche Aussage ist, dass die Lokalität unsicher ist.

Diese Unsicherheit hat praktische Konsequenzen. Wenn eine Anwendung in den USA bleiben muss, sollte der Kunde eine schriftliche Einrichtungs- und Backup-Standorterklärung verlangen. Wenn eine Anwendung Erreichbarkeit in Taiwan benötigt, sollte der Kunde überprüfen, ob der Dienst die Berechnung tatsächlich in der Nähe von NRIX platziert oder nur dorthin routet. Wenn die Workload personenbezogene Daten verarbeitet, sollte der Kunde fragen, wer auf den Server zugreifen kann, wo Protokolle gespeichert werden, wie Missbrauchstickets behandelt werden und welche Unterauftragnehmer den Dienst unterstützen.

Wenn der Dienst für Verwaltungsoberflächen von Microsoft 365 oder Cloudflare abhängt, sollte dies in die Compliance-Karte aufgenommen werden.

Die Adresseinträge warnen auch vor vereinfachenden Lokalitätsetiketten. Die RDAP-Antwort für 23.169.169.0/24 zeigt einen untergeordneten Eintrag mit einem Kunden-Typ-Etikett und einem Standort Missouri, während RIPEstat es als von AS397968 angekündigt zeigt. Der IPv6-Eintrag 2602:f9a9:102:: zeigt HaeImAlan Network mit einer Missouri-Adresse im untergeordneten Eintrag. Diese Einträge können Registrierungskontakte, Delegationen oder Kundenetiketten widerspiegeln, nicht die tatsächliche Serverplatzierung. Sie sind ein Nachweis des administrativen Kontexts, kein Beweis dafür, wo jedes Paket endet.

Deshalb ist die beste Artikelhaltung ein Punkt der Wachsamkeit. SIMPLE CLOUD SOLUTION LLC hat eine öffentliche Netzwerkgeografie, die die USA und Taiwan berührt. Es hat eine Unternehmensadresse in Colorado, eine Organisationsstadt in Missouri, eine Cloudflare-geschützte Domain und einen Exchange-Kontext in Taipei. Nichts davon erlaubt einem Käufer, den Speicherort der gehosteten Workloads abzuleiten. Die Datenlokalität sollte dienstspezifisch überprüft werden.

Was ein Kunde fragen sollte, bevor er sich auf den Dienst verlässt

Ein Kunde, der SIMPLE CLOUD SOLUTION LLC in Betracht zieht, sollte mit den Routennachweisen beginnen und sich dann schnell zu den Betriebsnachweisen bewegen. Die Routennachweise sind nicht der schwache Teil. ARIN, RIPEstat und PeeringDB zeigen genug, um ein echtes Netzwerk zu identifizieren. Der schwache Teil ist die fehlende Service-Ebene. Ein Käufer sollte die Servicebeschreibung in einfachen Worten verlangen: VPS, Bare-Metal, verwaltetes Hosting, Netzwerk-Transit, Tunnel-Dienst, Zugangsdienst, Mobildienst, Adress-Routing oder etwas anderes. Jeder Dienst hat eine andere Abhängigkeitskarte.

Die nächste Frage ist die Einrichtung. Wo ist die Workload physisch installiert? Ist es in einem benannten Rechenzentrum, einer Partnereinrichtung, einem gemieteten Server, einer entfernten Colocation-Umgebung, einem an den Exchange angeschlossenen Schrank, einem eigenen Standort des Kunden oder einer Drittanbieter-Cloud? Wem gehört die Hardware? Wer darf sie berühren? Was ist der Remote-Hand-Prozess? Was ist die erwartete Reparaturzeit, wenn eine Festplatte, ein Netzteil, ein Router oder eine Optik ausfällt? Gibt es Ersatzmaschinen oder nur Ersatz im besten Fall?

Als nächstes kommt die Netzwerkdiversität. Welche AS transportiert den Dienst? Ist es AS63008 oder AS397968? Welche Präfixe werden verwendet? Gibt es mindestens zwei Upstream-Pfade, die den Dienst transportieren können, wenn ein Exchange-Pfad ausfällt? Sind die Routenursprungsautorisierungen bereits für Notfall-Ursprungsänderungen vorhanden? Werden die Routenfilter nach Änderungen getestet? Ist der Anbieter für einen kritischen Pfad auf die NRIX-Route-Server-Konnektivität angewiesen, oder gibt es anderswo bezahlten Transit? Ist die IPv4-Verfügbarkeit dieselbe wie die IPv6-Verfügbarkeit?

Die Support-Bedingungen sind genauso wichtig wie die Routen. Welche Stunden sind abgedeckt? Wie wird ein kritisches Ticket eskaliert? Wer überwacht das Netzwerk? Gibt es eine öffentliche oder kundenspezifische Statusseite? Welcher Incident-Verlauf existiert? Was passiert, wenn Missbrauchsmeldungen außerhalb der Geschäftszeiten eingehen? Was passiert, wenn eine Zahlung fehlschlägt? Wie lange werden Daten nach einer Aussetzung oder Kündigung aufbewahrt? Werden Support und Abrechnung von derselben Person verwaltet? Kann der Anbieter eine Wartungsvorankündigung vor Routing-, Einrichtungs- oder Hardwarearbeiten geben?

Die Migrationsbedingungen sind der letzte Test. Ein Kunde sollte davon ausgehen, dass die vom Anbieter zugewiesenen Adressen nicht mitgenommen werden können. Das bedeutet, dass DNS unter Kundenkontrolle sein sollte, Backups außerhalb des Anbieters sein sollten, Bereitstellungsskripte die Dienste anderswo neu aufbauen sollten und Anwendungsgeheimnisse nicht von einer einzelnen Maschine abhängen sollten. Wenn eine Workload IPv6-Zuteilungen unter 2602:f9a9:: oder IPv4 unter 23.169.168.0/24 verwendet, sollte der Kunde wissen, wie schnell er umnummerieren kann.

Wenn die Workload AS397968 über eine kundenartige Delegation nutzt, sollte der Kunde wissen, wer die Route kontrolliert und wer Änderungen autorisieren kann.

Keine dieser Fragen erfordert, dass das Unternehmen groß ist. Ein kleiner Betreiber kann sie klar beantworten und dennoch eine gute Wahl für einen technischen Käufer sein. Der Punkt ist, dass die öffentlichen Quellen sie heute nicht beantworten. Die öffentlichen Beweise bringen den Käufer zur Tür. Der Vertrag und der Beweis müssen den Rest erledigen.

Der Beweiswert ist mittel für Routen und niedrig für Resilienz

SIMPLE CLOUD SOLUTION LLC verdient mehr als ein abwertendes Etikett „schwacher Fußabdruck". Es hat aktive ARIN-Ressourcen, zwei sichtbare ASNs, aktuelle RIPEstat-Routensichtbarkeit, gültige RPKI für Schlüsselpräfixe und einen PeeringDB-Exchange-Eintrag bei NRIX. Diese Fakten sind solider als viele kleine Hosting-Einträge. Sie zeigen eine echte Netzwerkoberfläche mit aktueller öffentlicher Erreichbarkeit.

Das gleiche Unternehmen verdient auch eine klare Herabstufung für Behauptungen über gehostete Kapazität. Die öffentliche Website konnte aus dieser Umgebung nicht direkt gelesen werden, da Cloudflare eine Sperrseite zurückgab. PeeringDB listet keine Unternehmenseinrichtungen. Keine öffentliche Bestellseite, kein Serverinventar, kein Status-Dashboard, keine Support-SLA, kein Incident-Archiv, keine Backup-Richtlinie, keine Hardware-Ersatzrichtlinie und keine Datenexportrichtlinie wurde im geprüften Material gefunden. Der Exchange-Eintrag verrät nicht den Berechnungsstandort. Die Routeneinträge verraten nicht die Anzahl der Kunden.

Die ARIN-Einträge verraten nicht den Bestand oder die Reparaturfenster.

Die nützlichste Endbewertung ist daher geteilt. Netzidentität: stark. Aktuelle öffentliche Routensichtbarkeit: mittel-hoch. Öffentlicher Einrichtungsnachweis: niedrig. Öffentlicher Nachweis gehosteter Kapazität: niedrig. Öffentlicher Resilienznachweis: niedrig. Gesamtbewertung Netzwerknachweis: Mittel, da die Routing-Oberfläche real und aktuell ist, aber die öffentliche Betriebsebene zu dünn bleibt, um eine nicht herabgestufte Cloud-Service-Abhängigkeitsbewertung zu unterstützen.

Für die Leser ist der wichtige Punkt nicht, dass SIMPLE CLOUD SOLUTION LLC unzuverlässig ist. Die öffentlichen Beweise beweisen das nicht. Der Punkt ist, dass das Netzwerk sichtbar ist, während die Serviceplattform undurchsichtig ist. Ein Kunde kann AS63008 und AS397968 überwachen. Ein Forscher kann die ARIN-, RIPEstat- und PeeringDB-Einträge zitieren. Ein Käufer sollte dennoch einen Nachweis über Racks, Transitverträge, Stromabhängigkeit, Support-Eskalation, Ersatzhardware und Migrationsrechte verlangen, bevor er Produktions-Workloads hinter die gehostete Kapazität des Unternehmens stellt.