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

Résumé

• Green Cloud Technologies, LLC dispose de plus de preuves opérationnelles qu’une simple étiquette d’hébergement dormant: l’ARIN lie l’AS54155 à Green Cloud Technologies, LLC, et la vue de juillet 2026 de RIPEstat montre des annonces IPv4 actives, une large visibilité de routage et six voisins observés. La surface de routage prouve cependant mieux la joignabilité que la diversité des sites, la profondeur du matériel de rechange ou la capacité de reprise pour les clients.
• Les preuves les plus solides concernant l’entreprise sont historiques et transactionnelles. 11:11 Systems a annoncé la clôture de l’acquisition de Green Cloud Defense en décembre 2021, a décrit Green Cloud comme un grand fournisseur IaaS indépendant exclusivement orienté canal, et a répertorié des centres de données à Atlanta, Greenville, Houston, Minneapolis, Nashville et Phoenix. Ces preuves sont réelles, mais les clients actuels ont besoin d’un planning de placement actuel, et non seulement d’une liste de villes datant de l’acquisition.
• Le patrimoine routé de Green Cloud semble composite. Les enregistrements RDAP de l’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 des acquisitions, de la capacité louée et une infrastructure héritée, mais cela signifie également que la propriété, l’accès aux installations et la responsabilité du support doivent être dissociés dans toute évaluation de la 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 l’AS54155 et que 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 éléments qui doivent être prouvés contractuellement.
• Le niveau de preuve est Moyen, pas Fort. Le dossier public de Green Cloud étaye une surface opérationnelle cloud et réseau active, mais la marque a été intégrée à 11:11, la carte opérationnelle spécifique à Green Cloud est datée, et la reprise dépend d’éléments relatifs aux installations, au transit, au support et à l’exportation des données que les pages publiques ne divulguent que partiellement.

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

Green Cloud Technologies, LLC illustre pourquoi la capacité hébergée doit être lue depuis le rack vers l’extérieur, et non depuis la marque vers l’intérieur. L’entreprise vendait de l’infrastructure cloud par l’intermédiaire de partenaires. Le client voyait une machine virtuelle, un poste de travail, un dépôt de sauvegarde, une cible de reprise ou une enveloppe de sécurité gérée. L’obligation opérationnelle sous-jacente était plus concrète: bâtiments, alimentation électrique, refroidissement, baies, hyperviseurs, étagères de stockage, routeurs, interconnexions, contrats de transit, systèmes de supervision et techniciens.

La piste d’identité publique commence par les ressources de numéros.L’enregistrement RDAP de l’ARIN pour l’AS54155nomme GREENCLOUD et répertorie Green Cloud Technologies, LLC comme titulaire.La vue d’ensemble AS de RIPEstatutilise le libellé « GREENCLOUD - Green Cloud Technologies, LLC » et indique que l’AS est annoncé dans sa vue de juillet 2026. C’est une preuve plus solide qu’un site web obsolète, car elle montre une présence active du plan de contrôle internet liée au nom légal.

Cela ne suffit toujours pas à garantir la 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 se trouvent dans des zones de feu distinctes, si le second engagement de transit peut supporter la charge de pointe, ou si des disques de rechange et des serveurs de remplacement sont sur place. L’AS54155 peut établir une périphérie; il ne peut pas à lui seul établir une promesse de reprise.

L’historique de la marque est important, car Green Cloud est passée d’un cloud de canal indépendant à une partie intégrante d’une plateforme d’infrastructure gérée plus vaste.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 orienté canal, au service de fournisseurs de services gérés, de revendeurs à valeur ajoutée et de consultants informatiques. La même annonce précisait que ces partenaires servaient plus de 2 000 entreprises et répertoriait des centres de données à Atlanta, Greenville, Houston, Minneapolis, Nashville et Phoenix. Pour un acheteur, ces faits indiquent que le rayon d’impact ne se limite pas à la liste de clients directs de Green Cloud. Il s’étend également aux entreprises en aval qui peuvent mieux connaître le fournisseur de services gérés local que l’opérateur d’infrastructure derrière le service.

