PaaS sur AWS : services, coûts et critères de choix

Le PaaS sur AWS consiste à utiliser des plateformes applicatives gérées pour déployer des logiciels avec moins d'administration de l'infrastructure. Amazon Web Services propose plusieurs voies : Elastic Beanstalk pour les environnements applicatifs, Amazon ECS Express Mode pour les services web conteneurisés, AWS Amplify Hosting pour les frameworks web compatibles et AWS Lambda pour le calcul serverless. Les bases de données et le stockage constituent des éléments distincts de l'application.

Le choix dépend du fonctionnement de votre code, de l'emplacement de son état persistant et des tâches d'exploitation que votre équipe souhaite conserver. Une plateforme gérée peut provisionner des ressources et automatiser des opérations courantes, mais vous restez responsable de l'application, de ses autorisations et de son comportement sous charge.

Ce guide s'appuie sur la documentation AWS vérifiée le 14 octobre 2026. Un changement important concerne les anciens comparatifs : AWS App Runner est fermé aux nouveaux clients. Les clients existants peuvent continuer à l'utiliser, y compris pour créer des services, mais AWS ne prévoit plus de nouvelles fonctionnalités et recommande d'évaluer ECS Express Mode pour une migration.

Ce que signifie « plateforme en tant que service » sur AWS

La plateforme en tant que service, ou PaaS, fournit un environnement de déploiement et d'exploitation des applications, tandis que le fournisseur cloud gère une partie des couches techniques sous-jacentes. Elle se situe entre la location d'infrastructure et l'utilisation d'un logiciel prêt à l'emploi. Notre guide des modèles de services cloud explique les différences générales entre IaaS, PaaS, SaaS et serverless.

Avec l'infrastructure en tant que service, comme une machine virtuelle Amazon EC2 classique, vous choisissez et gérez davantage le système d'exploitation et la pile applicative. Une offre PaaS peut gérer le déploiement, les contrôles de santé et la mise à l'échelle autour de votre code. Le logiciel en tant que service donne accès à une application déjà construite plutôt qu'à une plateforme pour votre propre code.

AWS est un fournisseur cloud dont les services couvrent ces différentes catégories. Qualifier l'ensemble d'AWS de « PaaS » masque des distinctions utiles. De même, serverless décrit une approche d'exploitation, pas un ensemble universel de fonctions. Examinez le service et son mode de déploiement précis au lieu de supposer que cette étiquette signifie absence de maintenance, de frais au repos ou de limites de capacité.

Comparer les principales options PaaS sur AWS

Option	Point de départ adapté à	Points à examiner
Elastic Beanstalk Standard	Applications web sur des plateformes compatibles, dont Windows	Version de plateforme, ressources EC2, paramètres d'environnement et politique de mise à jour
Elastic Beanstalk Cluster	Applications déployées par Beanstalk sur une base EKS	Conteneur ou compilation des sources, capacité partagée et frais EKS sous-jacents
Amazon ECS Express Mode	Applications HTTP et API sans état, conditionnées en conteneurs	Image, rôles IAM, réseau, contrôles de santé et limites de mise à l'échelle
AWS Amplify Hosting	Frameworks web frontend et full-stack compatibles	Compatibilité du framework, compilation, rendu serveur et ressources backend
AWS Lambda	Composants applicatifs serverless et modes de calcul pris en charge	Type de fonction, modèle d'exécution, quotas, intégrations et facturation
AWS App Runner	Clients existants exploitant des applications App Runner	Position actuelle du support et voie de migration testée
Amazon RDS et DynamoDB	Données persistantes gérées, en complément d'une plateforme applicative	Modèle de données, accès, restauration, disponibilité et capacité

Ces services ne sont pas interchangeables. Une base de données ne déploie pas votre application web, et le calcul conteneurisé ne définit pas à lui seul son processus de livraison. Choisissez d'abord l'environnement d'exécution, puis les services de données et d'intégration dont il a besoin.

