Résumé

  • PT. Arupa Cloud Nusantara n'est pas une simple marque d'hébergement web. Ses propres pages décrivent un agrégateur de technologies fondé en 2017, avec plus de 350 clients, plus de 50 partenaires de distribution, plus de 20 solutions en tant que service, et une adresse de contact publique actuelle au South Quarter Tower A à Jakarta Sud.
  • L'entreprise vend de la capacité hébergée à plusieurs niveaux: Arupa Compute, Virtual centres de données, Virtual Server, Private Cloud, Backup, Arupa Backup, reprise après sinistre Zerto, stockage d'objets, cloud géré, migration cloud, et, via une annonce de 2026 avec Civo, un cloud Kubernetes souverain destiné aux charges de travail indonésiennes.
  • Les preuves réseau sont visibles mais limitées. APNIC identifie AS136102 et AS137286 comme ressources de PT. Arupa Cloud Nusantara; RIPEstat a vu les deux ASN globalement visibles en IPv4 le 11 juillet 2026; PeeringDB montre un port 1 Gbps OpenIXP / NiCE pour AS136102 et un port 1 Gbps DCI-IX pour AS137286. Aucune source publique n'a trouvé d'annonces IPv6 pour l'un ou l'autre ASN.
  • Le test opérationnel non résolu est physique plutôt que linguistique. Les pages publiques décrivent une capacité flexible, une récupération rapide, une conformité locale et un support géré, mais elles ne publient pas le nombre de baies, les limites de contrat de centre de données, la topologie de l'alimentation et du refroidissement, la politique de pièces de rechange matérielles, les tests de restauration de sauvegarde, les exercices de basculement multi-sites ou les procédures de sortie pour les clients qui doivent déplacer leurs charges de travail.

La promesse cloud est réelle, mais les questions difficiles se cachent derrière la marque

Arupa est un bon exemple de la raison pour laquelle les petits et moyens fournisseurs de cloud doivent être analysés sous deux angles simultanément. Le premier angle est commercial: que propose le fournisseur et à qui s'adresse-t-il? De ce point de vue, l'entreprise a une empreinte publique beaucoup plus forte qu'un simple revendeur d'hébergement. Sapage d'accueilindique qu'elle aide les entreprises, les PME et les partenaires technologiques avec des solutions cloud, données et cybersécurité. Sapage à proposdit qu'Arupa Cloud Nusantara opère comme un agrégateur de technologies de confiance depuis 2017 et liste plus de 350 clients de confiance, plus de 50 partenaires de distribution, plus de 20 solutions en tant que service et une expertise 100% locale. Sapage du programme partenaireinvite les MSP, intégrateurs systèmes, revendeurs et partenaires ISV à rejoindre un écosystème croissant autour des services cloud et de sécurité des données.

Le deuxième angle est physique: quels équipements, bâtiments, routes, personnes et contrats rendent la promesse commerciale vraie un mauvais jour? Ces preuves sont plus minces. Les mêmes pages publiques décrivent une infrastructure cloud flexible, des ingénieurs locaux, une récupération rapide et des données stockées en Indonésie, mais elles nomment rarement le hall du centre de données, l'empreinte des baies, la conception électrique, le point de remontée, le stock de pièces de rechange ou le chemin d'escalade du support. Un acheteur peut voir les catégories de services.

Il ne peut pas tracer complètement la chaîne de dépendance d'une facture Arupa à une alimentation électrique, un commutateur, une étagère de disques, un cluster d'hyperviseurs, un référentiel de sauvegarde et un gestionnaire d'incidents humain.

Cela ne signifie pas que la capacité est fictive. L'entreprise dispose de ressources réseau enregistrées auprès d'APNIC, de deux systèmes autonomes visibles et de dossiers d'interconnexion publics. Elle a également une adresse de bureau formelle actuelle et plusieurs annonces de produits récentes. La conclusion correcte est plus précise: Arupa a suffisamment de preuves publiques pour être considérée comme une entreprise indonésienne de cloud et de services opérationnelle, mais pas assez pour attribuer un niveau de résilience à la capacité hébergée qu'elle vend. Le risque n'est donc pas « cette entreprise est-elle réelle?

» mais « quelles parties du cloud sont sous le contrôle opérationnel direct d'Arupa, et lesquelles dépendent d'un propriétaire de centre de données, d'un opérateur, d'un fournisseur de matériel, d'un concédant de logiciel ou d'un partenaire de migration? »

Identité, adresses et la limite Zettagrid

L'identité publique d'Arupa porte plusieurs étiquettes qui se chevauchent. Les enregistrements APNIC pourAS136102etAS137286nomment PT. Arupa Cloud Nusantara, le décrivent comme un membre corporatif/direct d'IDNIC et placent l'ancienne adresse de registre au Eightyeight@Kasablanka Office Tower, 18e étage, Menteng Dalam, Tebet, Jakarta Sud. Leprofil d'organisationde PeeringDB nomme également PT. Arupa Cloud Nusantara et utilise l'alias Zettagrid Indonesia à l'adresse Eighty Eight Kasablanka. Lapage de contactactuelle d'Arupa pointe plutôt vers South Quarter, Jalan R.A. Kartini Kav. 8, Tower A, 9e étage, Cilandak Barat, Jakarta Sud, avec des adresses email marketing et support.

