Lokal Cloud Indonesia montre un ASN cloud indonésien sans surface de routage publique actuelle

Résumé

• AS141143 est un enregistrement de système autonome indonésien valide. Son enregistrement RDAP mentionneIDNIC-LOKALCLOUD-AS-ID, l’associe à PT Lokal Cloud Indonesia et date l’enregistrement au 3 mars 2021. Cela prouve le contrôle d’un identifiant de réseau public, et non la présence de serveurs, baies, clients ou d’une plateforme cloud opérationnelle.
• Le 11 juillet 2026, les observations du RIPE NCC indiquaient zéro préfixe IPv4 annoncé, zéro préfixe IPv6 annoncé, zéro espace d’adressage visible, zéro voisin observé et aucun historique de routage de première ou dernière apparition pour AS141143. CAIDA a indépendamment marqué l’ASN commeseen=falseavec un cône de préfixes de zéro et un degré zéro.
• L’enregistrement public contient des déclarations de politique mentionnant AS140457 et AS139947, mais la vue de cohérence du RIPE NCC trouve les deux relations dans les données d’enregistrement et non dans BGP. Il s’agit de signaux de politique historiques ou prévus, et non de preuves de diversité de transit actuelle.
• Le domaine de Lokal Cloud est actif et sa page d’attente d’une ligne est accessible, mais le DNS place le chemin web derrière Cloudflare plutôt qu’AS141143. L’accessibilité du site web ne peut donc pas établir de capacité hébergée en direct par Lokal Cloud, tandis qu’un ASN sans route ne prouve pas à lui seul que l’entreprise a cessé toute activité possible.
• Les clients qui évaluent un fournisseur cloud ont besoin de preuves à un autre niveau: descriptions de service actuelles, limites des installations et des opérateurs, adresses clients attribuées, points de terminaison mesurables, diversité de transit et d’alimentation électrique, tests de sauvegarde et de restauration, escalade de support, inventaire, continuité de facturation et un chemin de sortie documenté. Aucun de ces éléments n’est établi dans le matériel public examiné ici.

Le fait le plus probant est une absence, pas une empreinte

La recherche sur les entreprises cloud commence souvent par une carte: un centre de données, une rangée de baies, une zone de disponibilité, un point d’échange réseau ou au moins un bloc d’adresses annoncé. Lokal Cloud Indonesia commence dans un cadre plus austère. Il existe un système autonome, un nom d’entreprise et un enregistrement indonésien. Il n’existe pas de route publique actuelle rattachée à cette identité.

L’enregistrement RDAP pour AS141143identifie la ressource commeIDNIC-LOKALCLOUD-AS-ID, indique l’Indonésie comme pays et enregistre l’événement de création au 3 mars 2021. Son contact abuse est étiqueté pour PT Lokal Cloud Indonesia, et le contact administratif porte une adresse à South Jakarta. Lavue d’ensemble du système autonomedu RIPE NCC rend de manière indépendante le titulaire commeIDNIC-LOKALCLOUD-AS-ID - PT Lokal Cloud Indonesiaet place le numéro dans un bloc d’ASN 32 bits attribué par l’APNIC.

Il s’agit de faits solides concernant l’identité et la ressource. Ce ne sont pas des faits de capacité physique. Un ASN est un numéro utilisé pour exprimer une politique de routage indépendante. L’explication de l’APNIC sur lesnuméros de système autonomedécrit leur rôle dans l’identification des réseaux qui présentent une politique de routage distincte à l’internet. L’attribution n’inclut pas un nombre de serveurs, un débit de port, un contrat de fibre ou une affirmation selon laquelle le numéro échange actuellement des routes.

Cette distinction n’est pas une prudence sémantique gratuite. Un service cloud est une chaîne d’actifs et d’obligations fonctionnels: hôtes de calcul, supports de stockage, hyperviseurs ou systèmes de conteneurs, commutation, pare-feu, espace d’adressage, transit, électricité, refroidissement, contrôle d’accès, surveillance, sauvegardes, facturation et personnel capable de rétablir le service. Un identifiant de réseau enregistré peut se situer à un point de cette chaîne, mais il ne peut pas remplacer la chaîne.

Si l’identifiant n’est pas visible dans le routage, il ne peut pas non plus fournir un chemin public actuellement observable vers les adresses issues de sa propre politique.

Le nom de l’entreprise invite naturellement à supposer que Lokal Cloud propose une capacité cloud indonésienne. Les preuves disponibles ne justifient pas de transformer ce nom en inventaire de produits. Elles n’établissent pas l’existence de machines virtuelles, de serveurs bare-metal, de stockage objet, de bases de données gérées, de Kubernetes, de colocation, de services de sauvegarde, de location client ou d’un accord de niveau de service. Elles n’identifient pas un bâtiment de centre de données et ne disent pas si l’entreprise possède du matériel, loue des baies, revend la plateforme d’un autre fournisseur ou est inactive.

Un profil défendable commence donc par l’ASN enregistré et suit les preuves vers l’extérieur, en s’arrêtant là où l’observation s’arrête.

AS141143 est enregistré, mais il n’annonce pas publiquement d’espace d’adressage

Les mesures de routage en direct sont cohérentes sur plusieurs dimensions. Lerésultat des préfixes annoncésdu RIPE NCC renvoie une liste de préfixes vide. Lerésultat de statut de routagecorrespondant indique qu’aucun des 327 pairs RIS IPv4 et aucun des 322 pairs IPv6 ne voit AS141143. Il compte zéro préfixe IPv4, zéro adresse IPv4, zéro préfixe IPv6 et zéro équivalent/48IPv6. Les champs qui identifieraient normalement la première ou la dernière apparition de l’ASN sont vides.

