PT Media Cloud Indonesia verkauft gehostete Kapazität, die noch von Racks, Transit und Reparaturfenstern abhängt

Zusammenfassung

• PT Media Cloud Indonesia hat stärkere öffentliche Betriebsnachweise als viele kleine Hosts: APNIC/IDNIC-Datensätze verknüpfen es mit AS140449, 103.152.240.0/23 und 2406:38c0::/32, während RIPEstat 103.152.240.0/24, 103.152.241.0/24 und 2406:38c0::/32 beobachtete, die von AS140449 während des Verifikationsfensters im Juli 2026 angekündigt wurden.
• Das Unternehmen vermarktet ein breites Bündel unter der Marke Media Cloud: Domains, WordPress- und Sitejet-Hosting, indonesische VPS, SSL, professionelle E-Mail, Webdienste, Game-Hosting-Werbung und ein lokales Loop-Angebot auf mci.net.id, das dedizierte Bandbreitenpakete von 1 Gbit/s, 2 Gbit/s und 3 Gbit/s anzeigt.
• Das Anliegen der Belastbarkeit ist ebenso konkret. PeeringDB listet einen Exchange-Anschluss bei OpenIXP/NiCE und keine Einrichtungsdatensätze für das Netzwerk; RIPEstat-Nachbardaten werden von AS138840 dominiert, und das RADB-IPv6-Routenobjekt beschreibt eine proxy-registrierte HSP-Global-Kundenroute. Dies sind sichtbare Zusammenschaltungsnachweise, kein Nachweis einer unabhängigen Multi-Site-Kapazität.
• Media Clouds eigene Nutzungsbedingungen und Rückerstattungsrichtlinie machen den physischen Ausfallweg sichtbar: Dienste können aufgrund von Gerätefehlfunktionen, Wartung, Reparatur oder Austausch, Telekommunikationsverbindungsunterbrechung, feindlichen Angriffen, Überlastung oder anderen Ausfällen unzugänglich werden; die Rückerstattung für Internetdienste ist an mehr als sieben ununterbrochene Ausfalltage oder die Unfähigkeit, den Dienst fortzusetzen, gebunden.
• Der Evidenzgrad ist Mittel. Die Identität, die Produktoberfläche, der geroutete Adressraum und die aktuelle Erreichbarkeit sind gut belegt; öffentliche Belege zum Standort von Einrichtungen, Reservekapazität, Transitdiversität, getesteter Wiederherstellung und Datenportabilitätsgrenzen bleiben unvollständig.

Das Unternehmen ist sichtbar, aber die Abhängigkeit bleibt physisch

PT Media Cloud Indonesia verdient eine genauere Betrachtung als ein einfaches 'kleiner Host'-Label. Das Unternehmen präsentiert zwei miteinander verbundene öffentliche Oberflächen. Eine ist die konnektivitätsorientierte Unternehmensseite untermci.net.id, die lokale Loop- und FTTH-Konnektivitätslösungen bewirbt und Benutzer zum Cloud-Dienstleistungs-Shop führt. Die andere istmediacloud.id, die kundenorientierte kommerzielle Oberfläche für Domains, Hosting, VPS, SSL-Zertifikate, E-Mail und Webdienste. Diese beiden Oberflächen sind keine bloßen Marken-Anekdoten. Sie zeigen, dass das Unternehmen die Kunden bittet, ihm sowohl ihre grundlegende Internetpräsenz als auch strukturierende Infrastrukturdienste anzuvertrauen.

Dieses Vertrauen kollidiert mit sehr realen Einschränkungen. Eine VPS ist eine virtuelle Maschine, aber sie läuft auf physischer Rechenleistung, Speicher, Strom und Kühlung. 'Unbegrenzte Bandbreite' ist ein Marketingbegriff, aber die Pakete durchlaufen dennoch Ports, Router, Filter, Glasfaser, Transitverträge und Exchange-Fabrics. Ein '24/7-Support'-Versprechen ist nur nützlich, wenn der Kunde das Team auch dann erreichen kann, wenn der betroffene Dienst, das Ticketsystem, DNS oder der Abrechnungsstatus selbst ausfällt.

Das lokale Loop-Angebot ist noch direkter: Es hängt vom Last-Mile-Zugang, einem Zusammenschaltungspunkt, einem Upstream-Pfad, Bereitschaftstechnikern und einer Geschäftsregel ab, was passiert, wenn die Leitung ausfällt.

Die öffentlichen Belege beginnen auf der Nummernressourcen-Ebene. Der APNIC/IDNIC-RDAP-Eintrag fürAS140449listet MEDIACLOUD-AS-ID, PT Media Cloud Indonesia, 'Internet Service Provider' und eine Verwaltungsadresse in Süd-Jakarta auf. APNIC/IDNIC zeigt auch das IPv4-Netz103.152.240.0/23und das IPv6-Netz2406:38c0::/32unter dem Namen MEDIACLOUD-ID. Diese Datensätze beweisen nicht den Standort jedes Servers, aber sie sind weitaus stärker als eine anonyme Wiederverkäuferseite. Sie zeigen ein Unternehmen mit direkt sichtbaren Internetnummernressourcen.

Das Unternehmen hostet auch seine öffentlichen Websites innerhalb dieses Fußabdrucks. Ein DNS-Check während dieser Recherche löste sowohl mci.net.id als auch mediacloud.id auf die Adresse 103.152.240.97 auf, innerhalb der 103.152.240.0/23-Zuteilung. Dies ist ein bescheidenes, aber wichtiges Signal: Die öffentliche Website wird nicht einfach hinter einem globalen Gateway ohne erkennbare Verbindung zur Netzwerkregistrierung gehostet. Die Marke, die ASN und der geroutete Adressraum sind ausreichend aufeinander abgestimmt, um den Infrastrukturanspruch überprüfbar zu machen.

Der schwierige Teil besteht nicht darin zu beweisen, dass Media Cloud eine öffentliche Präsenz hat. Der schwierige Teil ist die Bestimmung des Niveaus der Kundenresilienz, das diese Präsenz impliziert. Öffentliche Routing-Belege können zeigen, welche Präfixe sichtbar sind, welche ASNs angrenzend an das Netzwerk sind, ob Routenursprungsdaten abgedeckt sind und ob ein freiwilliges Exchange-Verzeichnis einen Port listet. Sie können nicht den Ersatzserver im Rack, den Einrichtungsvertrag, den Kunden-Backup-Prozess oder die Person zeigen, die autorisiert ist, Hardware nach Mitternacht auszutauschen. Diese Lücke ist der Kern des Artikels.

