Cloud fundamentals

#IaaS, PaaS, SaaS and FaaS: who owns what?

Cloud is more than a remote server: it is a choice about how much operation you own. Managed services reduce infrastructure work, but you still own data, permissions, application behavior and cost.

FaaS is managed, event-driven execution, not a guarantee that every request is cheap. Choose the least operational burden that meets the requirements. VMs help when OS control is essential but add ongoing work.

#Regions, availability zones and recovery

Two replicas on one machine do not protect against a datacenter failure. A region is a geographic service area; availability zones are fault-isolated locations within a region, with independent power, cooling and networking according to the provider's design. Zone availability and support depend on the service and SKU.

1. Define the SLO, RTO for acceptable recovery time, and RPO for acceptable data loss measured in time.
2. Distribute compute and data across zones where supported; selecting a region alone does not imply zone redundancy.
3. If a regional outage must be tolerated, plan cross-region routing, replication and failover.
4. Exercise recovery including DNS, secrets, permissions and backups, not only compute.

Multi-region designs add latency, cost and consistency complexity. Active-active is not universally necessary; tested backup recovery or warm standby may meet the objective more simply. Replication is not backup because accidental deletion can replicate too.

#Azure and AWS mapping: similar roles, different contracts

This map transfers concepts, not unchanged code or configuration. Review limits, pricing, delivery guarantees and identity models before choosing.

RDS offers multiple engines rather than cloning Azure SQL. Cosmos DB and DynamoDB have different models and consistency contracts. Entra ID provides user and workload identity; IAM focuses on AWS resource access, with IAM Identity Center supporting workforce federation and access. Application Insights belongs to Azure Monitor; CloudWatch is broader than APM, and tracing may require additional services or integrations. See the official comparison guide.

#Managed identity instead of copied keys

A copied connection key must be stored and rotated; a leak grants access until revocation. Azure managed identity gives an application an identity for short-lived tokens to services supporting Entra authentication. AWS workloads use IAM roles and temporary credentials. This example requires Azure.Identity, Azure.Storage.Blobs, an existing blob and Storage Blob Data Reader permission at an appropriate scope.

using Azure.Identity;
using Azure.Storage.Blobs;

var account = Environment.GetEnvironmentVariable("STORAGE_ACCOUNT")
    ?? throw new InvalidOperationException("STORAGE_ACCOUNT is required");
var credential = new DefaultAzureCredential(); // (1)
var service = new BlobServiceClient(
    new Uri($"https://{account}.blob.core.windows.net"), credential); // (2)
var blob = service.GetBlobContainerClient("invoices").GetBlobClient("invoice.txt");
await blob.DownloadToAsync("invoice.txt"); // (3)

Identity does not automatically grant permissions or bypass firewalls. Separate workload identities and apply least privilege. If a service cannot use workload identity, keep its key in Key Vault or Secrets Manager and rotate it. See Container Apps managed identity.

#Serverless: scale-to-zero still uses servers

Serverless transfers server management to the platform. Functions suit events such as invoice uploads and queue messages. A cold start initializes a new instance, including runtime, dependencies and application setup. Not every invocation is cold; startup time depends on the plan, runtime and application.

Make handlers idempotent because many triggers may redeliver. Minimize initialization and reuse connections, but keep important business state outside instance memory. For strict latency, evaluate minimum instances or provisioned capacity where offered, accepting reduced scale-to-zero savings. Long or sustained CPU workloads may fit container jobs or services better.

#Scaling without overwhelming downstream systems

Vertical scaling enlarges an instance; horizontal scaling adds instances. Vertical scaling has machine-size limits and may require restarts. Horizontal scaling needs requests to distribute safely; in-memory sessions, uploads and job state obstruct reliable scale-out.

1. Identify the bottleneck: CPU, database waits or queue backlog.
2. Choose a suitable signal: CPU for computation, queue age and backlog for workers, and latency as an outcome metric.
3. Set minimums, maximums and stabilization or cooldown rules to prevent oscillation.
4. Check aggregate connection pools and concurrency; twenty replicas can overwhelm one database.
5. On scale-in, stop accepting new work, drain and preserve retry safety.

Autoscaling reacts with delay: instance startup and metrics collection take time. Sudden bursts need headroom or queues and backpressure. Sticky sessions can be a temporary aid, but do not replace shared session design.

#Storage tiers, lifecycle and backup

Product images and PDFs need not live in relational rows. Object storage keeps blobs addressed by keys with metadata; block storage suits VM disks; file storage provides shared filesystem semantics. Choose by access pattern rather than size alone.

Azure and AWS offer different tiers and conditions; archival tiers do not all have identical offline behavior. Define lifecycle policies using supported age or access signals and review retention requirements, versioning and soft deletion. Replication helps with infrastructure failures; versioned backups and tested restores protect against logical deletion or corruption.

#VNets, VPCs and private endpoints

A cloud service is not automatically private. Azure VNets and AWS VPCs provide logical networks, with subnets dividing them. Routes determine paths, security groups or NSGs control allowed traffic, and DNS determines addresses; any of these can cause a timeout.

1. Define a clear application and data topology with intentional public entry points.
2. Use the service's appropriate private endpoint or private-access mechanism for private data paths.
3. Configure private DNS so the usual hostname resolves internally from the application network.
4. Disable public access where appropriate while preserving a known administration path.
5. Test identity and permissions separately from network access.

A private endpoint does not provide encryption or authorization; retain TLS and identity controls. Outbound NAT does not create a public inbound application route. Consider NAT charges, transfer costs and overlapping address ranges when connecting networks. Check resolution, route and port reachability before blaming credentials.

#Cost awareness and Infrastructure as Code

Cloud cost includes more than compute: databases, storage operations, egress, NAT, logs, backups and idle resources matter. Tag ownership and environments and configure budgets and alerts; an alert is not a guaranteed spending cap. Compare cost per successful order or request rather than one server bill.

IaC makes infrastructure reviewable and repeatable. Bicep targets Azure; Terraform uses declarative providers and state; Pulumi uses general-purpose languages and also maintains state. This complete Bicep example creates storage in an existing resource group and requires Azure CLI, login and deployment permission. Its derived name meets lowercase and length constraints.

param location string = resourceGroup().location

resource invoices 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'st${uniqueString(resourceGroup().id)}' // (1)
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false // (2)
    allowSharedKeyAccess: false
  }
}
output storageName string = invoices.name

Preview a plan or what-if before applying, protect state because it may contain secrets, and review drift and destructive changes. Avoid making permanent console-only production changes that never return to IaC. See the storage resource reference.

#The 12-factor app and ASP.NET Core deployment

Portability needs more than a container. The twelve factors cover one versioned codebase, explicit dependencies, external configuration, attached backing services, separate build/release/run stages, stateless processes, port binding, process-based concurrency, fast startup and graceful disposal, development/production parity, logs as event streams and separate administrative tasks. These are guidelines; sensitive configuration belongs in a secret store rather than Git.

For every path, run migrations separately, observe startup and requests, and exercise smoke tests and rollback. If the managed runtime does not suit .NET 10, consider an appropriate container or self-contained publish where supported; verify current platform support. Do not rely on local files for uploads or sessions. See .NET deployment on Elastic Beanstalk.