PT Media Cloud Indonesia vende capacidade hospedada que ainda depende de racks, trânsito e janelas de reparo

Resumo

• A PT Media Cloud Indonesia possui evidências públicas de operação mais sólidas do que muitos pequenos hospedeiros: os registros APNIC/IDNIC a vinculam ao AS140449, 103.152.240.0/23 e 2406:38c0::/32, enquanto o RIPEstat observou 103.152.240.0/24, 103.152.241.0/24 e 2406:38c0::/32 anunciados pelo AS140449 durante a janela de verificação de julho de 2026.
• A empresa comercializa um amplo conjunto sob a marca Media Cloud: domínios, hospedagem WordPress e Sitejet, VPS Indonésio, SSL, e-mail profissional, serviços web, promoção de hospedagem de jogos e uma oferta de loop local em mci.net.id que apresenta planos de banda larga dedicada de 1 Gbit/s, 2 Gbit/s e 3 Gbit/s.
• A preocupação com a resiliência é igualmente concreta. O PeeringDB lista um ponto de troca no OpenIXP/NiCE e zero instalações para a rede; os dados de vizinhança do RIPEstat são dominados pelo AS138840, e o objeto de rota IPv6 do RADB descreve uma rota de cliente HSP Global registrada por procuração. Estas são evidências de interconexão visíveis, não uma prova de capacidade multissite independente.
• Os termos de uso e a política de reembolso da Media Cloud tornam visível o caminho da falha física: os serviços podem ficar inacessíveis devido a mau funcionamento de equipamento, manutenção, reparo ou substituição, interrupção de link de telecomunicações, ataques hostis, congestionamento ou outras falhas; o reembolso dos serviços de internet está condicionado a mais de sete dias consecutivos de interrupção ou à impossibilidade de continuar o serviço.
• O nível de evidência é Médio. A identidade, a superfície do produto, o espaço de endereçamento roteado e a acessibilidade atual são bem fundamentados; as evidências públicas sobre localização das instalações, capacidade de reserva, diversidade de trânsito, recuperação testada e limites de portabilidade de dados permanecem incompletas.

A empresa é visível, mas a dependência permanece física

PT Media Cloud Indonesia merece uma leitura mais atenta do que um simples rótulo de "pequeno hospedeiro". A empresa apresenta duas superfícies públicas relacionadas. Uma é o site orientado a conectividade emmci.net.id, que promove soluções de loop local e conectividade FTTH e direciona os usuários para a loja de serviços Cloud. A outra émediacloud.id, a superfície comercial destinada a clientes para domínios, hospedagem, VPS, certificados SSL, e-mail e serviços web. Essas duas superfícies não são meras anedotas de marca. Elas mostram que a empresa pede aos clientes que confiem tanto sua presença básica na internet quanto serviços de infraestrutura estruturantes.

Essa confiança enfrenta restrições muito reais. Um VPS é uma máquina virtual, mas opera sobre computação, armazenamento, energia e refrigeração físicos. "Largura de banda ilimitada" é uma frase de marketing, mas os pacotes ainda passam por portas, roteadores, filtros, fibra óptica, contratos de trânsito e fabrics de exchange. Uma promessa de "suporte 24/7" só é útil se o cliente puder contatar a equipe mesmo quando o serviço afetado, o sistema de tickets, o DNS ou o estado de faturamento estiverem inativos.

A oferta de loop local é ainda mais direta: depende do acesso de última milha, de um ponto de interconexão, de um caminho upstream, de técnicos de plantão e de uma regra comercial sobre o que acontece quando o circuito permanece fora de serviço.

As evidências públicas começam no nível dos recursos digitais. O registro RDAP APNIC/IDNIC paraAS140449lista MEDIACLOUD-AS-ID, PT Media Cloud Indonesia, "Provedor de Serviços de Internet" e um endereço administrativo em Jacarta Sul. APNIC/IDNIC também mostra a rede IPv4103.152.240.0/23e a rede IPv62406:38c0::/32sob o nome MEDIACLOUD-ID. Esses registros não provam a localização de cada servidor, mas são muito mais sólidos do que uma página de revendedor anônimo. Eles mostram uma empresa com recursos de Internet digitais diretamente visíveis.

A empresa também hospeda seus sites públicos dentro dessa pegada. Uma verificação DNS durante esta pesquisa resolveu mci.net.id e mediacloud.id para o endereço 103.152.240.97, dentro da alocação 103.152.240.0/23. Este é um sinal modesto, mas importante: o site público não está simplesmente hospedado atrás de um gateway global sem aparente relação com o registro de rede. A marca, o ASN e o espaço de endereçamento roteado estão suficientemente alinhados para tornar a reivindicação de infraestrutura verificável.

