Zusammenfassung

  • Outofbox Cloud hat eine aktuelle öffentliche Route: AS147192 kündigt 103.174.148.0/23 an, und diese Route war am 15. Juli 2026 für 325 von 326 RIPE RIS IPv4-Peers sichtbar.
  • Die physischen Belege konzentrieren sich auf Sadashiv Nagar, Belagavi. Ein lokaler Bericht von 2020 beschrieb mehr als 100 installierte Server und Platz für fast 300, während ein Hochschulbesuch im September 2025 Racks, Kühlung und Notstrom am selben Ort dokumentierte. Keine der Quellen belegt die aktuelle betriebsbereite, nutzbare oder Reservekapazität des Standorts.
  • Die Behauptung des Unternehmens über acht Rechenzentrenregionen wird auf seinen öffentlichen Produktseiten nicht durch acht Städtenamen, Betreiber, Stromversorgungskonzepte, Kapazitätsangaben oder einen regionsbezogenen Statusverlauf untermauert. Die eigenen AGB schließen außerdem einen unterbrechungsfreien oder fehlerfreien Betrieb aus, trotz einer separaten Behauptung einer 99,99%igen SLA.
  • AS147192 hat einen beobachteten Nachbarn, AS141815, registriert auf die rechtlich eigenständige Outofbox Networks Private Limited. Dieses Netzwerk hat eine breitere Upstream- und Exchange-Konnektivität, aber die logische Routendiversität jenseits des ersten Hops begründet keine diversen Glasfaserzugänge, Leitungswege, Gebäude, Energieversorgungen oder Ausfallbereiche für Outofbox Cloud.

Acht Regionen werden beworben; ein Standort ist belegt

Der folgenreichste Satz auf der Produktseite von Outofbox Cloud ist nicht der Preis einer kleinen virtuellen Maschine. Es ist die Behauptung auf derBoxes-Seitedes Unternehmens, dass Kunden auf acht Rechenzentrenregionen ausweiten können. Dieselbe Seite verwendet den Marketingbegriff „globale Verfügbarkeit“ und bewirbt eine Startzeit von 55 Sekunden und eine 99,99%ige Verfügbarkeits-SLA. Dies sind messbare Aussagen, aber sie sind kein Beleg für eine globale Betriebspräsenz. Sie implizieren mehr als eine reine Webshop-Front: genügend installierte Rechen-, Speicher- und Adresskapazität, um eine Bestellung anzunehmen; eine Steuerungsebene, die den Workload platzieren kann; eine mit Strom versorgte Einrichtung; ein gerouteter Pfad; Support-Mitarbeiter; und, wenn das Wort „Regionen“ im üblichen Infrastruktursinn verwendet wird, geografisch unterscheidbare Betriebsstandorte.

Die öffentlichen Belege erlauben es einem Leser nicht, acht solcher Standorte aufzuzählen. Es erscheint keine Acht-Städte-Liste neben der Behauptung. Die Seite identifiziert keine Einrichtungsbetreiber, Colocation-Partner, Energieversorgungen, Rack-Zahlen, Leistungsumfänge, Zertifizierungen, Inbetriebnahmedaten oder regionale Statusendpunkte. Ein Kunde könnte nach der Kontoerstellung mehr Details erhalten, und private Verträge könnten sie enthalten.

Die öffentliche Behauptung kann dennoch nicht als Beweis dafür behandelt werden, dass acht unabhängig betreibbare Einrichtungen existieren, dass alle Aufträge annehmen oder dass ein Workload zwischen ihnen ausweichen kann.

Was belegt werden kann, ist eine kleinere Präsenz mit echten Betriebssignalen. DerBTW-Verzeichniseintragidentifiziert das Unternehmen, das Gegenstand dieses Profils ist. APNIC-Datensätze verbinden dieses Unternehmen mit einem autonomen System und einer portablen IPv4-Zuweisung. Die Website und die Registrierungskontakte des Unternehmens verweisen auf Sadashiv Nagar in Belagavi, Karnataka. Unabhängiges lokales Material beschreibt dort Server, Racks, Kühlung und Notstrom. Zum Beobachtungszeitpunkt lösten sich die Domänennamen der Website und des Kundenportals des Unternehmens ebenfalls in Adressen innerhalb dieses zugewiesenen IPv4-Blocks auf. Die DNS-Beobachtung stellt nur eine Adresszuordnung her; die physischen und Routing-Belege, getrennt betrachtet, stützen einen echten lokalen Betrieb. Keiner von ihnen stützt eine Acht-Standort-Karte.

Diese Unterscheidung ist keine Pedanterie. Ein Kunde, der sich für einen regionalen Anbieter entscheidet, legt möglicherweise zu Recht Wert auf lokalen Support, indische Datenresidenz und einen latenzärmeren Zugang von Karnataka. Diese Vorteile können beträchtlich sein, selbst wenn die Plattform auf eine Stadt konzentriert ist. Das Risiko tritt auf, wenn eine kompakte lokale Plattform mit Sprache verkauft wird, die Leser als Hyperscale-Geografie interpretieren könnten. Die richtige Bewertung ist weder „es gibt keine Infrastruktur“ noch „acht Regionen sind bewiesen“.

Es ist, dass die Belagavi-Präsenz gestützt wird, während die Geografie jenseits davon in öffentlichen Belegen unbekannt bleibt.

Das Unternehmen, die frühere Marke und der Netzbetreiber sind nicht austauschbar

OUTOFBOX CLOUD PRIVATE LIMITED ist ein indisches Privatunternehmen. Ein aktueller, aus dem MCA abgeleiteter Unternehmenseintrag, veröffentlicht vonIndiaFilings, gibt die Unternehmensidentifikationsnummer U72900KA2021PTC149665, ein Gründungsdatum vom 19. Juli 2021, einen aktiven Einreichungsstatus zum Stand seines Updates vom November 2025 und das registrierte Büro im Fourth Floor, Oneness, Sadashiv Nagar, Belagavi an. Es listet Ajit Kumar S Patil und Gowdesh Singangouda Patil als Direktoren. Da diese Seite Registrierungsinformationen erneut veröffentlicht und nicht selbst das Register ist, sollte der genaue aktuelle Einreichungsstatus anhand der Masterdaten des Ministry of Corporate Affairs überprüft werden, bevor ein wesentlicher Vertrag geschlossen wird.

