Green Cloud Technologies,LLC vend une capacité hébergée qui dépend toujours des baies, du transit et des fenêtres de réparation

Résumé

• Green Cloud Technologies,LLC dispose de plus de preuves opérationnelles qu'une étiquette d'hébergement dormante: ARIN lie AS54155 à Green Cloud Technologies,LLC, et la vue juillet 2026 de RIPEstat montre des annonces IPv4 actives, une large visibilité de routage et six voisins observés. La surface de routage, cependant, prouve mieux la joignabilité qu'elle ne prouve la diversité des sites, la profondeur des pièces de rechange matérielles ou la capacité de récupération des clients.
• La preuve la plus solide de l'entreprise est historique et transactionnelle. 11:11 Systems a déclaré avoir finalisé l'acquisition de Green Cloud Defense en décembre 2021, a décrit Green Cloud comme un grand fournisseur IaaS indépendant exclusivement par canaux, et a listé des centres de données à Atlanta, Greenville, Houston, Minneapolis, Nashville et Phoenix. Cette preuve est réelle, mais les clients actuels ont toujours besoin d'un calendrier de placement actuel, pas seulement d'une liste de villes datant de l'acquisition.
• Le domaine routé de Green Cloud semble mélangé. Les enregistrements RDAP d'ARIN lient certains préfixes directement à Green Cloud, tandis que d'autres blocs d'adresses actuellement annoncés pointent vers Cirrity, ipHouse, Advanced Network Solutions ou des enregistrements Green Cloud attribués par INAP. Cela est cohérent avec les acquisitions, la capacité louée et l'infrastructure héritée, mais cela signifie aussi que la propriété, l'accès aux installations et la responsabilité du support doivent être séparés dans tout examen de résilience.
• L'histoire de l'interconnexion publique est incomplète. RIPEstat voit des ASN voisins incluant Cogent, Level 3, Zayo, Hurricane Electric, Megaport et Unitas, tandis que PeeringDB ne renvoie aucun profil réseau Green Cloud pour AS54155 et des vérifications RPKI échantillonnées ont retourné un statut inconnu. Ces lacunes ne rendent pas le service faible en elles-mêmes; elles marquent les parties qui doivent être prouvées contractuellement.
• La note de preuve est Moyenne, pas Forte. Le dossier public de Green Cloud soutient une surface de cloud et de réseau opérationnelle en direct, mais la marque a été intégrée dans 11:11, la carte opérationnelle spécifique à Green Cloud est datée, et la récupération dépend de détails sur les installations, le transit, le support et l'exportation de données que les pages publiques ne divulguent que partiellement.

L'étiquette cloud cache une activité matérielle

Green Cloud Technologies,LLC est un exemple de pourquoi la capacité hébergée doit être lue du rack vers l'extérieur, pas de la marque vers l'intérieur. L'entreprise vendait de l'infrastructure cloud via des partenaires. Le client voyait une machine virtuelle, un bureau, un référentiel de sauvegarde, une cible de récupération ou une enveloppe de sécurité gérée. L'obligation opérationnelle en dessous était plus concrète: bâtiments, alimentation, refroidissement, armoires, hyperviseurs, baies de stockage, routeurs, interconnexions, contrats de transit, systèmes de surveillance et techniciens.

La trace d'identité publique commence par les ressources numériques.L'enregistrement RDAP d'ARIN pour AS54155nomme GREENCLOUD et liste Green Cloud Technologies,LLC comme inscrit.L'aperçu AS de RIPEstatutilise le label détenteur "GREENCLOUD - Green Cloud Technologies,LLC" et marque l'AS comme annoncé dans sa vue juillet 2026. C'est une preuve plus solide qu'un site web obsolète car elle montre une présence en direct sur le plan de contrôle Internet liée au nom légal.

Ce n'est toujours pas suffisant pour acheter une résilience. Un numéro de système autonome indique quelle origine apparaît dans le routage mondial. Il ne dit pas quel bâtiment héberge la charge de travail d'un client, si deux routeurs sont dans des zones d'incendie séparées, si le deuxième transit peut supporter la charge de pointe, ou si des disques de rechange et des serveurs de remplacement sont sur site. AS54155 peut établir une bordure; il ne peut pas à lui seul établir une promesse de récupération.

L'historique de la marque compte parce que Green Cloud est passé d'un cloud indépendant par canaux à une partie d'une plateforme d'infrastructure gérée plus large.11:11 Systems a annoncé la clôture de son acquisition de Green Cloud Defenseen décembre 2021 et a décrit Green Cloud comme un fournisseur IaaS exclusivement par canaux servant des fournisseurs de services gérés, des revendeurs à valeur ajoutée et des consultants IT. La même annonce a déclaré que ces partenaires servaient plus de 2 000 entreprises et a listé des centres de données à Atlanta, Greenville, Houston, Minneapolis, Nashville et Phoenix. Pour un acheteur, ces faits disent que le rayon d'explosion n'est pas seulement la liste de clients directs de Green Cloud. Il atteint aussi les entreprises en aval qui peuvent mieux connaître le MSP local que l'opérateur d'infrastructure derrière le service.