Die beworbene Produktpalette geht über eine einfache VPS-Seite hinaus

Die Produktseiten von Media Cloud zeigen ein Unternehmen, das ein One-Stop-Shop für indonesische Kunden sein möchte, die eine Webpräsenz aufbauen wollen. DerMedia Cloud Shopgibt an, Domains, Hosting, einen Site Builder, E-Mail, SSL-Zertifikate und VPS-Dienste bereitzustellen. Er bewirbt.id- und.com-Domains, Reseller- und Bulk-Dienste sowie eine Kachel 'Best VPS Cloud Hosting', die auf das VPS-Produkt verweist. Dies ist wichtig, weil ein breites Angebot mehrere Abhängigkeitspfade schafft. Ein Kunde kann eine Domain, DNS, SSL-Zertifikat, Postfach, Site Builder und VPS vom selben Anbieter kaufen und dann während eines Vorfalls feststellen, dass die technische Abhängigkeit und die Kontenabhängigkeit eng miteinander verbunden sind.

DieVPS-Seiteist der klarste Anspruch auf gehostete Kapazität. Sie bewirbt 'VPS Indonesia', beschreibt den Dienst als 'schnelle und stabile indonesische VPS zu erschwinglichen Preisen' und listet 100% dedizierte Ressourcen, NVMe-Speicher, unbegrenzte Bandbreite und DDoS-Schutz auf. Sie gibt auch an, dass Kunden Betriebssysteme und vorkonfigurierte Anwendungen wählen können. Dies ist genau die Sprache, die ein kleines Netzwerk zu einer Geschäftsabhängigkeit macht: Kunden kaufen nicht nur Adressraum; sie erwarten Rechenleistung, Speicher, Softwareinstallation, Sicherheitskontrollen und ausreichend Netzwerkspielraum, um Anwendungen erreichbar zu halten.

Die Hosting-Seiten fügen eine weitere Ebene hinzu.Sitejet Hostingpräsentiert gebündeltes Hosting mit einem Site Builder und hebt DDoS-Schutz, cPanel, Softaculous und Ein-Klick-Installationen hervor.WordPress Hostingverwendet dieselbe Zuverlässigkeits- und Funktionssprache, obwohl die Plantabelle für die zum Zeitpunkt der Konsultation erkannte Währung nicht verfügbar war. Dies ist nützlich, weil es die Plattformannahmen offenlegt, die dem Kundenerlebnis zugrunde liegen. cPanel, Softaculous, Site Builder und WordPress-Hosting hängen alle von Control Panels, Lizenzstatus, Speicher- und Backup-Praktiken ab. Dies sind operative Systeme, keine bloßen statischen Produktnamen.

E-Mail erweitert die Abhängigkeit weiter.E-Mail-Hostingbewirbt professionelle E-Mail mit einer Verfügbarkeitsgarantie von 99,9 %, benutzerdefinierten Domains, Sicherheit, Überwachung, 24/7-Support und Unterstützung bei Einrichtung, Migration und Fehlerbehebung.Professional Emailbeschreibt 8 GB pro Postfach, Webmail, Anti-Spam, Anti-Virus, DKIM-Signaturen, automatische Backups, Mail-Trace-Funktionen und Audit-Logs. Die MX-Einträge fügen Nuancen hinzu: mci.net.id verwendet Microsoft-E-Mail-Schutz, während mediacloud.id auf Google aspmx-Mail-Austauscher verweist. Dies ist nicht widersprüchlich; es zeigt, dass einige Teile des Geschäfts auf externe E-Mail-Plattformen angewiesen sind, selbst wenn die öffentlichen Websites im eigenen Adressraum von Media Cloud liegen.

DieSSL-Seiteund die Domain-Seiten vervollständigen das Bild. Media Cloud verkauft Vertrauensebenen auf Servern: Domain-Registrierung, Transfer,.id-Identität, Zertifikate, Site-Generierung und Postfachidentität. Ein Kunde, der diese Dienste konzentriert, mag Bequemlichkeit gewinnen, schafft aber auch ein Wiederherstellungsproblem. Wenn Abrechnung, Identitätsprüfung, Support oder das Control Panel gesperrt werden, können mehrere unabhängige Geschäftsfunktionen gleichzeitig gesperrt werden.

Die lokale Loop-Preisgestaltung macht die Rack- und Routing-Frage explizit

Die Startseite von mci.net.id ist ungewöhnlich hilfreich, da sie nicht nur abstrakte Cloud-Dienste bewirbt. Sie wirbt mit 'Local Loop and FTTH connectivity solutions' und beschreibt 'hochgeschwindigkeitsdedizierte Bandbreite für zuverlässige Geschäftskommunikation'. Die Seite listet lokale Loop-Pakete zu Rp 10.000.000 pro Monat für 1 Gbit/s, Rp 20.000.000 pro Monat für 2 Gbit/s und Rp 30.000.000 pro Monat für 3 Gbit/s auf, mit 'Get a quote'-Links. Sie gibt auch an, dass Media Cloud sichere, leistungsstarke dedizierte Konnektivität, niedrige Latenz, skalierbare Integration und 24/7 lokalen Support bietet.

Diese Behauptungen entsprechen keiner öffentlichen Offenlegung von Einrichtungen. Sie verlagern die Analyse jedoch von einfachem Webhosting auf physische Infrastruktur. Ein lokaler Loop-Dienst benötigt einen Kunden-Zugangspfad, einen Zusammenschaltungspunkt, einen Backhaul-Pfad, einen Router, ein Support-Modell und einen Reparaturprozess. Der Ausfallpfad ist nicht mehr einfach 'die VPS ist ausgefallen'.

Es kann ein Last-Mile-Glasfaserproblem, ein Problem mit einem vorgelagerten Lieferanten, ein Zugangsrouterproblem, ein Rechenzentrum-Verbindungsproblem, ein Support-Dispatch-Problem, eine Abrechnungssperre oder ein kundenseitiges Geräteproblem sein, das der Anbieter möglicherweise nicht kontrolliert.

