We're being told Native AOT is the .NET default for cloud.
It's not wrong. It's just answering a different question.
The startup win is real. For scale-to-zero functions, Lambda-style workloads, containers that cold-start constantly — if you're paying a cold-start tax, AOT is the right call.
But if your service runs warm replicas and never hits a cold-start? You're paying AOT's costs without collecting its benefit. I've seen teams make this switch and wonder why throughput felt worse.
Here's what those costs actually are: tiered compilation and dynamic PGO gone — the JIT re-optimises hot paths using real runtime call data that AOT never sees. Full reflection gone — EF Core dynamic proxies, reflection-based JSON conventions, plenty of NuGet packages, all broken or unsupported. Per-RID builds on every arch you care about.
For a warm service, JIT isn't 'the slow option.' It's actively adaptive. It knows your production traffic. AOT doesn't.
Before you flip the switch: benchmark against your actual workload. Find out if you're paying a cold-start tax at all. Most steady-state .NET services aren't.
The startup headline is real. It just might not be your headline.
https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/native-aot
Top comments (0)