L’observation des voisinsest tout aussi frappante: zéro voisin à gauche, à droite, unique ou incertain. En termes BGP, aucun système autonome adjacent observé ne porte une route visible vers ou depuis AS141143 dans cette fenêtre de mesure. C’est plus informatif qu’une page qui manque simplement d’un graphique de trafic. Les préfixes, la visibilité et l’adjacence sont tous absents ensemble.

CAIDA fournit une vérification structurelle indépendante. Sonrésultat AS Rank pour AS141143nomme le même réseau et le même pays, mais marque l’ASN comme non vu. Il ne rapporte aucun fournisseur, pair ou client, un degré global de zéro, et un cône contenant zéro préfixe et zéro adresse. La valeur d’un seul AS dans le cône AS est l’ASN lui-même, pas la preuve d’un réseau en aval. CAIDA et le RIPE NCC utilisent des produits de données et des méthodes différents, de sorte que leur accord réduit la probabilité que la conclusion repose sur le rendu vide d’une seule interface.

La formulation correcte est « aucune surface de routage publique actuelle », et non « l’entreprise n’a aucun système » ni « l’ASN ne pourra jamais fonctionner ». Les collecteurs publics ne voient pas les interconnexions privées, l’espace d’adressage privé, une application hébergée entièrement dans l’ASN de quelqu’un d’autre, ou une route confinée à un intervalle d’observation. Une entreprise pourrait aussi conserver une activité de conseil, de logiciel ou de revente sans lancer aucune route réseau.

Ce que les mesures établissent est plus étroit et reste commercialement important: à la date de référence, il n’existe aucun préfixe observé globalement pour lequel AS141143 fournit l’origine, et donc aucun point de terminaison client ou adresse cloud observable publiquement ne peut être attribué à cette origine.

Cette absence limite aussi les affirmations historiques. Les champs vides de première et dernière apparition n’établissent pas que AS141143 n’a jamais annoncé de route nulle part. Ils montrent que le résultat actuel du RIPE NCC ne fournit pas d’historique visible. Une route peut avoir existé hors de la couverture des collecteurs, en dessous d’un seuil de rapport ou dans un intervalle non conservé dans le résultat affiché. Sans une observation datée d’un collecteur, il serait imprudent de qualifier l’ASN d’anciennement actif. L’affirmation la plus solide étayée par des sources concerne la mesure actuelle: il n’est pas annoncé maintenant.

La politique de routage enregistrée n’est pas une relation de transit en direct

L’enregistrement public contient ce qui ressemble à une conception à deux fournisseurs. Lavue WHOISdu RIPE NCC reproduit des déclarations d’importation acceptant des routes de AS140457 et AS139947, des déclarations d’exportation annonçant AS141143 à chacun, et une politique par défaut pointant vers AS140457. Lues isolément, ces lignes pourraient être prises pour deux sessions en amont opérationnelles.

Lerésultat de cohérence de routagedu RIPE NCC empêche ce saut. Il répertorie AS140457 et AS139947 comme importations et exportations trouvées dans les données d’enregistrement tout en fixantin_bgpà faux pour chacun. Il ne trouve aucun préfixe actuel. Les déclarations de politique sont donc la preuve que quelqu’un a documenté des relations de routage prévues ou antérieures, mais pas la preuve que l’un ou l’autre voisin échange actuellement des routes AS141143.

Cette distinction reflète la manière dont fonctionne le routage internet.RFC 4271définit BGP comme un échange d’informations d’accessibilité réseau entre systèmes autonomes. Une ligne de politique peut décrire ce qui devrait être accepté ou annoncé si une session existe. Elle n’établit pas qu’un routeur est sous tension, qu’un circuit est livré, que l’authentification réussit, que les filtres autorisent la route, qu’un bloc d’adresses est lancé ou qu’un autre réseau le propage.

Deux numéros AS ne prouvent pas non plus la redondance physique. Même si les deux sessions devenaient visibles, les circuits pourraient se terminer sur le même routeur, le même panneau d’interconnexion, la même entrée de fibre, la même salle de rencontre du centre de données ou la même dorsale en amont. Ils pourraient dépendre d’une seule alimentation électrique de baie ou d’un seul compte pouvant être suspendu pour non-paiement. Il pourrait s’agir de sessions logiques sur un tissu d’échange partagé plutôt que de routes indépendamment tranchées.

Une affirmation de résilience nécessite des preuves sur les points de défaillance communs, pas un décompte de lignes de politique.

La politique statique reste utile car elle révèle l’architecture qui mérite vérification. Un client potentiel pourrait demander si AS140457 et AS139947 restent sous contrat; où chaque remise se termine; si chacun offre un transit complet ou seulement une accessibilité sélectionnée; si les filtres de route et les limites de préfixes maximaux sont testés; et si un basculement a été observé en charge.RFC 7454décrit les contrôles opérationnels autour du filtrage, de la protection de session et de l’hygiène du routage, mais il n’y a aucune preuve publique montrant lesquelles de ces pratiques Lokal Cloud ou une contrepartie nommée a déployées.

La même prudence s’applique aux registres de routes. Unerequête RADb pour AS141143ou unerecherche WHOIS APNICpeut faire apparaître des déclarations administratives. Ces enregistrements aident les opérateurs à construire des filtres et à contacter les détenteurs de ressources. Ils ne produisent pas de paquets, ne réservent pas de bande passante et ne vérifient pas un circuit. Dans ce cas, la table de routage en direct est l’observation opérationnelle la plus décisive, et elle indique que la conception enregistrée n’est pas visible en tant que réseau actuel.

Le site web reste accessible sur la surface de routage de quelqu’un d’autre

Le domaine de Lokal Cloud crée un cas de contrôle utile. Lesite web de l’entrepriseétait accessible à la date de référence, mais il n’offrait que la phrase « We’ll be right back! ». Il ne présentait pas de produits, de prix, d’emplacements, de canaux de support, d’informations de statut ou de documentation client. La page montre qu’une présence web persiste; elle n’établit pas ce que l’entreprise vend actuellement.

