Sous le capot d'AWS Fargate : pourquoi le service n'utilise pas Firecracker
Une idée reçue très répandue veut qu'AWS Fargate s'appuie sur la technologie de microVM Firecracker pour isoler chaque conteneur. Un ancien ingénieur de l'équipe AWS EKS clarifie l'architecture réelle du service et met en lumière les compromis d'isolation et de coût par rapport aux instances EC2 traditionnelles.
Fil « Architecture d'AWS Fargate face à Firecracker »
Dans l'écosystème cloud d'Amazon Web Services, une croyance persiste : AWS Fargate (le service d'exécution de conteneurs sans gestion de serveurs) utiliserait Firecracker (un gestionnaire de microVMs, des machines virtuelles extrêmement légères) pour exécuter chaque tâche de manière isolée. Justin Garrison, ancien ingénieur de l'équipe AWS EKS (Elastic Kubernetes Service, le service Kubernetes géré d'AWS) d'avril 2020 à janvier 2024, est revenu sur cette misconception technique entretenue par la communication officielle.
Une architecture basée sur EC2 et containerd
Contrairement à ce que suggèrent certains documents marketing, Fargate n'instancie pas une microVM Firecracker dédiée pour chaque conteneur. En réalité, le plan de données de Fargate repose sur des instances EC2 (Elastic Compute Cloud, les machines virtuelles classiques d'AWS) dédiées par client. Côté exécution, le service a délaissé Docker pour containerd (le logiciel de gestion du cycle de vie des conteneurs), qui s'interface avec le runtime standard runC (l'outil bas niveau qui lance les conteneurs Linux) plutôt qu'avec l'extension firecracker-containerd.
Garanties d'isolation et contraintes de ressources
Cette réalité architecturale implique des comportements précis quant à la séparation des charges de travail :
- Isolation inter-clients : Fargate garantit une isolation matérielle stricte vis-à-vis des autres comptes AWS en attribuant des instances EC2 distinctes par client.
- Isolation intra-client : Il n'existe pas d'isolation par virtualisation matérielle entre vos propres conteneurs exécutés au sein du même ensemble de tâches.
- Ressources partagées : Le phénomène de « noisy neighbor » (un composant voisin bruyant qui consomme excessivement le processeur ou la mémoire) reste possible entre vos propres conteneurs.
Un simple déplacement de la charge opérationnelle
Si Fargate dispense de la gestion du système d'exploitation sous-jacent, la complexité technique ne disparaît pas mais se déplace vers d'autres choix d'architecture :
« La charge opérationnelle se déplace vers d'autres sujets comme l'obtention de volumes EBS ou de GPU, la conversion de tous les agents en sidecars, et la compréhension du surcoût par rapport à EC2. »
L'absence de serveur classique impose par exemple l'usage de sidecars (des conteneurs secondaires associés au conteneur principal) pour exécuter des dmons système de collecte de journaux ou de sécurité. De plus, le raccordement de volumes EBS (Elastic Block Store, le stockage bloc sous forme de disques virtuels) ou l'accès aux processeurs graphiques GPU s'avèrent plus complexes, pour un coût financier global nettement supérieur à celui de machines EC2 gérées directement.