Cómo Zipline usa mTLS sobre QUIC en AWS para sus drones

En pocas palabras: Zipline asegura las comunicaciones de su flota de drones con mTLS sobre QUIC en AWS, usando un Network Load Balancer en modo passthrough que enruta por Connection ID sin descifrar tráfico. Cada backend en Amazon EKS verifica el certificado del dispositivo, evitando reconexiones durante los handoffs entre torres celulares.

Zipline, la empresa de delivery con drones que, a nivel mundial, hace una entrega cada 15 segundos según cifras reportadas en noviembre de 2026, resolvió un problema de conectividad con mTLS sobre QUIC en AWS: sus drones mantienen la sesión activa durante los handoffs entre torres celulares y cada dispositivo se autentica con certificado propio, sin reconexión ni secretos compartidos, según el blog oficial de AWS.

Lo interesante de este caso no es tanto el paso a paso (eso ya lo tenés en el repo de AWS), sino la decisión de diseño de fondo: separar el problema de transporte (QUIC) del problema de confianza (mTLS) y resolver cada uno con la herramienta que le corresponde. Vale la pena mirarlo con esa lupa antes de meterse en la implementación.

¿Qué problema de conectividad tenía la flota de drones de Zipline?

Con TCP, cada vez que un dron cambiaba de torre celular o de IP, se forzaba una reconexión completa con renegociación TLS. Eso agrega latencia justo en el peor momento: en pleno vuelo, con telemetría y datos de misión viajando en tiempo real.

Ponele que tenés miles de drones repartidos en varios continentes, cada uno transmitiendo posición y estado de la misión de forma continua. Ahí la estabilidad de conexión deja de ser un detalle técnico y se convierte en un requisito de negocio: una reconexión de más no es un log raro, es telemetría perdida mientras el dron sigue volando.

El otro lado del problema era la autenticación, y acá me parece que está la parte menos obvia del diseño. Gestionar un secreto único por dispositivo para miles de drones es operacionalmente pesado: alguien tiene que rotar eso, guardarlo, distribuirlo, y si un dron se pierde o se compromete, hay que revocar sin tocar al resto. Un secreto compartido para toda la flota es el camino fácil, pero es exactamente el que no podés tomar si un solo dispositivo filtrado te compromete todo. Complementá con resolver errores de trust policy en OIDC.

¿Cómo funciona QUIC con autenticación mutua TLS?

QUIC corre sobre UDP con TLS 1.3 integrado desde el diseño, y usa un Connection ID que mantiene la sesión viva aunque cambie la IP del cliente. Sobre esa base, mTLS agrega que el cliente también presenta certificado, no solo el servidor, y ese certificado se valida contra una CA de confianza en cada conexión.

En TLS estándar, solo el servidor se identifica. En mTLS, el dron también tiene que probar quién es. Eso le da a Zipline tres cosas concretas: identidad criptográfica por dispositivo, posibilidad de revocar un dron comprometido sin tocar al resto de la flota, y una base más sólida frente a eventuales exigencias regulatorias sobre dispositivos conectados.

¿Y cómo se resuelve el enrutamiento sin que el load balancer vea el tráfico? El Connection ID lleva un Server ID codificado, y el NLB lo lee en texto plano (sin necesitar las claves de cifrado) para mandar el paquete al pod correcto, según explica el anuncio original de soporte QUIC para NLB de noviembre de 2025. Esto tiene una consecuencia práctica que no es tan evidente a primera vista: como el NLB no descifra nada, tampoco podés usarlo para inspeccionar tráfico ni aplicar reglas a nivel de contenido. Esa responsabilidad se traslada entera al servidor.

¿Qué es el modo passthrough de un Network Load Balancer?

El modo passthrough significa que el NLB reenvía paquetes QUIC al backend sin terminar la sesión TLS ni ver el contenido en texto plano. La aplicación controla el handshake completo, incluida la verificación de certificados, y el load balancer solo opera a nivel de paquete.

Esto es clave para mTLS: si el NLB terminara TLS, perderías la cadena de confianza end-to-end entre el dron y el backend real. Al quedar todo en manos del servidor (en este caso, uno construido con quic-go corriendo en Amazon EKS), la verificación del certificado cliente ocurre donde tiene que ocurrir. Sobre eso hablamos en diseñar una arquitectura AWS de producción.