Le chemin de diffusion est distinct de AS141143. Uneréponse DNS A publiquerenvoie des adresses Cloudflare, et laréponse AAAArenvoie des adresses IPv6 Cloudflare. L’enregistrement RDAP Verisigndu domaine montre un enregistrement datant du 31 janvier 2020, une date d’expiration en janvier 2027 et des serveurs de noms Cloudflare. Ce sont des faits de domaine et de diffusion de contenu, pas des faits de réseau d’origine Lokal Cloud.

Cette séparation explique pourquoi deux affirmations peuvent être vraies simultanément: le site peut se charger, et AS141143 peut avoir zéro préfixe visible. Une requête vers la page d’accueil sollicite le DNS, la périphérie de Cloudflare et un arrangement d’origine caché derrière cette périphérie. Elle ne traverse pas une route publique lancée par AS141143. Cloudflare peut mandater une origine chez un autre fournisseur, et sa réponse publique dissimule l’adresse d’origine par conception. Rien dans cette réponse n’identifie des serveurs appartenant à Lokal Cloud ou une installation indonésienne.

L’entrée MX du domaine pointe de même versmail.lokalcloud.com, mais une étiquette de courrier n’est pas la preuve d’une boîte aux lettres fonctionnelle, d’un serveur propriétaire ou d’un chemin ASN. Le DNS est de la configuration. La délivrabilité dépend de la résolution de la cible, de l’acceptation SMTP, du passage des contrôles de politique, de la présence de stockage et d’une administration. Les enregistrements web et de courrier visibles montrent qu’une certaine configuration d’espace de noms public demeure; ils ne comblent pas le manque de route, de catalogue de services ou de preuves de capacité.

C’est une leçon de diligence importante car la disponibilité de la page d’accueil est un mauvais indicateur de la santé d’une plateforme cloud. Un fournisseur peut externaliser sa page corporate alors que son plan client est indisponible. Il peut aussi maintenir une page de statut en dehors du réseau primaire pour que les communications de panne survivent. Inversement, un ASN peut être actif alors que le site marketing est en panne. Les acheteurs ont besoin de tests dirigés vers le point de terminaison de service et la plateforme contractuelle, pas seulement d’une vérification de navigateur sur le nom de l’entreprise.

Les agrégateurs de routage commerciaux arrivent à la même conclusion générale, avec les limites habituelles. Lapage AS141143 d’IPinfoqualifie l’ASN d’inactif et rapporte zéro adresse IPv4, zéro adresse IPv6 et zéro domaine hébergé. Lavue de routage de Cloudflare Radarnomme le réseau mais n’expose aucun préfixe annoncé dans sa vue actuelle. Ce sont des signaux corroborants, pas des substituts aux données des collecteurs. Les agrégateurs peuvent mettre en cache d’anciennes classifications, inférer les rôles différemment ou laisser un panneau vide pour des raisons méthodologiques. Leur valeur ici est qu’ils ne révèlent pas une empreinte publique contraire.

Aucun enregistrement public ne situe une baie en fonctionnement

L’enregistrement fournit une adresse de correspondance à Jakarta. Il ne doit pas être converti en emplacement de centre de données. Les bureaux, les adresses enregistrées et les suites de contact peuvent héberger des fonctions juridiques, commerciales ou de support sans abriter le matériel client. Le contact RDAP à l’EightyEight Kasablanka Tower A prouve une adresse associée à l’administration du réseau en 2021. Il ne prouve pas qu’un routeur, un serveur, une baie de stockage, un générateur ou une entrée de fibre y est présent en 2026.

L’emplacement physique de toute capacité de calcul de Lokal Cloud reste donc inconnu. Il n’y a pas de nom d’installation public, d’adresse de campus, de nombre de baies, d’allocation électrique, de spécification de refroidissement, de liste d’opérateurs ou de description d’interconnexion dans les documents examinés. Le code pays indonésien de l’ASN identifie le contexte d’enregistrement du détenteur de la ressource; les champs de pays des ressources IP ne sont pas une géolocalisation précise.

Même un préfixe annoncé ne situerait pas à lui seul la machine qui répond sur une adresse, car le trafic peut être tunnellisé, anycasté, mandaté ou transporté via un transport distant.

Cette incertitude est importante pour les revendications de localité. « Entreprise indonésienne », « ASN indonésien », « serveur en Indonésie » et « les données restent en Indonésie » sont quatre propositions différentes. Les deux premières sont directement étayées ici. Les deux dernières ne le sont pas. Une entité juridique locale peut louer du matériel à l’étranger. Une plateforme étrangère peut exploiter une zone de disponibilité indonésienne. Un proxy peut faire apparaître un service près d’un utilisateur alors que le stockage est ailleurs. Seules les preuves d’installation, de contrat et de flux de données peuvent résoudre la frontière.

La zone de service public est tout aussi indéterminée. La régionIDest appropriée pour l’entité enregistrée et son enregistrement de numéro internet. Elle ne prouve pas une couverture nationale ni même un service Jakarta actuellement commandable. L’hébergement cloud ne nécessite pas une empreinte de dernier kilomètre dans chaque ville où vivent les clients, mais la latence, la localisation des données, les heures de support et les modalités de paiement définissent le marché pratique. Sans page de service ou points de terminaison client, aucune province, ville ou industrie ne peut être traitée comme un territoire d’exploitation attesté.

L’image d’un fournisseur cloud comme logiciel pur peut occulter les actifs finis qui le sous-tendent. Une modeste opération d’hébergement a encore besoin d’unités de baie, de CPU, de modules mémoire, de disques, de commutateurs, de distribution électrique, de refroidissement et de mains capables de remplacer les pièces défaillantes. Elle peut louer tous ces éléments à un fournisseur de colocation ou de gros, mais l’infrastructure louée reste de l’infrastructure.