Die Marke Outofbox Cloud existierte bereits vor diesem Unternehmen. Ein erhaltenerlokaler Bericht vom Februar 2020beschrieb OutofBox.cloud als einen von Belagavi aus gestarteten Dienst und bezeichnete ihn als hundertprozentige Tochtergesellschaft von FAAST Networks. Darin hieß es, der Dienst laufe auf einer angepassten OpenStack-Umgebung, habe zu diesem Zeitpunkt mehr als 100 Server und könne nahezu 300 physische Server aufnehmen. Der Bericht bezeichnete den Standort auch als das erste Rechenzentrum der Marke. Diese Aussagen betreffen einen Betrieb im Jahr 2020 und eine Markenbeziehung vor der Gründung der OUTOFBOX CLOUD PRIVATE LIMITED im Juli 2021. Sie sind eine nützliche Geschichte, aber kein aktuelles Eigentumszertifikat.

Eine zweite juristische Person ist für die Netzwerkerzählung von Bedeutung. APNIC registriert AS141815 aufOutofbox Networks Private Limited, während AS147192 zu Outofbox Cloud gehört. Die Datensätze verwenden dieselbe Sadashiv-Nagar-Straßenadresse und dieselbe Telefonnummer, aber unterschiedliche Netzwerk-Kontakt-E-Mail-Domänen. Unternehmensdatenquellen deuten auf überlappende Direktoren hin, und der Bericht von 2020 beschreibt eine Gruppenbeziehung. Dennoch sind zwei Privatunternehmen zwei juristische Personen. Die Telekommunikationsgenehmigung, Verträge, Schaltkreise und Adressräume des Netzwerkunternehmens können nicht automatisch als Vermögenswerte oder Verbindlichkeiten des Cloud-Unternehmens verbucht werden.

Diese Grenze wird besonders wichtig bei einem Ausfall oder einem Ausscheiden. Wenn ein Kunde Rechenleistung von Outofbox Cloud kauft, aber der erste sichtbare Netzwerkpfad von Outofbox Networks bereitgestellt wird, muss der Kunde wissen, welches Unternehmen den Servicevertrag unterzeichnet, welches die Server besitzt oder least, welches den Einrichtungsvertrag hält, welches die Bandbreite in Rechnung stellt, welches die Netzwerkbetriebsmitarbeiter beschäftigt und welches Unternehmen für die Wiederherstellung verantwortlich ist. Gemeinsame Direktoren, Marken, Adressen oder Telefonnummern können die Koordination erleichtern.

Sie ersetzen keine vertraglichen Rechte.

Die aktuelle öffentliche Website verschwimmt manchmal die Produkt- und Infrastrukturebenen. Sie bewirbt öffentliche Cloud, virtuelle private Cloud, private Cloud, Lastverteilung, verwaltetes Kubernetes, Plattformdienste, SAP-orientiertes Hosting, eine Banking-Community-Cloud, dedizierte Server und Colocation. Einige werden möglicherweise direkt erbracht; einige könnten auf verbundene Infrastruktur oder Lieferanten angewiesen sein. Die öffentlichen Seiten veröffentlichen keine dienstbezogene Eigentumsmatrix.

Dieses Profil schreibt die Produkte daher dem Marketing des Unternehmens und die Nummernressourcen ihren registrierten Inhabern zu, ohne anzunehmen, dass jede Ebene von derselben juristischen Person gehalten wird.

Was physisch in Belagavi belegt ist

Der stärkste aktuelle physische Beleg ist keine Marketingkarte. Es ist ein Bericht vom September 2025 der Abteilung für Künstliche Intelligenz und Data Science am Angadi Institute of Technology and Management. DerAktivitätsnachweisder Abteilung besagt, dass Studenten am 22. September Outofbox Cloud Private Limited in Sadashiv Nagar, Belagavi, besuchten. Er beschreibt die Verwaltung virtueller Maschinen, virtuelle private Clouds und Firewalls und identifiziert dann physische und virtuelle Server, Server-Racks, Kühlung, Notstromversorgung, Router, Switches, Firewalls und Speichersysteme im Rechenzentrums-Setup. Die Abteilung veröffentlichte den Bericht auch in ihremNewsletter 2025-26.

Dies ist eine bedeutungsvolle Bestätigung. Sie zeigt, dass Ausrüstung, die mit dem Unternehmen verbunden ist, am genannten Standort weniger als ein Jahr vor diesem Artikel physisch sichtbar war. Sie ist für den Standort nützlicher als eine IP-Geolokalisierungsdatenbank, da ein institutioneller Besuch einen tatsächlichen Ort betrifft, nicht eine Schlussfolgerung aus Netzwerklatenz oder Registrierungsdaten. DieBelagavi Technology Companies Associationbeschreibt Outofbox Cloud ebenfalls als lokal gehostet und in Indien ansässig, obwohl dieses Verbandsprofil werblich ist und seine Verifizierungsmethode nicht offenlegt.

Die Belege haben dennoch Grenzen. Der Hochschulbericht gibt nicht den genauen Raum, die Grundfläche, die Rack-Anzahl, die Rack-Dichte, die Versorgungsleitung, die USV-Topologie, die Batterieautonomie, die Generatorleistung, die Kraftstoffausdauer, die Kühlleistung, den Brandschutz, die Belegungsgenehmigung oder den Einrichtungsbetreiber des Gebäudes an. Er sagt nicht, ob die betrachteten Systeme Produktionskunden-Workloads trugen, als Trainingslabor dienten oder beide Funktionen mischten. Er identifiziert keine Eigentumsaufkleber auf der Ausrüstung.

Die gemeinsame Straßenadresse erscheint in Unternehmens- und Nummernressourcendatensätzen als Verwaltungskontakt; eine Verwaltungsadresse ist für sich genommen kein Einrichtungszertifikat.

Der Artikel von 2020 liefert Zahlen, aber keinen aktuellen Status. „Mehr als 100 Server“ ist eine Behauptung über installierte Ausrüstung zu einem bestimmten Zeitpunkt. „Nahezu 300 physische Server“ ist eine Behauptung über die Auslegung oder Platzkapazität. Er gibt nicht an, wie viele Rack-Einheiten, Steckdosen oder Kilowatt damals mit Strom versorgt wurden. Er kann nicht zeigen, wie viele Server im Jahr 2026 noch in Betrieb sind, wie viele kundenbereit sind, welcher Anteil reserviert ist oder ob späteres Wachstum Workloads anderswohin verlagert hat.

Der Ausdruck „praktisch unbegrenzt“ virtuelle Maschinen in diesem Bericht sollte als Werbesprache verstanden werden: Jede virtuelle Maschine verbraucht letztlich endliche CPU-, Speicher-, Speicher-, Netzwerk-, Strom- und Kühlungskapazität.

Für dieses Profil wurde kein öffentlicher Datensatz gefunden, der eine zweite Outofbox-Cloud-Einrichtung mit vergleichbaren physischen Belegen identifiziert. Es wurde keine öffentliche Stromgenehmigung, kein Versorgungsanschlusskapazität, keine Generatorgenehmigung, kein Brandschutz-NOC, keine bauliche Rechenzentrumsgenehmigung und keine Umweltmeldung gefunden, die sicher mit der Produktionsfläche des Cloud-Unternehmens in Verbindung gebracht werden könnte. Das Fehlen in einer öffentlichen Suche ist kein Beweis dafür, dass ein Dokument oder eine Genehmigung nicht existiert.

