Resumen
- PT Media Cloud Indonesia tiene evidencia operativa pública más sólida que muchos pequeños host: los registros APNIC/IDNIC lo vinculan a AS140449, 103.152.240.0/23 y 2406:38c0::/32, mientras que RIPEstat observó 103.152.240.0/24, 103.152.241.0/24 y 2406:38c0::/32 anunciados por AS140449 durante la ventana de verificación de julio de 2026.
- La empresa comercializa un amplio paquete bajo la marca Media Cloud: dominios, alojamiento WordPress y Sitejet, VPS indonesio, SSL, correo electrónico profesional, servicios web, promoción de alojamiento de juegos y una oferta de bucle local en mci.net.id que muestra paquetes de ancho de banda dedicado de 1 Gbit/s, 2 Gbit/s y 3 Gbit/s.
- La preocupación por la resiliencia es igualmente concreta. PeeringDB enumera una conexión de intercambio en OpenIXP/NiCE y cero registros de instalaciones para la red; los datos de vecinos de RIPEstat están dominados por AS138840, y el objeto de ruta IPv6 de RADB describe una ruta de cliente HSP Global registrada por proxy. Estas son pruebas de interconexión visibles, no pruebas de capacidad independiente multisitio.
- Los propios términos de uso y política de reembolso de Media Cloud hacen visible la ruta de falla física: los servicios pueden volverse inaccesibles debido a mal funcionamiento del equipo, mantenimiento, reparación o reemplazo, interrupción del enlace de telecomunicaciones, ataques hostiles, congestión u otras fallas; el reembolso de los servicios de Internet está condicionado a más de siete días continuos de interrupción o la imposibilidad de continuar con el servicio.
- El nivel de evidencia es Medio. La identidad, la superficie del producto, el espacio de direcciones enrutado y la accesibilidad actual están bien respaldados; la evidencia pública sobre la ubicación de las instalaciones, la capacidad de reserva, la diversidad de tránsito, la recuperación probada y los límites de portabilidad de datos siguen siendo incompletos.
La empresa es visible, pero la dependencia sigue siendo física
PT Media Cloud Indonesia merece una lectura más atenta que una simple etiqueta de 'pequeño host'. La empresa presenta dos superficies públicas vinculadas. Una es el sitio corporativo orientado a la conectividad enmci.net.id, que promueve soluciones de bucle local y FTTH y dirige a los usuarios a la tienda de servicios en la nube. La otra esmediacloud.id, la superficie comercial orientada al cliente para dominios, alojamiento, VPS, certificados SSL, correo electrónico y servicios web. Estas dos superficies no son meras anécdotas de marca. Muestran que la empresa pide a los clientes que le confíen tanto su presencia básica en Internet como los servicios de infraestructura estructurante.
Esta confianza choca con limitaciones muy reales. Un VPS es una máquina virtual, pero se ejecuta en cómputo, almacenamiento, energía y refrigeración físicos. El 'ancho de banda ilimitado' es una frase de marketing, pero los paquetes aún atraviesan puertos, enrutadores, filtros, fibra óptica, contratos de tránsito y tejidos de intercambio. Una promesa de 'soporte 24/7' solo es útil si el cliente puede comunicarse con el equipo incluso cuando el servicio afectado, el sistema de tickets, el DNS o el estado de facturación están fallando.
La oferta de bucle local es aún más directa: depende del acceso de última milla, un punto de interconexión, una ruta ascendente, técnicos de guardia y una regla comercial sobre lo que sucede cuando el circuito permanece inactivo.
La evidencia pública comienza en la capa de recursos numéricos. El registro RDAP de APNIC/IDNIC paraAS140449enumera MEDIACLOUD-AS-ID, PT Media Cloud Indonesia, 'Proveedor de Servicios de Internet' y una dirección administrativa en el sur de Yakarta. APNIC/IDNIC también muestra la red IPv4103.152.240.0/23y la red IPv62406:38c0::/32bajo el nombre MEDIACLOUD-ID. Estos registros no prueban la ubicación de cada servidor, pero son mucho más sólidos que una página de revendedor anónimo. Muestran una empresa con recursos numéricos de Internet directamente visibles.
La empresa también aloja sus sitios web públicos dentro de esta huella. Una verificación de DNS durante esta investigación resolvió tanto mci.net.id como mediacloud.id a la dirección 103.152.240.97, dentro de la asignación 103.152.240.0/23. Esta es una señal modesta pero importante: el sitio web público no está simplemente alojado detrás de una puerta de enlace global sin un vínculo aparente con el registro de red. La marca, el ASN y el espacio de direcciones enrutado están suficientemente alineados para que la afirmación de infraestructura sea verificable.
La parte difícil no es demostrar que Media Cloud tiene presencia pública. La parte difícil es determinar el nivel de resiliencia del cliente que implica esta presencia. La evidencia de enrutamiento público puede mostrar qué prefijos son visibles, qué ASN son adyacentes a la red, si los datos de origen de la ruta están cubiertos y si un directorio de intercambio voluntario enumera un puerto. No puede mostrar el servidor de repuesto en el rack, el contrato de instalación, el proceso de copia de seguridad del cliente ni la persona autorizada para reemplazar el hardware después de la medianoche. Esta brecha es el núcleo del artículo.
La gama de productos anunciada va más allá de una simple página de VPS
Las páginas de productos de Media Cloud muestran una empresa que quiere ser una ventanilla única para los clientes indonesios que desean crear una presencia web. Latienda Media Cloudindica que proporciona dominios, alojamiento, un creador de sitios web, correo electrónico, certificados SSL y servicios VPS. Promociona dominios.id y.com, servicios de reventa y al por mayor, y un mosaico 'Mejor VPS Cloud Hosting' que apunta al producto VPS. Esto es importante porque una oferta amplia crea múltiples rutas de dependencia. Un cliente puede comprar un dominio, DNS, certificado SSL, buzón de correo, creador de sitios web y VPS del mismo proveedor y luego descubrir durante un incidente que la dependencia técnica y la dependencia de la cuenta están estrechamente vinculadas.
Lapágina de VPSes la afirmación más clara de capacidad alojada. Comercializa 'VPS Indonesia', describe el servicio como 'VPS indonesio rápido y estable a precios asequibles' y enumera recursos dedicados al 100%, almacenamiento NVMe, ancho de banda ilimitado y protección DDoS. También indica que los clientes pueden elegir sistemas operativos y aplicaciones preconfiguradas. Este es exactamente el lenguaje que convierte una pequeña red en una dependencia comercial: los clientes no solo compran espacio de direcciones; esperan cómputo, almacenamiento, instalación de software, controles de seguridad y suficiente capacidad de red para mantener las aplicaciones accesibles.
Las páginas de alojamiento agregan una capa adicional.Alojamiento Sitejetpresenta alojamiento empaquetado con un creador de sitios web y destaca protección DDoS, cPanel, Softaculous e instalaciones con un clic.Alojamiento WordPressutiliza el mismo lenguaje de confiabilidad y características, aunque la tabla de planes no estaba disponible para la moneda detectada en el momento de la consulta. Esto es útil porque revela los supuestos de plataforma subyacentes a la experiencia del cliente. cPanel, Softaculous, los creadores de sitios web y el alojamiento WordPress dependen de paneles de control, estados de licencia, almacenamiento y prácticas de copia de seguridad. Estos son sistemas operativos, no meros nombres de productos estáticos.
El correo electrónico extiende aún más la dependencia.Alojamiento de correo electrónicoanuncia correo electrónico profesional con una garantía de disponibilidad del 99.9%, dominios personalizados, seguridad, monitoreo, soporte 24/7 y asistencia con configuración, migración y resolución de problemas.Correo electrónico profesionaldescribe 8 GB por buzón, webmail, antispam, antivirus, firmas DKIM, copias de seguridad automáticas, funciones de rastreo de correo y registros de auditoría. Los registros MX añaden matiz: mci.net.id usa protección de correo electrónico de Microsoft, mientras que mediacloud.id apunta a los intercambiadores de correo de Google aspmx. Esto no es contradictorio; muestra que algunas partes del negocio dependen de plataformas de correo electrónico externas, incluso cuando los sitios web públicos están en el propio espacio de direcciones de Media Cloud.
Lapágina de SSLy las páginas de dominios completan el panorama. Media Cloud vende capas de confianza sobre los servidores: registro de dominios, transferencia, identidad.id, certificados, generación de sitios e identidad de buzón. Un cliente que concentra estos servicios puede ganar conveniencia pero también crea un problema de recuperación. Si la facturación, la verificación de identidad, el soporte o el panel de control se bloquean, varias funciones comerciales independientes pueden bloquearse simultáneamente.
El precio del bucle local hace explícita la pregunta sobre el rack y el enrutamiento
La página de inicio de mci.net.id es inusualmente útil porque no solo promociona servicios abstractos en la nube. Anuncia 'soluciones de conectividad de bucle local y FTTH' y describe 'ancho de banda dedicado de alta velocidad para comunicaciones comerciales confiables'. La página enumera paquetes de bucle local a Rp 10,000,000 por mes para 1 Gbit/s, Rp 20,000,000 por mes para 2 Gbit/s y Rp 30,000,000 por mes para 3 Gbit/s, con enlaces 'Solicitar cotización'. También indica que Media Cloud proporciona conectividad dedicada segura y de alto rendimiento, baja latencia, integración escalable y soporte local 24/7.
Estas afirmaciones no equivalen a una divulgación pública de las instalaciones. Sin embargo, desplazan el análisis del simple alojamiento web a la infraestructura física. Un servicio de bucle local necesita una ruta de acceso al cliente, un punto de interconexión, una ruta de retorno, un enrutador, un modelo de soporte y un proceso de reparación. La ruta de falla ya no es simplemente 'el VPS está caído'.
Puede ser un problema de fibra de última milla, un problema de proveedor ascendente, un problema de enrutador de acceso, un problema de interconexión del centro de datos, un problema de despacho de soporte, un bloqueo de facturación o un problema del equipo del cliente que el proveedor puede o no controlar.
La historia de la dirección pública también requiere cuidado. Los registros de recursos numéricos de APNIC/IDNIC dan una dirección en Prudential Center en el sur de Yakarta. Los pies de página públicos actuales de Media Cloud dirigen a los lectores a Epicentrum Walk 3rd Floor Unit A306-307, Jl. HR Rasuna Said, Kuningan, South Jakarta. Ambas pueden ser ciertas de diferentes maneras: una puede ser una dirección de registro, la otra una oficina actual o ubicación de soporte, y ninguna identifica necesariamente dónde se alojan realmente las cargas de trabajo o los enrutadores del cliente.
La distinción es importante porque los clientes a menudo confunden una dirección de contacto corporativo con una dirección de instalación. No deberían.
La página de bucle local no menciona el centro de datos, el edificio de intercambio, la ruta de fibra, los proveedores de tránsito ascendente, el límite del servicio ni el sitio de recuperación. Esto es normal para una página de marketing pública, pero significa que el comprador debe hacer la pregunta. Si el bucle local ofrecido termina en el mismo edificio que la carga de trabajo alojada, el modelo de falla difiere de un bucle que aterriza en un hotel de telecomunicaciones separado. Si el bucle es entregado por un socio, la ruta de reembolso y escalación puede depender de la cola de tickets del socio.
Si el cliente necesita diversidad de enrutamiento, necesita saber si dos circuitos comparten conductos, entradas de edificio, paneles de conexión o una única puerta de enlace ascendente.
Esto no quiere decir que la oferta de bucle local de Media Cloud sea débil. Es para subrayar que hace inevitable la dependencia física. La capacidad alojada parece elástica hasta que la última milla o la ruta ascendente falla. Un cliente que compra conectividad en la nube y local del mismo proveedor debe preguntarse si esta agrupación aumenta el control o simplemente concentra la falla.
AS140449 actualmente anuncia un conjunto pequeño y consistente de prefijos
La evidencia de enrutamiento es más clara que la evidencia del sitio corporativo. Lavisión general de RIPEstat AS140449identificó al titular como 'MEDIACLOUD-AS-ID – PT Media Cloud Indonesia' y mostró que el AS fue anunciado durante la verificación de julio de 2026. Lavista de prefijos anunciados de RIPEstatenumeró 103.152.240.0/24, 103.152.241.0/24 y 2406:38c0::/32 como visibles en la ventana del 27/06/2026 al 11/07/2026. Eso significa que el /23 registrado se divide operativamente en dos anuncios /24 IPv4 visibles, mientras que la asignación IPv6 se anuncia como /32.
Esta configuración es consistente con un operador pequeño, no con una nube a hiperescala. Dos /24 proporcionan una presencia pública visible, suficiente para sitios web, alojamiento compartido, direcciones VPS, sistemas de control o servicios locales, pero no una gran huella de nube minorista. El /32 IPv6 es mucho más grande en términos de direcciones, pero el volumen de direcciones IPv6 no debe confundirse con la capacidad de cómputo instalada. La pregunta sobre la capacidad utilizable no es la cantidad de direcciones que existen, sino la cantidad de cargas de trabajo que se pueden alojar, mover, restaurar y respaldar cuando algo falla.
Elhistorial de enrutamiento de RIPEstatañade continuidad. Ambos /24 IPv4 aparecen en el historial desde septiembre de 2020, mientras que el /32 IPv6 aparece desde marzo de 2021. En el último intervalo observado, los prefijos IPv4 aún eran visibles hasta el 11/07/2026, y la ruta IPv6 también era visible hasta el 11/07/2026. Esto es más sólido que un ASN recién creado e inactivo. Sugiere una superficie de enrutamiento pública que ha persistido durante años.
Pero el historial también incluye períodos de menor visibilidad. Los colectores de rutas públicas pueden mostrar que la visibilidad cambió; no pueden explicar por qué. Una caída puede reflejar política de enrutamiento, cobertura del colector, un problema ascendente, un período de mantenimiento, filtrado de rutas, efectos de RPKI o IRR en otro lugar, o una interrupción genuina del servicio. Sería irresponsable convertir el historial en una afirmación de una interrupción específica sin evidencia del operador o del cliente.
Su valor es más limitado: muestra que el borde de ruta público es lo suficientemente observable como para ser monitoreado y que los clientes pueden preguntar qué cambió cuando la visibilidad cambió.
El estado BGP actual también es instructivo. Larespuesta del estado BGP de RIPEstatmostró muchas rutas de colectores globales hacia los prefijos de Media Cloud, la mayoría de las rutas llegando a AS140449 a través de AS138840. Otras rutas en la muestra incluían nombres de tránsito global grandes más arriba, pero la adyacencia inmediata repetida a AS138840 es la dependencia que importa. Un cliente no necesita cada detalle del colector de rutas; necesita saber si el borde de Media Cloud puede sobrevivir a una pérdida o congestión de la ruta ascendente inmediata.
La historia ascendente visible apunta a HSPnet y OpenIXP/NiCE
Lavista de vecinos ASN de RIPEstatregistró tres ASN adyacentes en la verificación del 11/07/2026: AS138840 como el vecino izquierdo dominante, AS7717 como otro vecino izquierdo y AS149004 como un vecino derecho. APNIC identificaAS138840como un registro NAP indonesio asociado con PT Parsaoran Global Datatrans / HSPnet. APNIC identificaAS7717como OpenIXP-AS-ID-AP. APNIC identificaAS149004como Morapido Net en Timor-Leste. Estas etiquetas no prueban contratos, pero ayudan a explicar el vecindario de enrutamiento.
PeeringDB añade una vista de interconexión voluntaria. Suconsulta API de red para AS140449enumera 'PT Media Cloud Indonesia', alias 'Mediacloud', sitio webhttps://mci.net.id, tipo de información 'Enterprise', soporte IPv6, una política generalmente abierta, un recuento de IX de 1 y un recuento de instalaciones de 0. La consulta asociada denetixlanenumera OpenIXP / NiCE, un puerto de 1 Gbit/s, dirección IPv4 43.252.146.141, dirección IPv6 2001:7fa:f::457 y un estado operativo. La consultanetfacno devuelve entradas de instalación.
La lectura más sólida es práctica: Media Cloud tiene una conexión de intercambio visible en OpenIXP/NiCE y un vecindario de enrutamiento público donde AS138840 es la ruta principal vista por los colectores. La lectura más débil sería inferir una arquitectura de resiliencia completa a partir de estos campos. PeeringDB es mantenido por el operador y voluntario. Un puerto de intercambio de 1 Gbit/s no prueba que todo el tráfico del cliente pueda fluir a través del intercambio durante un problema de tránsito.
Un recuento de instalaciones de 0 no prueba que la empresa no tenga racks; simplemente significa que PeeringDB no enumera entradas de instalaciones para la red. Una adyacencia ascendente observada no prueba si un enlace es de tránsito, peering, respaldo o una ruta de servidor de rutas a menos que esté respaldado por documentación del operador.
Los objetos de ruta de RADB refuerzan la misma precaución. Una consulta RADB para AS140449 devolvió objetos de ruta para 103.152.240.0/24 y 103.152.241.0/24 con origen AS140449 y descripciones que nombran a PT Media Cloud Indonesia. El objeto route6 para 2406:38c0::/32 usó origen AS140449, pero los comentarios describían un objeto de ruta registrado por proxy para una ruta de cliente HSP Global exportada bajo el AS de origen de Media Cloud, mantenido por MAINT-AS138840.
Esta redacción hace que la pregunta del contrato del proveedor sea central: si la ruta IPv6 depende de que HSP mantenga el objeto de ruta o el acuerdo ascendente, los clientes necesitan saber quién puede arreglar la entidad, quién puede cambiar los filtros y qué sucede cuando falla el contrato ascendente o el canal de soporte.
La garantía de origen de ruta sigue siendo incompleta
La validación de origen de ruta no es una prueba completa de resiliencia, pero es una verificación significativa. Verifica si una Autorización de Origen de Ruta (ROA) publicada respalda un prefijo y AS de origen dados. Durante las verificaciones de RIPEstat de julio de 2026,103.152.240.0/24,103.152.241.0/24y2406:38c0::/32devolvieron 'desconocido' sin una ROA validadora en la vista verificada. RADB también mostró un estado de validación de origen RPKI de 'no_encontrado' para los objetos de ruta.
Desconocido no es lo mismo que inválido. Significa que los datos de validación de origen de ruta verificados no encontraron una ROA autorizante. El riesgo práctico es que las redes que aplican políticas de enrutamiento estrictas pueden tratar las rutas desconocidas de manera diferente a las rutas válidas, o que un futuro secuestro de ruta o mala configuración será más difícil de filtrar mediante una política automatizada.
Para los clientes, esta no es la única pregunta de seguridad, pero es una buena pregunta de adquisición: ¿tiene intención Media Cloud de publicar ROA para sus prefijos anunciados, y puede demostrar que los objetos de ruta y las ROA son mantenidos por la parte con responsabilidad operativa?
RPKI tampoco puede probar la calidad del servicio. Un origen de ruta válido no indicaría cuántos servidores están en línea, si las copias de seguridad funcionan, si un bucle local tiene diversidad de ruta, o si un técnico puede cambiar el hardware rápidamente. Solo cierra una categoría de riesgo de enrutamiento. En este caso, la ausencia de ROA validadoras hace que el plano de control público sea menos completo que el catálogo de productos. Esta brecha es reparable, pero debe ser reconocida.
La lección más amplia para los clientes es que la resiliencia de la capacidad alojada tiene muchas capas. RPKI protege la autorización de origen. Los objetos IRR influyen en los filtros. Los vecinos BGP influyen en la accesibilidad. Los acuerdos de intercambio y tránsito influyen en las elecciones de ruta. Las instalaciones, la energía, los repuestos y el soporte influyen en la reparación. Las copias de seguridad y las rutas de exportación influyen en la recuperación.
La evidencia pública de Media Cloud es más fuerte en el medio de esta cadena y más débil en los extremos: la visibilidad de la ruta es clara; la portabilidad de datos y la restauración probada no son públicas.
Los propios términos de Media Cloud describen la ruta de falla
Las páginas legales de la empresa no son esquemas técnicos pulidos, pero son operativamente reveladoras. Lostérminos de servicio de mediacloud.iddefinen los servicios de manera amplia para incluir registro de nombres de dominio, alojamiento, servicios de creación de sitios web y servicios de Internet. Los términos establecen que el alojamiento almacena y sirve contenido del sitio web, y que los servicios de Internet pueden incluir televisión, correo electrónico, conectividad y servicios relacionados. También establecen que Media Cloud utilizará esfuerzos comercialmente razonables para proporcionar el sitio y los servicios las veinticuatro horas del día, los siete días de la semana.
La misma sección de disponibilidad es más importante que la frase de disponibilidad. Establece que los servicios pueden ser inaccesibles o inoperables por razones que incluyen mal funcionamiento del equipo, mantenimiento periódico, reparaciones o reemplazos, causas fuera del control razonable, interrupción o falla de enlaces de transmisión de telecomunicaciones o digitales, ataques hostiles a la red, congestión de la red y otras fallas. También establece que Media Cloud no tiene control sobre la disponibilidad continua o ininterrumpida. Esta redacción no es inusual; muchos proveedores utilizan descargos de responsabilidad similares.
Aquí, sin embargo, proporciona a los clientes una lista concisa de las categorías de dependencia exactas que deberían probar.
Lapolítica de reembolsoes igualmente específica. Establece que las tarifas de registro de dominio generalmente no son reembolsables una vez registradas o renovadas; los servicios de alojamiento y creación de sitios web no se reembolsan una vez comprados; y los servicios de banda ancha o Internet dedicado pueden ser elegibles para un reembolso si el servicio está inactivo durante más de siete días multiplicados por 24 horas de forma continua, o si Media Cloud no puede continuar prestando el servicio debido a dificultades técnicas o una prohibición del jefe de vecindario local. Este es un umbral operativo sorprendente. Sugiere que para la conectividad a Internet, el desencadenante del reembolso se mide en días, no en minutos u horas.
Los clientes no deben confundir la elegibilidad de reembolso con la resiliencia operativa. Un reembolso después de una semana de interrupción continua no restaura una aplicación, migra un buzón, recupera una base de datos ni mantiene una tienda en línea funcionando durante la interrupción. Solo define un recurso financiero. Un cliente con cargas de trabajo críticas debe preguntar por los objetivos de nivel de servicio, escalación de incidentes, notificación proactiva, ventanas de mantenimiento, obligaciones de exportación de datos y objetivos de recuperación medidos que sean distintos de la política de reembolso.
Esta es la razón por la que el título del artículo apunta a racks, tránsito y ventanas de reparación. Los términos legales de Media Cloud identifican las mismas categorías: equipo, mantenimiento, enlaces de telecomunicaciones, congestión y ataque. Los datos de enrutamiento público muestran entonces dónde aparece una dependencia de tránsito importante. El trabajo del comprador es convertir estas pistas públicas en evidencia contractual y comprobable.
La localización de datos no se resuelve con una marca indonesia
El posicionamiento de Media Cloud es fuertemente indonesio. La página de dominios enfatiza la identidad.id, la página de VPS dice 'VPS Indonesia', el pie de página da una dirección de contacto en el sur de Yakarta, y los registros APNIC/IDNIC colocan el AS y los recursos de dirección en Indonesia. Para muchos clientes, especialmente pequeñas empresas, este puede ser el punto principal: un proveedor local, un idioma local, expectativas de pago locales y soporte al que se puede acceder a través de canales indonesios.
Pero la soberanía y localización de datos exigen más que una etiqueta de país. Un sitio web alojado puede estar en las direcciones de Media Cloud mientras que el correo electrónico se maneja a través de Google o Microsoft. Un ticket de soporte puede contener información personal. Una copia de seguridad puede almacenarse en un sistema diferente al del servidor principal. Un registro de dominio puede involucrar procesos de registrador y registro. Una afirmación de mitigación de DDoS puede depender de filtrado ascendente o de una plataforma de terceros.
Cada capa puede colocar datos, metadatos o derechos de acceso en una ubicación operativa diferente.
Lapolítica de privacidadde la empresa establece que recopila información de contacto, información de facturación, identificadores de cuenta, contenido creado o cargado por el usuario, datos de registro, información del dispositivo y cookies o tecnologías similares. Establece que la información personal puede compartirse con proveedores de servicios, socios externos con fines de marketing o publicidad, como parte de transacciones comerciales, o cuando lo exija la ley. También establece que la información personal puede transferirse y procesarse en países distintos al del usuario, y que ningún método de transmisión por Internet o almacenamiento electrónico es completamente seguro. Este es un lenguaje de privacidad genérico, pero en un contexto de alojamiento es importante: el proveedor reconoce la posibilidad de procesamiento transfronterizo y por terceros.
El contexto legal indonesio también eleva el listón para una gestión clara de los datos. El Reglamento Gubernamental No. 71 de 2019 sobre Sistemas y Transacciones Electrónicas está publicado por JDIH Kemkomdigi enesta página oficial. La página incluye disposiciones sobre registro de operadores de sistemas electrónicos, confiabilidad, seguridad, gestión de riesgos, acuerdos de nivel de servicio y principios de procesamiento de datos personales. La Ley No. 27 de 2022 sobre Protección de Datos Personales está publicada enJDIH Kemkomdigi. Este artículo no afirma que Media Cloud caiga en una categoría regulatoria específica para cada producto, pero el marco nacional explica por qué los clientes deben preguntar dónde residen realmente los datos, las copias de seguridad, los registros, los tickets y el acceso de soporte.
La prueba práctica es simple. Un VPS indonesio debería venir con una respuesta de ubicación: ¿dónde está el host principal, dónde están las copias de seguridad, dónde está la identidad del plano de control, dónde están los registros, y qué servicios de terceros manejan el correo electrónico, DNS, filtrado DDoS, soporte o facturación? Sin esta matriz, 'local' sigue siendo una señal de marketing útil, pero no una garantía completa de soberanía.
La capacidad instalada y la capacidad utilizable son diferentes
La huella de red pública de Media Cloud respalda una narrativa de capacidad instalada modesta pero real. Tiene un AS registrado, un IPv4 /23 enrutado dividido en dos /24, un IPv6 /32, sitios web públicos dentro del mismo bloque IPv4, una lista de intercambio en PeeringDB, una oferta de bucle local y productos VPS/alojamiento/correo electrónico. Esto es más concreto que un revendedor puro sin un borde identificable. Es suficiente para justificar el interés del cliente.
La capacidad utilizable es la pregunta más difícil. Un producto VPS puede anunciar recursos dedicados y almacenamiento NVMe, pero las páginas públicas no revelan cuántos hipervisores existen, cómo se replica el almacenamiento, si las copias de seguridad del cliente están fuera del rack o fuera del sitio, cuántas máquinas de repuesto están en stock, qué fracción de la capacidad está reservada para conmutación por error, o si el panel de control puede funcionar si la red de producción falla.
Un producto de bucle local puede anunciar 1 Gbit/s, 2 Gbit/s o 3 Gbit/s, pero las páginas públicas no revelan rutas de fibra, diversidad de interconexión, diversidad de operadores ni la política de congestión durante una interrupción.
Esta distinción es importante durante una falla. La capacidad instalada es lo que un proveedor vende en un día normal. La capacidad utilizable es lo que queda después de una falla de un servidor, un enrutador, una ruta de fibra, un proveedor ascendente, un puerto de intercambio, una fuente de alimentación, una cola de soporte o una cuenta de facturación. La capacidad recuperable es lo que se puede restaurar dentro de la tolerancia de tiempo de inactividad y pérdida de datos del cliente. Los clientes compran la segunda y tercera categoría, ya sea que la factura las nombre o no.
El patrón ascendente visible de Media Cloud hace que esta distinción sea más urgente. Si la mayoría de las rutas del colector global llegan a AS140449 a través de AS138840, entonces el cliente debe preguntar si AS138840 es una dependencia ascendente única, una ruta de tránsito principal, una ruta de servidor de rutas, o parte de una mezcla de tránsito más amplia que los colectores públicos no exponen completamente. Si la presencia en OpenIXP/NiCE es de 1 Gbit/s, el cliente debe preguntar si se utiliza para peering sin liquidación, accesibilidad del servidor de rutas, respaldo o tráfico crítico del cliente.
Si PeeringDB no enumera registros de instalaciones, el cliente debe preguntar dónde está ubicado el equipo de producción y cómo se gestiona el acceso físico.
Ninguna de estas preguntas implica una falla. Son preguntas normales de diligencia debida de infraestructura. Un proveedor pequeño puede ser excelente si es honesto acerca de sus límites, prueba la recuperación y ofrece a los clientes rutas de salida factibles. Un proveedor grande puede ser frágil si oculta un punto de falla compartido. La evidencia pública de Media Cloud es lo suficientemente sólida para formular las preguntas iniciales, pero no lo suficientemente sólida para cerrarlas.
El soporte y la facturación son parte de la infraestructura
Media Cloud vende sus productos a través de una tienda que requiere inicio de sesión, enlaces de contacto y botones de WhatsApp. El pie de página enumera[email protected]en la tienda y[email protected]en el sitio corporativo, mientras que mci.net.id expone support.mci.net.id en 103.152.240.243. Esto da a los clientes varios puntos de entrada de soporte, pero la pregunta de resiliencia es si esos puntos de entrada son suficientemente independientes durante un incidente.
El soporte es infraestructura porque convierte la detección en reparación. Si un VPS falla, el cliente necesita más que un acuse de recibo genérico. Necesita una persona responsable calificada, un diagnóstico, una ruta de restauración estimada y una forma de recuperar datos si la restauración no cumple con el plazo del cliente. Si un bucle local falla, el cliente debe saber si Media Cloud puede enviar un técnico, si un socio controla la última milla, y si el mismo circuito transporta el portal de soporte.
Si la facturación bloquea una cuenta, el cliente necesita una ruta de escalación que pueda separar el estado comercial del acceso de emergencia a los datos.
Los términos de uso hacen que el estado de la cuenta y el pago sean operativamente relevantes. Los precios pueden cambiar; el impago puede llevar a la suspensión o terminación; los clientes son responsables de mantener la seguridad de la cuenta; Media Cloud puede suspender o terminar el acceso por violaciones. Estas cláusulas son estándar, pero muestran que el plano de control no es puramente técnico. Un dominio, un plan de alojamiento, un buzón o un VPS pueden fallar debido a una condición administrativa tanto como a una condición de hardware.
Los productos de correo electrónico hacen esto aún más visible. Las páginas de correo electrónico describen asistencia para la migración, solución de problemas, webmail, antispam, antivirus, firmas DKIM, copias de seguridad automáticas, funciones de rastreo de correo y registros de auditoría. Si estos son parte del proceso comercial de un cliente, entonces la recuperación debe incluir exportación de buzones, continuidad de DNS, continuidad de DKIM/SPF/DMARC, acceso a archivos y evidencia de soporte. No es suficiente decir 'el correo electrónico está alojado'.
El cliente debe saber qué sucede cuando el producto de correo electrónico o su dependencia de plataforma externa falla.
Para Media Cloud, el comprador debe solicitar un manual de procedimientos de soporte antes de mover cargas de trabajo críticas. ¿Quién recibe llamadas urgentes? ¿Hay una escalación telefónica para una interrupción de bucle local o VPS? ¿El personal de soporte está autorizado para mover cargas de trabajo o solo para crear tickets? ¿Las colas de cuentas, facturación y abuso están separadas de la respuesta a incidentes? ¿Qué tan rápido puede la empresa proporcionar una exportación completa del disco VPS, archivos del sitio web, contenido del buzón, zona DNS y código de autorización del dominio si el cliente decide irse?
El principal riesgo para el cliente es la concentración
La conveniencia de Media Cloud es también su riesgo. Un cliente puede plausiblemente comprar el dominio, el sitio web, el alojamiento, el VPS, el certificado SSL, el correo electrónico profesional y la conectividad dedicada de la misma familia de marcas. Esto puede reducir la gestión de proveedores para una pequeña empresa. También puede convertir un incidente de proveedor en una falla compuesta: la renovación del DNS, la emisión del certificado, el alojamiento web, la accesibilidad del VPS, el acceso al correo electrónico y la conectividad local pueden requerir el mismo equipo de soporte o la misma relación de cuenta.
La versión de infraestructura de la concentración es similar. Si el borde visible depende en gran medida de AS138840, si la superficie de intercambio es una única lista de OpenIXP/NiCE, si la producción está en una instalación no revelada, y si la ruta de soporte está vinculada a la misma red, entonces un solo problema operativo puede afectar múltiples capas. La evidencia pública no prueba que todos estos puntos únicos existan, pero tampoco los refuta. Los registros visibles son suficientes para exigir una respuesta.
Los clientes deben probar la concentración de cuatro maneras. Primero, separe la identidad y el DNS del alojamiento. ¿Se puede transferir el dominio rápidamente? ¿Se pueden exportar los registros DNS? ¿Son accesibles los registros de zona durante una interrupción del alojamiento? Segundo, separe el cómputo de la copia de seguridad de almacenamiento. ¿Puede el cliente recuperar un VPS o un sitio web en otro proveedor sin esperar a que Media Cloud reconstruya el host original? Tercero, separe la conectividad del alojamiento de aplicaciones.
Si el bucle local falla, ¿puede el cliente acceder al servicio alojado a través de otro proveedor de acceso? Cuarto, separe el soporte de la plataforma afectada. Si el portal de servicio está caído, ¿hay un canal de escalación independiente?
El umbral de reembolso del bucle local debería centrar la atención. Un servicio inactivo durante más de siete días continuos está muy por encima de la tolerancia de muchas cargas de trabajo comerciales. Un cliente que no puede operar durante una semana no debe confiar en la política de reembolso como plan de continuidad. Deben exigir conmutación por error, copias de seguridad probadas, acceso alternativo y términos de escalación por escrito antes de comprar.
Esta es la conclusión más práctica del expediente público. Media Cloud parece un proveedor operativo genuino con una red identificable. Vale la pena evaluarlo. La misma evidencia muestra por qué la evaluación debe ir más allá de la página de producto: un cliente necesita evidencia de diversidad, restauración y salida.
Lo que un comprador serio debería preguntar a continuación
Un comprador serio debería comenzar en el borde de enrutamiento. Pregunte a Media Cloud qué servicios utilizan AS140449, qué prefijos están asignados a los pools de VPS o alojamiento de clientes, y si algún servicio de cliente está detrás de otros proveedores. Pregunte si se publicarán ROA para 103.152.240.0/24, 103.152.241.0/24 y 2406:38c0::/32, y quién mantiene los objetos de ruta IRR.
Pregunte si AS138840 es el tránsito principal, un tránsito de respaldo, una adyacencia de servidor de rutas u otra relación, y si hay una segunda ruta de tránsito independiente con suficiente capacidad pagada para transportar el tráfico del cliente durante una falla.
A continuación, pregunte por el modelo de instalaciones. ¿Qué centro(s) de datos alojan los productos VPS y de alojamiento? ¿Los racks son propios, alquilados o subarrendados? ¿Hay fuentes de alimentación separadas, enrutadores separados, cortafuegos separados y entradas de fibra separadas? ¿Se utiliza OpenIXP/NiCE para tráfico crítico del cliente, y el puerto de intercambio de 1 Gbit/s tiene monitoreo de congestión?
Si PeeringDB no enumera instalaciones, ¿es porque la empresa elige no revelarlo, porque la red es proporcionada a través de un socio, o porque las cargas de trabajo del cliente no están colocadas en una instalación de interconexión pública?
Tercero, pregunte por las pruebas de recuperación. ¿Cuándo fue la última restauración de disco VPS? ¿Cuánto tiempo tomó? ¿Se restauró en el mismo host, en otro host en la misma instalación, o en una ubicación diferente? ¿Cómo se almacenan las copias de seguridad de alojamiento WordPress y Sitejet? ¿Puede un cliente probar una exportación sin cancelar el servicio? ¿El correo electrónico se respalda de manera que el cliente pueda recuperarlo? ¿Las claves DKIM, las zonas DNS, los certificados y los archivos de buzón están incluidos en un paquete de salida?
Cuarto, pregunte por los límites de soporte. ¿Cuál es la ruta de incidentes mayores para los servicios de VPS, alojamiento, dominio, correo electrónico, SSL y bucle local? ¿Qué método de contacto permanece disponible si mci.net.id o mediacloud.id no son accesibles? ¿El soporte de WhatsApp crea un ticket formal? ¿Hay tiempos de respuesta y restauración definidos? ¿Qué eventos generan notificaciones al cliente antes de que comience el mantenimiento?
Finalmente, pregunte cómo se corresponden las declaraciones legales y de privacidad con la colocación real de datos. La política de privacidad permite el procesamiento transfronterizo, y la evidencia DNS/MX muestra dependencia de plataformas globales para partes del negocio. El cliente debe preguntar dónde se procesan los datos personales, registros, copias de seguridad, tickets y registros de facturación, y si algún producto puede mantenerse contractualmente dentro de Indonesia.
Estas preguntas no son hostiles. Son la forma en que un comprador convierte la red pública visible de Media Cloud en una dependencia probada. La empresa tiene suficiente evidencia pública para justificar la conversación. Todavía no tiene suficiente evidencia pública para permitir que los clientes se la salten.
El nivel de evidencia
PT Media Cloud Indonesia obtiene un nivel de evidencia pública Medio. El nivel no es una puntuación de calidad para la empresa; es una puntuación de lo que la evidencia pública puede respaldar. En el lado positivo, la identidad y la superficie operativa son inusualmente concretas para un proveedor de alojamiento regional. APNIC/IDNIC vincula la empresa con AS140449, 103.152.240.0/23 y 2406:38c0::/32. RIPEstat vio tres prefijos activos anunciados en julio de 2026. Los sitios web públicos se resuelven dentro del bloque IPv4 de la empresa.
Media Cloud anuncia un conjunto específico de productos: dominios, alojamiento, VPS, SSL, correo electrónico, servicios web y conectividad de bucle local. PeeringDB enumera la red y una conexión OpenIXP/NiCE.
La rebaja se refiere a la evidencia de resiliencia. La evidencia pública no nombra una instalación de producción. PeeringDB no enumera entradas de instalaciones. La validación de origen de ruta devolvió 'desconocido' para los prefijos verificados. Las rutas BGP visibles están fuertemente asociadas con AS138840, y el objeto de ruta IPv6 describe una ruta de cliente HSP Global registrada por proxy. Los propios términos de Media Cloud establecen que los servicios pueden interrumpirse por mal funcionamiento del equipo, mantenimiento, reparación, falla del enlace de telecomunicaciones, ataques hostiles, congestión y otras causas.
La política de reembolso sugiere que algunos remedios de servicios de Internet se enmarcan en torno a una interrupción prolongada continua en lugar de un tiempo de inactividad operativo corto.
Esta combinación respalda una conclusión clara: Media Cloud es un proveedor genuino de servicios alojados y de conectividad en Indonesia con una red visible, pero los clientes no deben tratar la red visible como prueba de resiliencia en la nube multisitio. La ruta de diligencia debida apropiada es verificar la ubicación de las instalaciones, la diversidad de tránsito, los controles de origen de ruta, las pruebas de copia de seguridad y restauración, la escalación de soporte, las reglas de continuidad de facturación y los derechos de exportación de datos.
Si estas verificaciones son satisfactorias, la evidencia pública da a los clientes algo sólido para monitorear. Si estas verificaciones están ausentes, la conveniencia de un proveedor local empaquetado puede convertirse en una dependencia concentrada.