Die öffentliche Adressgeschichte erfordert ebenfalls Vorsicht. Die APNIC/IDNIC-Nummernressourceneinträge geben eine Adresse im Prudential Center in Süd-Jakarta an. Die aktuellen öffentlichen Footer von Media Cloud verweisen die Leser auf Epicentrum Walk 3rd Floor Unit A306‑307, Jl. HR Rasuna Said, Kuningan, Süd-Jakarta. Beide können auf unterschiedliche Weise wahr sein: eine kann eine Registeradresse sein, die andere ein aktuelles Büro oder Support-Standort, und keine identifiziert notwendigerweise, wo Kunden-Workloads oder Router tatsächlich gehostet werden.

Die Unterscheidung ist wichtig, weil Kunden oft eine geschäftliche Kontaktadresse mit einer Einrichtungsadresse gleichsetzen. Sie sollten das nicht tun.

Die lokale Loop-Seite nennt weder das Rechenzentrum, das Exchange-Gebäude, die Glasfaserroute, die vorgelagerten Transit-Anbieter, die Servicegrenze noch den Wiederherstellungsort. Dies ist für eine öffentliche Marketingseite normal, aber es bedeutet, dass der Käufer die Frage stellen muss. Wenn der angebotene lokale Loop im selben Gebäude wie die gehostete Workload endet, unterscheidet sich das Ausfallmodell von einem Loop, der in einem separaten Telekom-Hotel landet. Wenn der Loop von einem Partner bereitgestellt wird, können Rückerstattungs- und Eskalationspfade von der Ticket-Warteschlange des Partners abhängen.

Wenn der Kunde Routing-Diversität benötigt, muss er wissen, ob zwei Leitungen gemeinsame Kabelkanäle, Gebäudeeingänge, Patchpanels oder ein einzelnes vorgelagertes Gateway nutzen.

Dies soll nicht sagen, dass das lokale Loop-Angebot von Media Cloud schwach ist. Es soll unterstreichen, dass es physische Abhängigkeit unvermeidlich macht. Gehostete Kapazität scheint elastisch, bis die letzte Meile oder der Upstream-Pfad ausfällt. Ein Kunde, der Cloud und lokale Konnektivität vom selben Anbieter kauft, sollte fragen, ob dieses Bündeln die Kontrolle erhöht oder einfach Ausfälle konzentriert.

AS140449 kündigt derzeit eine kleine, konsistente Gruppe von Präfixen an

Die Routing-Belege sind klarer als die der Unternehmensseite. DieRIPEstat AS140449-Übersichtidentifizierte den Inhaber als 'MEDIACLOUD‑AS‑ID – PT Media Cloud Indonesia' und zeigte, dass die AS während des Checks im Juli 2026 angekündigt wurde. DieRIPEstat angekündigte Präfixe-Ansicht listete 103.152.240.0/24, 103.152.241.0/24 und 2406:38c0::/32 als sichtbar im Fenster vom 27.06.2026 bis 11.07.2026 auf. Das bedeutet, dass das registrierte /23 betrieblich in zwei sichtbare IPv4-/24-Ankündigungen aufgeteilt ist, während die IPv6-Zuteilung als /32 angekündigt wird.

Diese Konfiguration ist eher mit einem kleinen Betreiber als mit einer Hyperscale-Cloud vereinbar. Zwei /24 bieten eine sichtbare öffentliche Präsenz, genug für Websites, Shared Hosting, VPS-Adressen, Steuerungssysteme oder lokale Dienste, aber keinen massiven Retail-Cloud-Fußabdruck. Das IPv6 /32 ist in Adressbegriffen viel größer, aber das IPv6-Adressvolumen darf nicht mit installierter Rechenkapazität verwechselt werden. Die Frage der nutzbaren Kapazität ist nicht die Anzahl der vorhandenen Adressen, sondern die Anzahl der Workloads, die gehostet, verschoben, wiederhergestellt und unterstützt werden können, wenn etwas ausfällt.

RIPEstat'sRouting-Verlauffügt Kontinuität hinzu. Beide IPv4 /24 erscheinen im Verlauf seit September 2020, während das IPv6 /32 seit März 2021 erscheint. Im letzten beobachteten Intervall waren die IPv4-Präfixe bis zum 11.07.2026 sichtbar, und die IPv6-Route war ebenfalls bis zum 11.07.2026 sichtbar. Dies ist stärker als eine neu erstellte ruhende ASN. Es deutet auf eine öffentliche Routing-Oberfläche hin, die seit Jahren Bestand hat.

Aber der Verlauf enthält auch Perioden geringerer Sichtbarkeit. Öffentliche Route-Collectors können zeigen, dass sich die Sichtbarkeit geändert hat; sie können nicht erklären, warum. Ein Abfall kann Routing-Richtlinien, Collector-Abdeckung, ein Upstream-Problem, eine Wartungsperiode, Routenfilterung, RPKI- oder IRR-Effekte an anderer Stelle oder eine echte Dienstunterbrechung widerspiegeln. Es wäre unverantwortlich, den Verlauf in eine Behauptung eines bestimmten Ausfalls umzuwandeln, ohne Betreiber- oder Kundenbelege.

Sein Wert ist enger: Es zeigt, dass die öffentliche Routenkante ausreichend beobachtbar ist, um überwacht zu werden, und dass Kunden fragen können, was sich geändert hat, als sich die Sichtbarkeit änderte.

Der aktuelle BGP-Zustand ist ebenfalls lehrreich. RIPEstat'sBGP-Zustandsantwortzeigte viele globale Collector-Pfade zu Media Clouds Präfixen, die meisten Pfade erreichten AS140449 über AS138840. Andere Pfade in der Stichprobe enthielten große globale Transitnamen weiter upstream, aber die wiederholte unmittelbare Adjazenz zu AS138840 ist die Abhängigkeit, die zählt. Ein Kunde benötigt nicht jedes Detail der Route-Collector; er muss wissen, ob der Edge von Media Cloud einen Verlust oder eine Überlastung des unmittelbaren Upstream-Pfades überleben kann.

Die sichtbare Upstream-Geschichte deutet auf HSPnet und OpenIXP/NiCE hin

