On déploie un front React sur AWS Amplify, le prototype fonctionne en quelques heures, et tout semble rouler. Trois mois plus tard, la facture grimpe sans explication claire, un changement de région nécessite de recâbler l’authentification, et l’équipe passe plus de temps dans la console IAM que dans le code métier.
Ce scénario revient souvent dans les retours terrain sur Amplify. Le service accélère le démarrage d’un projet, mais il embarque des contraintes qui pèsent lourd dès que l’application quitte le stade du MVP.
A lire aussi : SQL est-il gratuit ou payant ?
Facturation Amplify : des compteurs dispersés sur plusieurs services AWS
Le premier réflexe avant d’adopter un outil cloud, c’est de vérifier combien il coûte. Avec Amplify, la réponse n’est pas simple. Amplify ne constitue pas une offre tarifaire unifiée : l’hébergement, le rendu côté serveur (SSR), le stockage et le transfert de données sont facturés séparément.
À cela s’ajoutent les services sous-jacents. Cognito pour l’authentification, AppSync pour l’API GraphQL, DynamoDB pour la base, Lambda pour les fonctions serverless, S3 pour le stockage objet. Chacun possède son propre compteur, ses propres seuils gratuits et sa propre logique de facturation.
A lire également : Comment créer un logiciel sans programmer ?
En pratique, on se retrouve à additionner des lignes de facture réparties dans plusieurs sections de la console AWS. Comparer ce total avec le prix affiché par Vercel ou Netlify (une ligne, un forfait) devient un exercice de comptabilité. Les crédits du niveau gratuit sont limités dans le temps pour les nouveaux comptes ; après cette période, chaque service bascule vers une tarification à l’usage sans visibilité consolidée.
Vendor lock-in AWS : le vrai coût de sortie d’Amplify
Amplify Gen 2 définit le backend en TypeScript au-dessus d’AWS CDK. L’approche est élégante pour qui reste dans l’écosystème Amazon. Le problème apparaît quand on envisage de migrer.
Quitter Amplify implique de remplacer les API, les modèles de données, l’authentification et l’infrastructure. L’application repose sur Cognito (gestion des utilisateurs), AppSync (couche GraphQL), DynamoDB (stockage NoSQL) et Lambda (logique métier). Aucun de ces services n’a d’équivalent direct chez un autre fournisseur cloud.
Concrètement, migrer vers Google Cloud ou Azure ne se limite pas à changer de plateforme d’hébergement. Il faut réécrire la couche d’authentification, adapter les resolvers GraphQL, transformer le schéma DynamoDB vers un autre moteur de base, et reconfigurer les fonctions serverless. Sur un projet de taille moyenne, cette migration représente plusieurs semaines de travail.
Des alternatives moins couplées pour le déploiement
Des plateformes comme Vercel, Netlify ou Railway proposent un déploiement frontend et backend avec une couche d’abstraction plus fine. On choisit sa base de données (PostgreSQL, MongoDB), son fournisseur d’authentification (Auth0, Clerk) et son hébergement de manière indépendante. Si un composant ne convient plus, on le remplace sans toucher au reste.
- Vercel gère le déploiement et le SSR, mais n’impose pas de base de données ni de service d’authentification propriétaire
- Netlify offre un modèle similaire avec des fonctions serverless portables vers n’importe quel runtime Node.js
- Railway permet de déployer des conteneurs standards, ce qui rend la migration vers un autre hébergeur quasi transparente
Courbe d’apprentissage Amplify : plus raide qu’annoncé
La promesse d’Amplify est de simplifier AWS pour les développeurs frontend. Dans les faits, la courbe d’apprentissage reste plus forte que celle de Vercel ou Netlify. Dès qu’un déploiement échoue ou qu’un utilisateur rencontre un problème d’accès, le diagnostic passe par plusieurs services et consoles AWS.
Un bug d’authentification peut venir de Cognito, d’une politique IAM mal configurée ou d’un resolver AppSync. Identifier la source demande de naviguer entre trois interfaces distinctes. Sur Vercel, le même problème se diagnostique depuis un seul tableau de bord avec des logs centralisés.
IAM et permissions : le mur pour les équipes frontend
Les équipes qui ne maîtrisent pas déjà IAM et l’écosystème AWS perdent un temps significatif sur la gestion des permissions. Amplify exige une compréhension d’IAM que la plupart des développeurs frontend n’ont pas. Configurer un rôle pour qu’une fonction Lambda accède à DynamoDB, autoriser un utilisateur Cognito à lire un bucket S3, restreindre les permissions d’un environnement de staging : chaque opération demande de manipuler des policies JSON dans la console IAM.
Ce n’est pas un défaut en soi. C’est un choix architectural d’AWS. La question est de savoir si votre équipe a le temps et les compétences pour absorber cette complexité. Si la réponse est non, le gain de temps initial d’Amplify disparaît dans le débogage des permissions.
Limites d’Amplify pour les architectures complexes en production
Amplify fonctionne bien pour une application simple : un frontend React, une API, une base de données, un système d’authentification. Les choses se compliquent avec des architectures multi-tenant, des pipelines de déploiement personnalisés ou des besoins de configuration réseau avancée.
Les architectures multi-tenant ou multi-région restent difficiles à gérer dans le cadre d’Amplify. Le service impose des conventions sur la structure du projet, le nommage des environnements et la gestion des branches. Sortir de ces conventions pour répondre à un besoin métier spécifique oblige à contourner le framework, ce qui annule son intérêt.
- Les pipelines CI/CD d’Amplify offrent peu de flexibilité par rapport à GitHub Actions ou GitLab CI configurés manuellement
- Le support des monorepos et des architectures microservices reste limité comparé à une infrastructure CDK ou Terraform gérée directement
- Les options de configuration réseau (VPC, peering, endpoints privés) nécessitent de sortir du périmètre Amplify pour intervenir dans la console AWS classique
Quand Amplify reste un choix pertinent
Amplify n’est pas un mauvais outil. C’est un outil spécialisé. Il convient aux prototypes rapides, aux applications internes sans contrainte de migration, et aux équipes déjà ancrées dans l’écosystème AWS qui acceptent le couplage avec les services Amazon.
Pour un projet destiné à la production avec une équipe qui ne vit pas dans la console AWS au quotidien, le rapport complexité/bénéfice penche rarement en faveur d’Amplify. Les retours varient sur ce point selon la taille de l’équipe et son expérience AWS, mais la tendance est nette dès que le projet dépasse le cadre d’un frontend simple avec un backend léger.
Le choix d’une plateforme de déploiement engage l’équipe pour des mois, parfois des années. Vérifier le coût réel, évaluer le coût de sortie et mesurer la charge de maintenance avant de s’engager reste la meilleure protection contre une dette technique silencieuse.
