AWS a présenté l’une des innovations les plus intéressantes pour ceux qui développent des applications serverless à grande échelle. Avec l’arrivée de Self-Managed Code Storage pour AWS Lambda, les fonctions n’ont plus besoin de stocker leur code dans le stockage géré par le service lui-même. Elles peuvent désormais faire référence directement aux artefacts stockés dans un bucket Amazon S3 appartenant au client. Bien que cette modification semble mineure, elle supprime une limitation historique de Lambda et ouvre de nouvelles possibilités pour les équipes gérant des centaines ou des milliers de fonctions.

Les essentiels d’AWS Lambda Self-Managed Code Storage en 20 secondes

• AWS permet à Lambda de référencer directement le code stocké dans un bucket privé Amazon S3.
• La limite pratique de stockage du code disparaît, dépendant désormais uniquement de la capacité du bucket S3.
• La limite de stockage géré par Lambda passe de 75 Go à 300 Go par région et par compte.
• Le déploiement peut être accéléré, tout en permettant au client de conserver un contrôle accru sur la sécurité, le chiffrement et la reprise après sinistre.

Pendant des années, le stockage du code était une préoccupation mineure pour de petits projets. Cependant, à mesure que les architectures serverless se sont développées, de nombreuses organisations ont fini par gérer des centaines de fonctions Lambda, plusieurs layers partagés, des bibliothèques de plus en plus volumineuses, voire des dépendances en intelligence artificielle ou en traitement de données. Dans ces scénarios, la limite historique de 75 Go par région et par compte pouvait devenir un obstacle, obligeant à demander des extensions via le support AWS. Bien qu’AWS ait déjà porté cette limite à 300 Go, la nouvelle fonctionnalité va encore plus loin en supprimant pratiquement cette restriction.

Ce que change réellement Self-Managed Code Storage

Jusqu’à présent, lorsqu’une fonction Lambda était créée ou mise à jour à partir d’un package ZIP stocké dans Amazon S3, Lambda copié ce package dans un stockage interne géré par le service. Cette copie était utilisée pour exécuter la fonction et comptabilisait dans la limite allouée.

Avec Self-Managed Code Storage, Lambda ne réalise plus cette copie et utilise directement l’objet stocké dans le bucket du client.

En pratique, la différence peut se résumer ainsi :

Modèle traditionnel (COPY)

CI/CD
   │
   ▼
Amazon S3
   │
   ▼
Lambda copie le ZIP
   │
   ▼
Stockage interne de Lambda
   │
   ▼
Exécution

Nouveau modèle (REFERENCE)

CI/CD
   │
   ▼
Amazon S3
   │
   ▼
Lambda référence directement l’objet

Ce changement réduit une étape complète du processus de déploiement, transformant le bucket S3 en la source unique et fiable du code.

AWS indique également qu’à l’issue de ses tests avec une fonction Python 3.13 d’environ 200 Mo, le temps de création de la fonction a été réduit d’environ cinq secondes en utilisant le mode REFERENCE par rapport à l’approche traditionnelle.

Du plafond de 75 Go à un stockage presque illimité

L’avantage le plus visible concerne la capacité de stockage.

Jusqu’à présent, toutes les versions de fonctions et layers stockés par Lambda comptaient dans la limite régionale. Dans des déploiements continus, avec plusieurs environnements ou multiples versions actives, cet espace pouvait rapidement devenir limitant.

Avec le mode REFERENCE, le stockage n’est plus dépendant de Lambda, mais uniquement du bucket Amazon S3.

Par ailleurs, AWS a simultanément augmenté la quota de stockage géré par Lambda de 75 Go à 300 Go par région et par compte. Même ceux qui continuent à utiliser le mode classique disposeront ainsi d’un espace quatre fois supérieur.

COPY vs REFERENCE : quelles différences ?

Il ne s’agit pas uniquement de disposer de plus d’espace ; cela change aussi la gestion du cycle de vie des artefacts.

Une évolution particulièrement adaptée aux pipelines CI/CD

Pour de nombreuses équipes DevOps, ce nouveau fonctionnement paraît tout à fait naturel.

Dans la majorité des pipelines modernes, le processus génère déjà un artefact, le stocke dans Amazon S3, puis déploie l’infrastructure.

Ce même artefact peut désormais devenir directement la copie utilisée par Lambda, évitant ainsi tout dédoublement inutile.

Cela facilite la réalisation d’actions telles que :

• effectuer des rollback en pointant vers une version antérieure de l’objet S3 ;
• centraliser tous les artefacts de déploiement ;
• appliquer les mêmes politiques de chiffrement et de conservation ;
• maintenir une source unique de vérité pour tout le code.

Dans les organisations utilisant plusieurs comptes via AWS Organizations, cela simplifie également la centralisation des paquets de déploiement dans un compte dédié et l’accès contrôlé depuis les comptes de production à l’aide de politiques de bucket.

Une sécurité et conformité renforcées

Un des avantages souvent moins évoqués mais crucial pour beaucoup d’entreprises, concerne le contrôle sur la sécurité.

