Deploying to the cloud

Hosting options for .NET apps — PaaS, containers and serverless — plus managed databases, configuration and secrets in the cloud.

Where should the app run?

Cloud providers (Azure, AWS, Google Cloud) offer several levels of abstraction. The higher you go, the less you operate yourself:

Model	You manage	Provider manages	Examples
IaaS (virtual machines)	OS, runtime, patches, app, scaling	Hardware, network	Azure VMs, AWS EC2
PaaS (app hosting)	Your app and its settings	OS, runtime, patching, load balancing, scaling	Azure App Service, AWS Elastic Beanstalk
Containers (managed)	Your container image	Orchestration, scaling, networking	Azure Container Apps, AWS ECS/Fargate, Google Cloud Run
Kubernetes	Cluster configuration and workloads	Control plane	AKS, EKS, GKE
Serverless functions	Individual functions	Everything else; scale to zero	Azure Functions, AWS Lambda

For a typical ASP.NET Core API, PaaS or managed containers is the sweet spot: little operational work, autoscaling, built-in TLS certificates and deployment slots.

Azure App Service

dotnet publish -c Release -o ./publish
az webapp up --name shop-api --runtime "DOTNETCORE:8.0" --sku B1

Then configure in the portal or CLI:

App settings become environment variables — ConnectionStrings__Shop, Payment__TimeoutSeconds.
Deployment slots (staging/production) let you deploy to staging, warm it up, then swap with zero downtime.
Scale up (bigger plan) or scale out (more instances, autoscale rules).
Health check path (/health) so unhealthy instances are replaced.

Azure Container Apps

For containerized apps: push your image to a registry and Container Apps runs it with HTTPS ingress, autoscaling (including scale to zero, and scaling on queue length), revisions for blue/green deployments, and built-in Dapr support for microservices.

Managed services instead of running your own

Need	Managed service (Azure / AWS)
Relational database	Azure SQL, Azure Database for PostgreSQL / RDS, Aurora
Cache	Azure Cache for Redis / ElastiCache
Files and images	Blob Storage / S3 (+ CDN in front)
Queues and events	Service Bus, Storage Queues / SQS, SNS
Secrets	Key Vault / Secrets Manager
Monitoring	Application Insights + Azure Monitor / CloudWatch

Managed services handle backups, patching, replication and failover — work you'd otherwise do yourself.

Secrets and identity in the cloud

Don't put secrets in app settings if you can avoid it. Give the app a managed identity and grant it access:

// The app authenticates as itself — no password in config
builder.Configuration.AddAzureKeyVault(
    new Uri("https://shop-vault.vault.azure.net/"), new DefaultAzureCredential());

DefaultAzureCredential uses your developer login locally and the managed identity in Azure. The same approach works for Azure SQL, Storage and Service Bus.

Infrastructure as code

Clicking resources together in a portal isn't repeatable. Describe them as code — Bicep or ARM (Azure), Terraform (any cloud), Pulumi (in C#!) — version it in git, and apply it from your pipeline. Creating an identical staging environment becomes one command.

Watch the bill

The cloud charges for what's provisioned, not just what's used:

Set budgets and alerts from day one.
Right-size instances; use autoscaling and scale-to-zero for dev/test.
Delete forgotten environments; tag resources by project and owner.
Egress (data leaving the cloud) and premium tiers add up — check pricing calculators.

Key takeaways

Choose the highest abstraction that fits: PaaS or managed containers for most web APIs, serverless for event-driven work.
App settings become environment variables; use deployment slots or revisions for zero-downtime releases.
Prefer managed databases, caches, storage and queues over self-hosting.
Use managed identities and Key Vault instead of stored secrets, infrastructure as code for repeatability, and budgets for cost control.

You will learn