Analyse des coûts AWS comparant Lambda, EC2, Fargate

Choisir le calcul approprié est un défi lorsque nous avons de nombreuses bonnes options d'AWS. Nos clients sont souvent enthousiastes à l'idée de ne payer que pour les millisecondes d'utilisation plutôt que de payer pour des ressources cloud inactives. Explorons à quoi cela ressemble avec le modèle de tarification de Lambda et comparons-le à d'autres choix de calcul populaires. Voyons quelques exemples de la capacité de Lambda à économiser de l'argent lorsque la charge de travail est inactive. Si la charge de travail change pour qu'elle soit toujours active, découvrons si Lambda pourrait encore économiser de l'argent.

Cas d'utilisation de Lambda / EC2 / Fargate 

Avant de comparer les coûts, notons que nous ne comparons pas des pommes avec des pommes.  

Lambda – Function As A Service 

• Déployer une fonction sur un runtime pris en charge (nodejs, python, ruby, java, go, .net). Vous pouvez utiliser une CLI pour empaqueter votre base de code compilée dans un fichier .zip à déployer. Pas besoin de considérer les conteneurs ou la maintenance des systèmes d'exploitation.
• Déployez un exécutable construit avec n'importe quel langage (par exemple, C++) en utilisant le mode d'exécution personnalisé.
• Déployez un conteneur Docker.

EC2 – Virtual Machine Service 

• Vous obtenez une machine dans le cloud que vous pouvez installer n'importe quel système d'exploitation et exécuter tout ce que vous voulez sans limitations.
• Il existe de nombreux types de machines avec différents modèles de tarification.

Fargate – Calcul sans serveur pour les conteneurs 

• Déployez un conteneur Docker. Vous pouvez faire en sorte que le conteneur s'exécute manuellement une seule fois, qu'il soit programmé ou qu'il s'exécute tout le temps.

• Fargate est un choix de moteur de calcul pour EKS, ou ECS. Les deux sont des services d'orchestration de conteneurs avec des capacités similaires. Fargate peut également être utilisé pour AWS Batch.

Scénario1. Quel est le coût d'une lambda fonctionnant en permanence ? 

En termes plus précis, quel est le coût d'une lambda fonctionnant pendant 1 seconde, chaque seconde de chaque jour pendant 30 jours, avec une simultanéité 1. Concurrence 1 signifierait qu'aucune demande ne se chevaucherait, empêchant ainsi plus d'un lambda de s'exécuter en même temps.  

La documentation indique que les processeurs virtuels sont proportionnels à la mémoire sélectionnée. À l'aide de ces deux articles de guide (1769 Mo, 10 Go) J'ai rempli le tableau ci-dessous, mais vous pouvez le remplir encore plus.

Disons que votre Lambda ne fonctionnerait que la moitié de la journée. Divisez le coût par 2.  Que diriez-vous si le scénario changeait de sorte que 2 requêtes s'exécutaient pendant 1 seconde, se chevauchant chaque seconde de la journée ? Multipliez le coût par 2. C'est l'épée à double tranchant de Lambda. Dix requêtes par seconde sont chères avec un Lambda de 1024 Mo à 430 $/mois. D'un autre côté, s'il ne fonctionnait que 5 minutes au total chaque jour, alors il est bon marché à 4,55 $/mois.

Scénario2. Quel est le coût d'une instance ec2 aux performances similaires ? 

En regardant uniquement les instances à usage général, il existe trois types : Burst, Burst Unlimited[196590xed] ou Fi Performance. Les instances de performances fixes sont plus faciles à comparer à lambda, car lambda est également une performance fixe. Les types de rafales ont des performances et des prix variés, mais je peux montrer deux extrêmes pour donner une limite inférieure et supérieure. Selon l'importance de la charge de travail sur le processeur, les instances en rafale peuvent vous permettre de réaliser des économies ou de devenir plus chères que les performances fixes.

Pour le plaisir, j'ai ajouté les instances M6g à la liste, car ce sont des processeurs ARM personnalisés spécialement conçus par AWS pour le meilleur rapport qualité-prix. Lambda et Fargate ne disposent pas encore de ces processeurs.

* Les instances T3 sont des instances , M5 et M6 sont des performances fixes.
* (b) – Performances de base en rafale avec des crédits CPU épuisés
* (t) – Le processeur est fourni en tant que thread d'un cœur fourni en tant que noyau
* Les prix ci-dessus sont les coûts à la demande. En utilisant des instances ponctuelles, les prix ont environ 70 % d'économies. En utilisant instances réservéesles prix ont en moyenne 30 à 60 % d'économies. En utilisant plan d'économiesles prix permettent d'économiser environ 27 %.

