DEV Community: Oleksandr Shevchenko

Bundling NuGet Package Dependencies in an SSIS Script Task

Oleksandr Shevchenko — Fri, 18 Sep 2026 16:03:12 +0000

Bundling NuGet Package Dependencies in an SSIS Script Task

If you've ever tried to reference a NuGet package with its own dependency tree from inside an SSIS Script Task, you've probably hit the same wall: it works fine in Visual Studio, then falls over the moment the package runs from the command line on a server. This walkthrough shows how to fix that properly — referencing any NuGet package with dependencies in a Script Task and bundling those dependencies so the package runs correctly outside of Visual Studio, without relying on the embedded DLLs option. A private package, Contoso.SampleLibrary, is used throughout as a concrete example.

Problem: SSIS Script Tasks that reference NuGet packages fail to execute from the CLI.

Solution: Temporarily point NuGet at the solution's packages folder, then use Costura.Fody to embed the required assemblies directly into the package.

Prerequisites

Visual Studio with the SSIS project open.
Access to your organization's private NuGet package source.

Step 1: Temporarily update NuGet.Config

Open %AppData%\NuGet\NuGet.Config — the user-level NuGet configuration file — and temporarily add a repositoryPath that points to the solution's packages folder.

Note: repositoryPath is resolved relative to the location of NuGet.Config, not the solution directory, so it must be specified as an absolute path.

Info: This update only redirects where packages are downloaded during script edit mode — from a temporary folder to a constant, persistent one. NuGet automatically resolves and chooses the proper compatible version of each library to incorporate into the solution.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="C:\path\to\solution\packages" />
  </config>
  <packageSources>
    <add key="YourOrg.PrivateFeed"
         value="https://pkgs.dev.azure.com/your-org/_packaging/YourOrg.PrivateFeed/nuget/v3/index.json"
         protocolVersion="3" />
  </packageSources>
</configuration>

Replace C:\path\to\solution\packages with the actual path to the solution's packages folder.

Step 2: Install the required packages

In Visual Studio:

Right-click the Script Task project and select Manage NuGet Packages.
Choose your organization's private package source.
Search for and install Contoso.SampleLibrary.
Also install Costura.Fody.

Info: Installing a package also pulls in its transitive dependencies automatically — see the summary below for how many packages this involves in this example.

Info: Costura.Fody embeds all third-party libraries directly inside the .dtsx file as binary resources, eliminating the need for an AssemblyResolver or any additional custom classes within the Script Task project.

Because the DLLs are embedded as binary data in the .dtsx file, the packages folder is only needed while editing the script in Visual Studio (script edit mode). On production/runtime servers, the packages folder is not required — everything needed is already embedded in the package.

After installation, restart the Script Task project so it picks up the new DLLs from NuGet.

Step 3: Clean up the temporary configuration

Once the installation is complete, remove the temporary package source and repositoryPath entries from:

%AppData%\NuGet\NuGet.Config

⚠️ Warning: These entries are only required for the one-time package restore and should not remain in the global NuGet configuration.

Summary

In this example, NuGet downloads 19 packages (dependencies) together with Contoso.SampleLibrary. No one would want to manually include all of them in an SSIS solution, especially since many of these packages contain multiple subfolders for different target runtimes and frameworks.

Even if a manual approach were used, maintaining and updating all of these libraries in the future would become another challenge. By using a combination of NuGet.Config and Costura.Fody, the SSIS solution can behave more like a traditional .NET application. This approach simplifies dependency management, automatically resolves compatible package versions and runtimes, and bundles the required assemblies, resulting in a more consistent and maintainable deployment model.

Have you run into NuGet dependency headaches in SSIS Script Tasks, or found a different approach that works for you? Let me know in the comments.

SnapStart vs Native AOT: what actually happens to cold starts, warm latency, and your AWS bill

Oleksandr Shevchenko — Fri, 18 Sep 2026 16:01:55 +0000

SnapStart vs Native AOT: what actually happens to cold starts, warm latency, and your AWS bill

If you run .NET on AWS Lambda, you've probably faced this fork in the road: enable SnapStart to shrink cold starts, or go all-in on Native AOT and skip the .NET runtime entirely. Both promise faster cold starts. Only one of them, in my tests, actually delivered.

I measured both configurations on the same 128 MB function shape, first with a couple of one-off samples, then with two proper batches (five cold requests and up to twelve warm requests per configuration), and finally ran the numbers through AWS's published pricing to see what it would cost at scale.

Spoiler: Native AOT won on cold latency, tied on warm latency, and won clearly on cost. Here's the data.

⚠️ Caveat up front: SnapStart isn't available on the Native AOT managed runtime, so this comparison necessarily ran AOT on Amazon Linux 2023 and SnapStart on the .NET 10 (C#/F#/PowerShell) managed runtime. That's a testing constraint, not a controlled experiment — the two configurations differ in more than just "SnapStart on or off." Treat this as directional evidence for this workload, not a universal verdict.

TL;DR

Cold requests (5 samples each): 471.72 ms mean for AOT vs 849.43 ms for SnapStart — AOT is 44.5% faster.
The gap is mostly first-execution, not snapshot restoration: 81.7% of the cold-latency difference comes from the first handler invocation, not the restore step.
Warm requests (8 AOT / 12 SnapStart): AOT has the lower median (35.68 vs 39.50 ms), SnapStart has the slightly lower mean (53.67 vs 57.32 ms) — no clear warm-latency winner in these small samples.
Cost: at 1M invocations/month and 1% cold starts, illustrative pricing puts AOT at $0.33/month vs SnapStart at $0.98/month per function — mostly because of SnapStart's caching and restoration fees, not compute.
Numbers below are small-sample measurements and a pricing model, not a guarantee for your workload. Verify before deciding.