Cela fait de Green Cloud un multiplicateur de dépendances. Lorsqu’un fournisseur de cloud direct tombe en panne, le client voit généralement le nom du fournisseur. Lorsqu’un cloud de canal tombe en panne, la première partie visible peut être le fournisseur de services gérés, 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 capables de changer une route, de remplacer du matériel ou d’approuver une migration. C’est pourquoi la véritable surface opérationnelle de Green Cloud n’est pas seulement l’AS54155.

C’est l’AS54155 plus le canal 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 vivantes, mais pas simples

L’instantané de routage le plus utile n’est pas le slogan de l’entreprise; c’est l’état du routage public.Le statut de routage RIPEstat pour l’AS54155montrait, dans la vue de juillet 2026 utilisée ici, 30 préfixes IPv4, 8 192 adresses IPv4, une visibilité IPv4 complète sur 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 existe 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 également une contrainte utile: la préparation à la double pile ne doit pas être déduite de l’étiquette cloud.

Les clients qui dépendent de la joignabilité IPv6, de la supervision IPv6 seule, du basculement double pile ou d’exigences d’approvisionnement du secteur public ont besoin de preuves produits actuelles plutôt que d’une affirmation générale selon laquelle un fournisseur cloud moderne en disposera.

Les enregistrements d’adresses montrent également pourquoi un récit d’entreprise unique et propre serait trompeur.L’enregistrement RDAP de l’ARIN pour 162.218.104.0pointe vers un bloc Green Cloud.L’enregistrement RDAP de l’ARIN pour 198.71.76.0pointe également 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 étiquettes Green Cloud. Ce schéma correspond à un fournisseur qui a accumulé ou exploité de l’infrastructure acquise, attribuée et louée plutôt qu’à un propriétaire d’un patrimoine d’adresses unique et homogène.

L’indice Cirrity est particulièrement important. Le reportage public deVMblog sur l’acquisition de Cirrity par Green Clouddécrivait Cirrity comme un fournisseur de services cloud d’Atlanta. Si un préfixe actuellement annoncé et originaire de Green Cloud remonte à Cirrity, cela ne prouve pas automatiquement où se trouve une charge de travail actuelle, mais cela explique pourquoi la capacité de Green Cloud doit être examinée comme un patrimoine hérité. Les plateformes acquises apportent souvent des conceptions de stockage, des versions d’hyperviseur, des contrats fournisseurs, des obligations clients et des traditions de maintenance distincts. L’intégration peut améliorer le service; elle peut aussi laisser des coutures cachées qui n’apparaissent qu’en cas de panne.

C’est la première dégradation par rapport à une lecture Forte. Green Cloud est visible sur internet. Ce n’est pas une coquille vide purement administrative. Mais la table de routage actuelle est une carte composite, et les preuves publiques ne permettent pas à un lecteur extérieur de dire exactement quelle ville, quel rack, quel fournisseur ou quel cluster cloud sous-tend chaque charge de travail client.

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

L’annonce de l’acquisition de 2021 est la liste publique de villes la plus claire pour Green Cloud. 11:11 a répertorié des centres de données Green Cloud à Atlanta, Greenville, Houston, Minneapolis, Nashville et Phoenix.L’annonce de l’acquisition par BusinessWireetle communiqué de PRNewswire concernant l’acquisition de Green Cloud par 11:11 Systems, société du portefeuille de Tiger Infrastructurerenforcent le même récit stratégique: Green Cloud était intégrée à une plateforme plus large de connectivité, de cloud et de sécurité.

La liste des villes est précieuse car elle fait passer l’analyse d’une vague étiquette « cloud américain » à un ensemble de marchés physiques. Atlanta est une plaque tournante majeure de la connectivité dans le Sud-Est. Greenville fournit 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 en termes d’alimentation électrique, de tempêtes, de personnel, de densité de transporteurs et de latence client. Un fournisseur unique 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 pourraient se trouver dans une ville tandis que les sauvegardes se trouvent dans une autre. Une cible de reprise après sinistre pourrait être réservée mais sous-dimensionnée. Un pool DaaS pourrait être localisé en fonction des pratiques de support plutôt que des préférences de souveraineté des données. Un service de sécurité pourrait stocker les journaux ou les tickets sur une plateforme différente du service de calcul.

