Conseil

Bien comprendre la facturation d’AWS Lambda

Le moteur d’orchestration Lambda d’AWS permet de créer et d’activer des fonctions en réaction à des événements. Un mécanisme qui implique un modèle de facture type que cet article tente de décrypter.

Stephen J. Bigelow
par
Publié le: 20 mai 2015

Avec la progression technologique et la multiplication des services Cloud, les développeurs peuvent désormais utiliser des services comme AWS  Lambda pour appeler, orchestrer et exécuter des fonctions et traitements clé de flux de données, et ce sur un mode de paiement à l’usage. Les équipes IT doivent ainsi maîtriser le modèles de facturation afin d’éviter les surprises.

AWS Lambda est un des très nombreux services Cloud offerts par le n°1 du Iaas. Lambda est en fait un service de calcul qui s’active et exécute du code en réaction à un type d’événement. Ce service est par exemple utilisé dans la mise en place de services en back-end à grand échelle ainsi que dans un scenario type de gestion de données récoltées d’un réseau de capteurs puis dirigée vers un autre service – comme par exemple DynamoDB, la base NoSQL de la firme. Ainsi Lambda s’active lorsqu’une tâche doit être effectuée et se désactive pour économiser les ressources et les coûts.

L’IT paie pour chacune des fonctions Lambda, selon un nombre de requêtes – le nombre de fois qu’une fonction est appelée – par mois, plus les coûts liés aux ressources de chaque requête, mesurées en Gigabyte/secondes. Alors que le modèle tarifaire semble simple en surface, nous avons joué avec les chiffres pour se préparer aux coûts associés.

AWS facture un prix référence de 0,20$ pour 1 million de requêtes (0,0000002$ par requête, plus 0, 00001667$ pour chaque Gb/s. Cela peut paraître certes une somme très réduite, mais à cela s’ajoute des millions de requêtes et de multiples fonctions par mois. Toutefois, AWS soustrait l’équivalent de   1 million de requêtes et 400 000 Gb/s par mois, ce qui représente la partie gratuite du service.

Cartographier les services

Pour mieux comprendre le modèle de facturation de Lambda, il faut déterminer la quantité de compute en Gb/s. D’abord, il s’agit d’identifier la quantité de mémoire allouée à la fonction lors de sa création. Si une fonction particulière utilise 256 Mo et est appelée 10 millions de fois sur le mois – chacune pendant une seconde -, cela représente 10 000 000 secondes de temps d’exécution. La demande en compute pour la fonction est donc de 0,25 GB multiplié par 10 000 000 secondes, soit 2 500 000 GB/s. On soustrait 400 000 Gb/s inclus dans le pan gratuit. Cela donne au final 2 100 000 Gb/s de compute facturable à raison de 0,00001667$ par Gb/S, soit 35,01 $ pour le mois.

Maintenant passons au calcul du prix lié au nombre de requêtes. Dans notre exemple, on en compte 10 millions, moins le million gratuit. Soit 9 millions de requêtes par mois à 0,20$ par million de requêtes. Au total, cela donne 1,80$.

Le coût total au mois pour cette fonction Lambda correspond donc à 36,81$. Cela se répète pour chaque fonction Lambda distincte, si vous en utilisez plus d’une pendant le mois.

Les développeurs doivent ainsi avoir connaissance de tous les coûts lorsqu’ils souhaitent planifier et budgétiser les fonctions Lambda. Par exemple, il se peut qu’il y ait des coûts additionnels si une fonction  Lambda transfère des données ou utilise d’autres services AWS. Des coûts en sus peuvent ainsi apparaître pour des requêtes lecture/écriture sur S3 et pour la capacité de stockage. Si une fonction échange également des données avec Amazon DynamoDB, des frais supplémentaires s’appliquent pour le stockage et le transfert de données. Si des données sont importées ou extraites d’AWS, les entreprises seront également facturées pour le transfert de données EC2.

Traduit par la rédaction

Pour approfondir sur PaaS