Logosys Cloud: Drei Stadtlabels, ein geroutetes /24 und Mumbai-Anbindung

Zusammenfassung

• Das eigeneNetzwerk-Looking-Glassvon Logosys Cloud nennt Hyderabad DC1, Mumbai DC1 und Chennai DC1, benennt jedoch nicht die Gebäude, Rack-Eigentümer, Leitungen, Stromtopologie oder das Serviceinventar hinter diesen Labels.
• APNIC weist Logosys Cloud dieAS150636und den portablen Block103.89.46.0/23zu. Am 15. Juli 2026 zeigte dieRIPEstat-Ansichtnur103.89.46.0/24als aktiv announced, ohne sichtbaren IPv6-Raum. Diese Route war für RIPE-RIS-Peers vollständig sichtbar und verfügte über eine gültige RPKI-Autorisierung.
• PeeringDB führteinen operativen 1-Gbps-Port bei DE-CIX Mumbai und ein Interconnection-Standort auf Web Werks Mumbai 1 auf.APNIC nennt beiAS133296Web Werks India Pvt. Ltd.; aktuelle BGP-Beobachtungen machen dieses ASN zum dominanten Nachbar-AS, doch kein Befund beweist, dass jeder Logosys-Dienst nur einen Standort oder einen Carrier nutzt.
• Produktseiten werben mit bis zu 100 Gbps Ports, vier Points of Presence, fünf indischen Internet-Exchange-Punkten, globalen Streaming-Servern und Colocation in Indien und den Vereinigten Staaten. Öffentliche Belege legen weder die installierte Flottengröße, Kundenzuweisungen, standortbezogene Kapazität, reservierte Leistung noch eine getestete Multi-Site-Wiederherstellung offen.

Die aufschlussreichste Seite ist die kleinste

Die Logosys Cloud-Seite, die am meisten über die Infrastruktur aussagt, ist nicht der Dedicated-Server-Katalog mit den großen Bandbreitenzahlen. Es ist eine kompakte Diagnoseseite auf einem Hostnamen, der mitlg-hyderabadbeginnt. Oben zeigt dasLogosys-Looking-Glassdrei Bezeichnungen: Hyderabad DC1, Mumbai DC1 und Chennai DC1. Es bietet Ping-, Traceroute- und Testdateifunktionen. Die Seite ist ein brauchbares Signal, dass der Betreiber Kunden den Blick auf die Netzwerkleistung ermöglichen will, doch die Stadtlabels sind keine Karte besessener Rechenzentren. Sie benennen weder Eigentümer, Straßenadresse, Raum, Cage, Router, Stromanbindung noch die verfügbaren Service-SKUs pro Stadt.

Diese Unterscheidung ist wichtig, weil der Rest des Logosys-Katalogs ein deutlich größeres mentales Bild erzeugt. DieDedicated-Server-Seitenennt vier Points of Presence und fünf Internet-Exchanges in Indien. Sie beschreibt Standard-1-Gbps-Ports, 10 Gbps für leistungsstärkere Server und bis zu 100 Gbps für ein Ultra-High-Bandwidth-Tier. DieLive-Streaming-CDN-Seitespricht von 20 Streaming-Servern weltweit. DieColocation-Seitenennt Standorte in Indien und den Vereinigten Staaten. DieÜber-uns-Seitebeschreibt ein Self-Service-Angebot mit VMs, dedizierter Compute, GPUs, Object Storage, Load Balancing, Firewalls, VPCs, DBaaS, reservierter IPv4 und Backup.

Jede Aussage kann einen Teil des Service-Portfolios beschreiben. Keine erklärt allein, wo eine konkrete VM betrieben wird, welches Unternehmen den Server besitzt, ob zwei beworbene Standorte Gebäude oder Carrier teilen, wie viel Kapazität installiert ist oder ob Restkapazität im Fehlerfall nutzbar bleibt. Öffentliche Netzwerkbeweise liefern eine robustere, aber kleinere Antwort. Sie liefern ein einziges AS, ein derzeit geroutetes IPv4-/24-Netz, eine benannte Austauschverbindung und eine benannte Einrichtung in Mumbai. Die richtige Lesart ist weder „die Webseite ist das Netzwerk“ noch „alles, was nicht in BGP sichtbar ist, existiert nicht“.

Produktabdeckung, logische Reichweite und physische Resilienz sind getrennte Behauptungen mit getrenntem Nachweisbedarf.

Ein Cloudunternehmen von 2022 mit älterer Broadcast-Herkunft

Die rechtliche Identität beginnt am 8. April 2022. In einer Kundenportal-Inkorporationsmeldungteilte das Unternehmen mit, dass Logosys India fortan Logosys Cloud Private Limited heißt, und nannte die FirmennummerU72900TG2022PTC161383. In der Bekanntmachung wurde Ashwin Kumar als Gründer und Managing Director genannt und eine Adresse in Kothapet, Hyderabad angegeben. APNICs Registrierung fürAS150636verwendet denselben Firmennamen und dieselbe Adresse in Hyderabad, wodurch die Rechtsperson deutlicher als nur eine Markenbezeichnung mit der öffentlichen Netznummer verknüpft wird.

Die Entwicklung vor 2022 ist komplexer. Laut About-Page sagt Logosys Cloud, dass das Unternehmen 2013 als Anbieter für vertraglose Rechenleistung begann. Eine separate Gesellschaft, Logosys Software Solutions Private Limited, wird inToflers Unternehmensprofilmit dem Gründungsdatum 22. März 2013 unter der CINU72200TG2013PTC086572geführt; das Profil nennt Ashwin Kumar und Moti Singh Purohit als Direktoren und dieselbe registrierte Adresse in Kothapet, Hyderabad. Die Website der Softwarefirma bietet Fernsehsendeprodukte für Playout an. Der aktuelleTerms-of-Service-Textvon Logosys Cloud nennt Logosys Cloud Private Limited als Service Provider, verlangt im Zahlungsabschnitt bei Überweisung, Scheck oder Bankwechsel die Begünstigung Logosys Software Solutions Private Limited. Die Daten zeigen also eine gemeinsame Adresse, das Auftreten von Ashwin Kumar in den Datensätzen beider Gesellschaften und eine Zahlungsanweisung. Sie belegen nicht die aktuelle Beteiligungsstruktur, Mutter-Tochter-Beziehung, Eigentümerschaft an Assets oder einen konzerninternen Leistungsvertrag.

