Skip to content

Cloud Computing

Cloud computing provides on-demand access to pooled computing capabilities through service APIs with measured usage. The durable engineering skill is choosing responsibility boundaries and designing for failure, security, operability, and cost—not memorizing provider product names.

NIST SP 800-145 remains a useful baseline definition: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.

Service Models

Model You mainly manage Provider mainly manages
IaaS Guest OS, runtime, application, data Facilities, hardware, virtualization
Managed container/platform Application, configuration, data Runtime platform and underlying hosts
Managed function Function code, triggers, data, limits Runtime lifecycle and scaling machinery
SaaS Users, configuration, data use, integrations Application and underlying stack

Responsibility is never fully outsourced. Customers still own identity, data classification, configuration, access, monitoring, recovery expectations, and safe use. Confirm the exact contract and service features rather than inferring them from the model name.

Choose the Highest Useful Abstraction

Managed services reduce undifferentiated operations but add service limits, pricing dimensions, API behavior, regional availability, and migration cost. Prefer the highest abstraction that meets control, portability, performance, compliance, and team-skill needs.

Do not build a portability layer for hypothetical multi-cloud. Preserve portable data, standard protocols, and recoverable architecture at expensive boundaries; accept provider-specific value where it materially reduces work.

Accounts, Projects, and Landing Zones

Create administrative boundaries around environments, data sensitivity, ownership, and blast radius. Establish centrally:

  • identity federation and emergency access;
  • audit logging and security monitoring;
  • approved regions and services;
  • network and DNS foundations;
  • encryption and key ownership;
  • resource ownership and cost metadata;
  • policy guardrails and exception paths;
  • backup and incident contacts.

Separate production authority from development convenience. Root or tenant-owner credentials should be rare, protected, monitored, and tested through a controlled recovery process.

Identity First

  • federate people through the organization's identity provider;
  • use workload identity and short-lived credentials for services and pipelines;
  • grant actions on the narrowest resources and conditions;
  • separate deployment, runtime, security, and billing roles;
  • review unused access and privilege escalation paths;
  • audit both successful and denied sensitive actions.

Network location does not establish identity. A private subnet can still contain compromised workloads.

Networking

Cloud networks define address space, routes, name resolution, traffic policy, and connectivity to the internet, other networks, and managed services.

Plan non-overlapping address ranges before connecting networks. Keep public exposure explicit, minimize inbound paths, control egress where the threat model requires it, and centralize DNS ownership without making one hidden team a delivery bottleneck.

Security groups, firewalls, private endpoints, and segmentation limit reachability; applications still need authentication, authorization, encryption, and input validation.

Compute

Choose among virtual machines, containers, managed platforms, and functions by workload shape:

  • execution duration and startup tolerance;
  • scaling pattern and concurrency;
  • operating-system and network control;
  • state and local storage needs;
  • hardware requirements;
  • observability and debugging;
  • unit economics at expected and peak demand.

Elasticity is not instant and cannot repair a saturated database or hot partition. Test scale-up delay, quotas, and downstream capacity.

Storage and Data

  • object storage fits durable objects accessed by key and lifecycle policy;
  • block storage presents volumes to compute and often has zone or attachment constraints;
  • file storage provides shared filesystem semantics;
  • managed databases provide data models plus varying backup, replication, and failover behavior.

Durability claims do not replace backup. Define deletion protection, versioning, immutability, retention, replication scope, recovery-point objective, recovery-time objective, and tested restoration. Understand who controls encryption keys and what happens if key access is lost.

Regions and Failure Domains

Zones and regions are provider-defined failure domains, not guarantees that every dependency is independent. Map the actual critical path: identity, DNS, control plane, network, compute, storage, keys, queues, observability, and third-party services.

Multi-zone is usually simpler than multi-region. Add regions only for a concrete availability, latency, sovereignty, or recovery requirement. Define traffic steering, data consistency, failover authority, capacity, and return-to-normal before claiming regional resilience.

Security and Data Governance

Classify data and enforce where it may be stored, processed, logged, replicated, and backed up. Use managed encryption with clear key policies, central audit trails, vulnerability management, configuration detection, and incident response integrated with provider APIs.

Public access should be intentional and continuously checked. Metadata services, instance roles, control-plane APIs, snapshots, CI identities, and support channels are part of the attack surface.

Infrastructure and Delivery

Manage resources through reviewed Infrastructure as Code. Build one immutable artifact, inject environment configuration, deploy progressively, and verify user outcomes. Use policy to prevent known-dangerous states without creating an unowned wall of noisy controls.

Provider outages and API rate limits affect deployments too. Keep enough cached artifacts, state, documentation, and emergency access to recover when the normal control path is impaired.

Cost

Cloud cost is an architectural signal. Measure by service, environment, owner, and unit of value such as request, tenant, or processed record.

Control:

  • idle and oversized resources;
  • storage lifecycle and old snapshots;
  • cross-zone, cross-region, and internet data transfer;
  • high-cardinality telemetry and log retention;
  • minimum provisioned capacity and scaling lag;
  • commitment discounts versus demand uncertainty;
  • abandoned experiments and duplicate environments.

The cheapest resource is one that does not need to exist. Cost optimization must preserve required reliability, security, and recovery margins.

Exit and Recovery

For critical services, know how to export data in a documented format, recreate infrastructure, rotate away from provider identities, replace dependent APIs, and operate during account or region impairment. Test the parts needed for the actual risk; a theoretical full-provider migration plan usually rots.

Checklist

  • Is the managed-service boundary understood precisely?
  • Are accounts, identities, regions, and ownership explicit?
  • Are credentials short-lived and least-privileged?
  • Are public exposure and data residency intentional?
  • Are quotas, scale-up delay, and downstream limits tested?
  • Are backup and restoration independent of replication?
  • Are failure domains mapped across the complete critical path?
  • Is cost visible per owner and unit of value?
  • Can critical data and control be recovered if the normal provider path fails?

Cloud architecture is good when it uses managed capabilities without surrendering understanding or recovery.