AWS Elastic Beanstalk

Elastic Beanstalk provisionne un environnement applicatif et coordonne notamment le calcul, la répartition de charge, la surveillance de santé et la mise à l'échelle. Sa documentation actuelle distingue le mode Standard, qui exécute les applications directement sur EC2, du mode Cluster, qui utilise Amazon EKS.

Standard prend en charge des familles de plateformes établies, notamment Java, .NET, Node.js, Python, PHP, Ruby, Go et Docker. Vérifiez la version compatible avec votre environnement précis : le nom d'un langage ne garantit pas toute la compatibilité. Le mode Cluster accepte une image de conteneur ou des sources que Beanstalk transforme en image.

Beanstalk convient lorsque vous recherchez un déploiement centré sur l'application tout en gardant une visibilité sur les ressources AWS sous-jacentes. Avant de choisir un mode, déterminez qui gérera les mises à jour de plateforme, les dépendances, la configuration et la restauration. Un premier déploiement réussi ne répond pas à ces questions d'exploitation continue.

Amazon ECS Express Mode et Fargate

ECS Express Mode crée un service ECS sur Fargate avec la configuration réseau, la répartition de charge, la surveillance et la mise à l'échelle associées. Pour le parcours de base à partir d'une image, vous fournissez une image de conteneur, un rôle d'exécution des tâches et un rôle d'infrastructure.

Il convient aux services HTTP et aux API sans état. L'image doit démarrer correctement, écouter sur le port configuré et proposer un contrôle de santé utile. Conservez les données durables hors des conteneurs remplaçables. Notre comparatif entre machine virtuelle et conteneur aide à préciser ce choix de conditionnement.

Fargate fournit le calcul conteneurisé géré ; ECS coordonne les tâches et services. Express Mode ajoute un parcours de déploiement avec des choix préconfigurés autour de ces composants. Vous devez toujours choisir les ressources, les accès et les limites de capacité adaptés, et comprendre les ressources créées dans votre compte.

AWS Amplify Hosting

Amplify Hosting propose un processus fondé sur Git avec déploiement continu pour les applications web compatibles. Il prend en charge les sites statiques, les applications monopages et les frameworks de rendu serveur compatibles, avec notamment des déploiements de prévisualisation et des domaines personnalisés.

C'est une option à examiner lorsque le framework frontend et le processus de compilation déterminent l'essentiel des besoins d'hébergement. Vérifiez la version exacte du framework et les fonctions nécessaires avant de le choisir. La compatibilité d'hébergement ne signifie pas que chaque extension, fonction serveur ou dépendance backend est prise en charge.

Amplify Hosting et le backend d'une application sont liés, mais distincts. L'authentification, les API, les bases de données et les traitements en arrière-plan peuvent créer d'autres ressources et responsabilités. Intégrez-les à l'architecture et à l'estimation des coûts plutôt que de considérer le frontend comme l'ensemble du système.

AWS Lambda

Lambda fournit du calcul serverless, mais sa famille de produits actuelle dépasse la fonction classique déclenchée par un événement. La documentation tarifaire Lambda distingue les Event Functions, Web Functions et MicroVMs, avec des modèles de facturation différents. Ce guide utilise le traitement événementiel comme exemple courant sans traiter toutes les options Lambda de la même manière.

Une fonction qui traite un fichier téléversé ou consomme une file de messages peut fonctionner indépendamment de l'application web. Concevez les gestionnaires en fonction des reprises et des modalités de livraison de leur source d'événements, notamment de l'effet des événements répétés sur les données enregistrées. Réussir une requête de test ne garantit pas le fonctionnement lorsque de nombreuses requêtes arrivent ensemble.

Consultez les quotas Lambda actuels pour le type d'exécution et le mode d'invocation choisis. Durée maximale, mémoire, concurrence et limites d'intégration comptent. Évitez d'affirmer que chaque fonction démarre instantanément ou que toute architecture serverless ne coûte rien lorsqu'elle est inactive.