Das ist keine reine Formalie. Ein Kunde, der einen Server kauft, sollte wissen, welche Gesellschaft Bestellung und Vertrag unterschreibt, Rechnungen stellt, Gelder erhält, Hardware besitzt oder least, das Support-Personal beschäftigt und eventuelle Service-Credits gewährt. Die Ankündigung 2022 sagt, dass Produkte, Services, Website und Kontaktnummern nach der Namensänderung gleich blieben, doch die fortdauernde Nennung der älteren Softwaregesellschaft als Zahlungsempfänger macht die vertragliche Grenze auf Basis von Unterlagen schriftlich zu bestätigen.

Der hier geprüfte Datensatz offenbart keine konsolidierte Konzernstruktur oder geprüfte Jahresabschlüsse für den Cloudbetrieb. Daher ist Logosys Clouds Eigentümerschaft außerhalb der benannten Direktoren aus den vorliegenden Belegen unbekannt.

Diese ältere Broadcast-Linie erklärt jedoch, warum der Katalog kein generischer Nachbau eines Commodity-Hosts ist. Logosys verkauft Streaming-Bandbreite, Remote-Playout-Server, FTP für Nachrichtensender, Playout-Softwarelizenzen und Managed Distribution neben VPS und Webhosting. In derRemote-Playout-Übersichtwerden ein 32-Core-Server mit 256 GB, SSDs, 10 TB Transfer und einer Nvidia-Quadro-GPU zusammen mit Logosys-Playout-Software kombiniert. Das ergibt eine klare operative Nische: Ein regionaler Broadcaster kann Software, Compute, Streaming und Support bei einem einzigen Geschäftspartner beziehen. Dadurch bündelt sich aber auch der Ausfall von mehreren Risikokomponenten bei demselben Counterpart.

Was das Unternehmen tatsächlich verkauft

Logosys Cloud deckt vier eng verbundene Märkte ab. Erstens Shared- und Reseller-Hosting, bei dem viele Kunden einen Server teilen und auf Control Panel, Webstack und Support-Team angewiesen sind. Zweitens virtuelle Infrastruktur, einschließlich KVM-VPS-Produkte und eine On-Demand-Oberfläche. Drittens physische Kapazität mit Dedicated-Servern und Rack-Unit- oder Vollrack-Colocation. Viertens Video-Infrastruktur einschließlich Live-Streaming, CDN-Vertrieb und Remote Playout.

Die Breite wird im Kundenportal sichtbar. DieCloud-Hosting-Oberflächewirbt mit Projektgruppen, On-Demand-VMs, Cloud-Init-Bereitstellung, Browser-Terminalzugriff, Rebuilds und einer REST-Schnittstelle. Das sind relevante Control-Plane-Funktionen. Sie erlauben es dem Kunden, Compute zu erstellen und zu löschen, ohne auf einen Techniker zu warten, vorausgesetzt zugrunde liegender Knoten, Speicher, Netzwerk und Lizenzbestand sind vorhanden. Die Seite gibt jedoch nicht an, wie viele Hypervisor-Hosts existieren, welche Overcommit-Richtlinie gilt, wie Replikation des Speichers erfolgt, welche Platzierungsregeln gelten oder welche Regionen im Selektor verfügbar sind.

DieVPS-Seitenennt KVM-Tarife von zwei bis vier Cores, 2 GB bis 8 GB RAM und 30 GB bis 240 GB Datenträger, mit monatlichem Transfer bis zu 3 TB. Sie nennt ebenfalls Dell-Server, DDoS-Schutz und 99,9 Prozent Uptime-Ziel. Der öffentliche Warenkorb zeigt jedoch derzeit nur einStarter-VPSab INR 1.550 pro Monat und stellt nicht dieselben Ressourcendetails bereit. Die Marketingseite startet bei INR 1.000. Ein Käufer kann aus diesen Seiten nicht erkennen, ob es sich um unterschiedliche Generationen, Standorte, Aktionspreise oder lediglich unsynchronisierte Kataloge handelt.

Dedizierte Hardware ist auf SKU-Ebene ebenfalls konkret, auf Flottenebene aber undurchsichtig. Die Hauptseite listet Intel-E3- und E5-Konfigurationen mit 1 Gbps-Uplinks und Transfer-Paketen. Der aktuelleDedicated-Server-Eintragbietet 128 GB RAM, zwei 480-GB-SSDs, 10 TB bei 1 Gbps und fünf IP-Adressen für INR 12.700 pro Monat. Doch der Titel nennt 48 Cores, während die Beschreibung einen E5-2680 v4 mit 28 Cores nennt. Diese Abweichung ist kein Beleg für fehlende Kapazität, aber Grund genug, eine finale Bill of Materials zu verlangen statt die Kartenbeschreibung als technische Spezifikation zu werten.

Der Unterschied zwischen verkäuflicher Konfiguration und installierter Flotte ist fundamental. Ein Produktkachel kann vorgerüstet werden, bevor Hardware eingerackt ist, kann nach Bestandserschöpfung weiter sichtbar bleiben oder eine hardwarebeschaffte Bestellung auf einem anderen Zeitpunkt beschreiben. Logosys selbst markiert eine E5-Konfiguration als „Sold out“, während andere Konfigurationen auswählbar bleiben. Einen öffentlichen Bestandszähler, eine serialisierte Hardwareliste, Rack-Anzahl oder Lieferfrist gibt es nicht. Die nutzbare Dedicated-Kapazität bleibt unbekannt.

Die Karte hat drei verschiedene Ortstypen

Öffentliche Verweise auf Hyderabad, Mumbai und Chennai sollten nicht auf eine gemeinsame Karte ohne erläuternde Legende gesetzt werden.

Hyderabad bleibt der stärkste Identitätsstandort. Er ist in der Gründungsmitteilung, in APNIC-Datensätzen und in Unternehmensrichtlinien als registrierte und Kontaktadresse genannt. Auch das Looking-Glass-Hostname nutzt Hyderabad, und die Seite zeigt Hyderabad DC1. Eine Adresse in Kothapet ist jedoch kein Beweis, dass Produktionsserver in genau diesem Gebäude stehen. Das Looking Glass verweist nur auf eine Städtekartensuche, nicht auf einen benannten Rechenzentrumsbetreiber oder eine konkrete Einrichtung.

Die öffentliche Evidenz legt nicht fest, ob Hyderabad DC1 ein eigenes Zimmer, ein gemietetes Cage, ein Wholesale-Space, ein Remote-Knoten oder eine labelhafte Standortbezeichnung für Leistungen über einen anderen Betreiber ist.

