PT Media Cloud Indonesia vende una capacidad alojada que aún depende de los bastidores, del tránsito y de las ventanas de reparación

Resumen

• PT Media Cloud Indonesia dispone de pruebas de funcionamiento público más sólidas que muchos pequeños proveedores de alojamiento: 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 paquete amplio 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 planes de ancho de banda dedicado de 1 Gbit/s, 2 Gbit/s y 3 Gbit/s.
• La reserva sobre la resiliencia es igualmente concreta. PeeringDB enumera una conexión de intercambio OpenIXP/NiCE y ningún registro de instalación para la red; los datos de vecinos 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 una prueba de capacidad multisitio independiente.
• Los propios términos de servicio y la política de reembolso de Media Cloud hacen visible el camino de fallo físico: los servicios pueden dejar de estar accesibles por mal funcionamiento del equipo, mantenimiento, reparación o sustitución, interrupción de enlaces de telecomunicaciones, ataques hostiles, congestión u otros fallos; el reembolso de los servicios de Internet está condicionado a más de siete días continuos de corte o imposibilidad de continuar el servicio.
• El nivel de evidencia es Medio. La identidad, la superficie de producto, el espacio de direccionamiento enrutado y la accesibilidad actual están bien respaldados; las pruebas públicas sobre la ubicación de las instalaciones, la capacidad de reserva, la diversidad de tránsito, la restauración probada y los límites de portabilidad de datos siguen siendo incompletas.

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 proveedor de alojamiento". La empresa presenta dos superficies públicas vinculadas. Una es el sitio institucional orientado a la conectividad enmci.net.id, que promociona soluciones de conectividad 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 destinada a los clientes para dominios, alojamiento, VPS, certificados SSL, correo electrónico y servicios web. Estas dos superficies no son simples anécdotas de marca. Muestran que la empresa pide a sus clientes que le confíen tanto su presencia básica en Internet como servicios estructurantes de infraestructura.

Esta confianza se enfrenta a limitaciones muy reales. Un VPS es una máquina virtual, pero se ejecuta sobre computación, almacenamiento, energía y refrigeración físicos. El "ancho de banda ilimitado" es una expresión comercial, pero los paquetes siempre atraviesan puertos, enrutadores, filtros, fibras ópticas, contratos de tránsito y tejidos de intercambio. Una promesa de "soporte 24/7" solo es útil si el cliente puede contactar con el equipo incluso cuando el servicio afectado, el sistema de tickets, el DNS o el estado de facturación fallan.

La oferta de bucle local es aún más directa: depende del acceso de última milla, de un punto de conexión, de un camino ascendente, de técnicos de guardia y de una política comercial sobre lo que sucede cuando el circuito permanece caído.

Las pruebas públicas comienzan con la capa de recursos de numeración. 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 Yakarta Meridional. 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 de numeración de Internet directamente visibles.

La empresa también aloja sus sitios públicos dentro de esta huella. Una verificación 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 mundial sin vínculo aparente con el registro de red. La marca, el ASN y el espacio de direccionamiento enrutado están suficientemente alineados para hacer verificable la afirmación de infraestructura.

La parte difícil no es probar que Media Cloud tiene presencia pública. La parte difícil es determinar el nivel de resiliencia para el cliente que esa presencia implica. Las pruebas de enrutamiento público pueden indicar qué prefijos son visibles, qué ASN son adyacentes a la red, si los datos de origen de ruta están cubiertos y si un directorio de intercambio voluntario enumera un puerto. No pueden mostrar el servidor de repuesto en el bastidor, el acuerdo de instalación, el proceso de copia de seguridad de los clientes o la persona autorizada para reemplazar el hardware después de la medianoche. Esta brecha es el núcleo del artículo.

La oferta 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 construir una presencia web. Latienda Media Cloudindica que proporciona dominios, alojamiento, un constructor de sitios, correo electrónico, certificados SSL y servicios VPS. Promociona dominios.id y.com, servicios de revendedor y grandes volúmenes, y un mosaico "Mejor alojamiento VPS Cloud" 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, constructor de sitios 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 declaración más clara de capacidad alojada. Comercializa "VPS Indonesia", describe el servicio como "VPS Indonesia rápido y estable a precios asequibles", y enumera recursos 100% dedicados, 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 red pequeña en una dependencia comercial: los clientes no solo compran espacio de direccionamiento; esperan computación, almacenamiento, instalación de software, controles de seguridad y margen de red suficiente para mantener las aplicaciones accesibles.