Le contrat du fournisseur devient alors une partie de la surface de défaillance du service: l’accès peut être révoqué, les files d’attente de mains à distance peuvent s’allonger, les interconnexions peuvent être retardées et l’inventaire de pièces de rechange peut s’épuiser.

Les documents de politique propres à l’Indonésie soulignent ces contraintes au niveau du marché sans rien prouver de spécifique à l’entreprise. Unrèglement du ministère des Communications et du Numérique de 2025identifie l’électricité limitée, instable et insuffisamment durable comme un défi d’offre pour la croissance des centres de données indonésiens. C’est un contexte pour les questions sur l’alimentation et la capacité. Il ne peut pas être utilisé pour déduire le fournisseur d’électricité, l’état de l’installation ou le bilan des pannes de Lokal Cloud.

La capacité installée et la capacité utilisable sont des échelles différentes

Les preuves peuvent être disposées comme une échelle, chaque échelon nécessitant quelque chose que celui d’en dessous ne fournit pas. Lokal Cloud atteint clairement le premier échelon: un nom légal enregistré et une identité de numéro internet. Le deuxième serait un espace d’adressage attribué propre à une origine. Aucun préfixe actuel n’est visible dans les données de routage examinées. Le troisième serait une annonce BGP active acceptée par d’autres réseaux. C’est également absent.

Les échelons suivants incluraient des points de terminaison de service accessibles, un accès client authentifié, du calcul et du stockage disponibles, des performances soutenues, des données récupérables et une exploitation commercialement soutenue.

Un ASN seul n’a pas de capacité d’hébergement calculable. Il ne code pas le nombre de serveurs installés, le nombre de CPU virtuels libres, la quantité de stockage répliqué ou le trafic qu’une périphérie peut supporter. Même un nombre de préfixes serait un mauvais indicateur: un seul/24IPv4 peut cacher une grande plateforme, tandis qu’une vaste allocation IPv6 peut ne contenir aucun hôte réactif. La quantité d’adresses est un espace de noms, pas un débit ni un inventaire.

Une annonce d’installation nécessiterait aussi un calibrage. La capacité de conception est la puissance ou la surface au sol qu’un site pourrait supporter sous des hypothèses déclarées. La capacité construite est ce qui a été construit. La capacité mise en service a passé des tests de préparation. La capacité installée a des équipements en place. La capacité commercialisable déduit les réserves de redondance, la marge de maintenance et les ressources déjà engagées. La capacité client utilisable ajoute des logiciels fonctionnels, l’accessibilité réseau, les licences, le support et la facturation.

Aucune de ces quantités n’est divulguée pour Lokal Cloud.

La couche de routage a sa propre échelle. Une politique enregistrée ne signifie pas une session configurée. Une session configurée ne signifie pas qu’elle est établie. Une session établie peut ne porter aucun préfixe. Un préfixe peut être annoncé mais filtré par la plupart des pairs. Une route largement visible peut encore ne mener à aucun service réactif. Une connexion réactive peut encore reposer sur un matériel sursouscrit ou un stockage irrécupérable.

Les zéros du RIPE NCC placent AS141143 en dessous de l’échelon d’annonce publique à la date de référence; ils ne disent rien de définitif sur l’équipement privé en dessous de la couche de routage.

RPKI illustre la différence entre permission et exploitation. La validation d’origine de route, spécifiée dansRFC 6811, permet à un réseau de vérifier si une origine est autorisée pour un préfixe. Une autorisation peut aider à empêcher qu’une origine incorrecte ne soit acceptée. Elle ne peut pas amener un routeur à annoncer une route, restaurer une fibre défaillante ou rendre un serveur sain. Ici, le paquet de routage ne contient aucun préfixe sur lequel fonder une revendication actuelle de validation AS141143. L’absence d’espace d’adressage visible vient avant les questions sur la validité d’une origine.

Les clients devraient donc résister à un calcul de capacité construit à partir de l’enregistrement ASN. La quantité actuelle défendable est zéro préfixe annoncé publiquement, et non zéro serveur physique ni zéro activité commerciale possible. La première est mesurée. Les dernières affirmations nécessiteraient un accès à l’inventaire, aux contrats, à la télémétrie ou à des déclarations corporatives qui ne sont pas publiques.

La frontière de l’opérateur est la principale inconnue commerciale

La fourniture de services cloud couvre souvent plusieurs entreprises même lorsque le client ne voit qu’une seule marque. Un détaillant peut posséder des serveurs mais louer la salle, l’alimentation et la fibre. Il peut louer des serveurs dédiés à un grossiste et ajouter la gestion. Il peut revendre des machines virtuelles sur la plateforme d’un autre fournisseur. Il peut fournir du conseil et de la facturation tandis que l’ensemble du plan de contrôle et de données appartient à un tiers. Chaque modèle attribue les obligations de défaillance et de récupération différemment.

Pour Lokal Cloud, le dossier public n’identifie pas le modèle. PT Lokal Cloud Indonesia est le titulaire désigné pour AS141143. IDNIC et l’APNIC administrent le système de ressources de numéros concerné. Des contreparties potentielles apparaissent dans d’anciennes déclarations de politique. Cloudflare dessert la périphérie visible du site web. Ces faits établissent plusieurs frontières administratives et de diffusion, mais aucune source ne les relie à un cloud client en direct.

Ce lien manquant affecte la responsabilité. Si un serveur tombe en panne, qui possède le châssis et stocke le disque? Si une baie perd de l’alimentation, qui peut entrer dans la salle? Si un fournisseur en amont suspend le service, qui détient le contrat et peut autoriser un changement? Si un client a besoin d’un export, quelle partie contrôle l’hyperviseur et le système de sauvegarde? Si l’entreprise de détail cesse de répondre, l’installation peut-elle libérer les données ou l’équipement directement au client? Une marque peut promettre un support sans avoir un contrôle unilatéral sur l’actif à réparer.