La différence d'adresse est un signal, pas une contradiction. Les enregistrements d'entreprise, de registre, d'interconnexion et de marketing sont souvent décalés. Mais pour un fournisseur de cloud, la rigueur des adresses importe car les clients doivent savoir quel site est un bureau, quel est une adresse d'enregistrement réseau et quel abrite l'équipement de production. Les pages de bureau public d'Arupa ne prétendent pas que le bureau de South Quarter est le centre de données. APNIC et PeeringDB identifient l'entreprise et ses ressources de numérotation, pas l'empreinte physique des baies.

L'entreprise doit donc être comprise comme un opérateur et partenaire technologique avec des adresses de bureau et de registre, tandis que le substrat d'hébergement se trouve ailleurs.

L'étiquette Zettagrid nécessite également une manipulation prudente. Plusieurs pages et profils tiers utilisent Arupa, Zettagrid Indonesia ou les deux. Lemessage de récompense partenaire Broadcomfait référence à PT Arupa Cloud Nusantara sous le nom de Zettagrid Indonesia et indique qu'il a remporté un prix de partenaire Broadcom de Crayon Indonesia pour 2025 après une reconnaissance similaire en 2024. Cela soutient l'idée qu'Arupa fait partie d'un écosystème de services cloud orienté VMware/Broadcom. Cela ne dit pas en soi si chaque service Arupa est fourni sur du matériel appartenant à Arupa, une infrastructure exploitée par Zettagrid, une colocation, des clouds partenaires ou un mélange de ces couches.

Ce que vend Arupa: le calcul d'abord, mais pas seulement

La pageArupa Computeprésente la famille de produits comme une infrastructure flexible et évolutive pour la croissance des entreprises. Au sein de cette famille,Virtual centres de donnéesest positionné comme un cloud VMware en Indonésie, donnant aux clients le contrôle de la capacité serveur, stockage et réseau sans posséder de serveurs physiques.Virtual Serverest la promesse plus simple de type VPS: des serveurs rapides, fiables et flexibles avec une capacité disponible en minutes.Private Cloudest présenté comme une infrastructure cloud dédiée pour une organisation, avec un isolement plus fort et un contrôle total.

Ce sont des engagements opérationnels matériellement différents. Un client de serveur virtuel a surtout besoin d'une VM fonctionnelle, d'une accessibilité réseau, de snapshots ou de sauvegardes et d'une voie de mise à niveau. Un client de centre de données virtuel a besoin de pools de ressources, d'isolement locataire, de segmentation réseau, de performances de stockage et de disponibilité du plan de gestion. Un client de cloud privé peut avoir besoin de matériel réservé, de fenêtres de maintenance prévisibles, de délais de remplacement matériel explicites et d'un modèle de propriété clair pour les licences et les appareils.

Si les trois sont vendus sous une seule histoire cloud, le fournisseur doit rendre visible la limite de capacité pour chaque produit.

La sauvegarde et la reprise après sinistre rendent cette limite encore plus nette. La pageBackupdit que le service protège et restaure automatiquement les données de l'entreprise.Arupa Backupest décrit comme un service tout-en-un combinant sauvegarde locale et cloud, reprise après sinistre et opération gérée. Un article de lancement séparé indique queArupa Backupinclut la sauvegarde des données, la récupération des données, la reprise après sinistre, la sécurité, la surveillance et même le matériel client sur site, géré par l'équipe experte d'Arupa.Zerto SecondSitepromet une réplication en temps réel, un RPO mesuré en secondes et un RTO mesuré en minutes.Active-Active DRprésente l'objectif comme une continuité d'activité permanente.

Chacune de ces affirmations ne peut être vraie que si la couche la plus lente est suffisamment rapide. Un RPO à l'échelle de la seconde est une déclaration de réplication; il dépend du débit d'écriture des applications, de la qualité de la liaison, du retard de réplication, de la latence de stockage et de la détection des pannes. Un RTO à l'échelle de la minute est une déclaration de récupération; il dépend des procédures, du DNS, des modifications de pare-feu, des dépendances d'application, des systèmes d'identité, de la cohérence des bases de données et de l'approbation du support.

Les pages produits publiques disent ce que le client devrait obtenir, mais pas les preuves de test montrant qu'un client spécifique peut l'obtenir.

Le stockage d'objets et Kubernetes élargissent la carte des dépendances

L'histoire du stockage d'Arupa s'étend au-delà de la sauvegarde de VM. Sa pageArupa Object Storagedécrit le stockage pour les archives, les sauvegardes, le contenu multimédia et les journaux, et indique que les données sont sécurisées dans un centre de données indonésien de niveau III avec chiffrement et langage de conformité réglementaire. Un article ultérieur indique qu'Arupa est unrevendeur agréé MinIO en Indonésiedepuis trois ans, promouvant MinIO AIStor pour le stockage compatible S3, l'IA/ML, l'IA générative, le data lakehouse et les charges de travail cloud-native.

Cela aide à expliquer la position d'Arupa sur le marché. Il ne vend pas seulement des emplacements de calcul génériques. Il assemble des logiciels cloud, de sauvegarde, de stockage, des licences et une mise en œuvre locale. Cela peut être précieux pour une entreprise indonésienne qui veut un partenaire local plutôt qu'un cloud en libre-service distant. Mais le stockage d'objets soulève également différents tests opérationnels.

Les questions importantes sont la durabilité, le codage d'effacement ou la politique de réplication, les domaines de défaillance, la protection contre la suppression, l'immuabilité, la bande passante de restauration, les limites de compatibilité S3, le chemin d'exportation et qui paie pour le trafic sortant lors d'une migration ou d'un incident. Une fiche technique qui dit « stockage d'objets » ne répond pas à ces questions.

