AWS Lambda cambia su captura de red a eBPF y Rust para miles de microVM
La plataforma serverless de Amazon sustituye su viejo módulo de kernel por una tubería en eBPF y Rust que registra el tráfico de cada microVM, con IPv6 como ciudadano de primera.
AWS Lambda ha reescrito el sistema que registra el tráfico de red de sus cargas de trabajo. La plataforma serverless de Amazon ha cambiado una captura basada en un módulo de kernel heredado por una tubería nueva escrita en eBPF y Rust, capaz de emitir un registro completo por cada microVM que se levanta y muere en cuestión de milisegundos. El motivo: la arquitectura anterior se quedaba sin aire a la densidad que Lambda maneja hoy.
Por qué el sistema viejo se ahogó
El diseño original venía de la era EC2 de un solo inquilino, menos densa. Tenía dos partes: una extensión en el kernel que contaba paquetes y los asignaba a inquilino y sandbox por flujo, y un daemon en espacio de usuario que leía esos contadores, los agrupaba, los serializaba y subía los ficheros con frecuencia.
Con pocas máquinas funcionaba. En un worker de Lambda, no. El primer problema fue la explosión de reglas de iptables: cada microVM añadía reglas a la cadena y cada paquete las recorre más o menos en lineal. Un host con un par de miles de microVM necesitaba más de 100.000 reglas solo para llevar la cuenta. El coste por paquete crecía con lo lleno que estuviera el host, justo lo contrario de lo que interesa cuando el plan es meter más microVM por máquina, no menos.
El segundo problema era de fondo: el módulo no hablaba IPv6. Un registro que no ve la mitad del espacio de direcciones no es de fiar, y en cuanto se propuso soporte dual-stack para Lambda, el enfoque quedó descartado.
Cómo es la tubería nueva
La sustitución son tres piezas que cooperan. En el kernel, un conjunto de programas eBPF enganchados al hook de control de tráfico (tc) sobre los dispositivos virtuales de cada red. Interceptan paquetes y emiten un evento compacto por paquete a un ring buffer. Solo miran: no hay código que copie, bloquee, descarte o reescriba un paquete.
En medio está el tagger, un proceso de usuario sin privilegios escrito en Rust, uno por red, es decir, por microVM. Encima, un orquestador privilegiado por host carga el eBPF, configura TC y lanza un tagger por cada red. La comunicación va por gRPC sobre un socket de dominio Unix.
Los registros se emiten en formato Amazon Ion, idénticos byte a byte a los que producía el daemon viejo. Esa era la condición para cambiar todo el motor de captura sin que se enteraran ni los consumidores, ni el pipeline de flow logs, ni los servicios de medición.
Los requisitos de diseño eran tres: atribución correcta, con cada flujo asociado a su microVM y a su inquilino; sobrecarga mínima en red y plataforma; e IPv6 como ciudadano de primera. La sobrecarga no es un detalle cosmético: cada megabyte de RAM y cada microsegundo de CPU cuentan a la densidad de Lambda, y se traducen directamente en utilización, margen y capacidad de servir peticiones bajo carga.
Todo esto ocurre en hosts de EC2 bare-metal llenos de invitados Firecracker que viven unos cientos de milisegundos. Cuando salta una alerta de seguridad, lo único que queda de esa carga es el registro que se capturó mientras existía, así que un paquete perdido o mal atribuido no es un problema de observabilidad menor: arrastra facturación y auditoría. La pieza que el original deja a medias es precisamente el tagger, y ahí está lo que conviene vigilar cuando se opera algo parecido, porque es el punto donde el modelo de un proceso por microVM se puede convertir en un problema de recursos con miles de redes activas por host.