Bases de données gérées et stockage objet

Amazon RDS gère des tâches courantes d'administration des bases relationnelles. Vous choisissez toujours le moteur et sa configuration et restez responsable du schéma, des requêtes, des accès et des exigences de restauration. Les réplicas de lecture, le basculement et les sauvegardes répondent à des besoins différents ; aucun ne remplace les autres.

DynamoDB est une base NoSQL serverless gérée. Son adéquation dépend des modes d'accès et de la modélisation des données, pas simplement du caractère « moderne » de l'application. Concevez les clés, les requêtes et le comportement de capacité autour de la tâche réelle.

Amazon S3 fournit du stockage objet pour des éléments tels que les fichiers téléversés et les ressources statiques. Ce n'est ni une base relationnelle ni un environnement général d'exécution applicative. Déterminez où placer chaque type d'état persistant avant de dimensionner la couche applicative.

Combien coûte le PaaS sur AWS ?

Il n'existe pas de tarif d'abonnement unique au PaaS AWS. La facture dépend des ressources, requêtes, données stockées et fonctions optionnelles utilisées. Partez d'une architecture et d'une estimation de charge, puis appliquez les tarifs régionaux actuels. Une fourchette mensuelle générique pour une « petite application » est peu fiable sans hypothèses sur le trafic, la base de données, la disponibilité et le réseau.

Beanstalk n'ajoute pas de frais de service propres dans ses deux modes, mais les ressources sous-jacentes sont facturées. Le mode Cluster ajoute les frais du plan de contrôle EKS et de gestion Auto Mode aux services de calcul et autres ressources concernés. ECS Express Mode n'ajoute pas non plus de frais de service, mais son infrastructure reste payante.

Poste de coût	À inclure dans l'estimation	Question à poser
Calcul applicatif	Capacité active, durée d'exécution, requêtes et options de capacité payantes	Quelles ressources restent provisionnées quand le trafic baisse ?
Base de données et stockage	Capacité, opérations, sauvegardes, réplicas et données conservées	Que faut-il pour atteindre l'objectif de restauration ?
Réseau	Répartition de charge, transferts et services réseau de l'architecture	Où les données circulent-elles, et à quelle fréquence ?
Compilation et surveillance	Compilations, stockage des images, journaux, métriques et conservation	Quel volume de diagnostic sera conservé ?
Exploitation	Support, maintenance, migration et réponse aux incidents	Qui assure le travail que la plateforme ne réalise pas ?

Estimez séparément les périodes calmes, la charge attendue et les pics. Dimensionner la couche web ne corrige pas une base de données surchargée, et une capacité minimale peut créer un coût de base. Les engagements et remises exigent leurs propres hypothèses d'utilisation ; ils ne réduisent pas tous les postes de la facture.

AWS Budgets peut signaler les dépenses réelles ou prévues, mais les alertes peuvent arriver après l'accumulation des coûts. Une notification budgétaire est un outil de surveillance, pas un plafond de dépense garanti. Définissez qui réagit et quelles ressources peuvent être arrêtées sans conséquence indésirable.

Vérifiez les conditions actuelles d'AWS Free Tier pour le compte et les services concernés. Ne supposez pas que chaque configuration est éligible ou reste gratuite après la période de découverte. Notre guide de comparaison des coûts cloud explique comment intégrer l'effort d'exploitation à l'évaluation des options.

Sécurité et exploitation restent des responsabilités partagées

Le modèle de responsabilité partagée d'AWS varie selon le service utilisé. L'infrastructure gérée réduit une partie de l'administration, mais le code, les données clients, les autorisations et la configuration exigent toujours des décisions du client. Le choix d'une plateforme ne suffit pas à établir que l'application respecte ses exigences de sécurité ou de conformité.

