.NET on AWS: From Lift-and-Shift to Serverless

1. Introduction: .NET Has a Home on AWS

There's a perception that AWS is "not for .NET," that it's a Python and Node.js world, and C# developers are second-class citizens. That hasn't been true for a while, and in 2026 it's less true than ever.

AWS has invested heavily in .NET tooling: Lambda Annotations for clean function authoring, CDK support for infrastructure-as-code in C#, Graviton/ARM support for cost-efficient compute, and Native AOT for sub-100ms cold starts. The developer experience has gotten good.

But the journey from "we have a .NET app on Windows Server" to "we're running serverless on Lambda with automated infrastructure" isn't one step. It's a spectrum, and where you land depends on your constraints, your team, and how much change you can absorb at once.

This guide walks through each stage of that spectrum, then covers the tooling that makes the cloud-native end productive: Lambda Annotations, CDK, and open source libraries I've built to fill the gaps in the AWS .NET ecosystem.

2. Lift and Shift: Get to AWS First

The fastest path to AWS is moving what you have. If you're running .NET Framework on Windows Server, you can run that same application on EC2 Windows instances or Elastic Beanstalk with minimal code changes.

EC2: The Direct Translation

EC2 Windows instances are the closest analog to on-premises Windows Server. You get a Windows VM, install IIS, deploy your application, and it runs. The application doesn't know it moved.

Elastic Beanstalk: Managed Deployment

Beanstalk wraps EC2 with deployment automation, auto-scaling, load balancing, and health monitoring. For teams that want to get out of the business of managing Windows Server patches and IIS configuration, it's a reasonable middle ground.

You deploy a zip file or a Docker container, Beanstalk handles the rest. It supports both .NET Framework on Windows and modern .NET on Linux, so it can also serve as a stepping stone to the next phase.

The Lift-and-Shift Reality Check

Lift-and-shift gets you to AWS, but it doesn't get you cloud-native benefits. You're still paying for idle compute, still managing servers (or at least server configurations), and still deploying monoliths. That's fine as a starting point. The value is in getting off on-premises hardware, into a region closer to your users, and onto infrastructure you can iterate on.

The key is to treat it as phase one, not the destination.

3. Modernize the Runtime: Modern .NET, Still Lift-and-Shift

The single highest-impact change you can make is migrating from .NET Framework to modern .NET (8 or 9). Even if you keep the same deployment model (EC2 or Beanstalk), the benefits are substantial.

Why Modern .NET Matters on AWS

Modern .NET runs on Linux. That single fact unlocks a cascade of benefits on AWS:

• No Windows license cost — Linux EC2 instances are 30-40% cheaper than equivalent Windows instances
• ARM/Graviton support — another 20% cost reduction with better performance (covered in section 5)
• Container-friendly — smaller base images, faster startup, better orchestration options
• Lambda-ready — modern .NET is a prerequisite for Lambda and Native AOT
• Better performance — modern .NET (10 as of early 2026) is much faster than .NET Framework in virtually every benchmark

The Migration Path

Microsoft's .NET Upgrade Assistant handles much of the mechanical work. The real challenges are:

You don't need a big-bang migration. Tackle one project or service at a time: migrate it, validate it, deploy it, then move on to the next. Each migrated service starts saving you money immediately, and the team builds muscle memory with each one. The first service is the hardest; by the third or fourth, it's routine.

4. Rewrite for Cloud-Native: Containers and Lambda

Once you're on modern .NET, you can target Linux containers on ECS/Fargate or go fully serverless with Lambda. This is where the architecture changes, not just the runtime.

Linux Containers on ECS/Fargate

Containers are the natural next step for teams that want cloud-native benefits without going fully serverless. You get consistent environments, fast deployments, and fine-grained scaling without managing EC2 instances directly.

AWS Lambda: Fully Serverless

Lambda is where .NET on AWS gets interesting. You write functions, AWS handles everything else: scaling, patching, availability. You pay only for the milliseconds your code runs.