Sans devis, planning de service ou dossier d’architecture actuel, l’ancienne liste de villes doit être traitée comme une géographie à vérifier, et non comme une promesse sur laquelle s’appuyer.

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 répertorie également des centres de données nord-américains dans des grandes villes comme Atlanta, Chicago, Dallas, Los Angeles, New York, San Jose, Scottsdale et Toronto, ainsi que d’autres emplacements dans des États comme la Virginie et le New Jersey. Cela montre une empreinte de la société mère 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 reprise et plus de choix de placement locaux, mais elle peut aussi brouiller les engagements hérités de Green Cloud qui correspondent encore à quelle région 11:11 actuelle. Les clients doivent demander une matrice de placement exacte: calcul de production, stockage répliqué, sauvegardes, snapshots, journaux du plan de gestion, enregistrements de tickets, télémétrie de sécurité et tout accès de support transfrontalier.

Le pays pertinent n’est pas seulement l’enregistrement américain de l’entreprise; c’est chaque lieu où les données, les métadonnées et l’accès opérationnel des clients peuvent résider.

La gamme 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é. Les documents d’acquisition de 2021 décrivaient Green Cloud comme un fournisseur IaaS avec sauvegarde, reprise après sinistre, poste de travail en tant que service et services de sécurité gérés.L’aperçu cloud de 11:11décrit désormais un hébergement cloud public et privé basé sur VMware, un support à la migration, la sécurité, la conformité et la sauvegarde.Le cloud privé hébergé 11:11met l’accent sur le cloud privé mono-locataire, le support à la migration, des configurations prédéfinies et sur mesure, des serveurs dédiés, des choix de stockage et un modèle de résilience N+1.L’environnement cloud flexible et la colocation 11:11étend ce langage au bare metal, à la colocation, au réseau à faible latence, à la supervision et au support 24 heures sur 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 bare metal nécessite de véritables pièces de rechange matérielles, une discipline firmware et un personnel de support capable d’accéder à la machine. Un service VMware nécessite des licences, une gestion du cycle de vie des hyperviseurs, une compatibilité de stockage et des outils de migration. Une extension de colocation nécessite des installations, des cages ou des baies, des commandes d’interconnexion, des interventions à 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 incomplet. 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 panne, ou la capacité d’absorber une panne de toute une ville.

Les clients doivent demander quelle couche bénéficie de la protection N+1: hôtes de calcul, contrôleurs de stockage, commutateurs d’agrégation, routeurs de périphérie, alimentations électriques, refroidissement, dépôts de sauvegarde et 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 d’une bande passante suffisante. Une base de données réglementée peut avoir besoin d’une réplication synchrone ou soigneusement gouvernée, de pistes d’audit, de garanties de rétention et d’une procédure de sortie documentée.

Cette distinction est importante car le modèle historique de canal de Green Cloud peut donner l’impression d’une 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 possède réellement. Lorsque l’inventaire matériel, la puissance électrique en rack ou la marge de transit deviennent rares, la défaillance n’est pas visible comme un échec marketing.

Elle apparaît sous forme de provisionnement lent, de mises à niveau retardées, de fenêtres de restauration contraintes, de reports de maintenance ou de tickets de support nécessitant une équipe plateforme.

Le SLA montre où le client est exposé

L’un des documents publics les plus utiles pour Green Cloud est l’ancienPDF de l’accord de niveau de service et de la politique de maintenance de Green Cloud Technologies. Il est daté et ne doit pas être considéré comme un contrat actuel sans confirmation, mais il reste une fenêtre pratique sur la façon dont Green Cloud encadrait les limites de défaillance. Le document décrit la disponibilité du service autour de l’infrastructure appartenant à Green Cloud, la maintenance planifiée, les niveaux de reprise après sinistre et les priorités de support. Il exclut également les éléments hors du contrôle du fournisseur, tels 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 doivent lire la limite de près. Si le service est joignable à l’intérieur de la périphérie de Green Cloud mais que le chemin FAI du client est rompu, le cloud peut être compté comme disponible alors que le client est hors ligne. 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’une panne imprévue.

