En el blog All Things Distributed, el ingeniero de AWS Zak van der Merwe describe su carrera construyendo control planes — esa capa de reconciliación que registra lo que debería existir en un servicio cloud y corrige continuamente la brecha con la realidad. Tras casi catorce años en AWS, construyó control planes para EC2 y, una década después, para Aurora DSQL.

Contrasta su empleo anterior a Amazon en una empresa de telecomunicaciones de Ciudad del Cabo — diez servidores con nombre, accesibles por SSH y físicamente — con su primera tarea en EC2: comprobar la salud de una flota donde el hardware fallaba constantemente. La lección: a esa escala, el fallo es ruido estadístico de fondo, y el control plane es lo que saca a los humanos del bucle de reacción.

Conceptualmente compara un control plane con un termostato: observa el estado real, lo compara con el deseado y corrige. Un mantra de EC2 era la estabilidad estática: las VMs en ejecución deben seguir funcionando aunque el control plane caiga. Una caída que impide lanzar recursos nuevos es mala; una en la que todo se detiene es catastrófica.

En el fondo del control plane de EC2 había una base MySQL: el acto crítico de una llamada RunInstances es escribir una sola fila. Entre los modos de fallo: la muerte del servidor primario (mitigada con un hot standby cuya conmutación seguía implicando guardias a las 3 de la madrugada) y un crecimiento que saturaba al único escritor. El equipo añadió réplicas de lectura — origen de la consistencia eventual de la API de EC2 — y luego shardó: primero en zonas de disponibilidad con control planes independientes, después internamente en cells. Cada proyecto de sharding llevó años, porque cada acceso a la base debe conocer su shard y no existe una clave de sharding universalmente correcta. También recuerda la era previa a la automatización, cuando parchear toda la flota por seguridad significaba repartir hosts entre todo el equipo por turnos.

Su lista de deseos para la base de datos ideal — escala sin heroicidades, alta disponibilidad, sin servidores que cuidar, plenamente relacional — lo llevó hacia 2021 al proyecto que se lanzó en GA en 2025 como Amazon Aurora DSQL. DSQL levanta una micro-VM Firecracker por conexión, de modo que un fallo afecta solo a una conexión. Las réplicas de lectura se añaden automáticamente por el control plane con lecturas fuertemente consistentes, y la partición es automática, lo que disuelve el dilema entre shardar pronto o lanzar rápido. Presenta DSQL como la escalabilidad de DynamoDB con el modelo de programación relacional.

El propio control plane de DSQL funciona sobre DSQL, pese a la dependencia circular. Ventajas: la base de contabilidad escala automáticamente con la adopción, y permanece disponible durante las caídas de zonas de disponibilidad, permitiendo que la reconciliación continúe — un fuerte contraste con las caídas de zona de la era EC2.

Admite carencias: faltan algunas funciones, en particular las restricciones de claves foráneas, que el equipo aborda con cautela porque pueden ser peligrosas a escala. La latencia es buena y predecible, aunque no tan rápida como las lecturas en caché de un Postgres de un solo nodo — y, según él, la latencia predecible al escalar importa más. Migrar el control plane de EC2 a DSQL llevaría años, algo que considera normal en un trabajo de esta envergadura.

Para cerrar, conecta los control planes con la era del codificado agéntico: cuando escribir código casi no cuesta nada, el cuello de botella se desplaza al juicio — decidir qué construir y cómo entregarlo con seguridad. Una infraestructura que elimina el trabajo invisible de llevar la contabilidad devuelve a los desarrolladores tiempo para lo esencial: salir y construir.