RIPEstat'sASN-Nachbarn-Ansichtverzeichnete drei benachbarte ASNs zum Zeitpunkt des Checks am 11.07.2026: AS138840 als dominanten linken Nachbarn, AS7717 als weiteren linken Nachbarn und AS149004 als rechten Nachbarn. APNIC identifiziertAS138840als einen indonesischen NAP-Eintrag, der mit PT Parsaoran Global Datatrans / HSPnet verbunden ist. APNIC identifiziertAS7717als OpenIXP‑AS‑ID‑AP. APNIC identifiziertAS149004als Morapido Net in Timor-Leste. Diese Bezeichnungen beweisen keine Verträge, aber sie helfen, die Routing-Nachbarschaft zu erklären.

PeeringDB fügt eine freiwillige Interconnection-Ansicht hinzu. IhreNetzwerk-API-Abfrage für AS140449listet 'PT Media Cloud Indonesia', Alias 'Mediacloud', Websitehttps://mci.net.id, Info-Typ 'Enterprise', IPv6-Unterstützung, eine allgemein offene Richtlinie, eine IX-Anzahl von 1 und eine Einrichtungsanzahl von 0 auf. Die zugehörigenetixlan-Abfragelistet OpenIXP / NiCE, einen 1 Gbit/s-Port, IPv4-Adresse 43.252.146.141, IPv6-Adresse 2001:7fa:f::457 und einen Betriebsstatus auf. Dienetfac-Abfragegibt keine Einrichtungseinträge zurück.

Die stärkste Lesart ist praktisch: Media Cloud hat einen sichtbaren Exchange-Anschluss bei OpenIXP/NiCE und eine öffentliche Routing-Nachbarschaft, in der AS138840 der primäre Pfad ist, der von Collectors gesehen wird. Die schwächere Lesart wäre, aus diesen Feldern eine vollständige Resilienzarchitektur abzuleiten. PeeringDB wird vom Betreiber gepflegt und ist freiwillig. Ein 1 Gbit/s-Exchange-Port beweist nicht, dass der gesamte Kundenverkehr während eines Transitproblems über die Exchange fließen kann.

Eine Einrichtungsanzahl von 0 beweist nicht, dass das Unternehmen keine Racks hat; es bedeutet lediglich, dass PeeringDB keine Einrichtungseinträge für das Netzwerk listet. Eine beobachtete Upstream-Adjazenz beweist nicht, ob eine Verbindung Transit, Peering, Backup oder ein Route-Server-Pfad ist, es sei denn, sie wird durch Betreiberdokumentation gestützt.

Die RADB-Routenobjekte verstärken dieselbe Vorsicht. Eine RADB-Abfrage für AS140449 gab Routenobjekte für 103.152.240.0/24 und 103.152.241.0/24 mit Ursprung AS140449 und Beschreibungen zurück, die PT Media Cloud Indonesia nennen. Das route6-Objekt für 2406:38c0::/32 verwendete Ursprung AS140449, aber die Bemerkungen beschrieben ein proxy-registriertes Routenobjekt für eine HSP-Global-Kundenroute, die unter der Media-Cloud-Ursprungs-AS exportiert wird, verwaltet von MAINT‑AS138840.

Diese Formulierung macht die Lieferantenvertragsfrage zentral: Wenn die IPv6-Route davon abhängt, dass HSP das Routenobjekt oder die Upstream-Vereinbarung pflegt, müssen Kunden wissen, wer die Entität reparieren kann, wer die Filter ändern kann und was passiert, wenn der Upstream-Vertrag oder Support-Kanal ausfällt.

Die Routenursprungsabsicherung bleibt unvollständig

Die Routenursprungsvalidierung ist kein vollständiger Resilienztest, aber sie ist eine bedeutende Überprüfung. Sie verifiziert, ob eine veröffentlichte Route Origin Authorisation (ROA) ein bestimmtes Präfix und eine Ursprungs-AS unterstützt. Während der RIPEstat-Checks im Juli 2026 gaben103.152.240.0/24,103.152.241.0/24und2406:38c0::/32den Status 'unknown' zurück, ohne eine validierende ROA in der geprüften Ansicht. RADB zeigte ebenfalls einen RPKI-Ursprungsvalidierungsstatus von 'not_found' für die Routenobjekte.

Unbekannt ist nicht dasselbe wie ungültig. Es bedeutet, dass die geprüften Routenursprungsvalidierungsdaten keine autorisierende ROA gefunden haben. Das praktische Risiko besteht darin, dass Netzwerke mit strengen Routing-Richtlinien unbekannte Routen möglicherweise anders behandeln als gültige Routen, oder dass eine zukünftige Route-Hijack- oder Fehlkonfiguration durch automatisierte Richtlinien schwerer zu filtern sein wird.

Für Kunden ist dies nicht die einzige Sicherheitsfrage, aber es ist eine gute Beschaffungsfrage: Beabsichtigt Media Cloud, ROAs für seine angekündigten Präfixe zu veröffentlichen, und kann es nachweisen, dass die Routenobjekte und ROAs von der Partei mit operativer Verantwortung gepflegt werden?

RPKI kann auch nicht die Servicequalität beweisen. Ein gültiger Routenursprung würde nicht anzeigen, wie viele Server online sind, ob Backups funktionieren, ob ein lokaler Loop Pfadvielfalt hat oder ob ein Techniker schnell Hardware austauschen kann. Es schließt nur eine Kategorie von Routing-Risiken. In diesem Fall macht das Fehlen validierender ROAs die öffentliche Steuerungsebene weniger vollständig als den Produktkatalog. Diese Lücke ist behebbar, aber sie muss anerkannt werden.

Die breitere Lehre für Kunden ist, dass die Resilienz gehosteter Kapazität viele Schichten hat. RPKI schützt die Ursprungsautorisierung. IRR-Objekte beeinflussen Filter. BGP-Nachbarn beeinflussen die Erreichbarkeit. Exchange- und Transit-Vereinbarungen beeinflussen Pfadentscheidungen. Die Einrichtung, Stromversorgung, Ersatzteile und Support beeinflussen die Reparatur. Backups und Exportpfade beeinflussen die Wiederherstellung. Die öffentlichen Belege von Media Cloud sind in der Mitte dieser Kette am stärksten und an den Enden schwächer: Die Routensichtbarkeit ist klar; Datenportabilität und getestete Wiederherstellung sind nicht öffentlich.