La couche Kubernetes ajoute une autre dépendance. L'article d'Arupa du 22 mai 2026 indique qu'elle a formé unpartenariat stratégique avec Civopour apporter une plateforme cloud souveraine basée sur Kubernetes en Indonésie, avec un support local, des services de mise en œuvre et une assistance pour les besoins réglementaires. Lapage Indonésie de Civodécrit une région indonésienne hébergée à Jakarta, conçue pour la liberté du cloud public et le contrôle du cloud privé, avec Kubernetes géré, calcul, bases de données gérées, équilibreurs de charge, hébergement local et alignement avec la loi indonésienne sur la protection des données personnelles.

Les preuves concernant Civo sont solides pour l'intention de service: capacité Kubernetes, juridiction locale et partenariat produit. Elles sont plus faibles sur les questions physiques que cet article teste. Ils ne publient pas le nombre de baies derrière la région de Jakarta, l'identité de l'installation sur la page publique, la conception de basculement de site, la combinaison d'opérateurs, le pool de pièces de rechange matérielles, ou si le rôle d'Arupa est revendeur, opérateur, support de première ligne, partenaire de mise en œuvre ou une combinaison qui varie selon le client.

La lecture prudente est que le partenariat élargit l'offre cloud-native d'Arupa, tout en laissant la conception du site sous-jacent et de la reprise à vérifier dans les documents contractuels du client.

Les deux ASN montrent un réseau opérationnel, pas une carte cloud complète

Le registre de routage donne à Arupa l'un de ses ancrages publics les plus solides. APNIC identifieAS136102comme IDNIC-ARUPA-AS-ID et enregistre les politiques d'importation depuis AS24538 et AS7717, les exportations vers AS23949 et AS7717, et une route par défaut vers AS24538. Il identifieAS137286sous le même nom d'AS, avec des importations depuis AS7717, AS17451 et AS56258, des exportations vers les mêmes trois ASN et une route par défaut vers AS17451. Les enregistrements de contact et d'abus pointent vers Arupa.

Lesdonnées d'état de routage de RIPEstat pour AS136102montraient, lors de la vérification du 11 juillet 2026, tous les 327 pairs RIS IPv4 disponibles voyant l'ASN, sept préfixes IPv4 visibles, 2 560 adresses IPv4 et aucun espace IPv6 visible. Sesdonnées de préfixes annoncésmontraient des préfixes incluant 103.10.148.0/22, 103.90.250.0/23, 103.90.250.0/24, 103.90.251.0/24, 103.145.194.0/23, 103.145.194.0/24 et 103.145.198.0/23 dans la fenêtre de deux semaines se terminant le 11 juillet 2026. Lesdonnées d'état de routage correspondantes pour AS137286montraient 327 pairs IPv4 sur 327 voyant l'ASN, trois préfixes IPv4 visibles, 2 048 adresses IPv4 et aucun espace IPv6 visible, tandis que sesdonnées de préfixes annoncésmontraient 49.128.188.0/22, 103.90.248.0/23 et 103.145.196.0/23.

BGP.tools présente indépendammentAS136102comme étant en peering avec quatre autres réseaux et ayant deux fournisseurs en amont, listant PT iForte Global Internet et Biznet Networks comme fournisseurs en amont. Il présenteAS137286comme étant en peering avec trois autres réseaux et ayant deux fournisseurs en amont, listant Biznet Networks et PT PGAS Telekomunikasi Nusantara comme fournisseurs en amont. Les mêmes pages ne montrent aucun espace IPv6 originaire. Cela ne rend pas le réseau faible; de nombreux réseaux d'entreprise/cloud indonésiens restent dominés par IPv4. Cela signifie que les affirmations des clients concernant IPv6 doivent être testées séparément plutôt que déduites de l'existence d'un produit cloud.

Les ASN ne doivent pas être confondus avec la carte cloud complète. Un fournisseur de cloud peut héberger des charges de travail clients derrière des ASN partenaires, des interconnexions privées, des services tunnel, des régions cloud publiques, des réseaux de contenu ou des préfixes appartenant aux clients. Inversement, un ASN peut être à l'origine d'espace d'adressage en aval ou client qui n'est pas le pool propre du fournisseur. La preuve AS montre qu'Arupa dispose d'un routage Internet actif. Elle ne révèle pas chaque locataire, cluster de stockage, structure d'hyperviseur ou chemin de support.

Les préfixes montrent à la fois l'espace Arupa et des contours de type client

La preuve des préfixes ajoute une nuance importante. APNIC assigne103.90.248.0/22à PT. Arupa Cloud Nusantara en tant qu'espace portable alloué, et les enregistrements APNIC pour103.10.148.0/22et49.128.188.0/22sont des ressources portables allouées à Arupa. Ces trois blocs constituent une preuve solide de ressources d'entreprise.

D'autres espaces originaires visibles nécessitent plus de prudence. L'enregistrement APNIC pour103.145.194.0/23montre l'assignation parent à CV Qorner Organizer, tandis qu'une entrée IDNIC plus spécifique pour 103.145.194.0/24 nomme Arupa. L'assignation parent d'APNIC pour103.145.196.0/23nomme CV Gweinity Elkalindo, tandis qu'un /24 IDNIC plus spécifique nomme Arupa. L'assignation parent d'APNIC pour103.145.198.0/23nomme CV Geowhan Multi Teknologi, tandis qu'un /24 IDNIC plus spécifique nomme Arupa.