Es bedeutet, dass ein Leser sie nicht verwenden kann, um den Standort zu quantifizieren oder die Acht-Regionen-Behauptung zu testen.

Die Karte sollte daher konservativ gezeichnet werden. Belagavi ist ein unterstützter Betriebsstandort und registrierter Kontaktort. Mumbai ist ein unterstützter logischer Austauschstandort für AS141815 bei NIXI, kein Beweis dafür, dass Outofbox Cloud Server in Mumbai besitzt. Die Bezeichnungen Bengaluru und Chennai, die von kommerziellen IP-Ortsbestimmungswerkzeugen zurückgegeben werden, sind Messschätzungen, keine Einrichtungsadressen. Die verbleibenden beworbenen Regionen sind unbekannt, bis das Unternehmen Städtenamen und die rechtliche oder betriebliche Grundlage für jede einzelne veröffentlicht.

Ein Produktkatalog ist kein Bestand

Die aktuellePreisseitevon Outofbox Cloud macht den Dienst wirtschaftlich greifbar. Sie listet Konfigurationen von einem kleinen Plan mit zwei CPUs, 2 GB RAM, 100 GB NVMe für 630 ₹ pro Monat bis hin zu viel größeren Rechen- und Speicherkombinationen auf. Die Boxes-Seite beschreibt Allzweck-, CPU-optimierte, speicheroptimierte und speicheroptimierte Instanzen und sagt, dass einige Pläne dedizierte Hyper-Threads verwenden. Diese Details zeigen, was das Unternehmen zu verkaufen anbietet. Sie offenbaren nicht die Anzahl oder Generation der physischen Hosts, die Überbuchungspolitik, die Speicherreplikation, das Ersatzteillager oder die Platzierungsregeln hinter den Plänen.

Die Unterscheidung zwischen Katalog und Kapazität ist während eines Ansturms oder Ausfalls am wichtigsten. Ein Plan kann sichtbar bleiben, wenn kein geeigneter Host über freien Speicher verfügt. Ein Steuerungspanel kann eine Bestellung annehmen, während die Hardwarebereitstellung verzögert wird. Eine nominell dedizierte vCPU kann auf Scheduler-Ebene isoliert sein, während sie sich dennoch einen Sockel, Speicherkanäle, Speichercontroller, Top-of-Rack-Switches und Stromversorgungen teilt.

NVMe-Kapazität kann lokal auf einem Host, auf mehrere Hosts repliziert, durch einen Speichercluster gesichert oder von einem separaten Sicherungsdienst wiederhergestellt werden. Die öffentliche Plantabelle löst diese Möglichkeiten nicht auf.

Die Homepage sagt, die Plattform habe mehr als 40 Kunden und mehr als 500 Cloud-Bereitstellungen. Dies sind Zähler aus erster Hand ohne Datum, Definition oder Prüfung. Eine „Bereitstellung“ könnte eine aktive virtuelle Maschine, ein Anwendungsstart, eine historische Bereitstellungsaktion, eine Testumgebung oder ein Kundenprojekt sein. Sie kann nicht in installierte Server oder verkaufte Kapazität umgewandelt werden. Auch erzwingen 512 zugewiesene IPv4-Adressen keine Ein-Adresse-pro-Server-Regel: Adressen können Hypervisoren, virtuellen Maschinen, Netzwerkadressübersetzung, Lastverteilern, Routern, Reserven oder Kunden zugewiesen sein.

Die Website bewirbt auch Lastverteilung. Ein Lastverteiler kann Anfragen auf mehrere Server verteilen, beweist aber keine geografische Redundanz. Die dahinter liegenden Server können sich ein Rack, einen Top-of-Rack-Switch, eine USV, einen Kühlkreislauf, einen Gebäudeeingang und einen vorgelagerten Router teilen. Ebenso bietet eine virtuelle private Cloud logische Isolierung, keine physisch getrennte Cloud. Ein Private-Cloud-Angebot kann auf dedizierter Hardware in einer gemeinsam genutzten Einrichtung laufen. Jedes ist nützlich, aber jedes adressiert eine andere Ausfallschicht.

Damit die Kapazität entscheidungsrelevant ist, müsste der Anbieter die Pläne mit einem Betriebsumfang verbinden: verfügbare Host-Pools nach Region, CPU- und Speicherzuweisungsregeln, Speicherhaltbarkeit, Netzwerkport-Verpflichtungen, Bereitstellungsvorlaufzeiten, Wartungsreserve und den Punkt, an dem „verfügbare“ Kapazität tatsächlich mit Strom versorgt und bereitstellbar ist. Keiner dieser Werte ist öffentlich. Die sichere Schlussfolgerung ist, dass bestimmte Produkte vermarktet werden und die Service-Endpunkte live sind, während der installierte und verfügbare Bestand unbekannt bleibt.

Das öffentliche Netzwerk ist real, kompakt und sichtbar

Der klarste aktuelle Betriebsnachweis ist AS147192. DerAPNIC-Autonome-System-Eintragnennt OOBCLOUD-AS-IN und OUTOFBOX CLOUD PRIVATE LIMITED, markiert den Eintrag als aktiv und zeigt ein Registrierungsdatum vom 13. Oktober 2021. DerAPNIC-Adresseintragweist 103.174.148.0 bis 103.174.149.255 als portablen IPv4-Raum dem Unternehmen zu. Das ist ein /23 mit 512 Adressen. Der Ressourceneintrag hat keinen entsprechenden IPv6-Block.

DieRouting-Status-Beobachtungdes RIPE NCC am 15. Juli 2026 fand ein angekündigtes IPv4-Präfix, 512 Adressen, kein IPv6-Präfix und einen beobachteten Nachbarn. Die Route war für 325 von 326 IPv4-Peers im Routing Information Service sichtbar, was ein starker Beleg für eine breite öffentliche Routensichtbarkeit zu diesem Zeitpunkt ist. Es ist ein Beleg für Erreichbarkeit, nicht für eine globale Betriebspräsenz. DasErgebnis der angekündigten Präfixezeigt 103.174.148.0/23 kontinuierlich im Beobachtungsfenster vom 1. bis 15. Juli.