Mumbai bleibt der stärkste Interconnection-Standort. DerPeeringDB-Eintrag von LogosysnenntAS150636auf Web Werks Mumbai 1 sowie einen 1 Gbps-Port bei DE-CIX Mumbai. DerEintrag der Einrichtungverortet Web Werks Mumbai 1 im Sigma IT Park in Rabale, Navi Mumbai, und nennt vier im Gebäude verfügbare Exchanger. Das ist ein guter Hinweis auf eine gemeldete operative Netzpräsenz. PeeringDB wird von Netzteilnehmern gepflegt und ist kein Ausstattungsaudit, daher lässt es keine Aussage über die Anzahl von Logsiy-Racks, Servern oder Cross-Connects zu.

Web Werks liefert einen wichtigen Kontext zur Gebäudegrenze. Die aktuelleIndia-Data-Center-Seitebeschreibt Mumbai 1 als 2,3-MW-Zweckbau mit N+N-Redundanz. Das sind Betreiberangaben für das gesamte Gebäude. Sie dürfen nicht automatisch auf Logosys übertragen werden. Ein Mandant kann einen Bruchteil eines Cabinets oder mehrere Racks nutzen; er kann eine oder zwei Strompfade kaufen; er kann an einen Carrier, ein Exchange-Fabric oder mehrere Netze angebunden sein. Öffentlich gibt es keinen Hinweis auf die vertraglich zugesicherte Kilowattzahl von Logosys, PDU-Anordnung, USV-Logik, Generatorabdeckung oder Remote-Hands-Bedingungen im Gebäude.

Chennai ist aktuell nur eine vom Unternehmen veröffentlichte Stadtbezeichnung im vorliegenden Material. In dem PeeringDB-Datensatz von Logosys wird kein benannter Chennai-Standort aufgeführt. Weder Straßenadresse noch Vermieter, kein Exchange-Port und kein Testserver-Address im Looking-Glass. Das beweist nicht das Nichtvorhandensein indirekter Serviceknoten, gemieteter Server oder privater Interconnects in Chennai. Es bedeutet, dass Status, Betreiber, Serviceinventar und Ausfallunabhängigkeit von „Chennai DC1“ offen sind.

Die eigene Dedicated-Server-Aussage des Unternehmens ergänzt eine vierte Präsenz und fünf indische Exchanges, benennt diese aber nicht. Die Colocation-Beschreibung nennt eine US-Präsenz. Das sind Reichweitenaussagen, keine Routenkarte. Ein CDN-Partner, Transit-Anbieter, Reseller-Abrede oder gemietete Maschine kann Reichweite schaffen, ohne dass Logosys in jedem Ort einen eigenen Router oder Cage besitzt. Andersherum kann ein privater Link oder ein nicht offen dokumentiertes Managementnetz verborgen bleiben und in BGP-Daten nicht erscheinen. Konkrete Glasfaserwege zwischen den Logosys-Standorten sind nicht öffentlich.

Es gibt keine belegbaren Hinweise auf physisch unterschiedliche Trassen, unabhängige Zuleitungen oder eigenständige Langstreckenpfade.

Ein zugewiesenes /23, ein sichtbares /24

Adressressourcen markieren die klarste harte Grenze. DerAPNIC-RDAP-Eintrag zum autonomen SystemweistAS150636als LOGOSYSCL-AS-IN aus, aktiv in Indien, registriert im Februar 2023. DieAPNIC-Adressdatenstellen Logosys Cloud den portablen IPv4-Bereich103.89.46.0bis103.89.47.255zu. Das ist ein /23 mit 512 Adressen vor Netz-, Broadcast- und Reservierungsaufwand. „Portable“ bedeutet, dass der Adressblock dem Inhaber zugeordnet ist und nicht nur ein Subnetz im Aggregate eines Providers; es bedeutet nicht, dass das Unternehmen Gebäude oder Glasfaser besitzt.

Zum Beobachtungszeitpunkt des 15. Juli 2026 ergab dieRIPEstat-Ansicht angekündigter Präfixenur103.89.46.0/24. DieRouting-Status-Ansichtzählte 256 angekündigte IPv4-Adressen, keine IPv6-Präfixe und vollständige Sichtbarkeit von 326 IPv4 RIPE RIS Peers im Messset. Die Route wurde erstmals am 26. Juli 2023 gesehen. Das ist ein operativ nützlicher Befund: die aktive /24 war zu diesem Zeitpunkt keine schwache oder nur lokale Ankündigung.

Die zweite Hälfte,103.89.47.0/24, enthält ein APNIC-Route-Objekt mitAS150636und der Inhaber hat eine RPKI-Autorisierung für das gesamte /23 mit Max-Länge /24. Sie war im aktuellen announced-prefix-Ergebnis nicht sichtbar. Ein Route-Objekt und eine gültige Route-Origin-Authorization sind Berechtigungs- und Richtliniendaten; sie sind kein Beleg für eine derzeit propagierte, global akzeptierte oder kundentrafiklastige Aktivität. Das nicht angekündigte /24 kann reserviert, vorbereitet, zurückgezogen oder privater genutzt sein. Öffentliche Belege klären das nicht.

Die aktive Route hat eine gültige Origin-Autorisierung.RIPEstat-RPKI-Validierungfindet ein gültiges ROA für UrsprungAS150636, das103.89.46.0/23mit Maximal-Länge /24 abdeckt. Dadurch sinkt ein Fehler-Typ bei der Route-Origin-Prüfung: Netzwerke mit ROV können verifizieren, dass dieses AS berechtigt ist, diese /24 zu originieren. RPKI validiert nicht den gesamten AS-Pfad, beweist nicht, dass Pakete einen gesunden Server erreichen, und schützt keinen Service vor Ausfällen in Strom, Switching, Anwendungen oder Support-Prozessen.

IPv6 bleibt im kommerziellen Bild ein offener Punkt. PeeringDB meldet null IPv6-Präfixe für Logosys, und RIPEstat zeigte ebenfalls keine annoncierten IPv6-Routen. Der DE-CIX-Eintrag nennt keine IPv6-Adresse für den Logosys-Port. Ein Provider kann IPv6 über ein anderes Netzwerk oder für ausgewählte Kunden liefern, aber kein eigenes, in Besitz genommenes IPv6-Origin ist sichtbar. Käufer mit native-dual-stack-Anforderung sollten den zugewiesenen Präfixumfang, Routing-Policy, Reverse-DNS-Prozess und Testadresse fordern, statt aus einem allgemeinen Cloud-Begriff auf IPv6 zu schließen.

Ein Peering-Port sind nicht fünf unabhängige Exits