Scénario3. Quel est le coût d'une tâche Fargate aux performances similaires ? 

Fargate a également quelques modes différents à prendre en compte. Vous pouvez exécuter une tâche Fargate comme toujours en cours d'exécution, ou vous pouvez exécuter une tâche ponctuelle à partir d'un calendrier cron ou d'un appel d'API runtask manuel. Pour cet article, j'ai décidé de ne considérer Fargate qu'en mode d'exécution permanente, car la charge minimale de la tâche unique par exécution est de 1 minute. Même si votre élément de travail ne prend qu'une seconde, la facturation sera arrondie à 1 minute. Cela peut être idéal pour les éléments de travail de longue durée, mais j'ai pensé qu'il s'agissait davantage d'un scénario spécialisé que ce que nous essayons de comparer.

Fargate a la possibilité de configurer séparément la mémoire du processeur, ce qui vous permet de choisir plus souvent les ressources de la bonne taille pour votre charge de travail sans payer pour des ressources surprovisionnées. Son prix a des coûts fixes de 3,20 $ par 1 Go et de 29,15 $ par 1vCPU.

* Les prix ci-dessus sont des frais à la demande. En utilisant fargate spotles prix permettent de réaliser des économies d'environ 30 %. En utilisant plan d'économiesles prix permettent d'économiser environ 20 %.

Scénario4. Coût d'opportunité des personnes 

Ces choix de calcul peuvent avoir un impact sur vos équipes de différentes manières. Faites comprendre à l'équipe la quantité de travail et les risques impliqués dans la configuration initiale, mais également tout travail de maintenance périodique. Trouvez un équilibre entre le moment où optimiser les coûts du cloud et le moment où votre équipe doit se concentrer sur la croissance de l'entreprise avec de nouvelles fonctionnalités. Un choix rentable peut être une facture cloud plus chère en fonction de l'expertise de votre organisation et de l'infrastructure établie.  

Une liste de tâches à prendre en compte par votre organisation lors de l'estimation de l'impact des choix d'infrastructure : 

• Configuration de plusieurs environnements (par exemple Test, Dev, Prod) 
• CI/CD – Comment déployer un changement testé dans des environnements.
• Scale Orchestration – Comment et quand mettre à l'échelle.
• Vitesse de mise à l'échelle – Dans quelle mesure un service est-il réactif aux événements de mise à l'échelle.
• Maintenance de la sécurité – Où peuvent exister des vulnérabilités et comment déployer un correctif.

• Couplage des choix d'infrastructure – Dans quelle mesure les choix d'infrastructure devraient-ils avoir un impact sur le code de l'application.
• Dimensionnement correct – Les choix d'infrastructure sont-ils basés sur les charges de travail actuelles ou devrions-nous nous adapter à un objectif commercial à venir. Créez un tableau de bord et une alarme pour savoir quand vos choix peuvent être obsolètes.

Qu'est-ce que tout cela signifie ? 

Dans les scénarios ci-dessus, j'ai essayé d'être aussi factuel que possible sans me prononcer. Ci-dessous, je commence à formuler des opinions sur la base des preuves ci-dessus, mais ces généralités opiniâtres pourraient ne pas correspondre à votre charge de travail ou à votre organisation. Il s'agit de trouver la bonne taille et le bon équilibre pour votre entreprise tout en faisant des choix flexibles pour les objectifs de croissance futurs de l'entreprise.

Nos clients ne veulent pas payer pour des ressources cloud inactives, concentrons-nous donc sur deux scénarios. Un scénario dans lequel la charge de travail est principalement inactive, et l'autre scénario dans lequel une charge de travail est tout le temps active et traite au moins 1 requête. Gardez à l'esprit que Lambda, EC2, Fargate ont tous une taille de mémoire et de processeurs virtuels différents pris en charge. Ci-dessous, je montre quelques exemples de chaque service ayant la possibilité d'un ajustement parfait de la mémoire et du processeur.

Pour EC2, je recommande de profiler votre charge de travail pour découvrir les meilleures performances/coûts. Ici, dans ce tableau, j'ai supposé que M5.large était le résultat de cette enquête pour montrer un exemple de la façon dont vous pouvez évaluer votre situation.

