Résumé
- PT. Arupa Cloud Nusantara n’est pas une simple marque d’hébergement web. Ses propres pages décrivent un agrégateur technologique 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 public actuelle au South Quarter Tower A à Jakarta Sud.
- L’entreprise vend une capacité hébergée à travers plusieurs couches: Arupa Compute, Virtual centres de données, Virtual Server, Private Cloud, Backup, Arupa Backup, reprise après sinistre Zerto, stockage objet, cloud managé, migration cloud et, via une annonce Civo de 2026, un cloud Kubernetes souverain destiné aux charges de travail indonésiennes.
- Les preuves réseau sont visibles mais étroites. APNIC identifie AS136102 et AS137286 comme des ressources de PT. Arupa Cloud Nusantara; RIPEstat a vu les deux ASN globalement visibles en IPv4 le 11 juillet 2026; PeeringDB montre un port OpenIXP / NiCE de 1 Gbps pour AS136102 et un port DCI-IX de 1 Gbps 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 racks, les limites des baux des centres de données, la topologie d’alimentation et de refroidissement, la politique de pièces de rechange matérielles, les tests de restauration des sauvegardes, 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 du cloud est réelle, mais les questions difficiles se situent sous la marque
Arupa est un bon exemple de la raison pour laquelle les fournisseurs de cloud de petite et moyenne taille doivent être analysés sous deux angles simultanément. Le premier angle est commercial: qu’offre le fournisseur et à qui s’adresse-t-il? De ce point de vue, l’entreprise a une empreinte publique bien plus solide 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, de données et de cybersécurité. Sapage à proposindique qu’Arupa Cloud Nusantara opère en tant qu’agrégateur technologique 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 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 second angle est physique: quels équipements, bâtiments, routes, personnes et contrats rendent la promesse commerciale vraie lors d’une mauvaise journée? 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 la salle du centre de données, l’empreinte en racks, la conception électrique, le point de remise en amont, le stock de matériel ou le chemin d’escalade du support. Un acheteur peut voir les catégories de services.
Il ne peut pas retracer entièrement la chaîne de dépendance depuis une facture Arupa jusqu’à une alimentation électrique, un commutateur, une étagère de disques, un cluster d’hyperviseurs, un dépôt de sauvegarde et un responsable d’incident 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 d’enregistrements d’interconnexion publics. Elle dispose également d’une adresse de bureau officielle actuelle et de plusieurs annonces de produits récentes. La conclusion correcte est plus précise: Arupa dispose de suffisamment de preuves publiques pour être considérée comme une entreprise indonésienne opérationnelle de cloud et de services, 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 licence logicielle ou d’un partenaire de migration? »
Identité, adresses et la frontière Zettagrid
L’identité publique d’Arupa présente plusieurs étiquettes qui se chevauchent. Les enregistrements APNIC pourAS136102etAS137286nomment PT. Arupa Cloud Nusantara, la décrivent comme un membre corporatif / direct d’IDNIC et placent l’ancienne adresse de registre à Eightyeight@Kasablanka Office Tower, 18e étage, Menteng Dalam, Tebet, Jakarta Selatan. 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 indique plutôt South Quarter, Jalan R.A. Kartini Kav. 8, Tower A, 9e étage, Cilandak Barat, Jakarta Sud, avec des adresses e-mail 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 cloud, la rigueur des adresses est importante car les clients doivent savoir quel site est un bureau, lequel est une adresse d’enregistrement réseau et lequel contient les équipements de production. Les pages de bureau publiques d’Arupa ne prétendent pas que le bureau de South Quarter soit le centre de données. APNIC et PeeringDB identifient l’entreprise et ses ressources de numérotation, pas l’empreinte physique des racks.
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. Lepost de remise du prix partenaire Broadcomfait référence à PT Arupa Cloud Nusantara en tant que Zettagrid Indonesia et indique qu’elle a remporté un prix 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 opérée par Zettagrid, de la colocation, des clouds partenaires, ou un mélange de ces couches.
Ce qu’Arupa vend: le calcul d’abord, mais pas seulement
Lapage Arupa 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 des capacités de serveur, de stockage et de 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 quelques minutes.Private Cloudest présenté comme une infrastructure cloud dédiée pour une organisation, avec une isolation renforcée 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 en cours d’exécution, d’une accessibilité réseau, de snapshots ou sauvegardes et d’un chemin d’évolution. Un client de centre de données virtuel a besoin de pools de ressources, d’isolation des locataires, 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 explicites de remplacement du matériel et d’un modèle de propriété clair pour les licences et les appliances.
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. Lapage Backupindique 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 exploitation gérée. Un article de lancement distinct indique qu’Arupa 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 du matériel sur site client, 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 de l’ordre de la seconde est une déclaration de réplication; il dépend du débit d’écriture des applications, de la qualité des liaisons, du retard de réplication, de la latence de stockage et de la détection des pannes. Un RTO de l’ordre 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 applicatives, des systèmes d’identité, de la cohérence des bases de données et de l’autorisation du support.
Les pages produits publiques disent ce que le client devrait recevoir, mais pas les preuves par les tests qui montrent qu’un client spécifique peut le recevoir.
Le stockage objet et Kubernetes élargissent la carte des dépendances
L’histoire du stockage d’Arupa ne se limite pas à la sauvegarde des VM. Sapage Arupa 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 Tier III avec chiffrement et langage de conformité réglementaire. Un article ultérieur indique qu’Arupa est unrevendeur MinIO agréé 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-natives.
Cela aide à expliquer la position d’Arupa sur le marché. Elle ne se contente pas de vendre des créneaux de calcul génériques. Elle assemble du cloud, de la sauvegarde, des logiciels de stockage, des licences et une implémentation locale. Cela peut être précieux pour une entreprise indonésienne qui souhaite un partenaire local plutôt qu’un cloud en libre-service distant. Mais le stockage objet soulève également des tests opérationnels différents.
Les questions importantes sont la durabilité, la politique de codage d’effacement ou 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 la sortie de données lors d’une migration ou d’un incident. Une fiche technique qui dit « stockage objet » 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 d’implémentation et une aide concernant les besoins réglementaires. Lapage Indonésiede Civo dé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 managé, du calcul, des bases de données managées, des équilibreurs de charge, un hébergement local et un 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 un partenariat produit. Elles sont plus faibles pour les questions physiques que cet article teste. Elles ne publient pas le nombre de racks derrière la région de Jakarta, l’identité de l’installation sur la page publique, la conception de basculement du site, la combinaison d’opérateurs, le pool de pièces de rechange matérielles, ni si le rôle d’Arupa est revendeur, opérateur, support de première ligne, partenaire d’implémentation, ou une combinaison qui varie selon le client.
L’interprétation prudente est que le partenariat élargit l’offre cloud-native d’Arupa, tout en laissant la conception du site sous-jacent et de la récupération à vérifier dans les documents contractuels du client.
Les deux ASN montrent un réseau opérationnel, pas une carte cloud complète
L’enregistrement de routage donne à Arupa l’un de ses ancrages publics les plus solides. APNIC identifieAS136102comme IDNIC-ARUPA-AS-ID et enregistre des politiques d’importation depuis AS24538 et AS7717, des exportations vers AS23949 et AS7717, et une route par défaut vers AS24538. Elle identifieAS137286sous le même nom AS, avec des importations depuis AS7717, AS17451 et AS56258, des exportations vers les trois mêmes ASN, et une route par défaut vers AS17451. Les enregistrements de contact et d’abus renvoient à Arupa.
Lesdonnées d’état de routage de RIPEstat pour AS136102montraient, lors de la vérification du 11 juillet 2026, 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 des 327 pairs IPv4 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 appairé avec quatre autres réseaux et ayant deux opérateurs en amont, listant PT iForte Global Internet et Biznet Networks comme amonts. Il présenteAS137286comme appairé avec trois autres réseaux et ayant deux opérateurs en amont, listant Biznet Networks et PT PGAS Telekomunikasi Nusantara comme amonts. 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 revendications 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 cloud peut héberger les charges de travail de ses clients derrière des ASN partenaires, des interconnexions privées, des services de tunnel, des régions de cloud public, des réseaux de contenu ou des préfixes appartenant aux clients. Inversement, un ASN peut originer de l’espace d’adressage aval ou client qui n’est pas le pool propre du fournisseur. Les preuves AS montrent qu’Arupa a un routage Internet actif. Elles ne révèlent 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
Les preuves des préfixes ajoutent une nuance importante. APNIC attribue103.90.248.0/22à PT. Arupa Cloud Nusantara comme espace portable attribué, et les enregistrements APNIC de103.10.148.0/22et49.128.188.0/22sont des ressources portables allouées à Arupa. Ces trois blocs constituent des preuves solides de ressources d’entreprise.
D’autres espaces originaires visibles nécessitent plus de prudence. L’enregistrement APNIC pour103.145.194.0/23montre l’attribution parente à CV Qorner Organizer, tandis qu’une entrée plus spécifique IDNIC 103.145.194.0/24 nomme Arupa. L’attribution parente103.145.196.0/23d’APNIC nomme CV Gweinity Elkalindo, tandis qu’un /24 plus spécifique IDNIC nomme Arupa. L’attribution parente103.145.198.0/23d’APNIC nomme CV Geowhan Multi Teknologi, tandis qu’un /24 plus spécifique IDNIC nomme Arupa.
Les recherches d’objets de route RADB renforcent la nature multicouche du routage. L’ensemble d’origine AS136102inclut des objets décrits comme Arupa par Biznet, des objets enregistrés par proxy, des routes de clients de transit iForte et plusieurs objets de route dérivés 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 RPKI. Cela n’est pas inhabituel pour un fournisseur qui utilise des opérateurs de transit et peut transporter des ressources en aval. Mais cela indique aux clients de ne pas supposer que chaque route est le même type d’actif.
La question du client est pratique. Si une charge de travail utilise un espace d’adressage attribué par Arupa, qui maintient les objets de route, RPKI, le DNS inverse et la portabilité des préfixes? Si une charge de travail utilise des ressources appartenant au client ou à un tiers originaires par Arupa, à quelle vitesse ces routes peuvent-elles être transférées vers un autre fournisseur après un litige contractuel ou une panne? Si Arupa change d’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 d’une trivialité comptable.
L’interconnexion est visible chez OpenIXP et DCI-IX
PeeringDB montre deux profils réseau Arupa distincts.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 rattachement d’échange PeeringDB estOpenIXP / NiCE, avec l’adresse IPv4 218.100.27.158 et un port de 1 Gbps.PT. Arupa Cloud Nusantara / AS137286liste trois préfixes IPv4, aucun préfixe IPv6 et une politique ouverte. Son rattachement d’échange estDCI Indonesia DCI-IX, avec l’adresse IPv4 103.142.207.31 et un port de 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 répertorié à Bekasi, et lesdonnées de rattachement des installations DCI-IXde PeeringDB le placent dans les installations de DCI Indonesia, y compris JK1, JK2, JK3, JK5, H2-01, H2-02, E1 et E2. Le propre site de DCI décritDCI Indonesiacomme exploitant une plateforme de centres de données indonésiens, 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 de 1 Gbps peut prendre en charge un peering local utile, une joignabilité des routes et une diversité opérationnelle. Il ne prouve pas que les clusters de calcul d’Arupa se trouvent dans la même installation, que le port DCI-IX est le seul chemin vers ces clusters, qu’Arupa dispose d’espace rack 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 fabrics d’échange spécifiques; ils ne publient pas la topologie entre ces fabrics 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 soulignent à plusieurs reprises la flexibilité. Les serveurs virtuels peuvent être provisionnés rapidement; la capacité de centre de données virtuel peut évoluer sans investissement dans des serveurs physiques; le cloud privé offre une infrastructure dédiée; le cloud managé 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 commutateur, des licences d’hyperviseur et de la puissance 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 des voisins bruyants, 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 en conditions normales et néanmoins manquer de capacité résiliente suffisante après avoir perdu un hôte, un nœud de stockage, une PDU de rack ou un chemin en amont.
Les pages publiques ne montrent pas le nombre de racks d’Arupa, la génération des serveurs, l’architecture de stockage, la politique de sursouscription, le ratio d’hôtes de rechange, l’isolation pour la maintenance, la redondance du plan de gestion ou les objectifs de remplacement du 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 des preuves publiques. Il en va de même pour les affirmations sur le GPU-AI et Kubernetes.
Un service GPU est contraint par l’inventaire des cartes, la densité de puissance, le refroidissement, la pile de pilotes, l’ordonnanceur 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 des pools de nœuds, la capacité des équilibreurs de charge, la sauvegarde etcd, les pulls d’images, le comportement CNI et les procédures de mise à niveau.
L’économie de l’hébergement crée une pression ici. Le client veut de l’élasticité cloud. Le fournisseur gagne sa marge en partageant efficacement l’infrastructure. 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 seulement « évolutive ». 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 de conformité complète
La souveraineté des données est au cœur du récit actuel d’Arupa. La page de stockage objet indique que les données se trouvent dans un centre de données indonésien Tier III. Le partenariat Civo indique que le cloud souverain donne aux organisations indonésiennes une infrastructure locale alignée sur les besoins réglementaires. La page Indonésie de Civo indique que la région est hébergée à Jakarta, conserve 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é par lePP 71 Tahun 2019, qui est la réglementation citée dans l’ensemble des règles relatives aux fournisseurs de systèmes électroniques indonésiens.
La localité est précieuse, en particulier 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 offrir aux clients un chemin de support local. Mais la localité n’est pas un contrôle complet.
Les clients doivent encore savoir quelles données sont stockées localement, quelles métadonné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 aux incidents transfrontalière.
Le même point s’applique au « cloud souverain ». La souveraineté ne se résume pas au pays indiqué sur une page de région. C’est le langage contractuel, le contrôle opérationnel, l’accès au support, la procédure légale, 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 une façade locale vers une pile internationale complexe si les contrôles ne sont pas définis.
L’avantage d’Arupa est qu’elle 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 processeurs/sous-traitants, des cartes des emplacements 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 des données testé.
Premier chemin de défaillance: le contrat de rack ou d’installation cède en premier
Le risque pour Arupa commence au niveau du rack. Un client achète un centre de données virtuel, un dépôt de sauvegarde ou un pool de nœuds Kubernetes. En dessous, un ensemble d’armoires, d’alimentations électriques, 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 de la performance de l’opérateur de l’installation en matière d’alimentation, de refroidissement, d’accès et d’intervention à 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 du rack de production. La page de Civo parle d’hébergement à Jakarta, mais pas du nom de l’installation ni de la topologie détaillée. La page de stockage objet mentionne un centre de données indonésien Tier III, mais pas si la plateforme de stockage est mono-site, répliquée sur plusieurs sites ou protégée par un codage d’effacement au sein d’un seul site. La page de contact d’Arupa donne un bureau, pas une salle de données.
Le test de défaillance du rack 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 rack tombe en panne? Que se passe-t-il si l’installation nécessite 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 un remplacement de disque? Quels crédits de service s’appliquent et quelles étapes de récupération relèvent du support au mieux?
Les clients devraient demander un calendrier de dépendances service par service. Il devrait indiquer le nombre de sites de production, l’opérateur du centre de données, le niveau ou la certification de l’installation si revendiqué, le partage des responsabilités en matière de rack et d’alimentation, le SLA d’intervention à distance, l’inventaire du matériel contrôlé par Arupa, la couverture du support des fournisseurs et le pré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é de transit et d’IX est utile mais incomplète
L’enregistrement de routage donne à Arupa une diversité au niveau logique. AS136102 est visible avec des 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. Cela vaut mieux qu’un seul flux de transit isolé.
La question restante est la diversité physique. Deux ASN peuvent encore 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’objets de route ou un pare-feu client. Un client qui examine la diversité de route 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 raccordement, les longueurs d’onde ou les circuits Ethernet, et le premier fournisseur de restauration. La troisième est physique: les entrées du bâtiment, les colonnes montantes, les conduits, le premier point de rencontre diversifié et les travaux publics partagés.
La séparation entre AS136102 et AS137286 pourrait être utile sur le plan opérationnel. 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 d’amont différentes. Les données publiques ne permettent pas de déterminer quelle interprétation est correcte. Le test pratique est de savoir si une charge de travail cliente peut rester joignable si un ASN, un port IX, un amont ou un chemin d’installation est retiré du service.
L’absence d’IPv6 publique est également un problème pour le client. 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-natifs exigent de plus en plus une double pile. RIPEstat et BGP.tools n’ont pas montré d’origine IPv6 visible pour l’un ou l’autre ASN lors de la vérification. Si Arupa vend une connectivité client IPv6, les acheteurs devraient demander si elle est fournie via d’autres ASN, des tunnels, des plateformes partenaires, un adressage privé, ou si elle ne fait pas actuellement partie du service.
Troisième chemin de défaillance: la sauvegarde ne vaut que par la bande passante de restauration et l’autorité
Les produits de sauvegarde peuvent échouer de manière silencieuse. Une sauvegarde peut exister mais se 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 après sinistre 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 de l’ordre de la seconde et un RTO de l’ordre de la minute. Les preuves publiques ne montrent pas de tests de restauration.
Pour Arupa Backup, les questions difficiles sont la portée et l’autorité de la restauration. Si les données du client 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 souhaite quitter Arupa après un incident, peut-il exporter des sauvegardes complètes dans un format standard sans attendre un ticket de service géré?
Si un dépôt de sauvegarde est hébergé dans un seul centre de données indonésien, qu’est-ce qui le protège d’une indisponibilité à 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 des écritures, l’isolation du réseau de test, la restauration après basculement et la cartographie des dépendances applicatives. Une seule VM peut récupérer rapidement. Un service métier composé de base de données, serveur d’application, stockage de fichiers, identité, VPN et dépendances d’API tierces peut ne pas récupérer. La page publique ne distingue pas une capacité produit d’une validation de récupération spécifique au client.
La meilleure preuve serait des preuves de tests 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é des sauvegardes, les procédures de test de récupération exécutées par le client et un calendrier indiquant qui peut approuver un basculement en production. Ces divulgations ne révéleraient pas les secrets des clients. Elles montreraient que la promesse de récupération est plus qu’une brochure.
Quatrième chemin de défaillance: la main-d’œuvre de support et la migration sont aussi des capacités
Arupa vend l’expertise locale comme partie intégrante du produit. La page à propos met l’accent sur les ingénieurs locaux. LeService Cloud Managéindique qu’Arupa gère l’implémentation, la maintenance et la sécurité afin que les partenaires puissent se concentrer sur leur activité. LaMigration Cloudindique qu’elle déplace les charges de travail depuis des environnements de cloud public, cloud privé ou hybride avec une approche structurée et à faible risque, une conformité locale et des coûts transparents. LeSupport d’Implémentationmet l’accent sur l’exécution professionnelle, la réduction des risques et un support technique local.
Il s’agit d’un véritable avantage de service sur un marché où de nombreux clients ne souhaitent pas exploiter eux-mêmes l’infrastructure cloud. Mais la main-d’œuvre de support est aussi une ressource limitée. Lors d’une migration normale, la même équipe d’experts peut guider la découverte, le basculement, l’optimisation et la documentation. Lors d’un incident régional, la même équipe peut être sollicitée par de nombreux clients à la fois.
Si le produit dépend d’un support haut de gamme, les clients devraient demander comment Arupa priorise les incidents, combien d’ingénieurs couvrent l’escalade 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 un autre type d’enfermement. Arupa peut aider les clients à migrer vers son environnement; cela ne prouve pas automatiquement que les clients peuvent en sortir rapidement. La sortie dépend des formats de données, de l’exportation des VM, du réadressage réseau, du DNS, de la compatibilité du stockage objet, de la récupération des sauvegardes, de la portabilité des licences, de la documentation des dépendances et de la bande passante de sortie. Si la seule sauvegarde actuelle d’un client se trouve dans le service géré d’Arupa, quitter le fournisseur pendant un litige ou une panne peut être plus difficile que d’y entrer.
Les pages publiques doivent donc être lues comme des invitations au service, et non comme des garanties de sortie. Un client sérieux devrait demander des runbooks de migration et de migration inverse avant de signer. La demande n’est pas conflictuelle. C’est ainsi qu’un fournisseur cloud prouve sa confiance dans ses propres opérations: il peut aider un client à entrer parce qu’il sait également 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 entreprise direct 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 subir Arupa qu’indirectement, via une application gérée, un portail de sauvegarde, une clause de reprise après sinistre ou un lot de cloud privé vendu sous la relation d’une autre entreprise. Lapage programme partenaireest explicite sur le fait qu’Arupa souhaite des MSP, intégrateurs systèmes, revendeurs et partenaires ISV dans l’écosystème. Ce modèle est commercialement sensé. Il signifie également que la communication en cas d’incident doit passer par plus d’une organisation.
Dans une panne d’hébergement simple, le propriétaire du service et le fournisseur d’infrastructure sont la même entreprise. Dans une pile cloud pilotée par les 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 télécom, de Civo, MinIO, VMware/Broadcom, Veeam, Zerto ou d’un autre fournisseur pour agir, et le client peut ne pas savoir quelle dépendance est contraignante. Ce n’est pas une critique des ventes par canal. C’est un rappel que le séquencement du support est une contrainte de capacité.
Lorsque de nombreux partenaires appellent lors du 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 client deviennent partie intégrante de l’infrastructure.
La facturation peut également faire partie du chemin de défaillance. Les fournisseurs cloud traitent souvent le calcul, le stockage, la rétention des sauvegardes, les adresses IP, le support géré et la sortie de données comme des éléments facturables distincts. La page Indonésie de Civo met l’accent sur une tarification prévisible pour Kubernetes managé et compare les coûts mensuels des ressources avec les hyperscalers mondiaux. La page de migration d’Arupa indique que les clients bénéficient de transparence des coûts. Ce sont des signaux positifs.
Mais les clients doivent encore savoir comment les frais se comportent pendant les tests de reprise après sinistre, la récupération prolongée, la restauration d’urgence, l’exportation de données, l’échec de migration, la suspension de facturation, l’expiration des droits de licence ou la résiliation du contrat. Un service de sauvegarde techniquement disponible mais financièrement coûteux à récupérer peut toujours être un mauvais outil de récupération.
Le stock de matériel est la troisième contrainte silencieuse. Les pages d’Arupa décrivent l’expertise locale et l’implémentation gérée, mais ne divulguent pas les serveurs, disques, contrôleurs, optiques, pare-feu, appliances de sauvegarde ou cartes GPU de rechange. Un fournisseur peut avoir d’excellents ingénieurs et néanmoins attendre un RMA fournisseur, un processus douanier, une autorisation de partenaire ou un créneau d’accès à l’installation.
Les clients qui achètent du cloud privé ou du matériel de sauvegarde sur site devraient demander si les pièces de rechange sont conservées 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 n’est donc pas seulement « Arupa répond-elle aux tickets? » C’est « qui d’autre doit agir avant que mon service ne soit rétabli, et que se passe-t-il si la relation commerciale est tendue alors que l’incident technique est toujours ouvert? » Un fournisseur favorable au canal gagne la confiance en rendant ces transferts visibles.
Il devrait définir les niveaux de gravité, les obligations de notification client contre partenaire, 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 remplacement et l’assistance à la sortie avant l’incident. Pour Arupa, dont la thèse publique repose fortement sur le support local et le succès 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é fera défaut.
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 mono-site, lesquels sont répliqués, lesquels ont une reprise après sinistre optionnelle et lesquels utilisent des plateformes partenaires. La matrice n’a pas besoin d’indiquer le nombre de racks. Elle doit 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 la capacité et de la 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 dépôt, les options de rétention, l’immuabilité, la bande passante de restauration et les temps de restauration testés.
Pour le stockage objet, 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 des pools 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 réconcilier le récit réseau en des termes adaptés au client. Pourquoi AS136102 et AS137286 sont-ils séparés? Quels services utilisent quel ASN? L’un ou l’autre fournit-il de 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 la maintenance RPKI/objets de route fonctionne-t-elle?
Quatrièmement, elle pourrait publier des exemples de procédures d’incident et de migration. Cela devrait inclure l’escalade du support, la notification client, le préavis de maintenance, les options d’exportation de données, la continuité de la facturation pendant une panne et les conditions dans lesquelles Arupa ou le client peut initier un basculement. Les fournisseurs cloud les plus crédibles rendent visibles les procédures ennuyeuses, car c’est là que réside la confiance.
La note actuelle des preuves est donc mitigée plutôt que négative. L’étendue des produits publics d’Arupa, sa visibilité réseau et son positionnement local sont plus solides que ceux de nombreux petits fournisseurs d’hébergement. La divulgation de la capacité physique est plus faible que l’étendue des services. Cet écart est précisément là où 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 contraintes à un modèle hyperscale mondial, et toutes les entreprises ne souhaitent pas assembler seules la sauvegarde, Kubernetes, le stockage, la migration et le support de conformité. Le profil public d’Arupa répond à cette demande. Il combine des ventes et un support locaux, du calcul cloud, de la sauvegarde, du stockage objet, de la reprise après sinistre, la distribution MinIO, des signaux de l’écosystème Broadcom/VMware et le positionnement de cloud souverain Civo.
Il dispose également de ressources de routage indonésiennes actives qui montrent que l’entreprise n’est pas une coquille avec seulement une brochure produit.
Le prochain seuil n’est pas plus de noms de produits. C’est la visibilité des contraintes. Les clients qui achètent une capacité hébergée ont besoin de savoir où se trouve la capacité, quel rack elle occupe, quels amonts la transportent, quelle marge survit à une panne, qui dispose de 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 dossier commercial 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 étayent cette thèse aux niveaux de l’entreprise, des produits et du routage. Elles ne soutiennent pas encore pleinement une revendication de résilience multi-sites vérifiable de manière indépendante. Jusqu’à ce que davantage de preuves sur les installations et la récupération soient publiées, PT.
Arupa Cloud Nusantara doit être traitée comme un fournisseur indonésien opérationnel de cloud et de services technologiques dont la valeur client dépend des calendriers privés derrière ses promesses de cloud public: racks, transit, stock de matériel, main-d’œuvre de support, tests de sauvegarde et droits de migration.