A parte difícil não é provar que a Media Cloud tem presença pública. A parte difícil é determinar o nível de resiliência do cliente que essa presença implica. As evidências de roteamento públicas podem mostrar quais prefixos são visíveis, quais ASNs são adjacentes à rede, se os dados de origem de rota são cobertos e se um diretório de exchange voluntário lista uma porta. Elas não podem mostrar o servidor reserva no rack, o contrato de instalação, o processo de backup do cliente ou a pessoa autorizada a substituir o hardware depois da meia-noite. Essa lacuna está no centro do artigo.

A linha de produtos anunciada vai além de uma simples página de VPS

As páginas de produtos da Media Cloud mostram uma empresa que quer ser um balcão único para clientes indonésios que desejam construir uma presença web. Aloja Media Cloudindica que fornece domínios, hospedagem, construtor de sites, e-mail, certificados SSL e serviços VPS. Ela promove domínios.id e.com, serviços de revenda e atacado, e um selo "Best VPS Cloud Hosting" apontando para o produto VPS. Isso importa porque uma oferta ampla cria múltiplos caminhos de dependência. Um cliente pode comprar um domínio, DNS, certificado SSL, caixa de e-mail, construtor de sites e VPS do mesmo provedor e descobrir durante um incidente que a dependência técnica e a dependência de conta estão intimamente ligadas.

Apágina de VPSé a reivindicação mais clara de capacidade hospedada. Ela comercializa "VPS Indonesia", descreve o serviço como "VPS indonésio rápido e estável a preços acessíveis" e lista recursos 100% dedicados, armazenamento NVMe, largura de banda ilimitada e proteção DDoS. Ela também indica que os clientes podem escolher sistemas operacionais e aplicativos pré-configurados. Esta é exatamente a linguagem que transforma uma pequena rede em dependência comercial: os clientes não estão comprando apenas espaço de endereçamento; eles esperam computação, armazenamento, instalações de software, controles de segurança e capacidade de rede suficiente para manter os aplicativos acessíveis.

As páginas de hospedagem adicionam outra camada.Sitejet Hostingapresenta hospedagem agrupada com construtor de sites e destaca proteção DDoS, cPanel, Softaculous e instalações com um clique.WordPress Hostingusa a mesma linguagem de confiabilidade e recursos, embora a tabela de planos não estivesse disponível para a moeda detectada no momento da consulta. Isso é útil porque revela as suposições de plataforma subjacentes à experiência do cliente. cPanel, Softaculous, construtores de sites e hospedagem WordPress dependem todos de painéis de controle, status de licença, armazenamento e práticas de backup. São sistemas operacionais, não simples nomes de produtos estáticos.

O e-mail estende ainda mais a dependência.Email Hostinganuncia e-mail profissional com garantia de disponibilidade de 99,9%, domínios personalizados, segurança, monitoramento, suporte 24/7 e assistência para configuração, migração e solução de problemas.Professional Emaildescreve 8 GB por caixa de correio, webmail, anti-spam, antivírus, assinaturas DKIM, backups automáticos, funções de rastreamento de e-mail e logs de auditoria. Os registros MX adicionam nuances: mci.net.id usa proteção de e-mail da Microsoft, enquanto mediacloud.id aponta para servidores de e-mail do Google aspmx. Isso não é contraditório; mostra que algumas partes da empresa dependem de plataformas de e-mail externas, mesmo quando os sites públicos estão no espaço de endereçamento próprio da Media Cloud.

Apágina SSLe as páginas de domínios completam o quadro. A Media Cloud vende camadas de confiança sobre os servidores: registro de domínio, transferência, identidade.id, certificados, geração de sites e identidade de caixa de correio. Um cliente que concentra esses serviços pode ganhar conveniência, mas também cria um problema de recuperação. Se o faturamento, a verificação de identidade, o suporte ou o painel de controle travarem, várias funções de negócios independentes podem travar simultaneamente.

A precificação do loop local torna explícita a questão do rack e do roteamento

A página inicial de mci.net.id é incomumente útil porque não promove apenas serviços de nuvem abstratos. Ela anuncia "soluções de conectividade de loop local e FTTH" e descreve "banda larga dedicada de alta velocidade para comunicações empresariais confiáveis". A página lista planos de loop local a 10.000.000 IDR por mês para 1 Gbit/s, 20.000.000 IDR por mês para 2 Gbit/s e 30.000.000 IDR por mês para 3 Gbit/s, com links "Obter orçamento". Ela também indica que a Media Cloud fornece conectividade dedicada segura e de alto desempenho, baixa latência, integração escalável e suporte local 24/7.

Essas afirmações não equivalem a uma divulgação pública de instalação. No entanto, elas deslocam a análise da simples hospedagem web para a infraestrutura física. Um serviço de loop local precisa de um caminho de cliente, um ponto de interconexão, um caminho de link, um roteador, um modelo de suporte e um processo de reparo. O caminho de falha não é mais apenas "o VPS está fora do ar".

Pode ser um problema de fibra de última milha, um problema de provedor upstream, um problema de roteador de acesso, um problema de interconexão de data center, um problema de despacho de suporte, um bloqueio de faturamento ou um problema de equipamento do lado do cliente que o provedor pode ou não controlar.