Media Clouds eigene Bedingungen beschreiben den Ausfallpfad

Die rechtlichen Seiten des Unternehmens sind keine ausgefeilten technischen Schemata, aber sie sind operativ aufschlussreich. Diemediacloud.id-Nutzungsbedingungendefinieren Dienste weit gefasst, einschließlich Domain-Namensregistrierung, Hosting, Website-Erstellungsdienste und Internetdienste. Die Bedingungen besagen, dass Hosting Website-Inhalte speichert und bereitstellt, und dass Internetdienste Fernsehen, E-Mail, Konnektivität und verwandte Dienste umfassen können. Sie besagen auch, dass Media Cloud kommerziell angemessene Anstrengungen unternehmen wird, um die Website und Dienste vierundzwanzig Stunden am Tag, sieben Tage die Woche bereitzustellen.

Derselbe Verfügbarkeitsabschnitt ist wichtiger als der Verfügbarkeitssatz. Er besagt, dass Dienste aus Gründen wie Gerätefehlfunktionen, regelmäßige Wartung, Reparaturen oder Austausch, Ursachen außerhalb der angemessenen Kontrolle, Unterbrechung oder Ausfall von Telekommunikations- oder digitalen Übertragungsverbindungen, feindliche Netzeingriffe, Netzüberlastung und andere Ausfälle unzugänglich oder nicht betriebsbereit sein können. Er besagt auch, dass Media Cloud keine Kontrolle über die kontinuierliche oder ununterbrochene Verfügbarkeit hat. Diese Formulierung ist nicht ungewöhnlich; viele Anbieter verwenden ähnliche Haftungsausschlüsse.

Hier gibt sie den Kunden jedoch eine präzise Liste der genauen Abhängigkeitskategorien, die sie testen sollten.

DieRückerstattungsrichtlinieist ebenso spezifisch. Sie besagt, dass Domain-Registrierungsgebühren in der Regel nicht erstattungsfähig sind, sobald sie registriert oder verlängert wurden; Hosting- und Website-Erstellungsdienste werden nach dem Kauf nicht erstattet; und Breitband- oder dedizierte Internetdienste können für eine Rückerstattung in Frage kommen, wenn der Dienst für mehr als sieben Tage mal 24 Stunden ununterbrochen ausgefallen ist oder wenn Media Cloud den Dienst aufgrund technischer Schwierigkeiten oder eines Verbots durch den örtlichen Nachbarschaftsvorsteher nicht weiter erbringen kann. Dies ist eine auffällige operative Schwelle. Es deutet darauf hin, dass der Rückerstattungsauslöser für Internetkonnektivität in Tagen gemessen wird, nicht in Minuten oder Stunden.

Kunden sollten die Rückerstattungsberechtigung nicht mit operativer Resilienz verwechseln. Eine Rückerstattung nach einer Woche ununterbrochenem Ausfall stellt keine Anwendung wieder her, migriert kein Postfach, stellt keine Datenbank wieder her oder hält einen Online-Shop während des Ausfalls am Laufen. Sie definiert lediglich einen finanziellen Rechtsbehelf. Ein Kunde mit kritischen Workloads sollte Service-Level-Ziele, Eskalation von Vorfällen, proaktive Benachrichtigungen, Wartungsfenster, Datenexportpflichten und gemessene Wiederherstellungsziele verlangen, die sich von der Rückerstattungsrichtlinie unterscheiden.

Aus diesem Grund verweist der Artikeltitel auf Racks, Transit und Reparaturfenster. Die rechtlichen Bedingungen von Media Cloud identifizieren dieselben Kategorien: Ausrüstung, Wartung, Telekommunikationsverbindungen, Überlastung und Angriff. Die öffentlichen Routing-Daten zeigen dann, wo eine große Transitabhängigkeit auftritt. Die Aufgabe des Käufers ist es, diese öffentlichen Hinweise in vertragliche und testbare Belege zu verwandeln.

Datenlokalisierung wird nicht durch eine indonesische Marke gelöst

Media Clouds Positionierung ist stark indonesisch. Die Domain-Seite betont die.id-Identität, die VPS-Seite sagt 'VPS Indonesia', der Footer gibt eine Kontaktadresse in Süd-Jakarta an, und die APNIC/IDNIC-Datensätze ordnen die AS und Adressressourcen in Indonesien ein. Für viele Kunden, insbesondere kleine Unternehmen, mag dies der Hauptpunkt sein: ein lokaler Anbieter, eine lokale Sprache, lokale Zahlungserwartungen und Support, der über indonesische Kanäle erreichbar ist.

Aber Datensouveränität und -lokalisierung erfordern mehr als ein Länderlabel. Eine gehostete Website kann auf Media Clouds Adressen liegen, während E-Mail über Google oder Microsoft abgewickelt wird. Ein Support-Ticket kann personenbezogene Daten enthalten. Ein Backup kann in einem anderen System als dem primären Server gespeichert sein. Eine Domain-Registrierung kann Registrar- und Registry-Prozesse umfassen. Eine DDoS-Mitigationsbehauptung kann auf Upstream-Filterung oder einer Drittanbieterplattform beruhen. Jede Schicht kann Daten, Metadaten oder Zugriffsrechte an einem anderen operativen Standort platzieren.

DieDatenschutzrichtliniedes Unternehmens besagt, dass es Kontaktinformationen, Abrechnungsinformationen, Kontokennungen, benutzererstellte oder hochgeladene Inhalte, Protokolldaten, Geräteinformationen und Cookies oder ähnliche Technologien erhebt. Sie besagt, dass personenbezogene Daten mit Dienstleistern, Drittanbieterpartnern zu Marketing- oder Werbezwecken, im Rahmen von Geschäftstransaktionen oder wenn gesetzlich erforderlich, geteilt werden können. Sie besagt auch, dass personenbezogene Daten in andere Länder als das des Benutzers übertragen und dort verarbeitet werden können, und dass keine Methode der Internetübertragung oder elektronischen Speicherung vollständig sicher ist. Dies ist eine allgemeine Datenschutzsprache, aber in einem Hosting-Kontext ist sie wichtig: Der Anbieter erkennt die Möglichkeit einer grenzüberschreitenden und drittanbieterseitigen Verarbeitung an.