Die Sichtbarkeit hat eine Geschichte und ist kein Tagesereignis. DieRouting-Historievon RIPE zeigt, dass AS147192 das /23 von November 2021 bis zum aktuellen Abfragefenster ankündigt, vorbehaltlich der Sampling- und Sichtbarkeitsschwellen des Collectorsystems. DasErgebnis der Routenursprungsvalidierungwar gültig, mit einer Route Origin Authorisation, die AS147192 erlaubt, das /23 und Präfixe bis /24 anzukündigen. RPKI-Gültigkeit reduziert eine Klasse von Ursprungsfehlern; sie liefert keine Betriebszeit, Kapazität, Pfaddiversität oder Schutz vor einem autorisierten Betreiberfehler.

Zum Beobachtungszeitpunkt zeigten A-Einträge für die öffentliche Website und den Kundenportal-Hostnamen des Unternehmens auf Adressen innerhalb des /23, das OUTOFBOX CLOUD PRIVATE LIMITED zugewiesen ist: die Hauptseite auf 103.174.148.253 und mycloud.outofbox.cloud auf 103.174.148.14. Dies stellt nur eine punktuelle Zuordnung zwischen diesen Domänennamen und diesem zugewiesenen Bereich her.

Es stellt nicht fest, wem die antwortenden Server oder Anwendungen gehörten oder wer sie betrieb, wo sie physisch gehostet wurden, ob eine der Adressen Anycast war, ob einer der Hostnamen Teil einer Produktionssteuerungsebene war oder ob einer der Dienste eine Ausfalldomäne mit Kunden-Workloads teilte.

DasPeeringDB-Profilvon AS147192 ist hauptsächlich dafür informativ, was es nicht dokumentiert. Der selbstgemeldete Eintrag beschreibt einen Asien-Pazifik-Bereich, ein Verkehrsband von 100-1000 Mbps und 512 IPv4-Adressen. Es listet keine öffentlichen Exchange-Verbindungen und keine Einrichtungen auf und wurde seit Oktober 2022 nicht wesentlich aktualisiert. PeeringDB ist freiwillig; Null-Felder können unentdeckte oder veraltete Informationen bedeuten, nicht physische Abwesenheit. Sie können dennoch nicht zur Untermauerung von acht Regionen verwendet werden.

Das Netzwerk ist daher sowohl echt als auch kompakt. Es hat eine stabile Route, eine gültige Ursprungsautorisierung und live Service-Endpunkte. Dennoch ist die gesamte öffentliche Ursprungsoberfläche ein einziger IPv4-Block ohne sichtbare IPv6-Ankündigung und einen unmittelbaren beobachteten Nachbarn. Die Routenbelege stützen den Betriebsstatus stärker als die Website allein. Sie definieren auch eine enge logische Abhängigkeit, die einer Untersuchung bedarf.

Ein unmittelbarer Nachbar, dann ein breiteres Netzwerk

DieAS147192-Nachbarbeobachtungdes RIPE identifiziert nur AS141815 auf der linken Seite der gesammelten Pfade. Ein zweiter Collector-basierter Bericht erreicht dieselbe grundlegende Topologie. Dies beweist nicht, dass es nur einen physischen Schaltkreis gibt. Private Links, Backup-Sitzungen, durch Richtlinien verborgene Routen und Verbindungen mit zu geringer Collector-Sichtbarkeit erscheinen möglicherweise nicht. Was es beweist, ist, dass die den untersuchten Collectorn zur Verfügung stehende öffentliche Route keine unabhängige First-Hop-Diversität zeigte.

AS141815 ist auf Outofbox Networks Private Limited registriert. DieISP-Genehmigungsliste 2026des indischen Department of Telecommunications führt dieses Unternehmen, nicht Outofbox Cloud Private Limited, mit einer Kategorie-B-Genehmigung für Karnataka und derselben Sadashiv-Nagar-Adresse auf. Dies ist eine wertvolle rechtliche Unterscheidung: Das Netzwerkunternehmen besitzt die offengelegte ISP-Genehmigung, während das Cloud-Unternehmen die sichtbare Cloud-ASN und den Adressblock besitzt. Der öffentliche Datensatz zeigt nicht die zwischengesellschaftliche Vereinbarung, unter der Transit oder Einrichtungen bereitgestellt werden.

Jenseits dieses ersten Nachbarn hat AS141815 mehr Routenoptionen. Dasaktuelle Nachbarergebnisvon RIPE zeigt vier beobachtete Nachbarn: AS45117, AS9730, AS137085 und die Cloud-ASN des Unternehmens AS147192. Sein Routing-Status zeigt vier angekündigte IPv4-/24er und kein sichtbares IPv6. PeeringDB listet einebetriebsfähige 1-Gbps-Verbindung am NIXI Mumbaifür AS141815 auf. Die Existenz mehrerer externer AS-Adjanzen jenseits von AS141815 kann die Routenwahl und die Wiederherstellung nach einem ausgefallenen Upstream-Routing verbessern.

Es beweist dennoch keine physische Redundanz für die Cloud. Zwei Upstream-ASNs können über Glasfasern in einem Kabel, einer Carrier-Übergabe, einem Straßengraben, einem Gebäudeeingang oder einem Router ankommen. Ein Internet-Exchange-Port in Mumbai kann über einen einzelnen Backhaul von Belagavi erreicht werden. Die Cloud-ASN kann über einen einzigen Cross-Connect oder ein einziges Gerät mit der Netzwerk-ASN verbunden sein. Keine öffentliche Quelle identifiziert Schaltungsanbieter, Übergabestandorte, Route-Reflector, Edge-Router-Paare, Glasfaserzugänge, Leitungswege, Schutzumschaltung, garantierte Raten oder Failover-Testergebnisse.

Die Unterscheidung zwischen logischer und physischer Diversität gilt auch für die Geografie. NIXI Mumbai ist ein Austauschpunkt, an dem AS141815 einen Port hat; es ist kein Beleg dafür, dass Outofbox Cloud Rechen- oder Speicherkapazität in Mumbai betreibt. Eine Route kann durch Mumbai verlaufen, während der Workload in Belagavi bleibt. Umgekehrt könnte ein Anbieter Rechenleistung anderswo leasen, ohne sie von AS147192 aus anzukündigen. Netzwerkkarten und AS-Pfade zeigen Paketerreichbarkeit, nicht Serverbesitz.

Für einen Kunden ist die nützliche Frage nicht einfach „Wie viele Upstreams?“, sondern: Welcher Ausfall entfernt den Zugang zu diesem spezifischen Workload? Die Beantwortung erfordert einen Pfad vom Host der virtuellen Maschine und dem Top-of-Rack-Switch über den Einrichtungsrand, die Cloud-Netzwerk-Übergabe, die Fernverbindungen und die Upstream-Anbieter. Das öffentliche Routing offenbart die AS-Ebene in der Mitte dieser Kette. Die Rack-Ebene und die Tiefbau-Enden bleiben unbekannt.

Historische Kapazität kann nicht zur aktuellen nutzbaren Kapazität hochgestuft werden