A história do endereço público também requer cautela. Os registros de recursos digitais APNIC/IDNIC fornecem um endereço no Prudential Center em Jacarta Sul. Os rodapés públicos atuais da Media Cloud direcionam os leitores para Epicentrum Walk 3rd Floor Unit A306-307, Jl. HR Rasuna Said, Kuningan, Jacarta Sul. Ambos podem ser verdadeiros de maneiras diferentes: um pode ser um endereço de registro, o outro um escritório atual ou local de suporte, e nenhum identifica necessariamente onde as cargas de trabalho dos clientes ou os roteadores estão realmente hospedados.

A distinção importa porque os clientes frequentemente confundem um endereço de contato da empresa com um endereço de instalação. Não deveriam.

A página de loop local não nomeia o data center, o edifício de exchange, a rota de fibra, os provedores de trânsito upstream, o limite de serviço ou o local de recuperação. Isso é normal para uma página de marketing pública, mas significa que o comprador precisa perguntar. Se o loop local proposto termina no mesmo prédio que a carga de trabalho hospedada, o modelo de falha difere de um loop que termina em um hotel de telecomunicações separado. Se o loop é fornecido por um parceiro, o caminho de reembolso e escalação pode depender da fila de tickets do parceiro.

Se o cliente precisa de diversidade de roteamento, ele precisa saber se dois circuitos compartilham dutos, entradas de prédio, painéis de conexão ou um único gateway upstream.

Isso não quer dizer que a oferta de loop local da Media Cloud seja fraca. É para destacar que ela torna a dependência física inevitável. A capacidade hospedada parece elástica até que a última milha ou o caminho upstream falhe. Um cliente que compra nuvem e conectividade local do mesmo provedor deve se perguntar se esse agrupamento aumenta o controle ou apenas concentra a falha.

AS140449 anuncia atualmente um pequeno conjunto coerente de prefixos

As evidências de roteamento são mais claras do que as evidências do local da empresa. Avisão geral do AS140449 no RIPEstatidentificou o detentor como "MEDIACLOUD-AS-ID – PT Media Cloud Indonesia" e mostrou que o AS estava sendo anunciado durante a verificação de julho de 2026. Avisão de prefixos anunciados no RIPEstatlistou 103.152.240.0/24, 103.152.241.0/24 e 2406:38c0::/32 como visíveis na janela de 27/06/2026 a 11/07/2026. Isso significa que o /23 registrado é dividido operacionalmente em dois anúncios IPv4 /24 visíveis, enquanto a alocação IPv6 é anunciada como /32.

Essa configuração é consistente com um pequeno operador, não com uma cloud hyperscale. Dois /24 fornecem uma presença pública visível, suficiente para sites, hospedagem compartilhada, endereços VPS, sistemas de controle ou serviços locais, mas não uma pegada de nuvem de varejo massiva. O /32 IPv6 é muito maior em termos de endereços, mas o volume de endereços IPv6 não deve ser confundido com capacidade de computação instalada. A questão da capacidade utilizável não é quantos endereços existem, mas quantas cargas de trabalho podem ser hospedadas, movidas, restauradas e suportadas em caso de falha.

Ohistórico de roteamentodo RIPEstat adiciona continuidade. Os dois /24 IPv4 aparecem no histórico desde setembro de 2020, enquanto o /32 IPv6 aparece desde março de 2021. No último intervalo observado, os prefixos IPv4 ainda estavam visíveis até 11/07/2026, e a rota IPv6 também estava visível até 11/07/2026. Isso é mais sólido do que um ASN dormente recém-criado. Sugere uma superfície de roteamento pública que persistiu por anos.

Mas o histórico também inclui períodos de menor visibilidade. Os coletores de rotas públicos podem mostrar que a visibilidade mudou; eles não podem explicar por quê. Uma queda pode refletir política de roteamento, cobertura do coletor, problema upstream, período de manutenção, filtragem de rota, efeitos RPKI ou IRR em outro lugar, ou uma interrupção real de serviço. Seria irresponsável converter o histórico em uma afirmação de interrupção específica sem evidência do operador ou do cliente.

Seu valor é mais restrito: mostra que a borda de rota pública é observável o suficiente para ser monitorada e que os clientes podem se perguntar o que mudou quando a visibilidade mudou.

O estado BGP atual também é instrutivo. Aresposta de estado BGPdo RIPEstat mostrou muitos caminhos de coletores globais para os prefixos da Media Cloud, a maioria dos caminhos alcançando AS140449 via AS138840. Outros caminhos na amostra incluíam grandes nomes de trânsito global mais upstream, mas a adjacência imediata repetida com AS138840 é a dependência que importa. Um cliente não precisa de todos os detalhes do coletor de rotas; ele precisa saber se a borda da Media Cloud pode sobreviver a uma perda ou congestionamento do caminho upstream imediato.