Les recherches d'objets de route RADB renforcent la nature en couches du routage. L'ensemble d'origine AS136102inclut des entités décrites comme Arupa par Biznet, des entités enregistrées par procuration, des routes de transit iForte et plusieurs objets de route dérivés de RPKI. L'ensemble d'origine AS137286inclut Arupa par Biznet, des objets de route PGAS, des objets de route Level 3/Biznet et des entrées dérivées de RPKI. Ce n'est pas inhabituel pour un fournisseur qui utilise des opérateurs de transit et peut transporter des ressources en aval. Mais cela dit aux clients de ne pas supposer que chaque route est le même type d'actif.

La question client est pratique. Si une charge de travail utilise un espace d'adressage assigné par Arupa, qui maintient les objets de route, RPKI, DNS inverse et la portabilité des préfixes? Si une charge de travail utilise des ressources appartenant au client ou à des tiers originaires d'Arupa, à quelle vitesse ces routes peuvent-elles être déplacées vers un autre fournisseur après un litige contractuel ou une panne? Si Arupa change de fournisseurs en amont, quels préfixes sont couverts par des ROA valides et lesquels dépendent d'objets de route proxy maintenus par quelqu'un d'autre?

L'adressage et le routage font partie de la portabilité de l'hébergement, pas une trivialité comptable.

L'interconnexion est visible à OpenIXP et DCI-IX

PeeringDB montre deux profils réseau distincts d'Arupa.Arupa-JKT / AS136102porte l'alias Zettagrid Indonesia, indique que le profil a six préfixes IPv4, aucun préfixe IPv6, une bande passante de 1 à 5 Gbps, un ratio principalement entrant et une politique ouverte. Son attachement d'échange PeeringDB estOpenIXP / NiCE, avec l'adresse IPv4 218.100.27.158 et un port 1 Gbps.PT. Arupa Cloud Nusantara / AS137286liste trois préfixes IPv4, aucun préfixe IPv6 et une politique ouverte. Son attachement d'échange estDCI Indonesia DCI-IX, avec l'adresse IPv4 103.142.207.31 et un port 1 Gbps.

Ces enregistrements sont utiles car ils placent Arupa dans deux contextes d'interconnexion indonésiens différents. OpenIXP / NiCE est un profil d'échange indonésien avec un historique PeeringDB remontant à 2010. DCI-IX est listé à Bekasi, et lesdonnées d'attachement d'installation DCI-IXde PeeringDB le placent dans les installations DCI Indonesia, y compris JK1, JK2, JK3, JK5, H2-01, H2-02, E1 et E2. Le site de DCI décritDCI Indonesiacomme exploitant une plateforme de centre de données indonésienne, avec cinq emplacements, neuf centres de données, 132 MW de capacité brute et un écosystème de connectivité incluant des fournisseurs cloud, des institutions financières, des entreprises et des FAI.

Les enregistrements d'interconnexion ne sont pas les mêmes que les enregistrements de centre de données. Un port d'échange 1 Gbps peut supporter un peering local utile, une accessibilité de route et une diversité opérationnelle. Cela ne prouve pas que les clusters de calcul d'Arupa sont dans la même installation, que le port DCI-IX est le seul chemin vers ces clusters, qu'Arupa a de l'espace baie dans chaque installation DCI attachée à l'échange, ou qu'OpenIXP et DCI-IX servent des domaines de défaillance de production distincts.

Les enregistrements prouvent qu'Arupa est visible sur des tissus d'échange spécifiques; ils ne publient pas la topologie entre ces tissus et les charges de travail des clients.

La capacité hébergée n'est pas la même chose que le matériel installé

Les pages commerciales d'Arupa mettent à plusieurs reprises l'accent sur la flexibilité. Les serveurs virtuels peuvent être provisionnés rapidement; la capacité du centre de données virtuel peut évoluer sans investissement dans des serveurs physiques; le cloud privé offre une infrastructure dédiée; le cloud géré réduit la complexité opérationnelle. Ces affirmations sont normales pour les services cloud. L'information publique manquante est le pool physique qui sous-tend la promesse.

Pour le calcul, la distinction importante est entre la capacité installée et la capacité utilisable. La capacité installée est la somme des serveurs, des étagères de stockage, des ports de commutateurs, des licences d'hyperviseur et de l'alimentation disponible sur un site. La capacité utilisable est ce qui reste après avoir réservé une marge pour les pannes, la maintenance, le contrôle du voisin bruyant, les fenêtres de sauvegarde, les snapshots, la réplication, les systèmes de gestion et les engagements de croissance déjà vendus.

Un fournisseur peut avoir du CPU disponible dans des conditions normales et manquer encore de capacité résiliente suffisante après la perte d'un hôte, d'un nœud de stockage, d'une PDU de baie ou d'un chemin en amont.

Les pages publiques ne montrent pas le nombre de baies d'Arupa, la génération de serveurs, l'architecture de stockage, la politique de surréservation, le ratio d'hôtes de réserve, l'isolation de maintenance, la redondance du plan de gestion ou les objectifs de remplacement matériel. Cela ne signifie pas que l'entreprise en manque. Cela signifie que les acheteurs ne peuvent pas vérifier le modèle de capacité à partir de preuves publiques. Il en va de même pour les affirmations GPU-AI et Kubernetes.

Un service GPU est contraint par l'inventaire des cartes, la densité de puissance, le refroidissement, la pile de pilotes, le planificateur de cluster, le registre d'images, le débit de stockage et l'approvisionnement en pièces de rechange. Un service Kubernetes est contraint par la redondance du plan de contrôle, la conception du pool de nœuds, la capacité de l'équilibreur de charge, la sauvegarde etcd, les extractions d'images, le comportement CNI et les procédures de mise à niveau.