The historical knock on .NET Lambda was cold starts. With Native AOT (section 6), that's largely solved. A well-optimized .NET Lambda function starts in under 100ms, competitive with Node.js and Python.

In practice, most modern .NET applications on AWS use a mix: Lambda for API endpoints and event handlers, ECS for background workers and long-running processes. The two complement each other well.

5. x86 vs ARM/Graviton

AWS Graviton processors are ARM-based chips designed by Amazon. They offer better price-performance than equivalent x86 instances, typically 20% cheaper with equal or better throughput for most .NET workloads.

Making the Switch

For pure .NET code (no native dependencies), switching to Graviton is usually as simple as changing the architecture target. .NET's runtime handles the ARM compilation transparently.

// In your CDK stack or SAM template
Architecture = Lambda.Architecture.ARM_64

// Or in serverless.template
"Architectures": ["arm64"]

The main gotcha is native dependencies: NuGet packages that include platform-specific binaries (like SQLite, image processing libraries, or gRPC). These need ARM-compatible versions. Most popular packages support ARM64 now, but check before deploying.

6. Native AOT: Solving the Cold Start Problem

Native Ahead-of-Time (AOT) compilation is the biggest quality-of-life improvement for .NET on Lambda. Instead of shipping IL code that the JIT compiles at runtime, you ship a pre-compiled native binary. The result: cold starts drop from 1-3 seconds to under 100ms.

How It Works

Native AOT compiles your .NET code to a self-contained native binary at build time. No JIT, no runtime compilation, no reflection-based startup overhead. The binary starts like a Go or Rust program. Fast.

<PropertyGroup>
  <PublishAot>true</PublishAot>
  <StripSymbols>true</StripSymbols>
</PropertyGroup>

The Trade-offs

Native AOT isn't free. The compilation model imposes constraints:

In practice, if you're building new Lambda functions with modern patterns (source-generated JSON, constructor-based DI), AOT works smoothly. Retrofitting older code that relies heavily on reflection takes more effort. The stack trace issue is the most frustrating day-to-day trade-off. When something goes wrong in a dev environment, you're often left reading logs and reasoning about the failure rather than jumping straight to the line that threw.

7. Lambda Annotations: Writing Lambda Functions Like Normal C#

Lambda Annotations is an AWS-provided framework that lets you write Lambda functions using familiar ASP.NET-style patterns (attribute-based routing, dependency injection, model binding) instead of manually parsing APIGatewayProxyRequest objects.

It's a source generator. At build time, it generates the boilerplate Lambda handler code for you. You write clean C# methods; it handles the plumbing.

Before and After

public async Task<APIGatewayProxyResponse> GetCustomer(
    APIGatewayProxyRequest request, ILambdaContext context)
{
    var id = request.PathParameters["id"];
    var customer = await _service.GetAsync(id);
    return new APIGatewayProxyResponse
    {
        StatusCode = 200,
        Body = JsonSerializer.Serialize(customer),
        Headers = new Dictionary<string, string>
        {
            { "Content-Type", "application/json" }
        }
    };
}

[LambdaFunction]
[RestApi(LambdaHttpMethod.Get, "/customers/{id}")]
public async Task<IHttpResult> GetCustomer(
    [FromServices] ICustomerService service,
    string id)
{
    var customer = await service.GetAsync(id);
    return HttpResults.Ok(customer);
}

The difference is dramatic. The Annotations version reads like a normal ASP.NET controller method. Route parameters are extracted automatically, DI is handled via [FromServices], and response serialization is built in.

Key Features

Project Structure

A Lambda Annotations project is a standard .NET console application. The source generator creates the entry point and handler wiring. You organize your code however makes sense. I typically use a structure like this:

