Most .NET developers end up on Azure by default. Microsoft makes it easy: Visual Studio integration, App Service, Azure SQL, one-click deploy. But Azure's reliability track record is rough, the portal is a mess, and AWS has a broader, more mature set of services. Maybe your company already standardized on AWS. Maybe you want Lambda's scaling model. Either way, you realize the .NET-on-AWS ecosystem is way less obvious.
I've been building .NET on AWS for years — production multi-tenant SaaS in regulated industries, not side projects. I maintain open source libraries (FluentDynamoDB, LambdaOpenApi) that exist specifically because the built-in AWS tooling for .NET isn't enough. If your team is trying to make C# work on AWS and hitting walls, I've probably hit them first.
The .NET-on-AWS gap
AWS's documentation assumes you're using Python, TypeScript, or Java. The .NET examples are an afterthought. CDK has good C# support but the examples are all TypeScript. You can't write a .NET function in the Lambda web console the way you can with Node or Python — you need a proper build and deploy pipeline from day one. That's a higher barrier to entry, even though the end result is better.
The good news: modern .NET with AoT (Ahead-of-Time) compilation is one of the best-performing runtimes on Lambda today, second only to native Rust or C++. Cold starts under 300ms, tiny memory footprint, fast execution. It just takes more setup to get there than dropping a .js file in the console.
What I help .NET teams with on AWS
Lambda with .NET 10 and AoT
Getting cold starts under 300ms, handling the no-reflection constraint, structuring handlers, and knowing when Lambda isn't the right choice for your workload.
DynamoDB from C#
Data modeling for .NET developers who think in relational terms. Single-table design, access pattern mapping, and FluentDynamoDB for type-safe repositories instead of raw SDK boilerplate.
CDK in .NET
Infrastructure as code in C# so your whole team can read it. Construct libraries, multi-stack patterns, and CI/CD pipelines that deploy through CDK.
Migration from Azure or .NET Framework
Incremental paths from Azure App Service to Lambda or ECS. From Azure SQL to DynamoDB or Aurora. From .NET Framework to modern .NET. One service at a time.
Source generators over reflection
AoT kills reflection, which breaks a lot of traditional .NET patterns. Source generators do the same work at compile time. I've built production source generators and can help your team adopt them.
Open source I maintain in this space
These exist because I needed them and they didn't exist:
FluentDynamoDB
Type-safe DynamoDB repositories with source generation. No reflection, no runtime surprises.
LambdaOpenApi
Compile-time OpenAPI documentation for Lambda functions. Zero runtime cost.
LambdaGraphQL
AppSync GraphQL integration for .NET. Source-generated resolver manifests and a client for pushing mutations.
Sound familiar?
"We're a .NET shop but our company is all-in on AWS."
Common in enterprises that standardized on AWS for everything else. I'll help your .NET team become productive on AWS without abandoning the language and ecosystem they know.
"Lambda cold starts are killing our API response times."
Solvable with AoT compilation, but it means restructuring how you do DI, serialization, and validation. The no-reflection constraint breaks a lot of libraries people rely on.
"We're still on .NET Framework and need to modernize."
The Upgrade Assistant gets you partway. The rest is untangling Framework-specific dependencies, replacing System.Web, and choosing between Lambda and ECS based on your workload characteristics.
Frequently Asked Questions
Is AWS a good fit for .NET applications?
Yes, but it's a different experience than Azure. AWS doesn't hand you integrated tooling the way Visual Studio + Azure does. You get more flexibility and often better pricing, but you need to know the patterns. Lambda supports .NET 10 with AoT compilation, DynamoDB works great from C#, and CDK has first-class .NET support. The gap has closed significantly in the last few years.
Should I use Native AoT for Lambda?
For most APIs, yes. AoT compilation drops cold starts from 2-3 seconds down to 200-400ms, which makes Lambda viable for synchronous API calls. The trade-off is you lose reflection, which means some libraries (like certain DI containers and ORMs) won't work without changes. Source generators are the answer — they do at compile time what reflection does at runtime.
Can I use Entity Framework with DynamoDB?
No. DynamoDB is not a relational database and ORM patterns don't apply. You need to think in terms of access patterns, not tables and joins. Libraries like FluentDynamoDB provide a type-safe repository pattern that feels familiar to .NET developers while respecting DynamoDB's actual data model.
What about migrating from Azure to AWS?
It's doable but requires rethinking some assumptions. Azure App Service maps roughly to ECS or Lambda. Azure SQL maps to RDS or (better for serverless) DynamoDB. Azure Functions maps to Lambda. The code ports easily — the infrastructure and deployment patterns are what change. Incremental migration works best: move one service at a time rather than a big-bang replatform.