L'économie de l'hébergement crée une tension ici. Le client veut l'élasticité du cloud. Le fournisseur gagne sa marge en partageant l'infrastructure efficacement. La résilience consomme de la marge car elle laisse de la capacité inutilisée jusqu'à ce que quelque chose tombe en panne. C'est pourquoi la preuve ne peut pas être simplement « évolutif ». La preuve est un rapport de capacité montrant l'utilisation normale, la marge en mode dégradé et le plus grand composant dont la perte a été testée. Les pages publiques d'Arupa donnent l'offre. La preuve nécessaire pour un acheteur sérieux est le calendrier d'ingénierie.

La localité est un argument de vente, pas une réponse complète à la conformité

La souveraineté des données est centrale dans le récit actuel d'Arupa. La page de stockage d'objets indique que les données résident dans un centre de données indonésien de niveau III. Le partenariat Civo dit que le cloud souverain offre aux organisations indonésiennes une infrastructure locale alignée sur les besoins réglementaires. La page Indonésie de Civo dit que la région est hébergée à Jakarta, maintient les données sous juridiction indonésienne et s'aligne sur laloi indonésienne sur la protection des données personnelles. Le cadre des systèmes électroniques indonésiens est également ancré parPP 71 Tahun 2019, qui est le règlement cité dans l'ensemble de règles du fournisseur de systèmes électroniques indonésiens.

La localité est précieuse, surtout pour les clients réglementés. Elle peut réduire l'incertitude juridictionnelle, améliorer la latence, simplifier la gouvernance de l'accès aux données et donner aux clients un chemin de support local. Mais la localité n'est pas un contrôle complet.

Les clients ont toujours besoin de savoir quelles données sont stockées localement, quelles données de télémétrie ou de support quittent l'Indonésie, quelles équipes de support des fournisseurs peuvent accéder aux systèmes, comment les clés de chiffrement sont gérées, où les sauvegardes sont répliquées et ce qui se passe lors d'une réponse à un incident transfrontalier.

Le même point s'applique au « cloud souverain ». La souveraineté n'est pas seulement le pays nommé sur une page de région. C'est le langage contractuel, le contrôle opérationnel, l'accès au support, le processus juridique, la garde des clés, l'auditabilité, la divulgation des sous-traitants, la conception de la reprise après sinistre et les droits de sortie. Un cloud local peut être une option souveraine solide si ces contrôles sont explicites. Il peut aussi être un front-end local pour une pile internationale complexe si les contrôles ne sont pas définis.

L'avantage d'Arupa est qu'il peut combiner une présence de bureau indonésienne, des ingénieurs locaux, des ressources réseau indonésiennes et un support partenaire local. La question ouverte est de savoir si les contrats de service transforment cette présence locale en contrôles exécutoires. Un acheteur devrait demander des calendriers de localisation des données, des listes de sous-traitants/processeurs, des cartes d'emplacement de sauvegarde, des options de gestion des clés, des procédures de notification de violation, des preuves d'audit et un chemin d'exportation de données testé.

Premier chemin de défaillance: le contrat de baie ou de centre de données cède en premier

Le risque pour Arupa commence au niveau de la baie. Un client achète un centre de données virtuel, un référentiel de sauvegarde ou un pool de nœuds Kubernetes. En dessous, un ensemble d'armoires, d'alimentations, d'unités de refroidissement, de commutateurs et de baies de stockage doit continuer à fonctionner. Si Arupa possède le matériel mais loue l'espace du centre de données, le service dépend des performances de l'opérateur de l'installation sur l'alimentation, le refroidissement, l'accès et les mains à distance.

Si Arupa consomme une plateforme partenaire, le service dépend de la capacité, de la maintenance et du chemin d'escalade de ce fournisseur. Si Arupa héberge sur plusieurs sites, le client doit savoir quels produits sont véritablement multi-sites et lesquels n'ont que des options de sauvegarde ou de reprise après sinistre disponibles à un coût supplémentaire.

Les données publiques n'identifient pas l'installation de production pour chaque service. La visibilité DCI-IX ne prouve pas l'emplacement de la baie de production. La page de Civo mentionne un hébergement à Jakarta, mais pas le nom de l'installation ni la topologie détaillée. La page de stockage d'objets mentionne un centre de données indonésien de niveau III, mais pas si la plateforme de stockage est monosite, répliquée sur plusieurs sites ou protégée par un codage d'effacement sur un seul site. La page de contact d'Arupa donne un bureau, pas une salle de données.

Le test de défaillance de la baie devrait être explicite. Que se passe-t-il si un hôte hyperviseur tombe en panne? Que se passe-t-il si une étagère de stockage tombe en panne? Que se passe-t-il si une PDU de baie tombe en panne? Que se passe-t-il si l'installation a besoin d'une fenêtre de maintenance d'urgence? Combien de charges de travail clients peuvent être redémarrées ailleurs sans sursouscrire le cluster restant? Combien de temps une restriction d'accès au centre de données peut-elle retarder le remplacement d'un disque? Quels crédits de service s'appliquent, et quelles étapes de récupération relèvent d'un support au mieux?

Les clients devraient demander un calendrier de dépendance service par service. Il devrait montrer le nombre de sites de production, l'opérateur du centre de données, le niveau ou la certification de l'installation si revendiqué, la répartition des responsabilités pour les baies et l'alimentation, le SLA des mains à distance, l'inventaire matériel contrôlé par Arupa, la couverture de support du fournisseur et l'avis de maintenance planifiée. Sans cela, le mot « cloud » masque le premier domaine de défaillance au lieu de le supprimer.