La question pratique n’est pas de savoir si le SLA utilise un pourcentage de disponibilité élevé. Il s’agit de savoir quelles pannes comptent, lesquelles 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 gravité inférieure peuvent attendre. Le support d’urgence en dehors des heures normales se concentre sur les incidents critiques. La maintenance est traitée comme un élément normal de la vie du service. En d’autres termes, le support n’est pas un pool infini d’ingénieurs. Il est rationné par gravité, calendrier et droits.

C’est rationnel, mais cela devient un risque pour le client lorsqu’une restauration, une migration ou un changement d’interconnexion tombe en dessous de la priorité la plus élevée même si les propres activités du client sont sous pression.

Lapage de support actuelle de 11:11poursuit le thème des limites de support à plus grande échelle. Elle répertorie des numéros de support mondiaux, des liens de compte et de console, et des contacts distincts pour les services cloud, les services de sécurité, les services de connectivité et la facturation. Cette séparation est utile sur le plan opérationnel, mais elle indique également aux clients de cartographier à l’avance la propriété des pannes. Une charge de travail issue de Green Cloud peut échouer par le calcul, la sécurité, la connectivité, la facturation ou la gestion des accès. Chaque chemin peut avoir une file d’attente et une pratique d’escalade différentes.

Le chemin de facturation mérite attention car les pannes cloud ne sont pas seulement techniques. Un compte suspendu, un litige contractuel, une non-concordance de licence, un solde prépayé épuisé ou un mode de paiement échoué peuvent créer un événement d’indisponibilité 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 en amont, et un litige dans l’une ou l’autre couche peut affecter la continuité du service.

L’examen de la résilience doit donc inclure les règles d’escalade de facturation et de contrôle des comptes, pas seulement les schémas de sauvegarde et de routage.

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

Lavue des voisins ASN de RIPEstat pour l’AS54155a observé six voisins dans les données de juillet 2026 utilisées ici. Les ASN se résolvent en noms de grands acteurs ou pertinents pour l’infrastructure:Cogent,Level 3,Zayo,Hurricane Electric,MegaportetUnitas. C’est mieux que de voir un seul fournisseur amont isolé dans une vue de routage public.

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 fournisseurs amont 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 dépend toujours du chemin d’accès sous-jacent, du port, de la plateforme et du point d’extrémité distant. Un fournisseur peut avoir plusieurs chemins logiques tout en étant vulnérable à une panne d’installation, un arriéré d’interconnexion ou une erreur de contrôle des modifications.

PeeringDB aiderait normalement à combler une partie de cette lacune car il répertorie souvent les installations, les échanges, la politique de peering et des indications de trafic. Dans le cas de Green Cloud, unerecherche API PeeringDB pour l’AS54155n’a renvoyé aucun profil réseau. L’absence de PeeringDB n’est pas un échec en soi. De nombreux fournisseurs légitimes ne tiennent pas de profil à jour. Néanmoins, cela supprime une source maintenue par l’opérateur qui aurait pu clarifier les sites d’interconnexion, la politique de trafic ou les rattachements d’installations. C’est une autre raison pour laquelle le niveau de preuve reste en dessous de Fort.

La sécurité de l’origine des routes est tout aussi incomplète d’après les vérifications publiques. Unerequête de validation RPKI RIPEstat pour l’AS54155 et 162.218.104.0/22échantillonnée a 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. Le statut RPKI inconnu ne prouve pas un mauvais routage et ne signifie pas que la route est inutilisable. Cela signifie que les clients qui s’appuient sur une validation stricte de l’origine des routes doivent demander si des ROA existent pour les préfixes qui transportent réellement leurs services, et si ce n’est pas le cas, quel est le plan de sécurité de routage de l’opérateur.

Des pages de visibilité réseau telles queBGP.tools pour l’AS54155,la boîte à outils BGP de Hurricane Electricetla page IPinfo de l’AS54155sont des contre-vérifications 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 électrique des racks, la diversité des routes, les procédures de restauration ou les obligations commerciales sous-jacentes à chaque session.

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