Les contacts d’enregistrement montrent que des rôles administratifs et d’abus existaient lorsque l’ASN a été enregistré. Ils ne constituent pas un effectif opérationnel actuel. Un contact nommé peut changer de poste, et une adresse e-mail peut persister sans qu’une équipe 24 h/24 ne soit derrière. Les preuves publiques n’établissent pas la couverture des opérations réseau, les heures de support en indonésien, les niveaux d’escalade, les communications d’incident ou l’autorité des mains à distance.

La facturation fait aussi partie de la frontière de l’opérateur. Les charges de travail cloud peuvent échouer sans panne matérielle si une facture de grossiste, un renouvellement de domaine, une licence logicielle ou un compte de transit expire. Les clients peuvent continuer à payer un détaillant alors qu’un contrat en amont est contesté. Le message d’attente de la page d’accueil ne donne aucune explication et ne doit pas être lu comme la preuve d’un événement de facturation. Il rend simplement le statut commercial plus difficile à vérifier.

Un acheteur peut réduire cette incertitude par la divulgation contractuelle. Les documents utiles ne sont pas des badges marketing mais une entité contractante nommée, une description de service, une région d’installation, des conditions de traitement des données, une liste de sous-traitants, une politique de support et d’escalade, l’étendue des sauvegardes, les objectifs de récupération, les droits de maintenance, l’assistance à la résiliation et la procédure de restitution des données. Lorsqu’un revendeur dépend d’un grossiste, le client doit comprendre si ses protections survivent à la résiliation de la relation en amont.

L’économie d’un ASN non annoncé est modeste mais révélatrice

Détenir un ASN crée de l’optionalité. Il peut préserver une identité de réseau, soutenir un déploiement planifié, simplifier une future conception multi-hébergement ou permettre à une entreprise de conserver une continuité administrative pendant une migration. Le numéro lui-même n’est pas la partie coûteuse d’une plateforme cloud. Le matériel, l’alimentation de l’installation, la connectivité, les logiciels, le personnel et l’acquisition de clients dominent les dépenses d’exploitation.

Cela rend un ASN d’apparence dormante économiquement ambigu. Il pourrait représenter une rétention prudente pendant une pause, un projet qui n’a jamais atteint la production, une opération entièrement fournie par un autre réseau, ou un service qui a retiré ses routes. Les preuves publiques ne peuvent pas choisir parmi ces explications. Elles peuvent cependant montrer que les coûts et les capacités impliqués par une périphérie publique indépendante ne sont pas actuellement visibles.

Une petite périphérie cloud active a des coûts fixes récurrents avant que la première charge de travail ne tourne. Les engagements de baie et d’alimentation sont généralement achetés en unités minimales. Les interconnexions et le transit ont des frais mensuels. Les serveurs ont besoin de disques, de mémoire, d’alimentations et de cycles de remplacement de rechange. La surveillance et la main-d’œuvre d’astreinte doivent exister la nuit comme pendant les heures de bureau. Les sauvegardes consomment du stockage et de la sortie séparés.

Les frais de paiement, les taxes, les pertes de fraude et les licences logicielles s’ajoutent au-dessus de la plateforme physique.

L’utilisation détermine si ces coûts fixes deviennent des prix compétitifs ou une pression financière. Les serveurs vides consomment du capital et un peu d’énergie; les serveurs fortement consolidés augmentent le rayon d’impact d’une panne d’hôte. Les plans bon marché peuvent dépendre d’une sursouscription élevée, d’un support limité ou d’un remplacement lent. Un fournisseur peut annoncer une grande capacité théorique tout en ayant peu de stocks immédiatement commercialisables après déduction de la redondance et des engagements existants.

Aucun prix ou inventaire public de Lokal Cloud ne permet de tels calculs économiques. Il serait irresponsable de déduire un avantage de faible coût du nom de l’entreprise ou d’un enregistrement indonésien. La meilleure utilisation analytique de l’itinéraire absent est comme déclencheur de diligence: avant de comparer les prix, établir qu’il existe un produit commandable, une ressource livrable et une route par laquelle les clients l’atteignent.

L’absence de résultat PeeringDB actuel renforce cette prudence. Larecherche PeeringDB pour AS141143n’expose pas d’installation, d’échange ou de profil d’interconnexion vérifié pour l’ASN, et larecherche API réseaun’a renvoyé aucun objet réseau à la date de référence. La participation à PeeringDB est volontaire, donc l’absence n’est pas la preuve qu’aucun port ou baie n’existe. Elle retire un chemin public courant pour vérifier l’emplacement et la capacité d’interconnexion.

La défaillance peut commencer dans la baie, la route, le compte ou le chemin de migration

Parce qu’aucune plateforme en direct n’est établie, l’analyse des défaillances doit rester conditionnelle. Elle doit demander ce qui importerait si Lokal Cloud fournit des charges de travail hébergées, plutôt que de décrire des incidents non documentés.

Au niveau de la baie, un hôte peut tomber en panne par une alimentation, une carte mère, de la mémoire, un périphérique de stockage, un ventilateur ou un défaut de micrologiciel. Les composants redondants réduisent certains risques mais ne remplacent pas les pièces de rechange ni un technicien. Un cluster de stockage peut survivre à la perte d’un disque puis échouer pendant la reconstruction. Une paire de commutateurs peut partager une version logicielle défectueuse. Deux cordons d’alimentation peuvent toujours mener à un disjoncteur unique en amont.

Sans inventaire d’installation et de matériel, il n’y a aucune preuve sur le nombre de domaines de défaillance.