Las páginas de alojamiento añaden otra capa.Alojamiento Sitejetpresenta un alojamiento empaquetado con un constructor de sitios y destaca la protección DDoS, cPanel, Softaculous e instalaciones en un clic.Alojamiento WordPressutiliza el mismo lenguaje de fiabilidad 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 las suposiciones de plataforma que subyacen a la experiencia del cliente. cPanel, Softaculous, los constructores de sitios y el alojamiento WordPress dependen todos de paneles de control, estados de licencia, prácticas de almacenamiento y copias de seguridad. Son sistemas operativos, no simples nombres de productos estáticos.

El correo electrónico amplía aún más la dependencia.Alojamiento de correoanuncia correo profesional con una garantía de disponibilidad del 99,9%, dominios personalizados, seguridad, supervisión, soporte 24/7 y asistencia para configuración, migración y solución de problemas.Correo profesionaldescribe 8 GB por buzón, webmail, antispam, antivirus, firmas DKIM, copias de seguridad automáticas, funciones de seguimiento de correo y registros de auditoría. Los registros MX añaden un matiz: mci.net.id utiliza la protección de correo de Microsoft, mientras que mediacloud.id apunta a los intercambiadores de correo aspmx de Google. Esto no es contradictorio; muestra que algunas partes de la empresa dependen de plataformas de correo externas, incluso cuando los sitios web públicos residen en el espacio de direcciones propio de Media Cloud.

Lapágina SSLy las páginas de dominios completan el panorama. Media Cloud vende capas de confianza además de los servidores: registro de dominios, transferencia, identidad.id, certificados, creación de sitios e identidad de buzón de correo. Un cliente que concentra estos servicios puede ganar en comodidad, 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, múltiples funciones empresariales independientes pueden bloquearse simultáneamente.

La tarificación del bucle local hace explícita la cuestión de los bastidores 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 "un ancho de banda dedicado de alta velocidad para comunicaciones empresariales fiables". La página enumera planes de bucle local a 10.000.000 Rp al mes por 1 Gbit/s, 20.000.000 Rp al mes por 2 Gbit/s y 30.000.000 Rp al mes por 3 Gbit/s, con enlaces "Solicitar presupuesto". 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 la instalación. Sin embargo, trasladan el análisis de un simple alojamiento web a la infraestructura física. Un servicio de bucle local requiere una ruta de acceso al cliente, un punto de conexión, una ruta de agregación, un enrutador, un modelo de soporte y un proceso de reparación. La ruta de fallo ya no es simplemente "el VPS está caído".

Puede ser un problema de fibra en la última milla, un problema de proveedor ascendente, un problema del enrutador de acceso, un problema de interconexión del centro de datos, un problema de envío de soporte, un bloqueo de facturación o un problema del equipo del cliente que el proveedor puede controlar o no.

La historia de las direcciones públicas también debe tratarse con precaución. Los registros de recursos de numeración de APNIC/IDNIC dan una dirección en el Prudential Center en Yakarta Meridional. Los pies de página públicos actuales de Media Cloud dirigen a los lectores a Epicentrum Walk Piso 3 Unidad A306-307, Jl. HR Rasuna Said, Kuningan, Yakarta Meridional. 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 las cargas de trabajo o los enrutadores de los clientes.

La distinción es importante porque los clientes a menudo confunden una dirección de contacto comercial con una dirección de instalación. No deberían.

La página del bucle local no nombra el centro de datos, el edificio de intercambio, la ruta de fibra, los proveedores de tránsito ascendentes, la frontera del servicio o el sitio de recuperación. Esto es normal para una página comercial 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 fallo difiere de un bucle que termina en un hotel de telecomunicaciones separado. Si el bucle es proporcionado por un socio, la ruta de reembolso y escalado puede depender de la cola de tickets del socio.

Si el cliente necesita diversidad de enrutamiento, debe saber si los dos circuitos comparten conductos, entradas de edificios, paneles de parcheo o una única puerta de enlace ascendente.