Green Cloud n’est pas restée immobile avant 11:11. L’entreprise s’est développée par acquisition et par superposition de services de sécurité.La page d’archive de 11:11 concernant l’accord définitif de Green Cloud pour acquérir Cascade Defenseet l’annonce ultérieure d’acquisition et de changement de marquemontrent comment l’entreprise est passée d’une infrastructure cloud brute à la sécurité gérée.La couverture de Cascade par MSSP Alerta situé l’opération sur le marché des fournisseurs de services de sécurité gérés, tandis quela couverture par MSSP Alert de l’acquisition par 11:11a lié la plateforme cloud et 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 approfondi. L’annonce de l’acquisition par 11:11 indiquait que la combinaison ajouterait des capacités de connectivité et de sécurité pour le réseau national de partenaires de canal de Green Cloud. Elle a également mentionné la continuité de la technologie et de la direction après l’opération, ce qui est important pour la transition opérationnelle.

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

Un client qui demande seulement si le fournisseur est « 11:11 maintenant » risque de passer à côté de la question la plus importante: quelle plateforme héritée héberge réellement cette charge de travail?

C’est pourquoi l’historique de Cirrity et Cascade est important 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 mère actuelle. Aucun de ces faits n’est mauvais; ensemble, ils signifient que le client doit exiger une carte. La carte doit relier le service nommé au site physique, au bloc d’adresses, au chemin amont, à la cible de sauvegarde, à la pile de supervision de sécurité, à la file d’attente de support et à l’entité contractuelle.

Les partenariats fournisseurs montrent la forme de la plateforme

Les références technologiques publiques de Green Cloud soutiennent l’image d’une véritable plateforme de capacité hébergée. Unblog 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 lignes d’activité. Unprofil de blog fournisseur cloud VMware de Green Cloud Defensesituait l’entreprise dans l’écosystème des fournisseurs cloud de VMware.L’aperçu cloud de 11:11perpétue maintenant ce cadrage basé sur VMware.

Ces références sont importantes car elles éloignent la discussion du 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 correctifs. Les environnements Cisco UCS ont des interconnexions de matrice, des profils de serveur, des dépendances 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 lorsqu’elle est bien gérée.

Chaque couche peut également introduire sa propre fenêtre de maintenance ou point de défaillance opérationnel unique.

Les mentions publiques de partenaires technologiques 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 indiquent cependant aux acheteurs ce qu’il faut demander. Un client doit demander si sa charge de travail repose sur VMware Cloud Foundation, vCloud Director, une pile VMware héritée, du bare metal dédié ou une plateforme colocalisée. Il doit demander si les sauvegardes sont sur la même famille de stockage que la production.

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

Il en va de même pour la sécurité. Un pare-feu géré, un SIEM ou un service de point d’accès peut réduire le risque lorsqu’il est doté en personnel et intégré. Il peut également 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 modifier les règles de pare-feu? Si un chemin d’ingestion SIEM est retardé, qui s’en aperçoit? Si le service est revendu par l’intermédiaire d’un MSP, qui reçoit l’alerte, et qui a l’autorité pour approuver le confinement?

Les clients du canal héritent d’une responsabilité stratifiée

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

La distribution par canal modifie le comportement en cas d’incident. Une entreprise en aval peut appeler le MSP. Le MSP peut ouvrir un ticket auprès de 11:11 ou d’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 opérateur ou un fournisseur de matériel peut alors devoir intervenir. Chaque transfert coûte du temps. Chaque partie peut avoir une visibilité et une autorité différentes. Lors d’un petit incident, cette stratification peut être invisible.

Lors d’une panne régionale, d’une migration ou d’un verrouillage de facturation, elle peut faire la différence entre une reprise mesurée et des jours d’incertitude.

La meilleure façon de réduire ce risque est de définir l’escalade avant la panne. Les clients finaux doivent savoir quelle partie peut approuver une restauration, quelle partie peut autoriser un basculement, quelle partie peut exporter des données, quelle partie peut changer le DNS, quelle partie peut provisionner une capacité de remplacement et quelle partie peut communiquer avec les utilisateurs affectés. Les MSP doivent 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 ouvrables.

