Essential AWS Services Every .NET Developer Should Master in 2026

Amazon Web Services (AWS) remains the dominant cloud platform, and for .NET developers the hard part is not the 200+ services on the menu - it is knowing which handful you actually need. The short answer: most production .NET apps on AWS run on about seven services - AWS Lambda or ECS Fargate for compute, Amazon S3 for files, Amazon RDS or DynamoDB for data, SQS and SNS for messaging, IAM and Cognito for security, and CloudWatch for observability. Everything else is situational.

In this article, I will walk through the essential AWS services every .NET developer should master in 2026, grouped by use case so you can map a problem to the right tool. The headline change this year for .NET developers: AWS Lambda now ships a .NET 10 managed runtime, so the newest long-term-support release of .NET runs serverless on AWS with first-class support. Let’s get into it.

Most of the services below have a dedicated, hands-on tutorial on this blog. I link to each one under the relevant section so you can go deep when you need to. If you want the structured path instead of jumping around, my free AWS for .NET Developers course covers this end to end.

The .NET Developer’s AWS Service Map (Quick Reference)

Before the deep dive, here is the cheat sheet. If you only remember one thing from this article, make it this table. It maps each essential service to the problem it solves, how it fits a .NET workflow, and the shape of its bill.

To keep things readable, the rest of this guide categorizes these services by their primary use case so you can find the right tool for the challenge in front of you.

How You Actually Call These Services (The AWS SDK for .NET)

Every service below is reached through the AWS SDK for .NET. You add the per-service NuGet package (AWSSDK.S3, AWSSDK.DynamoDBv2, and so on), register the client with services.AddAWSService<IAmazonS3>() from AWSSDK.Extensions.NETCore.Setup, and the SDK resolves credentials and region from your environment. Locally that means a named profile in your ~/.aws/credentials file; in production it means an IAM role attached to your Lambda, ECS task, or EC2 instance - never hardcoded keys.

One 2026 note that bites people: use AWS SDK for .NET v4, which went generally available in April 2025. Version 3 reached end-of-support on June 1, 2026, so any new project should target v4 today. The package IDs (AWSSDK.*) are the same across v3 and v4, so the change is mostly a version bump plus a few breaking-change fixes.

How Do You Run a .NET App on AWS?

This is the first question every team hits, and AWS gives you several answers depending on how much control versus convenience you want.

AWS Lambda

AWS Lambda is a serverless compute service that runs your code without provisioning or managing servers. For .NET developers, Lambda is excellent for event-driven applications, microservices, and lightweight functions triggered by events such as HTTP requests, queue messages, or file uploads to S3. It scales automatically with load and scales to zero, so you pay per request and nothing while idle - which is why it wins for spiky or low-volume traffic. A function can run for up to 15 minutes, use up to 10 GB of memory, and the first 1 million requests each month are free.

.NET 10 on Lambda (new in 2026): As of January 8, 2026, AWS Lambda supports .NET 10 as a managed runtime and as a container base image. Because .NET 10 is the latest long-term-support (LTS) release - supported with security and bug fixes until November 2028 - this is the version I recommend for any new serverless .NET function. AWS automatically patches the managed runtime and base image, and .NET 10 brings JIT and Native AOT improvements that cut executable size and cold-start time. See the official AWS Lambda runtimes documentation and the .NET 10 support announcement for the details.

Cold starts are the classic concern with serverless .NET. If latency matters, SnapStart restores a pre-initialized snapshot of your function instead of cold-starting from scratch, and AWS documents up to a 10x reduction in cold-start time.

For orchestrating multiple Lambdas into a workflow, AWS Step Functions with .NET lets you coordinate steps, retries, and error handling without writing the glue yourself.

Amazon ECS with Fargate

Amazon ECS (Elastic Container Service) with Fargate runs containerized .NET applications without managing the underlying servers. Fargate provisions compute on demand, so you ship a container image of your ASP.NET Core app and let AWS scale it based on the container’s resource needs. It integrates cleanly with load balancers, IAM, and CloudWatch, which makes it a strong default for long-running services, WebSockets, and microservices that need more than a single short-lived function. For batch or queue-worker containers that tolerate interruption, Fargate Spot runs them for up to ~70% off on-demand pricing.