* Les prix sont pour un Fenêtre de 30 jours.
* Le vert est l'option la moins chère pour le scénario, tandis que le jaune est le deuxième moins cher et le rouge est le plus cher.
* cpu+  (cpu est surprovisionné)
* mem+ (la mémoire est surprovisionnée)
* taille correcte (cpu et mémoire correspondent exactement)
 [19659380]Quelques faits saillants émergent du tableau.

1. Lorsqu'il est correctement dimensionné avec des contraintes, EC2 a le meilleur coût.
2. Lorsque les contraintes sont plus petites que la plus petite instance EC2, la flexibilité de Fargate en matière de redimensionnement offre un meilleur coût.
3. Lambda commence à économiser de l'argent par rapport à EC2 une fois qu'il fonctionne la moitié ou moins du temps.
4. Lambda économise de l'argent par rapport à Fargate une fois qu'il fonctionne un quart du temps ou moins.

Lambda 

Idéal pour 

• Les charges de travail avec de longues périodes d'inactivité 
• Minimiser vos coûts d'opportunité[19659012] 
• Isoler votre maintenance de sécurité au seul code d'application 
• Scaling rapide 

Le modèle de tarification de Lambda indique que vous ne payez que pour la durée d'exécution de votre lambda. Par conséquent, votre charge de travail ne coûtera rien lorsqu'elle est inactive. En théorie, les périodes d'inactivité permettront de réaliser des économies, mais mesurez soigneusement le travail car les lambdas simultanés peuvent facilement devenir coûteux. Pour atténuer ce risque, envisagez de placer une passerelle API devant le lambda pour appliquer la limitation du débit. Notez également que choisir le processeur le moins cher n'est pas trivial, car plus le processeur est rapide, plus la durée vous sera facturée. Vous pourriez être surpris de découvrir qu'un choix de processeurs plus élevé est moins cher.

Lambda a pour mission d'être l'une des technologies d'évolutivité les plus rapides dans le cloud. Si vous souhaitez évoluer très rapidement, le coût qui en découle ne vous dérange peut-être pas, surtout si vos revenus augmentent plus rapidement à cause de cela. Notez que vous voudrez envisager d'optimiser les démarrages à froid car vous serez facturé pour cela. Il peut être difficile d'optimiser les démarrages à froid afin qu'un utilisateur frontal ne ressente pas un backend lent. Par conséquent, je ne recommanderais pas de créer quelque chose avec Lambda destiné à l'utilisateur final, comme une API qui bloque l'interface utilisateur.

Les organisations trouveront Lambda facile à utiliser et à entretenir. La plupart du travail consisterait à configurer le pipeline CI/CD. Il n'y a pas de système d'exploitation à maintenir, par conséquent, la maintenance de la sécurité est minimale pour votre code d'application ou votre conteneur Docker.  

Mon dernier conseil est de communiquer avec les ingénieurs d'application le risque / la probabilité que ce choix d'infra Lambda change. Considérez que dans un an ou deux, lorsque le trafic aura changé, serait-il judicieux de rester sur Lambda. Si les ingénieurs d'application s'attendent à un changement, ils peuvent alors organiser le code de manière plus flexible.

EC2 

Idéal pour 

• Les charges de travail qui ont peu ou pas de temps d'inactivité.
• Charges de travail qui bénéficieraient de processeurs ou de GPU spécialisés non encore disponibles pour Fargate / Lambda.

EC2 est idéal pour les charges de travail qui doivent toujours traiter des données. Si votre EC2 ne fait qu'un travail de nuit, vous payez toujours toute la journée pour qu'il soit disponible. Il existe des moyens de désactiver ou de réactiver automatiquement votre instance, mais vous paierez alors les personnes/le coût d'opportunité pour que votre équipe conçoive une solution. De plus, le temps qu'il faut pour qu'un EC2 s'allume est beaucoup plus long que l'heure de démarrage d'un Lambda.

EC2 innove chaque année avec de nouveaux types d'instances pour offrir un meilleur rapport performances/prix dans les scénarios de calcul généraux et de calcul spécialisés auxquels les autres offres sans serveur n'ont généralement pas accès. L'inconvénient est que l'organisation moyenne trouvera EC2 plus difficile à utiliser et à maintenir, ce qui entraînera des effectifs lourds et un coût d'opportunité. Consultez la liste de contrôle avec votre équipe pour déterminer l'ampleur de l'impact. Plus important encore, EC2 dispose d'un système d'exploitation que votre équipe sera chargée de corriger et de mettre à niveau à mesure que de nouvelles vulnérabilités seront découvertes.