Attribuez à l'automatisation des déploiements et au code applicatif des autorisations distinctes et limitées aux besoins. Ne placez pas d'identifiants secrets dans les dépôts de code ou les images de conteneurs. Examinez explicitement l'exposition publique et documentez la mise à jour des secrets, dépendances et droits d'accès.

Définissez la restauration de manière mesurable : quelle perte de données est acceptable et combien de temps le rétablissement peut-il prendre ? Testez une restauration, un retour à une version précédente et la perte d'une instance ou d'une tâche active. La surveillance de santé signale un problème ; elle ne prouve pas que l'équipe sait rétablir le service.

Les outils d'intégration et de livraison continues, dont AWS CodePipeline lorsqu'il convient, peuvent automatiser les mises en production. Ils ont toujours besoin de tests, d'une configuration versionnée et d'un plan de retour arrière. Gardez les changements de production vérifiables et permettez d'identifier précisément la version applicative en cours d'exécution.

Réaliser un petit déploiement pilote avant de s'engager

Testez le choix sur un parcours applicatif représentatif. Par exemple, une API conteneurisée sans état avec une base de données séparée peut servir de pilote ECS Express Mode. Il s'agit d'une démarche d'évaluation illustrative, pas d'un benchmark ni d'une garantie d'adéquation à toutes les applications.

1. Définir les critères d'acceptation

Consignez l'environnement d'exécution, le trafic, le temps de réponse maximal acceptable, les tâches en arrière-plan et les besoins en données. Ajoutez les restrictions d'accès, les régions nécessaires, les objectifs de restauration et le budget d'exploitation. Déterminez quel résultat éliminerait la plateforme avant d'investir dans son intégration.

Repérez les dépendances à un disque local, aux sessions en mémoire, à un GPU, à des privilèges système ou à un processus de longue durée. Ces contraintes peuvent peser davantage sur le choix du service que le langage de programmation.

2. Rendre la livraison reproductible

Construisez un artefact versionné avec des versions de dépendances fixées et une configuration documentée. Pour les conteneurs, vérifiez que l'architecture de l'image correspond au calcul cible. Séparez les données de test de la production et assurez-vous que remplacer une instance ou une tâche ne supprimera pas l'unique copie de données importantes.

Utilisez un point de contrôle de santé pertinent et testez localement les échecs de démarrage. Un processus actif apporte moins de garanties qu'une application prête à traiter les requêtes attendues.

3. Configurer explicitement le service choisi

Pour l'exemple conteneurisé, suivez le guide de la console ECS Express Mode. Sélectionnez l'image et les rôles requis, puis vérifiez le port, le chemin de santé, le CPU, la mémoire, les nombres minimal et maximal de tâches, le réseau et la journalisation avant la création. Privilégiez une empreinte d'image immuable pour identifier la version testée.

La référence de l'API du service distingue le rôle d'exécution utilisé pour les opérations de la tâche du rôle de tâche utilisé par le code applicatif pour appeler les services AWS. Ne corrigez pas une erreur d'autorisation en accordant à l'application un accès illimité au compte.

4. Tester le parcours complet d'une requête

Exercez l'authentification, les lectures et écritures en base, les téléversements et les dépendances de file de messages ou de notification. Mesurez les temps de réponse et les erreurs avec un trafic représentatif. Incluez des requêtes répétées, des entrées invalides, des dépendances indisponibles et un déploiement pendant que le trafic est actif.

Observez l'application et la base de données lorsque la capacité évolue. Davantage d'instances applicatives peuvent épuiser les connexions à la base ou multiplier les tâches en arrière-plan si la coordination manque. Consignez les échecs et la reprise, pas seulement le débit maximal atteint.

5. Vérifier les versions, la restauration et la facture

Déployez une nouvelle version, puis revenez à la précédente. Vérifiez que les changements de base de données restent compatibles avec ce retour arrière. Entraînez-vous à restaurer les données nécessaires dans un environnement séparé afin que la restauration ne reste pas un simple réglage non testé.