Au niveau de la route, l’état actuel est déjà extérieurement indiscernable d’une origine retirée: aucun préfixe AS141143 n’est visible. Si les adresses client dépendaient de cet ASN, elles n’auraient pas de chemin observé globalement à travers lui. Une restauration exigerait un bloc d’adresses, une origine configurée, au moins une session externe fonctionnelle et l’acceptation par le réseau plus large. Si l’ancienne politique reflète encore la conception prévue, la restauration pourrait aussi nécessiter l’action de AS140457 ou AS139947. Le dossier public ne montre pas que l’une ou l’autre relation reste disponible.

Au niveau de l’installation, les pannes d’alimentation et de refroidissement peuvent arrêter de nombreux hôtes à la fois. L’autonomie des générateurs est finie; les batteries font le pont plutôt que d’éliminer les pannes; la livraison de carburant et la maintenance comptent pendant une interruption prolongée. Les systèmes d’incendie, les fuites d’eau, les contrôles d’accès et les travaux publics créent des événements moins fréquents mais plus vastes. Une deuxième baie dans la même salle peut améliorer la redondance de l’équipement sans fournir de redondance de site.

Au niveau du support, la récupération peut échouer parce qu’aucune personne autorisée n’est disponible. Les équipes de mains à distance ont besoin d’instructions claires et de droits d’accès. Un remplacement de disque est inutile si le modèle correct n’est pas en stock. La restauration à partir d’une sauvegarde nécessite des informations d’identification, des clés, des logiciels compatibles et une capacité réseau suffisante pour déplacer les données. Un e-mail de support existant dans un enregistrement de 2021 n’établit pas une chaîne d’escalade testée en 2026.

Au niveau commercial, des factures d’installation, de transit, de logiciels ou de domaine impayées peuvent interrompre le service. Les contrôles de fraude peuvent geler un paiement. Un litige contractuel peut bloquer l’accès physique. Un petit opérateur peut aussi dépendre fortement d’un fondateur ou d’un ingénieur, créant un risque de personne clé même lorsque l’équipement est redondant. Aucune preuve financière ou de personnel publique ne permet de quantifier ce risque pour Lokal Cloud.

Au niveau de la migration, les clients peuvent découvrir trop tard que leur seule sauvegarde se trouve à l’intérieur du même fournisseur. Les formats d’image propriétaires, les volumes de sortie élevés, les clés de chiffrement perdues et les dépendances DNS peuvent prolonger les temps d’arrêt après une défaillance du fournisseur. La portabilité des données fait donc partie de la résilience, et non simplement d’une commodité de résiliation.

Un plan de sortie utilisable inclut des sauvegardes actuelles hors plateforme, des étapes de reconstruction documentées, une configuration exportée, un contrôle DNS indépendant et suffisamment de temps et de bande passante pour déplacer.

La population affectée est inconnue. Il n’y a pas de liste publique de clients, de nombre de domaines hébergés attribuables à l’ASN, d’inventaire de points de terminaison réactifs ou de mesure de trafic. Il serait incorrect de prétendre à une large panne indonésienne ou de nommer des secteurs à risque. L’impact conditionnel est clair: tout client dont la seule copie accessible, le plan de contrôle ou la sauvegarde dépend d’un chemin de fournisseur indisponible pourrait perdre l’accès, tandis que les clients entièrement hébergés ailleurs ne seraient pas affectés par l’état de routage de l’ASN.

La redondance doit être démontrée à chaque dépendance partagée

Une revendication de récupération crédible pour un fournisseur cloud commence par la topologie, mais ne s’arrête pas là. Deux fournisseurs de transit ne sont utiles que s’ils peuvent effectivement porter les préfixes du client et ne s’effondrent pas sur la même défaillance physique. Deux sites ne sont utiles que si la réplication des données, l’identité, le DNS, l’orchestration et l’accès du personnel survivent à la perte de l’un. Les sauvegardes ne sont utiles que si elles sont isolées et que les restaurations s’achèvent dans la fenêtre promise.

Pour AS141143, la paire enregistrée de contreparties de politique ne suffit pas. La première étape de vérification serait une route actuelle visible à travers des collecteurs indépendants. La deuxième serait des chemins montrant une diversité en amont utilisable. La troisième cartographierait chaque session logique à un port physique, un opérateur, une entrée et un routeur. La quatrième testerait le retrait contrôlé d’un chemin et observerait si le trafic se déplace sans interruption inacceptable.

L’alimentation exige la même discipline. Une déclaration sur les doubles alimentations devrait identifier si elles proviennent de chemins de distribution séparés, de tableaux de distribution et de systèmes d’alimentation sans interruption distincts. La capacité des générateurs a besoin d’un historique de test de charge, d’une autonomie de carburant et d’arrangements de ravitaillement. Une charge de travail répartie sur deux baies peut encore partager le refroidissement, l’alimentation du bâtiment et la même équipe d’exploitation. Les sources publiques ne fournissent aucun de ces détails pour Lokal Cloud.

La récupération de calcul a besoin de preuves de rechange et d’orchestration. Les clients doivent savoir si un hôte défaillant déclenche un redémarrage automatique ailleurs, si la capacité restante peut absorber la charge et si le stockage reste cohérent. Une plateforme avec deux hôtes peut techniquement offrir une migration mais manquer de marge lorsque l’un est en panne. Le CPU installé n’est pas un CPU récupérable à moins qu’une réserve de panne ne soit gardée libre.

La récupération des données a besoin de mesures plutôt que d’une case à cocher de sauvegarde. L’objectif de point de récupération définit la quantité de données récentes pouvant être perdues; l’objectif de temps de récupération définit l’intervalle de restauration ciblé. Ni l’un ni l’autre n’est significatif sans le dernier test réussi, la portée des données incluses et les dépendances exclues. Les sauvegardes stockées dans la même baie, le même compte ou le même domaine administratif peuvent disparaître avec le service primaire.

