Un exmiembro del equipo de EKS de AWS (abril de 2020 a enero de 2024) sostiene que la creencia generalizada de que AWS Fargate utiliza Firecracker para crear microVMs por contenedor es una inexactitud que la propia AWS nunca corrigió, pese a que su documentación y entradas de blog lo sugieren.
El texto señala que la página oficial de Firecracker afirma que el proyecto se desarrolló "para mejorar la experiencia de cliente de servicios como AWS Lambda y AWS Fargate", y que el artículo del blog de AWS de 2020 "Under the hood: AWS Fargate data plane" pasa cerca del 80% de su extensión explicando la migración desde Docker a containerd, pero incluye Firecracker únicamente como runtime alternativo configurable, no como la tecnología subyacente real. Para usar Firecracker sería necesario cambiar el plugin de runtime de containerd de runC a firecracker-containerd, un cambio que el autor describe como inviable a la escala de Amazon por razones organizativas más que técnicas.
En realidad, según el testimonio, Fargate se ejecuta sobre instancias EC2 dedicadas por cliente, igual que cualquier otro servicio de AWS, sin aislamiento por hardware entre los contenedores de un mismo cliente. Eso significa que Fargate no elimina los problemas de vecindad ruidosa ni garantiza aislamiento a nivel de microVM; simplemente traslada la carga operativa a otras áreas (volúmenes EBS, GPUs, sidecars, costes superiores a los de EC2). El autor recomienda no tratar Fargate como magia tecnológica y evaluar con honestidad cuánto trabajo se elimina realmente frente a cuánto se reubica en otros frentes.