hariri.ch
Prenez contact

Cloud & Infrastructure

Elastic Beanstalk Cluster Mode : ce que change la mutualisation sur EKS

6 min de lecture

Plusieurs groupes de blocs colorés partagent une plateforme commune, à côté de blocs encore installés sur des bases individuelles.

Un socle partagé plutôt qu’une exploitation application par application

Avec Cluster Mode, annoncé le 17 septembre 2026, AWS fait évoluer Elastic Beanstalk vers l’exploitation de plusieurs applications sur une infrastructure commune, propulsée par Amazon Elastic Kubernetes Service (EKS). Le changement central n’est donc pas seulement technique : il consiste à mutualiser les ressources et à appliquer un même cadre opérationnel à un portefeuille applicatif.

Ce mode entièrement géré prend en charge le déploiement, la mise à l’échelle, les correctifs, la surveillance et les mises à niveau pendant toute la durée de vie de la charge de travail. Selon AWS, le partage des ressources permet de réduire le coût par application à mesure que le portefeuille grandit, sans accroître la complexité opérationnelle.

Cette promesse mérite toutefois d’être confrontée au profil des applications. Cluster Mode ajoute des postes de facturation liés à EKS : il ne constitue donc pas automatiquement l’option la moins chère pour une application isolée.

Du code au cluster, avec plusieurs stratégies de déploiement

Cluster Mode accepte trois points d’entrée : du code source, un Dockerfile ou une image de conteneur. Lorsque cela est nécessaire, Elastic Beanstalk assure automatiquement la conteneurisation avec Cloud Native Buildpacks. L’équipe n’a donc pas systématiquement à fournir une image déjà construite pour déployer son application.

Le premier déploiement associé à un ensemble donné de sous-réseaux déclenche la création du cluster EKS. AWS estime cette étape à environ dix minutes. Les déploiements suivants réutilisent ce cluster : ce délai initial doit être distingué du fonctionnement courant.

Quatre stratégies de déploiement sont prises en charge :

  • All-at-once, pour une mise à jour en une seule fois.
  • Rolling, pour un déploiement progressif.
  • Immutable, pour un déploiement immuable.
  • Traffic-splitting, pour un déploiement avec répartition du trafic.

Un retour arrière automatique est prévu en cas d’échec. Pour les équipes, le choix ne porte donc pas uniquement sur le format livré : il concerne aussi la manière d’introduire une nouvelle version en production.

Observabilité, secrets et HTTPS intégrés au socle

AWS indique avoir reconstruit le socle d’infrastructure d’Elastic Beanstalk autour de plusieurs composants : une observabilité fondée sur OpenTelemetry, une mise à l’échelle pilotée par les événements, une intégration avec AWS Secrets Manager et HTTPS activé par défaut via AWS Certificate Manager.

L’intérêt pratique est de disposer d’un ensemble cohérent de fonctions d’exploitation, plutôt que de traiter séparément ces besoins pour chaque application. Il reste néanmoins utile de distinguer les fonctions annoncées de leurs modalités précises : les éléments fournis ne détaillent pas les paramètres de mise à l’échelle ni les possibilités de personnalisation de l’observabilité.

AWS présente également Elastic Beanstalk comme éligible à HIPAA, conforme à PCI DSS et aligné sur SOC 1, 2 et 3, sans configuration supplémentaire. Cette description porte sur le service ; elle ne doit pas être interprétée comme une validation automatique de la conformité de chaque application et de ses usages.

Le calcul économique dépend du nombre d’applications

Cluster Mode ne comporte pas de frais de service supplémentaires. Les clients paient toutefois les ressources sous-jacentes consommées, notamment le plan de contrôle EKS, le calcul EKS Auto Mode, Amazon ECR et Amazon CloudWatch. Le mode n’est pas éligible à l’offre gratuite AWS Free Tier.

La logique économique repose sur la mutualisation : plusieurs applications peuvent partager des ressources et mieux les occuper. Mais les frais propres à cette infrastructure doivent être compensés par les gains obtenus. Une baisse du coût par application annoncée par AWS ne signifie donc pas nécessairement une baisse de facture dans tous les cas.

Dans son analyse des cas d’usage, AWS recommande de conserver Standard pour les charges dépensant moins de 500 dollars par mois. Son raisonnement est que les frais du plan de contrôle EKS et le surcoût d’EKS Auto Mode peuvent dépasser les économies de mutualisation d’une application unique. Ce montant constitue un repère de décision, pas une garantie de rentabilité au-delà du seuil.

Une migration progressive, sans abandon imposé de Standard

Elastic Beanstalk Standard, fondé sur Amazon EC2, reste entièrement pris en charge. Les environnements Standard et Cluster Mode peuvent coexister au sein d’une même application Elastic Beanstalk. Une équipe peut ainsi migrer environnement par environnement, plutôt que basculer l’ensemble en une seule opération.

Des contrôles de compatibilité interviennent avant toute modification, et aucun environnement n’est forcé de migrer. Pour évaluer le nouveau mode, une démarche raisonnable consiste donc à examiner d’abord la compatibilité, puis les coûts et le comportement opérationnel d’un environnement candidat.

Cluster Mode est disponible de manière générale dans toutes les régions AWS où Elastic Beanstalk est proposé. Cette disponibilité large ne dispense pas d’examiner séparément celle des autres fonctions utilisées autour du service.

GitHub Actions et analyse par IA : deux évolutions distinctes

Cluster Mode s’inscrit dans une évolution plus large d’Elastic Beanstalk. Le 11 février 2026, AWS a annoncé une action GitHub permettant de déclencher les déploiements lors de l’envoi de modifications de code ou de configuration vers un dépôt. Elle peut créer les applications et environnements nécessaires, gérer les paquets avec des exclusions configurables et s’authentifier auprès d’IAM via OpenID Connect.

Le 23 avril 2026, AWS a aussi étendu l’analyse d’environnement par IA à Windows Server, après Amazon Linux 2 et AL2023. Pour Windows, les événements récents, l’état des instances et les journaux sont transmis à Amazon Bedrock pour analyse.

Cette dernière fonction exige une région proposant à la fois Elastic Beanstalk et Bedrock. Ces annonces complètent l’outillage du service, mais ne doivent pas être confondues avec les caractéristiques propres à Cluster Mode.

À retenir

  • Cluster Mode mutualise plusieurs applications sur EKS et gère leur exploitation dans la durée.
  • L’absence de frais de service supplémentaires n’élimine pas les coûts EKS ; AWS privilégie Standard pour les charges de moins de 500 dollars par mois.
  • Standard reste pris en charge, avec une migration possible environnement par environnement après validation de compatibilité.

Publié par :

Sources