La conférence AWS re:Invent se tiendra du 2 au 8 décembre 2024 à Las Vegas. Ippon Technologies sera sur place pour vous faire vivre l’événement. Nous vous proposerons une série d’articles pour décrypter les annonces et les nouveautés en temps réel.
En attendant, nous vous invitons à découvrir les dernières annonces pré-re:Invent. Comme chaque année, AWS multiplie les annonces à l’approche de cet événement, dévoilant des nouveautés programmées pour coïncider avec cette période, mais qui ne seront pas présentées lors des keynotes.
Au vu des annonces déjà faites ces dernières semaines, cette édition du re:Invent s’annonce particulièrement prometteuse en termes de nouveautés et d’innovations (spoiler: il y aura de l’IA), mais pour le moment, faisons le point sur les annonces majeures de ces dernières semaines qui ont retenu notre attention.
Les dernières annonces marquantes
Organisation et Landing Zone
Gestion centralisée des accès root
AWS propose désormais une gestion centralisée des accès root pour les comptes membres via AWS Organizations, offrant une solution plus sécurisée et plus efficace pour les environnements multi-comptes.
Jusqu’à présent, chaque compte AWS disposait de son propre utilisateur root, conçu pour des cas exceptionnels mais doté de privilèges illimités et non restreignables. Cette sensibilité nécessitait des mesures de protection rigoureuses : activer la MFA (authentification multi-facteurs) et restreindre son usage au strict minimum. Cependant, la gestion manuelle de ces pratiques devenait rapidement complexe et chronophage, en particulier dans les organisations avec de nombreux comptes.
Désormais, avec AWS Organizations, il est possible de :
- Supprimer les mots de passe root et empêcher leur récupération, éliminant ainsi les risques liés aux informations d’identification à long terme.
- Utiliser des sessions root temporaires : Ces sessions, limitées en durée et en portée, permettent d’exécuter des tâches spécifiques (comme la suppression d’une politique S3 incorrecte) tout en respectant le principe du moindre privilège.
- Créer des comptes sécurisés par défaut, sans mot de passe root, évitant toute configuration manuelle post-provisionnement.
Cette nouvelle approche est désormais notre principale recommandation pour la gestion des utilisateurs root. Elle renforce considérablement la sécurité tout en simplifiant l’administration dans les environnements multi-comptes.
Security Groups centralisés
Deux nouveautés vont plaire notamment aux équipes sécurité, qui peinent souvent à maintenir des configurations homogènes sur les Security Groups (SG) à travers plusieurs VPCs.
Pour centraliser la gestion des règles de firewall, on utilise souvent des Prefix Lists partagées via AWS Resource Access Manager (RAM). Cependant, cela nécessite de recréer des Security Groups dans chaque VPC, avec des règles référençant ces Prefix Lists, ce qui est lourd à maintenir.
Désormais, il est possible d’associer un même SG à plusieurs VPC dans le même compte. Cela ouvre la voie à des Security Groups gérés centralement, utilisables dans différents VPC, réduisant ainsi le besoin de dupliquer les configurations.
En parallèle, AWS permet désormais de partager des Security Groups entre comptes via RAM, mais uniquement dans un scénario spécifique : lorsque des sous-réseaux d’un VPC centralisé sont partagés avec d’autres comptes. Dans ce cas précis, les SG peuvent également être partagés, simplifiant encore davantage la gouvernance des règles de sécurité.
Resource Control Policies (RCPs)
AWS introduit les Resource Control Policies (RCPs), un nouveau type de politique d’autorisation permettant de contrôler les types de ressources pouvant être créées ou modifiées dans les comptes membres d’AWS Organizations. Cette nouveauté complète les Service Control Policies (SCPs) en ciblant directement les ressources elles-mêmes, alors que les SCPs s’appliquent aux services. Expliquons cela.
Avant les RCPs la gestion des autorisations dans AWS Organizations se limitait principalement aux SCPs, qui permettent de restreindre les actions API exécutables par les utilisateurs IAM d’une organisation. Les RCPs ajoutent une couche de protection, en restreignant les permissions accordées à certaines ressources dans l’organisation. Typiquement, ils s’appliquent aux ressources qui disposent d’une Resource Policy, comme les buckets S3, les clés KMS, les queues SQS ou les secrets dans AWS Secret Manager.
Amazon VPC Block Public Access
Amazon VPC Block Public Access améliore la sécurité des VPC avec un contrôle plus précis sur l’accès Internet dans les VPCs.
À l’image de la fonctionnalité S3 Block Public Access, qui permet de désactiver rapidement tous les accès publics à des buckets, il est désormais possible d’appliquer ce principe aux VPC.
Le blocage peut être configuré de deux façons :
- Bidirectionnel : Bloque tout le trafic Internet entrant et sortant via des Internet Gateways.
- Entrant uniquement : Autorise le trafic sortant via des NAT Gateways ou des Egress-Only Internet Gateways, tout en bloquant les connexions entrantes.
Il est possible de spécifier explicitement les subnets qui feront exception à la règle et qui pourront accéder à Internet (typiquement, nos subnet Egress et Ingress).
Dans la pratique, ces patterns sont souvent déjà utilisés, notamment dans des architectures où les entrées et sorties Internet sont centralisées dans des VPC spécifiques. Cependant, il n’existait jusqu’à présent aucun moyen d’imposer ces politiques globalement ni de prouver facilement leur application.
Exposition d’applications
APIs REST privées avec un Custom Domain Name
Il est désormais possible d’utiliser des noms de domaine personnalisés pour les endpoints privés dans API Gateway.
Jusqu’à présent, ces endpoints utilisaient des noms générés automatiquement par AWS. Pour obtenir un nom personnalisé comme internal-api.company.com, il fallait ajouter un Application Load Balancer (ALB) devant l’API, ce qui complique l’architecture tout en augmentant les coûts et la latence.
Désormais, il est possible de :
- Attribuer des noms de domaine personnalisés directement aux endpoints privés.
- Partager ces domaines entre comptes via AWS Resource Access Manager (RAM).
L’API Gateway gère la terminaison SSL ainsi que le routage des domaines vers les différentes APIs.
Cette fonctionnalité, déjà disponible pour les APIs REST publiques, était attendue depuis longtemps pour les APIs privées. Des indices visibles dans la console laissaient supposer son arrivée imminente, et c’est désormais chose faite.
VPC Origins pour CloudFront
Jusqu’à présent, l’utilisation de CloudFront avec des origines hébergées dans un VPC (comme une instance EC2) nécessitait d’exposer publiquement la source. Pour empêcher l’accès direct à l’origine, il fallait mettre en place une solution de sécurité personnalisée, souvent complexe à gérer, impliquant des firewalls, des ACLs ou du filtrage IP.
Avec cette nouvelle fonctionnalité, CloudFront peut désormais se connecter directement à un ALB ou un NLB situés dans des sous-réseaux privés, éliminant ainsi la nécessité de les exposer publiquement. Cela simplifie considérablement les configurations et rend superflues les mesures de sécurité additionnelles.
Cette simplicité, déjà disponible pour des origines S3 ou Lambda, est désormais étendue à toutes les origines hébergées dans un VPC, ce qui va grandement simplifier la conception et la gestion des architectures cloud.
Modification des en-têtes avec Application Load Balancer
Le Load Balancer phare d’AWS gagne en intelligence avec la possibilité de modifier les en-têtes des requêtes avant de les transmettre au backend, ou des réponses avant de les envoyer au client.
Il est désormais possible de :
- Renommer les en-têtes TLS ajoutés aux requêtes par l’ALB ce qui limite les adaptations à apporter à certains backends
- Ajouter des en-têtes aux réponses tels que HSTS ou CORS, sans avoir à adapter l’application pour cela. A date, cela ne semble possible que via la CLI, la Console AWS ne propose pas encore cette possibilité.
- Désactiver l’en-tête « Server=awselb/2.0 » dans les réponses pour masquer les informations sensibles sur l’infrastructure.
Avant cette nouveauté, ces ajustements nécessitaient soit une implémentation spécifique dans l’application cible, soit l’utilisation de reverse proxies, ajoutant des couches de complexité aux architectures.
Avec cette fonctionnalité native, ces besoins sont désormais directement adressés par l’ALB.
Stockage et données
Aurora Serverless v2 peut scaler jusqu’à zéro
Amazon Aurora Serverless v2 peut désormais réduire automatiquement sa capacité à zéro ACU (Aurora Capacity Unit) en période d'inactivité, permettant de réduire considérablement les coûts pour les applications à usage intermittent.
Avant cette nouveauté, les instances Aurora Serverless v2 ne pouvaient descendre qu’à 0,5 ACU, générant des coûts même en l’absence d’activité. Avec cette mise à jour, les instances peuvent se mettre en pause automatiquement après une période d'inactivité définie. Durant cette pause, aucun coût de calcul n'est facturé, seuls les coûts de stockage persistent. Lorsqu'une connexion est requise, l'instance reprend automatiquement son activité, avec un délai de reprise pouvant atteindre 15 secondes
Une application utilisée uniquement en fin de mois pourrait voir sa base de données mise en pause durant les périodes d’inactivité, éliminant ainsi les frais de calcul. À l’arrivée d’une requête, la base est "réveillée" pour traiter l’opération : la première requête subira une latence plus élevée, mais les suivantes fonctionneront normalement.
Attention, pour le moment, cette fonctionnalité ne fonctionne qu’avec les dernières versions de MySQL (Aurora MySQL 3.08.0 - compatible with MySQL 8.0.39) et PostgreSQL (16.3 or higher, 15.7 or higher, 14.12 or higher, or 13.15 or higher).
À quoi s’attendre pendant le re:Invent ?
Si ces annonces sont un indicateur, les keynotes à venir devraient offrir leur lot de révélations majeures. Vous avez peut-être remarqué le faible nombre d’annonces récentes liées à l’IA et à la data, ce qui laisse présager de grandes annonces dans ces domaines lors des keynotes (et soyons honnêtes, le contraire aurait été surprenant ! 😄).
Nous publierons des articles en temps réel la semaine prochaine pour vous tenir informés des nouveautés les plus marquantes. Préparez-vous à une semaine dense en annonces et suivez-nous sur le blog Ippon Technologies pour une couverture complète de l’événement.
Rendez-vous au re:Invent !