Eso sí: el passthrough tiene un costado práctico incómodo, y es el que más dolores de cabeza genera en la práctica. Los target groups de AWS usan health checks TCP por default, así que un servidor que solo hable UDP queda marcado como unhealthy aunque esté respondiendo perfecto por QUIC. La solución que documenta AWS es agregar un listener TCP mínimo que acepte y cierre la conexión, nada más, solo para pasar el chequeo. Es un parche razonable, pero es un parche: tu infraestructura de salud termina validando un protocolo que no es el que realmente usás.

¿Qué arquitectura usa AWS y qué pieza hace qué?

AWS armó una referencia con Amazon EKS, el AWS Load Balancer Controller (LBC) y AWS Private CA. El LBC provisiona el NLB y el target group de forma declarativa, siguiendo el flujo normal de Kubernetes, y se encarga de inyectar un Server ID único por pod a través de la variable de entorno AWS_LBC_QUIC_SERVER_ID. Los certificados los emite AWS Private CA: uno de servidor (CN=quic-example.local) y uno de cliente por dron (CN=drone-001), ambos firmados por la misma CA. El resumen de quién hace qué queda más claro en una tabla que en ocho pasos consecutivos:

Componente	Función en la arquitectura
Network Load Balancer (modo passthrough)	Enruta paquetes QUIC por Connection ID sin terminar TLS
AWS Load Balancer Controller	Provisiona NLB y target group, inyecta Server ID por pod
quic-go (en Amazon EKS)	Termina el handshake mTLS completo, incluida verificación del cliente
AWS Private CA	Emite certificados de servidor y de cliente (por dron)
Health check TCP	Requiere un listener TCP mínimo aunque el tráfico real sea UDP/QUIC

¿Te conviene este patrón? Criterios para decidir

Esto no es algo que montás porque suena moderno. Montar tu propia CA, tu propio servidor QUIC y la lógica de inyección de Server ID tiene costo operativo real, y ese costo solo se justifica si tu caso de uso se parece al de Zipline en lo esencial. Tres preguntas ayudan a filtrar:

• ¿Tus clientes cambian de red en medio de una sesión activa? Si tus dispositivos están mayormente fijos o conectados por WiFi estable, el problema que resuelve QUIC (mantener sesión durante handoffs) directamente no te aplica. TCP con reconexión ocasional puede ser suficiente.
• ¿Necesitás revocar dispositivos individuales sin afectar al resto? Si tu modelo de autenticación ya usa algo como API keys rotables centralmente y revocar una no te genera dolor operativo, mTLS por certificado agrega complejidad sin un beneficio proporcional.
• ¿Tenés volumen y criticidad para justificar correr tu propia PKI? AWS Private CA tiene costo por CA activa y por certificado emitido. Para una flota de cientos o miles de dispositivos de misión crítica, el cálculo cierra. Para un puñado de dispositivos de prueba, probablemente no.

Ejemplo hipotético (a modo ilustrativo, no un caso real): pensemos en una empresa que opera sensores IoT fijos en plantas industriales, conectados por Ethernet dentro de la misma red local, sin movilidad entre redes. Aunque esa empresa también tenga “miles de dispositivos” y quiera revocar certificados individualmente, el problema de los handoffs celulares no existe en su escenario: ahí mTLS sobre TCP, sin QUIC, probablemente resuelve lo mismo con menos piezas nuevas que mantener. El patrón de Zipline tiene sentido específicamente porque combina movilidad entre redes (celular) con escala de dispositivos y necesidad de revocación granular; si te falta la primera condición, estás pagando la complejidad de QUIC sin cobrar el beneficio que la justifica.

¿Qué limitaciones técnicas hay que tener en cuenta?

La limitación más concreta es el requisito del Connection ID: el Server ID decodificado tiene que ir en los bytes 1 a 8 de cada Connection ID que emite el servidor. Si tu implementación QUIC no respeta ese formato, el NLB no puede enrutar nada, así de simple.

Otra cosa que no es obvia a primera vista: el NLB nunca ve tráfico en texto plano, lo cual es una ventaja de seguridad, pero también significa que no podés aplicar reglas de security group delante del NLB en modo QUIC. Esas restricciones hay que implementarlas en el propio servidor.

Y después está el tema del estándar en sí. QUIC-LB, la especificación de la IETF en la que se basa este mecanismo de Server ID, todavía está en estado de borrador. AWS aclara que viene estable desde hace varios meses, pero eso no es lo mismo que una RFC final: habría que monitorear si cambia algo antes de apostar una arquitectura productiva entera a ese detalle. Si tu organización tiene aversión a dependencias sobre estándares no cerrados, esto solo debería pesar en tu decisión, no descartarla de plano: el draft lleva tiempo estable y AWS ya lo soporta en producción.