Cela fait de Green Cloud un multiplicateur de dépendance. Quand un fournisseur cloud direct échoue, le client voit généralement le nom du fournisseur. Quand un cloud par canaux échoue, la première partie visible peut être le MSP, le revendeur ou le consultant qui a packagé le service. Le chemin de support contractuel peut alors traverser plusieurs couches avant d'atteindre les personnes qui peuvent changer une route, remplacer du matériel ou approuver une migration. C'est pourquoi la véritable surface opérationnelle de Green Cloud n'est pas seulement AS54155.

C'est AS54155 plus le réseau de partenaires, les files d'attente de support, les composants de plateforme hérités et la politique de placement actuelle de 11:11.

Les preuves actuelles de Green Cloud sont réelles, mais pas simples

L'instantané de routage le plus utile n'est pas le slogan de l'entreprise; c'est l'état de routage public.Le statut de routage RIPEstat pour AS54155montrait, dans la vue juillet 2026 utilisée ici, 30 préfixes IPv4, 8 192 adresses IPv4, une visibilité IPv4 complète à travers les pairs RIS rapportés dans cette sortie, aucune annonce IPv6 visible, et six voisins observés.La vue des préfixes annoncés de RIPEstatincluait des blocs tels que 162.218.104.0/22, 198.71.76.0/22, 207.200.176.0/23, 45.42.134.0/24 et de nombreuses routes /24 individuelles.

Ce ne sont pas des faits cosmétiques. Trente préfixes IPv4 actuels signifient qu'il y a une surface de routage active à tester. Une large visibilité des collecteurs signifie que les routes n'étaient pas simplement des annonces locales ou privées au moment de l'observation publique. L'absence d'IPv6 visible dans la même vue est aussi une contrainte utile: la préparation double pile ne doit pas être déduite de l'étiquette cloud.

Les clients qui dépendent de la joignabilité IPv6, de la surveillance IPv6 uniquement, du basculement double pile ou des exigences d'approvisionnement du secteur public ont besoin de preuves de produit actuelles plutôt qu'une affirmation générale qu'un fournisseur cloud moderne l'aura.

Les enregistrements d'adresses montrent aussi pourquoi un récit d'entreprise unique serait trompeur.L'enregistrement RDAP d'ARIN pour 162.218.104.0pointe vers un bloc Green Cloud.L'enregistrement RDAP d'ARIN pour 198.71.76.0pointe aussi vers Green Cloud. Mais d'autres plages annoncées portent des indices différents:207.200.176.0pointe vers Advanced Network Solutions,162.244.152.0pointe vers Cirrity, et plusieurs enregistrements attribués par INAP portent des labels Green Cloud. Ce motif correspond à un fournisseur qui a accumulé ou exploité à travers des infrastructures acquises, attribuées et louées plutôt qu'un qui possède un domaine d'adresses homogène unique.

L'indice Cirrity est particulièrement important. Les reportages publics deVMblog sur l'acquisition de Cirrity par Green Clouddécrivaient Cirrity comme un fournisseur de services cloud à Atlanta. Si un préfixe annoncé actuellement originaire de Green Cloud trace vers Cirrity, cela ne prouve pas automatiquement où se trouve une charge de travail présente, mais cela explique pourquoi la capacité de Green Cloud doit être examinée comme un domaine hérité. Les plateformes acquises apportent souvent des conceptions de stockage séparées, des versions d'hyperviseur séparées, des contrats de fournisseur séparés, des obligations clients séparées et des traditions de maintenance séparées. L'intégration peut améliorer le service; elle peut aussi laisser des coutures cachées qui n'apparaissent que lors d'un incident.

C'est la première dégradation par rapport à une lecture Forte. Green Cloud est visible sur Internet. Ce n'est pas une pure société de papiers. Mais la table de routage actuelle est une carte composite, et les preuves publiques ne permettent pas à un lecteur externe de dire exactement quelle ville, rack, fournisseur ou cluster cloud soutient chaque charge de travail client.

La liste des six villes est utile, mais ce n'est pas une garantie de placement

L'annonce d'acquisition de 2021 est la liste de villes publiques la plus claire pour Green Cloud. 11:11 a listé les centres de données Green Cloud à Atlanta, Greenville, Houston, Minneapolis, Nashville et Phoenix.L'annonce d'acquisition de BusinessWireetle communiqué PRNewswire sur la société de portefeuille Tiger Infrastructure 11:11 Systems acquérant Green Cloudrenforcent la même histoire stratégique: Green Cloud était en train d'être intégré dans une plateforme plus large de connectivité, cloud et sécurité.

La liste de villes est précieuse car elle déplace l'analyse d'une vague étiquette "cloud US" vers un ensemble de marchés physiques. Atlanta est un hub de connectivité majeur du Sud-Est. Greenville donne un siège social en Caroline du Sud et un contexte opérationnel régional. Houston, Minneapolis, Nashville et Phoenix sont des zones de risque matériellement différentes pour l'alimentation, les tempêtes, le personnel, la densité de transporteurs et la latence client. Un seul fournisseur avec des points dans les six marchés peut offrir des choix de placement utiles. Il peut aussi avoir une profondeur inégale entre eux.