Die Zahl von mehr als 100 Servern aus dem Jahr 2020 ist die einzige öffentliche Zählung installierter Ausrüstung, die für dieses Profil gefunden wurde. Die Angabe „nahezu 300“ aus demselben Bericht beschreibt, wie viele physische Server das erste Rechenzentrum aufnehmen konnte. Selbst wenn beide zum Zeitpunkt der Veröffentlichung präzise waren, repräsentieren sie unterschiedliche Zustände. Installierte Ausrüstung ist nicht der Designraum. Mit Strom versorgte Ausrüstung ist nicht unbedingt betriebsbereit. Betriebsbereite Ausrüstung ist nicht unbedingt für einen neuen Kunden verfügbar.

Verfügbare Ausrüstung kann bereits reserviert sein oder die CPU-, Speicher-, Speicher- und Netzwerkkombination des Workloads nicht erfüllen.

Keine Quelle aus dem Jahr 2026 gibt die aktuelle Serverzahl an. Keine Quelle gibt Megawatt, Kilowatt, Rack-Anzahl, Rack-Dichte oder Versorgungszuweisung an. Keine Quelle beziffert USV-Module, Generatorleistung, Batteriedauer, Dieselvorrat, Kühlungsredundanz, Power Usage Effectiveness oder Brandschutz. Keine Quelle identifiziert eine N-, N+1-, 2N- oder verteilt-redundante Auslegung. Der Studentenbesuch von 2025 bestätigt, dass Kühlungs- und Notstromlösungen vorhanden waren; er spezifiziert nicht deren Kapazität, Wartungszustand oder Fähigkeit, eine volle Produktionslast während eines längeren Versorgungsausfalls zu tragen.

Der Website-Angabe „acht Rechenzentrenregionen“ fehlt ebenfalls ein Kapazitätsnenner. Eine Region könnte eine vollständig betriebene Unternehmenseinrichtung, ein geleastes Rack, von einer anderen Cloud gemietete Kapazität, ein Edge-Standort, ein geplanter Standort oder ein auswählbares Etikett in einem Steuerungspanel bedeuten. Diese Arrangements schaffen unterschiedliche Verpflichtungen und Ausfallarten. Ohne Regionsnamen und Betreiberangaben kann die installierte Kapazität nicht dem Unternehmen zugeschrieben werden und der Kundenstandort kann nicht bestimmt werden.

Der Adressraum kann ebenfalls leicht überinterpretiert werden. Ein /23 gibt der Organisation 512 IPv4-Adressen, nicht 512 Server. Ein einzelner Server kann viele privat adressierte virtuelle Maschinen hinter einigen öffentlichen Adressen hosten. Ein Kunde kann mehrere öffentliche Adressen erhalten. Einige Adressen werden durch Netzwerk, Broadcast, Gateway, Verwaltung, Reserve oder Anti-Missbrauchsfunktionen verbraucht. Die IPv4-Zahl ist eine nützliche Obergrenze für bestimmte öffentliche Adressprodukte, aber sie ist keine Rechen-, Speicher-, Strom- oder Kundenanzahl.

Die beworbenen Konfigurationen liefern ebenfalls kein Bestandssignal. Ein online angezeigter 32-Core-Plan ist ein Angebot, kein Beweis dafür, dass ein passender Host frei ist. Das Unternehmen kann einen gepoolten Scheduler betreiben, manuell bereitstellen, Ersatzhardware vorhalten oder Kapazität von Partnern zukaufen. Die öffentlichen Seiten sagen es nicht. Die AGB veröffentlichen keine Erfüllungsfrist. Ein potenzieller Käufer sollte eine datierte Kapazitätsbestätigung für die ausgewählte Region und Konfiguration verlangen, einschließlich der Frage, ob die Ressourcen installiert, mit Strom versorgt, getestet und sofort zuweisbar sind.

Die vertretbare Kapazitätsfeststellung ist daher eng. Historisch installierte Kapazität: mehr als 100 Server, berichtet 2020 und nicht unabhängig geprüft. Historische Auslegungskapazität: nahezu 300 physische Server am ersten Belagavi-Standort, berichtet 2020. Aktuelle physische Präsenz: Racks, Server, Kühlung und Notstrom, beobachtet bei einem Bildungsbesuch 2025. Derzeit installierte, mit Strom versorgte, nutzbare, verkaufte, reservierte und freie Kapazität: unbekannt.

Ein 99,99%-Badge braucht eine Uhr, einen Umfang und eine Abhilfe

Die Boxes-Seite bewirbt eine 99,99%ige Verfügbarkeits-SLA. Bei einer Messung über ein 365-Tage-Jahr ohne Ausschlüsse entspricht eine Ausfallzeit von 0,01% etwa 52,6 Minuten. Bei monatlicher Messung sind es in einem 30-Tage-Monat etwa 4,4 Minuten. Echte Service-Level-Vereinbarungen definieren den Messzeitraum, die gemessene Komponente, was als nicht verfügbar gilt, Wartungsausschlüsse, Kundenpflichten, Anspruchsfenster und Servicegutschriften. Ein Prozentsatz ohne diese Bedingungen kann einem Kunden nicht sagen, welche Abhilfe auf einen Host-, Speicher-, Netzwerk- oder Steuerungsebenenausfall folgt.

Die öffentlichenAllgemeinen Geschäftsbedingungendes Unternehmens schaffen zusätzliche Unsicherheit. Sie sagen, das Unternehmen strebe nach Verfügbarkeit und Sicherheit, garantiere aber keinen unterbrechungsfreien oder fehlerfreien Betrieb, und lehnen die Haftung für die Unfähigkeit zur Nutzung der Dienste ab. Eine separate unterzeichnete Servicebestellung kann diese Website-Bedingungen überstimmen oder ergänzen. Es wurde kein öffentlicher SLA-Zeitplan, keine Gutschriftstabelle und kein Statusverlaufsarchiv gefunden, um den Marketingprozentsatz mit dem Haftungsausschluss in Einklang zu bringen.

Der Umfang ist entscheidend. Die Verfügbarkeit von Rechenleistung kann das Betriebssystem eines Kunden ausschließen. Die Hostverfügbarkeit kann mit einem unerreichbaren Netzwerk koexistieren. Die Netzwerkverfügbarkeit kann mit Speicherkorruption koexistieren. Eine regionale SLA kann einen gleichzeitigen Multi-Region-Ausfall ausschließen, während eine in nur einer Region bereitgestellte virtuelle Maschine keine geografische Wiederherstellung hat. Der Sicherungserfolg ist kein Wiederherstellungserfolg. Die Supportverfügbarkeit garantiert keine Wiederherstellungszeit.