L’opérateur de plateforme doit savoir quels partenaires de canal ont des comptes critiques et quels comptes nécessitent des plans de reprise spéciaux.

Les informations publiques suggèrent que le modèle de canal était central pour la croissance de Green Cloud. Leprofil Inc. 5000 de Green Cloudet lapage d’archive de 11:11 célébrant la cinquième apparition de Green Cloud au classement Inc. 5000renforcent l’idée que l’entreprise était un vendeur d’infrastructure en phase de croissance, et non un département informatique 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 reprise ont-ils évolué avec 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 é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 toutes 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 par priorité de service.

Là encore, le document doit ê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 reprise 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 de stockage est suspendue pendant la maintenance, les objectifs de point de reprise peuvent s’allonger. 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é via un portail qui est également affecté, les clients peuvent perdre à la fois la visibilité du service et celle du statut.

Les agrégateurs de statut publics tels quela page Green Cloud Technologies de StatusGator,la liste de pages de statut externes de Rootlyetla page de statut 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 sur la maintenance/les pannes fait partie de l’expérience client du service. La preuve qui trancherait la question est une archive de statut contrôlée par l’opérateur, une politique de maintenance actuelle et des conditions de notification aux clients.

La maintenance crée également un problème de portabilité des données. Les clients testent souvent les sauvegardes lorsque les systèmes sont sains, puis découvrent lors d’une panne que les exportations sont plus lentes, moins complètes ou plus limitées en autorisations que prévu. Un examen approprié de la résilience de Green Cloud ou 11:11 doit inclure une exportation chronométrée de la charge de travail la plus importante, et pas seulement une restauration depuis une sauvegarde à l’intérieur de la même plateforme.

La sortie des données est une tâche physique et opérationnelle: les données doivent être lues depuis le 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 reprise

L’étiquette de zone de service américaine de Green Cloud est raisonnable, mais la localisation des données ne doit pas s’arrêter à l’étiquette du 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églementé devrait demander six emplacements, et non un seul. Premièrement, où se trouve l’instance de calcul principale ou l’hôte bare metal? Deuxièmement, où se trouve la baie de stockage qui contient les données de production? Troisièmement, où sont stockées les sauvegardes et les snapshots? 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 supervision et la télémétrie de sécurité? Sixièmement, d’où proviennent les tickets de support et les sessions administratives à distance?

La réponse est importante 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 mauvais. 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 aux règles de confidentialité, de contrat, d’assurance, d’engagement client et 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 doit 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 à une escalade de support?

Le chemin de défaillance est: rack, route, 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 l’AS54155 ou un chemin parent/partenaire. Elle dépend de la politique de stockage et de sauvegarde. Elle est supportée par un chemin de canal et les équipes de service 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.

Au niveau du rack, la question est de savoir si les composants hôtes, de stockage et réseau ont une redondance suffisante pour le niveau de service payé. Au niveau de la route, la question est de savoir si les voisins observés se traduisent par une capacité amont réelle, diversifiée et suffisante. Au niveau de la réparation, la question est de savoir si les pièces de rechange et les techniciens sont disponibles dans la ville où la panne se produit. Au niveau du support, la question est de savoir si les bonnes personnes peuvent agir sans attendre les transferts de canal.

Au niveau du contrat, la question est de savoir quels événements comptent par rapport aux engagements de service et lesquels sont exclus. Au niveau de la sortie, la question est de savoir si le client peut récupérer des données et une configuration complètes dans un délai imparti.

Les preuves publiques de Green Cloud permettent de poser ces questions avec des détails. L’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, cloud privé, colocation et support actuelles. Les documents historiques de Green Cloud montrent six marchés de centres de données américains, un vaste réseau de partenaires et une gamme de services qui incluait l’IaaS, la sauvegarde, la reprise après sinistre, le DaaS et la sécurité.

