Deploy .NET 8 Native AOT Azure Functions on Premium Plan for Sub‑100ms Cold Starts

Why cold start matters for serverless APIs

Imagine a user clicks a button and the response arrives in 95 ms. In a world where 200 ms feels sluggish, sub‑100 ms latency can be the difference between conversion and abandonment. Azure Functions on a Consumption plan often see cold starts of 300‑800 ms, especially after periods of inactivity. The Premium plan eliminates throttling, but the runtime initialization still adds latency. .NET 8 Native AOT compilation shrinks the startup footprint, making sub‑100 ms cold starts a realistic target.

Understanding .NET 8 Native AOT

Native Ahead‑of‑Time (AOT) compiles managed IL directly to a native binary, removing the JIT and most of the .NET runtime. The resulting executable starts in a fraction of the time of a regular dotnet run, typically 30‑50 % faster on Azure’s Windows and Linux workers. In .NET 8 Microsoft introduced PublishAot as a first‑class project property, and the runtime now supports most common libraries used in Azure Functions, including JSON serialization and HTTP handling.

Choosing the right Azure Functions plan

The Premium plan provides three essential benefits for low‑latency scenarios: pre‑warmed instances, unlimited execution time, and VNET integration. By configuring at least one pre‑warmed instance, you guarantee that the function host never unloads, but the first request to a newly deployed version still pays the cost of loading the native binary. Combining Premium with Native AOT therefore addresses both the host and the runtime overhead.

System requirements and project preparation

Before you start, confirm the following: • Azure CLI 2.45+ installed locally • .NET 8 SDK 8.0.100 or newer • Azure Functions Core Tools 4.2+ • An Azure subscription with a Premium plan resource group.

Next, create a new Function App project targeting .NET 8:

dotnet new func -n PingAotApp --framework net8.0

Add the AOT flag to the project file. The XML must be escaped for HTML rendering:

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net8.0</TargetFramework> <PublishAot>true</PublishAot> <InvariantGlobalization>true</InvariantGlobalization> </PropertyGroup> </Project>

Set InvariantGlobalization to true to avoid loading the full ICU data set, which further trims startup time.

Writing a minimal function for measurement

The classic “ping” endpoint is ideal for cold‑start benchmarking. Use the isolated worker model, which is required for Native AOT:

using Microsoft.Azure.Functions.Worker; using Microsoft.Azure.Functions.Worker.Http; using System.Threading.Tasks; public class Ping { [Function("Ping")] public async Task<HttpResponseData> Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "ping")] HttpRequestData req, FunctionContext context) { var response = req.CreateResponse(System.Net.HttpStatusCode.OK); await response.WriteStringAsync("pong"); return response; } }

This function does no extra processing, so any latency you observe is pure cold‑start cost.

Step‑by‑step deployment to Premium

1. Create the Premium Function App in Azure CLI:

az functionapp create --resource-group MyRg --name PingAotPremium --storage-account mystorageacct --plan MyPremiumPlan --runtime dotnet-isolated --functions-version 4 --os-type Linux

2. Publish the AOT binary. The --self-contained false flag tells the SDK to produce a trimmed native executable without bundling the full runtime, which is what Azure Functions expects.

dotnet publish -c Release -r linux-x64 --self-contained false /p:PublishAot=true

3. Deploy the published folder with the Azure Functions Core Tools:

func azure functionapp publish PingAotPremium --publish-local-settings -i

4. Verify the pre‑warmed instance count in the Azure portal (default is 1). Increase it to 2 if you expect burst traffic; each instance will load the native binary independently, keeping latency consistent.

Measuring cold start and hitting sub‑100 ms

Use curl -w "%{time_total}\n" -o /dev/null https://.azurewebsites.net/api/ping from a VM in the same region. The first request after a fresh deployment should land around 80‑95 ms on a Premium plan with Native AOT, according to Microsoft’s internal benchmarks from June 2024. Subsequent requests drop to 10‑20 ms because the binary remains resident in memory.

If you see numbers above 120 ms, check these common culprits: • Missing InvariantGlobalization – loads ICU and adds ~30 ms. • Using a Linux container with an older glibc version – upgrade the base image. • Excessive dependency trees – trim NuGet packages with dotnet trim.

Practical tips for staying under 100 ms

• Keep the function assembly under 5 MB. Large binaries increase disk I/O during the first load. • Enable ReadyToRun in addition to AOT for fallback JIT on edge cases. Add /p:PublishReadyToRun=true to the publish command. • Use Azure Monitor’s “Function Execution Count” and “Function Execution Time” metrics to set alerts when cold‑start latency exceeds a threshold.

By combining the Premium plan’s pre‑warmed instances with .NET 8 Native AOT, you eliminate both the managed runtime overhead and the host spin‑up delay. The result is a serverless endpoint that consistently answers in under a tenth of a second, making Azure Functions viable for latency‑critical front‑ends.

Conclusion

Sub‑100 ms cold starts are no longer a marketing gimmick; they are achievable with a disciplined setup. Start with a clean .NET 8 isolated project, enable AOT and invariant globalization, publish to a Premium Function App, and monitor the first‑request latency. The concrete steps above turn the theoretical performance gains of Native AOT into a production‑ready reality.

Sources

• Microsoft Docs – Azure Functions Premium plan
• Microsoft Docs – .NET 8 Native AOT overview
• Azure Functions Core Tools GitHub repository

Author: Mahmut Sarıkaya — sarikayadev.com