Für Outofbox Cloud ist die SLA-Frage direkt mit den Netzwerk- und Einrichtungsbelegen verbunden. Gilt die 99,99% für jede einzelne Box, den Hypervisor-Pool, den ersten Netzwerksprung, das Steuerungspanel, den Speicher oder alle? Wird sie von externen Sonden gemessen? Sind die acht Regionen separate SLA-Bereiche? Zählt ein Ausfall von AS141815? Zählt geplante Wartung in der Belagavi-Einrichtung? Welche Gutschrift ist verfügbar, und ist die einzige Abhilfe des Kunden eine Gutschrift? Bis ein Vertrag diese Fragen beantwortet, ist das Badge eine Marketingbehauptung und keine quantifizierte Wiederherstellungsgarantie.

Wie der Dienst ausfallen kann

Der erste Ausfallpfad ist die Einrichtungsstromversorgung. Eine Versorgungsunterbrechung sollte die kritische Last auf die USV und dann auf die Stromerzeugung oder eine andere Versorgung übertragen. Der Besuch von 2025 stützt das Vorhandensein einer Notstromversorgung, aber keine öffentliche Quelle gibt die Autonomie oder Redundanz an. Ein Generator kann starten, Kraftstoff ausgehen, überhitzen oder nur einen Teil der Last tragen. Batterien können degradiert sein. Schaltanlagen können einen gemeinsamen Ausfallpunkt schaffen.

Wenn der Standort eine Versorgungsleitung oder einen Verteilungspfad hat, können mehrere Geräte gleichzeitig ausfallen, selbst wenn einzelne Server über doppelte Netzteile verfügen.

Der zweite Pfad ist die Kühlung. Server können elektrisch mit Strom versorgt bleiben, während thermische Grenzen Abschaltungen oder Drosselungen erzwingen. Eine kompakte Einrichtung benötigt ausreichende Kühlung für die tatsächliche Rack-Dichte, nicht nur für die nominale Raumfläche. Redundante Klimaanlagen können sich dennoch Steuerungen, Kondensatoren, Pumpen oder Strom teilen. Der Bildungsbesuch bestätigt Kühlgeräte, aber nicht deren Leistung, Redundanz oder Wartung. Ein Kunde kann aus dem Vorhandensein eines Kühlgeräts nicht auf thermische Widerstandsfähigkeit schließen.

Der dritte Pfad ist der Netzwerkzugang. Der eine öffentlich sichtbare Nachbar von AS147192 bedeutet, dass die Route der Cloud das beobachtete Internet durch AS141815 erreicht. Ein zweiter Upstream jenseits von AS141815 kann helfen, wenn ein Anbieterpfad ausfällt, aber nicht, wenn die Cloud-zu-Netzwerk-Übergabe, der gemeinsame Edge-Router, der Belagavi-Backhaul oder der Gebäudeeingang ausfällt. Die Routenursprungsautorisierung schützt die Legitimität des Ursprungs, nicht die Verfügbarkeit. Eine gültige Route kann dennoch zurückgezogen, gefiltert oder unerreichbar sein.

Der vierte Pfad ist der Verwaltungszugang, dessen Architektur unbekannt ist. Die Website- und Kundenportal-Domänennamen zeigten während der Beobachtung in den zugewiesenen /23 des Unternehmens, aber diese Tatsache identifiziert nicht den Server- oder Anwendungsbesitz, das physische Hosting, eine Produktionssteuerungsebenenrolle oder einen gleichzeitigen Ausfall mit Kunden-Workloads. DNS, Authentifizierung, Abrechnung und Support werden nur dort zu Verfügbarkeitsabhängigkeiten, wo die tatsächliche Architektur sie dazu macht.

Ein Kunde würde eine Architekturbeschreibung und getestete Out-of-Band-Verfahren benötigen; der öffentliche Datensatz liefert keines von beiden.

Der fünfte Pfad ist der Speicher. Die Preisseiten bewerben NVMe-Mengen und wöchentliche Backups bei einigen Webhosting-ähnlichen Plänen, erklären aber keine Replikation für Boxes. Lokales NVMe kann eine hervorragende Leistung liefern und setzt eine virtuelle Maschine gleichzeitig einem Host-Level-Ausfall aus, es sei denn, die Daten werden anderswo repliziert. Ein replizierter Speichercluster kann einen Laufwerks- oder Knotenausfall überleben, aber nicht unbedingt einen Gebäudeausfall oder Betreiberfehler. Ein wöchentliches Backup begrenzt das Wiederherstellungspunktziel nur, wenn es erfolgreich, isoliert, aufbewahrt und wiederherstellbar ist.

Die Website veröffentlicht keine Wiederherstellungstests oder Backup-Standortdetails.

Der sechste Pfad ist der Hardwarebestand. Ein kleiner regionaler Anbieter kann nahen Support und attraktive Preise bieten, aber die Ersatzzeit hängt von Ersatzlaufwerken, Netzteilen, Speicher, Netzwerkkarten, Switches und vollständigen Hosts ab. Das Unternehmen veröffentlicht keinen Teilebestand oder Herstellersupport. Eine ausgefallene Komponente kann in Minuten ersetzt werden, wenn ein Ersatzteil vor Ort ist, oder in Tagen, wenn es beschafft werden muss. Die in einer Plantabelle beworbene Kapazität begründet keinen Reparaturbestand.

Der siebte Pfad sind Mitarbeiter und Eskalation. Die Website bewirbt 24/7-Überwachung und -Support, aber die öffentlichen Bedingungen definieren keine Reaktions- oder Wiederherstellungsziele. Eine echte Eskalationskette erfordert einen anerkannten Vorfall, einen technischen Verantwortlichen, eine Kommunikationsfrequenz und die Befugnis, einen Workload zu verschieben oder Ausrüstung zu ersetzen. Die Größe des Bereitschaftsteams, die Trennung des Netzwerkbetriebs, das Zugriffskontrollmodell und der Zugang zur Einrichtung außerhalb der Geschäftszeiten sind unbekannt.

Kundenreferenzen auf der Homepage sind nützliche Marktsignale, aber sie werden vom Unternehmen ausgewählt und ersetzen keine Vorfallstatistiken.

Der achte Pfad ist Abrechnungs- oder Vertragsausfall. Eine technisch gesunde virtuelle Maschine kann unverfügbar werden, wenn ein Konto gesperrt wird, eine Zahlung bestritten wird, eine Missbrauchsbeschwerde falsch behandelt wird oder die liefernde juristische Person die Bedingungen ändert. Die Website-Bedingungen räumen sich weites Ermessen ein und schränken Garantien ein. Kunden benötigen Kündigungsfristen, Eskalation bei Streitigkeiten, Datenexportrechte und eine definierte Gnadenfrist. Regulierte oder kritische Kunden benötigen auch Klarheit über Subunternehmer und welche juristische Person auf Daten zugreifen kann.

