1. Technical feasibility & performance
- Nested virtualization on AWS is possible but comes with a measurable overhead.
- otterley: “As a practical matter, anywhere from 5‑15 %.”
- wmf: “At the scale of millions/billions of microVMs you’re better off running them on bare‑metal to avoid the overhead of nested virtualization.”
- BobbyTables2: “The technical details are a lot more complex than most realize.”
- matheus‑rr: “The LKML debates you’re referencing are mostly about edge cases… not the core nesting path that workloads like Firecracker and Kata actually exercise.”
2. Business & cost implications
- The feature is expensive and often not worth the extra cost for most workloads.
- PunchyHamster: “It is expensive. But the point where it stops being expensive is far above most companies’ use case.”
- re‑thc: “Or maybe you just never needed most of these in the first place.”
- otterley: “You pay the same for an instance whether you’ve subdivided it into your own VMs or not.”
- direwolf20: “You can use an expensive AWS VM instead of an expensive AWS bare‑metal image.”
3. Historical maturity & vendor lag
- Nested virtualization has existed for a decade in other clouds; AWS is simply catching up.
- HumanOstrich: “It’s been around for almost 15 years and stable enough for several providers to roll it out in production the past 10 years (GCP and Azure in 2017).”
- blabble: “It’s been in KVM since the mid‑10s and in Xen for at least as long.”
- boulos: “We put in a lot of effort with great customers to get nested virtualization running well on GCE years ago, and I’m glad to hear AWS is coming around.”
- otterley: “AWS is just late to the game because they’ve rolled so much of their own stack instead of adapting open‑source solutions and contributing back to them.”
These three themes—technical performance, cost‑benefit trade‑offs, and the long‑standing maturity of nested virtualization—dominate the discussion.