Nous exploitons trois applications Next.js sur AWS App Runner et avons rédigé un bilan honnête après six mois. La question qu'on nous pose le plus à propos de cet article ne porte pas sur les timeouts ou les health checks. C'est « App Runner n'est-il pas plus cher que Fargate ? »
Par heure-vCPU, oui, d'environ 58 %. Par mois, pour la plupart des petites équipes, non. La différence tient à ce que chaque service facture pendant que personne n'utilise l'application, et à la plomberie que Fargate exige alors qu'App Runner l'inclut. Voici la même application chiffrée des deux façons, au prix catalogue dans us-east-1, avec chaque ligne qui apparaît sur la facture.
Les deux grilles tarifaires
| App Runner | Fargate (Linux, x86) | Fargate (Linux, ARM) | |
|---|---|---|---|
| vCPU | $0,064 par heure-vCPU, uniquement pendant le traitement des requêtes | $0,040478 par heure-vCPU, en continu | $0,03238 par heure-vCPU, en continu |
| Mémoire | $0,007 par Go-heure, en continu | $0,004446 par Go-heure, en continu | $0,00356 par Go-heure, en continu |
| Load balancer | Inclus | ALB : $0,0225/heure + $0,008 par LCU-heure | idem |
| Point d'entrée HTTPS, certificat TLS | Inclus | Certificat ACM sur l'ALB (gratuit) | idem |
| IPv4 publique | Non facturée | $0,005/heure par adresse (ALB et tâches) | idem |
| Savings Plans / Spot | Non | Compute Savings Plans, Fargate Spot | idem |
Les deux facturent à la seconde avec un minimum d'une minute. La ligne qui compte est la première. App Runner divise la vie d'une instance en deux états : provisionnée (elle existe, elle est chaude, elle attend) et active (elle traite au moins une requête). À l'état provisionné, vous ne payez que la mémoire. Fargate n'a pas un tel état : une tâche en cours d'exécution paie son vCPU et sa mémoire chaque seconde où elle existe, qu'elle serve mille requêtes ou aucune.
L'application que nous avons chiffrée
Il s'agit de l'application publique de notre décomposition de facture AWS : une application Next.js pour un client américain, deux instances toujours actives de 2 vCPU et 4 Go chacune, pour qu'un déploiement ou un crash ne la laisse jamais sans capacité. 730 heures dans un mois.
App Runner. La mémoire est payée en continu : 2 instances × 4 Go × $0,007 × 730 h = $40,88. Le vCPU n'est payé que pendant qu'une instance est active : 2 instances × 2 vCPU × $0,064 × 730 h = $186,88 si les deux étaient occupées chaque seconde du mois. Le chiffre réel correspond à $186,88 multiplié par la part du temps où les instances traitent des requêtes. Nous appellerons cette part la fraction d'occupation.
Fargate, x86. Chaque tâche coûte 2 × $0,040478 + 4 × $0,004446 = $0,0987 par heure. Deux tâches pour un mois : $144,16. Puis les éléments qu'App Runner ne vous fait pas penser à ajouter :
- Un Application Load Balancer : $0,0225 × 730 = $16,43, plus environ une LCU en moyenne pour un trafic modeste, $5,84. $22,27.
- IPv4 publique pour l'ALB, une par zone de disponibilité, deux zones : $7,30.
- Les tâches ont besoin d'une route sortante pour appeler des API externes, récupérer des images et envoyer des e-mails. Soit des sous-réseaux publics avec une IP publique par tâche ($7,30), soit des sous-réseaux privés et une passerelle NAT ($32,85 plus $3,65 pour son adresse plus $0,045 par Go traité, ~$37).
Total pour Fargate sur x86 : ~$181 avec des sous-réseaux publics, ~$210 avec des sous-réseaux privés et un NAT. La même configuration sur ARM (Graviton), sous-réseaux publics : ~$152.
Où les courbes se croisent
La facture d'App Runner est $40,88 plus $186,88 × fraction d'occupation. Celle de Fargate est un chiffre fixe. Mettons-les sur le même graphique :
| Fraction d'occupation | App Runner | Fargate ARM, public | Fargate x86, public | Fargate x86 + NAT |
|---|---|---|---|---|
| 10 % | $60 | $152 | $181 | $210 |
| 25 % | $88 | $152 | $181 | $210 |
| 50 % | $134 | $152 | $181 | $210 |
| 75 % | $181 | $152 | $181 | $210 |
| 100 % | $228 | $152 | $181 | $210 |
App Runner reste moins cher que Fargate x86 tant que les instances ne sont pas occupées trois quarts du temps, et moins cher que la configuration en sous-réseau privé presque tout le temps. Graviton déplace le seuil à 60 %.
Ce que « occupé » veut vraiment dire
C'est là que la comparaison part de travers, dans les deux sens. Occupé ne veut pas dire utilisation CPU. Une instance App Runner est active, et facturée pour le vCPU, dès qu'au moins une requête est en cours, avec un minimum d'une minute à chaque réveil. Une seule requête toutes les trente secondes maintient une instance active en continu, même si le CPU reste à 2 %.
La façon honnête d'estimer votre fraction d'occupation est donc de regarder quand il y a du trafic tout court, pas son intensité :
- Une application B2B utilisée aux heures de bureau dans un ou deux fuseaux horaires : occupée environ 10 à 12 heures en semaine, inactive les nuits et les week-ends. Soit 30 à 40 %. C'est l'application publique de notre client, et c'est pourquoi App Runner lui revient moins cher.
- Une application grand public avec un trafic mondial, ou tout ce qui est sollicité en permanence par des monitors, des webhooks et des bots : effectivement 100 %. Ici, Fargate gagne, clairement sur ARM.
- Outils internes, panneaux d'administration, staging : occupés quelques pour cent du temps. App Runner à la taille minimale (0,25 vCPU, 0,5 Go) coûte environ $2,60 par mois au repos. La même tâche Fargate coûte $9 par mois, que quelqu'un l'ouvre ou non.
Vérifiez votre propre chiffre avant de décider. Les journaux de requêtes de l'ALB ou de CloudFront, regroupés par minute, vous diront quelle part des minutes a eu au moins une requête.
La ligne que la plupart des comparaisons oublient
App Runner n'a pas besoin de passerelle NAT pour l'accès Internet sortant avec son réseau par défaut. Dès que vous ajoutez un VPC connector pour que le service puisse atteindre une base de données privée, tout le trafic sortant passe par votre VPC, et il vous faut un NAT pour tout ce qui touche Internet : Stripe, une API d'e-mail, un fournisseur d'identité. C'est notre cas : nos services App Runner parlent à Aurora, donc le compte a déjà un NAT.
Quand les deux options ont besoin du NAT, il s'annule dans la comparaison et le seuil de rentabilité revient à environ 75 % sur x86. Quand App Runner n'en a pas besoin et que Fargate en aurait besoin, ce sont $37 par mois et par compte que seul un côté paie. Avec trois comptes (dev, staging, prod), cela fait plus de $100 par mois, la troisième ligne la plus importante de notre facture.
Quand Fargate est quand même la bonne réponse
Le coût n'est pas le seul facteur, et il y a des cas où nous choisirions Fargate quelle que soit la fraction d'occupation :
- Des requêtes qui durent plus de 120 secondes. Le timeout de la gateway d'App Runner est fixe. Les exports, la génération de rapports et les appels IA longs doivent soit passer par une file d'attente, soit passer sur Fargate.
- Vous voulez des engagements. Les Compute Savings Plans couvrent Fargate, pas App Runner, et Fargate Spot enlève jusqu'à 70 % sur les workers interruptibles. À la taille de notre facture, les engagements n'en valent pas encore la peine ; à dix fois cette taille, si.
- Vous avez besoin de contrôler le chemin réseau : sidecars, service mesh, règles de security group spécifiques par tâche, plusieurs conteneurs dans une même tâche. C'est à ça que sert ECS, et notre guide Fargate couvre la configuration.
- Plusieurs services derrière un seul ALB. Le coût fixe de l'ALB n'est payé qu'une fois. Avec dix services derrière des règles de listener basées sur l'hôte, cela revient à $2 par service, et la comparaison bascule en faveur de Fargate pour les services occupés.
Ce que nous ferions
Pour une petite équipe qui livre des applications web, commencez sur App Runner. C'est moins cher au niveau de trafic que connaissent réellement la plupart des jeunes produits, il n'y a ni ALB, ni target groups, ni sous-réseaux à gérer, et passer à Fargate plus tard est un changement dans la stack CDK, pas dans l'application, puisque les deux exécutent la même image de conteneur (gardez-la petite dans tous les cas).
Reconsidérez la question quand un service est occupé la majeure partie du mois, ou quand sa ligne App Runner dépasse quelques centaines de dollars. À ce moment-là, faites tourner ce service-là sur Fargate avec Graviton, et laissez les services calmes où ils sont.
Si vous voulez que ce calcul soit fait pour votre propre trafic et votre architecture, parlez-nous. C'est généralement un exercice d'une heure avec votre Cost Explorer ouvert.