Der indonesische rechtliche Kontext erhöht auch die Messlatte für ein klares Datenmanagement. Die Regierungsverordnung Nr. 71 von 2019 über elektronische Systeme und Transaktionen wird von JDIH Kemkomdigi aufdieser offiziellen Seiteveröffentlicht. Die Seite enthält Bestimmungen zur Registrierung von Betreibern elektronischer Systeme, Zuverlässigkeit, Sicherheit, Risikomanagement, Service-Level-Vereinbarungen und Grundsätzen der Verarbeitung personenbezogener Daten. Das Gesetz Nr. 27 von 2022 über den Schutz personenbezogener Daten wird aufJDIH Kemkomdigiveröffentlicht. Dieser Artikel behauptet nicht, dass Media Cloud für jedes Produkt in eine bestimmte regulatorische Kategorie fällt, aber der nationale Rahmen erklärt, warum Kunden fragen sollten, wo Daten, Backups, Protokolle, Tickets und Supportzugriff tatsächlich residieren.

Der praktische Test ist einfach. Eine indonesische VPS sollte mit einer Standortantwort kommen: Wo ist der primäre Host, wo sind die Backups, wo ist die Steuerungsebenenidentität, wo sind die Protokolle und welche Drittanbieterdienste wickeln E-Mail, DNS, DDoS-Filterung, Support oder Abrechnung ab? Ohne diese Matrix bleibt 'lokal' ein hilfreiches Marketingsignal, aber keine vollständige Souveränitätssicherung.

Installierte Kapazität und nutzbare Kapazität sind unterschiedlich

Der öffentliche Netzwerk-Fußabdruck von Media Cloud unterstützt eine Erzählung von bescheidener, aber echter installierter Kapazität. Es hat eine registrierte AS, ein geroutetes IPv4 /23 aufgeteilt in zwei /24, ein IPv6 /32, öffentliche Websites innerhalb desselben IPv4-Blocks, einen PeeringDB-Exchange-Eintrag, ein lokales Loop-Angebot und VPS-/Hosting-/E-Mail-Produkte. Dies ist konkreter als ein reiner Wiederverkäufer ohne erkennbaren Edge. Es reicht aus, um das Interesse der Kunden zu rechtfertigen.

Die nutzbare Kapazität ist die schwierigere Frage. Ein VPS-Produkt mag dedizierte Ressourcen und NVMe-Speicher bewerben, aber die öffentlichen Seiten offenbaren nicht, wie viele Hypervisoren existieren, wie Speicher repliziert wird, ob Kunden-Backups außerhalb des Racks oder außerhalb des Standorts sind, wie viele Ersatzmaschinen bevorratet werden, welcher Anteil der Kapazität für Failover reserviert ist oder ob das Control Panel funktionieren kann, wenn das Produktionsnetzwerk ausfällt.

Ein lokales Loop-Produkt mag 1 Gbit/s, 2 Gbit/s oder 3 Gbit/s bewerben, aber die öffentlichen Seiten offenbaren nicht die Glasfaserpfade, Interconnection-Diversität, Betreiberdiversität oder die Überlastungsrichtlinie während eines Ausfalls.

Diese Unterscheidung ist während eines Ausfalls wichtig. Installierte Kapazität ist das, was ein Anbieter an einem normalen Tag verkauft. Nutzbare Kapazität ist das, was nach einem Ausfall eines Servers, Routers, Glasfaserpfads, vorgelagerten Lieferanten, Exchange-Ports, einer Stromversorgung, einer Support-Warteschlange oder eines Abrechnungskontos übrig bleibt. Wiederherstellbare Kapazität ist das, was innerhalb der Ausfallzeit- und Datenverlusttoleranz des Kunden wiederhergestellt werden kann. Kunden kaufen die zweite und dritte Kategorie, unabhängig davon, ob die Rechnung sie benennt.

Media Clouds sichtbares Upstream-Muster macht diese Unterscheidung dringlicher. Wenn die meisten globalen Collector-Pfade AS140449 über AS138840 erreichen, muss der Kunde fragen, ob AS138840 eine einzelne Upstream-Abhängigkeit, ein primärer Transitpfad, ein Route-Server-Pfad oder Teil eines breiteren Transit-Mix ist, den öffentliche Collectors nicht vollständig offenlegen. Wenn die OpenIXP/NiCE-Präsenz bei 1 Gbit/s liegt, muss der Kunde fragen, ob sie für settlement-freies Peering, Route-Server-Erreichbarkeit, Backup oder kritischen Kundenverkehr genutzt wird.

Wenn PeeringDB keine Einrichtungsdatensätze listet, muss der Kunde fragen, wo sich die Produktionsausrüstung befindet und wie der physische Zugang verwaltet wird.

Keine dieser Fragen impliziert ein Verschulden. Es sind normale Infrastruktur-Due-Diligence-Fragen. Ein kleiner Anbieter kann ausgezeichnet sein, wenn er ehrlich über seine Grenzen ist, die Wiederherstellung testet und den Kunden gangbare Ausstiegspfade gibt. Ein großer Anbieter kann spröde sein, wenn er einen gemeinsamen Ausfallpunkt verbirgt. Die öffentlichen Belege für Media Cloud sind stark genug, um die ersten Fragen zu stellen, aber nicht stark genug, um sie abzuschließen.

Support und Abrechnung sind Teil der Infrastruktur

Media Cloud verkauft seine Produkte über einen Shop, der eine Anmeldung, Kontaktlinks und WhatsApp-Buttons erfordert. Der Footer listet[email protected]im Shop und[email protected]auf der Unternehmensseite, während mci.net.id support.mci.net.id unter 103.152.240.243 bereitstellt. Dies gibt den Kunden mehrere Support-Einstiegspunkte, aber die Resilienzfrage ist, ob diese Einstiegspunkte während eines Vorfalls ausreichend unabhängig sind.

Support ist Infrastruktur, weil er Erkennung in Reparatur verwandelt. Wenn eine VPS ausfällt, braucht der Kunde mehr als eine generische Bestätigung. Er braucht eine qualifizierte verantwortliche Person, eine Diagnose, einen geschätzten Wiederherstellungspfad und eine Möglichkeit, Daten wiederherzustellen, wenn die Wiederherstellung die Frist des Kunden verpasst. Wenn ein lokaler Loop ausfällt, muss der Kunde wissen, ob Media Cloud einen Techniker entsenden kann, ob ein Partner die letzte Meile kontrolliert und ob derselbe Stromkreis das Support-Portal trägt.