Deuxième chemin de défaillance: la diversité du transit et de l'IX est utile mais incomplète

L'enregistrement de routage donne à Arupa une diversité au niveau logique. AS136102 est visible avec les chemins iForte et Biznet dans BGP.tools, tandis qu'AS137286 est visible avec les chemins Biznet et PGAS. PeeringDB place les deux ASN à des échanges différents: OpenIXP / NiCE pour AS136102 et DCI-IX pour AS137286. C'est mieux qu'un flux de transit isolé unique.

La question restante est la diversité physique. Deux ASN peuvent toujours partager un bâtiment, une salle d'interconnexion, un conduit de fibre métropolitain, un fournisseur optique, une fenêtre de maintenance en amont, un mainteneur d'objet de route ou un pare-feu client. Un client examinant la diversité des routes d'Arupa a besoin de trois cartes. La première est logique: les ASN en amont, les pairs IX, les politiques BGP, les préfixes acceptés et les préférences de basculement. La deuxième est optique: les noms des opérateurs, les types de remise, les circuits de longueur d'onde ou Ethernet et le premier fournisseur de réparation.

La troisième est physique: les entrées du bâtiment, les colonnes montantes, les conduits, le premier point de rencontre diversifié et les services publics partagés.

La séparation entre AS136102 et AS137286 pourrait être opérationnellement utile. Elle peut donner à Arupa des plans de routage distincts pour différents services, régions, groupes de clients ou plateformes partenaires. Elle peut également refléter des transitions historiques et des économies en amont différentes. Les données publiques ne nous permettent pas de décider quelle interprétation est correcte. Le test pratique est de savoir si une charge de travail client peut rester accessible si un ASN, un port IX, un fournisseur en amont ou un chemin d'installation est mis hors service.

L'absence d'IPv6 public est également une préoccupation pour les clients. Cela peut ne pas avoir d'importance pour de nombreuses charges de travail indonésiennes aujourd'hui, mais certains environnements réglementés, d'entreprise ou cloud-native nécessitent de plus en plus une double pile. RIPEstat et BGP.tools n'ont montré aucune origine IPv6 visible pour l'un ou l'autre ASN lors de la vérification. Si Arupa vend de la connectivité IPv6 aux clients, les acheteurs devraient demander si elle est fournie via d'autres ASN, tunnels, plateformes partenaires, adressage privé, ou si elle ne fait pas actuellement partie du service.

Troisième chemin de défaillance: la sauvegarde n'est aussi bonne que la bande passante de restauration et l'autorité

Les produits de sauvegarde peuvent échouer silencieusement. Une sauvegarde peut exister mais restaurer trop lentement. Une réplique peut être à jour mais incohérente. Un plan de reprise après sinistre peut dépendre d'un pare-feu, d'une clé de licence, d'un changement DNS, d'un fournisseur d'identité ou d'un montage de stockage qui n'est pas inclus dans le test de récupération.

Les pages de sauvegarde et de reprise d'Arupa sont commercialement claires: elles mettent l'accent sur la sauvegarde hybride, la sauvegarde cloud, le service géré, la protection contre les ransomwares, la réplication en temps réel, un RPO à l'échelle de la seconde et un RTO à l'échelle de la minute. Les preuves publiques ne montrent pas de tests de restauration.

Pour Arupa Backup, les questions difficiles sont la portée de la restauration et l'autorité. Si les données clients sont sur site et dans le cloud d'Arupa, qui décide quand basculer? Si un ransomware est suspecté, qui valide le point de récupération? Si le matériel local fait partie de l'offre, qui possède le stock de remplacement et le support? Si le client veut quitter Arupa après un incident, peut-il exporter les sauvegardes complètes dans un format standard sans attendre un ticket de service géré?

Si un référentiel de sauvegarde est hébergé dans un seul centre de données indonésien, qu'est-ce qui le protège d'une panne à l'échelle de l'installation?

Pour la réplication de type Zerto, les variables clés sont l'historique du journal, la bande passante, la fidélité de l'ordre d'écriture, l'isolation du réseau de test, le retour arrière et le mappage des dépendances applicatives. Une seule VM peut récupérer rapidement. Un service métier composé d'une base de données, d'un serveur d'applications, d'un stockage de fichiers, d'une identité, d'un VPN et de dépendances d'API tierces peut ne pas récupérer. La page publique ne fait pas la distinction entre la capacité du produit et la validation de récupération spécifique au client.

La meilleure preuve serait des preuves de test anonymisées. Arupa pourrait publier des benchmarks de restauration pour des tailles de données courantes, des exercices de basculement mesurés, le retard de réplication maximal supporté en cas de congestion, les options d'immuabilité de la sauvegarde, les procédures de test de récupération exécutées par le client et un calendrier montrant qui peut approuver un basculement de production. Ces divulgations ne révéleraient pas les secrets des clients. Elles montreraient que la promesse de récupération est plus qu'un dépliant.

Quatrième chemin de défaillance: le travail de support et la migration sont aussi des capacités

Arupa vend une expertise locale dans le cadre du produit. La page à propos met l'accent sur les ingénieurs locaux. LeManaged Cloud Servicedit qu'Arupa gère la mise en œuvre, la maintenance et la sécurité afin que les partenaires puissent se concentrer sur leur activité. LeCloud Migrationdit qu'il déplace les charges de travail depuis le cloud public, le cloud privé ou les environnements hybrides avec une approche structurée, à faible risque, une conformité locale et des coûts transparents. LeImplementation Supportmet l'accent sur l'exécution professionnelle, la réduction des risques et le support technique local.