You do not even need a Dockerfile anymore. The .NET 10 SDK builds an OCI container image directly with dotnet publish /t:PublishContainer, defaulting to a small chiseled base. Push that to Amazon Elastic Container Registry (ECR) and point Fargate at it.

If you want the deploy automated, see deploying a .NET Web API to ECS with GitHub Actions for a full CI/CD pipeline.

EC2, Elastic Beanstalk, and ECS Express Mode

Amazon EC2 (Elastic Compute Cloud) is the foundational service for running virtual machines in the cloud. It gives you full control over the operating system and installed software, which makes it the natural home for a lift-and-shift or for workloads with specific OS-level requirements. The tradeoff is ownership: you patch, scale, and secure the instance yourself. It is maximum flexibility at maximum operational overhead.

If you want a managed middle ground, AWS Elastic Beanstalk automates deployment, scaling, and monitoring of web apps including .NET, and Amazon ECS Express Mode is the simplest managed path to a containerized API: point it at a container image and it handles networking, load balancing, and scaling for you. ECS Express Mode is also the service AWS now recommends in place of AWS App Runner, which moved to maintenance mode and closed to new customers on April 30, 2026 - so I would not start a new project on App Runner today.

Not sure which compute option fits your workload? I wrote a dedicated comparison.

Where Does a .NET App Store Files? (S3)

Almost every app needs somewhere to put files, and on AWS that is overwhelmingly Amazon S3.

Amazon S3 (Simple Storage Service)

Amazon S3 (Simple Storage Service) is the most widely used storage service in AWS - highly scalable object storage designed for 11 nines of durability (99.999999999%). It is ideal for images, videos, documents, backups, and logs, with versioning, lifecycle policies, and fine-grained access control built in. For .NET applications, you integrate S3 for uploads, downloads, and backups using the AWS SDK for .NET, and the first 5 GB are free for the first 12 months. This is arguably the single most-used AWS service across .NET projects.

Two S3 patterns come up constantly in real apps. Presigned URLs let clients upload and download directly to S3 without routing bytes through your API, and multipart upload handles large files reliably.

For very large files, see large file uploads with S3 multipart and presigned URLs. And for a real event-driven example, serverless image processing with S3, SQS, and Lambda ties storage, messaging, and compute together.

Which AWS Database Should a .NET Developer Use?

AWS offers managed databases across relational, NoSQL, and in-memory workloads. The trick is matching the engine to your data shape.

Amazon RDS (Relational Database Service)

Amazon RDS (Relational Database Service) is a managed relational database that supports SQL Server, PostgreSQL, MySQL, MariaDB, Oracle, and IBM Db2. RDS handles backups, patching, and scaling so you can focus on your application. For .NET developers, RDS is the natural relational option and works directly with Entity Framework Core - the recommended approach for most line-of-business apps that need transactions and relationships.

For most .NET line-of-business apps, plain RDS (PostgreSQL or SQL Server) is the right default. Reach for Amazon Aurora when you want higher throughput and read-replica scale, or Aurora Serverless v2 when traffic is bursty and you want the database to scale down between spikes. EF Core treats both as ordinary PostgreSQL or MySQL.

Amazon DynamoDB

Amazon DynamoDB is a fully managed NoSQL database that delivers single-digit millisecond latency at any scale. It is ideal for key-value and document data - real-time analytics, gaming, high-traffic APIs - and the first 25 GB are free. For .NET developers working with non-relational data, DynamoDB is simple and cost-effective, with a strong object persistence model in the AWS SDK.

DynamoDB has sharp edges worth knowing: when to use UpdateItem vs PutItem in .NET, and how to handle concurrency with optimistic locking so two writers do not silently clobber each other. One warning: single-table design is the most over-applied pattern in AWS .NET content. If you cannot already name your access patterns, you want RDS.

Amazon ElastiCache

Amazon ElastiCache is a fully managed in-memory data store supporting Valkey, Redis OSS, and Memcached, in both node-based and serverless flavors. AWS now recommends Valkey for new deployments because it is Redis-compatible and cheaper. It caches frequently accessed data to reduce database load - perfect for session storage, real-time analytics, and caching API responses. Serving a cached read from memory avoids the database round trip entirely, so hot-path reads drop from tens of milliseconds to sub-millisecond.