No se trata de decir que la oferta de bucle local de Media Cloud es débil. Se trata de señalar que hace inevitable la dependencia física. La capacidad alojada parece elástica hasta que falla la última milla o la ruta ascendente. Un cliente que compra nube y conectividad local del mismo proveedor debería preguntarse si esta agrupación aumenta el control o simplemente concentra el fallo.

AS140449 anuncia actualmente un pequeño conjunto de prefijos coherente

Las pruebas de enrutamiento son más claras que las del sitio institucional. Lavisión general de AS140449 de RIPEstatidentificó al titular como "MEDIACLOUD-AS-ID - PT Media Cloud Indonesia" y mostró que el AS se anunciaba durante la verificación de julio de 2026. Lavista de prefijos anunciadosde RIPEstat enumeraba 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. Esto significa que el /23 registrado se divide operativamente en dos anuncios IPv4 /24 visibles, mientras que la asignación IPv6 se anuncia como /32.

Esta configuración es coherente con un operador pequeño más que con una nube a gran escala. 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 huella masiva de nube al por menor. 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 computación instalada. La cuestión de la capacidad utilizable no es cuántas direcciones existen, sino cuántas cargas de trabajo pueden ser alojadas, movidas, restauradas y soportadas cuando algo falla.

Elhistorial de enrutamientode RIPEstat añade continuidad. Los dos /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 seguían siendo 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 inactivo recién creado. Sugiere una superficie de enrutamiento público que ha persistido durante años.

Pero el historial también incluye períodos de menor visibilidad. Los colectores de rutas públicos pueden mostrar que la visibilidad cambió; no pueden explicar por qué. Una caída puede reflejar una política de enrutamiento, cobertura del colector, un problema ascendente, un período de mantenimiento, filtrado de rutas, efectos de RPKI o IRR en otros lugares, o una verdadera interrupción del servicio. Sería irresponsable convertir el historial en una afirmación de fallo específico sin pruebas del operador o del cliente.

Su valor es más limitado: muestra que el borde de ruta público es lo suficientemente observable para ser monitorizado y que los clientes pueden preguntar qué cambió cuando la visibilidad cambió.

El estado BGP actual también es instructivo. Larespuesta de estado BGPde RIPEstat mostró numerosas rutas desde colectores mundiales hacia los prefijos de Media Cloud, la mayoría de las rutas alcanzando AS140449 a través de AS138840. Otras rutas en la muestra incluían grandes nombres de tránsito mundiales 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 visible ascendente apunta a HSPnet y OpenIXP/NiCE

Lavista de vecinos ASNde RIPEstat registró tres ASN adyacentes durante la verificación del 11/07/2026: AS138840 como vecino izquierdo dominante, AS7717 como otro vecino izquierdo y AS149004 como 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 la existencia de contratos, pero ayudan a explicar la vecindad 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 info "Enterprise", soporte IPv6, una política general abierta, un contador IX de 1 y un contador de instalaciones de 0. Laconsulta netixlanasociada enumera 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. Laconsulta netfacno devuelve ninguna entrada 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 una vecindad 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 los operadores y es voluntario. Un puerto de intercambio de 1 Gbit/s no prueba que todo el tráfico de clientes pueda fluir a través del intercambio en caso de problemas de tránsito.

Un contador de instalaciones de 0 no prueba que la empresa no tenga bastidores; simplemente significa que PeeringDB no enumera entradas de instalación para la red. Una adyacencia ascendente observada no prueba si un enlace es de tránsito, peering, copia de seguridad o ruta de servidor de rutas, a menos que esté respaldado por la documentación del operador.

Los objetos de ruta 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 usaba origen AS140449, pero las observaciones describían un objeto de ruta registrado por proxy para una ruta de cliente HSP Global exportada bajo el AS de origen Media Cloud, mantenido por MAINT-AS138840.