La liste n'est pas une garantie de placement pour un compte individuel. Les serveurs virtuels d'un client MSP peuvent être dans une ville tandis que les sauvegardes sont dans une autre. Une cible de reprise après sinistre peut être réservée mais sous-dimensionnée. Un pool de bureau en tant que service peut être localisé selon la pratique de support plutôt que la préférence de souveraineté des données. Un service de sécurité peut stocker des journaux ou des tickets sur une plateforme différente du service de calcul.

Sans un devis, un calendrier de service ou un exhibit d'architecture actuel, l'ancienne liste de villes doit être traitée comme une géographie à vérifier, pas une promesse sur laquelle compter.

L'empreinte actuelle de 11:11 élargit le contexte. Sapage des régions cloudindique que l'entreprise exploite plus de 25 installations dans le monde et que la sécurité, la stabilité et la souveraineté des données sont au cœur de sa posture cloud. La page liste aussi des centres de données nord-américains dans des grandes villes telles qu'Atlanta, Chicago, Dallas, Los Angeles, New York, San Jose, Scottsdale et Toronto, plus d'autres emplacements dans des États comme la Virginie et le New Jersey. Cela montre une empreinte parente plus large que la carte historique de Green Cloud.

Pour la souveraineté des données, plus grand n'est pas automatiquement meilleur. Une plateforme plus large peut offrir plus d'options de récupération et plus de choix de placement local, mais elle peut aussi brouiller quels engagements Green Cloud hérités correspondent encore à quelle région actuelle de 11:11. Les clients devraient demander une matrice de placement exacte: calcul de production, stockage répliqué, sauvegardes, instantanés, journaux du plan de gestion, enregistrements de ticketing, télémétrie de sécurité et tout accès de support transfrontalier.

Le pays pertinent n'est pas seulement l'enregistrement US de l'entreprise; il est chaque endroit où les données client, les métadonnées et l'accès opérationnel peuvent résider.

La combinaison de services indique un vendeur de capacité, pas seulement un réseau

L'ancienne description publique de Green Cloud et les pages produits actuelles de 11:11 pointent toutes deux vers de la capacité hébergée plutôt qu'une simple connectivité. Le matériel d'acquisition de 2021 décrivait Green Cloud comme un fournisseur IaaS avec sauvegarde, reprise après sinistre, bureau en tant que service et services de sécurité gérés.L'aperçu cloud de 11:11décrit maintenant un hébergement cloud public et privé basé sur VMware, le support de migration, la sécurité, la conformité et la sauvegarde.11:11 Cloud privé hébergémet l'accent sur le cloud privé monolocataire, le support de migration, les configurations préconstruites et sur mesure, les serveurs dédiés, les choix de stockage et un modèle de résilience N+1.11:11 Environnement cloud flexible et colocationétend ce langage au nu métal, à la colocation, à la mise en réseau à faible latence, à la surveillance et au support 24h/24.

C'est une histoire d'actifs physiques. Un cloud privé nécessite un inventaire de serveurs dédiés suffisant pour répondre aux blocs engagés. Un service de nu métal nécessite des pièces de rechange matérielles réelles, une discipline de firmware et un personnel de support qui peut atteindre la machine. Un service VMware nécessite des licences, une gestion du cycle de vie de l'hyperviseur, une compatibilité de stockage et des outils de migration. Une extension de colocation nécessite des installations, des cages ou racks, des commandes d'interconnexion, des mains à distance et une capacité électrique.

Le client achète une abstraction; le fournisseur gère une activité de matériel et de contrats.

Le langage N+1 de la page cloud privé de 11:11 est utile mais pas complet. N+1 peut signifier qu'il y a un composant supplémentaire dans un cluster, une unité d'alimentation supplémentaire, un hôte supplémentaire, un contrôleur de baie supplémentaire ou une philosophie de conception plus large. Cela ne signifie pas nécessairement un basculement double site, une migration en direct complète sous chaque incident, ou la capacité d'absorber une panne de ville entière.

Les clients devraient demander quelle couche a une protection N+1: les hôtes de calcul, les contrôleurs de stockage, les commutateurs d'agrégation, les routeurs de bord, les alimentations, le refroidissement, les référentiels de sauvegarde et le personnel de support. La bonne réponse diffère selon la charge de travail. Un petit service web peut avoir besoin d'un redémarrage automatique et de suffisamment de bande passante. Une base de données régulée peut nécessiter une réplication synchrone ou soigneusement gouvernée, des pistes d'audit, des garanties de rétention et une procédure de sortie documentée.

Cette distinction compte car l'ancien modèle de canal de Green Cloud peut rendre la capacité plus élastique qu'elle ne l'est. Un partenaire peut vendre un service rapidement. L'opérateur d'infrastructure ne peut déployer, réserver et réparer que ce qu'il a réellement. Quand l'inventaire matériel, l'alimentation du rack ou la marge de transit devient rare, l'échec n'est pas visible comme un échec marketing. Il apparaît comme un approvisionnement lent, des mises à niveau retardées, des fenêtres de restauration contraintes, des reports de maintenance ou des tickets de support qui nécessitent une équipe de plateforme.

Le SLA montre où le client est exposé