A história upstream visível aponta para HSPnet e OpenIXP/NiCE

Avisão de vizinhos ASNdo RIPEstat registrou três ASNs adjacentes na verificação de 11/07/2026: AS138840 como vizinho esquerdo dominante, AS7717 como outro vizinho esquerdo e AS149004 como vizinho direito. APNIC identificaAS138840como um registro NAP indonésio associado à PT Parsaoran Global Datatrans / HSPnet. APNIC identificaAS7717como OpenIXP-AS-ID-AP. APNIC identificaAS149004como Morapido Net no Timor-Leste. Esses rótulos não provam contratos, mas ajudam a explicar a vizinhança de roteamento.

PeeringDB adiciona uma visão de interconexão voluntária. Suaconsulta de API de rede para AS140449lista "PT Media Cloud Indonesia", alias "Mediacloud", sitehttps://mci.net.id, tipo de informação "Enterprise", suporte IPv6, política geralmente aberta, número de IX de 1 e número de instalações de 0. Aconsulta netixlanassociada lista OpenIXP/NiCE, uma porta de 1 Gbit/s, endereço IPv4 43.252.146.141, endereço IPv6 2001:7fa:f::457 e estado operacional. Aconsulta netfacnão retorna nenhuma entrada de instalação.

A leitura mais forte é prática: a Media Cloud tem um ponto de exchange visível no OpenIXP/NiCE e uma vizinhança de roteamento pública onde AS138840 é o caminho principal visto pelos coletores. A leitura mais fraca seria inferir uma arquitetura de resiliência completa a partir desses campos. PeeringDB é mantido pelo operador e voluntário. Uma porta de exchange de 1 Gbit/s não prova que todo o tráfego de cliente pode passar pelo exchange em caso de problema de trânsito. Um número de instalações de 0 não prova que a empresa não tem racks; significa apenas que o PeeringDB não lista nenhuma entrada de instalação para a rede.

Uma adjacência upstream observada não prova se um link é de trânsito, peering, backup ou caminho de servidor de rotas, a menos que seja apoiada por documentação do operador.

Os objetos de rota RADB reforçam a mesma cautela. Uma consulta RADB para AS140449 retornou objetos de rota para 103.152.240.0/24 e 103.152.241.0/24 com origem AS140449 e descrições nomeando PT Media Cloud Indonesia. O objeto route6 para 2406:38c0::/32 usava origem AS140449, mas as observações descreviam um objeto de rota registrado por procuração para uma rota de cliente HSP Global exportada sob o AS de origem Media Cloud, mantido por MAINT-AS138840.

Essa formulação torna a questão do contrato de provedor central: se a rota IPv6 depende da HSP para manter o objeto de rota ou o arranjo upstream, os clientes precisam saber quem pode reparar a entidade, quem pode modificar os filtros e o que acontece quando o contrato upstream ou o canal de suporte falha.

A garantia de origem de rota permanece incompleta

A validação de origem de rota não é um teste completo de resiliência, mas é uma verificação significativa. Ela verifica se uma autorização de origem de rota (ROA) publicada apoia um prefixo e um AS de origem dados. Nas verificações do RIPEstat de julho de 2026,103.152.240.0/24,103.152.241.0/24e2406:38c0::/32retornaram "unknown" sem ROA validante na visão verificada. RADB também mostrou status de validação de origem RPKI como "not_found" para os objetos de rota.

Desconhecido não é o mesmo que inválido. Significa que os dados de validação de origem de rota verificados não encontraram nenhuma ROA autorizante. O risco prático é que redes que aplicam políticas de roteamento estritas podem tratar rotas desconhecidas de forma diferente das rotas válidas, ou que um sequestro de rota ou configuração incorreta futura será mais difícil de filtrar por política automatizada.

Para os clientes, essa não é a única questão de segurança, mas é uma boa pergunta de aprovisionamento: a Media Cloud pretende publicar ROAs para seus prefixos anunciados, e pode demonstrar que os objetos de rota e as ROAs são mantidos pela parte com responsabilidade operacional?

O RPKI também não pode provar a qualidade do serviço. Uma origem de rota válida não indicaria quantos servidores estão online, se os backups funcionam, se um loop local tem diversidade de caminho, ou se um técnico pode substituir hardware rapidamente. Ela fecha apenas uma categoria de risco de roteamento. Neste caso, a ausência de ROA validante torna o plano de controle público menos completo do que o catálogo de produtos. Essa lacuna é reparável, mas precisa ser reconhecida.

A lição mais ampla para os clientes é que a resiliência da capacidade hospedada tem muitas camadas. O RPKI protege a autorização de origem. Os objetos IRR influenciam os filtros. Os vizinhos BGP influenciam a acessibilidade. Os arranjos de exchange e trânsito influenciam as escolhas de caminho. A instalação, energia, peças de reposição e suporte influenciam o reparo. Os backups e caminhos de exportação influenciam a recuperação. As evidências públicas da Media Cloud são mais fortes no meio dessa cadeia e mais fracas nas extremidades: a visibilidade das rotas é clara; a portabilidade de dados e a recuperação testada não são públicas.