Esta redacción sitúa la cuestión del acuerdo con el proveedor en el centro: si la ruta IPv6 depende del mantenimiento del objeto de ruta por parte de HSP o del acuerdo ascendente, los clientes deben saber quién puede corregir el objeto, quién puede cambiar los filtros y qué sucede si falla el acuerdo 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 de resiliencia completa, pero es una comprobación significativa. Verifica si una autorización de origen de ruta (ROA) publicada respalda un prefijo y AS de origen dados. Durante las comprobaciones de RIPEstat de julio de 2026,103.152.240.0/24,103.152.241.0/24y2406:38c0::/32devolvieron "unknown" (desconocido) sin ROA validante en la vista comprobada. RADB también mostró un estado de validación de origen RPKI como "not_found" (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 comprobados no encontraron un 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 válidas, o que un futuro secuestro de ruta o mala configuración sea más difícil de distinguir mediante políticas automatizadas.

Para los clientes, esta no es la única cuestión de seguridad, pero es una buena pregunta de aprovisionamiento: ¿Tiene Media Cloud la intención de publicar ROA para sus prefijos anunciados, y puede demostrar que los objetos de ruta y los 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 reemplazar el hardware rápidamente. Solo reduce una categoría de riesgo de enrutamiento. En este caso, la ausencia de ROA validantes hace que el plano de control público sea menos completo que el catálogo de productos. Esta brecha es corregible, pero debe ser reconocida.

La lección más amplia para los clientes es que la resiliencia de la capacidad alojada tiene múltiples 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. La instalación, la energía, las piezas de repuesto y el soporte influyen en la reparación. Las copias de seguridad y las rutas de exportación influyen en la recuperación.

Las pruebas públicas de Media Cloud son más sólidas en el centro de esta cadena y más débiles en los extremos: la visibilidad de las rutas es clara; la portabilidad de datos y la restauración probada no son públicas.

Las propias condiciones de Media Cloud describen la ruta de fallo

Las páginas legales de la empresa no son esquemas técnicos pulidos, pero son reveladoras desde el punto de vista operativo. Lostérminos de servicio de mediacloud.iddefinen los servicios de manera amplia para incluir el registro de nombres de dominio, el alojamiento, los servicios de creación de sitios web y los servicios de Internet. Los términos establecen que el alojamiento almacena y sirve el contenido de los sitios web, y que los servicios de Internet pueden incluir televisión, correo electrónico, conectividad y servicios relacionados. También especifican que Media Cloud realizará esfuerzos comercialmente razonables para proporcionar el sitio y los servicios 24 horas al día, siete días a la semana.

La misma sección sobre la disponibilidad es más importante que la frase sobre la disponibilidad. Indica que los servicios pueden ser inaccesibles o inoperativos por razones como mal funcionamiento del equipo, mantenimiento periódico, reparaciones o sustituciones, causas fuera de un control razonable, interrupción o fallo de los enlaces de telecomunicación o transmisión digital, ataques hostiles a la red, congestión de la red y otros fallos. También indica que Media Cloud no tiene control sobre la disponibilidad de forma continua o ininterrumpida. Esta redacción no es inusual; muchos proveedores utilizan cláusulas de exención similares.

Sin embargo, aquí ofrece a los clientes una lista concisa de las categorías de dependencia exactas que deberían probar.

Lapolítica de reembolsoes igualmente específica. Indica que las tarifas de registro de dominios generalmente no son reembolsables una vez registrados o renovados; los servicios de alojamiento y creación de sitios web no se reembolsan una vez adquiridos; y los servicios de Internet de banda ancha o dedicados pueden ser elegibles para reembolso si el servicio está caído durante más de siete días multiplicados por 24 horas de forma continua, o si Media Cloud no puede continuar proporcionando el servicio debido a dificultades técnicas o a la prohibición del jefe de barrio local. Este es un umbral operativo llamativo. Sugiere que para la conectividad a Internet, el desencadenante de 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 corte continuo no restaura una aplicación, no migra un buzón de correo, no recupera una base de datos y no mantiene un escaparate en línea durante la interrupción. Solo define un recurso comercial. Un cliente con cargas de trabajo críticas debería solicitar objetivos de nivel de servicio, escalado 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.

Por eso el título del artículo apunta a los bastidores, el tránsito y las 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úblicos muestran luego dónde aparece una dependencia de tránsito importante. El trabajo del comprador es convertir estos indicios públicos en pruebas contractuales y de testeo.

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 VPS dice "VPS Indonesia", el pie de página da una dirección de contacto en Yakarta Meridional, y los registros APNIC/IDNIC sitúan el AS y los recursos de direcciones en Indonesia. Para muchos clientes, especialmente las pequeñas empresas, esto puede ser lo esencial: un proveedor local, un idioma local, expectativas de pago locales y un soporte al que se puede contactar a través de canales indonesios.

Pero la soberanía y localización de datos exigen algo más que una etiqueta de país. Un sitio web alojado puede residir en las direcciones de Media Cloud mientras el correo electrónico se gestiona 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 servidor principal. Un registro de dominio puede implicar procesos de registrador y registro. Una afirmación de mitigación DDoS puede depender de un filtrado ascendente o de una plataforma de terceros.

Cada capa puede situar los datos, los metadatos o los derechos de acceso en una ubicación operativa diferente.

Lapolítica de privacidadde la empresa indica que recopila información de contacto, información de facturación, credenciales de cuenta, contenido creado o cargado por el usuario, datos de registro, información del dispositivo y cookies o tecnologías similares. Indica que la información personal puede compartirse con proveedores de servicios, socios externos con fines de marketing o publicidad, en el marco de transacciones comerciales, o cuando lo exija la ley. También indica que la información personal puede transferirse y tratarse 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, importa: el proveedor reconoce las posibilidades de tratamiento transfronterizo y por parte de terceros.

El contexto jurídico indonesio también eleva el listón para una gestión clara de los datos. El reglamento gubernamental n.º 71 de 2019 sobre sistemas y transacciones electrónicas se publica en JDIH Kemkomdigi enesta página oficial. La página incluye disposiciones sobre el registro de operadores de sistemas electrónicos, fiabilidad, seguridad, gestión de riesgos, acuerdos de nivel de servicio y principios de tratamiento de datos personales. La ley n.º 27 de 2022 sobre protección de datos personales se publica enJDIH Kemkomdigi. Este artículo no afirma que Media Cloud entre en una categoría regulatoria específica para cada producto, pero el marco nacional explica por qué los clientes deberían preguntar dónde residen realmente los datos, las copias de seguridad, los registros, los tickets y el acceso al soporte.

La prueba práctica es sencilla. Un VPS indonesio debería ir acompañado de una respuesta sobre la 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 externos gestionan el correo, el DNS, el filtrado DDoS, el soporte o la facturación? Sin esta matriz, "local" sigue siendo una señal de marketing útil pero no una garantía de soberanía completa.

Capacidad instalada y 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 /23 IPv4 enrutado dividido en dos /24, un /32 IPv6, sitios web públicos dentro del mismo bloque IPv4, una lista de intercambio PeeringDB, una oferta de bucle local y productos de VPS/alojamiento/correo. Esto es más concreto que un mero revendedor sin borde identificable. Es suficiente para justificar el interés de los clientes.

La capacidad utilizable es la cuestión 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 de los clientes están fuera del bastidor o fuera del sitio, cuántas máquinas de repuesto hay almacenadas, 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 las rutas de fibra, la diversidad de interconexión, la diversidad de operadores o la política de congestión durante una interrupción.

Esta distinción es importante durante un fallo. La capacidad instalada es lo que un proveedor vende en un día normal. La capacidad utilizable es lo que queda después de que falle 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 puede restaurarse dentro de la tolerancia del cliente en cuanto a tiempo de inactividad y pérdida de datos. Los clientes compran las categorías segunda y tercera, tanto si la factura las menciona como si no.

El esquema ascendente visible de Media Cloud hace más urgente esta distinción. Si la mayoría de las rutas de los colectores mundiales alcanzan 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 OpenIXP/NiCE es de 1 Gbit/s, el cliente debe preguntar si se utiliza para peering sin acuerdo de pago, para accesibilidad del servidor de rutas, para copia de seguridad o para tráfico crítico de clientes.

Si PeeringDB no enumera ningún registro de instalación, el cliente debe preguntar dónde está el equipo de producción y cómo se gestiona el acceso físico.

Ninguna de estas preguntas implica una falta. Son preguntas normales de diligencia de infraestructura. Un proveedor pequeño puede ser excelente si es honesto sobre sus limitaciones, prueba la recuperación y da a los clientes rutas de salida viables. Un proveedor grande puede ser frágil si oculta un punto único de fallo. Las pruebas públicas para Media Cloud son lo suficientemente sólidas como para plantear las primeras preguntas, pero no lo suficiente para cerrarlas.

El soporte y la facturación forman 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 institucional, mientras que mci.net.id expone support.mci.net.id en 103.152.240.243. Esto da a los clientes múltiples puntos de entrada de soporte, pero la cuestión de resiliencia es si estos puntos de entrada son suficientemente independientes durante un incidente.

El soporte es infraestructura porque convierte la detección en reparación. Si un VPS se cae, el cliente necesita algo más que un acuse de recibo genérico. Necesita un responsable cualificado, un diagnóstico, una ruta de restauración estimada y una forma de recuperar los datos si la restauración no cumple el plazo del cliente. Si un bucle local falla, el cliente debe saber si Media Cloud puede intervenir, 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 escalado que pueda separar el estado comercial del acceso de emergencia a los datos.

Los términos de servicio hacen que el estado de la cuenta y del pago sea operativamente relevante. Los precios pueden cambiar; el impago puede dar lugar a suspensión o rescisión; los clientes son responsables de mantener la seguridad de la cuenta; Media Cloud puede suspender o rescindir el acceso en caso de violación. 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 de correo o un VPS puede 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 describen ayuda para la migración, solución de problemas, webmail, antispam, antivirus, firmas DKIM, copias de seguridad automáticas, funciones de seguimiento de correo y registros de auditoría. Si estos forman parte del proceso de negocio de un cliente, entonces la recuperación debe incluir la exportación de buzones, la continuidad DNS, la continuidad DKIM/SPF/DMARC, el acceso a archivos y las pruebas de soporte. No basta con decir que "el correo está alojado".

El cliente debe saber qué sucede cuando el producto de correo o su dependencia de una plataforma externa falla.

Para Media Cloud, el comprador debería solicitar un manual de procedimientos de soporte antes de mover cargas de trabajo críticas. ¿Quién recibe las llamadas urgentes? ¿Existe un escalado telefónico en caso de fallo del bucle local o del VPS? ¿Está el personal de soporte autorizado para mover cargas de trabajo o solo para crear tickets? ¿Están las colas de cuenta, facturación y abusos separadas de la respuesta a incidentes?

¿Con qué rapidez puede la empresa proporcionar una exportación completa del disco de un VPS, los archivos de un sitio web, el contenido de un buzón de correo, la zona DNS y el código de autorización del dominio si el cliente decide irse?

El principal riesgo para el cliente es la concentración

La comodidad de Media Cloud es también su riesgo. Un cliente puede, de manera plausible, 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 del proveedor en una interrupción 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 necesitar 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 sola lista 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 a múltiples capas. Las pruebas públicas no prueban que todos estos puntos únicos existan, pero tampoco los refutan. Los registros visibles son suficientes para exigir una respuesta.

Los clientes deberían probar la concentración de cuatro maneras. En primer lugar, separar 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? En segundo lugar, separar la computación de la copia de seguridad del almacenamiento. ¿Puede el cliente recuperar un VPS o un sitio web en otro proveedor sin esperar a que Media Cloud reconstruya el host original? En tercer lugar, separar 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? En cuarto lugar, separar el soporte de la plataforma afectada. Si el portal de servicios está caído, ¿existe un canal de escalado independiente?

El umbral de reembolso del bucle local debería centrar la atención. Un servicio caído durante más de siete días continuos está mucho más allá de la tolerancia de muchas cargas de trabajo empresariales. Un cliente que no puede funcionar durante una semana no debería confiar en la política de reembolso como plan de continuidad. Debería exigir conmutación por error, copias de seguridad probadas, acceso alternativo y condiciones de escalado por escrito antes de comprar.

Esta es la conclusión más práctica del expediente público. Media Cloud parece un proveedor operativo real con una red identificable. Vale la pena evaluarlo. Las mismas pruebas muestran por qué la evaluación debe ir más allá de la página del producto: un cliente necesita pruebas de diversidad, restauración y salida.

Lo que un comprador serio debería preguntar a continuación

Un comprador serio debería empezar por el borde de enrutamiento. Pregunte a Media Cloud qué servicios utilizan AS140449, qué prefijos se asignan 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 reserva, una adyacencia de servidor de rutas u otra relación, y si existe una segunda ruta de tránsito independiente con capacidad de pago suficiente para enrutar el tráfico de clientes en caso de fallo.

A continuación, pregunte sobre el modelo de instalación. ¿Qué centro(s) de datos aloja(n) los productos VPS y de alojamiento? ¿Los bastidores son propios, alquilados o revendidos? ¿Hay fuentes de alimentación separadas, enrutadores separados, cortafuegos separados y entradas de fibra separadas? ¿Se utiliza OpenIXP/NiCE para el tráfico crítico de clientes, y tiene el puerto de intercambio de 1 Gbit/s supervisión de congestión?

Si PeeringDB no enumera ninguna instalación, ¿es porque la empresa decide no revelarla, porque la red se proporciona a través de un socio, o porque las cargas de trabajo de los clientes no se colocan en una instalación de interconexión pública?

En tercer lugar, pregunte sobre las pruebas de recuperación. ¿Cuándo fue la última restauración de un disco VPS? ¿Cuánto tiempo llevó? ¿Se restauró en el mismo host, en otro host en la misma instalación o en otra ubicación? ¿Cómo se almacenan las copias de seguridad de los alojamientos WordPress y Sitejet? ¿Puede un cliente probar una exportación sin cancelar el servicio? ¿Se realiza una copia de seguridad del correo electrónico de manera que el cliente pueda recuperarlo? ¿Se incluyen las claves DKIM, las zonas DNS, los certificados y los archivos de buzones en un paquete de salida?

En cuarto lugar, pregunte sobre los límites del soporte. ¿Cuál es la ruta de incidente mayor para los servicios 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 por WhatsApp crea un ticket formal? ¿Existen tiempos de respuesta y restauración definidos? ¿Qué eventos generan notificaciones a los clientes antes del inicio del mantenimiento?

Por último, pregunte cómo se corresponden las declaraciones legales y de privacidad con la ubicación real de los datos. La política de privacidad permite el tratamiento transfronterizo, y las pruebas DNS/MX muestran dependencia de plataformas globales para algunas partes del negocio. El cliente debería preguntar dónde se tratan los datos personales, los registros, las copias de seguridad, los tickets y los registros de facturación, y si algún producto puede mantenerse dentro de Indonesia por contrato.

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 suficientes pruebas públicas para justificar la conversación. Todavía no tiene suficientes pruebas públicas para permitir a los clientes evitarla.

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 las pruebas públicas pueden respaldar. En el lado positivo, la identidad y la superficie de operación son inusualmente concretas para un proveedor de alojamiento regional. APNIC/IDNIC vincula a 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 degradación se refiere a las pruebas de resiliencia. Las pruebas públicas no nombran ninguna instalación de producción. PeeringDB no enumera ninguna entrada de instalación. La validación de origen de ruta devolvió "desconocido" para los prefijos comprobados. Las rutas BGP visibles están fuertemente asociadas a AS138840, y el objeto de ruta IPv6 describe una ruta de cliente HSP Global registrada por proxy. Las propias condiciones de Media Cloud indican que los servicios pueden interrumpirse por mal funcionamiento del equipo, mantenimiento, reparación, fallo de enlaces de telecomunicaciones, ataques hostiles, congestión y otras causas.

La política de reembolso sugiere que algunos recursos para los servicios de Internet se formulan en torno a un corte continuo prolongado en lugar de un breve tiempo de inactividad operativa.

Esta combinación respalda una conclusión clara: Media Cloud es un verdadero proveedor indonesio de servicios alojados y conectividad con una red visible, pero los clientes no deberían tratar la red visible como una prueba de resiliencia de nube multisitio. La vía de diligencia adecuada consiste en 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, el escalado del soporte, las reglas de continuidad de facturación y los derechos de exportación de datos.

Si estas verificaciones son satisfactorias, las pruebas públicas dan a los clientes algo sólido que monitorizar. Si estas verificaciones están ausentes, la comodidad de un proveedor local empaquetado puede convertirse en una dependencia concentrada.