Un des documents publics les plus utiles pour Green Cloud est l'ancienPDF de la politique de niveau de service et de maintenance de Green Cloud Technologies. Il est daté et ne doit pas être traité comme un contrat actuel sans confirmation, mais il reste une fenêtre pratique sur la façon dont Green Cloud a encadré les limites de défaillance. Le document décrit la disponibilité du service autour de l'infrastructure détenue par Green Cloud, la maintenance planifiée, les niveaux de reprise après sinistre et les priorités de support. Il exclut aussi les parties hors du contrôle du fournisseur, telles que les réseaux côté client et les dépendances Internet plus larges.

Cette structure est normale pour un fournisseur hébergé, et c'est exactement pourquoi les clients devraient lire attentivement la limite. Si le service est joignable à l'intérieur de la bordure de Green Cloud mais que le chemin FAI du client est cassé, le cloud peut compter comme disponible tandis que le client est hors service. Si l'environnement virtuel est opérationnel mais qu'une application spécifique est mal configurée, le fournisseur d'infrastructure peut ne pas être responsable de la panne applicative.

Si une fenêtre de maintenance est planifiée, le service affecté peut être indisponible sans créer le même recours qu'un échec non planifié. La question pratique n'est pas de savoir si le SLA utilise un pourcentage de disponibilité élevé. C'est quels échecs comptent, lesquels ne comptent pas, et qui supporte la douleur opérationnelle au milieu.

Le modèle de support du même document rappelle que la main-d'œuvre fait partie de la capacité. Les problèmes de priorité 1 reçoivent l'attention la plus rapide; les problèmes de moindre sévérité peuvent attendre. Le support d'urgence en dehors des heures normales se concentre sur les incidents critiques. La maintenance est traitée comme une partie normale du cycle de vie du service. En d'autres termes, le support n'est pas un pool infini d'ingénieurs. Il est rationné par sévérité, calendrier et droit.

C'est rationnel, mais cela devient un risque client quand une restauration, une migration ou un changement d'interconnexion tombe en dessous de la plus haute priorité même si l'entreprise du client est sous pression.

Lapage de support actuelle de 11:11continue le thème de la limite de support à plus grande échelle. Elle liste des numéros de support mondiaux, des liens de compte et de console, et des contacts séparés pour les services cloud, les services de sécurité, les services de connectivité et la facturation. Cette séparation est opérationnellement utile, mais elle dit aussi aux clients de cartographier la propriété des échecs à l'avance. Une charge de travail originaire de Green Cloud peut échouer via le calcul, la sécurité, la connectivité, la facturation ou la gestion d'accès. Chaque chemin peut avoir une file d'attente et une pratique d'escalade différentes.

Le chemin de facturation mérite l'attention car les défaillances cloud ne sont pas seulement techniques. Un compte suspendu, un différend contractuel, une non-concordance de licence, un solde prépayé épuisé ou une méthode de paiement échouée peuvent créer un événement de temps d'arrêt qui ressemble à un problème d'infrastructure pour les utilisateurs finaux. Un fournisseur avec des partenaires de canal ajoute une autre couche: le client final peut payer le MSP, le MSP peut payer la plateforme amont, et un différend dans une couche peut affecter la continuité du service.

L'examen de résilience devrait donc inclure les règles d'escalade de facturation et de contrôle de compte, pas seulement les diagrammes de sauvegarde et de routage.

La diversité de transit est suggérée, pas prouvée

Lavue des voisins ASN de RIPEstat pour AS54155a observé six voisins dans les données juillet 2026 utilisées ici. Les ASN résolvent en noms importants ou pertinents pour l'infrastructure:Cogent,Level 3,Zayo,Hurricane Electric,MegaportetUnitas. C'est mieux que de voir un seul upstream solitaire dans une vue de routage publique.

Mais l'adjacence BGP et la diversité physique sont des choses différentes. Un collecteur de routes peut voir des voisins sans dire à l'acheteur si ces voisins sont des transits complets, des pairs partiels, des routes d'échange, des interconnexions privées ou des sessions héritées. Deux upstreams apparemment différents peuvent entrer dans le même bâtiment par la même salle de rencontre ou même dépendre de la même coupure de fibre métropolitaine.

Une session Megaport peut être précieuse pour l'interconnexion définie par logiciel, mais elle repose toujours sur le chemin d'accès sous-jacent, le port, la plateforme et le point de terminaison distant. Un fournisseur peut avoir plusieurs chemins logiques et être toujours vulnérable à une panne d'installation, à un arriéré d'interconnexion ou à une erreur de contrôle de changement.

PeeringDB aiderait normalement à combler une partie de cet écart car il liste souvent les installations, les échanges, la politique de peering et les indices de trafic. Dans le cas de Green Cloud, unerecherche API PeeringDB pour AS54155n'a retourné aucun profil réseau. L'absence de PeeringDB n'est pas un échec en soi. De nombreux fournisseurs légitimes ne maintiennent pas un profil à jour. Néanmoins, elle supprime une source maintenue par l'opérateur qui aurait pu clarifier les sites d'interconnexion, la politique de trafic ou les rattachements aux installations. C'est une autre raison pour laquelle la note de preuve reste en dessous de Forte.

