La semaine du 14 septembre, AWS a vendu le platform engineering comme un produit : Elastic Beanstalk Cluster Mode place un portefeuille d'applications sur un EKS partagé et entièrement managé, et la nouvelle expérience de démarrage remet à un nouveau builder un projet préconfiguré au lieu d'un compte vide. En dessous, le compute est devenu moins cher dans deux directions (instances T8i, ARM64 dans ECS Express Mode), PrivateLink a gagné un endpoint tunnel pour partager des segments réseau entiers, et deux changements d'identité ont atterri qui casseront discrètement la supervision si vous les ignorez. L'outillage de migration a été calme cette semaine (rien côté AWS Transform ni DMS), donc l'histoire plateforme ouvre le bal.

Elastic Beanstalk Cluster Mode : l'argument PaaS, encore une fois

Le 17 septembre, AWS Elastic Beanstalk a introduit Cluster Mode : plusieurs applications tournent sur une infrastructure partagée propulsée par Amazon EKS, entièrement managée, avec une seule base opérationnelle. Vous envoyez du source en Java, .NET, Python, Node.js, PHP, Ruby ou Go (ou un Dockerfile, ou une image), Beanstalk le conteneurise avec Cloud Native Buildpacks quand c'est nécessaire, et l'environnement reçoit des déploiements à bascule de trafic avec rollback automatique, de l'autoscaling événementiel, l'intégration Secrets Manager, de l'observabilité OpenTelemetry et du dépannage assisté par IA. Les environnements Standard et Cluster Mode coexistent au sein de la même application, donc vous migrez un environnement à la fois.

L'argument du coût par application est celui que chaque équipe plateforme interne a avancé pour financer un cluster EKS partagé. La différence, c'est qui le fait tourner : AWS, pendant toute la vie de la charge, et vous ne voyez jamais un nœud, un kubeconfig ni une fenêtre de mise à niveau.

Avec vingt petits services et aucune envie de Kubernetes, Cluster Mode est probablement le bon choix par défaut. Si vous avez une équipe plateforme qui possède déjà EKS, Cluster Mode lui dispute les mêmes charges et offre moins de contrôle : pas de politiques d'admission personnalisées, pas de réglage des nœuds, pas de choix de CNI. Le mode de défaillance est celui qu'ont toujours les plateformes partagées, une mise à niveau de la base qui convient à dix-neuf applications et pas à la vingtième, sauf que désormais la vingtième ne peut plus rien figer. Pilotez-le avec les applications dont vous accepteriez volontiers de perdre le contrôle.

Du compute moins cher, de deux façons

Le 17 septembre, les instances EC2 T8i sont passées en disponibilité générale : Intel Xeon 6 de sixième génération sur mesure, cartes Nitro de sixième génération, quatre tailles (nano, micro, small, medium), jusqu'à 30 % de meilleur rapport prix-performance que T3, jusqu'à 70 % de compute en plus, 1,25x la bande passante réseau, 2,4x la bande passante EBS. Même système de crédits CPU avec les modes Standard et Unlimited, donc le passage depuis T3 est un changement de type d'instance et rien d'autre. t8i.micro et t8i.small sont dans le Free Tier.

Le 18 septembre, ECS Express Mode a ajouté ARM64 comme architecture CPU, donc le chemin « donnez-moi une URL pour cette image » peut atterrir sur Graviton, qu'AWS annonce jusqu'à 40 % plus avantageux en prix-performance que x86. Configurable pour les services Express Mode nouveaux et existants via console, CLI, SDK et IaC.

Les deux ne font économiser que si quelqu'un fait le changement. La flotte T3 de la plupart des comptes, ce sont des bastions, des runners de build et des outils internes oubliés ; un changement de variable Terraform et un instance refresh, c'est tout le travail. Pour Express Mode en ARM64, le prérequis est une image multi-arch, et le mode de défaillance est une image de base ou une dépendance native qui n'existe qu'en amd64. Construisez avec docker buildx build --platform linux/amd64,linux/arm64 et laissez la manifest list faire le travail, puis basculez l'architecture.