La récupération du support a besoin d’une escalade nommée. Un plan sérieux devrait fournir un canal hors de la plateforme affectée, des objectifs de réponse, l’autorité pour engager l’installation et un processus de communication client. La page d’attente d’une ligne n’est pas une page de statut, et le dossier public ne contient aucun historique d’incident. Le silence ne peut pas être traité comme une preuve de fiabilité ou de défaillance.

Enfin, la récupération client a besoin de portabilité. Un fournisseur peut avoir une excellente redondance des composants tout en exposant les clients au verrouillage si les images de machines virtuelles, les données d’objet, les journaux d’accès ou le matériel de chiffrement ne peuvent pas être exportés. La disposition de résilience la plus forte permet à un client de reconstruire un service critique avec un autre fournisseur sans attendre le retour du plan de contrôle du fournisseur défaillant.

La localité indonésienne est une question juridique et architecturale, pas une promesse de marque

La souveraineté des données est pertinente parce que l’identité de Lokal Cloud est indonésienne et que la localité peut influencer l’achat cloud. Pourtant, la loi ne transforme pas tout service de marque indonésienne en un magasin de données local vérifié.

Lerèglement gouvernemental indonésien n° 71 de 2019distingue les opérateurs de systèmes électroniques du secteur public et du secteur privé. Il exige des opérateurs du secteur public qu’ils gèrent, traitent et stockent les systèmes et données électroniques en Indonésie, sous réserve d’une exception de disponibilité technologique, tout en permettant aux opérateurs privés de traiter ou stocker en Indonésie et/ou à l’étranger sous des conditions de surveillance et d’exécution spécifiées. Ce cadre rend la classe d’opérateur et le flux de données importants; il ne soutient pas une déclaration générale selon laquelle toutes les données des clients indonésiens doivent toujours rester en Indonésie.

Laloi sur la protection des données personnelles, loi n° 27 de 2022établit des devoirs autour du traitement et de la protection des données personnelles. La conformité dépend des rôles, de la finalité, des garanties, des droits et des conditions de transfert, et pas simplement du code pays attaché à un ASN. Un client a encore besoin de savoir qui contrôle les données, qui les traite, où vont les répliques et les sauvegardes, et quels sous-traitants peuvent y accéder.

La localité a également plusieurs couches. Les données au repos peuvent se trouver dans un pays tandis que les sauvegardes sont dans un autre. La télémétrie de gestion peut traverser les frontières même lorsque le disque primaire ne le fait pas. Le personnel de support à l’étranger peut avoir un accès privilégié. Le DNS, la diffusion de contenu, l’identité, la facturation et le courrier électronique peuvent utiliser des fournisseurs mondiaux. Le propre site web public de Lokal Cloud démontre déjà une dépendance de diffusion mondiale via Cloudflare, bien que cela ne dise rien d’une plateforme client distincte.

Une forte revendication de localité nommerait donc le pays de l’installation et de préférence la zone métropolitaine; divulguerait les emplacements de sauvegarde et de reprise après sinistre; identifierait les sous-traitants; expliquerait l’accès de support transfrontalier; et indiquerait ce qui se passe pendant un basculement. Elle distinguerait également la résidence de la souveraineté. La résidence décrit l’emplacement de stockage physique. La souveraineté concerne les lois et les autorités qui peuvent atteindre les données.

Une copie stockée localement peut rester soumise à des contrats ou des relations corporatives couvrant plusieurs juridictions.

Aucune de ces divulgations n’est publique pour Lokal Cloud dans les sources examinées. L’enregistrement indonésien de l’entreprise est une preuve pertinente de présence juridique et administrative. Il ne suffit pas à commercialiser une charge de travail comme résidente, souveraine ou physiquement hébergée en Indonésie. Les acheteurs pour des charges de travail réglementées ou sensibles auraient besoin de représentations contractuelles et de vérification technique avant de s’appuyer sur la localité.

Les index de marché sont des signaux utiles, mais ils ne peuvent pas créer un réseau en exploitation

Les index tiers comblent certaines lacunes tout en en créant d’autres.BGP.Tools,BGP Toolkit de Hurricane ElectricetBGPViewoffrent tous des moyens d’inspecter l’ASN à travers des données de routage collectées ou agrégées. Leurs pages peuvent différer en fraîcheur, en étiquettes et en rétention historique. Aucune ne fournit un préfixe annoncé actuel qui contredit les conclusions du RIPE NCC et de CAIDA utilisées ici.

Un profil commercial vide peut signifier un réseau inactif, un réseau très récent, un angle mort de mesure ou une page qui ne s’est pas rafraîchie. Un décompte de domaines hébergés à zéro peut manquer des services derrière des réseaux de diffusion de contenu, des applications non web ou des domaines dont les adresses appartiennent à un fournisseur en amont. Une étiquette « ISP » ou « hosting » peut provenir du texte du registre plutôt que de clients observés. Ces signaux devraient guider les questions, pas devenir des affirmations sur les revenus ou l’équipement installé.

Il en va de même de l’absence de PeeringDB. De nombreux réseaux en exploitation publient volontairement des informations sur l’installation, l’échange, le trafic et le contact; beaucoup ne le font pas. Une absence de liste signifie qu’il n’y a pas de profil d’interconnexion volontairement divulgué à examiner. Cela ne prouve pas que l’entreprise manque d’un circuit de transit privé. La preuve ne devient persuasive qu’en combinaison: aucun objet PeeringDB, aucun préfixe RIPE NCC, aucun voisin RIPE NCC, une visibilité nulle et CAIDAseen=falsepointent tous vers l’absence de surface publique AS141143 actuelle.

Ce qui renverserait cette conclusion est simple. Une route actuelle largement visible issue d’AS141143 établirait un routage public. Un avis d’entreprise signé nommant un préfixe et un service relierait la route à une offre. Un enregistrement d’installation ou d’échange pourrait localiser une partie de la périphérie. Des points de terminaison réactifs et une documentation client pourraient établir un service. Des mesures indépendantes dans le temps pourraient montrer une stabilité. D’ici là, l’identité de registre statique reste le plafond de ce qui peut être affirmé avec confiance.

