Decoupling Memory from Startup Time in AKS Sandbox Pods

What if a 96GB sandboxed pod could start as fast as a 2GB one?

Before recent improvements in AKS Pod Sandboxing, large-memory pods could take over a minute longer to start than smaller ones. For customers running latency-sensitive, autoscaling, AI/ML, or bursty workloads, that startup delay directly impacted scale-out responsiveness, job completion time, and overall cluster efficiency.

AKS Pod Sandboxing provides strong workload isolation by running pods inside lightweight virtual machines. This model is especially valuable for security-sensitive, untrusted, or multi-tenant workloads, but it came with a tradeoff: memory size directly impacted startup latency.

With recent updates to the Azure Linux kernel used by AKS on Microsoft Hypervisor (MSHV), AKS has significantly improved startup time for large-memory sandboxed pods. This article explains what changed, why it matters, and what AKS customers should expect in practice. 

The Problem: Large-Memory Pod Startup Was Expensive 

Before this change, Kata-based pod sandboxes on AKS using the Microsoft Hypervisor (MSHV) followed an eager memory allocation model: 

• When a pod sandbox VM was created, all memory specified in the pod resource request was committed up front on the host. 

• For example: a pod requesting 32 GB, 64 GB, or 96 GB of memory forced the host to allocate and pin those virtual memory pages in physical memory before the VM could boot. 
• As a result, sandbox startup time scaled linearly with memory size. 

Measurements showed startup times growing quickly as memory increased: 

This led to: 

• Slower startup and scale-out for memory-heavy workloads. 
• Inefficient node utilization due to wasted memory reserved but unused at startup.

What Changed: Deferred Page Allocation in MSHV Host Kernel 

With deferred page allocation, the kernel no longer commits all virtual machine memory at sandbox creation time. 

• The pod sandbox VM boots with a small initial memory footprint. 

• Host memory pages are committed lazily, only when the guest faults them. 

• The total available memory remains bounded by the pod memory limit defined in the pod specification. 

This behavior aligns with how KVM-based systems handle guest memory today but is implemented for MSHV in Azure Linux. 

In short: memory is provisioned on demand, not up front.

Guest Memory Allocation (Before & After)

Results 

1. Pod Startup Time Is Now Effectively Constant 

The most visible benefit for AKS customers is dramatically improved pod startup time for large-memory pods. 

With deferred page allocation enabled, startup time becomes approximately O(1) with respect to memory size: 

• ~7x faster startup for 32 GB pods 

• ~12x faster startup for 64 GB pods 

• ~17x faster startup for 96 GB pods 

2. Higher Density and Better Memory Utilization 

Deferred page allocation also reduces wasted reserved memory at pod start. This allows AKS nodes to safely oversubscribe memory for cold pods, pack more sandboxed pods per node, and improve overall workload density and infrastructure efficiency. 

Tradeoff: First-Touch Page Fault Cost 

Deferred page allocation introduces a first-touch cost: when a workload accesses a memory page for the first time, a page fault triggers host allocation. This cost is incurred once per page. After memory is populated, steady-state performance matches eager allocation in benchmarks.

For most workloads, especially those that ramp memory gradually or benefit from faster startup, the improvement outweighs this one-time cost.

What AKS Pod Sandboxing Customers Need To Do 

Here's the good part: No changes are required for workloads to benefit from this improvement. However, customers are encouraged to:

• Specify realistic memory requests and limits. 
• Take advantage of improved startup behavior for scale-out scenarios. 

Deferred page allocation is available in AKS Pod Sandboxing on AKS Azure Linux version 202603.18.1 or later, running kernel-mshv 6.6.121 or newer.