La sécurité de l'origine de routage est également incomplète à partir des vérifications publiques. Unerequête de validation RPKI RIPEstat échantillonnée pour AS54155 et 162.218.104.0/22a retourné un statut inconnu car aucune ROA de validation n'est apparue dans cette réponse. Une deuxième requête pour un autre préfixe actuel a produit le même type de résultat inconnu. Un statut RPKI inconnu ne prouve pas un mauvais routage et ne signifie pas que la route est inutilisable. Cela signifie que les clients qui comptent sur une validation stricte de l'origine de routage devraient demander si des ROA existent pour les préfixes qui transportent réellement leurs services, et sinon, quel est le plan de sécurité de routage de l'opérateur.

Les pages de visibilité réseau telles queBGP.tools pour AS54155,BGP Toolkit de Hurricane Electricetla page AS54155 d'IPinfosont des vérifications croisées utiles, mais elles ont la même limite. Elles montrent la joignabilité et les métadonnées de routage. Elles ne vérifient pas l'alimentation du rack, la diversité de route, les procédures de restauration ou les obligations commerciales sous chaque session.

Les acquisitions ont amélioré la portée et accru le risque d'intégration

Green Cloud n'est pas resté immobile avant 11:11. L'entreprise s'est développée par acquisitions et par superposition de services de sécurité.La page d'archives de 11:11 sur Green Cloud parvenant à un accord définitif pour acquérir Cascade Defenseet l'annonce d'acquisition et de changement de nom de Green Cloudmontrent comment l'entreprise est passée au-delà de l'infrastructure cloud brute vers la sécurité gérée.La couverture de Cascade par MSSP Alerta encadré l'accord dans le marché des fournisseurs de services de sécurité gérés, tandis quela couverture de l'acquisition par 11:11 par MSSP Alerta lié le cloud et la plateforme de sécurité de Green Cloud à la stratégie plus large de 11:11.

Les acquisitions ne sont pas intrinsèquement risquées. Elles peuvent apporter du capital, de l'automatisation, de nouveaux produits, de meilleures pratiques de sécurité et un support plus profond. L'annonce d'acquisition de 11:11 a déclaré que la combinaison ajouterait des capacités de connectivité et de sécurité pour le réseau de partenaires de canal national de Green Cloud. Elle a aussi nommé la continuité technologique et de direction après l'accord, ce qui compte pour la passation opérationnelle.

Le risque est que les domaines acquis vieillissent souvent de manière inégale. Un cloud acquis peut utiliser une réplication de stockage différente, un système de ticketing différent, un standard de pare-feu différent, une pile de sauvegarde différente ou un ensemble de contrats d'installation différent. Les services de sécurité peuvent avoir leurs propres dépendances de journalisation et de surveillance. Les partenaires de canal peuvent continuer à vendre selon d'anciennes habitudes même si la plateforme amont est en cours de rationalisation.

Un client qui demande seulement si le fournisseur est "11:11 maintenant" peut manquer la question plus importante: quelle plateforme hébergée héberge réellement cette charge de travail?

C'est pourquoi l'histoire de Cirrity et Cascade compte pour un examen de résilience. Cirrity explique une partie de l'héritage cloud et d'adresses. Cascade explique la couche de sécurité gérée. 11:11 explique la plateforme parente actuelle. Aucun de ces faits n'est mauvais; ensemble, ils signifient que le client devrait exiger une carte. La carte devrait relier le service nommé au site physique, au bloc d'adresses, au chemin amont, à la cible de sauvegarde, à la pile de surveillance de sécurité, à la file d'attente de support et à l'entité contractuelle.

Les partenariats avec les fournisseurs montrent la forme de la plateforme

Les références technologiques publiques de Green Cloud soutiennent l'image d'une plateforme de capacité hébergée réelle. Unblog du centre de données Cisco sur l'utilisation par Green Cloud des serveurs Cisco UCS S-Seriesdécrivait l'utilisation par l'entreprise de l'infrastructure serveur Cisco pour soutenir de nouvelles activités. Unprofil de blog du fournisseur cloud VMware de Green Cloud Defenseplaçait l'entreprise dans l'écosystème des fournisseurs cloud VMware.L'aperçu cloud de 11:11continue maintenant ce cadrage basé sur VMware.

Ces références sont importantes car elles éloignent la discussion d'un langage purement virtuel. Les clouds VMware fonctionnent sur des hôtes, des clusters, des datastores, des serveurs de gestion, des accords de licence et des cycles de patch. Les environnements Cisco UCS ont des interconnexions de fabric, des profils de serveur, des dépendances de firmware et des choix de stockage. Les services Fortinet et de sécurité gérés ont des capteurs, des chemins d'ingestion de journaux, des analystes et des règles d'escalade. Chaque couche peut renforcer le service quand elle est bien gérée.

Chaque couche peut aussi introduire sa propre fenêtre de maintenance ou son propre point de défaillance opérationnelle unique.

