Amazon EC2 (Elastic Compute Cloud) est l’un des services cloud les plus connus au monde. C’est aussi l’un des plus mal compris par les agences web et les développeurs indépendants qui n’ont pas de background infrastructure.
Cet article ne va pas vous expliquer comment configurer un groupe de sécurité ou lancer une instance t2.micro. Ça, la documentation AWS le fait mieux que moi. Ce que je veux faire, c’est vous donner un cadre pour décider si et quand EC2 est le bon outil pour votre projet.
Ce qu’EC2 est vraiment
EC2, c’est un serveur virtuel dans le cloud. Vous le louez à l’heure, vous choisissez sa puissance, et vous avez un contrôle total sur ce qui tourne dessus.
C’est la différence fondamentale avec les plateformes comme Vercel, Netlify, ou Render : sur EC2, vous êtes responsable de tout. Le système d’exploitation, les mises à jour de sécurité, la configuration du serveur web, les backups. Tout.
C’est une puissance considérable. C’est aussi une responsabilité considérable.
Quand EC2 a du sens pour une agence
Vous avez des contraintes techniques précises
Certaines stacks exigent un contrôle bas niveau qu’une plateforme gérée ne vous donnera pas. Une application Laravel avec des jobs en queue, un serveur Node.js avec des WebSockets persistants, un environnement Docker personnalisé — EC2 est souvent la réponse naturelle.
Votre client a des exigences de conformité
Secteur financier, santé, données gouvernementales — ces environnements demandent parfois un contrôle précis sur où les données vivent et comment le serveur est configuré. EC2 dans une région AWS spécifique (Canada Central, par exemple) répond à des exigences que les plateformes hébergées ne peuvent pas toujours satisfaire.
Vous gérez un volume prévisible et élevé
À partir d’un certain volume de trafic, les plateformes PaaS deviennent coûteuses. Une instance EC2 bien dimensionnée peut être significativement moins chère qu’un plan Pro sur une plateforme gérée — si vous avez les compétences pour la maintenir.
Quand EC2 n’est pas la bonne réponse
C’est là où beaucoup d’agences se trompent.
Pour un site WordPress ou un site statique, EC2 est presque toujours du sur-dimensionnement. WP Engine, Kinsta, ou même un hébergement mutualisé de qualité font le travail pour une fraction du coût opérationnel — et sans que vous ayez à gérer les mises à jour de sécurité du serveur à 2h du matin.
Pour une application Next.js ou Astro, Vercel ou Cloudflare Pages font mieux qu’EC2 sur tous les aspects qui comptent pour vos clients : performance globale, CDN intégré, déploiements atomiques, rollback en un clic. À moins d’une contrainte technique très spécifique, il n’y a pas de raison de choisir EC2.
Si votre équipe n’a pas de compétences DevOps, EC2 est un pari risqué. Une instance mal configurée est une surface d’attaque. Un serveur qu’on « configure une fois et oublie » est un incident de sécurité en attente.
Le vrai coût d’EC2
Le prix affiché par AWS n’est pas le coût réel.
Une instance t3.medium à ~0,04$/heure semble abordable. Mais ajoutez : le temps de configuration initiale, les mises à jour de sécurité régulières, la gestion des backups, la surveillance, et la résolution d’incidents à des heures improbables — et le coût total opérationnel dépasse souvent ce qu’une solution gérée vous aurait coûté.
Pour les projets clients, je recommande systématiquement de quantifier ce coût opérationnel avant de proposer EC2. Si votre agence n’a pas les ressources pour le maintenir correctement, vous créez une dette technique et opérationnelle que quelqu’un devra payer plus tard.
Le bon niveau d’abstraction
AWS propose aujourd’hui des services qui vous donnent la flexibilité d’EC2 sans la charge opérationnelle :
- Elastic Beanstalk — déployez votre app, AWS gère l’infrastructure
- ECS / Fargate — conteneurs Docker sans serveur à gérer
- Lambda — fonctions serverless pour des tâches ciblées
- Lightsail — instances simplifiées avec prix fixes, idéal pour les petits projets
Pour la plupart des projets d’agence, l’un de ces services est plus approprié qu’EC2 brut.
Ce que je retiens pour ma pratique
EC2 reste un outil puissant et légitime. Mais c’est un outil de précision, pas un choix par défaut.
Avant de proposer EC2 à un client, je pose trois questions :
- Quelle contrainte technique ou réglementaire justifie EC2 plutôt qu’une solution gérée ?
- Qui sera responsable des mises à jour et de la surveillance après le lancement ?
- Le coût opérationnel total est-il inclus dans le budget du projet ?
Si vous n’avez pas de réponses claires à ces trois questions, une plateforme gérée est probablement le meilleur choix — pour vous et pour votre client.
L’infrastructure cloud est un domaine où les mauvaises décisions coûtent cher, pas toujours immédiatement. Prendre le temps d’aligner le choix technologique avec les capacités réelles de l’équipe, c’est de la stratégie, pas de la prudence excessive.