1. Initial cold-start and single warm-request samples

Both configurations use 128 MB of allocated memory. Native AOT was tested on the Amazon Linux 2023 managed runtime; SnapStart was tested on the .NET 10 (C#/F#/PowerShell) managed runtime, since SnapStart is not available for the Native AOT runtime. This runtime difference is a testing constraint, not a controlled variable — the compared configurations differ in more than just SnapStart on/off.

Measurement	SnapStart	Native AOT
Cold initialization / restoration	346.09 ms	267.41 ms
First handler execution	496.66 ms	192.15 ms
Approximate cold-start total¹	842.75 ms	459.56 ms
Cold billed duration	500 ms	460 ms
Warm handler execution	9.41 ms	36.82 ms
Warm billed duration	10 ms	37 ms
Maximum memory used	55 MB	50 MB

¹ Initialization/restoration plus execution; excludes API Gateway, client networking, and a separate authorizer.

Interpretation

Cold request: Native AOT was 383.19 ms faster. SnapStart took approximately 83% longer.
Warm request: SnapStart was 27.41 ms faster, approximately 74% shorter.
Most of the cold-request difference came from handler execution, not snapshot restoration:
- Restoration versus initialization: 78.68 ms difference.
- First handler execution: 304.51 ms difference.

That first-execution difference deserves investigation. Network reconnection, downstream service latency, and first-use initialization are possible explanations—not conclusions established by these logs.

Important limitation: these are one cold and one warm sample per configuration. They show what happened, but do not establish typical or p95 performance, or prove that SnapStart caused the warm improvement. Runtime/build details are based on the supplied deployment descriptions rather than independently established by these REPORT lines.

Source logs

summary="Raw CloudWatch REPORT lines (initial single-request samples)"

SnapStart:

REPORT RequestId: b23a929b-c7f9-404b-ad32-49210dad2fe0 Duration: 496.66 ms Billed Duration: 500 ms Memory Size: 128 MB Max Memory Used: 55 MB Restore Duration: 346.09 ms Billed Restore Duration: 3 ms
REPORT RequestId: fd64a0ca-b27b-4a58-bfab-06314199a0dc Duration: 9.41 ms Billed Duration: 10 ms Memory Size: 128 MB Max Memory Used: 55 MB

Native AOT without SnapStart:

REPORT RequestId: e2055d28-ce2e-4c69-ba09-df58c8efec4b Duration: 192.15 ms Billed Duration: 460 ms Memory Size: 128 MB Max Memory Used: 50 MB Init Duration: 267.41 ms
REPORT RequestId: 0513e1ac-1715-4ea4-bd87-f3d885ad0b44 Duration: 36.82 ms Billed Duration: 37 ms Memory Size: 128 MB Max Memory Used: 50 MB

Follow-up warm-request samples

The additional batch contains 8 Native AOT requests and 12 SnapStart requests. None of these REPORT lines includes Init Duration or Restore Duration, so they are consistent with warm invocations. REPORT lines alone do not rule out a suppressed initialization after a failure.

Metric	SnapStart (12 requests)	Native AOT (8 requests)
Median execution	39.50 ms	35.68 ms
Mean execution	53.67 ms	57.32 ms
Minimum execution	30.59 ms	23.71 ms
Maximum execution	181.04 ms	199.86 ms
Mean billed duration	54.25 ms	57.625 ms
Reported maximum memory used	55–58 MB	50–53 MB

Native AOT's median is 3.825 ms lower; SnapStart's median is approximately 10.7% higher. However, SnapStart's mean execution is 6.4% lower. Both datasets have slow observations that influence the means; all observations are retained. Max Memory Used is an execution-environment high-water mark, not an isolated measurement of memory consumed by each request.

These results do not establish a consistent warm-execution winner. They supersede the initial single-request warm comparison as the basis for the cost estimates below. Sample sizes are small and unequal, request equivalence has not been verified, and p95 estimates would be unstable.

Durations and billed durations from the follow-up batch, in supplied order (milliseconds):

summary="Raw warm-batch data (20 requests)"

AOT execution: 23.71, 199.86, 60.78, 38.82, 28.88, 44.28, 32.53, 29.66
AOT billed:    24, 200, 61, 39, 29, 45, 33, 30
Snap execution: 41.02, 33.65, 39.33, 181.04, 36.62, 40.43, 90.49, 39.67, 37.90, 41.12, 32.21, 30.59
Snap billed:    42, 34, 40, 182, 37, 41, 91, 40, 38, 42, 33, 31

Follow-up cold-start samples (five per configuration)

Each SnapStart RESTORE_REPORT repeats the Restore Duration shown in its corresponding REPORT; it is counted once, not twice. Approximate Lambda-side cold latency is restoration or initialization plus handler execution, not billed duration.

Metric	SnapStart	Native AOT
Mean restoration / initialization	365.74 ms	296.80 ms
Mean first handler execution	483.69 ms	174.92 ms
Mean cold total	849.43 ms	471.72 ms
Median cold total	827.50 ms	440.35 ms
Cold total minimum–maximum	775.62–976.80 ms	432.07–605.38 ms
Mean billed duration	500.60 ms	472.40 ms
Reported maximum memory used	55 MB	50 MB

Native AOT's mean cold latency is 377.71 ms (44.5%) lower than SnapStart's. Equivalently, SnapStart's mean cold latency is approximately 80.1% higher than AOT's. Even the slowest AOT cold request in this batch is faster than the fastest SnapStart cold request. This is descriptive evidence from five samples each, not a population-level guarantee or a matched-pair experiment.

The mean gap has two components:

Restoration versus initialization: 68.94 ms.
First handler execution: 308.77 ms, accounting for approximately 81.7% of the total gap.

The first-handler penalty is consistent across this batch: SnapStart executions range from 460.01 to 500.75 ms, versus 149.83 to 212.37 ms for AOT. This supports investigating first-use work, network reconnection, and downstream call timing rather than attributing the whole difference to restoration. These logs do not identify the cause or prove the deployed build types.

Values in supplied order (milliseconds); totals combine fields within each request, not requests across configurations:

summary="Raw cold-start batch data (10 requests)"

Snap restore: 335.73, 333.19, 481.15, 363.02, 315.61
Snap execution: 491.77, 470.25, 495.65, 500.75, 460.01
Snap cold total: 827.50, 803.44, 976.80, 863.77, 775.62
Snap billed: 493, 509, 497, 502, 502
Snap billed restore: 1, 38, 1, 1, 41
AOT init: 277.92, 276.34, 282.24, 254.48, 393.01
AOT execution: 162.43, 164.18, 149.83, 185.78, 212.37
AOT cold total: 440.35, 440.52, 432.07, 440.26, 605.38
AOT billed: 441, 441, 433, 441, 606

SnapStart's billed restore portion varies from 1 to 41 ms, while actual restoration takes 315.61 to 481.15 ms. A lower chargeable restore portion does not mean a faster response. Billed duration already includes that chargeable portion; do not add it again when calculating compute cost.

End-to-end Postman observations

The user reports that Native AOT responds faster in Postman for both cold and warm requests. No numerical Postman timings were supplied, so this is a qualitative observation, not a measured percentage improvement. Postman includes client/network overhead, API Gateway, authorization, and the backend handler; a single Lambda Duration does not cover that entire path.

2. Pros and cons for this application

Option	Pros supported by these samples	Cons / trade-offs
Native AOT	Lower cold latency across both supplied batches; lower follow-up warm median; lower reported memory use; no SnapStart fees; user reports faster Postman responses	Slightly higher follow-up warm mean and one 199.86 ms observation; AOT requires compatible libraries and trimming configuration
SnapStart	Slightly lower follow-up warm mean and mean billed duration	Higher follow-up warm median; slower cold samples and consistently longer first-handler execution in the new batch; snapshot caching and restoration fees; published-version management; still has cold restores

Neither provides guaranteed warm-like latency after idle periods.

3. Long-term pricing assumptions

The following estimates use rates published in the AWS Lambda pricing example, reviewed on 2026-09-15:

Charge	Rate used
x86 execution	$0.0000166667 / GB-second
Requests	$0.20 / million
.NET SnapStart caching	$0.0000015046 / GB-second
.NET SnapStart restoration	$0.0001397998 / GB restored

These are illustrative public example rates, not a verified Ohio-region quote: the regional pricing lookup failed.

Assumptions:

One function, 128 MB = 0.125 GB.
One SnapStart version cached throughout a 30-day month.
Cold durations use the five-request follow-up batch's mean billed duration: SnapStart 500.60 ms, AOT 472.40 ms. Warm durations use the warm follow-up batch's mean billed duration: SnapStart 54.25 ms, AOT 57.625 ms. Initial single cold and warm samples remain historical context and are not pooled into these estimates.
These small samples are assumed representative only for illustration; they are not a reliable long-term traffic forecast.
Both alternatives have the same invocation count and cold-start percentage.
Each modeled cold SnapStart invocation corresponds to one snapshot restoration.
Excludes discounts, deployment/snapshot-initialization compute, API Gateway, logs, and downstream services.
Billing uses allocated memory, not maximum memory used.

Additional SnapStart fees at 128 MB

Caching: approximately $0.49/month per active version.
Restoration: approximately $0.0175 per 1,000 restores.
Seven functions with one cached version each: approximately $3.41/month, or $41.52 per 365-day year, for caching alone.

Old active versions can increase caching charges. Caching has a three-hour minimum per version.

The logged Billed Restore Duration: 3 ms contributes to ordinary duration billing; it does not replace the separate restoration fee.

Calculation model

Let N be monthly invocations and f the fraction experiencing a cold start. Durations below are billed seconds and costs are USD.

summary="Show the full cost formulas"

SnapStart compute = N × [f × 0.500600 + (1 − f) × 0.054250] × 0.125 × 0.0000166667
AOT compute       = N × [f × 0.472400 + (1 − f) × 0.057625] × 0.125 × 0.0000166667
Requests          = N × 0.20 / 1,000,000
SnapStart cache   = 0.125 × 2,592,000 × 0.0000015046
SnapStart restore = N × f × 0.125 × 0.0001397998

SnapStart total = SnapStart compute + Requests + SnapStart cache + SnapStart restore
AOT total       = AOT compute + Requests

4. Estimated monthly cost

Includes execution, requests, and applicable SnapStart fees.

Invocations per function/month	Cold-start percentage	SnapStart	Native AOT
100,000	0.1%	$0.52	$0.032
100,000	1%	$0.54	$0.033
1,000,000	0.1%	$0.82	$0.32
1,000,000	1%	$0.98	$0.33
1,000,000	10%	$2.64	$0.41

At one million invocations/month and 1% cold starts, twelve such 30-day months cost approximately:

SnapStart: $11.81 per function
Native AOT: $3.94 per function

These are small absolute amounts at 128 MB, but multiply with function count, retained versions, and traffic. These per-function estimates should not be treated as per-API-request costs when each API request invokes both an authorizer and a handler.

Could SnapStart eventually be cheaper?

Potentially, if its slightly lower mean warm billed duration holds across many requests. Under this updated model:

With virtually no restores, roughly 69.3 million invocations/month are needed for warm-compute savings to offset caching.
Above approximately 0.040% cold invocations, restoration fees and cold-duration differences outweigh those warm savings even before adding caching.

These thresholds are highly sensitive to the measured durations and assumed pricing.

5. Project-level potential cost impact

This compares Native AOT without SnapStart against SnapStart enabled for seven Lambda functions, using the supplied logs as a duration proxy. It is an estimate of the Lambda cost difference, not the project's entire AWS bill.

Project assumptions

Seven functions, each allocated 128 MB.
One active cached version per function throughout a 30-day month: seven snapshots total.
1% cold starts in both scenarios.
Mean billed durations from the supplied batches: 472.40 ms cold / 57.625 ms warm without SnapStart, versus 500.60 ms cold / 54.25 ms warm with SnapStart.
These durations are assumed to represent all seven functions; individual function timings have not been verified.
Uses the illustrative pricing rates in section 3, excluding discounts and deployment/snapshot-initialization compute.
Other infrastructure costs are excluded and assumed unchanged between scenarios.

Invocation counts below are totals across the project, not per function and not API request counts. An API request invoking both a JWT authorizer and a backend function produces two Lambda invocations. Scheduled/background invocations also count toward the total.

Monthly project Lambda costs

Total Lambda invocations/month	Without SnapStart	With SnapStart	SnapStart extra/month
100,000	$0.03	$3.46	+$3.43
1,000,000	$0.33	$3.91	+$3.58
10,000,000	$3.29	$8.38	+$5.10

Totals and differences are rounded independently from unrounded calculations.

At one million total project invocations/month, twelve 30-day months cost approximately:

Without SnapStart: $3.94.
With SnapStart: $46.91.
Additional SnapStart cost: $42.97.

Cost breakdown at one million project invocations/month

Cost component	Without SnapStart	With SnapStart
Requests	$0.200	$0.200
Execution	$0.129	$0.122
Snapshot caching — seven versions	—	$3.412
Snapshot restorations — 10,000 restores	—	$0.175
Total	$0.33	$3.91

The project's SnapStart caching component is 7 × $0.4874904 = $3.4124328/month. Execution, requests, and restoration charges use the project's total invocations only once; they are not multiplied by seven again. Retaining additional active versions increases caching charges.

Cost conclusion: at 1% cold starts, the modeled warm-execution saving is less than one cent per million project invocations and does not offset SnapStart caching and restoration fees. The supplied logs therefore favor disabling SnapStart on cost as well as observed cold latency, subject to these assumptions. This is not a recommendation to change deployments without reviewing individual functions and retained versions.

6. Recommendation

The current evidence favors Native AOT for cold latency across both supplied batches, warm median, and modeled cost. The five-request cold batch has mean totals of 471.72 ms for AOT versus 849.43 ms for SnapStart. The user also reports faster end-to-end Postman responses with Native AOT. SnapStart has a slightly lower follow-up warm mean, so these logs do not prove Native AOT is faster for every warm request.

Before deciding permanently, compare identical requests and dependencies across multiple cold starts and warm runs, recording median and p95 total API latency. Keep allocated memory, architecture, workload, and downstream configuration equivalent.

In particular, investigate why first-handler execution averages 483.69 ms with SnapStart versus 174.92 ms with AOT in the five-request cold batch. This accounts for approximately 81.7% of the mean cold-latency gap. Correlate client timings with authorizer and backend request IDs, and instrument downstream calls before selecting a code-level optimization.

Closing thoughts

For this workload, Native AOT beat SnapStart on cold latency, tied on warm latency, and came out cheaper once caching and restoration fees were modeled — without needing the extra moving parts of published versions and snapshot management. That said, the runtime mismatch noted above (Amazon Linux 2023 vs the .NET 10 managed runtime) means this isn't a clean, apples-to-apples benchmark, and five cold samples per configuration is a small dataset to build a permanent architectural decision on.

If you're weighing the same trade-off: measure your own workload, watch what happens to that first post-restore invocation, and run the numbers through your actual traffic and cold-start rate before committing.

Have you run a similar comparison, or seen different results with a heavier workload or larger memory allocation? I'd like to hear about it in the comments.

.NET NativeAOT on AWS Lambda: 7 Faster Cold Starts, 73% Lower Costs

Oleksandr Shevchenko — Thu, 04 Dec 2025 16:56:23 +0000

.NET NativeAOT on AWS Lambda: The Performance Revolution You've Been Waiting For

If you're running .NET on AWS Lambda and haven't explored NativeAOT yet, you're leaving serious performance (and money) on the table. Let me show you some numbers that might change your mind:

🚀 7× faster cold starts (6680ms → 940ms)
⚡ 6× faster warm runs (91ms → 14ms)
💾 50% less memory (93MB → 42MB)
💰 73% lower costs for high-volume workloads

And here's the kicker: these aren't theoretical numbers. They're from real Lambda functions running in production.

whitewAw / dotnet-lambda-aot-performance-comparison

.NET NativeAOT: Performance Revolution

A Deep Dive into AOT vs ReadyToRun vs Regular .NET

🎬 Interactive Presentation

📊 Interactive Slide Presentation - Full visual presentation with charts, comparisons, and code examples.

📈 Performance Charts - Interactive charts showing all benchmark results.

📋 Table of Contents

🎯 Introduction & Objectives

Who This Presentation Is For

.NET engineers familiar with Lambda, microservices, or performance-critical applications looking to understand modern compilation strategies.

What You'll Learn

NativeAOT fundamentals and how it compares to ReadyToRun and Regular .NET
Measured performance improvements from real-world Lambda functions
Practical build and deployment strategies
Code…

View on GitHub

Why Should You Care?

Every second your Lambda function takes to cold start is a second your users wait. And in the world of web applications, every millisecond counts:

Amazon found that 100ms delay = 1% revenue loss
Google reports 53% of mobile users abandon sites taking >3 seconds to load
A 6.7-second cold start (Regular .NET) is simply unacceptable for modern APIs

But it's not just about user experience - it's about your bottom line:

Scale	Regular .NET	NativeAOT	Savings
1M requests/mo	$0.98	$0.26	$0.72/mo
10M requests/mo	$9.80	$2.60	$7.20/mo
100M requests/mo	$98.00	$26.00	$72/mo

For an enterprise with 50 Lambda functions handling 100M requests each: $43,200/year saved.

The Three Compilation Modes: A Quick Primer

Before we dive into the numbers, let's understand what we're comparing:

1. Regular .NET (JIT)

Traditional approach: ships IL bytecode, compiles to native at runtime.

App Start → Load IL → Init Runtime → JIT Compile → Execute
                      ⏱️ SLOW      ⏱️ SLOW

Pros: Maximum flexibility, smallest package

Cons: Slowest startup, unpredictable performance

2. ReadyToRun (R2R)

Hybrid: ships both IL and precompiled native images.

App Start → Load R2R+IL → Init Runtime → Execute (mostly native)
                          ⏱️ SLOW

Pros: Faster startup than Regular, minimal code changes

Cons: Still requires full runtime, larger packages

3. NativeAOT

Pure native: everything compiled ahead-of-time.

App Start → Execute Native Binary
            ✅ FAST

Pros: Fastest startup, lowest memory, no runtime overhead

Cons: Reflection limitations (requires source generators)

The Real Performance Data

I built identical Lambda functions in all three modes and ran them through hundreds of test cycles. Here's what I found:

Cold Start Performance

Regular .NET 8:      ████████████████████████████████████████ 6680ms
ReadyToRun .NET 8:   ████████████████████████ 4389ms
AOT .NET 8:          ██████ 1082ms ⚡
AOT .NET 9:          █████ 971ms ⚡
AOT .NET 10:         ████ 940ms ⚡ (FASTEST)

Improvement: 7.1× faster (Regular → AOT .NET 10)

Warm Run Performance

ReadyToRun .NET 8:   ████████████ 99ms
Regular .NET 8:      ███████████ 91ms
AOT .NET 8:          ██ 18ms ⚡
AOT .NET 9:          █ 14ms ⚡ (FASTEST)
AOT .NET 10:         ██ 17ms ⚡

Improvement: 6.5× faster (Regular → AOT .NET 9)

Memory Usage

ReadyToRun .NET 8:   ████████████ 89-96 MB
Regular .NET 8:      ███████████ 88-93 MB
AOT .NET 8:          █████ 46-52 MB ⚡
AOT .NET 9:          ████ 43-49 MB ⚡
AOT .NET 10:         ████ 42-48 MB ⚡ (LOWEST)

Improvement: 52% less memory (Regular → AOT .NET 10)

The Code: What Changes?

The good news? Your business logic doesn't change. The differences are in how you bootstrap and serialize.

Regular .NET Lambda

[assembly: LambdaSerializer(typeof(DefaultLambdaJsonSerializer))]

namespace LambdaRegularDemo;

public class Function
{
    private readonly IDynamoDBRepository _repository;

    public Function(IDynamoDBRepository repository)
    {
        _repository = repository;
    }

    [LambdaFunction]
    public async Task<Guid> FunctionHandler(
        Dictionary<string, string> input, 
        ILambdaContext context)
    {
        using var cts = new CancellationTokenSource(context.RemainingTime);
        return await _repository.CreateAsync(cts.Token);
    }
}

NativeAOT Lambda

Main difference: Source-generated JSON serialization

// AOTJsonContext.cs
[JsonSerializable(typeof(Guid))]
[JsonSerializable(typeof(Dictionary<string, string>))]
public partial class AOTJsonContext : JsonSerializerContext { }

// Function.cs
public class Function
{
    private readonly IDynamoDBRepository _repository;

    public Function(IDynamoDBRepository repository)
    {
        _repository = repository;
    }

    public async Task<Guid> FunctionHandler(
        Dictionary<string, string> input, 
        ILambdaContext context)
    {
        // Same business logic!
        using var cts = new CancellationTokenSource(context.RemainingTime);
        return await _repository.CreateAsync(cts.Token);
    }
}

// Program.cs - Custom runtime bootstrap
var handler = async (Dictionary<string, string> input, ILambdaContext context) =>
{
    await using var serviceProvider = CreateServiceProvider();
    var function = serviceProvider.GetRequiredService<Function>();
    return await function.FunctionHandler(input, context);
};

await LambdaBootstrapBuilder
    .Create(handler, new SourceGeneratorLambdaJsonSerializer<AOTJsonContext>())
    .Build()
    .RunAsync();

Project Configuration

The key difference is in your .csproj:

<PropertyGroup>
  <OutputType>Exe</OutputType> <!-- Must be Exe for AOT -->
  <TargetFramework>net9.0</TargetFramework>
  <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
  <PublishAot>true</PublishAot> <!-- Enable AOT -->
  <SelfContained>true</SelfContained>
  <StripSymbols>true</StripSymbols>
  <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>

The AOT Challenge: Reflection

NativeAOT's biggest limitation? No dynamic reflection. But this is actually a blessing in disguise - it forces you to write better code.

❌ What Doesn't Work

// Dynamic type loading
Type t = Type.GetType("MyNamespace.MyClass");
var instance = Activator.CreateInstance(t);

// Runtime assembly loading
Assembly asm = Assembly.Load("PluginAssembly");

// Reflection-based serialization
JsonSerializer.Serialize(obj); // Uses reflection!

✅ AOT-Friendly Alternatives

1. JSON Source Generation

[JsonSerializable(typeof(MyType))]
public partial class MyJsonContext : JsonSerializerContext { }

// Usage
var json = JsonSerializer.Serialize(
    data, 
    MyJsonContext.Default.MyType
);

2. Constructor Injection (Always!)

// ✅ DO: Types known at compile time
public class MyService
{
    private readonly IRepository _repo;

    public MyService(IRepository repo)
    {
        _repo = repo;
    }
}

// ❌ DON'T: Service locator pattern
var repo = serviceProvider.GetService<IRepository>();

3. Explicit Type Registration

// ✅ DO: Compile-time registration
services.AddSingleton<IPlugin, ConcretePlugin1>();
services.AddSingleton<IPlugin, ConcretePlugin2>();

// ❌ DON'T: Runtime discovery
var plugins = Directory.GetFiles("plugins", "*.dll")
    .Select(Assembly.LoadFrom);

Building for Production

Use Docker to ensure consistent Linux binaries:

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build

# Install native toolchain for AOT
RUN apt-get update && \
    apt-get install -y clang zlib1g-dev zip

WORKDIR /src
COPY . .

# Build AOT Lambda
RUN dotnet restore ./LambdaAOTDemo9/LambdaAOTDemo9.csproj && \
    dotnet publish ./LambdaAOTDemo9/LambdaAOTDemo9.csproj \
    -c Release -o /artifacts/publish && \
    mv /artifacts/publish/LambdaAOTDemo9 /artifacts/publish/bootstrap && \
    cd /artifacts/publish && \
    zip -r /artifacts/LambdaAOTDemo9-lambda.zip .

Why Docker?

Ensures Linux build on any dev OS (Windows, Mac, Linux)
Includes required native dependencies (clang, zlib1g-dev)
Reproducible builds across team

Deploying to AWS Lambda

Option 1: Custom Runtime (Recommended)

LambdaAOTFunction:
  Type: AWS::Lambda::Function
  Properties:
    Runtime: provided.al2023
    Handler: bootstrap
    Code:
      S3Bucket: !Ref DeploymentBucket
      S3Key: LambdaAOTDemo9-lambda.zip
    MemorySize: 256  # Can use less memory with AOT!
    Timeout: 30

Option 2: Container Image

FROM public.ecr.aws/lambda/provided:al2023

COPY --from=build /artifacts/publish/bootstrap ${LAMBDA_RUNTIME_DIR}/bootstrap

CMD ["bootstrap"]

Benefits:

Deploy .NET 9, .NET 10, or future versions today
No waiting for AWS managed runtime updates
Smaller image (no 200MB+ .NET runtime layer)

When Should You Use AOT?

✅ Choose NativeAOT When:

Cold start time is critical (APIs, webhooks, user-facing functions)
Memory costs matter (high-volume serverless)
Running .NET 9/10 on Lambda (managed runtime only supports .NET 8)
Predictable performance required (SLA-driven workloads)

Perfect for:

REST API backends
Event processors (S3, SQS, EventBridge)
GraphQL resolvers
Scheduled tasks

⚠️ Choose Regular .NET When:

Maximum flexibility required (plugins, dynamic loading)
Heavy reflection/dynamic code (complex ORMs, frameworks)
Long-running processes (cold start amortized over lifetime)
Fastest dev iteration

🔄 Choose ReadyToRun When:

You want 34% faster cold starts with minimal code changes
Testing AOT compatibility as a migration step
Some dynamic features required

But remember: R2R still costs 300% more than AOT!

The Business Case: Dual Value Proposition

Quick responses aren't just a technical metric - they drive business value:

1. Lower Operating Costs

At 100M requests/month:

Regular: $98/month per function
AOT: $26/month per function
Savings: $72/month

With 50 functions: $43,200/year saved 💰

2. Better User Experience

At 100M requests/month, switching to AOT eliminates:

2,138 hours of cumulative user waiting time
Calculation: (91ms - 14ms) × 100M requests = ~2,138 hours

Translation:

Higher conversion rates
Lower bounce rates
Better SLA compliance
Competitive advantage

Real-World Results

Here's the complete performance table from my tests:

Function	.NET	Runtime	Cold Start	Warm Avg	Memory
Regular	8	dotnet8	6680 ms	91 ms	88-93 MB
ReadyToRun	8	dotnet8	4389 ms	99 ms	89-96 MB
AOT	8	dotnet8	1082 ms	18 ms	49-52 MB
AOT	9	dotnet8	971 ms	14 ms ⚡	47-49 MB
AOT	10	dotnet8	940 ms ⚡	17 ms	42-45 MB ⚡

.NET 10 AOT wins on cold start and memory

.NET 9 AOT wins on warm performance

Getting Started

Ready to try it yourself? Here's the quickest path:

# Clone the demo repo
git clone https://github.com/whitewAw/dotnet-lambda-aot-performance-comparison.git
cd dotnet-lambda-aot-performance-comparison

# Build all Lambda packages via Docker
docker build -f src/Dockerfile -t aot-demo .

# Extract artifacts
docker create --name temp aot-demo
docker cp temp:/artifacts ./build-output
docker rm temp

# Deploy to AWS
aws s3 cp ./build-output/LambdaAOTDemo9-lambda.zip s3://your-bucket/
aws lambda update-function-code \
  --function-name my-function \
  --s3-bucket your-bucket \
  --s3-key LambdaAOTDemo9-lambda.zip

Key Takeaways

NativeAOT is production-ready for Lambda workloads
7× faster cold starts and 73% cost savings are real
Code changes are minimal (mostly serialization)
.NET 9/10 can run on Lambda today via custom runtime
User experience AND cost both improve dramatically
Start preparing now even if you're not migrating yet:
- Adopt JSON source generation
- Use constructor injection
- Avoid reflection where possible

The Future is AOT

.NET's investment in NativeAOT is clear:

.NET 8: Stable for console apps, minimal APIs
.NET 9: Improved trimming, best warm performance (14ms avg)
.NET 10: Smallest binaries (5.56 MB), fastest cold start (940ms)

Each version shows measurable improvements in size and performance.

Performance Variance Note

⚠️ Important: Your results may vary based on:

AWS region and AZ
Time of day
Lambda execution environment reuse
Your specific workload

The results shown represent averaged measurements from multiple test runs. Individual runs may vary by ±5-15%.

Always benchmark your specific workload!

Try It Yourself

The complete source code, benchmarks, and detailed documentation are available:

whitewAw / dotnet-lambda-aot-performance-comparison

.NET NativeAOT: Performance Revolution

A Deep Dive into AOT vs ReadyToRun vs Regular .NET

🎬 Interactive Presentation

📊 Interactive Slide Presentation - Full visual presentation with charts, comparisons, and code examples.

📈 Performance Charts - Interactive charts showing all benchmark results.

📋 Table of Contents

🎯 Introduction & Objectives

Who This Presentation Is For

.NET engineers familiar with Lambda, microservices, or performance-critical applications looking to understand modern compilation strategies.

What You'll Learn

NativeAOT fundamentals and how it compares to ReadyToRun and Regular .NET
Measured performance improvements from real-world Lambda functions
Practical build and deployment strategies
Code…

View on GitHub

What's included:

✅ Working Lambda functions (.NET 8, 9, 10 AOT + R2R + Regular)
✅ Containerized build pipeline
✅ Performance testing invoker
✅ CloudFormation templates
✅ Detailed migration guide

Discussion

Have you tried NativeAOT on Lambda? What were your results? Drop a comment below!

Questions I'd love to hear:

What's holding you back from trying AOT?
What performance improvements have you seen?
What challenges did you face during migration?

If this helped you, consider ⭐ starring the repo and following me for more .NET performance deep-dives!

Connect:

GitHub: @whitewAw
Repository: dotnet-lambda-aot-performance-comparison

Related Resources:

dotnet #aws #lambda #serverless #performance #nativeaot #csharp #cloudcomputing

Building a Privacy-First Financial Analysis PWA with Blazor WebAssembly + On-Device AI (Gemini Nano)

Oleksandr Shevchenko — Tue, 18 Nov 2025 21:14:38 +0000

Free, offline-capable, multi-language financial statement analysis for Ukrainian businesses - powered 100% in the browser (no servers, no API keys).

Live Demo: https://whitewaw.github.io/Assessment-of-Ukrainian-financial-statements/

GitHub Repo: https://github.com/whitewAw/Assessment-of-Ukrainian-financial-statements

Why I Built This

Small and medium businesses in Ukraine (and anywhere) often need quick insights from their balance sheet and income statement without sending data to third-party services or paying SaaS fees. I wanted:

Zero back-end infrastructure
Professional-grade ratio analysis and multi-year comparison
Installable PWA with offline mode
Strict privacy: data never leaves the browser
AI assistance without OpenAI keys or billing surprises

Blazor WebAssembly + Chrome's built-in Gemini Nano made this possible.

Core Highlights

Feature -> Benefit

Blazor WebAssembly (.NET 10) -> Full C# front-end, no server required
AOT Compilation -> Faster startup + optimized runtime
On-Device AI (Gemini Nano) -> Private financial chat & contextual insights
16 Analysis Tables -> Comprehensive coverage of capital, liquidity, solvency, efficiency
7 Interactive Charts -> Visual composition & trend exploration
Multi-Language (6) -> Ukrainian, English, German, Spanish, French, Russian
PWA + Offline -> Works after first load; installable
Local Storage + JSON Import/Export -> Data portability without backend
Privacy-First -> No telemetry, no tracking, no API keys

AI Assistant: 100% Client-Side

Chrome 127+ exposes a Prompt API enabling local inference via Gemini Nano. No keys, no cloud calls.

Example capability prompt:

const capabilities = await LanguageModel.availability();
"available"

Sample financial question internally passed to the AI service:

var prompt = $$"""
Using the company's working capital ( {model.WorkingCapitalCurrent} ), current ratio ( {model.CurrentRatio} ), and debt-to-equity ( {model.DebtToEquity} ), provide:
1. A concise stability assessment
2. Top 3 risks (if any)
3. Recommended next action
Answer in Ukrainian if source data locale is 'uk'.
"""$$;

The assistant streams responses for better UX and can explain formulas contextually.

Architecture Overview

AFS/ (Blazor WASM App)
  App.razor          → Root + Router
  Pages/             → UI pages (AI Assistant, Tables, Charts)
  wwwroot/index.html → SEO meta + PWA shell
AFS.ComponentLibrary/
  Components/        → Reusable UI (Tables, Charts, Chat)
AFS.Core/
  Models/            → Financial & ratio models
  Services/          → Calculation + AI integration + Storage
  Interfaces/        → Abstractions (IAIFinancialAdvisor, etc.)

Key separation: AFS.Core handles pure calculations (testable logic), while UI stays thin.

Financial Analysis Coverage

Includes:

Liquidity: Current, Quick, Cash, Working Capital
Solvency: Debt-to-Equity, Interest Coverage, Leverage
Profitability: ROA, ROE, Margins
Efficiency: Turnover metrics (assets, receivables, inventory, payables)
Stability: Autonomy coefficient, classification levels
Fixed & Intangible asset efficiency

Each table is generated from strongly typed models instead of ad-hoc dictionaries, enabling safer refactors.

Performance Choices

AOT publish shrinks cold start and improves runtime math-heavy loops
IL trimming + Brotli compression reduces payload
Critical CSS inlined in index.html for faster LCP
Service Worker caches static assets → instant repeat visits

Publishing command:

# Release build with AOT
 dotnet publish AFS/AFS.csproj -c Release -o build

Privacy & Data Handling

No calls are made to external APIs for analysis. Data stays:

In memory (runtime calculations)
In browser Local Storage (optional save)
Optional JSON export:

{
  "Year": 2024,
  "Form1": { "AssetsTotal": 1234567 },
  "Form2": { "NetProfit": 45678 }
}

You control export/import - nothing is uploaded.

Getting Started (Local)

# Clone
 git clone https://github.com/whitewAw/Assessment-of-Ukrainian-financial-statements.git
 cd Assessment-of-Ukrainian-financial-statements

# Restore
 dotnet restore

# Ensure WASM tooling
 dotnet workload install wasm-tools

# Run
 dotnet run --project AFS
# Visit https://localhost:7157

Enable AI (Chrome):

Update to Chrome 127+
chrome://flags/#prompt-api-for-gemini-nano → Enabled
First run downloads Gemini Nano (~1.7GB one-time)

Example: Ratio Calculation Service (Simplified)

public class LiquidityRatioService
{
    public decimal CurrentRatio(decimal currentAssets, decimal currentLiabilities)
        => currentLiabilities == 0 ? 0 : currentAssets / currentLiabilities;

    public decimal QuickRatio(decimal liquidAssets, decimal currentLiabilities)
        => currentLiabilities == 0 ? 0 : liquidAssets / currentLiabilities;
}

Integrated into a composite financial model so derived ratios are accessible to the AI advisor.

Internationalization (i18n)

Resx-based resources under AFS.ComponentLibrary/Resources/:

Resource.uk.resx
Resource.en.resx
etc.

Culture selector updates displayed language instantly - no reload.

SEO & GitHub Pages Quirk

Because this is a Blazor SPA hosted on GitHub Pages, Google Search Console may show a "False 404" during inspection of dynamic routes. A 404.html fallback mirrors index.html so all routes hydrate properly. Canonical + hreflang tags are manually set in index.html.

Roadmap (Selected)

PDF report generation (AI summary + graphs)
Multi-company comparison panel
Forecasting & anomaly detection (local AI augment)
Optional cloud sync layer (opt-in)

Contributions welcome - especially localization or advanced financial models.

Lessons Learned

On-device AI drastically lowers friction (no keys, instant trust)
Blazor AOT is now fast enough for real-time ratio computation
Strong typing across financial models prevents subtle column mapping errors
PWA + offline + privacy is a compelling trio for sensitive domains (finance, health, legal)

How You Can Help

⭐ Star the repo if you find it useful
🐛 Open issues for incorrect ratio definitions or edge cases
🌍 Add new language translations
📊 Contribute advanced metrics or sector benchmarks
🤖 Improve AI prompts for financial diagnostics

Final Thoughts

This project shows what’s now possible entirely in the browser: serious domain analysis + AI guidance without surrendering data or paying API bills. If you’re building privacy-first analytical tools, combining Blazor WebAssembly with on-device AI is absolutely worth exploring.

Explore the demo, inspect the code, and feel free to fork.

👉 Demo: https://whitewaw.github.io/Assessment-of-Ukrainian-financial-statements/

👉 Code: https://github.com/whitewAw/Assessment-of-Ukrainian-financial-statements

Questions?

Drop them in the comments or open a GitHub Discussion.

Made with ❤️ + .NET + WebAssembly + On-Device AI.