Heroku a démocratisé le déploiement d’applications web grâce à sa simplicité radicale : un git push et l’application est en ligne. Mais cette simplicité a un prix, qui devient lourd à mesure que l’application grandit : coûts des dynos, add-ons facturés au prix fort et marges de configuration réduites. La migration vers AWS ECS permet de reprendre le contrôle de ses coûts d’hébergement applicatif tout en conservant un modèle de conteneurs familier, avec une flexibilité d’infrastructure bien supérieure.
Pourquoi quitter Heroku pour AWS ECS ?
La motivation est d’abord financière. Heroku facture ses dynos et ses add-ons à des tarifs élevés, et chaque service supplémentaire (base de données managée, cache, monitoring, logs) alourdit la facture de façon difficilement maîtrisable. Sur AWS, le même service s’exécute sur des instances EC2 ou en mode Fargate (serverless), avec un coût souvent nettement inférieur à charge égale, et surtout avec la possibilité de négocier, de réserver de la capacité et d’optimiser finement.
S’ajoute une raison de contrôle : Heroku impose un modèle « platform as a service » qui masque l’infrastructure et limite les réglages (réseau, sécurité, régions, conformité). Amazon ECS (Elastic Container Service) offre la même abstraction conteneur avec une granularité d’infrastructure totale : VPC, groupes de sécurité, IAM, monitoring CloudWatch et intégration à tout l’écosystème AWS.
Heroku vs AWS ECS : ce qui change
| Dimension | Heroku | AWS ECS |
|---|---|---|
| Modèle | PaaS (dynos, buildpacks) | Orchestration de conteneurs (tasks, services) |
| Déploiement | git push + buildpacks | Image Docker + task definition |
| Exécution | Dynos facturés à l’unité | EC2 ou Fargate (serverless) |
| Scaling | Manual ou auto (coûteux) | Auto scaling fin (CPU, mémoire, requêtes) |
| Base de données | Add-on Heroku Postgres | Amazon RDS / Aurora |
| Redis | Add-on Heroku Redis | ElastiCache |
| Configuration | Variables d’environnement (config vars) | SSM Parameter Store / Secrets Manager |
| Observabilité | Add-on monitoring | CloudWatch, X-Ray, logs |
| Coût | Élevé, peu optimisable | Maîtrisable (Fargate, Savings Plans) |
Cette table montre que la migration exige de reconstruire certaines briques (base, cache, logs), mais qu’elle ouvre un champ d’optimisation considérable.
Les étapes d’une migration Heroku vers AWS ECS
- Audit de l’application Heroku : lister les apps, les dynos, les add-ons (Postgres, Redis, etc.), les config vars, les domaines et les tâches planifiées (scheduler).
- Conteneurisation : créer un Dockerfile pour chaque application, en reproduisant le comportement des buildpacks (installation des dépendances, commande de démarrage).
- Création du socle AWS : VPC, sous-réseaux publics/privés, groupes de sécurité, rôles IAM, et choix du mode d’exécution (Fargate pour le serverless ou EC2 pour les coûts optimisés).
- Définition des tâches ECS : écrire les task definitions (image, CPU, mémoire, variables d’environnement, secrets, logs), puis créer les services ECS avec un load balancer.
- Migration des données : transférer la base Heroku Postgres vers Amazon RDS (ou Aurora) via
pg_dump/pg_restoreou DMS, et migrer Redis vers ElastiCache. - Configuration des secrets et variables : déplacer les config vars vers SSM Parameter Store ou Secrets Manager, avec chiffrement et rotation.
- Mise en place de l’observabilité : logs CloudWatch, métriques, alertes et, si besoin, tracing X-Ray.
- Bascule progressive et rollback : tester en pré-production, basculer le DNS, conserver Heroku en secours, puis décommissionner.
Les pièges de la migration
Le premier piège est la reconstruction des add-ons : chaque service Heroku (Postgres, Redis, mail, recherche) doit trouver son équivalent AWS et être migré sans perte. Le deuxième est la configuration d’exécution : Heroku gérait les redémarrages, les timeouts et la santé des dynos ; sur ECS, il faut configurer les health checks, les grace periods et les stratégies de redéploiement. Le troisième est la sécurité : en passant d’un PaaS fermé à un cloud ouvert, il faut penser VPC, groupes de sécurité, IAM et chiffrement dès le départ.
Enfin, la gestion des coûts : sans discipline FinOps, la flexibilité d’AWS peut se retourner contre vous ; il faut taguer, surveiller et dimensionner correctement les tâches Fargate ou les instances EC2.
Reprise des données et continuité de service
La reprise des données de Heroku Postgres vers RDS se fait idéalement par réplication logique ou par une fenêtre de bascule courte (dump + restore), en validant l’intégrité des données (comptage de lignes, checksum). Pour Redis, la migration des clés est rapide mais nécessite de gérer la cohérence si les données sont critiques.
La continuité de service repose sur une bascule DNS progressive : on déploie l’application sur ECS en parallèle, on teste, puis on redirige le trafic. Heroku reste en secours pendant une période de transition, permettant un rollback immédiat en cas d’anomalie.
Optimiser les coûts : l’objectif central
La migration est l’occasion de mettre en place une vraie stratégie d’optimisation : Fargate pour les charges irrégulières (paiement à la seconde), EC2 avec Savings Plans pour les charges stables, auto scaling pour absorber les pics sans surprovisionner, et RDS avec instances réservées. Le résultat est une facture prévisible et souvent nettement inférieure à celle d’Heroku, pour un niveau de service équivalent ou supérieur.
Conduite du changement et bonnes pratiques
- Conteneuriser proprement : images légères, multi-stage builds, variables d’environnement externes.
- Centraliser les secrets dans Secrets Manager/SSM, jamais dans les images.
- Configurer l’auto scaling sur des métriques pertinentes (CPU, mémoire, requêtes).
- Mettre en place le FinOps : tags, budgets, alertes de coûts dès le premier jour.
- Former les équipes aux concepts ECS, Fargate, task definitions et CloudWatch.
- Documenter les runbooks : déploiement, rollback, rotation des secrets, sauvegardes.
Scheduler, workers et CI/CD : migrer les briques périphériques
Une application Heroku ne se résume pas à ses dynos web : elle s’appuie sur des briques périphériques qu’il faut reconstruire sur AWS ECS, souvent moins visibles mais tout aussi critiques.
Le Heroku Scheduler (tâches planifiées à fréquence fixe) se remplace par Amazon EventBridge Scheduler, qui déclenche des tâches ECS (RunTask) ou des fonctions Lambda à la fréquence voulue, avec plus de finesse (cron, fuseaux horaires, retry). Les workers et files d’attente (Sidekiq, Celery, RQ) deviennent des services ECS dédiés, scalés indépendamment, alimentés par SQS ou ElastiCache en remplacement des add-ons Redis.
Le CI/CD doit aussi être repensé : Heroku déployait par git push ; sur ECS, le déploiement passe par un pipeline qui construit l’image Docker, la pousse vers ECR, puis met à jour le service via une définition de tâche versionnée (GitHub Actions, CodePipeline ou autre). Adoptez des déploiements blue/green ou rolling avec conservation des versions précédentes, afin de pouvoir revenir en arrière en un clic.
Enfin, les add-ons divers — recherche (Elasticsearch), messagerie, monitoring — doivent chacun trouver leur équivalent AWS et être migrés avec leurs données. Inventoriez-les exhaustivement dès l’audit : ce sont eux qui réservent les surprises en fin de projet.
Pourquoi confier cette migration à Performances Digital ?
La migration de Heroku vers AWS ECS est un projet d’infrastructure qui demande de maîtriser à la fois la conteneurisation, le réseau, les bases de données et la gestion des coûts. Chez Performances Digital, nous pilotons cette transition de bout en bout : audit de vos apps Heroku, conteneurisation, mise en place d’ECS/Fargate, migration des bases et du cache, et optimisation FinOps. Notre objectif : vous rendre le contrôle de votre hébergement tout en réduisant durablement vos coûts.
Reprendre le contrôle de vos coûts d’hébergement, c’est réinvestir dans votre produit plutôt que dans des add-ons. Demandez votre devis gratuit : nous analyserons votre usage Heroku et vous remettrons un plan de migration chiffré, avec une trajectoire de bascule sans interruption.