How Do You Secure a .NET App on AWS?

Security is non-negotiable, and for .NET applications on AWS two services do the heavy lifting: IAM for resource access and Cognito for user authentication.

AWS IAM (Identity and Access Management)

AWS IAM (Identity and Access Management) controls who and what can access your AWS resources. You create users, groups, and roles, and attach policies that enforce least-privilege access. IAM is the single most important security service to understand, because almost every other service depends on it, and it is free.

With IAM, you can:

• Create users and assign permissions: give each user access only to what they need.
• Create roles and policies: attach roles to your EC2 instances, Lambda functions, and ECS tasks so they access AWS resources securely without hardcoded keys. You will use this constantly.
• Enable MFA (Multi-Factor Authentication): add a second layer to user authentication.
• Monitor and audit access: use AWS CloudTrail to log API activity and catch unauthorized access.

For production, rotate keys automatically - see automated IAM access key rotation.

Amazon Cognito

Amazon Cognito is a fully managed service for user authentication, authorization, and user management in web and mobile apps. It lets you add secure sign-up and sign-in to your .NET applications without building auth infrastructure yourself, including social and enterprise identity providers, and it has a free tier for monthly active users.

Key features of Amazon Cognito include:

• User pools: a managed user directory for sign-ups, sign-ins, and profiles.
• Identity pools: let authenticated users access AWS resources securely.
• Federated identities: allow login with existing third-party credentials.
• Multi-Factor Authentication (MFA): require extra verification steps.

IAM controls machine and service access at a granular level, while Cognito handles your end users. You need both.

Configuration and Secrets

Hardcoding connection strings and API keys is the fastest way to leak them. AWS gives you two managed stores, and both have clean .NET integrations. The rule of thumb: use AWS Systems Manager Parameter Store for plain config and anything you read at startup (standard parameters are free), and AWS Secrets Manager only when you need automatic rotation or cross-account sharing, since it bills per secret per month. Most apps need Parameter Store far more than they think.

For straightforward app configuration, see using AWS Parameter Store in .NET.

How Do You Monitor a .NET App on AWS?

When something breaks in production, observability is the difference between a five-minute fix and an all-nighter. Three services cover it.

Amazon CloudWatch

Amazon CloudWatch provides real-time metrics, logs, and alarms for your AWS resources and applications. You can track CPU, memory, network, and custom application metrics, collect logs, and trigger alarms on critical events.

Key features for .NET developers include:

• Metric monitoring: visualize system and application metrics on dashboards.
• Logs monitoring: collect and analyze logs from your .NET apps with CloudWatch Logs.
• Alarms: get notified on high resource use or error spikes.
• Events: trigger automated actions in response to events.

Tracing with OpenTelemetry and X-Ray

AWS X-Ray gives you end-to-end tracing across a distributed .NET application - request tracing, error detection, a service map, and per-component latency. In 2026, the recommended way to instrument is the OpenTelemetry .NET SDK (vendor-neutral), exported to X-Ray and CloudWatch through the AWS Distro for OpenTelemetry (ADOT), rather than the older X-Ray SDK. CloudWatch Application Signals then layers an APM-style service map and service-level objectives on top. This matters most for microservices, where the call graph is hard to reason about by hand.

AWS CloudTrail

AWS CloudTrail records API calls made to your AWS account so you can audit and monitor activity. It tracks changes, surfaces unusual behavior, and supports compliance - security auditing (who accessed what, and when), troubleshooting unauthorized access or config changes, and keeping a detailed record for audits.

Together, CloudWatch, X-Ray, and CloudTrail give you metrics, traces, and an audit trail - the three pillars of keeping a production .NET app healthy.

Adding AI to .NET Apps with AWS

More and more .NET apps need to read documents, analyze images, or generate text. AWS exposes all three from the SDK, no data-science background required.

Amazon Rekognition

Amazon Rekognition is an image and video analysis service that handles object detection, facial recognition, and text extraction. It is a fit for .NET features like content moderation, identity verification, and tagging - object and scene detection, facial analysis, and text detection from images or video.

Amazon Textract