PeeringDB ist präzise bei der einen Exchange-Verbindung, die angezeigt wird: ein operativer 1-Gbps-Port bei DE-CIX Mumbai mit Teilnahme am Route Server. Der Datensatz klassifiziert das Netz als Content, nennt eine offene Peering-Politik, dokumentiert überwiegend ausgehenden Traffic und verortet den selbst gemeldeten Verkehr im Bereich 1–5 Gbps. Der Eintrag wurde zuletzt im Dezember 2023 aktualisiert. Diese Felder helfen anderen Netzwerken bei Interconnect-Entscheidungen. Sie sind kein aktuelles Auslastungsbild, kein Vertrag und keine Kapazitätsreservation.

Ein 1-Gbps-Exchange-Port hat eine Obergrenze auf Leitungsebene; er begrenzt nicht automatisch das gesamte AS, wenn Transit- oder private Interconnects sonstwo bestehen. Ebenso kann eine selbst gemeldete 1–5-Gbps-Spanne Verkehr außerhalb dieses Exchanges enthalten. Ein grundsätzliches Spannungsfeld ist nicht gegeben, aber es gibt keinen öffentlichen Messwert, der die Traffic-Bandbreite auf einzelne Leitungen abbildet. Ein Käufer sollte nicht „1 Gbps DE-CIX“ mit „bis zu 100 Gbps Server-Port“ addieren und dadurch 101 Gbps externe Kapazität annehmen.

Serverzugriffsgeschwindigkeit, Aggregatkapazität, Transit-Commit und Internet-Exchange-Port sind unterschiedliche Segmente.

Die aktuelle Pfad-Evidenz ist besonders wichtig. DieRIPEstat-NachbaransichtsiehtAS133296als dominant direkt vorherliegendes Netzwerk über viele Beobachtungswege. Die APNIC-RDAP-Registrierung zu diesem ASNnenntWEBWERKS-AS-INund beschreibt Web Werks India Pvt. Ltd. DieBGP-Zustandsansichtfür das aktive /24 zeigt außerdem eine kleine Zahl an Pfaden, bei denen andere Netze direkt vorAS150636erscheinen, einschließlich Pfaden konsistent mit Exchange- oder alternativen Verbindungen. Das stützt eine differenzierte Schlussfolgerung: Web Werks war der dominante sichtbare Pfad zum Messzeitpunkt, während gleichzeitig gewisse logische Pfadvielfalt beobachtbar war.

Es stützt jedoch nicht die stärkere Formulierung „physisch redundantes Multi-Homing“. Zwei BGP-Nachbarn können am selben Router enden, denselben Cross-Connect-Bündel nutzen, denselben Datencenter-Bereich passieren oder dieselbe Versorgungsstrecke teilen. Ein Exchange-Route-Server kann Hunderte Peers über einen physischen Port bereitstellen. Unterschiedliche Upstream-Pfade können sich außerhalb des Kundenanschlusses wieder vereinigen. Das Umgekehrte ist ebenfalls möglich: private Leitungen können physisch vielfältig sein, während öffentliche Collector nur einen Pfad melden.

Für physische Resilienz müsste Logosys Edge-Router, Portstandorte, Carrier, Cross-Connects, Gebäudeeingänge und Nachweis-Tests für den gekauften Service offenlegen.

Die Aussage zu fünf Exchanges kann auf Netze für Kunden, Exchange-Fabrics über Dritte oder Verbindungen verweisen, die in PeeringDB nicht genannt sind. Der öffentliche Datensatz nennt die anderen vier nicht. Bis zu ihren Namen, Ports und dem Betriebsstatus bekannt sind, ist die einzige unabhängige, nachvollziehbare Exchange-Anbindung in dieser Prüfung DE-CIX Mumbai. Das ist sinnvolle Konnektivität, aber ein Exchange-Port ersetzt keinen Transit und stellt alleine keinen alternativen Datenverkehrspfad bereit, wenn Gebäude, Router oder Zugangsleitung ausfallen.

Wer Eigentümer von Rack, Server und Strompfad ist

Logosys verwendet Eigentumsbegriffe an manchen Stellen präzise und an anderen eher offen. Die Streaming-Seite spricht von „Fully Own Network“, während die Colocation-Seite erklärt, dass Kunden Geräte in einem IDC-Rack aufstellen können und ein Service Provider Strom sowie Netzwerk bereitstellt. Die Dedicated-Seite verspricht Single-Tenant-Physikserver, nennt aber nicht, ob Logosys jede Servereinheit besitzt, least oder bezieht. PeeringDB nennt Web Werks Mumbai 1 als Interconnection-Einrichtung, nicht als Logosys-eigenes Gebäude.

Daraus ergeben sich mindestens vier mögliche Eigentumsebenen für einen gekauften Service. Logosys Cloud kann der vertragliche Serviceanbieter sein. Eine Rechenzentrumsfirma kann das Gebäude, USV, Generatoren und Kühlung besitzen oder betreiben. Ein Carrier oder Exchange kann die externe Konnektivität liefern. Logosys selbst, der Rechenzentrumsbetreiber, ein Finanzleaser oder ein anderer Lieferant kann den Server besitzen. Der Kunde kontrolliert seine Gast-VM oder die colocation Hardware, aber möglicherweise nicht Hypervisor, Switch, Storage-Array oder Remote-Hands-Reihenfolge. Öffentliche Seiten klären nicht jede Ebene für jede SKU.

DasColocation-Angebot von Logosysist konkret zu den Retail-Bündeln. Es nennt 1U bei 200 W, 2U bei 300 W, 4U bei 400 W und 8U bei 600 W, jeweils mit 100 GB Bandbreite. Es listet zudem ein Viertel-Rack mit 1 kW, ein halbes Rack mit 1,5 kW und ein vollständiges 42U-Rack mit 3 kW. Das sind gebotene Produktgrenzen, keine Bestätigung über nutzbare Live-Reserve. Sie werfen technische Rückfragen auf. Die Seite nennt „Power Supply: Yes“, spezifiziert aber nicht A- und B-Leitungen, Spannung, Leitungsschutz, Messverfahren oder den Unterschied zwischen Dauer- und Spitzenleistung. Die volle Rackdichte von 3 kW ist für viele klassische Hosting-Workloads plausibel, kann bei GPU-lastigen oder modernen Dual-Socket-Systemen aber limitieren.