Errores comunes al implementar mTLS sobre QUIC en AWS

• Olvidarse la annotation por pod: la label en el namespace (elbv2.k8s.aws/quic-server-id-inject: enabled) activa la inyección, pero sin la annotation service.beta.kubernetes.io/aws-load-balancer-quic-enabled-containers en cada pod, el contenedor nunca recibe el Server ID y el enrutamiento falla en silencio.
• No exponer un listener TCP de respaldo: si el servidor solo escucha UDP, el health check TCP por defecto lo marca unhealthy y el target queda fuera de rotación aunque el servicio QUIC funcione perfecto.
• Registrar instancias con el mismo Server ID: cada instancia necesita un QuicServerId distinto en el target group; reutilizar el mismo en varias instancias rompe el enrutamiento por Connection ID.
• Asumir que el NLB hace la verificación de certificados: el NLB en passthrough no termina TLS. Toda la lógica de validar el certificado del dispositivo cliente corre en tu propio backend.

Preguntas Frecuentes

¿Qué es el modo passthrough de QUIC en un Network Load Balancer?

Es un modo de operación donde el NLB reenvía paquetes QUIC directo al backend sin descifrar ni terminar la sesión TLS. El enrutamiento se hace leyendo un Server ID codificado en el Connection ID, y toda la verificación de certificados queda del lado del servidor de destino. Ya lo cubrimos antes en los checks de seguridad en tu pipeline.

¿Por qué los drones de Zipline necesitan mTLS y no solo TLS?

Porque con TLS estándar solo el servidor prueba su identidad, y Zipline necesita verificar también que cada dron sea legítimo antes de aceptar su telemetría. mTLS permite revocar el certificado de un dron comprometido sin tener que rotar credenciales en toda la flota.

¿Puede un Network Load Balancer de AWS hacer mTLS por sí mismo?

No. En modo passthrough, el NLB no termina TLS ni ve tráfico en texto plano, así que no puede validar certificados. Esa verificación mutua ocurre en el backend, en el caso de Zipline, un servidor quic-go corriendo en Amazon EKS.

¿Cómo evita QUIC la reconexión cuando un dispositivo cambia de torre celular?

QUIC usa un Connection ID que identifica la sesión más allá de la IP o el puerto de origen. Cuando un dron cambia de torre celular y su IP cambia, la sesión sigue activa porque el NLB y el servidor siguen reconociendo el mismo Connection ID, sin forzar un handshake TLS nuevo.

¿Qué rol cumple AWS Private CA en una flota de drones o IoT?

AWS Private CA emite y gestiona los certificados de servidor y de cliente que usa cada dispositivo para autenticarse. En el caso de referencia de Zipline, la misma CA firma tanto el certificado del servidor (CN=quic-example.local) como el de cada dron cliente (CN=drone-001).

Conclusión

Lo que publicó AWS es una guía de referencia, no un producto nuevo: el soporte QUIC en NLB ya existía desde noviembre de 2025, y lo que suma ahora es el patrón completo de mTLS sobre esa base, documentado con el caso real de Zipline.

Mi lectura es que el valor de este post no está en los comandos (eso lo copiás del repo y listo), sino en el criterio de cuándo vale la pena: movilidad entre redes más necesidad de revocación granular por dispositivo es la combinación que justifica toda esta complejidad. Sin esa combinación, estás construyendo una PKI propia y un servidor QUIC a medida para resolver un problema que quizás no tenés.

Lo que la fuente no dice, y que me parece la pregunta más honesta antes de meterse en esto, es cuánto overhead operativo suma correr tu propia CA y tu propio servidor QUIC a escala: eso se mide recién cuando lo ponés en producción con tu volumen real de dispositivos, no en el repo de ejemplo con dos nodos. Antes de migrar algo así, conviene validar en staging que el formato del Connection ID (Server ID en los bytes 1 a 8) se respeta en tu implementación específica, y confirmar que el health check TCP de respaldo no introduce falsos negativos bajo carga real.

Fuentes

• AWS – Securing autonomous fleet communications at scale with mTLS over QUIC using NLB passthrough
• AWS – Introducing QUIC Protocol Support for Network Load Balancer
• AWS What’s New – Network Load Balancer QUIC passthrough mode