C'est un véritable avantage de service dans un marché où de nombreux clients ne veulent pas opérer eux-mêmes l'infrastructure cloud. Mais le travail de support est aussi une ressource finie. Lors d'une migration normale, la même équipe d'experts peut guider la découverte, la transition, l'optimisation et la documentation. Lors d'un incident régional, cette même équipe peut être sollicitée par de nombreux clients à la fois.

Si le produit dépend d'un support à forte interaction, les clients devraient demander comment Arupa priorise les incidents, combien d'ingénieurs couvrent les escalades en dehors des heures ouvrables, quelles tâches sont automatisées et ce qui se passe si un fournisseur clé doit également rejoindre le pont de conférence.

La migration crée une autre forme d'enfermement. Arupa peut aider les clients à migrer dans son environnement; cela ne prouve pas automatiquement que les clients peuvent partir rapidement. La sortie dépend des formats de données, de l'exportation VM, du réadressage réseau, du DNS, de la compatibilité du stockage d'objets, de la récupération de sauvegarde, de la portabilité des licences, de la documentation des dépendances et de la bande passante sortante. Si la seule sauvegarde actuelle d'un client se trouve dans le service géré d'Arupa, quitter le fournisseur lors d'un litige ou d'une panne peut être plus difficile que d'entrer.

Les pages publiques doivent donc être lues comme des invitations de service, pas comme des garanties de sortie. Un client sérieux devrait demander des manuels de migration et de migration inverse avant de signer. La demande n'est pas contradictoire. C'est ainsi qu'un fournisseur de cloud prouve sa confiance dans ses propres opérations: il peut aider un client à entrer parce qu'il sait aussi comment le client pourrait récupérer ou sortir.

Le client affecté est souvent le client d'un partenaire

Le positionnement d'Arupa en tant que partenaire modifie le rayon d'impact. Un client direct d'entreprise peut savoir qu'il achète du calcul, de la sauvegarde ou un service géré Arupa. Un client en aval d'un MSP, d'un intégrateur système ou d'un revendeur peut ne faire l'expérience d'Arupa qu'indirectement, via une application gérée, un portail de sauvegarde, une clause de reprise après sinistre ou un bundle cloud privé vendu sous une autre relation d'entreprise. Lapage du programme partenaireest explicite: Arupa veut des MSP, intégrateurs systèmes, revendeurs et partenaires ISV dans l'écosystème. Ce modèle a du sens commercial. Cela signifie également que la communication sur les incidents doit transiter par plus d'une organisation.

Lors d'une simple panne d'hébergement, le propriétaire du service et le fournisseur d'infrastructure sont la même entreprise. Dans une pile cloud pilotée par des partenaires, le client final affecté peut appeler le revendeur, le revendeur peut appeler Arupa, Arupa peut avoir besoin d'un opérateur de centre de données, d'un opérateur de télécoms, de Civo, MinIO, VMware/Broadcom, Veeam, Zerto ou un autre fournisseur pour agir, et le client peut ne pas savoir quelle dépendance est contraignante. Ce n'est pas une critique de la vente par canal. C'est un rappel que le séquencement du support est une contrainte de capacité.

Lorsque de nombreux partenaires appellent pendant le même incident, le banc d'ingénierie d'Arupa, le triage des tickets, les droits d'escalade des fournisseurs et les modèles de communication avec les clients font partie de l'infrastructure.

La facturation peut aussi faire partie du chemin de défaillance. Les fournisseurs de cloud traitent souvent le calcul, le stockage, la rétention des sauvegardes, les adresses IP, le support géré et le trafic sortant comme des éléments facturables séparés. La page Indonésie de Civo met l'accent sur des prix prévisibles pour Kubernetes géré et compare les coûts mensuels des ressources avec les hyperscalers mondiaux. La page de migration d'Arupa dit que les clients bénéficient de la transparence des coûts. Ce sont des signaux positifs.

Mais les clients ont toujours besoin de savoir comment les frais se comportent lors des tests de reprise après sinistre, d'une récupération prolongée, d'une restauration d'urgence, de l'exportation de données, d'un échec de migration, d'une suspension de facturation, de l'expiration des droits de licence ou de la résiliation du contrat. Un service de sauvegarde techniquement disponible mais financièrement coûteux à récupérer peut encore être un mauvais outil de récupération.

Le stock de pièces de rechange est la troisième contrainte silencieuse. Les pages d'Arupa décrivent une expertise locale et une mise en œuvre gérée, mais ne divulguent pas les serveurs de rechange, les disques, les contrôleurs, les optiques, les pare-feu, les appareils de sauvegarde ou les cartes GPU. Un fournisseur peut avoir d'excellents ingénieurs et attendre encore un RMA du fournisseur, un processus douanier, une autorisation de partenaire ou un créneau d'accès à l'installation.

Les clients qui achètent un cloud privé ou du matériel de sauvegarde sur site devraient demander si les pièces de rechange sont détenues en Indonésie, si Arupa les possède, si le client les possède et si le SLA change lorsque la panne est un problème d'approvisionnement du fournisseur plutôt qu'un problème de ticket de support.

La question pratique de diligence raisonnable n'est donc pas simplement « Arupa répond-elle aux tickets? » C'est « qui d'autre doit agir avant que mon service soit restauré, et que se passe-t-il si la relation commerciale est tendue alors que l'incident technique est toujours ouvert? » Un fournisseur favorable aux canaux gagne la confiance en rendant ces transferts visibles.