Die gleiche Colocation-Seite nennt ganz oben „Tier 4 rechenzentrum“ und beschreibt später „Tier 3 data centers“. Sie nennt weder Zertifizierungsstelle, noch Facility-Identifier, noch Zertifikat. Tier-Begriffe können ein Designziel, internen Anbieterbegriff oder eine formale Drittzertifizierung bezeichnen; diese Ebenen sind nicht gleichwertig. Die sichere Schlussfolgerung ist: Die Seite enthält beide Aussagen. Kunden sollten die konkrete Einrichtung, Zertifizierung, Geltungsbereich und Gültigkeitsdauer anfordern, statt einen generischen Tier-Label direkt auf ein Logosys-Rack zu übertragen.

Auch bei der Flächenkapazität ist häufige Fehlinterpretation möglich. Web Werks gibt für Mumbai 1 2,3 MW an. Das ist die Anlagenangabe des Betreibers für den gesamten Standort, nicht die installierte oder reservierte Kapazität von Logosys. Sie sagt nichts über den Anteil nach bestehender Last, Kühlgrenzen, vertraglichen Reservierungen und Wartungsbedingungen aus. Der Artikel findet keine Offenlegung zu Logosys-Rackzahl, Power Commit, Generatorlaufzeit, Kraftstoffvertrag, Kühllogik, Ersatzteillager oder Server-Inventar.

Installierte, eingeschaltete, betriebsbereite, verkaufte und ausfallnutzbare Kapazität sind auf Unternehmensebene nicht bekannt.

Streaming verändert die Abhängigkeitskette

Das markanteste Workload-Profil ist der Broadcast-Streaming-Bereich. Die Live-CDN-Seite nennt Pläne von 1 TB und zehn Verbindungen bis 5 TB und 1.000 Verbindungen, mit einem Kanal je Plan. Sie spricht von<5 Sekunden Latenz für HLS und DASH, Wowza-Unterstützung und 20 Streaming-Servern weltweit. Die About-Seite nennt über 100 betreute Fernsehkanäle. Das sind erste Herstellerangaben. Es gibt keinen öffentlichen Server-Index, keinen Provider-Verzeichnisbeleg, keine Traffic-Reports und keine Kundenreferenzbelege, die Ort und Zustand aller 20 Server sowie die aktive Kundenzahl belegen.

Für Broadcaster sind „20 Server“ ohne Lastannahmen keine Kapazitätsgröße. Ein Server, der einen hochwertigen Beitragssignal-Stream entgegennimmt und umpackt, hat ganz andere CPU-, GPU-, Speicher- und Egress-Limits als ein Edge-Knoten, der gecachte Segmente ausliefert. Zehn Verbindungen bei einer Bitrate sind nicht mit zehn bei einer anderen gleichzusetzen. Ein monatlicher Transfer-Höchstwert sagt wenig über Spitzenkonkurrenz. Ein CDN kann eigene Server, gemietete Bare-Metal-Systeme, virtuelle Maschinen oder einen dritten Verteilungspartner nutzen. Die Logosys-Seite trennt keine Rollen von Origin, Transcoding, Packaging und Edge nach Standort.

Der Ausfallpfad ist ebenfalls asymmetrisch. Fällt ein Edge-Knoten aus und wird der Verkehr umgelenkt, kann es zu kurzen Qualitätsänderungen kommen. Fällt allein der einzige Live-Origin, Encoder oder Playout-Server aus, können alle Edges stabil bleiben, der Kanal aber dunkel werden. Wird das Kunden-Control-Panel nicht erreicht, läuft ein bestehender Stream meist weiter, aber der Betreiber kann ihn dann nicht neu starten oder umlenken. Fällt ein Upstream-Pfad aus, bleiben Server ggf. unter Strom und isoliert erreichbar. Fällt eine Grafik- oder Playout-Lizenz aus, helfen Netz- und Compute-Kapazität nicht bei der Programmfortführung.

„CDN-Redundanz“ erfordert daher ein Design pro Rolle, nicht nur eine Knotenzahl.

Die Frage der Remote-Planung ist genauso relevant. Ein Kunde sollte klären, ob Playout-Server und Streaming-Origin denselben Host, Rack, dieselbe Einrichtung oder dieselbe Stromdomäne teilen; ob eine zweite Instanz warm, kalt oder nur wiederherstellbar ist; wie aktuell die Medienkopie ist; und wer das Failover initiieren darf. Die öffentliche Darstellung enthält weder RPO noch RTO. Es wird Support rund um die Uhr angeboten, aber nicht Personalstufen, Eskalationsziele oder Reaktionszeit der Remote-Hands.

Kapazitätsaussagen sind nicht Kapazitätszustände

Der Begriff „Kapazität“ umfasst in diesem Markt mindestens sieben Zustände. Design-Kapazität beschreibt, was ein System bei geplanter Auslegung tragen könnte. Installierte Kapazität ist Hardware im Rack. In Betrieb gegangene Kapazität hat eine aktive Strom- und Kühlzuteilung. „Lit“ bezeichnet eine aktive Netzverbindung. Operative Kapazität passiert Health-Checks. Verkauft bedeutet Kapazität für Kunden gebunden. Nutzbare Kapazität ist das, was unter der betrachteten Ausfallsituation verbleibt. Logosys-Öffentlichkeitsseiten beschreiben überwiegend Produktmaxima und Katalogkonfigurationen, nicht diese Zustände.

Die 100-Gbps-Angabe auf der Dedicated-Seite ist eine Port-Speed-Versprechung für ein Ultra-High-Bandwidth-Segment. Es gibt dort keinen benannten Server, keine benannte Einrichtung, kein Switch-Modell, keinen Transit-Commit oder aktuellen Preis zu dieser Zahl. Der wichtigste käufliche Dedicated-Eintrag zeigt 1 Gbps. Der PeeringDB-Austausch-Port ist 1 Gbps. Keine dieser Zahlen widerlegt die anderen, da sie unterschiedliche Ports und Standorte adressieren können. Eine 100-Gbps-Zugriffsgeschwindigkeit liefert aber nicht automatisch 100 Gbps ins öffentliche Internet, wenn weitere Pfade, Richtlinien und Commercial Commits das nicht stützen.

Die IPv4-Inventardarstellung zeigt eine weitere Grenze. Ein /23 enthält 512 Adressen, und nur ein /24 war zum Beobachtungszeitpunkt global announced. Die Dedicated-Liste enthält fünf IP-Adressen pro Server. Das bedeutet nicht, dass Logosys nur etwa 51 solche Server verkaufen kann: Adressen können von Upstreams kommen, über Private Networking wiederverwendet werden oder je nach Produkt anders verteilt werden. Es zeigt jedoch, dass öffentlich tragbares Adressraum-Inventory endlich und teilweise nicht announced ist.