MyApi/
├── Functions/
│   ├── CustomerFunctions.cs      # Lambda function definitions
│   └── OrderFunctions.cs
├── Services/
│   ├── ICustomerService.cs       # Business logic interfaces
│   └── CustomerService.cs
├── Models/
│   └── CreateCustomerRequest.cs  # Request/response DTOs
├── Validators/
│   └── CreateCustomerValidator.cs
└── Startup.cs                    # DI registration

Each method decorated with [LambdaFunction] becomes its own Lambda function in AWS. You can have multiple functions in a single project. They share the same DI container and deployment package, but scale independently.

8. CDK with C#: Infrastructure as Actual Code

AWS CDK (Cloud Development Kit) lets you define cloud infrastructure using real programming languages instead of YAML or JSON templates. And yes, C# is a first-class CDK language.

This means your infrastructure code lives alongside your application code, in the same language, with the same IDE support: IntelliSense, refactoring, type checking, unit tests. No more context-switching between C# and CloudFormation YAML.

What CDK Looks Like

var table = new Table(this, "CustomersTable", new TableProps
{
    PartitionKey = new Attribute
    {
        Name = "pk",
        Type = AttributeType.STRING
    },
    BillingMode = BillingMode.PAY_PER_REQUEST,
    RemovalPolicy = RemovalPolicy.RETAIN
});

var function = new Function(this, "GetCustomerFunction", new FunctionProps
{
    Runtime = Runtime.DOTNET_10,
    Architecture = Architecture.ARM_64,
    Handler = "MyApi::MyApi.Functions_GetCustomer_Generated::GetCustomer",
    Code = Code.FromAsset("./src/MyApi/bin/Release/net10.0/publish"),
    MemorySize = 256,
    Timeout = Duration.Seconds(30),
    Environment = new Dictionary<string, string>
    {
        ["TABLE_NAME"] = table.TableName
    }
});

table.GrantReadData(function);

That last line — table.GrantReadData(function) — is where CDK shines. It automatically creates the IAM policy with the minimum permissions needed. No hand-crafting IAM JSON, no forgetting to add permissions, no overly broad dynamodb:* policies.

Why C# for CDK

9. FluentDynamoDB: DynamoDB Without the Pain

DynamoDB is the natural database choice for serverless .NET on AWS. It scales automatically, has single-digit millisecond latency, and costs nothing when idle. But the official AWS SDK for DynamoDB in .NET is... verbose. Very verbose.

FluentDynamoDB is an open source library I built to fix that. It's a source-generated, AOT-compatible framework that gives you a fluent, type-safe API for DynamoDB operations — without reflection, without the Document Model's runtime overhead, and without writing raw Dictionary<string, AttributeValue> everywhere.

The Problem It Solves

var request = new UpdateItemRequest
{
    TableName = "Customers",
    Key = new Dictionary<string, AttributeValue>
    {
        ["pk"] = new AttributeValue { S = "CUSTOMER#123" },
        ["sk"] = new AttributeValue { S = "PROFILE" }
    },
    UpdateExpression = "SET #name = :name, #ud = :ud",
    ExpressionAttributeNames = new Dictionary<string, string>
    {
        ["#name"] = "name",
        ["#ud"] = "updatedDate"
    },
    ExpressionAttributeValues = new Dictionary<string, AttributeValue>
    {
        [":name"] = new AttributeValue { S = "New Name" },
        [":ud"] = new AttributeValue { S = DateTime.UtcNow.ToString("O") }
    },
    ConditionExpression = "attribute_exists(pk)"
};
await client.UpdateItemAsync(request);

await table.Customers.Update(Customer.Keys.Pk("123"), Customer.Keys.Sk("PROFILE"))
    .IfExists()
    .Set(x => new CustomerUpdateModel
    {
        Name = "New Name",
        UpdatedDate = DateTime.UtcNow
    })
    .UpdateAsync();

Same result, a fraction of the code. And the FluentDynamoDB version is type-safe — the compiler catches typos in property names, and the source generator handles all the AttributeValue mapping.

Key Features

Entity Definition