Amazon Textract goes beyond simple optical character recognition (OCR) to extract text, forms, and tables from scanned documents and PDFs. For .NET apps that process invoices, receipts, or onboarding documents, Textract turns unstructured files into structured data you can act on.

Amazon Bedrock

Amazon Bedrock is a fully managed service for integrating generative AI without managing infrastructure. It gives .NET developers access to foundation models from providers like Amazon (Nova), Anthropic, Meta, Mistral AI, and Cohere for text generation, summarization, and content creation.

The .NET angle that makes Bedrock worth picking: you call it either through the AWS SDK’s Converse API (one request shape across every model) or through Microsoft.Extensions.AI, so the same IChatClient code you would write against Azure OpenAI works against Anthropic models on Bedrock. That portability - swap the model, keep the code - is the real reason to choose Bedrock over a single-vendor SDK.

How Do AWS Services Talk to Each Other? (SQS, SNS, EventBridge)

Messaging is how you build scalable, decoupled, resilient .NET systems through asynchronous communication and event-driven architectures.

Amazon SQS (Simple Queue Service)

Amazon SQS (Simple Queue Service) is a fully managed message queue for decoupling and scaling microservices and serverless apps. Messages can be up to 256 KB and are retained for up to 14 days. Standard queues give near-unlimited throughput; FIFO queues maintain order at 300 transactions per second (3,000 with batching).

Key benefits for .NET developers:

• Standard and FIFO queues: standard for high throughput, FIFO for ordering and de-duplication.
• Decoupled architecture: components communicate reliably without direct dependencies.
• Reliable processing: automatic retries with Dead Letter Queues for diagnostics.

Amazon SNS (Simple Notification Service)

Amazon SNS (Simple Notification Service) is a fully managed publish/subscribe service that broadcasts messages to multiple subscribers such as microservices or end users - event-driven notifications to apps, devices, or email, topic-based filtering, and fan-out to SQS or Lambda.

SQS and SNS solve different problems, and mixing them up is a common mistake. If you are deciding between them, read SQS vs SNS - when to use what. For higher-level messaging, the AWS Message Processing Framework for .NET gives you a clean abstraction over both.

Amazon EventBridge

Amazon EventBridge is a serverless event bus that connects applications using events. It routes events from AWS services or custom apps to targets like Lambda, SQS, or HTTP endpoints, validates them against a schema registry, and (through EventBridge Pipes) wires point-to-point integrations with filtering and transformation in between.

Amazon API Gateway

Amazon API Gateway is a fully managed service for creating, deploying, and managing APIs at any scale. It is the go-to front door for serverless .NET applications, integrating directly with AWS Lambda. It enforces a default account limit of 10,000 requests per second and a 29-second integration timeout, so it doubles as a throttle in front of your backend.

Key benefits for .NET developers:

• REST and WebSocket APIs: build both request/response and real-time APIs.
• Integration with AWS Lambda: trigger .NET Lambda functions for backend logic.
• Throttling and rate limiting: protect APIs with built-in quotas.
• Security: secure APIs with Cognito, IAM policies, or API keys.
• Monitoring: use CloudWatch for API metrics and logging.

Networking and Infrastructure You’ll Touch but Rarely Configure by Hand

A few services are the plumbing every app runs on, but a .NET developer mostly configures them once and moves on:

• Amazon VPC (Virtual Private Cloud): the isolated network your resources run inside. You define IP ranges, subnets, and routing, mostly to restrict access to databases and internal services.
• Amazon Route 53: scalable DNS (Domain Name System) with health checks and failover that routes users to your app on EC2, a load balancer, or elsewhere.
• Elastic Load Balancing (ELB): distributes incoming traffic across EC2 instances or containers so your app stays available under load. Fargate and EC2 services sit behind one.
• Amazon EBS and EFS: block storage for EC2 instances (EBS) and a shared file system across instances (EFS), for the rarer cases where object storage in S3 is not the right shape.

Infrastructure as Code and Local Development