Fargate  

Idéal pour 

• Les charges de travail qui ont peu ou pas de temps d'inactivité  
• Réduire vos opportunités coûts 
• Isoler votre maintenance de sécurité sur une image Docker 
• Scaling rapide 

Fargate a des considérations de tarification similaires à celles d'EC2 en ce sens que vous paierez pour les ressources inactives. Avec Fargate, vous pouvez choisir 0,25, 0,5, 1, 2 ou 4 vCPU tandis que EC2 n'offre pas moins de 1 CPU. Si votre situation n'a pas besoin de processeurs lourds, vous pouvez réaliser plus d'économies que EC2 en choisissant ces options de processeurs virtuels inférieurs. Fargate ne prend pas en charge de nombreuses variantes de processeur, car la machine virtuelle sous-jacente (Firecracker) ne prend en charge que les processeurs Intel, mais cela va bientôt changer. Firecracker prendra en charge davantage de types de processeurs, tels que le processeur graviton2 qui se trouve à l'intérieur des instances m6g, augmentant ainsi les performances et réduisant les coûts.  

Fargate peut évoluer plus rapidement que EC2 offrant ainsi une plus grande disponibilité. Il est également plus rapide à réduire en cas de surprovisionnement. Il n'a besoin de faire tourner que des conteneurs par rapport à des systèmes d'exploitation entiers, il nécessite donc moins de ressources pour tourner. Des systèmes d'exploitation entiers peuvent créer des ressources dont vous n'avez pas besoin pour votre application, telles que la mémoire vidéo. Je n'ai pas vu de références comparant cela à Lambda, mais j'imagine que Lambda évolue plus rapidement.

Les organisations trouveront Fargate facile à utiliser et à entretenir, comme Lambda. Il n'y a pas de système d'exploitation à maintenir, la maintenance de la sécurité est donc minimale pour votre conteneur Docker. Lors de la montée en puissance d'une équipe pour se familiariser avec la pile technologique de Fargate, j'ai constaté que Fargate est juste un peu plus de travail que Lambda car il y a plus de boutons à régler. Cependant, si vous adoptez une approche d'infrastructure en tant que code, les modèles par défaut provenant du CDK sont excellents et vous pouvez réduire la complexité à une seule ligne de code avec la possibilité de personnaliser ces paramètres par défaut.

Conclusion 

Beaucoup de nos activités sont motivées par la minimisation des coûts d'opportunité, la minimisation des risques et la maximisation du potentiel de croissance. Lambda et Fargate correspondent bien à ces objectifs, mais les coûts du cloud peuvent être considérablement différents en fonction de la charge de travail. Envisagez d'utiliser Lambda lorsque votre charge de travail a beaucoup de temps d'inactivité, mais ayez un plan si la charge de travail change. Une fois la charge de travail élevée, envisagez de passer à Fargate. Il est facile de changer plus tard si vous utilisez l'infrastructure en tant que code, comme je l'ai décrit dans un article de mon blog précédent. Il suffit de quelques lignes de code pour passer de Lambda à Fargate.  

Pour un calcul à usage général avec des charges de travail en cours d'exécution, EC2 est le moins cher pour la facture cloud. Cependant, cela peut entraîner un transfert des coûts vers votre organisation d'autres manières plus importantes. EC2 pourrait toujours être le bon choix si la charge de travail bénéficierait grandement de nombreuses instances spécialisées, et qu'il n'y a pas beaucoup d'intérêt à avoir besoin d'une mise à l'échelle rapide. Il a des coûts d'opportunité plus élevés, plus de risques de sécurité que vous serez responsable de gérer et évolue plus lentement que Lambda/Fargate, ce qui entraîne plus de problèmes de disponibilité.

Perficient aide ses clients à trouver la bonne taille et le bon équilibre pour votre organisation tout en faisant des choix flexibles pour les futurs objectifs de croissance de l'entreprise. Mon équipe travaille fréquemment au sein d'équipes produit pour les aider à créer de nouvelles applications cloud natives tout en montrant les avantages et les risques du sans serveur. Contactez-nous pour voir comment nous pouvons également aider votre organisation.

À propos de l'auteur

Quincy Mitchell est ingénieur logiciel dans la pratique Custom Development Solutions pour Perficient. Il adore créer des outils qui aident les ingénieurs à faire plus qu'ils ne peuvent imaginer.

En savoir plus sur cet auteur