Une migration cloud AWS ne se résume pas à déplacer des serveurs. Elle oblige à choisir un modèle d’exploitation.
Pour une DSI ou un CTO, le choix entre EC2, ECS et EKS doit être guidé par les applications, les compétences disponibles, les exigences de sécurité et le niveau d’automatisation recherché.
La bonne question n’est pas “quelle technologie est la plus moderne ?”, mais : quel modèle permet de livrer et d’exploiter avec le moins de complexité inutile ?
EC2 : le chemin le plus proche de l’existant
Amazon EC2 convient lorsque l’entreprise veut migrer des workloads existants avec un minimum de changement applicatif.
Ce choix est pertinent pour :
- des applications historiques difficiles à conteneuriser immédiatement ;
- des dépendances fortes au système d’exploitation ;
- des migrations progressives ;
- des équipes déjà organisées autour de l’administration serveur ;
- des scénarios où la transformation applicative doit être dissociée de la migration infrastructure.
EC2 offre un contrôle fin, mais il conserve une responsabilité importante côté exploitation : patching, durcissement, supervision, sauvegarde, capacité et gestion des images.
ECS : conteneuriser sans porter toute la complexité Kubernetes
Amazon ECS est souvent un bon choix pour exploiter des applications conteneurisées sur AWS avec une couche d’orchestration plus simple qu’une plateforme Kubernetes.
Il convient lorsque :
- les applications sont prêtes pour les conteneurs ;
- l’entreprise veut standardiser les déploiements ;
- les équipes cherchent une intégration native avec les services AWS ;
- le besoin de portabilité multi-cloud n’est pas prioritaire ;
- le modèle d’exploitation doit rester relativement sobre.
ECS permet d’accélérer la modernisation sans installer toute la gouvernance d’un cluster Kubernetes. C’est souvent un compromis solide pour des équipes qui veulent industrialiser les conteneurs sans surdimensionner la plateforme.
EKS : Kubernetes managé pour les besoins de plateforme
Amazon EKS devient pertinent lorsque l’entreprise a un besoin clair de Kubernetes : portabilité, écosystème cloud native, workloads multiples, standardisation plateforme ou compétences déjà présentes.
EKS peut être adapté si :
- plusieurs équipes produit doivent partager une plateforme ;
- les pratiques CI/CD et Infrastructure as Code sont déjà avancées ;
- la sécurité Kubernetes est cadrée ;
- le run plateforme est assumé ;
- l’entreprise veut capitaliser sur l’écosystème Kubernetes.
EKS reste un service managé, mais il ne supprime pas la responsabilité de conception, de sécurité, d’observabilité et d’exploitation du cluster.
Comparaison synthétique
| Option | À privilégier si | Point de vigilance |
|---|---|---|
| EC2 | vous migrez un existant avec peu de refonte | dette serveur et gestes d’exploitation |
| ECS | vous voulez industrialiser les conteneurs sur AWS | dépendance au modèle AWS |
| EKS | vous avez un vrai besoin Kubernetes | complexité plateforme et run |
Les critères de décision
Patrimoine applicatif
Une application monolithique fortement liée à son système peut commencer sur EC2. Une application déjà conteneurisée peut viser ECS. Un paysage de services nombreux et multi-équipes peut justifier EKS.
Compétences disponibles
Le choix doit être réaliste. Une plateforme EKS sans compétences Kubernetes crée un risque opérationnel. À l’inverse, rester sur EC2 par habitude peut maintenir une dette qui ralentit les équipes.
Sécurité et conformité
La sécurité doit être intégrée dès la landing zone : identité, réseau, segmentation, journalisation, chiffrement, politiques d’accès et gestion des secrets.
Run et observabilité
Le modèle cible doit préciser qui opère quoi, quelles alertes sont suivies, comment les incidents sont traités et comment les mises à jour sont planifiées.
Trajectoire recommandée
Chez Doveaia, nous recommandons une approche Cadrage -> Build -> Run.
Le cadrage identifie les applications candidates, les contraintes, les dépendances, les risques et les critères de décision.
Le build met en place la landing zone, les pipelines, l’observabilité, les règles de sécurité et les premiers workloads.
Le run installe l’exploitation : incidents, capacité, coûts, mises à jour, amélioration continue et transfert aux équipes.
Cette trajectoire évite de choisir une technologie avant d’avoir validé le modèle opérationnel.
Pour comparer ce raisonnement côté Microsoft, consultez aussi notre guide Migration cloud Azure : VM, Container Apps ou AKS. Si votre décision porte sur Kubernetes, notre article Kubernetes pour l’entreprise détaille les conditions de réussite.
Sources utiles
- Amazon EC2 : https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html
- Amazon ECS : https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html
- Amazon EKS : https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html
- AWS Well-Architected Framework : https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
Conclusion
EC2, ECS et EKS ne sont pas trois niveaux d’une même maturité. Ce sont trois modèles d’exploitation différents.
Le bon choix dépend du niveau de transformation acceptable, des compétences disponibles, des exigences de sécurité et de la capacité de run. Une migration cloud réussie commence par cette décision, avant l’implémentation.