Wenn die Abrechnung ein Konto sperrt, braucht der Kunde einen Eskalationspfad, der den Geschäftsstatus vom Notfalldatenzugriff trennen kann.

Die Nutzungsbedingungen machen den Konto- und Zahlungsstatus operativ relevant. Preise können sich ändern; Nichtzahlung kann zur Aussetzung oder Kündigung führen; Kunden sind für die Aufrechterhaltung der Kontosicherheit verantwortlich; Media Cloud kann den Zugang bei Verstößen aussetzen oder kündigen. Diese Klauseln sind Standard, aber sie zeigen, dass die Steuerungsebene nicht rein technisch ist. Eine Domain, ein Hosting-Plan, ein Postfach oder eine VPS können aufgrund eines administrativen Zustands ebenso ausfallen wie aufgrund eines Hardwarezustands.

Die E-Mail-Produkte machen dies noch sichtbarer. Die E-Mail-Seiten beschreiben Migrationsunterstützung, Fehlerbehebung, Webmail, Anti-Spam, Anti-Virus, DKIM-Signaturen, automatische Backups, Mail-Trace-Funktionen und Audit-Logs. Wenn diese Teil des Geschäftsprozesses eines Kunden sind, muss die Wiederherstellung den Postfachexport, DNS-Kontinuität, DKIM/SPF/DMARC-Kontinuität, Archivzugriff und Support-Belege umfassen. Es reicht nicht zu sagen 'E-Mail wird gehostet'. Der Kunde muss wissen, was passiert, wenn das E-Mail-Produkt oder seine externe Plattformabhängigkeit ausfällt.

Für Media Cloud sollte der Käufer vor der Verlagerung kritischer Workloads ein Support-Verfahrenshandbuch anfordern. Wer nimmt dringende Anrufe entgegen? Gibt es eine telefonische Eskalation für einen lokalen Loop- oder VPS-Ausfall? Sind Support-Mitarbeiter befugt, Workloads zu verschieben, oder nur Tickets zu erstellen? Sind Konto-, Abrechnungs- und Missbrauchs-Warteschlangen von der Incident-Response getrennt? Wie schnell kann das Unternehmen einen vollständigen VPS-Disk-Export, Website-Dateien, Postfachinhalte, DNS-Zone und Domain-Autorisierungscode bereitstellen, wenn der Kunde sich entscheidet, zu gehen?

Das Hauptrisiko für den Kunden ist Konzentration

Die Bequemlichkeit von Media Cloud ist auch ihr Risiko. Ein Kunde kann plausibel die Domain, Website, Hosting, VPS, SSL-Zertifikat, professionelle E-Mail und dedizierte Konnektivität von derselben Markenfamilie erwerben. Dies kann das Lieferantenmanagement für ein kleines Unternehmen reduzieren. Es kann auch einen Anbietervorfall in einen zusammengesetzten Ausfall verwandeln: DNS-Verlängerung, Zertifikatsausstellung, Webhosting, VPS-Erreichbarkeit, E-Mail-Zugriff und lokale Konnektivität können alle dasselbe Support-Team oder dieselbe Kontobeziehung erfordern.

Die Infrastrukturversion der Konzentration ist ähnlich. Wenn der sichtbare Edge stark von AS138840 abhängt, wenn die Exchange-Oberfläche ein einzelner OpenIXP/NiCE-Eintrag ist, wenn die Produktion in einer nicht offengelegten Einrichtung sitzt und wenn der Support-Pfad an dasselbe Netzwerk gebunden ist, dann kann ein einziges operatives Problem mehrere Ebenen betreffen. Öffentliche Belege beweisen nicht, dass all diese Single Points existieren, aber sie widerlegen sie auch nicht. Die sichtbaren Aufzeichnungen reichen aus, um eine Antwort zu verlangen.

Kunden sollten die Konzentration auf vier Arten testen. Erstens, Identität und DNS vom Hosting trennen. Kann die Domain schnell übertragen werden? Können DNS-Einträge exportiert werden? Sind Zoneneinträge während eines Hosting-Ausfalls erreichbar? Zweitens, Rechenleistung vom Speicher-Backup trennen. Kann der Kunde eine VPS oder Website bei einem anderen Anbieter wiederherstellen, ohne darauf zu warten, dass Media Cloud den ursprünglichen Host wieder aufbaut? Drittens, Konnektivität vom Anwendungshosting trennen. Wenn der lokale Loop ausfällt, kann der Kunde den gehosteten Dienst über einen anderen Zugangsanbieter erreichen?

Viertens, Support von der betroffenen Plattform trennen. Wenn das Service-Portal ausgefallen ist, gibt es einen unabhängigen Eskalationskanal?

Die Rückerstattungsschwelle für den lokalen Loop sollte die Gedanken fokussieren. Ein Dienst, der länger als sieben ununterbrochene Tage ausgefallen ist, liegt weit jenseits der Toleranz vieler Geschäfts-Workloads. Ein Kunde, der eine Woche lang nicht arbeiten kann, sollte sich nicht auf die Rückerstattungsrichtlinie als Kontinuitätsplan verlassen. Sie sollten vor dem Kauf Failover, getestete Backups, alternativen Zugang und schriftliche Eskalationsbedingungen verlangen.

Dies ist die praktischste Schlussfolgerung aus der öffentlichen Akte. Media Cloud sieht aus wie ein echter operativer Anbieter mit einem identifizierbaren Netzwerk. Es ist eine Bewertung wert. Dieselben Belege zeigen, warum die Bewertung über die Produktseite hinausgehen muss: Ein Kunde benötigt Belege für Diversität, Wiederherstellung und Ausstieg.

Was ein ernsthafter Käufer als nächstes fragen sollte