PrivateLink Tunnel Endpoints : partager un CIDR, pas un service

Le 18 septembre, AWS PrivateLink a annoncé les Tunnel Endpoints, un nouveau type de VPC endpoint. Jusqu'ici, partager des ressources avec un tiers externe signifiait une Resource Configuration par ressource. Désormais une Resource Configuration peut représenter une plage CIDR de votre réseau ; vous la partagez via AWS RAM, et l'autre côté crée un tunnel endpoint et utilise l'encapsulation GENEVE pour atteindre n'importe quoi dans cette plage. Facturation horaire par tunnel endpoint plus un coût par Go de données traitées.

Cela comble l'écart entre PrivateLink (un service, un endpoint, aucune exposition du routage) et Transit Gateway ou le peering (routage complet, dans les deux sens, et une négociation de CIDR). Un fournisseur qui a besoin de quarante hôtes dans votre sous-réseau de management imposait auparavant l'option lourde ; il obtient maintenant un tunnel vers exactement la plage que vous avez nommée.

Le coût par Go en fait un chemin de control plane, pas de transfert de masse ; modélisez le coût avant que quelqu'un y fasse passer des sauvegardes. Et « une plage CIDR » est une autorisation plus large qu'« un service » : la discipline des security groups et des NACL à l'intérieur de cette plage fait maintenant partie de votre surface d'attaque externe, donc traitez la plage que vous exposez comme une DMZ et dimensionnez-la en conséquence.

Deux changements d'identité qui cassent les dashboards

Le 14 septembre, la connexion de l'utilisateur root a commencé à être servie depuis US East (Ohio) et US West (Oregon) en plus de N. Virginia, le trafic étant réparti sur les trois. Bon pour la résilience, mais l'événement CloudTrail ConsoleLogin d'une connexion root est maintenant enregistré dans la Région qui l'a traitée, quelle qu'elle soit. Si votre alarme de connexion root est un metric filter sur un trail us-east-1, elle attrape désormais à peu près un tiers des connexions root. Déplacez-la vers un trail d'organisation ou ajoutez les deux autres Régions cette semaine.

Le 15 septembre, STS a fusionné ses limites de jetons de session en une seule limite de 4 096 octets, remplaçant des plafonds séparés sur la taille du jeton et sur les politiques de session et les tags passés en entrée. STS renvoie maintenant la taille du jeton et le pourcentage d'utilisation, les journalise dans CloudTrail et publie des métriques CloudWatch ; un nouveau paramètre optionnel émet des jetons délibérément gros pour tester si vos proxies et vos en-têtes y survivent. Si vous avez déjà rencontré « packed policy too large », voici le correctif, et le paramètre de test prouve que votre stack tient le plafond avant qu'un tag de session ne vous y pousse.

Aussi cette semaine

Le fil conducteur

Cluster Mode et la nouvelle expérience builder sont le même produit à deux échelles : AWS choisit les défauts et endosse la responsabilité opérationnelle qui va avec. Le prix, c'est que des défauts choisis pour tout le monde ne conviennent parfaitement à personne, et les endroits où ça mord (le réglage des nœuds, une alarme de connexion root qui supposait une seule Région, un jeton de session qui supposait deux limites) sont exactement ceux que les lancements plus modestes de la semaine ont touchés. Le travail de plateforme ne disparaît pas quand AWS fait tourner la plateforme ; il passe de construire la chose à savoir lesquels de ses défauts sont mauvais pour vous.

À lire ensuite

Pour la lecture IA et agents de la même semaine, voyez ercan.ai. Si votre équipe a besoin d'aide concrète sur AWS, l'architecture cloud, les pipelines CI/CD, Linux, GitHub ou GitLab, et le travail de plateforme autour, le volet conseil vit sur ercanermis.com.

Références