Les mentions de partenaires technologiques publics ne sont pas des audits de capacité. Elles ne disent pas combien de serveurs sont installés, combien sont réservés, si le stockage est tout-flash ou hybride pour un client spécifique, ou à quelle vitesse un hôte défaillant peut être remplacé dans chaque ville. Elles disent cependant aux acheteurs quoi demander. Un client devrait demander si sa charge de travail repose sur VMware Cloud Foundation, vCloud Director, une pile VMware héritée, du nu métal dédié ou une plateforme de colocation. Il devrait demander si les sauvegardes sont sur la même famille de stockage que la production.

Il devrait demander si l'accès de gestion dépend d'un réseau de contrôle séparé. Il devrait demander comment les changements de licence, en particulier dans l'écosystème VMware, pourraient modifier le prix ou le calendrier de migration.

La même chose s'applique à la sécurité. Un pare-feu géré, un SIEM ou un service de point final peut réduire le risque quand il est doté en personnel et intégré. Il peut aussi créer une dépendance à la disponibilité de la plateforme de sécurité elle-même. Si le plan de gestion de la sécurité tombe en panne, les clients peuvent-ils encore changer les règles de pare-feu? Si un chemin d'ingestion SIEM est retardé, qui le remarque? Si le service est revendu par l'intermédiaire d'un MSP, qui reçoit l'alerte et qui a l'autorité d'approuver le confinement?

Les clients canaux héritent d'une responsabilité en couches

L'orientation exclusivement par canaux de Green Cloud n'est pas une note de bas de page. L'annonce d'acquisition de 11:11 décrivait un réseau national de partenaires de canal de plus de 700 MSP, VAR et consultants IT servant plus de 2 000 entreprises. Cela signifie que de nombreux utilisateurs finaux affectés peuvent ne pas faire l'expérience de Green Cloud comme un fournisseur direct. Ils peuvent en faire l'expérience comme le cloud, la sauvegarde ou le service de sécurité de leur fournisseur technologique local.

La distribution par canal modifie le comportement des incidents. Une entreprise en aval peut appeler le MSP. Le MSP peut ouvrir un ticket avec 11:11 ou un chemin de support Green Cloud hérité. 11:11 peut avoir besoin d'impliquer les équipes cloud, connectivité, sécurité ou facturation. Un fournisseur d'installation, un transporteur ou un vendeur de matériel peut alors être nécessaire pour agir. Chaque transfert coûte du temps. Chaque partie peut avoir une visibilité différente et une autorité différente. Lors d'un petit incident, cette superposition peut être invisible.

Lors d'une panne régionale, d'une migration ou d'un blocage de facturation, elle peut faire la différence entre une récupération mesurée et des jours d'incertitude.

La meilleure façon de réduire ce risque est de définir l'escalade avant l'incident. Les clients finaux devraient savoir quelle partie peut approuver une restauration, quelle partie peut autoriser un basculement, quelle partie peut exporter des données, quelle partie peut modifier le DNS, quelle partie peut provisionner une capacité de remplacement et quelle partie peut communiquer avec les utilisateurs affectés. Les MSP devraient savoir s'ils ont un accès console, un accès API, un accès téléphonique d'urgence et une autorité de modification en dehors des heures de bureau.

L'opérateur de plateforme devrait savoir quels partenaires de canal ont des comptes critiques et quels comptes ont besoin de plans de récupération spéciaux.

Les informations publiques suggèrent que le modèle de canal était central à la croissance de Green Cloud. Leprofil Inc. 5000 de Green Cloudet lapage d'archives de 11:11 célébrant la cinquième apparition de Green Cloud dans la liste Inc. 5000renforcent que l'entreprise était un vendeur d'infrastructure en phase de croissance, pas un département IT d'entreprise statique. La croissance peut être positive, mais dans l'infrastructure, elle soulève une question de capacité: le support, l'inventaire matériel, l'automatisation et les tests de récupération ont-ils suivi l'échelle de la base de partenaires?

Les fenêtres de maintenance font partie du produit

Un service hébergé vend souvent de la continuité, mais il ne peut pas éviter la maintenance. Les mises à jour de firmware, les correctifs d'hyperviseur, les mises à jour de sécurité, la maintenance des routeurs, les changements de contrôleur de stockage, les mises à niveau de plateforme de sauvegarde et les réparations physiques nécessitent tous un travail planifié. Le document SLA et maintenance de Green Cloud rend cela visible en décrivant les fenêtres de maintenance et le traitement des priorités de service.

Encore une fois, le document devrait être confirmé par rapport aux conditions actuelles de 11:11, mais la réalité opérationnelle reste vraie pour tout fournisseur.

La question pratique est de savoir comment la maintenance interagit avec la récupération du client. Si la production et la sauvegarde sont maintenues dans la même fenêtre, un changement échoué peut affecter les deux. Si la réplication du stockage est mise en pause pendant la maintenance, les objectifs de point de récupération peuvent s'étirer. Si un changement réseau touche à la fois les chemins primaire et secondaire, une dépendance commune cachée peut apparaître. Si un événement de maintenance est communiqué par un portail qui est également affecté, les clients peuvent perdre à la fois le service et la visibilité de l'état.