Os termos da Media Cloud descrevem o caminho da falha

As páginas legais da empresa não são diagramas técnicos refinados, mas são operacionalmente reveladoras. Ostermos de uso do mediacloud.iddefinem amplamente os serviços para incluir registro de nomes de domínio, hospedagem, serviços de criação de sites e serviços de internet. Os termos indicam que a hospedagem armazena e serve o conteúdo do site, e que os serviços de internet podem incluir televisão, e-mail, conectividade e serviços relacionados. Eles também indicam que a Media Cloud fará esforços comercialmente razoáveis para fornecer o site e os serviços vinte e quatro horas por dia, sete dias por semana.

A mesma seção sobre disponibilidade é mais importante do que a frase sobre disponibilidade. Ela indica que os serviços podem ficar inacessíveis ou inoperáveis por razões que incluem mau funcionamento de equipamento, manutenção periódica, reparos ou substituições, causas além do controle razoável, interrupção ou falha de links de telecomunicações ou transmissão digital, ataques de rede hostis, congestionamento de rede e outras falhas. Ela também indica que a Media Cloud não tem controle sobre a disponibilidade contínua ou ininterrupta. Essa redação não é incomum; muitos provedores usam isenções de responsabilidade semelhantes.

Aqui, no entanto, ela dá aos clientes uma lista concisa das categorias exatas de dependência que eles devem testar.

Apolítica de reembolsoé igualmente específica. Ela indica que as taxas de registro de domínio são geralmente não reembolsáveis uma vez registradas ou renovadas; os serviços de hospedagem e criação de sites não são reembolsados uma vez adquiridos; e os serviços de internet banda larga ou dedicados podem ser elegíveis para reembolso se o serviço for interrompido por mais de sete dias multiplicados por 24 horas consecutivas, ou se a Media Cloud não puder continuar a fornecer o serviço devido a dificuldades técnicas ou proibição pelo chefe local do bairro. Este é um limite operacional marcante. Sugere que para conectividade de internet, o gatilho de reembolso é medido em dias, não em minutos ou horas.

Os clientes não devem confundir elegibilidade de reembolso com resiliência operacional. Um reembolso após uma semana de interrupção contínua não restaura um aplicativo, não migra uma caixa de correio, não recupera um banco de dados e não mantém uma loja online funcionando durante a interrupção. Ele define apenas um recurso financeiro. Um cliente com cargas de trabalho críticas deve exigir acordos de nível de serviço, escalação de incidentes, notificação proativa, janelas de manutenção, obrigações de exportação de dados e objetivos de recuperação medidos que são distintos da política de reembolso.

É por isso que o título do artigo aponta para os racks, o trânsito e as janelas de reparo. Os termos legais da Media Cloud identificam as mesmas categorias: equipamento, manutenção, links de telecomunicações, congestionamento e ataque. Os dados de roteamento públicos mostram então onde aparece uma dependência de trânsito importante. O trabalho do comprador é transformar esses indícios públicos em evidências contratuais e testáveis.

A localização dos dados não é resolvida por uma marca indonésia

O posicionamento da Media Cloud é fortemente indonésio. A página de domínios enfatiza a identidade.id, a página VPS diz "VPS Indonesia", o rodapé fornece um endereço de contato em Jacarta Sul, e os registros APNIC/IDNIC colocam o AS e os recursos de endereço na Indonésia. Para muitos clientes, especialmente pequenas empresas, este pode ser o ponto principal: um provedor local, idioma local, expectativas de pagamento locais e suporte acessível através de canais indonésios.

Mas a soberania e localização de dados exigem mais do que um rótulo de país. Um site hospedado pode estar nos endereços da Media Cloud enquanto o e-mail é tratado via Google ou Microsoft. Um ticket de suporte pode conter informações pessoais. Um backup pode ser armazenado em um sistema diferente do servidor principal. Um registro de domínio pode envolver processos de registrador e registro. Uma reivindicação de mitigação DDoS pode depender de filtragem upstream ou plataforma de terceiros. Cada camada pode colocar dados, metadados ou direitos de acesso em uma localização operacional diferente.

Apolítica de privacidadeda empresa indica que coleta informações de contato, informações de faturamento, identificadores de conta, conteúdo criado ou carregado pelo usuário, dados de log, informações de dispositivo e cookies ou tecnologias semelhantes. Ela indica que as informações pessoais podem ser compartilhadas com provedores de serviços, parceiros terceiros para fins de marketing ou publicidade, no contexto de transações comerciais, ou quando exigido por lei. Ela também indica que as informações pessoais podem ser transferidas e processadas em países diferentes do país do usuário, e que nenhum método de transmissão pela internet ou armazenamento eletrônico é completamente seguro. Esta é uma linguagem de privacidade genérica, mas em um contexto de hospedagem, isso importa: o provedor reconhece a possibilidade de processamento transfronteiriço e por terceiros.