Il devrait définir les niveaux de gravité, les obligations de notification des clients par rapport aux partenaires, l'autorité d'escalade des fournisseurs, les contacts en dehors des heures ouvrables, les règles de coût de restauration, les frais d'exportation de données, les hypothèses de stock de rechange et l'assistance à la sortie avant l'incident. Pour Arupa, dont la thèse publique repose fortement sur le soutien local et la réussite des partenaires, ces détails opérationnels ne sont pas secondaires. Ils sont la partie du cloud que les clients ressentiront en premier lorsque la capacité échoue.

Quelles preuves amélioreraient l'évaluation

Arupa pourrait renforcer considérablement l'image opérationnelle publique sans révéler de données clients sensibles. Premièrement, elle pourrait publier une matrice de localisation des services de haut niveau: quels produits fonctionnent dans quelle région ou classe d'installation indonésienne, lesquels sont monosite, lesquels sont répliqués, lesquels ont une reprise après sinistre facultative et lesquels utilisent des plateformes partenaires. La matrice n'a pas besoin de montrer le nombre de baies. Elle devrait séparer les emplacements de bureau, de registre, d'échange, de calcul de production et de sauvegarde.

Deuxièmement, elle pourrait publier un résumé de capacité et de résilience pour chaque famille de produits. Pour le calcul, cela signifie la redondance du cluster d'hyperviseurs, la méthode de protection du stockage, la marge normale, la marge en mode dégradé et la politique de maintenance. Pour la sauvegarde, cela signifie l'emplacement du référentiel, les options de rétention, l'immuabilité, la bande passante de restauration et les temps de restauration testés.

Pour le stockage d'objets, cela signifie la politique de placement des données, le modèle de durabilité, les limites de compatibilité S3, la gestion des clés et la procédure d'exportation. Pour Kubernetes, cela signifie la conception du plan de contrôle, le domaine de défaillance du pool de nœuds, le modèle d'équilibreur de charge, la fenêtre de mise à niveau et la sauvegarde du cluster.

Troisièmement, elle pourrait concilier le récit réseau en termes conviviaux. Pourquoi AS136102 et AS137286 sont-ils séparés? Quels services utilisent quel ASN? L'un d'eux fournit-il l'IPv6 client? OpenIXP et DCI-IX sont-ils utilisés pour le trafic de production, le trafic de gestion, l'optimisation du peering ou les chemins de sauvegarde? Quels préfixes appartiennent à Arupa, lesquels sont des préfixes clients ou en aval, et comment fonctionne la maintenance RPKI/objet de route?

Quatrièmement, elle pourrait publier des exemples de procédures d'incident et de migration. Cela devrait inclure l'escalade du support, la notification du client, l'avis de maintenance, les options d'exportation de données, la continuité de facturation lors d'une panne et les conditions dans lesquelles Arupa ou le client peuvent initier un basculement. Les fournisseurs de cloud les plus crédibles rendent visibles les procédures ennuyeuses, car c'est là que réside la confiance.

Le score de preuve actuel est donc mitigé plutôt que négatif. La largeur des produits publics d'Arupa, la visibilité réseau et le positionnement local sont plus forts que ceux de nombreux petits fournisseurs d'hébergement. La divulgation de la capacité physique est plus faible que la largeur des services. C'est précisément là que la diligence du client devrait se concentrer.

Un cloud local utile dépend de contraintes visibles

L'Indonésie a besoin de plus d'options d'infrastructure locale crédibles. Toutes les charges de travail ne devraient pas être forcées dans un modèle hyperscale mondial, et toutes les entreprises ne veulent pas assembler elles-mêmes la sauvegarde, Kubernetes, le stockage, la migration et le support de conformité. Le profil public d'Arupa répond à cette demande. Il combine vente et support locaux, calcul cloud, sauvegarde, stockage d'objets, reprise après sinistre, distribution MinIO, signaux d'écosystème Broadcom/VMware et positionnement cloud souverain Civo.

Il dispose également de ressources de routage indonésiennes actives qui montrent que l'entreprise n'est pas une coquille vide avec seulement un dépliant produit.

Le prochain seuil n'est pas plus de noms de produits. C'est la visibilité des contraintes. Les clients achetant de la capacité hébergée ont besoin de savoir où se trouve la capacité, quelle baie elle occupe, quels fournisseurs en amont la transportent, quelle marge survit à une panne, qui détient les pièces de rechange, qui peut entrer dans l'installation, quels tests de récupération ont été réussis et comment les données peuvent être déplacées si la relation ou la plateforme échoue. Ces questions n'affaiblissent pas le business case d'Arupa. Elles le rendent investissable pour les clients dont les charges de travail comptent.

La meilleure thèse publique d'Arupa est que les entreprises indonésiennes peuvent acheter une capacité cloud locale avec un support local. Ses preuves publiques soutiennent cette thèse aux niveaux de l'entreprise, des produits et du routage. Elles ne soutiennent pas encore pleinement une affirmation vérifiable indépendamment de résilience multi-sites. Jusqu'à ce que davantage de preuves sur les installations et la reprise soient publiées, PT.

Arupa Cloud Nusantara doit être traité comme un fournisseur indonésien opérationnel de services cloud et technologiques dont la valeur pour le client dépend des calendriers privés derrière ses promesses cloud publiques: racks, transit, stock de pièces de rechange, main-d'œuvre de support, tests de sauvegarde et droits de migration.