L'exploitation de conteneurs en production exige une orchestration fiable, une mise à l'échelle fluide et un minimum de charge opérationnelle. AWS Elastic Container Service (ECS) avec le type de lancement Fargate répond à ces trois exigences en supprimant totalement la nécessité de provisionner ou de gérer des serveurs. Dans ce guide, nous expliquons ce qu'est Fargate, comment mettre en place un déploiement prêt pour la production et comment maîtriser les coûts.
Qu'est-ce qu'AWS ECS Fargate ?
Amazon ECS est un service d'orchestration de conteneurs entièrement géré. Lorsque vous choisissez le type de lancement Fargate, AWS prend en charge l'intégralité de l'infrastructure de calcul. Vous définissez vos conteneurs, spécifiez les besoins en CPU et mémoire, et Fargate s'occupe du reste : provisionnement des hôtes, placement des tâches, mise à jour du système d'exploitation et mise à l'échelle de la flotte.
Contrairement au type de lancement EC2, où vous gérez vous-même un cluster d'instances EC2, Fargate abstrait complètement la couche serveur. Vous ne payez que les ressources vCPU et mémoire effectivement consommées par vos tâches, facturées à la seconde avec un minimum d'une minute.
Configuration étape par étape
1. Construire et publier l'image Docker
Commencez par créer une image Docker pour votre application et publiez-la dans Amazon Elastic Container Registry (ECR). ECR s'intègre nativement avec ECS et prend en charge l'analyse d'images, les politiques de cycle de vie et la réplication inter-régions.
aws ecr create-repository --repository-name mon-app
docker build -t mon-app:latest .
docker tag mon-app:latest <account-id>.dkr.ecr.<region>.amazonaws.com/mon-app:latest
aws ecr get-login-password | docker login --username AWS --password-stdin <account-id>.dkr.ecr.<region>.amazonaws.com
docker push <account-id>.dkr.ecr.<region>.amazonaws.com/mon-app:latest
2. Créer une Task Definition
Une task definition constitue le schéma directeur de votre conteneur. Elle spécifie l'image Docker, les allocations de CPU et mémoire, les mappings de ports, les variables d'environnement, la configuration de journalisation et les rôles IAM.
Paramètres essentiels à configurer :
- networkMode : Défini sur
awsvpc(obligatoire pour Fargate). Chaque tâche reçoit sa propre interface réseau élastique et une adresse IP privée. - requiresCompatibilities : Défini sur
FARGATE. - cpu / memory : Choisissez parmi les combinaisons prises en charge (par exemple, 0,25 vCPU / 512 Mo, 1 vCPU / 2 Go, jusqu'à 16 vCPU / 120 Go).
- logConfiguration : Utilisez le pilote
awslogspour transmettre les logs du conteneur vers CloudWatch. - executionRoleArn : Un rôle IAM qui accorde à ECS la permission de télécharger les images depuis ECR et d'écrire les logs.
- taskRoleArn : Un rôle IAM que votre code applicatif assume au moment de l'exécution pour accéder à d'autres services AWS.
3. Configurer le réseau
Les tâches Fargate s'exécutent à l'intérieur d'un VPC. Créez ou sélectionnez des sous-réseaux privés pour vos tâches et associez un security group qui autorise le trafic entrant uniquement sur les ports exposés par votre application. Pour les services accessibles depuis Internet, placez un Application Load Balancer (ALB) dans des sous-réseaux publics et dirigez le trafic vers les tâches dans les sous-réseaux privés.
4. Créer un service ECS
Un service ECS maintient le nombre souhaité d'instances de tâches en cours d'exécution et s'intègre avec l'ALB pour les vérifications de santé et la répartition du trafic. Lors de la création du service, spécifiez :
- Le cluster et la task definition.
- Le nombre souhaité de tâches.
- La configuration réseau (sous-réseaux, security groups, attribution d'IP publique).
- Le target group du load balancer, le nom du conteneur et le port du conteneur.
Le planificateur du service remplace automatiquement les tâches défaillantes et les distribue entre les zones de disponibilité pour garantir une haute disponibilité.
Intégration avec l'Application Load Balancer
Un ALB est indispensable pour les déploiements Fargate en production. Il offre le routage par chemin et par hôte, la terminaison TLS, les vérifications de santé et le connection draining. Créez un target group avec le type de cible défini sur ip (et non instance, car les tâches Fargate utilisent le mode réseau awsvpc). Configurez des chemins de health check qui retournent un HTTP 200 depuis votre application et définissez des valeurs appropriées pour le délai de désinscription, assurant ainsi des arrêts progressifs lors des déploiements.
Politiques d'auto-scaling
ECS Service Auto Scaling ajuste le nombre souhaité de tâches en fonction des métriques CloudWatch. Trois types de politiques sont disponibles :
- Target Tracking : L'option la plus simple. Définissez une valeur cible pour une métrique telle que l'utilisation moyenne du CPU (par exemple, 60 %), et ECS ajuste automatiquement le nombre de tâches pour maintenir cette cible.
- Step Scaling : Définissez des ajustements de mise à l'échelle correspondant aux seuils d'alarmes CloudWatch. Utile lorsque vous avez besoin de comportements différents en scale-out et en scale-in.
- Scheduled Scaling : Augmentez ou diminuez la capacité à des moments prédéterminés, idéal pour les charges de travail aux schémas de trafic prévisibles.
Pour la plupart des applications, commencez par le target tracking sur l'utilisation CPU à 60-70 %. Ajoutez une seconde politique surveillant le nombre de requêtes par cible de l'ALB si votre charge est davantage liée aux E/S qu'au CPU.
Stratégies d'optimisation des coûts
La tarification de Fargate est transparente, mais les coûts peuvent s'accumuler rapidement. Voici des méthodes concrètes pour les réduire :
- Dimensionner correctement les tâches : Évitez le surprovisionnement en CPU et mémoire. Utilisez les métriques de Container Insights pour identifier l'utilisation réelle des ressources et ajustez les task definitions en conséquence.
- Utiliser Fargate Spot : Pour les charges tolérantes aux interruptions (jobs batch, processeurs de files d'attente), Fargate Spot offre des économies allant jusqu'à 70 %. Les tâches peuvent être interrompues avec un préavis de deux minutes ; concevez donc vos applications pour un arrêt progressif.
- Tirer parti des Savings Plans : Les Compute Savings Plans s'appliquent à Fargate et peuvent réduire les coûts jusqu'à 50 % en échange d'un engagement d'un ou trois ans.
- Optimiser la taille des images : Des images plus petites réduisent les coûts de stockage ECR et accélèrent le démarrage des tâches. Utilisez des builds multi-étapes et des images de base minimales comme Alpine ou Distroless.
- Contrôler le volume de journalisation : CloudWatch Logs facture l'ingestion et le stockage. Filtrez les logs détaillés au niveau applicatif et définissez des politiques de rétention des logs.
Fargate vs. EC2 vs. EKS : Choisir la bonne approche
| Critère | Fargate | Type de lancement EC2 | EKS (Kubernetes) |
|---|---|---|---|
| Gestion des serveurs | Aucune | Vous gérez les instances | Vous configurez le control plane |
| Granularité de mise à l'échelle | Par tâche | Par instance + par tâche | Par pod + par nœud |
| Temps de démarrage | 30 à 60 secondes | Dépend du lancement de l'instance | Dépend du provisionnement du nœud |
| Modèle de coût | Paiement par ressources de tâche | Paiement par instance (Reserved/Spot) | Frais du control plane + calcul |
| Support GPU | Limité | Support complet | Support complet |
| Idéal pour | Microservices, API, jobs batch | Charges importantes et stables | Équipes maîtrisant Kubernetes |
Choisissez Fargate lorsque vous souhaitez zéro gestion d'infrastructure et que vos charges présentent un trafic variable ou imprévisible. Choisissez EC2 lorsque vous avez besoin d'instances GPU, de types d'instances spécifiques ou que vous souhaitez optimiser les coûts pour des charges importantes et stables. Choisissez EKS lorsque votre équipe possède une expertise Kubernetes et que vous avez besoin de portabilité entre fournisseurs cloud ou de fonctionnalités avancées de planification.
Si vous comparez Fargate et App Runner sur le prix, nous avons chiffré la même application sur les deux, load balancer et NAT compris.
Conseils pratiques pour les déploiements en production
- Utiliser les déploiements progressifs (rolling) avec
minimumHealthyPercentdéfini à 100 etmaximumPercentdéfini à 200. Cela garantit des déploiements sans interruption en lançant les nouvelles tâches avant de retirer les anciennes. - Activer ECS Exec pour le débogage. Il offre un accès shell interactif aux conteneurs en cours d'exécution sans SSH, en s'appuyant sur AWS Systems Manager.
- Définir des délais d'arrêt appropriés. Le paramètre
stopTimeoutdonne à votre application le temps de terminer les requêtes en cours avant l'arrêt forcé du conteneur. - Implémenter des vérifications de santé à la fois au niveau du conteneur (dans la task definition) et au niveau du target group de l'ALB. Utilisez des endpoints distincts si nécessaire.
- Utiliser AWS Copilot ou CDK pour gérer l'infrastructure en tant que code. Ces deux outils simplifient le provisionnement des ressources ECS et prennent en charge la génération de pipelines CI/CD.
- Surveiller avec Container Insights pour obtenir une visibilité sur les métriques de CPU, mémoire, réseau et stockage au niveau des tâches et des services.
Conclusion
AWS ECS Fargate offre un équilibre convaincant entre simplicité et puissance pour l'exploitation d'applications conteneurisées. En éliminant la gestion des serveurs, il permet aux équipes d'ingénierie de se concentrer sur la logique applicative plutôt que sur l'infrastructure. Avec un dimensionnement réfléchi des tâches, des politiques d'auto-scaling et des stratégies d'optimisation des coûts, Fargate peut servir de fondation robuste pour les charges de production de toute envergure.