Auf dem Blog All Things Distributed beschreibt AWS-Ingenieur Zak van der Merwe seine Karriere im Bau von Control Planes — jener Abgleichschicht, die festhält, was in einem Cloud-Dienst existieren soll, und kontinuierlich die Lücke zur Realität schließt. Nach knapp vierzehn Jahren bei AWS hat er Control Planes für EC2 und rund ein Jahrzehnt später für Aurora DSQL gebaut.

Er stellt seinen Job vor Amazon bei einer Kapstädter Telekommunikationsfirma gegenüber — zehn benannte Server, in die man sich per SSH einloggen und zu denen man hinlaufen konnte — und seine erste EC2-Aufgabe: Health Checks für eine Flotte, in der ständig Hardware ausfiel. Die Lektion: In dieser Größenordnung ist Ausfall statistisches Hintergrundrauschen, und die Control Plane hält Menschen aus der Reaktionsschleife heraus.

Konzeptionell vergleicht er eine Control Plane mit einem Thermostat: beobachten, mit dem Sollzustand vergleichen, nachsteuern. Ein EC2-Mantra war Static Stability — laufende VMs müssen weiterlaufen, selbst wenn die Control Plane ausfällt. Ein Ausfall, bei dem Kunden keine neuen Ressourcen starten können, ist schlecht; einer, bei dem alles steht, ist katastrophal.

Im Kern der EC2-Control-Plane lag eine MySQL-Datenbank: Der kritische Akt eines RunInstances-Aufrufs ist das Schreiben einer einzigen Zeile. Zu den Ausfallmodi gehörten sterbende Primärserver (gemildert durch Hot-Standby-Umschaltung, die trotzdem Pagerdienst um 3 Uhr nachts bedeutete) und Wachstum, das einen einzelnen Writer überforderte. Das Team fügte Read Replicas hinzu — der Grund für die Eventual Consistency der EC2-API — und shardete dann: zuerst in Availability Zones mit unabhängigen Control Planes, dann intern in Cells. Jedes Sharding-Projekt dauerte Jahre, weil jeder Datenbankzugriff seinen Shard kennen muss und es keinen universell richtigen Sharding-Schlüssel gibt. Er erinnert auch an die Zeit vor der Automatisierung, als flottenweites Sicherheits-Patching bedeutete, Hosts schichtweise im Team aufzuteilen.

Sein Wunschzettel für die ideale Datenbank — skaliert ohne Heldentaten, hochverfügbar, keine Server zum Babysitten, voll relational — führte ihn um 2021 zu dem Projekt, das 2025 als Amazon Aurora DSQL in GA ging. DSQL startet pro Verbindung eine Firecracker-Micro-VM, sodass ein Ausfall nur eine Verbindung betrifft. Read Replicas werden automatisch von der Control Plane hinzugefügt, mit stark konsistenten Reads, und die Partitionierung erfolgt automatisch — das Dilemma zwischen frühem Sharding und schnellem Release entfällt. Er positioniert DSQL als DynamoDB-ähnliche Skalierbarkeit mit relationalem Programmiermodell.

Die DSQL-Control-Plane läuft selbst auf DSQL, trotz der zirkulären Abhängigkeit. Vorteile: Die Buchhaltungsdatenbank skaliert automatisch mit der Kundenakzeptanz, und sie bleibt bei Availability-Zone-Ausfällen verfügbar, sodass der Abgleich weiterläuft — ein scharfer Kontrast zu Zonenausfällen in der EC2-Ära.

Er räumt Lücken ein: Einige Features fehlen, darunter Foreign Key Constraints, die das Team vorsichtig angeht, weil sie bei Skalierung gefährlich sein können. Die Latenz ist gut und vorhersehbar, wenn auch nicht so schnell wie gecachte Reads auf einem Single-Node-Postgres — und vorhersehbare Latenz sei bei Skalierung wichtiger. Eine Migration der EC2-Control-Plane auf DSQL würde Jahre dauern, was er für solche Arbeit als normal ansieht.

Zum Schluss verknüpft er Control Planes mit der Ära des agentischen Codings: Wenn das Schreiben von Code fast nichts kostet, verlagert sich der Engpass auf Urteilsvermögen — was man baut und wie man es sicher ausliefert. Infrastruktur, die unsichtbare Buchhaltungsarbeit abnimmt, gibt Entwicklern Zeit für das, was zählt: loszugehen und zu bauen.