Examinez les ressources créées et comparez l'utilisation observée à l'estimation. Incluez les répartiteurs de charge, journaux, images, stockage et composants réseau. Observez assez longtemps pour comprendre le coût de base et le travail facturable au-delà d'une seule requête réussie.

6. Consigner la décision et terminer le pilote

Conservez la configuration, les données de test, les résultats, les limites connues et le nom du responsable d'exploitation. Si le pilote réussit, préparez les accès de production, les validations de déploiement, la surveillance et la restauration avant de déplacer le trafic réel.

À la fin du pilote, identifiez les ressources et données conservées qui peuvent être supprimées, puis retirez-les par le processus du service concerné. Vérifiez que les documents ou sauvegardes nécessaires sont préservés et recherchez les ressources encore facturées. Arrêter le trafic applicatif n'arrête pas tous les frais.

Migrer une application App Runner existante

Les clients App Runner existants ne doivent pas interpréter la restriction visant les nouveaux clients comme un avis d'arrêt immédiat. Utilisez la position actuelle du support pour planifier une migration. Inventoriez d'abord l'image ou la compilation des sources, la configuration, le domaine, les secrets, les connexions réseau et les contrôles d'exploitation.

ECS Express Mode exige une image de conteneur : un déploiement App Runner fondé sur les sources nécessite donc une étape de compilation qui la produit. Validez le service de remplacement avant de déplacer le trafic. Le guide AWS utilise un routage DNS progressif lorsqu'un domaine personnalisé commun est disponible ; une URL de service par défaut exige une autre transition des clients ou des points d'accès.

Conservez une voie de retour arrière testée pendant la validation. La migration du trafic applicatif et celle de la base de données sont distinctes. Un nouveau point d'accès en bonne santé ne prouve pas que l'état persistant et toutes les tâches en arrière-plan ont été transférés correctement.

La place de Compute with Hivenet

Compute with Hivenet fournit des ressources de calcul CPU et GPU. Évaluez-les lorsqu'elles correspondent à la tâche, tout en définissant séparément le déploiement, l'exploitation et les connexions de l'application. Ne supposez pas que louer une instance remplace une plateforme applicative gérée, une base relationnelle ou toutes les intégrations AWS.

Une comparaison utile énumère les mêmes responsabilités des deux côtés : environnement d'exécution, stockage, déploiement, surveillance, restauration, support et coût total. Déplacer une application peut changer la personne qui assume ces tâches. Comparez une configuration testée et le travail nécessaire plutôt qu'un récit de migration non étayé ou un pourcentage d'économie universel.

Questions fréquentes

Amazon EC2 est-il un PaaS ou un IaaS ?

EC2 est généralement classé comme infrastructure en tant que service. Vous louez du calcul et gérez davantage le système d'exploitation invité et les logiciels. Une plateforme comme Beanstalk peut coordonner des ressources EC2 sans faire de chaque déploiement EC2 une application PaaS.

AWS Lambda est-il considéré comme un PaaS ?

Lambda est un service de calcul serverless. Les fonctions déclenchées par des événements sont souvent décrites comme des fonctions en tant que service, un modèle plus précis au sein des plateformes gérées. Choisissez le type d'exécution Lambda et ses limites plutôt que de vous fier à l'étiquette PaaS.

Amazon S3 est-il un PaaS ou un SaaS ?

S3 est un stockage objet géré. Il peut servir une application, mais ce n'est ni une plateforme complète d'hébergement applicatif ni une application métier prête à l'emploi. « Stockage objet » est la description la plus utile pour décider de son usage.

DynamoDB est-il un PaaS ou un IaaS ?

DynamoDB est une base de données serverless gérée, souvent décrite comme une base de données en tant que service. Vous utilisez son modèle de données et ses API au lieu d'entretenir des serveurs de base de données. La logique applicative, les autorisations et les modes d'accès appropriés restent de votre responsabilité.