3.34 Les groupes de placement AWS
Les placement groups permettent de contrôler où AWS positionne nos instances EC2 — soit pour améliorer les performances (faible latence inter-instances), soit pour se protéger des défaillances matérielles. Trois stratégies sont disponibles, à choisir au lancement.
- Cluster — les instances sont regroupées sur le même hardware physique dans une seule zone de disponibilité. Performances élevées et latence très faible (utile pour HPC et applications nécessitant des échanges réseau rapides). Inconvénient : si le support physique tombe, toutes les instances tombent.
- Spread — chaque instance est placée sur son propre support physique, réparti entre différentes zones de disponibilité (limite : 7 instances par AZ par groupe). C'est l'inverse du Cluster — on optimise la résilience. Idéal pour les applications critiques où chaque instance doit survivre à la défaillance des autres.
- Partition — les instances sont réparties en partitions (jusqu'à 7 par AZ, jusqu'à 100 instances par partition). Les instances d'une même partition partagent le matériel, mais pas avec les autres partitions. Adapté aux gros workloads distribués type Cassandra, Kafka, HDFS.
Création dans la console
Dans la console EC2, on va dans Réseaux et sécurité → Placement Groups, puis on crée un nouveau groupe avec un nom et la stratégie souhaitée. Pour la stratégie Partition, on précise le nombre de partitions (jusqu'à 7). Pour affecter une instance à un placement group, on coche la case correspondante à l'étape "Configure Instance Details" lors du lancement.
Attention : la stratégie Cluster ne fonctionne pas avec tous les types d'instances. Un t2.micro ne peut pas être placé en Cluster — il faut un type performance comme m5.4xlarge. Pour Spread et Partition, les contraintes sont plus souples. Bien choisir sa stratégie selon le besoin : performance pure (Cluster), résilience maximale (Spread), ou gros workloads distribués (Partition).
En résumé
Les groupes de placement AWS permettent de définir comment les instances EC2 sont distribuées dans les zones de disponibilité et sur les serveurs physiques pour optimiser les performances ou la disponibilité. Cette leçon couvre les trois stratégies principales : le cluster (regroupement sur un même matériel pour faible latence), le spread (répartition maximale pour éviter les défaillances simultanées), et la partition (compromis avec répartition par partition). Chaque stratégie répond à des besoins différents selon la criticité et les performances requises de l'application.
Points clés
- Stratégie Cluster : instances regroupées sur le même matériel physique dans une même zone, garantit très faible latence mais tous les risques de défaillance matérielle sont concentrés
- Stratégie Spread : chaque instance sur un matériel physique différent dans différentes zones, réduit drastiquement les risques de défaillance simultanée avec limite de 7 instances par zone
- Stratégie Partition : instances réparties par partitions (jusqu'à 7) avec 100 instances max par partition, idéale pour applications très consommatrices comme Cassandra ou HDFS
- Les groupes de placement se créent depuis la console AWS en spécifiant la zone de disponibilité et la stratégie, puis s'affectent aux instances lors de leur lancement
- Cas d'usage Cluster : big data et traitements batch rapides ; Spread : applications critiques à très haute disponibilité ; Partition : bases de données distribuées
Questions fréquentes
Quel est le groupe de placement à choisir pour garantir une très haute disponibilité ?
La stratégie Spread est idéale pour la haute disponibilité car elle répartit chaque instance sur un matériel physique différent dans des zones de disponibilité distinctes, éliminant les risques de défaillance simultanée de plusieurs instances.
Combien d'instances maximum peut contenir un groupe de placement ?
Un groupe de placement peut contenir jusqu'à 100 instances. Pour la stratégie Spread, la limite est de 7 instances par zone de disponibilité. Pour la partition, il peut y avoir jusqu'à 7 partitions avec 100 instances par partition.
Quand utiliser la stratégie Cluster plutôt que Spread ?
La stratégie Cluster convient aux applications nécessitant une très faible latence et des performances réseau extrêmement rapides (big data, traitements batch), car elle place toutes les instances sur le même matériel. Spread est préférable pour les applications critiques où la disponibilité prime sur la performance réseau brute.