O contexto legal indonésio também eleva a barra para uma gestão clara de dados. O Regulamento Governamental nº 71 de 2019 sobre Sistemas e Transações Eletrônicas é publicado pela JDIH Kemkomdigi emesta página oficial. A página inclui disposições sobre registro de operadores de sistemas eletrônicos, confiabilidade, segurança, gestão de riscos, acordos de nível de serviço e princípios de tratamento de dados pessoais. A Lei nº 27 de 2022 sobre Proteção de Dados Pessoais é publicada emJDIH Kemkomdigi. Este artigo não afirma que a Media Cloud se enquadra em uma categoria regulatória específica para cada produto, mas a estrutura nacional explica por que os clientes devem perguntar onde residem realmente os dados, backups, logs, tickets e acesso ao suporte.

O teste prático é simples. Um VPS indonésio deve vir com uma resposta sobre localização: onde está o host principal, onde estão os backups, onde está a identidade do plano de controle, onde estão os logs, e quais serviços terceiros gerenciam e-mail, DNS, filtragem DDoS, suporte ou faturamento? Sem essa matriz, "local" continua sendo um sinal de marketing útil, mas não uma garantia completa de soberania.

Capacidade instalada e capacidade utilizável são diferentes

A pegada de rede pública da Media Cloud sustenta uma narrativa de capacidade instalada modesta, mas real. Ela tem um AS registrado, um /23 IPv4 roteado dividido em dois /24, um /32 IPv6, sites públicos no mesmo bloco IPv4, uma listagem de exchange no PeeringDB, uma oferta de loop local e produtos VPS/hospedagem/e-mail. Isso é mais concreto do que um mero revendedor sem borda identificável. É suficiente para justificar o interesse dos clientes.

A capacidade utilizável é a questão mais difícil. Um produto VPS pode prometer recursos dedicados e armazenamento NVMe, mas as páginas públicas não divulgam quantos hipervisores existem, como o armazenamento é replicado, se os backups do cliente estão fora do rack ou fora do local, quantas máquinas de reposição são estocadas, que fração da capacidade é reservada para failover, ou se o painel de controle pode operar se a rede de produção falhar.

Um produto de loop local pode prometer 1 Gbit/s, 2 Gbit/s ou 3 Gbit/s, mas as páginas públicas não divulgam os caminhos de fibra, a diversidade de interconexão, a diversidade de operadoras ou a política de congestionamento em caso de falha.

Essa distinção importa em caso de falha. Capacidade instalada é o que um provedor vende em um dia normal. Capacidade utilizável é o que resta após uma falha de servidor, roteador, caminho de fibra, provedor upstream, porta de exchange, energia, fila de suporte ou conta de faturamento. Capacidade recuperável é o que pode ser restaurado dentro dos limites de tolerância de tempo de inatividade e perda de dados do cliente. Os clientes compram a segunda e a terceira categorias, quer a fatura as nomeie ou não.

O modelo upstream visível da Media Cloud torna essa distinção mais urgente. Se a maioria dos caminhos de coletores globais atinge AS140449 via AS138840, o cliente precisa perguntar se AS138840 é uma dependência upstream única, um caminho de trânsito principal, um caminho de servidor de rotas, ou parte de um mix de trânsito mais amplo que os coletores públicos não expõem completamente. Se a presença OpenIXP/NiCE é de 1 Gbit/s, o cliente precisa perguntar se ela é usada para peering sem liquidação, acessibilidade do servidor de rotas, backup ou tráfego crítico do cliente.

Se o PeeringDB não lista nenhuma instalação, o cliente precisa perguntar onde está o equipamento de produção e como o acesso físico é gerenciado.

Nenhuma dessas perguntas implica culpa. São perguntas normais de due diligence de infraestrutura. Um pequeno provedor pode ser excelente se for honesto sobre seus limites, testar a recuperação e dar aos clientes caminhos de saída viáveis. Um grande provedor pode ser frágil se esconder um ponto único de falha. As evidências públicas para a Media Cloud são fortes o suficiente para formular as perguntas iniciais, mas não fortes o suficiente para encerrá-las.

Suporte e faturamento fazem parte da infraestrutura

A Media Cloud vende seus produtos através de uma loja que requer login, links de contato e botões WhatsApp. O rodapé lista[email protected]na loja e[email protected]no site corporativo, enquanto mci.net.id expõe support.mci.net.id em 103.152.240.243. Isso dá aos clientes vários pontos de entrada de suporte, mas a questão de resiliência é se esses pontos de entrada são suficientemente independentes durante um incidente.