Kunden mit hohem Adressbedarf sollten klären, ob die Adressen bei Logosys liegen oder vom Provider stammen, ob sie nach Migration geroutet werden können und wie Missbrauchs-Historie sowie Reverse-DNS verwaltet werden.

Keine öffentlichen Nutzungsdaten zeigen CPU-Belastung, RAM-Nutzung, Storage-Konsum, Oversubscription, Portauslastung, Rack-Leistungsaufnahme oder reservierte Bestellungen. Der 1–5-Gbps-Bandbreitenbereich bei PeeringDB ist selbst berichtet und alt genug für eine Rekonfirmation. Der „Sold out“-Marker im Produktstore zeigt, dass Lagerzustände relevant sind, verrät aber nicht, ob die Engpassursache Prozessoren, Laufwerke, Chassis, Rackleistung oder ein ausgelaufenes SKU-Label war. Die Kapazitätsplanung für einen produktiven Einsatz muss daher mit einem datierten, standortbezogenen Angebot mit Ausliefertermin beginnen.

Das 99,9-%-Versprechen hat Verfahrensaspekte

Logosys veröffentlicht ein detailliertesService Level Agreement, was besser ist als reine Werbeklauseln. Es nennt eine monatliche Schwelle von 99,9 Prozent. In einem 30-Tage-Monat sind 0,1 Prozent rund 43 Minuten und 12 Sekunden. Zwischen 99,9 und 99 Prozent wird eine Serviceverlängerung von einem Tag gewährt; niedrigere Bänder führen zu zwei oder drei Tagen, bei unter 97 Prozent nach Formel. Logosys kann stattdessen eine gleichwertige Gutschrift oder Rabattsmaßnahme nach Ermessen bereitstellen.

Die Abhilferegelung ist enger als die Schlagzeile. Der Kunde muss eine Störung per E-Mail innerhalb von 24 Stunden nach Entdeckung melden. Die Uhrzeit beginnt mit dem Versand der Mail, nicht zwingend mit Beginn der Störung. Der Rebate-Antrag muss danach mit Nachweis innerhalb einer kurzen Frist nach dem Abrechnungsmonat gestellt werden. Störungen werden nicht zusammengeführt. Geplante Arbeiten, Notfallwartung und viele externe Ereignisse können ausgeschlossen werden.

Ausgeschlossen sind außerdem Leistungen fremder Exchanges, DNS außerhalb der Logosys-Kontrolle, Kunden-Zugangsleitungen, Netze nicht im Besitz von Logosys und einzelne Drittsoftware oder -dienste.

Diese Ausnahmen entsprechen genau den zuvor genannten Infrastrukturgrenzen. Die einzige benannte Exchange, der Facility-Betreiber und das dominante Nachbar-AS sind unterschiedliche Organisationen. Ein Kunde kann eine vollständige Anwendungsstörung erleben, obwohl der betroffene Ausfall vertraglich nicht in die Downtime-Berechnung fällt. Das bedeutet nicht, dass die SLA wertlos ist; es macht die Architektur wichtiger als die Kompensation. Eine Verlängerung um einen Tag auf einer günstigen VPS ist nicht automatisch gleichwertig zum Geschäftsausfall eines stillen Fernsehsenders oder eines nicht verfügbaren Commerce-Portals.

Im SLA wird zudem festgelegt, dass der Kunde für geeignete Backup- und Recovery-Pläne einschließlich regelmäßiger Tests verantwortlich bleibt und Logosys nicht für Integrität und Sicherheit der Kundendaten haftet. Die Haftungsobergrenze ist ein Monatsentgelt vor dem Ereignis, und Folgeschäden sind ausgeschlossen. Kunden mit strengeren Schutzanforderungen brauchen eine vertragliche Ergänzung mit service-spezifischer Verfügbarkeit, Datendürftigkeit, Eigentum des Backups, Incident-Kommunikation sowie exakten Berechnungskomponenten.

Lokale Cloud bedeutet nicht automatisch bekannte Datenlokalität

Logosys positioniert sich als indische Cloud mit indischen Preisen, indischer Corporate Identity und einem in Indien registrierten AS. Das sind nachvollziehbare Lokalitätssignale. Sie belegen jedoch nicht automatisch, wo jede Kategorie von Kundendaten tatsächlich liegt.

Die Colocation-Seite nennt Zentren in Indien und den Vereinigten Staaten. Die Live-CDN-Seite nennt weltweit verteilte Server. Das Kundenportal ist eine separate Servicefläche gegenüber der Marketingseite. Backups, Monitoring-Daten, Support-Anhänge, DNS-Informationen und Streaming-Edges können andere Standorte als der primäre Compute-Knoten haben. Ein Kunde mit „India“-Hosting sollte im Bestellprozess Standorte und Länder für Primärdaten, Replikation, Backups, Snapshots, Logs und Support-Zugriff festlegen lassen.

DieDatenschutzerklärungnennt Logosys Cloud Private Limited und beschreibt Kategorien von Kunden-, Billing- und Nutzungsinformationen, die erhoben werden. Sie ist kein standortgenauer Datenresidenzplan für gehostete Workloads. Die Bedingungen legen Verantwortung für Kundendaten und rechtliche Compliance weitgehend beim Kunden. Bei regulierten oder standortsensiblen Einsätzen sind Marken-Nationalität und IP-Country-Code nicht ausreichende Kontrollmechanismen.

Migration testet Lokalitätsbehauptungen zusätzlich. Ein VPS-Image kann vom proprietären Control Panel, einer manuell zugewiesenen Adresse, einem lokalen Backup-Produkt oder einer Lizenz abhängen, die nicht mit der Platte wandert. Ein Streaming-Service kann von Logosys-Software, Wowza-Konfiguration und einem CDN-Arrangement abhängen. DieRückerstattungsbedingungennennen Self-Service- und manuell gesteuerte Deprovisionierung, weitere Abrechnung bis zur Deprovisionierungsbestätigung sowie Sonderbehandlung für gebuchte Nodes und Softwarelizenzen. DieKündigungsbedingungenverlangen mindestens sieben Tage Vorlauf vor Verlängerung. Keine Seite verspricht ein Standard-Exportformat, ein Transferfenster nach Vertragsende oder Unterstützung beim Portieren eines aktiven Service zu einem anderen Anbieter.

Wie Ausfälle sich ausbreiten

Der praktischste Resilienztest beginnt mit einem konkreten Ausfall und verfolgt die Auswirkungen.

