AWS Lambda, attention aux coûts des logs !

La facturation de AWS Lambda repose sur un modèle pay-per-use, c’est-à-dire que l’on paie proportionnellement au temps d’exécution de chaque fonction lambda. Plus une fonction s’exécute, plus la facture augmente. Le second critère pris en compte est la mémoire allouée. Plus on alloue de la mémoire, plus la facture augmente. Et c’est tout. Enfin presque ! Les logs Clouwatch vont aussi être facturés et il convient donc de maîtriser ces coûts.

Comment sont facturés les logs

Si l’on consulte la page officielle concernant la tarification de Cloudwatch, on constate que la tarification s’effectue selon deux critères. D’une part l’ingestion des données et d’autre part le stockage de ces données. L’ingestion de données correspond aux logs qui vont être écrits. Si l’on prend par exemple la région eu-west-3 (Paris), chaque gigaoctet ingéré sera facturé 0,5985 dollars. Le stockage des données correspond à la durée de rétention de ces données. Pendant combien de temps vont être conservés les logs dans le cloud AWS ? Toujours sur la région eu-west-3, chaque gigaoctet stocké pendant un mois sera facturé 0,0315 dollars. Il est à noter qu’il existe une offre free tiers, ainsi les 5 premiers gigaoctets sont gratuits. Pour le reste il va donc falloir optimiser ces deux aspects.

Configurer la durée de rétention

La première chose à faire est donc de configurer la durée de rétention des logs. Lorsque l’on déploie une fonction Lambda, par défaut, les logs sont configurés pour ne jamais expirer. Il est heureusement possible de changer cela.

Soit en passant par la console :

Une meilleure option est d’éviter d’utiliser la console et recourir à un outil d’infrastructure as code.
Par exemple avec sam vous pouvez ajouter ceci:

LambdaLogGroup:
	Type: AWS::Logs::LogGroup
	DependsOn: [ HelloWorldFunction ] # fonction dont on souhaite configurer les logs
	Properties:
			RetentionInDays: 3
			LogGroupName: !Join ['', ['/aws/lambda/', !Ref HelloWorldFunction]]

La durée exacte à choisir sera souvent un compromis entre l’optimisation des coûts souhaités, les potentielles obligations réglementaires ou encore les besoins en débogage.

Configurer les niveau de log

La deuxième chose à améliorer est le volume de logs envoyés à Cloudwatch.
Il est parfois tentant de se passer d’un framework de log et d’utiliser simplement les fonctions print du langage.

Prenons par exemple cette ligne de code:

fmt.Printf("Received request from ip='%s'\n", string(ip))

Dans Cloudwatch cela donnera le résultat suivant :

Si tu as lu mon article sur le format json pour les logs tu identifies déjà un premier souci. L’autre problème est que cela est probablement une information de débogage. Par conséquent, il n’est pas nécessaire d’afficher cela systématiquement !

C’est là que l’utilisation d’un framework de log est intéressant. Il devient possible de choisir le niveau de log de chaque message. Par exemple la ligne précédente devient :

zap.L().Debug("Received request", zap.String("ip", string(ip))

Enfin vous pouvez choisir le niveau de log à inclure pour votre application. Pour plus de flexibilité il est même possible d’utiliser des variables d’environnements. Ce que j’aime bien faire est d’avoir une variable permettant d’identifier l’environnement de déploiement, dev ou prod, et d’associer un niveau pour chaque environnement. Par exemple debug pour dev et warn pour prod. Je rajoute alors une deuxième variable, comme LOGGER_LEVEL, afin de pouvoir réécrire le niveau par défaut. Cela est utile en cas de problème inconnu en production par exemple.

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 Jp Valery.