Azure vs AWS for .NET Teams: How to Choose the Right Cloud for Your Workloads

I've built and deployed .NET applications on both Azure and AWS, and one of the most frequent questions I get from teams is simple: which one should we use?

The honest answer is that both are excellent platforms for modern .NET. Since .NET became cross-platform and container-friendly, the old assumption that "Microsoft stack means Microsoft cloud" no longer holds automatically. The right choice depends far more on your organisation, your existing investments, and your team's skills than on any single feature.

In this post I'll compare the two through the lens of a .NET team and finish with the decision framework I use with clients.

Hosting Your ASP.NET Core Applications

Both clouds offer a spectrum from fully managed to fully controlled.

Azure App Service is, in my view, one of the smoothest ways to run an ASP.NET Core app: deployment slots, easy scaling, built-in authentication, and first-class Visual Studio integration. Azure Container Apps is a strong middle ground for microservices when you want containers without managing Kubernetes.

On AWS, ECS with Fargate is the workhorse for containerised .NET services, and Lambda supports .NET well, including native AOT for faster cold starts. AWS's container offering is mature and battle-tested at enormous scale.

If your team prefers containers, the playing field is nearly level. A well-built Docker image of an ASP.NET Core app runs equally well on either cloud.

Data: SQL Server, PostgreSQL, and Beyond

This is often where the decision tips.

• SQL Server workloads: Azure SQL Database and Azure SQL Managed Instance are deeply integrated with the SQL Server ecosystem. Managed Instance in particular is attractive for lifting existing databases with minimal changes. AWS offers SQL Server on RDS, which works well, but Azure tends to feel more natural for SQL Server-heavy estates, and licensing options may favour it depending on your agreements.
• PostgreSQL: both are strong. Azure Database for PostgreSQL and Amazon RDS / Aurora PostgreSQL are excellent. If you're starting fresh, PostgreSQL with EF Core (via Npgsql) is a great, cloud-portable default.
• NoSQL: Azure Cosmos DB and Amazon DynamoDB are both powerful but have very different data modelling and pricing models. Prototype before committing.

Whichever you choose, keep your data access behind EF Core or well-defined repositories so the provider is a configuration detail:

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseNpgsql(builder.Configuration.GetConnectionString("Default")));

Identity and Security

For organisations already on Microsoft 365, Microsoft Entra ID (formerly Azure AD) is a significant advantage. Single sign-on, conditional access, and group-based authorisation integrate naturally with ASP.NET Core through Microsoft.Identity.Web.

On AWS, IAM is extremely granular for controlling access to cloud resources, and Amazon Cognito handles application user identity. Many AWS-hosted .NET apps still use Entra ID for workforce login, which works fine because it's standards-based (OpenID Connect).

For secrets, both offer managed stores: Azure Key Vault and AWS Secrets Manager. Both integrate with the .NET configuration system, so application code stays clean:

// Azure
builder.Configuration.AddAzureKeyVault(
    new Uri(builder.Configuration["KeyVault:Uri"]!), new DefaultAzureCredential());

The equivalent on AWS uses the AWS SDK's configuration extensions. Either way, prefer managed identities / IAM roles over connection strings with embedded credentials.

DevOps and Developer Experience

• CI/CD: Azure DevOps and GitHub Actions both deploy to either cloud. GitHub Actions has become my default because it's cloud-neutral and well supported by both providers.
• Infrastructure as Code: Azure has Bicep; AWS has CloudFormation and the AWS CDK, which you can write in C#. Terraform works across both and is a sensible choice for multi-cloud or for teams that want one IaC language.
• Tooling: Visual Studio and VS Code have deep Azure integration. AWS provides the AWS Toolkit for Visual Studio and an official .NET SDK that are mature and well documented.

Here's a small example of AWS CDK in C#, which many .NET developers appreciate because it's infrastructure in the language they already know:

var cluster = new Cluster(this, "AppCluster", new ClusterProps { Vpc = vpc });

new ApplicationLoadBalancedFargateService(this, "Api", new ApplicationLoadBalancedFargateServiceProps
{
    Cluster = cluster,
    TaskImageOptions = new ApplicationLoadBalancedTaskImageOptions
    {
        Image = ContainerImage.FromRegistry("myregistry/my-api:latest")
    }
});

Observability

Azure's Application Insights gives .NET developers a lot of value with very little setup: request tracing, dependency tracking, and exception analysis. AWS offers CloudWatch and X-Ray. My strong recommendation on either platform is to instrument with OpenTelemetry. It keeps your telemetry portable and lets you switch backends without touching application code.

Cost: Compare Workloads, Not Price Lists

Headline prices are rarely what decides your bill. What matters is:

• Right-sizing and autoscaling behaviour for your actual traffic.
• Reserved capacity or savings plans for steady workloads, which both clouds offer.
• Licensing: if you hold existing Windows Server or SQL Server licences, check what benefits apply on each platform.
• Data egress and inter-service traffic, which often surprises teams after go-live.

I always recommend estimating two or three real workloads in each provider's pricing calculator rather than comparing individual services in isolation.

My Decision Framework

When advising a team, I work through these questions in order:

1. What does the organisation already use? Existing enterprise agreements, Microsoft 365, or a central AWS landing zone usually outweigh feature differences.
2. What does the team know? Cloud skills take time to build. Productivity and operational safety come from familiarity.
3. What is the data estate? Heavy SQL Server usage leans toward Azure; heavy use of AWS-native services or data platforms leans toward AWS.
4. Which managed services save the most effort for this specific workload?
5. What are the compliance and regional requirements? Check that required regions and certifications are available for every service you plan to use.

As a rough rule of thumb: Microsoft-centric organisations with SQL Server and Entra ID will usually move fastest on Azure. Organisations already invested in AWS can run .NET there just as successfully.

Stay Portable Where It's Cheap

You don't need to be "multi-cloud" to benefit from portability. A few habits keep options open at little cost:

• Package services as containers.
• Use OpenTelemetry for observability.
• Keep cloud SDK usage behind your own interfaces in the infrastructure layer.
• Prefer open standards (OIDC, PostgreSQL, Terraform) where they fit.

Final Thoughts

There's no universal winner in Azure vs AWS for .NET. Both run modern ASP.NET Core applications reliably and at scale. Make the decision based on your organisation's ecosystem, your data, and your team's skills, then design your applications so that the cloud is an implementation detail rather than a permanent constraint.