Shuffle sharding : la technique d’AWS pour isoler les charges de travail face aux attaques DDoS

Dans le domaine des infrastructures cloud, l’isolation des charges de travail est un enjeu critique pour garantir la disponibilité des services. AWS a développé une technique originale baptisée « shuffle sharding » pour répondre à ce besoin, notamment dans le cadre de son service DNS Amazon Route 53. Cette approche, née de la nécessité de protéger les domaines hébergés contre des attaques par déni de service distribué (DDoS), repose sur un principe simple mais puissant : au lieu d’attribuer chaque client à un ensemble fixe de serveurs, on mélange aléatoirement les affectations pour que chaque client soit servi par un sous-ensemble unique de ressources.

Aux origines du problème

Lorsque AWS a lancé ses premiers services, les clients ont rapidement exprimé le besoin d’utiliser Amazon S3, CloudFront et Elastic Load Balancing directement depuis la racine de leur nom de domaine (par exemple « exemple.com » et non « www.exemple.com »). Or, le protocole DNS, conçu dans les années 1980, ne permet pas d’utiliser un enregistrement CNAME à la racine. AWS a donc dû héberger directement les domaines de ses clients pour pouvoir retourner les adresses IP dynamiques de ses services, dont le nombre ne cesse de croître.

Héberger le DNS d’entreprises majeures est une tâche exigeante : une panne peut paralyser toute une activité. Pour AWS, l’urgence était réelle, et une petite équipe d’ingénieurs fut constituée pour relever le défi.

Le défi des attaques DDoS

Les fournisseurs DNS sont des cibles privilégiées des attaques DDoS, car le protocole UDP rend les requêtes facilement falsifiables. Chaque jour, des milliers d’attaques visent des domaines, pour des motifs allant de l’extorsion à la nuisance. La réponse classique – augmenter massivement la capacité des serveurs – est inefficace : ajouter un serveur coûte des milliers de dollars, alors qu’un attaquant peut louer des botnets pour quelques centimes par machine.

À l’époque de la construction de Route 53, la solution répandue était d’utiliser des appliances réseau spécialisées capables de « nettoyer » le trafic. AWS a estimé que couvrir l’ensemble de ses domaines nécessiterait des dizaines de millions de dollars et des mois de délais, ce qui était incompatible avec son besoin de rapidité et de frugalité. Il fallait une méthode qui ne consomme des ressources que sur les domaines effectivement attaqués.

Le principe du shuffle sharding

Le shuffle sharding est né de cette contrainte. Pour le comprendre, il faut d’abord envisager un système classique sans sharding : un ensemble de huit serveurs (ou « workers ») gère toutes les requêtes. En cas de défaillance d’un serveur due à une attaque, les autres prennent le relais, mais le problème se propage rapidement jusqu’à paralyser l’ensemble du service. Tous les clients sont alors impactés.

Avec un sharding classique, on divise le parc en groupes fixes (par exemple quatre groupes de deux serveurs). Chaque groupe est affecté à certains clients. Si un groupe est attaqué, seuls les clients de ce groupe sont touchés. Mais la redondance est limitée : si un serveur tombe dans un groupe, la charge se reporte sur l’unique autre serveur, ce qui peut entraîner une saturation.

Le shuffle sharding va plus loin : il attribue à chaque client un sous-ensemble aléatoire et unique de serveurs, extrait d’un pool commun. Par exemple, avec huit serveurs, un client peut être servi par les serveurs {1,3,5,7} et un autre par {2,4,6,8}. La clé est que les affectations sont mélangées (shuffled) de sorte que deux clients ne partagent pas exactement le même jeu de serveurs. Ainsi, lorsqu’une attaque cible un client spécifique, seuls les serveurs de son sous-ensemble sont saturés ; les autres serveurs restent disponibles pour les autres clients. De plus, comme chaque serveur appartient à plusieurs sous-ensembles différents, la redondance est meilleure que dans un sharding fixe.

Application à Amazon Route 53

Route 53 utilise le shuffle sharding pour distribuer la charge DNS. Le service dispose d’un grand nombre de serveurs répartis dans le monde. Lorsqu’un client enregistre un domaine, un sous-ensemble aléatoire de ces serveurs est choisi pour en assurer la résolution. Cette randomisation est effectuée à l’aide d’une fonction de hachage déterministe appliquée au nom de domaine, garantissant que le même domaine sera toujours servi par les mêmes serveurs, mais que deux domaines différents auront des ensembles distincts.

Ce mécanisme présente plusieurs avantages. D’abord, il réduit considérablement le rayon d’impact d’une attaque DDoS : même si un domaine est submergé, seuls les serveurs de son sous-ensemble sont affectés, et les autres domaines restent opérationnels. Ensuite, il est économique : inutile d’acheter des appliances coûteuses, car la défense est intégrée dans l’architecture. Enfin, il peut être adapté à d’autres services qu’AWS a depuis généralisés à de nombreux composants internes.

Un modèle pour la résilience multi-tenant

L’équipe AWS à l’origine de cette invention souligne que le shuffle sharding est devenu un modèle récurrent chez Amazon pour fournir des services multi-tenant offrant une expérience proche du single-tenant. En rendant chaque client « unique » du point de vue des ressources qui le servent, on isole naturellement les défaillances.

Dans un contexte où les attaques DDoS ne cessent de croître en fréquence et en puissance, cette approche offre une alternative pragmatique à l’accumulation de capacités. Elle illustre comment une contrainte technique peut devenir un levier d’innovation architecturale.

Conclusion

Le shuffle sharding est une technique astucieuse qui combine simplicité conceptuelle et efficacité opérationnelle. Née pour résoudre un problème concret de DNS, elle a été adoptée plus largement chez AWS pour isoler les charges de travail et renforcer la résilience des services cloud. Dans un environnement où la disponibilité est primordiale, ce modèle de distribution aléatoire des ressources constitue une réponse élégante aux attaques et aux pannes.