You define entities with attributes, and the source generator creates the mapping code, key builders, and table accessors:

[DynamoDbTable("customers")]
public partial class Customer
{
    [PartitionKey(Prefix = "CUSTOMER")]
    [DynamoDbAttribute("pk")]
    public string Pk { get; set; } = string.Empty;

    [SortKey(Prefix = "PROFILE")]
    [DynamoDbAttribute("sk")]
    public string Sk { get; set; } = string.Empty;

    [DynamoDbAttribute("name")]
    public string Name { get; set; } = string.Empty;

    [DynamoDbAttribute("email")]
    public string Email { get; set; } = string.Empty;

    [GlobalSecondaryIndex("email-index", IsPartitionKey = true)]
    [DynamoDbAttribute("gsi1pk")]
    public string EmailIndex { get; set; } = string.Empty;
}

From that definition, FluentDynamoDB generates:

• • Customer.Keys.Pk("123") → "CUSTOMER#123"
• • Type-safe query builders for the table and GSI
• • CustomerUpdateModel for partial updates
• • Full ToDynamoDb() / FromDynamoDb() mapping — no reflection

Querying

// Query with lambda expressions
var customers = await table.Customers
    .Query(x => x.Pk == Customer.Keys.Pk(tenantId)
        && x.Sk.StartsWith("PROFILE"))
    .WithFilter(x => x.Status == "active")
    .Take(25)
    .ToListAsync();

// Pagination
var token = query.Response?.GetEncodedPaginationToken();
var nextPage = await table.Customers
    .Query(x => x.Pk == Customer.Keys.Pk(tenantId))
    .Paginate(new PaginationRequest(25, token))
    .ToListAsync();

The library also supports composite entities (multi-item patterns), projections, dynamic fields for sparse attribute patterns, batch operations, transactions, and PartiQL, all with the same fluent, type-safe API.

10. LambdaOpenApi: API Documentation from Your Code

If you're using Lambda Annotations, your functions already have route definitions, request/response types, and HTTP method declarations. LambdaOpenApi extracts that information at build time and generates an OpenAPI 3.0 specification. No manual spec maintenance, no Swagger annotations, no drift between your code and your docs.

The Problem

In a traditional ASP.NET Core application, Swashbuckle or NSwag generates your OpenAPI spec at runtime by reflecting over your controllers. Lambda functions don't have a running web server to reflect against. So .NET Lambda developers typically maintain OpenAPI specs by hand — which means they're always out of date.

How LambdaOpenApi Works

LambdaOpenApi is a build-time tool. It analyzes your Lambda Annotations project — the [RestApi] attributes, the method signatures, the request/response types — and generates a complete OpenAPI 3.0 document.

[LambdaFunction]
[RestApi(LambdaHttpMethod.Post, "/customers")]
[OpenApiOperation("CreateCustomer", "Creates a new customer")]
[OpenApiRequestBody(typeof(CreateCustomerRequest))]
[OpenApiResponse(201, typeof(Customer), "Customer created")]
[OpenApiResponse(400, typeof(ErrorResponse), "Validation error")]
public async Task<IHttpResult> CreateCustomer(
    [FromServices] ICustomerService service,
    [FromBody] CreateCustomerRequest request)
{
    // ...
}

dotnet build
# Outputs: openapi.json in your project directory

Why This Matters at Scale

When you have dozens of Lambda functions across multiple microservices, each generating its own OpenAPI spec, you can merge them into a unified API document at build time. This feeds into:

The spec is always accurate because it's generated from the code. No manual sync, no forgotten updates, no "the docs say one thing but the API does another."

11. Putting It All Together

Here's what a modern .NET on AWS stack looks like when you combine everything in this guide:

The Migration Roadmap

You don't need to adopt everything at once. Here's a practical sequence:

Each phase delivers standalone value. You can stop at any point and still be better off than where you started. The key is forward momentum. Don't let perfect be the enemy of progress.