Les agrégateurs d'état publics tels quela page Green Cloud Technologies de StatusGator,le listing de page d'état externe de Rootlyetla page d'état Green Cloud Technologies de Netbeepsont des signaux non officiels. Ils ne doivent pas être traités comme un historique d'incidents faisant autorité. Ils suggèrent que des observateurs externes suivent plusieurs composants de service Green Cloud et que la communication de maintenance/panne fait partie de la façon dont les clients vivent le service. La preuve qui trancherait la question est un archive d'état contrôlée par l'opérateur, une politique de maintenance actuelle et des conditions de notification client.

La maintenance crée aussi un problème de portabilité des données. Les clients testent souvent les sauvegardes quand les systèmes sont sains et découvrent ensuite lors d'un incident que les exportations sont plus lentes, moins complètes ou plus limitées par les permissions que prévu. Un examen de résilience approprié de Green Cloud ou 11:11 devrait inclure une exportation chronométrée de la plus grande charge de travail importante, pas seulement une restauration à partir de la sauvegarde au sein de la même plateforme.

La sortie de données est une tâche physique et opérationnelle: les données doivent être lues du stockage, déplacées sur un réseau, conditionnées dans un format utilisable et remises à quelqu'un ayant l'autorité de les utiliser ailleurs.

La localisation des données dépend des enregistrements, des journaux et des copies de récupération

Le label de zone de service US de Green Cloud est raisonnable, mais la localisation des données ne devrait pas s'arrêter au label de pays. La liste historique des centres de données est basée aux États-Unis. L'empreinte cloud actuelle de 11:11 est mondiale. L'entreprise vend des services cloud, de sauvegarde, de reprise après sinistre, de sécurité gérée et de connectivité. Chaque service peut placer différentes données à différents endroits.

Un client régulé devrait demander six emplacements, pas un. Premièrement, où se trouve l'instance de calcul principale ou l'hôte de nu métal? Deuxièmement, où se trouve la baie de stockage qui contient les données de production? Troisièmement, où les sauvegardes et les instantanés sont-ils stockés? Quatrièmement, où la capacité de reprise après sinistre est-elle réservée ou pré-provisionnée? Cinquièmement, où résident les journaux, les enregistrements de surveillance et la télémétrie de sécurité? Sixièmement, d'où proviennent les tickets de support et les sessions d'administration à distance?

La réponse compte car la localisation cloud peut échouer par catégorie. Un client peut avoir des données de production à Atlanta, une copie de sauvegarde à Phoenix, des journaux de sécurité dans une plateforme de la société mère, des données de facturation dans un autre système et un accès de support depuis plusieurs pays. Rien de tout cela n'est automatiquement faux. Cela peut même être utile pour la résilience. Mais cela doit être divulgué pour que les clients puissent décider si le placement correspond à la vie privée, au contrat, à l'assurance, aux engagements clients et aux règles sectorielles.

La page des régions cloud de 11:11 indique que l'entreprise se concentre sur la sécurité, la stabilité et la souveraineté des données et met l'accent sur la résidence physique garantie. C'est une promesse utile à tester. Un acheteur devrait demander le mécanisme écrit: la garantie s'applique-t-elle par région, pays, installation, produit cloud ou contrat client? Inclut-elle les sauvegardes? Inclut-elle les journaux? Inclut-elle la télémétrie de sécurité gérée? Survit-elle à un basculement de reprise après sinistre? Survit-elle à l'escalade de support?

Le chemin de défaillance est baie, routage, réparation, contrat et sortie

Le chemin de défaillance le plus important de Green Cloud n'est pas un scénario catastrophique unique. C'est une chaîne. Une charge de travail client repose sur une plateforme physique. Elle atteint les utilisateurs via AS54155 ou un chemin parent/partenaire. Elle dépend de la politique de sauvegarde et de stockage. Elle est supportée via un chemin de canal et les équipes de service de 11:11. Elle peut être affectée par la maintenance, la facturation et l'état du contrat. Elle doit être suffisamment portable pour partir si le service ne répond plus aux exigences.

À la couche baie, la question est de savoir si les composants hôte, stockage et réseau ont suffisamment de redondance pour le niveau de service payé. À la couche routage, la question est de savoir si les voisins observés se traduisent par une capacité amont réelle, diversifiée et suffisante. À la couche réparation, la question est de savoir si les pièces de rechange et les techniciens sont disponibles dans la ville où l'incident se produit. À la couche support, la question est de savoir si les bonnes personnes peuvent agir sans attendre les transferts de canal.

À la couche contrat, la question est de savoir quels événements comptent contre les engagements de service et lesquels sont exclus. À la couche sortie, la question est de savoir si le client peut récupérer l'intégralité des données et de la configuration dans un délai imparti.

Les preuves publiques de Green Cloud permettent de poser ces questions avec des précisions. AS54155 est actif. Certains préfixes correspondent directement à Green Cloud. D'autres suggèrent une capacité héritée ou attribuée. 11:11 publie des pages cloud actuelles, cloud privé, colocation et support. Le matériel historique de Green Cloud montre six marchés de centres de données US, un grand réseau de partenaires et une combinaison de services incluant IaaS, sauvegarde, reprise après sinistre, DaaS et sécurité.

Ce que les preuves publiques ne montrent pas, c'est une carte de capacité par produit actuelle, des résultats de tests de basculement audités, des conditions d'exportation client actuelles ou des diagrammes de transit par site.