Ce que les preuves publiques ne montrent pas, c’est une carte de capacité actuelle par produit, 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. Une coquille dormante d’un seul préfixe mériterait une conclusion beaucoup plus sévère. Green Cloud n’est pas cela. Mais une note Fort complète nécessiterait des preuves actuelles de l’opérateur qui cartographient le patrimoine hérité de Green Cloud dans les régions cloud actuelles 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 sortir sous contrainte.

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

Un client ou un partenaire de canal examinant la capacité adossée à Green Cloud devrait commencer par le planning de placement. Le planning doit nommer la ville de production, la ville secondaire, le dépôt de sauvegarde, l’emplacement de journalisation de sécurité et la juridiction de support pour le service réel, et non pour la marque en général. Il doit indiquer si le compte repose sur l’infrastructure héritée de Green Cloud, héritée de Cirrity, un environnement attribué par INAP, le cloud public 11:11, le cloud privé 11:11, le bare metal flexible ou la colocation.

Deuxièmement, le client doit demander une déclaration de routage et de sécurité d’origine. L’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 des routes et de l’état RPKI pour ces préfixes. Si les ROA ne sont pas présentes, le fournisseur doit expliquer si elles sont prévues et comment le risque de détournement de route ou de fuite de route est géré autrement.

Troisièmement, le client doit tester le basculement, et pas seulement lire le langage de reprise. Un test de restauration doit mesurer la détection, l’autorisation, le basculement, la validation applicative, l’accès utilisateur, la restauration et l’impact sur la facturation. Il doit inclure le partenaire de canal si le client achète par son intermédiaire. Il doit inclure le chemin de statut et de communication. Il doit inclure une escalade de support en dehors des heures normales si la charge de travail est censée être protégée à toute heure.

Quatrièmement, le client doit tester la sortie des données. L’exportation doit inclure les images de machines virtuelles ou les données applicatives, 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 doit ê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’à l’intérieur du même fournisseur est utile pour de nombreux incidents mais insuffisante en cas de défaillance du contrat fournisseur ou de migration forcée.

Enfin, le client doit aligner le contrat sur le chemin de défaillance réel. Le SLA ne doit pas être lu comme un simple pourcentage de disponibilité. Il doit ê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 transporteurs tiers, verrouillages de facturation, erreurs de partenaires et force majeure. Le client doit savoir quelles pannes donnent lieu à des crédits, lesquelles donnent lieu à une aide opérationnelle, et lesquelles ne donnent rien.

En résumé

Green Cloud Technologies, LLC vend une forme de capacité qui est visiblement réelle mais opérationnellement stratifiée. L’internet public voit toujours l’AS54155. L’ARIN lie toujours l’AS à Green Cloud Technologies, LLC. Le dossier d’acquisition et les pages cloud actuelles de 11:11 étayent l’idée que Green Cloud est devenue partie intégrante d’une plateforme d’infrastructure gérée plus large plutôt que de disparaître.

Les documents de service historiques, les registres d’acquisition et les références de partenaires montrent une entreprise qui vendait de l’IaaS, de la sauvegarde, de la reprise après sinistre, du DaaS et de la sécurité par un vaste réseau de canal.

La dégradation est tout aussi importante. Les preuves spécifiques à Green Cloud concernant les villes et les services sont en grande partie historiques. La table de routage publique actuelle est un mélange d’enregistrements directs de Green Cloud, d’enregistrements 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 gravité et les dépendances exclues comptent.

Le dossier public ne prouve pas que chaque emplacement annoncé ou hérité dispose de la même capacité de rechange, de la même diversité de transit ou de la même profondeur de restauration.

Pour les lecteurs, la conclusion utile est pratique. Traitez Green Cloud comme une dépendance d’infrastructure active dans l’orbite de 11:11, et non comme un simple logo cloud. Avant d’y placer des charges de travail critiques, exigez des preuves actuelles de placement de site, de diversité de routage, de capacité de reprise, d’autorité de support, de pratique de maintenance et de portabilité des données. La valeur du service ne réside pas seulement dans la machine virtuelle ou le dépôt de sauvegarde. Elle réside dans les racks, les routes, les personnes et les contrats qui doivent encore fonctionner lorsque le chemin facile a disparu.