AWS vs Azure vs GCP for .NET developers compared in 2026. See pricing, C# SDK code, serverless and hosting options, then pick the best cloud for your app.
The AWS vs Azure vs GCP debate comes up on almost every .NET team, usually right before a migration or a greenfield project kicks off. In 2026 all three clouds run .NET 10 well, publish official C# SDKs, and offer serverless, containers, and managed SQL. That makes the decision harder, not easier, because the differences are now about developer experience, pricing models, and ecosystem fit rather than raw capability. This guide compares AWS, Azure, and Google Cloud specifically from a C# and .NET developer's point of view, with runnable code, pricing notes, and a clear recommendation.
AWS vs Azure vs GCP: The Short Answer for .NET Developers
If you want the recommendation up front, here it is:
- Choose Azure if your team lives in Visual Studio, uses Entra ID (Azure AD), Microsoft 365, or SQL Server, or wants the smoothest path for ASP.NET Core, Blazor, and .NET Aspire.
- Choose AWS if you need the broadest service catalog, your company already standardizes on AWS, or you are building high-scale event-driven systems where Lambda, SQS, and DynamoDB are the backbone.
- Choose GCP if your workload is container-first (Cloud Run, GKE), leans heavily on data and analytics (BigQuery), or you value simple, predictable pricing and a clean developer experience.
The rest of this article explains why, so you can defend that choice to your architect, your CTO, or your future self during the 2 a.m. outage.
Market Share and Momentum in 2026
Market position matters because it affects hiring, community answers on Stack Overflow, and how quickly a new .NET feature is supported. As of 2026, AWS still holds the largest share of global cloud infrastructure at roughly 30 percent, Azure sits in the low-to-mid 20s and continues to grow fastest among the big three, and Google Cloud holds around 11 to 12 percent. For .NET developers specifically, the picture is different. Azure has the deepest Microsoft integration, but AWS has invested heavily in .NET for over a decade with its own .NET team, the AWS Toolkit for Visual Studio and Rider, and first-day support for new .NET LTS releases on Lambda. GCP is the smallest of the three in .NET mindshare, but its .NET client libraries are mature and its container story is arguably the cleanest.
Hosting an ASP.NET Core App: Side by Side
Most .NET workloads are web APIs or full web apps. Here is how each cloud handles them.
Azure App Service and Azure Container Apps
Azure App Service is the classic platform-as-a-service choice. You right-click Publish in Visual Studio or run az webapp up, and your ASP.NET Core app is live with TLS, deployment slots, and autoscale. Azure Container Apps is the newer serverless container platform built on Kubernetes and KEDA, and it is the recommended target for .NET Aspire applications. The azd CLI can deploy an entire Aspire app model, including Redis, PostgreSQL, and multiple services, with one command.
AWS Elastic Beanstalk, App Runner, and ECS Fargate
AWS gives you three realistic paths. Elastic Beanstalk is the closest analog to App Service and supports .NET on Linux and Windows. App Runner is the simplest container option, similar to Cloud Run. ECS on Fargate is the production workhorse for containerized .NET services. The AWS .NET team ships a deployment tool, dotnet aws deploy, that inspects your project and recommends the right compute target.
Google Cloud Run and GKE
Cloud Run is the standout GCP service for .NET developers. You give it a container image, and it scales to zero when idle and up to thousands of instances under load. Billing is per 100 milliseconds of request time, which is excellent for bursty APIs. GKE Autopilot handles Kubernetes with less operational burden than managing node pools yourself.
The Dockerfile you use is the same on all three clouds, which is one of the biggest wins of .NET's container-first tooling:
// Program.cs - a minimal API that runs unchanged on App Service, App Runner, or Cloud Run
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHealthChecks();
var app = builder.Build();
// All three clouds set PORT (Cloud Run, App Runner) or ASPNETCORE_URLS (App Service).
// Kestrel reads ASPNETCORE_URLS automatically; PORT needs one line.
var port = Environment.GetEnvironmentVariable("PORT");
if (!string.IsNullOrEmpty(port))
{
app.Urls.Add($"http://0.0.0.0:{port}");
}
app.MapHealthChecks("/healthz");
app.MapGet("/api/orders/{id:int}", (int id) =>
Results.Ok(new { Id = id, Status = "Shipped", Cloud = Environment.GetEnvironmentVariable("CLOUD_NAME") ?? "local" }));
app.Run();
You can also skip the Dockerfile entirely with the .NET SDK's built-in container publish:
// Run from the project folder. Produces an OCI image without a Dockerfile.
// dotnet publish -c Release -p:PublishProfile=DefaultContainer -p:ContainerRepository=orders-api
Serverless: Azure Functions vs AWS Lambda vs Cloud Functions in C#
This is where the developer experience differs most, and it is one of the most searched comparisons for .NET developers.
AWS Lambda with C#
Lambda supports .NET 8 and .NET 10 managed runtimes with Native AOT for sub-100 millisecond cold starts. The programming model uses attributes from the Lambda Annotations framework, which generates the boilerplate at compile time:
using Amazon.Lambda.Annotations;
using Amazon.Lambda.Annotations.APIGateway;
using Amazon.Lambda.Core;
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
public class OrderFunctions
{
private readonly IOrderRepository _repo;
// Constructor injection works via Lambda Annotations + a Startup class
public OrderFunctions(IOrderRepository repo) => _repo = repo;
[LambdaFunction(MemorySize = 512, Timeout = 30)]
[HttpApi(LambdaHttpMethod.Get, "/orders/{id}")]
public async Task<IHttpResult> GetOrder(int id, ILambdaContext context)
{
context.Logger.LogInformation($"Fetching order {id}");
var order = await _repo.GetAsync(id);
return order is null
? HttpResults.NotFound()
: HttpResults.Ok(order);
}
}
Azure Functions with C#
Azure Functions uses the isolated worker model, which runs your code in a normal .NET process so you control the host, dependency injection, and middleware. It feels like ASP.NET Core:
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
using System.Net;
public class OrderFunctions
{
private readonly IOrderRepository _repo;
private readonly ILogger<OrderFunctions> _logger;
public OrderFunctions(IOrderRepository repo, ILogger<OrderFunctions> logger)
{
_repo = repo;
_logger = logger;
}
[Function("GetOrder")]
public async Task<HttpResponseData> GetOrder(
[HttpTrigger(AuthorizationLevel.Function, "get", Route = "orders/{id:int}")] HttpRequestData req,
int id)
{
_logger.LogInformation("Fetching order {OrderId}", id);
var order = await _repo.GetAsync(id);
var response = req.CreateResponse(order is null ? HttpStatusCode.NotFound : HttpStatusCode.OK);
if (order is not null)
{
await response.WriteAsJsonAsync(order);
}
return response;
}
}
Google Cloud Functions with C#
Google's Functions Framework for .NET is the simplest of the three. A function is a class implementing IHttpFunction, and under the hood it is just an ASP.NET Core app deployed to Cloud Run:
using Google.Cloud.Functions.Framework;
using Microsoft.AspNetCore.Http;
using System.Threading.Tasks;
public class GetOrderFunction : IHttpFunction
{
public async Task HandleAsync(HttpContext context)
{
var idValue = context.Request.Query["id"];
if (!int.TryParse(idValue, out var id))
{
context.Response.StatusCode = 400;
await context.Response.WriteAsync("Missing or invalid id");
return;
}
await context.Response.WriteAsJsonAsync(new { Id = id, Status = "Shipped" });
}
}
Verdict on serverless: Azure Functions offers the richest binding model (Cosmos DB, Service Bus, Durable Functions for orchestrations). AWS Lambda has the best cold-start story thanks to early and thorough Native AOT support, plus the SnapStart feature. GCP is the simplest to learn but has the thinnest binding ecosystem.
Databases and Storage for .NET Apps
Entity Framework Core works everywhere, so the real question is which managed database fits your data model and budget.
- SQL Server: Azure SQL Database is the obvious winner, with serverless tiers, Hyperscale, and native Entra ID authentication. AWS RDS for SQL Server works but licensing is more expensive. GCP Cloud SQL for SQL Server exists but sees less investment.
- PostgreSQL: All three are strong. AWS Aurora PostgreSQL and Azure Database for PostgreSQL Flexible Server are mature. GCP AlloyDB is a compelling high-performance option. Npgsql makes the .NET side identical.
- NoSQL: Azure Cosmos DB has a first-class .NET SDK and LINQ support. AWS DynamoDB is cheaper at massive scale but has a steeper learning curve for developers used to relational modeling. GCP Firestore is simple and developer friendly.
- Blob storage: Azure Blob Storage, Amazon S3, and Google Cloud Storage are functionally equivalent for most .NET apps.
Here is the same upload operation on all three, showing how similar the modern SDKs feel:
// Azure Blob Storage (Azure.Storage.Blobs)
var blobClient = new BlobContainerClient(connectionString, "invoices");
await blobClient.UploadBlobAsync("2026/inv-1001.pdf", fileStream);
// Amazon S3 (AWSSDK.S3)
var s3 = new AmazonS3Client();
await s3.PutObjectAsync(new PutObjectRequest
{
BucketName = "invoices",
Key = "2026/inv-1001.pdf",
InputStream = fileStream
});
// Google Cloud Storage (Google.Cloud.Storage.V1)
var gcs = await StorageClient.CreateAsync();
await gcs.UploadObjectAsync("invoices", "2026/inv-1001.pdf", "application/pdf", fileStream);
Pricing Comparison: What .NET Teams Actually Pay
List prices are close enough that the winner depends on your usage pattern rather than the rate card. A few practical observations from 2026 pricing:
- Windows licensing: If you still run .NET Framework 4.8 on Windows Server, Azure Hybrid Benefit lets you reuse existing Windows Server and SQL Server licenses, which can cut compute bills by 40 percent or more. AWS and GCP charge for Windows licensing on top of compute.
- Serverless: Lambda, Azure Functions Consumption, and Cloud Functions all have generous free tiers (roughly one to two million requests per month). Cloud Run's per-100-millisecond billing and CPU throttling between requests make it the cheapest for spiky HTTP APIs.
- Egress: Data leaving the cloud is where bills explode. GCP has historically been slightly cheaper on egress, and all three now offer free egress when you migrate away, thanks to regulatory pressure in the EU and UK.
- Committed spend: AWS Savings Plans, Azure Reservations, and GCP Committed Use Discounts all offer 30 to 60 percent off for one- or three-year commitments.
The honest advice is to run your real workload for a month on the cloud's free tier before committing. Synthetic pricing calculators consistently underestimate egress and logging costs.
Developer Experience and Tooling
This is where Azure pulls ahead for most .NET teams, and it is not close.
- Azure: Visual Studio publish profiles, GitHub Actions templates generated from the portal, .NET Aspire integration, Azure Developer CLI, and Application Insights with automatic ASP.NET Core instrumentation. Managed identity removes connection strings from your code entirely.
- AWS: The AWS Toolkit for Visual Studio and Rider, the
dotnet awsCLI tooling, Lambda test tool, and the excellent AWS .NET SDK. The AWS Cloud Development Kit (CDK) lets you define infrastructure in C#, which many .NET teams prefer over Bicep or Terraform HCL. - GCP: Cloud Code for Visual Studio Code and the Functions Framework are solid, and the client libraries are consistently designed. Tooling inside Visual Studio proper is thinner.
Here is a small example of why managed identity on Azure feels so natural in .NET. No secrets, no key rotation:
using Azure.Identity;
using Azure.Storage.Blobs;
// DefaultAzureCredential uses your Visual Studio login locally
// and the app's managed identity in App Service / Container Apps.
var credential = new DefaultAzureCredential();
var blobService = new BlobServiceClient(
new Uri("https://mystorageacct.blob.core.windows.net"),
credential);
await foreach (var container in blobService.GetBlobContainersAsync())
{
Console.WriteLine(container.Name);
}
AWS achieves the same result with IAM roles and the default credential chain in the AWS SDK, and GCP uses Application Default Credentials. All three work well. Azure simply has the tightest loop between local development and production for a Windows-based .NET developer.
Best Practices When Choosing a Cloud for .NET
- Design for portability at the edges, not everywhere. Use abstractions like
IDistributedCache,IFileProvider, and OpenTelemetry so swapping providers is a configuration change. Do not build a full cloud-agnostic layer; it costs more than any migration you will actually do. - Prefer Linux containers. Linux compute is cheaper on all three clouds and .NET 10 runs identically. Reserve Windows hosting for legacy .NET Framework apps.
- Use OpenTelemetry from day one. Azure Monitor, AWS X-Ray and CloudWatch, and Google Cloud Trace all accept OTLP. Your instrumentation code stays the same across clouds.
- Adopt infrastructure as code in C# where possible. AWS CDK and Pulumi both support C#, keeping your whole stack in one language and one review process.
- Enable Native AOT for serverless. Cold starts drop from around one second to under 100 milliseconds on Lambda and Azure Functions Flex Consumption.
Common Pitfalls
- Assuming Azure is automatically cheapest for .NET. It is often cheapest for Windows and SQL Server workloads because of Hybrid Benefit. For Linux containers and PostgreSQL, AWS and GCP frequently win.
- Ignoring region availability. Newer services, like Azure Container Apps features or Lambda SnapStart for .NET, roll out to US regions first. Teams in Australia, Canada, and India should check regional availability before designing around a feature.
- Hardcoding cloud-specific SDK calls in business logic. Keep SDK usage in a thin infrastructure layer behind interfaces. Your domain code should not know what S3 is.
- Forgetting the exit cost. Cosmos DB and DynamoDB data models do not port cleanly. If you might leave, PostgreSQL is the safest bet.
- Skipping the free tier trial. Every cloud offers credits. Deploy a real slice of your app to two of them and compare the bills and the developer friction honestly.
Conclusion: AWS vs Azure vs GCP for .NET Developers in 2026
There is no universal winner in the AWS vs Azure vs GCP comparison, but there is usually a clear winner for your team. Azure remains the best default for most .NET shops because of Visual Studio integration, managed identity, .NET Aspire, and licensing benefits for SQL Server and Windows. AWS is the right call when your organization already runs on it, when you need the deepest service catalog, or when Lambda's Native AOT cold-start performance matters. GCP deserves serious consideration for container-first and data-heavy workloads, where Cloud Run and BigQuery offer the best price-to-effort ratio.
Key takeaways:
- All three clouds run .NET 10 well; the decision is about ecosystem fit, not capability.
- Azure wins on developer experience and Microsoft licensing. AWS wins on breadth and serverless performance. GCP wins on container simplicity and predictable pricing.
- Use Linux containers, OpenTelemetry, and thin infrastructure abstractions so you can change your mind later without a rewrite.
- Test your real workload on a free tier before signing a multi-year commitment.
Whichever cloud you choose, the skills transfer. A .NET developer who understands containers, managed identity, and event-driven design will be productive on AWS, Azure, or GCP within weeks.
Your go-to resource for C#, .NET, and modern software development. Follow along for daily tutorials, tips, and real-world examples.
Comments
Post a Comment