En devenant propriétaire du stockage où réside le code, le client peut appliquer directement ses politiques AWS S3 :

• chiffrement SSE-KMS ;
• Object Lock ;
• versionnage ;
• audit ;
• politiques IAM spécifiques ;
• rétention d’objets.

Cela facilite la conformité aux exigences internes de sécurité ou obligations réglementaires, sans dépendre uniquement du stockage géré par Lambda.

De plus, avec l’utilisation de S3 Cross-Region Replication (CRR), il est possible de maintenir automatiquement une copie du code dans une autre région, renforçant ainsi la résilience face aux sinistres.

De nouvelles responsabilités pour le client

L’autre face de la médaille : le client devient responsable de la disponibilité du code.

Avec le mode REFERENCE, le bucket doit avoir le versionnage activé, et Lambda doit disposer des permissions pour accéder aux objets via s3:GetObject et s3:GetObjectVersion.

Si une clé KMS gérée par le client est utilisée, Lambda nécessitera également les permissions kms:Decrypt.

Un point important à surveiller : si l’objet disparaît, si la politique du bucket change ou si la clé de chiffrement devient indisponible, Lambda ne pourra plus accéder au code. La fonction pourrait alors passer en état Inactive, ce qui n’arrivait pas lorsque Lambda stockait ses propres copies en interne.

Il est recommandé de mettre en place des politiques de cycle de vie pour supprimer les anciennes versions du code de manière contrôlée, tout en conservant quelques versions disponibles pour d’éventuels rollback.

La prise en charge par Terraform encore en cours d’adaptation

Au moment de l’annonce, AWS a confirmé le support via AWS CLI et AWS CloudFormation.

Cependant, le fournisseur officiel hashicorp/aws pour Terraform n’avait pas encore intégré le paramètre s3_object_storage_mode. En conséquence, de nombreux équipes devront pour l’instant combiner Terraform avec CloudFormation ou la CLI pour déployer des fonctions utilisant ce nouveau mode REFERENCE.

Il est prévu que le support soit intégré dans les futures versions du fournisseur.

Quand envisager d’utiliser REFERENCE ?

Il n’est pas nécessaire pour toutes les organisations de changer immédiatement.

Le mode traditionnel reste tout à fait valable pour de nombreux projets.

REFERENCE est particulièrement pertinent lorsque :

• vous gérez des centaines ou milliers de fonctions Lambda ;
• vous utilisez de nombreux layers partagés ;
• vos pipelines CI/CD utilisent déjà Amazon S3 comme référentiel d’artefacts ;
• vous avez besoin de politiques avancées de sécurité ou de conformité ;
• vous souhaitez maintenir une source unique de vérité pour votre code.

Le mode COPY reste une option intéressante lorsque :

• le projet est de petite taille ;
• les fonctions occuper peu d’espace ;
• les 300 Go disponibles suffisent ;
• vous souhaitez une simplicité opérationnelle maximale ;
• vous utilisez souvent l’éditeur intégré à la console Lambda.

Une évolution logique du mode serverless

Self-Managed Code Storage ne modifie pas la façon dont AWS Lambda exécute le code, mais change la gestion des artefacts de déploiement. Le stockage ne relève plus uniquement de Lambda, mais passe sous le contrôle du client, une approche qui s’intègre parfaitement aux organisations utilisant déjà l’infrastructure as code et des pipelines automatisés.

Au-delà de la suppression quasi totale de la limite historique de stockage, cette fonctionnalité offre un contrôle accru sur la sécurité, la récupération et la gouvernance du logiciel. Elle oblige également à une gestion plus rigoureuse du cycle de vie des objets stockés dans Amazon S3.

Pour les équipes utilisant déjà S3 comme référentiel central, le passage à REFERENCE paraît tout à fait naturel. Pour les autres, l’augmentation de la capacité à 300 Go représente une amélioration majeure sans nécessiter de modification de l’architecture existante.

Questions fréquentes

Qu’est-ce que AWS Lambda Self-Managed Code Storage ?

C’est une nouvelle fonctionnalité qui permet à AWS Lambda d’utiliser directement le code stocké dans un bucket Amazon S3 du client, sans le copier dans le stockage interne géré par Lambda au préalable.

Le plafond de stockage de Lambda disparaît-il ?

La capacité de stockage gérée par Lambda est portée à 300 Go par région et par compte. Si le mode REFERENCE est utilisé, la limite pratique devient la capacité du bucket S3.

Le versionnage du bucket est-il obligatoire ?

Oui. Le mode REFERENCE exige que le bucket ait le versionnage activé afin que Lambda référence toujours une version précise et immuable de l’artefact.

Y a-t-il un coût supplémentaire ?

AWS ne facture pas de coût additionnel pour l’utilisation de Self-Managed Code Storage, mais le stockage dépend de celui d’Amazon S3, et donc seront appliqués les tarifs habituels, y compris pour les requêtes et transferts interrégionaux si applicable.