Der neunte Pfad ist die Migration. Die Fähigkeit, eine virtuelle Maschine schnell zu starten, ist nicht dasselbe wie die Fähigkeit, schnell zu gehen. Images können von proprietären Netzwerken, verwalteten Datenbanken, Objektspeichern, Snapshots oder Identitätsdiensten abhängen. Große Datenmengen benötigen Zeit und Bandbreite für den Export. Ausgehende Gebühren, Image-Formate, API-Kompatibilität und Löschbestätigung sind nicht öffentlich beschrieben. Ohne einen getesteten Export bleibt der Kunde während eines Vorfalls sowohl von der Plattform als auch von deren Support-Team abhängig.

Der zehnte Pfad ist die korrelierte Geografie. Wenn die belegten Server, die Steuerungsebene, die Cloud-Netzwerk-Übergabe und die Mitarbeiter in Sadashiv Nagar konzentriert sind, könnte ein einziges gebäudebezogenes Ereignis sie alle gleichzeitig betreffen. Die Website behauptet acht Regionen, aber keine öffentliche Quelle erlaubt es einem Kunden, zwei benannte Einrichtungen auszuwählen und zu überprüfen, ob sie separate Betreiber, Stromnetze, Überschwemmungsgebiete, Backhaul-Routen und Steuerungsebenen haben.

Die Multi-Server-Platzierung in einem Raum ist eine nützliche Verfügbarkeitstechnik; sie ist keine geografische Notfallwiederherstellung.

Dies sind Szenarien, keine Behauptungen, dass eines davon eingetreten ist. Sie zeigen, warum eine aktuelle Route und ein fotografiertes Rack notwendige, aber unzureichende Belege für die Widerstandsfähigkeit sind. Zuverlässigkeit hängt davon ab, wie die Schichten verbunden sind und was der Anbieter unter Ausfall getestet hat.

Bankensprache erhöht den Sorgfaltsstandard

Outofbox Cloud bewirbt eine Banking Community Cloud und sagt, seine Plattform sei für compliance-sensitive Workloads geeignet. Diese Sprache beweist nicht, dass eine Bank den Dienst nutzt oder dass die Plattform eine bestimmte Prüfung bestanden hat. Sie macht die fehlenden Details jedoch folgenreicher. Ein reguliertes Finanzinstitut kann die Verantwortung nicht einfach durch den Kauf eines für Banken vermarkteten Dienstes auslagern.

DieRichtlinien der Reserve Bank of India zur Auslagerung von IT-Dienstleistungen von 2023beziehen ausdrücklich Cloud Computing und Rechenzentrumsdienste ein. Sie verlangen von betroffenen regulierten Unternehmen, eine Due Diligence durchzuführen, Lieferkettenabhängigkeiten abzubilden, Service-Level zu überwachen, Geschäftskontinuitäts- und Notfallwiederherstellungsvereinbarungen zu treffen, Prüfungs- und Zugriffsrechte zu wahren und einen Ausstieg zu planen. Der Cloud-Anhang behandelt den Datenlebenszyklus und die Bewegung von Cloud-gehosteten Diensten. Diese Pflichten liegen in erster Linie beim regulierten Kunden, aber ein Anbieter muss in der Lage sein, die Belege und vertraglichen Rechte zu liefern, die der Kunde benötigt.

DieCybersicherheitsrichtlinien von CERT-In von 2022gelten für Dienstanbieter, Rechenzentren, VPS-Anbieter und Cloud-Anbieter. Sie umfassen Zeitsynchronisation, sechsstündige Meldung für bestimmte Vorfälle, eine rollierende 180-Tage-Protokollpflicht innerhalb Indiens und die Aufbewahrung bestimmter Kundenregistrierungsinformationen für fünf Jahre nach Kündigung oder Entzug. Dieses Profil hat keine öffentlichen Compliance-Bestätigungen von Outofbox Cloud gefunden. Diese Abwesenheit beweist keine Nichteinhaltung; diese Kontrollen können intern sein. Ein Kunde sollte fragen, wie die Verpflichtungen umgesetzt werden und wie sie mit Datenschutz, Zugriffskontrolle und Löschungszusagen interagieren.

DieDatenschutzseitedes Unternehmens beantwortet diese Unternehmensfragen nicht. Sie enthält sichtbar generischen WordPress-„Vorschlagstext“ über Kommentare, Cookies, Medien und Benutzerprofile. Sie identifiziert nicht den juristischen Namen des Unternehmens, die Rechenzentrumsregionen, die Unterauftragsverarbeiter, die Cloud-Dienst-Telemetrie, den Aufbewahrungszeitplan, den Sicherheitskontakt, die Handhabung von Kunden-Workloads oder grenzüberschreitende Übermittlungen. Eine unterzeichnete Datenverarbeitungsvereinbarung kann diese Details liefern, aber die öffentliche Seite sollte nicht als Cloud-spezifische Datenschutzerklärung behandelt werden.

Für eine Bank oder einen anderen kritischen Kunden ist die praktische Anforderung ein Belegpaket: benannte Standorte und Betreiber; Subunternehmer; Datenort und -bewegungsregeln; Sicherheitszertifizierungen und -umfang; Penetrationstest- und Prüfungszusammenfassungen; Vorfallhistorie; Backup- und Wiederherstellungstests; Wiederherstellungszeit- und Wiederherstellungspunktverpflichtungen; Strom- und Netzwerktopologie; Mitarbeiterzugriffskontrollen; Schlüsselverwaltung; Löschungsbelege; und ein Exit-Runbook.

Der kompakte lokale Fußabdruck des Anbieters könnte ein Vorteil für Residenz und Support sein, aber nur, wenn der Kunde überprüfen kann, wo sich Daten und Kopien tatsächlich befinden.

Datenlokalität wird auf Länderebene gestützt, nicht in Acht-Regionen-Auflösung

Die Belege verbinden Outofbox Cloud stark mit Indien. Das Unternehmen ist in Karnataka registriert. APNIC markiert seine Nummernressourcen in Indien. Die physischen Berichte verweisen auf Belagavi. Das verbundene Netzwerkunternehmen besitzt eine Karnataka-ISP-Genehmigung. Die öffentliche Route und die Service-Endpunkte sind aktiv. Diese Fakten stützen eine Indien-zentrierte Betriebsidentität.

Sie etablieren nicht den Standort jedes Workloads. Ein IP-Registrierungsland ist keine Serverkoordinate. Ein Kunde kann auf Hardware platziert werden, die dem Anbieter gehört, in geleasten Racks, in Partnerkapazität oder einer anderen Cloud. Backups können sich anderswo befinden. Die acht beworbenen Regionen sind unbenannt. Das Wort „global“ auf einer Produktseite kann die Verkaufsreichweite oder Internet-Erreichbarkeit beschreiben, nicht die Rechenzentrumsgeografie.

