Sur le blog All Things Distributed, l'ingénieur AWS Zak van der Merwe décrit sa carrière dans la construction de control planes — cette couche de réconciliation qui enregistre ce qui doit exister dans un service cloud et corrige en continu l'écart avec la réalité. Après presque quatorze ans chez AWS, il a bâti des control planes pour EC2 puis, une dizaine d'années plus tard, pour Aurora DSQL.

Il oppose son emploi pré-Amazon dans une entreprise de télécoms au Cap — dix serveurs nommés, accessibles en SSH et physiquement — à sa première mission chez EC2 : vérifier la santé d'une flotte où le matériel tombait en panne en permanence. La leçon : à cette échelle, la panne est un bruit statistique de fond, et c'est la control plane qui sort les humains de la boucle de réaction.

Conceptuellement, il compare une control plane à un thermostat : observer l'état réel, le comparer à l'état souhaité, corriger. Un mantra d'EC2 était la stabilité statique — les VM en cours d'exécution doivent continuer de tourner même si la control plane tombe. Une panne empêchant de lancer de nouvelles ressources est grave ; une panne où tout s'arrête est catastrophique.

Au cœur de la control plane d'EC2 se trouvait une base MySQL : l'acte critique d'un appel RunInstances est l'écriture d'une seule ligne. Parmi les modes de défaillance : la mort du serveur primaire (atténuée par un basculement vers un hot standby, qui impliquait quand même des astreintes à 3 h du matin) et une croissance qui saturait l'unique writer. L'équipe a ajouté des réplicas de lecture — origine de la cohérence éventuelle de l'API EC2 — puis a shardé, d'abord en zones de disponibilité dotées de control planes indépendantes, puis en cells internes. Chaque projet de sharding a pris des années, car chaque accès à la base doit connaître son shard et il n'existe pas de clé de sharding universellement correcte. Il évoque aussi l'époque pré-automatisation où un patch de sécurité sur toute la flotte signifiait répartir les hôtes par équipes et par shifts.

Sa liste de souhaits pour la base idéale — scalabilité sans héroïsme, haute disponibilité, aucun serveur à bichonner, pleinement relationnelle — l'a mené vers 2021 au projet devenu Amazon Aurora DSQL, lancé en GA en 2025. DSQL démarre une micro-VM Firecracker par connexion, de sorte qu'une panne n'affecte qu'une seule connexion. Les réplicas de lecture sont ajoutés automatiquement par la control plane avec des lectures fortement cohérentes, et le partitionnement est automatique, ce qui dissout le dilemme entre sharder tôt et livrer vite. Il présente DSQL comme la scalabilité de DynamoDB avec le modèle de programmation relationnel.

La control plane de DSQL fonctionne elle-même sur DSQL, malgré la dépendance circulaire. Avantages : la base de comptabilité scale automatiquement avec l'adoption, et elle reste disponible lors des pannes de zone de disponibilité, permettant à la réconciliation de continuer — un contraste marqué avec les pannes de zone de l'ère EC2.

Il concède des lacunes : certaines fonctionnalités manquent, notamment les contraintes de clés étrangères, que l'équipe aborde avec prudence car elles peuvent être dangereuses à grande échelle. La latence est bonne et prévisible, sans égaler les lectures en cache d'un Postgres mono-nœud — et une latence prévisible à l'échelle compte davantage selon lui. Migrer la control plane d'EC2 vers DSQL prendrait des années, ce qu'il juge normal pour un travail de cette envergure.

En conclusion, il relie les control planes à l'ère du codage agentique : quand écrire du code ne coûte presque plus rien, le goulot d'étranglement se déplace vers le jugement — décider quoi construire et le livrer en sécurité. Une infrastructure qui retire le travail invisible de tenue des livres redonne aux développeurs le temps de l'essentiel : aller construire.