Ein ernsthafter Käufer sollte am Routing-Edge beginnen. Fragen Sie Media Cloud, welche Dienste AS140449 verwenden, welche Präfixe Kunden-VPS- oder Hosting-Pools zugewiesen sind und ob Kundendienste hinter anderen Anbietern sitzen. Fragen Sie, ob ROAs für 103.152.240.0/24, 103.152.241.0/24 und 2406:38c0::/32 veröffentlicht werden und wer die IRR-Routenobjekte pflegt. Fragen Sie, ob AS138840 der primäre Transit, ein Backup-Transit, eine Route-Server-Adjazenz oder eine andere Beziehung ist und ob es einen zweiten unabhängigen Transitpfad mit ausreichender bezahlter Kapazität gibt, um Kundenverkehr während eines Ausfalls zu transportieren.

Als nächstes fragen Sie nach dem Einrichtungsmodell. Welche(s) Rechenzentrum/Rechenzentren hostet/hosten die VPS- und Hosting-Produkte? Sind die Racks Eigentum, geleast oder untervermietet? Gibt es separate Stromversorgungen, separate Router, separate Firewalls und separate Glasfasereingänge? Wird OpenIXP/NiCE für kritischen Kundenverkehr genutzt und hat der 1 Gbit/s-Exchange-Port eine Überlastungsüberwachung?

Wenn PeeringDB keine Einrichtungen listet, liegt das daran, dass das Unternehmen sich entscheidet, sie nicht offen zu legen, weil das Netzwerk über einen Partner bereitgestellt wird, oder weil Kunden-Workloads nicht in einer öffentlichen Interconnection-Einrichtung platziert sind?

Drittens fragen Sie nach Wiederherstellungstests. Wann wurde die letzte VPS-Disk-Wiederherstellung durchgeführt? Wie lange hat es gedauert? Wurde sie auf demselben Host, einem anderen Host in derselben Einrichtung oder an einem anderen Ort wiederhergestellt? Wie werden WordPress- und Sitejet-Hosting-Backups gespeichert? Kann ein Kunde einen Export testen, ohne den Dienst zu kündigen? Werden E-Mails so gesichert, dass der Kunde sie abrufen kann? Sind DKIM-Schlüssel, DNS-Zonen, Zertifikate und Postfacharchive in einem Ausstiegspaket enthalten?

Viertens fragen Sie nach Support-Grenzen. Was ist der Haupteinsatzpfad für VPS, Hosting, Domain, E-Mail, SSL und lokale Loop-Dienste? Welche Kontaktmethode bleibt verfügbar, wenn mci.net.id oder mediacloud.id nicht erreichbar ist? Erstellt der WhatsApp-Support ein formelles Ticket? Gibt es definierte Reaktions- und Wiederherstellungszeiten? Welche Ereignisse generieren Kundenbenachrichtigungen vor Beginn der Wartung?

Schließlich fragen Sie, wie die rechtlichen und datenschutzrechtlichen Erklärungen mit der tatsächlichen Datenplatzierung übereinstimmen. Die Datenschutzrichtlinie erlaubt grenzüberschreitende Verarbeitung, und die DNS/MX-Belege zeigen eine Abhängigkeit von globalen Plattformen für Teile des Geschäfts. Der Kunde sollte fragen, wo personenbezogene Daten, Protokolle, Backups, Tickets und Abrechnungsunterlagen verarbeitet werden und ob jedes Produkt vertraglich in Indonesien gehalten werden kann.

Diese Fragen sind nicht feindselig. Sie sind der Weg, wie ein Käufer Media Clouds sichtbares öffentliches Netzwerk in eine getestete Abhängigkeit verwandelt. Das Unternehmen hat genügend öffentliche Belege, um das Gespräch zu rechtfertigen. Es hat noch nicht genügend öffentliche Belege, um Kunden zu erlauben, es zu überspringen.

Der Evidenzgrad

PT Media Cloud Indonesia erhält einen mittleren öffentlichen Evidenzgrad. Der Grad ist kein Qualitätsscore für das Unternehmen; es ist ein Score dafür, was die öffentlichen Belege stützen können. Positiv ist, dass die Identität und die Betriebsoberfläche für einen regionalen Hosting-Anbieter ungewöhnlich konkret sind. APNIC/IDNIC verbindet das Unternehmen mit AS140449, 103.152.240.0/23 und 2406:38c0::/32. RIPEstat sah drei aktive Präfixe, die im Juli 2026 angekündigt wurden. Die öffentlichen Websites lösen innerhalb des IPv4-Blocks des Unternehmens auf.

Media Cloud bewirbt eine spezifische Produktpalette: Domains, Hosting, VPS, SSL, E-Mail, Webdienste und lokale Loop-Konnektivität. PeeringDB listet das Netzwerk und einen OpenIXP/NiCE-Anschluss.

Die Herabstufung betrifft die Resilienz-Belege. Öffentliche Belege nennen keine Produktionseinrichtung. PeeringDB listet keine Einrichtungseinträge. Die Routenursprungsvalidierung gab für die geprüften Präfixe 'unknown' zurück. Die sichtbaren BGP-Pfade sind stark mit AS138840 verbunden, und das IPv6-Routenobjekt beschreibt eine proxy-registrierte HSP-Global-Kundenroute. Media Clouds eigene Bedingungen besagen, dass Dienste durch Gerätefehlfunktionen, Wartung, Reparatur, Telekommunikationsverbindungsausfall, feindliche Angriffe, Überlastung und andere Ursachen unterbrochen werden können.

Die Rückerstattungsrichtlinie deutet darauf hin, dass einige Internetdienst-Abhilfen um anhaltende ununterbrochene Ausfälle herum formuliert sind und nicht um kurze betriebliche Ausfallzeiten.

Diese Kombination unterstützt eine klare Schlussfolgerung: Media Cloud ist ein echter indonesischer Anbieter von gehosteten und Konnektivitätsdiensten mit einem sichtbaren Netzwerk, aber Kunden sollten das sichtbare Netzwerk nicht als Beweis für Multi-Site-Cloud-Resilienz behandeln. Der angemessene Due-Diligence-Pfad ist, die Einrichtungsplatzierung, Transitdiversität, Routenursprungskontrollen, Backup- und Wiederherstellungstests, Support-Eskalation, Abrechnungskontinuitätsregeln und Datenexportrechte zu überprüfen.

Wenn diese Überprüfungen zufriedenstellend sind, geben die öffentlichen Belege den Kunden etwas Solides, das sie überwachen können. Wenn diese Überprüfungen fehlen, kann die Bequemlichkeit eines gebündelten lokalen Anbieters zu konzentrierter Abhängigkeit werden.