Dies ist wichtig für Datensouveränität und Latenz. Ein Kunde, der eine Residenz in Karnataka anstrebt, sollte einen Vertrag erhalten, der die Stadt und die Einrichtungsgrenze nennt, und sich nicht auf die Adresse des Unternehmens verlassen. Ein Kunde, der eine indische Residenz anstrebt, sollte Primärdaten, Replikate, Snapshots, Protokolle und Supportzugriff identifizieren. Ein Kunde, der eine geografische Wiederherstellung anstrebt, sollte einen zweiten Standort identifizieren und dort eine Wiederherstellung testen. Der Beleg, der einen Standort etabliert, kann nicht zu einem Beleg für acht ausgedehnt werden.

Was die Behauptung in Infrastrukturbelege verwandeln würde

Outofbox Cloud könnte die öffentliche Bewertung wesentlich verbessern, ohne sensible technische Details preiszugeben. Erstens könnte es eine Liste von acht Regionen mit Stadt, Land, Startstatus, ob die Kapazität unternehmenseigen oder partnerbetrieben ist und welche Dienste in jeder verfügbar sind, veröffentlichen. Ein als geplant markierter Standort sollte von einem Standort, der Produktions-Workloads annimmt, getrennt werden.

Zweitens könnte es einen Service-Level-Zeitplan veröffentlichen. Dieses Dokument sollte die gemessene Komponente, die Beobachtungsmethode, die Wartungsausschlüsse, das Anspruchsverfahren und die Gutschriften definieren. Eine Statusseite mit historischen Vorfällen und regionsbezogenen Komponenten würde es Kunden ermöglichen, den Prozentsatz mit der Betriebsgeschichte zu vergleichen. Eine Aussage, dass die Bedingungen durch eine unterzeichnete SLA ersetzt werden, würde den aktuellen Haftungsausschluss in Einklang bringen.

Drittens könnte es eine hochrangige Widerstandsfähigkeitsauslegung für den Belagavi-Standort bereitstellen: Anzahl der Versorgungsleitungen, USV- und Generator-Redundanzklasse, minimale Kraftstoffautonomie, Kühlungsredundanz, Brandschutz, Rack- und Leistungsumfang, Netzwerkrandauslegung und das Datum des letzten Failover-Tests. Genaue Schaltungswege und sicherheitsrelevante Details müssen nicht öffentlich sein. Datierte, unabhängig bestätigte Zusammenfassungen würden ausreichen, um installierte, mit Strom versorgte und nutzbare Kapazität zu unterscheiden.

Viertens könnte es die Grenze zu Outofbox Networks Private Limited und FAAST Networks klären. Kunden müssen wissen, wer den Transit bereitstellt, wer die Telekommunikationsgenehmigung besitzt, wer die Edge-Ausrüstung betreibt, ob die Vereinbarung eine verbundene Unterauftragsvergabe ist und was passiert, wenn sich diese Lieferbeziehung ändert. Die Routendaten machen die Abhängigkeit bereits sichtbar; eine vertragliche Offenlegung würde sie handhabbar machen.

Fünftens könnte es Portabilitätsdetails veröffentlichen: unterstützte Image-Exporte, Snapshot-Formate, API-Dokumentation, Ausgangskosten, Bandbreitenlimits, Löschungsverfahren und getestete Wiederherstellung in eine andere Region oder einen anderen Anbieter. Portabilität ist kein sekundäres Merkmal für eine kleine Cloud. Sie ist Teil der Widerstandsfähigkeit, weil sie einem Kunden einen Wiederherstellungspfad gibt, wenn der Anbieter, die Einrichtung oder der Vertrag die Ausfalldomäne ist.

Schließlich könnte es seine Kapazitätsangaben datieren. Eine vierteljährliche Aufstellung der in Betrieb befindlichen Hosts, der verkaufbaren Ressourcenpools, der reservierten Kapazität und des Wartungsbestands pro Region wäre ungewöhnlich transparent. Selbst eine weniger detaillierte Angabe, unabhängig bestätigt und klar gekennzeichnet, wäre besser, als zuzulassen, dass die 300-Server-Designzahl aus einem Bericht von 2020 eine Interpretation im Jahr 2026 trägt, die sie nicht stützen kann.

Die Betriebsschlussfolgerung

Outofbox Cloud ist nicht nur ein Name in einem Firmenverzeichnis. Es hat ein seit langem sichtbares autonomes System, einen gültig autorisierten IPv4-Ursprung, öffentliche Domänennamen, die zum Beobachtungszeitpunkt in seinen zugewiesenen /23 aufgelöst wurden, und aktuelle unabhängige Belege für physische Cloud-Ausrüstung in Belagavi. Der lokale Betriebsfall ist glaubwürdig, während die DNS-Assoziation weder den Serverbesitz noch den Hosting-Standort identifiziert.

Der öffentliche Netzwerkfall ist ebenfalls klar: AS147192 kündigt einen /23 an und erreicht das beobachtete Internet durch einen unmittelbaren AS-Nachbarn, die rechtlich eigenständige, aber eng verbundene Outofbox Networks Private Limited.

Die größere Widerstandsfähigkeitsbehauptung ist noch nicht belegt. Acht Rechenzentrenregionen werden beworben, aber nicht benannt. Eine 99,99%ige SLA wird angezeigt, aber nicht öffentlich definiert. Ein historischer Bericht gibt eine installierte Zahl und eine Auslegungsobergrenze, aber die aktuelle mit Strom versorgte und nutzbare Kapazität ist unbekannt. Racks, Kühlung und Notstrom wurden gesehen, aber ihr technischer Umfang und ihre Ausfalltoleranz sind unbekannt. Eine breitere Konnektivität hinter AS141815 existiert, aber die physische Routen- und Einrichtungsdiversität ist unbekannt.

Das hinterlässt eine praktische, faire Lesart. Outofbox Cloud kann als kleiner Indien-zentrierter Anbieter mit einem belegten Belagavi-Fußabdruck und einem betriebsfähigen öffentlichen Netzwerk bewertet werden. Es sollte noch nicht anhand öffentlicher Belege als eine Cloud mit acht Regionen und nachgewiesener geografischer Ausfallsicherung bewertet werden. Kunden können diese Lücke durch Verträge, Standort- und Architekturbelege, Kapazitätsbestätigung, Wiederherstellungstests und eine echte SLA schließen. Bis dahin ist die wichtigste Infrastrukturtatsache nicht, wie schnell eine Box gestartet werden kann.

Es ist, wie viele unabhängig überlebensfähige Orte diese Box am Laufen halten können, wenn Belagavi, der erste Netzwerksprung oder das liefernde Unternehmen ausfällt.