Clicking around the AWS console is fine for learning, but production environments should be defined in code so they are repeatable and reviewable. As a .NET developer you have three solid options: Terraform (most widely used, cloud-agnostic), AWS CDK (define infrastructure in C#), and AWS SAM CLI (serverless-focused, great for local Lambda testing).

If you prefer C# over HCL, see AWS CDK for .NET developers.

Running AWS Locally

You do not have to pay AWS to develop against it. LocalStack emulates S3, SQS, DynamoDB, and dozens of other services on your machine, so your inner loop costs nothing and runs offline. Paired with .NET Aspire, you get the emulated dependencies wired straight into your app’s startup.

What Does This Actually Cost? (Free Tier and the Surprise Bills)

AWS gives new accounts a free tier, and several services have an always-free allowance: 1 million Lambda requests a month, 25 GB of DynamoDB storage, and 5 GB of S3 for the first year. For a .NET dev kicking the tires, Lambda + DynamoDB + S3 will likely cost nothing on a hobby project, because all three genuinely scale to zero.

The bills that surprise people are not compute. They are the NAT Gateway (which bills roughly $32 a month before a single byte of traffic) and an always-on RDS instance you forgot was running. The moment you put a Lambda inside a VPC behind a NAT Gateway, or spin up RDS, you have left the free zone. Architect to stay serverless and you stay cheap.

How I’d Actually Pick (Opinionated)

After building and writing about these services for years, here is the honest version: you do not need to learn all of them, and trying to is the fastest way to stall. Most production .NET applications run happily on a small, boring core.

If I were starting today, this is the stack I would learn first and reach for by default:

• Compute: Start with AWS Lambda (on the .NET 10 runtime) for event-driven work and APIs with spiky traffic. When you need long-running processes, WebSockets, or more control, move to ECS Fargate - and if you want Fargate with far less setup, ECS Express Mode is the simplest managed path in 2026. Reach for EC2 last; it is the most flexible and the most work. Skip App Runner - it is closed to new customers now.
• Storage: S3 for anything file-shaped. You will use it on almost every project.
• Database: RDS with EF Core if your data is relational (it usually is). DynamoDB only when you genuinely need key-value scale and predictable latency - not because NoSQL sounds modern.
• Messaging: SQS to decouple, SNS to fan out. Add EventBridge when you are routing many event types.
• Security: IAM is not optional - learn roles and least privilege early. Add Cognito when you need real user auth.
• Observability: CloudWatch from day one. You cannot fix what you cannot see.

The most common mistake I see is over-engineering: reaching for Step Functions, EventBridge buses, and DynamoDB single-table designs on a project that one RDS database and a couple of Lambdas would serve fine. Start simple. Add services when a real constraint forces you to, not because a diagram looked impressive. The one thing worth front-loading is IAM and credentials - getting access control right early is far cheaper than retrofitting it after a leak.

That is the stack the free AWS for .NET Developers course builds, in the order you would actually adopt it - not alphabetically.

Key Takeaways

• You do not need all of AWS. A focused core - Lambda or ECS Fargate, S3, RDS or DynamoDB, SQS, IAM, and CloudWatch - covers the majority of production .NET workloads.
• AWS Lambda now supports the .NET 10 managed runtime (since January 2026), as both a managed runtime and a container base image, supported through November 2028. Use it for new serverless .NET functions.
• Use AWS SDK for .NET v4. Version 3 reached end-of-support on June 1, 2026.
• Skip App Runner for new projects - it closed to new customers in April 2026. Use ECS Express Mode or Fargate instead.
• IAM is the one to master early. Roles and least privilege underpin every other service and are painful to bolt on later.
• Watch the NAT Gateway and always-on RDS - they are the bills that surprise people; Lambda, S3, and DynamoDB scale to zero.

Frequently Asked Questions

Closing Thoughts

AWS can feel overwhelming because of how many services it offers, but as a .NET developer you only need a focused core to build scalable, secure, cost-efficient systems. The developers who get the most out of AWS are the ones who can reason about tradeoffs - when to use Lambda over Fargate, RDS over DynamoDB, SQS over SNS - rather than recite service names. That same skill is exactly what employers probe in interviews, where AWS architecture questions come up constantly.

If you want the structured, hands-on path through all of this, my free AWS for .NET Developers course walks through these services end to end with real .NET code.

I hope this guide helps you get started with the essential AWS services. If you found it useful, feel free to share it with your colleagues.

Happy Coding :)