Ein Rack- oder Standort-Ausfall bei Strom.Läuft ein Service nur in Web Werks Mumbai 1, können Rack-PDU, Rackraum, USV-Pfad oder ein Gebäudeeinbruch Compute und Netzwerk-Edge gemeinsam betreffen. Die N+N-Infrastrukturkommunikation des Standorts beweist nicht, dass der jeweilige Kunde zwei getrennte Leitungen oder Dual-Corded-Hardware nutzt. Wiederherstellung hängt von Reservehardware, Remote-Hands, Backup-Ort und ausreichend reservierter Kapazität am anderen Standort ab; diese Werte sind öffentlich nicht quantifiziert.

Ausfall des dominanten Upstream-Pfades.Aktuell zeigt der Großteil der globalen RoutenAS133296unmittelbar vor Logosys. Fällt diese Nachbarschaft aus, hängt Erreichbarkeit von der Betriebsbereitschaft und Verbreitung alternativer Sessions ab. Ein DE-CIX-Route-Server-Port kann direkte Pfade zu teilnehmenden Peers liefern, ist aber kein allgemeiner Transit zu jedem Ziel. Die Zahl der logischen Nachbarn sagt nicht, ob Links denselben Router, denselben Cross-Connect oder denselben Gebäudeeintritt teilen.

Ausfall des Exchange-Ports oder Edge-Routers.Der gelistete DE-CIX-Port ist 1 Gbps in einer Mumbai-Einrichtung. Fällt Exchange-Traffic zusammen mit Transit auf demselben Edge-Chassis aus, kann ein Ausfall sowohl bei Verbindungen als auch beim Transit eintreten, obwohl mehrere Netzwerke vertraglich benannt sind. Werden getrennte Chassis und Wege genutzt, kann Resilienz deutlich stärker sein. Aus öffentlicher Sicht ist diese Topologie nicht bekannt.

Ausfall von Hypervisor, Storage oder Bestandsmaterial.Die Web-Hosting-Seite verspricht automatisches Umziehen auf einen anderen Server bei Hardwarefehlern. Sie beschreibt jedoch nicht Shared Storage, Replikationslatenz, Fencing oder die Ausfalldomänen, und nicht jedes VPS-Produkt nutzt dieses Design. Dedicated-Server erfordern typischerweise Reparatur oder Ersatzchassis, außer der Kunde hat einen Standby-Knoten. RAID 1 kann einen Festplattenausfall abfedern, nicht jedoch jeden Controller-, Mainboard-, Strom- oder Betreiberfehler.

Ausfall der Steuerungsebene.Das Kundenportal steuert Bestellung, Abrechnung, Tickets und einige Serveraktionen. Eine Störung dort kann laufende Workloads am Leben lassen und dennoch Rebuilds, Konsolenzugang, Skalierung oder Kündigung blockieren. Das ist zwar nicht automatisch ein totaler Ausfall, kann aber Zwischenfälle verlängern. Logosys stellt Telefon, E-Mail und Ticketsystem bereit, aber keine unabhängigen Support-Reaktionsstatistiken.

Ausfall der Streaming-Quelle.Mehrere CDN-Edges helfen nicht, wenn der einzige Encoder, der Playout-Prozess oder Origin keinen gültigen Stream mehr liefert. Wiederherstellung verlangt eine zweite Einspeisung, aktuelle Inhalte, Lizenzen, Berechtigungen und getestete Verkehrsumschaltung. Die öffentliche „20-Server“-Aussage benennt keine Rollen.

DNS- oder Zertifikatsausfall.Logosys warnt vor redundanten DNS-Lösungen, nennt aber in den öffentlichen Seiten keine autoritativen Provider je Service oder eine Trennung der Steuer- und Ausfalldomänen. DNS ist im SLA ausgeschlossen, wenn außerhalb der direkten Logosys-Kontrolle. Kunden sollten DNS-Diversität, Registrar-Sicherheit, Zertifikatserneuerung und Zugriff auf Berechtigungen unabhängig vom Hosting-Konto prüfen.

Support- und Abrechnungsstörung.Kleine Anbieter stützen sich oft auf ein konzentriertes Technikteam. Logosys bewirbt kontinuierlichen Support, veröffentlicht aber keine Teamgröße, On-Call-Rotation oder Eskalationszeiten. Die wiederkehrende Nennung einer separaten Softwaregesellschaft bei Zahlungen fügt eine zusätzliche operative Schnittstelle hinzu. Im Ereignisfall braucht der Kunde einen eindeutig verantwortlichen Partner, der über Facility, Carrier, Hardware und Software verfügen darf.

Die Wirtschaftlichkeit ist attraktiv, weil die Grenzen beim Käufer liegen

Die Listenpreise von Logosys sind konkurrenzfähig. INR 1.550 gibt Zugriff auf ein Einstiegs-VPS im aktuellen Store. INR 12.700 finanziert eine Dedicated-Konfiguration mit 128 GB RAM, SSDs, 10 TB bei 1 Gbps und fünf Adressen. Colocation beginnt bei INR 4.500 für 1U, während ein vollständiges Rack bei INR 50.000 mit 3 kW steht. Streaming startet bei INR 1.500 für einen Kanal und 1 TB Transfer pro Monat. Diese Preise sind für kleinere Organisationen ein Einstieg in Infrastruktur mit weniger Mindestbindung als hyperskalige oder Wholesale-Verträge.

Die ökonomische Kehrseite: Ein Großteil des Integrationsrisikos liegt im Verantwortungsbereich des Kunden. Er muss Backups, Managed Support, Softwarelizenzen, Zusatzadressen, Ersatzteile, Bandbreitenspitzen, Traffic-Überziehungen, Remote-Hands und Zweitstandorte einpreisen. Ein niedriger Monatspreis ist nicht automatisch der Preis für einen ausfallsicheren Service. Für Broadcaster ist der sinnvolle Nenner eher Kosten je gesichertem Kanalstunde als Kosten je Kern. Für Unternehmensanwendungen kann es Kosten je wiederhergestelltem Transaktionsvolumen oder je getestetem Recovery-Vorgang sein.

Der Vertrag unterstreicht diese Verteilung. Rabatte erfolgen über Serviceverlängerungen oder Gutschriften und sind nicht auf Folgeschäden ausgelegt. Ausfälle müssen kurzfristig dokumentiert und eigene Recovery-Vorkehrungen vorgehalten werden. Für gebuchte Nodes und genutzte Softwarelizenzen gibt es eingeschränkte Rückgabeoptionen. Das kann ein rationales Angebot für nicht-kritische Lasten, Dev/Test-Umgebungen, regionale Medienbetriebe mit eigenem Backup-Pfad oder Kunden mit lokalem Supportbedarf sein. Es ist schwächer, wenn die Annahme getroffen wird, ein Cloud-Label enthalte automatisch Multi-Region-Dauerhaftigkeit.

