Les variables d’environnements permettent d’assurer une stricte séparation de la configuration et du code lorsque l’on utilise des fonctions Lambda. C’est le cas par exemple lorsque l’on doit écrire dans un bucket S3, le bucket cible ne sera pas le même entre les déploiements. En utilisant une variable d’environnement il est alors possible de déployer le même code sur plusieurs environnements (production, dev, recette) et plusieurs régions. La configuration du niveau des logs entre les environnements est aussi un cas d’utilisation possible des ces variables d’environnements.

Il existe toutefois une limite fixée par AWS à ne pas dépasser, qui est de 4 kilo-octets. Il y a quelques semaines j’ai été confronté au problème de la dépasser et je vais donc partager les différentes solutions possibles.

Faire le ménage

La première chose à faire est de vérifier que toutes les variables actuellement définies sont bien utilisées. Dans mon cas par exemple, après analyse j’ai découvert que l’on avait dix variables qui contenaient la même valeur. Par conséquent, le code a été simplifié pour utiliser une seule variable.

Parameter Store

Dans certains cas, il ne sera pas possible de faire le ménage. Il va donc falloir réfléchir à stocker cette configuration ailleurs. Une des options possibles est le Parameter Store, qui fait partie de Systems Manager. Pour faire simple, Parameter Store est un service qui stocke des chaînes de caractères. Ces chaînes de caractères sont réparties en trois catégories : String, StringList et SecureString.

La première, String, va stocker la donnée brute, sans la chiffrer. StringList quant à elle contient une liste de valeurs séparées par des virgules. Là encore aucun chiffrement n’est effectué sur la donnée. Enfin, SecureString permet de stocker une donnée de manière chiffrée. Typiquement cela est utilisé pour une donnée sensible qui doit être stockée et référencée de manière sécurisée, comme par exemple une clef d’API.

Il existe également une limite de 4 kilo-octets, mais par paramètre stocké. Au niveau des coûts, le stockage des paramètres est gratuit et la consultation des paramètres est gratuite si l’on n’excède pas les 40 requêtes par seconde.

Secrets Manager

Lancé en 2018, le service Secrets Manager peut de prime abord sembler identique au Parameter Store. Dans les faits, et comme son nom l’indique, il a pour but de faciliter la gestion des secrets, c’est-à-dire des variables sensibles.

Au-delà du chiffrement à l’aide KMS, son atout est de gérer la rotation de ces secrets. Cette rotation est soit intégrée nativement à Secrets Manager, par exemple pour les identifiants d’une base RDS, soit configurable via une fonction lambda implémentée spécifiquement pour cela.

Chaque secret à une taille maximale de 10 kilo-octets et sera facturé $0.40 par mois. La consultation des secrets sera facturée 0,05 $ par tranche de 10 000 appels API.

Un fichier sur S3

Une autre approche possible est de stocker la configuration dans un fichier sur S3. Cela est particulièrement pratique quand on a une configuration structurée, pouvant être représentée sous forme d’arbre.

C’est d’ailleurs l’implémentation que j’ai choisie pour mon projet budgetcategorizer. Un fichier au format yaml contient toute la configuration et une variable d’environnement indique à ma fonction lambda l’endroit où se trouve ce fichier.

L’avantage de cette approche est le faible coup. Stocker un giga-octets sur S3 coûte environ 3 centimes, je te laisse faire le calcul pour un fichier de quelques kilo-octets. L’inconvénient est que la lecture du fichier depuis S3 va impacter légèrement le cold start de la lambda.

Morceler la lambda

Enfin la dernière option possible est de refactorer la lambda. Peut-être que la lambda au fil de ses évolutions a trop grossie. Elle se retrouve alors à assumer plusieurs responsabilités, ce qui complexifie son code et augmente le nombre de variables d’environnement. La solution est alors d’éclater ce monstre en plusieurs fonctions plus petites, ayant chacune une responsabilité bien définie.

Si tu es arrivé jusqu’ici, merci beaucoup d’avoir lu cet article !
Pense à t’abonner à la mailing list pour ne rater aucun article, le formulaire se trouve en bas de page.
Photo de couverture par Marcin Simonides.