Les signaux non officiels sont encore moins capables de prouver une capacité physique. Des publications sociales, des publicités de revendeurs, des pages de plans archivées et des extraits de recherche peuvent suggérer qu’une entreprise a autrefois vendu de l’hébergement, mais ils peuvent survivre après la disparition des stocks, du personnel ou des contrats en amont. Ils peuvent aussi décrire une entité juridique différente avec un nom similaire. Aucun signal de ce type ne devrait être utilisé pour affirmer des baies en direct sans corroboration actuelle de commande, de routage et opérationnelle.

Ce qu’un client ou une contrepartie devrait vérifier maintenant

La première question est de savoir si Lokal Cloud offre actuellement un service quelconque. Un acheteur devrait obtenir une description de service datée, un prix, une entité contractante et un canal de support fonctionnel. Il devrait demander un point de terminaison de test ou un locataire d’essai et confirmer que la route et l’opérateur du point de terminaison correspondent à l’architecture promise. Si le service est fourni depuis un autre ASN, ce n’est pas automatiquement un défaut, mais l’opérateur réel doit être divulgué.

La deuxième question est de savoir où le service s’exécute. Des preuves utiles incluent un nom d’installation, une ville, une baie ou un arrangement de gros, un engagement de localisation des données et une liste de sous-traitants. Une visite de site n’est pas toujours pratique, mais les contrats, les rapports d’audit et les attestations d’installation peuvent réduire l’incertitude. L’adresse de contact de South Jakarta ne doit pas être acceptée comme un emplacement de serveur sans confirmation directe.

La troisième question est de savoir qui contrôle le réseau. Pour un service destiné à utiliser AS141143, l’acheteur devrait voir un préfixe issu actuel, une visibilité de route, les noms des fournisseurs en amont, le basculement attendu et une explication de l’absence actuelle. Si l’ASN est conservé uniquement pour un usage futur, cela devrait être énoncé clairement. Si le trafic client utilise l’ASN d’un fournisseur en amont, la description de service devrait identifier la dépendance et expliquer comment les adresses se déplacent lors d’une défaillance du fournisseur.

La quatrième question est la capacité récupérable. Demander le nombre de domaines de défaillance, la marge d’hôtes de rechange, le mode de réplication du stockage, l’emplacement des sauvegardes, le dernier test de restauration, les objectifs de récupération et le processus de maintenance. Les certifications peuvent soutenir la gouvernance, mais elles ne répondent pas à la question de savoir si les données d’un client spécifique peuvent être restaurées avant une date limite spécifique.

La cinquième question est la continuité commerciale. Le contrat devrait couvrir les crédits de panne, le préavis, la suspension, la résiliation, l’exportation de données et l’assistance pendant la migration. Les clients devraient conserver des copies indépendantes des informations d’identification, de la configuration DNS, des images, des bases de données et du matériel de chiffrement. Une sortie de fournisseur est bien plus facile avant que le fournisseur ne devienne injoignable.

La sixième question est l’âge des preuves. L’enregistrement ASN date de 2021, tandis que l’observation de routage est actuelle au 11 juillet 2026. Un enregistrement administratif durable et un zéro actuel décrivent des moments différents et des couches différentes. La diligence devrait privilégier la dernière observation d’exploitation pour la disponibilité, tout en conservant l’enregistrement comme preuve d’identité.

Ces demandes sont proportionnées précisément parce que le dossier public est mince. Elles ne présument pas de faute ou de défaillance. Elles convertissent l’incertitude en affirmations testables. Un petit fournisseur peut avoir une infrastructure solide et peu de documentation publique; il peut combler cette lacune avec des routes actuelles, des contrats, des tests et des divulgations.

La conclusion mesurée est plus étroite que « actif » ou « mort »

Lokal Cloud Indonesia occupe un état reconnaissable mais souvent mal compris. Son numéro de système autonome n’est pas fictif, expiré ou mal attribué dans les sources examinées. AS141143 est enregistré via le système de numéros internet indonésien à PT Lokal Cloud Indonesia. Le domaine reste également enregistré et le site web répond.

Mais l’identité de réseau n’a pas de surface de routage publique actuelle. Le RIPE NCC ne voit aucun espace d’adressage annoncé, aucune route visible et aucun voisin. CAIDA ne voit aucun cône de préfixes et marque l’ASN comme non vu. La politique enregistrée nomme deux contreparties possibles, mais les données de cohérence ne les trouvent pas dans BGP. Le site web atteint les utilisateurs via Cloudflare, de sorte qu’il ne peut pas combler cette lacune probante.

Cela ne laisse aucune base pour affirmer une capacité hébergée en direct. Il peut y avoir de l’équipement, des services privés, une activité de revente, une migration ou un déploiement en pause hors de l’observation publique. Chacune de ces explications est possible; aucune n’est établie. La conclusion de l’article n’est donc pas que toute activité corporative a cessé. Elle est que les preuves publiques s’arrêtent avant qu’un réseau cloud en exploitation issu de Lokal Cloud ne commence.

Pour les clients, la réponse pratique est de vérifier le service aux couches des actifs, de la route, du contrat et de la récupération. Demander où tourne la charge de travail, qui exploite chaque dépendance, quel espace d’adressage la porte, ce qui survit à une défaillance de site ou d’amont, comment le support escalade, et comment les données sortent. Jusqu’à ce que ces questions aient des réponses actuelles, AS141143 doit être compris comme un ASN d’entreprise cloud indonésien enregistré avec une capacité de routage public observée nulle, et non comme la preuve d’une plateforme cloud indonésienne en exploitation.