Suporte é infraestrutura porque transforma detecção em reparo. Se um VPS falha, o cliente precisa mais do que um recibo genérico. Ele precisa de uma pessoa responsável qualificada, um diagnóstico, um caminho de restauração estimado e um meio de recuperar dados se a restauração exceder o prazo do cliente. Se um loop local falha, o cliente precisa saber se a Media Cloud pode enviar um técnico, se um parceiro controla a última milha, e se o mesmo circuito carrega o portal de suporte. Se o faturamento bloqueia uma conta, o cliente precisa de um caminho de escalação que possa separar o status comercial do acesso de emergência aos dados.

Os termos de uso tornam o status da conta e do pagamento operacionalmente relevantes. Os preços podem mudar; o não pagamento pode resultar em suspensão ou rescisão; os clientes são responsáveis por manter a segurança da conta; a Media Cloud pode suspender ou rescindir o acesso em caso de violação. Essas cláusulas são padrão, mas mostram que o plano de controle não é puramente técnico. Um domínio, plano de hospedagem, caixa de correio ou VPS pode falhar devido a uma condição administrativa tanto quanto a uma condição de hardware.

Os produtos de e-mail tornam isso ainda mais visível. As páginas de e-mail descrevem assistência à migração, solução de problemas, webmail, anti-spam, antivírus, assinaturas DKIM, backups automáticos, funções de rastreamento de e-mail e logs de auditoria. Se estes fazem parte do processo de negócios de um cliente, a recuperação deve incluir exportação de caixa de correio, continuidade de DNS, continuidade de DKIM/SPF/DMARC, acesso a arquivos e evidências de suporte. Não basta dizer "o e-mail está hospedado". O cliente precisa saber o que acontece quando o produto de e-mail ou sua dependência de plataforma externa falha.

Para a Media Cloud, o comprador deve solicitar um manual de procedimento de suporte antes de mover cargas de trabalho críticas. Quem atende chamadas urgentes? Existe escalação telefônica para falha de loop local ou VPS? Os membros da equipe de suporte estão autorizados a mover cargas de trabalho ou apenas a criar tickets? As filas de conta, faturamento e abuso são separadas da resposta a incidentes? Com que rapidez a empresa pode fornecer uma exportação completa do disco VPS, arquivos do site, conteúdo da caixa de correio, zona DNS e código de autorização de domínio se o cliente decidir sair?

O principal risco do cliente é a concentração

A conveniência da Media Cloud é também o seu risco. Um cliente pode plausivelmente comprar o domínio, site, hospedagem, VPS, certificado SSL, e-mail profissional e conectividade dedicada da mesma família de marcas. Isso pode reduzir o gerenciamento de fornecedores para uma pequena empresa. Mas também pode transformar um incidente de fornecedor em uma falha composta: renovação de DNS, emissão de certificado, hospedagem web, acessibilidade do VPS, acesso a e-mail e conectividade local podem todos exigir a mesma equipe de suporte ou o mesmo relacionamento de conta.

A versão de infraestrutura da concentração é semelhante. Se a borda visível depende fortemente de AS138840, se a superfície de exchange é uma única listagem OpenIXP/NiCE, se a produção está em uma instalação não divulgada, e se o caminho de suporte está vinculado à mesma rede, então um único problema operacional pode afetar múltiplas camadas. As evidências públicas não provam que todos esses pontos únicos existem, mas também não os descartam. Os registros visíveis são suficientes para exigir uma resposta.

Os clientes devem testar a concentração de quatro maneiras. Primeiro, separar identidade e DNS da hospedagem. O domínio pode ser transferido rapidamente? Os registros DNS podem ser exportados? Os registros de zona são acessíveis durante uma falha de hospedagem? Segundo, separar computação de backup e armazenamento. O cliente pode recuperar um VPS ou site em outro provedor sem esperar que a Media Cloud reconstrua o host original? Terceiro, separar conectividade da hospedagem de aplicativos. Se o loop local falhar, o cliente pode acessar o serviço hospedado através de outro provedor de acesso? Quarto, separar suporte da plataforma afetada.

Se o portal de serviço estiver fora do ar, existe um canal de escalação independente?

O limite de reembolso do loop local deve concentrar as mentes. Um serviço interrompido por mais de sete dias consecutivos está muito além da tolerância de muitas cargas de trabalho profissionais. Um cliente que não pode operar por uma semana não deve contar com a política de reembolso como plano de continuidade. Ele deve exigir failover, backups testados, acesso alternativo e condições de escalação por escrito antes de comprar.

Esta é a conclusão mais prática do dossiê público. A Media Cloud parece ser um provedor operacional genuíno com uma rede identificável. Vale a pena ser avaliada. As mesmas evidências mostram por que a avaliação deve ir além da página de produto: um cliente precisa de evidências de diversidade, recuperação e saída.

O que um comprador sério deve perguntar a seguir

