We are looking to reduce cold start times for our AWS Lambda and Azure Functions written in C#. Is Native AOT (Ahead-of-Time) compilation ready for production use? I've heard there are limitations with reflection and certain NuGet libraries. Is the trade-off in binary size and speed worth the refactoring?
3 answers
Native AOT provides a massive boost for serverless. By compiling directly to machine code, you bypass the JIT compiler, which virtually eliminates cold starts. In our tests, we saw Lambda startup times drop from 400ms to under 50ms. Memory footprint also dropped by nearly 50%. However, the warnings about reflection are real—libraries like older versions of AutoMapper or Entity Framework (without Source Generators) will fail. You have to embrace "Trim-safe" code. If your function is a high-frequency microservice where latency and cost (memory usage) matter, the refactoring effort is definitely worth the investment.
Are there any specific third-party SDKs you’ve found that completely break with AOT? I'm worried about our cloud provider's SDK compatibility
The binary size reduction is also a hidden perk. Smaller deployment packages mean faster uploads and slightly lower storage costs in your container registry.
Great point, Laura. In a CI/CD pipeline, those smaller artifacts really add up, especially when you're deploying multiple times a day across different environments.
Michael, most of the official AWS and Azure SDKs have been updated to support Source Generators, which is the AOT-friendly alternative to reflection. The biggest headaches usually come from older, community-maintained JSON serializers or DI containers. As long as you stick to System.Text.Json with source generation and the built-in .NET dependency injection, you’re usually safe. I'd recommend running the .NET Analyzers for trimming early in your dev cycle to catch these issues.