C'est pourquoi la posture correcte n'est ni le rejet ni la confiance aveugle. Un coquille dormant avec un préfixe unique mériterait une conclusion beaucoup plus sévère. Green Cloud n'est pas cela. Mais une note Forte complète nécessiterait des preuves opérationnelles actuelles qui cartographient le domaine Green Cloud hérité dans les régions cloud présentes de 11:11, prouvent la diversité des chemins, documentent le statut RPKI, expliquent la gestion des adresses acquises et montrent comment les clients peuvent récupérer ou partir sous stress.

Ce qu'un client devrait vérifier avant de s'y fier

Un client ou un partenaire de canal examinant une capacité soutenue par Green Cloud devrait commencer par le calendrier de placement. Le calendrier devrait nommer la ville de production, la ville secondaire, le référentiel de sauvegarde, l'emplacement de journalisation de sécurité et la juridiction de support pour le service réel, pas pour la marque en général. Il devrait dire si le compte repose sur Green Cloud hérité, l'infrastructure héritée de Cirrity, un environnement attribué par INAP, le cloud public de 11:11, le cloud privé de 11:11, le nu métal flexible ou la colocation.

Deuxièmement, le client devrait demander une déclaration de routage et de sécurité d'origine. AS54155 a des annonces IPv4 actives et des voisins observés, mais le client a besoin des préfixes utilisés pour le service, de la conception amont ou de peering, de la politique de filtrage de route et de l'état RPKI pour ces préfixes. Si les ROA ne sont pas présents, le fournisseur devrait expliquer s'ils sont planifiés et comment le risque de détournement de route ou de fuite de route est autrement géré.

Troisièmement, le client devrait tester le basculement, pas simplement lire le langage de récupération. Un test de restauration devrait mesurer la détection, l'autorisation, le basculement, la validation de l'application, l'accès utilisateur, le retour arrière et l'impact sur la facturation. Il devrait inclure le partenaire de canal si le client achète par son intermédiaire. Il devrait inclure le chemin de communication et d'état. Il devrait inclure une escalade de support en dehors des heures normales si la charge de travail est censée être protégée en toutes heures.

Quatrièmement, le client devrait tester la sortie de données. L'exportation devrait inclure les images de machines virtuelles ou les données d'application, les métadonnées, les informations du catalogue de sauvegarde, les règles de pare-feu, les dépendances DNS, la configuration de contrôle d'accès et les journaux nécessaires à l'audit. L'exportation devrait être effectuée sur un chemin réseau réaliste avec un temps d'achèvement mesuré. Une sauvegarde qui ne peut être restaurée qu'au sein du même fournisseur est utile pour de nombreux incidents mais insuffisante pour une défaillance contractuelle du fournisseur ou une migration forcée.

Enfin, le client devrait aligner le contrat avec le chemin de défaillance réel. Le SLA ne devrait pas être lu comme un simple pourcentage de disponibilité. Il devrait être lu comme une carte des dépendances incluses et exclues: joignabilité Internet publique, configuration client, maintenance planifiée, incidents de sécurité, pannes de transporteur tiers, blocages de facturation, erreurs de partenaires et force majeure. Le client devrait savoir quels échecs produisent des crédits, lesquels produisent une aide opérationnelle et lesquels ne produisent rien.

En résumé

Green Cloud Technologies,LLC vend une forme de capacité qui est visiblement réelle mais opérationnellement superposée. Internet public voit toujours AS54155. ARIN lie toujours l'AS à Green Cloud Technologies,LLC. Les archives d'acquisition de 11:11 et les pages cloud actuelles soutiennent l'idée que Green Cloud est devenu partie d'une plateforme d'infrastructure gérée plus large plutôt que de disparaître. Les documents de service historiques, les archives d'acquisition et les références de partenaires montrent une entreprise qui vendait IaaS, sauvegarde, reprise après sinistre, DaaS et sécurité à travers un grand réseau de canaux.

La dégradation est tout aussi importante. Les preuves de ville et de service spécifiques à Green Cloud sont largement historiques. La table de routage publique actuelle est mélangée entre des enregistrements d'adresses directs Green Cloud, acquis et attribués. PeeringDB ne fournit pas de profil d'interconnexion. Les vérifications RPKI échantillonnées sont inconnues. Le modèle de support et de maintenance indique clairement que les fenêtres de réparation, les files d'attente de sévérité et les dépendances exclues comptent.

Le dossier public ne prouve pas que chaque emplacement annoncé ou hérité a une capacité de rechange égale, une diversité de transit égale ou une profondeur de restauration égale.

Pour les lecteurs, la conclusion utile est pratique. Traitez Green Cloud comme une dépendance d'infrastructure en direct dans l'orbite de 11:11, pas comme un simple logo cloud. Avant de placer des charges de travail critiques sur elle, exigez des preuves actuelles de placement de site, de diversité de routage, de capacité de récupération, d'autorité de support, de pratique de maintenance et de portabilité des données. La valeur du service n'est pas seulement dans la machine virtuelle ou le référentiel de sauvegarde.

Elle est dans les racks, les routes, les personnes et les contrats qui doivent encore fonctionner quand le chemin facile a disparu.