Was die Aussagen in Infrastrukturbelege verwandeln würde

Logosys könnte sein öffentliches Angebot deutlich prüfbarer machen, ohne sensible Netzdetails zu offenbaren. Erster Verbesserungspunkt wäre eine datierte Standortmatrix. Jede Stadt sollte den Facility-Betreiber, verfügbare Serviceklassen, Eigentums- oder Leasingform und die Annahme von Neuaufträgen offenlegen. Eine Karte sollte Büro, Cloud-Region, CDN-Edge, Exchange-Port und Colocation-Raum unterscheiden. Verbindungen zwischen Städten sollten nur dort dargestellt werden, wo physischer Pfad und Betreiber nachgewiesen sind; andernfalls sollte die Karte den Servicebereich statt impliziter Glasfaser zeigen.

Der zweite Punkt wäre eine Netzwerk-Fakten-Seite. Sie könnte aktive Präfixe, IPv6-Status, Transit-Provider, Exchanges, Portkapazitäten, Looking-Glass-Adressen und RPKI-Abdeckung mit Aktualitätsdatum publizieren. Sie sollte benennen, ob mehrere Sessions auf getrennten Routern laufen und ob diese über unterschiedliche Zugangswege in die Facility geführt werden. Der aktuelle PeeringDB-Eintrag ist hilfreich, wurde aber zuletzt 2023 erheblich aktualisiert und nennt nur einen Exchange und eine einzige Einrichtung.

Der dritte Punkt wäre ein Kapazitätsvokabular. Logosys muss keine kundenkritischen Auslastungswerte veröffentlichen, aber es könnte installierte Server von bestellbaren Konfigurationen trennen, Leitungskapazität von gebuchter Leitung, Gebäudeleistung von Mieterleistung und normale von ausfallnutzbarer Reservekapazität unterscheiden. Für Colocation sollte ein Angebot Feed-Anzahl, Sicherungsgröße, Spannung, enthaltene Energie, Messverfahren, Cross-Connects und Remote-Hands-Bedingungen benennen. Für Cloud sollte die Host-Generation, Storage-Durability, Overcommit-Richtlinie und Live-Migration-Abdeckung benannt werden.

Der vierte Punkt wäre service-spezifischer Recovery-Nachweis. Das Unternehmen könnte veröffentlichen, ob VPS-Instanzen auf einen anderen Knoten verschoben werden können, ob Backups im selben Standort liegen, wie Streaming-Origin und Edge failovern und welche Anforderungen Kunden erfüllen müssen. Eine Status-Historie sollte Vorfälle nach Service und Region ausweisen und Kundenkontext schützen. Ein nachgewiesener Failover-Test mit Datum, Umfang und gemessener Wiederanlaufzeit wäre aussagekräftiger als ein generisches Redundanz-Icon.

Für Käuferinnen und Käufer heute ergibt sich damit eine klare Prüfliste:

1. Exakte vertragliche und abrechnende Rechtsperson auf der Bestellung nennen, inklusive der Rolle von Logosys Software Solutions Private Limited.
2. Standort und Land für Compute, Primärspeicher, Replikation, Backups, Logs und Supportzugriff benennen.
3. Festlegen, wem Server, Rack, Strompfad, Cross-Connect und verwendeter IP-Raum gehören.
4. Aktive Transit- und Exchange-Daten beschaffen und erfragen, welche Verbindungen physisch unabhängig sind und failoverfähig getestet werden.
5. Jede Bandbreitenaussage in Port, Commit, Burst-Regel, Transferkontingent und Überlastfall trennen.
6. Jede Kapazitätsaussage in installierte, aktive, betriebsfähige, bestellbare und ausfallnutzbare Mengen transformieren.
7. Backup-Eigentum, Exportformat, Wiederherstellungszeit/-punkt und Ausstiegsunterstützung vertraglich festlegen.
8. Marketing-Konfiguration, Warenkorbinhalt und finale Stückliste vor Zahlung gegeneinander prüfen.
9. Incident-Notification und Servicegutschriften auf den realen Geschäftsimpact statt auf die generische 99,9%-Seite ausrichten.
10. Belege für Hyderabad, Chennai, die vierte Point-of-Presence-Aussage, die vier weiteren Exchanges und etwaige US-Standorte anfordern, wenn das Design davon abhängt.

Das Fazit

Logosys Cloud ist nicht nur ein Webhoster mit angehängtem Cloud-Begriff. Das Unternehmen verfügt über ein registriertes indisches Netzwerk, eine gültige Origin Protection, eine sichtbare Mumbai-Interconnection, Self-Service-Steuerung, physische Serverangebote und eine fundierte Spezialisierung in TV-Playout und Streaming. Für regionale Broadcaster und kleinere indische Kunden kann diese Kombination wirtschaftlich sinnvoll sein.

Die öffentliche Infrastrukturdarstellung ist jedoch nicht so umfassend wie die Produktdarstellung. Das drei Stadt-Label zeigt nicht drei unabhängige Einrichtungen. Das zugewiesene /23 bedeutet nicht, dass beide /24s aktiv geroutet werden. Ein 1-Gbps-Exchange-Port beweist nicht fünf Exchange-Verbindungen oder einen 100-Gbps-Internetpfad. Ein 2,3-MW-Standort bedeutet nicht 2,3 MW für Logosys. Zwanzig Streaming-Server bedeuten nicht zwanzig unabhängige Origins. Eine 99,9-%-SLA garantiert nicht automatisch die Wiederherstellung bei Ausfällen von Facility, Transit, Steuerungsebene oder Datenverlust.

Die Belege stützen eine begrenzte Schlussfolgerung. Logosys Cloud kontrolliertAS150636, kündigt aktiv ein gut sichtbares, RPKI-validiertes /24 an und meldet eine operative Präsenz bei Web Werks Mumbai 1 sowie DE-CIX Mumbai. Hyderabad ist als Corporate- und Betriebsbasis klar belegt, während Chennai und der Rest der beworbenen Reichweite unzureichend spezifiziert sind. Alles darüber hinaus sollte über standort-, kapazitäts- und ausfallspezifische Bestellungen eingekauft werden, nicht aus dem Katalog abgeleitet. Nächster sinnvoller Nachweis ist keine größere Bandbreite, sondern ein datierter Nachweis zu Standort, Ausfallrestkapazität und Verantwortlichkeit bei Wiederanlauf.