Um comprador sério deve começar pela borda de roteamento. Perguntar à Media Cloud quais serviços usam AS140449, quais prefixos são atribuídos aos pools de VPS ou hospedagem de clientes, e se algum serviço de cliente está atrás de outros provedores. Perguntar se ROAs serão publicados para 103.152.240.0/24, 103.152.241.0/24 e 2406:38c0::/32, e quem mantém os objetos de rota IRR. Perguntar se AS138840 é o trânsito principal, trânsito de backup, adjacência de servidor de rotas ou outra relação, e se existe um segundo caminho de trânsito independente com capacidade paga suficiente para transportar o tráfego do cliente em caso de falha.

Em seguida, perguntar sobre o modelo de instalação. Qual(is) data center(s) hospeda(m) os produtos VPS e hospedagem? Os racks são próprios, alugados ou sublocados? Existem fontes de energia separadas, roteadores separados, firewalls separados e entradas de fibra separadas? O OpenIXP/NiCE é usado para tráfego crítico do cliente, e a porta de exchange de 1 Gbit/s tem monitoramento de congestionamento? Se o PeeringDB não lista nenhuma instalação, é porque a empresa opta por não divulgar, porque a rede é fornecida através de um parceiro, ou porque as cargas de trabalho dos clientes não são colocadas em uma instalação de interconexão pública?

Terceiro, perguntar sobre testes de recuperação. Quando foi a última restauração de disco VPS? Quanto tempo levou? Foi restaurada no mesmo host, em outro host na mesma instalação, ou em um local diferente? Como os backups de hospedagem WordPress e Sitejet são armazenados? Um cliente pode testar uma exportação sem cancelar o serviço? O e-mail é copiado de forma que o cliente possa recuperá-lo? As chaves DKIM, zonas DNS, certificados e arquivos de caixa de correio estão incluídos em um pacote de saída?

Quarto, perguntar sobre os limites de suporte. Qual é o caminho de incidente grave para serviços VPS, hospedagem, domínio, e-mail, SSL e loop local? Qual método de contato permanece disponível se mci.net.id ou mediacloud.id estiverem inacessíveis? O suporte WhatsApp cria um ticket formal? Existem tempos de resposta e restauração definidos? Quais eventos geram notificações aos clientes antes do início da manutenção?

Finalmente, perguntar como as declarações legais e de privacidade correspondem ao posicionamento real dos dados. A política de privacidade permite o processamento transfronteiriço, e as evidências DNS/MX mostram dependência de plataformas globais para algumas partes do negócio. O cliente deve perguntar onde os dados pessoais, logs, backups, tickets e registros de faturamento são processados, e se um produto pode ser contratualmente mantido na Indonésia.

Essas perguntas não são hostis. São a maneira como um comprador transforma a rede pública visível da Media Cloud em uma dependência testada. A empresa tem evidências públicas suficientes para justificar a conversa. Ainda não tem evidências públicas suficientes para permitir que os clientes a pulem.

O nível de evidência

PT Media Cloud Indonesia recebe um nível de evidência pública Médio. O nível não é uma pontuação de qualidade para a empresa; é uma pontuação para o que as evidências públicas podem sustentar. No lado positivo, a identidade e a superfície operacional são incomumente concretas para um provedor de hospedagem regional. APNIC/IDNIC vincula a empresa ao AS140449, 103.152.240.0/23 e 2406:38c0::/32. RIPEstat viu três prefixos ativos anunciados em julho de 2026. Os sites públicos resolvem no bloco IPv4 da empresa.

A Media Cloud anuncia um conjunto específico de produtos: domínios, hospedagem, VPS, SSL, e-mail, serviços web e conectividade de loop local. PeeringDB lista a rede e um ponto de troca OpenIXP/NiCE.

As preocupações de rebaixamento dizem respeito a evidências de resiliência. As evidências públicas não nomeiam uma instalação de produção. PeeringDB não lista nenhuma entrada de instalação. A validação de origem de rota retornou "unknown" para os prefixos verificados. Os caminhos BGP visíveis estão fortemente associados ao AS138840, e o objeto de rota IPv6 descreve uma rota de cliente HSP Global registrada por procuração. Os próprios termos da Media Cloud indicam que os serviços podem ser interrompidos por mau funcionamento de equipamento, manutenção, reparo, falha de link de telecomunicações, ataques hostis, congestionamento e outras causas.

A política de reembolso sugere que alguns recursos para serviços de internet são enquadrados em torno de interrupção prolongada contínua, em vez de tempo de inatividade operacional curto.

Essa combinação sustenta uma conclusão clara: a Media Cloud é um provedor genuíno indonésio de serviços hospedados e conectividade com uma rede visível, mas os clientes não devem tratar a rede visível como prova de resiliência de nuvem multissite. O caminho adequado de due diligence é verificar a localização das instalações, diversidade de trânsito, controles de origem de rota, testes de backup e restauração, escalação de suporte, regras de continuidade de faturamento e direitos de exportação de dados. Se essas verificações forem satisfatórias, as evidências públicas dão aos clientes algo sólido para monitorar.

Se essas verificações estiverem ausentes, a conveniência de um provedor local agrupado pode se tornar uma dependência concentrada.