CLOUD ARCHITECTURE STRATEGY

Cloud is not a destination. It is a control plane — and like every control plane, it fails when the architecture beneath it is misunderstood.

For a decade, the default enterprise cloud strategy was “lift and shift”: move workloads wholesale, assume the provider handles resilience, and figure out the bill later. The bill arrived. The post-mortems followed. The lesson was consistent: cloud cost is an architecture problem, not a finance problem. Egress charges, zombie resources, over-provisioned reservations, and misaligned workload placement are not billing anomalies — they are architectural decisions that weren’t made.

This pillar covers cloud architecture from first principles. Not provider feature lists. Not vendor migration playbooks. The physics of how cloud behaves — economically, topologically, and operationally — and the decision frameworks that let architects place workloads with precision rather than optimism.

The four domains covered here — AWS, Azure, GCP, and Cloud Native — are not interchangeable. Each has a distinct compute model, a distinct data gravity profile, and a distinct cost envelope. Getting cloud right means understanding those differences before you commit capacity, not after you read the invoice.

The Physics of Cloud Infrastructure

Cloud cost is metered physics, not subscription pricing.

Every resource unit you consume — compute cycle, storage byte, network packet — has an economic weight attached to it. The providers abstract this into hourly rates and GB/month figures, but the underlying reality is simpler and more dangerous: cloud charges you for every decision you don’t make explicitly.

Elasticity has a floor. Cloud compute scales down, but not to zero unless you architect for it. A VM left running at 3% utilisation costs the same as one running at 90%. Reserved instances reduce unit cost but create a new liability: underutilised commitment. The discipline of cloud cost management is not FinOps tooling — it is rightsize-by-design, enforced at the architecture layer before provisioning begins.

Egress is the hidden gravity well. Moving data into a cloud provider is free or near-free. Moving data out — to another region, another provider, or back on-premises — is charged at rates that compound rapidly at enterprise data volumes. A 500TB dataset doesn’t just cost money to move — it costs time, and every hour that transfer runs is another hour of metered egress exposure. The Physics of Data Egress post covers the exact mechanics of how egress burns budget and what architectural guardrails prevent it.

Identity is the real control plane. Firewalls are not the perimeter in cloud environments — IAM is. Every resource, every API call, every cross-service interaction is governed by an identity policy. When that policy is fragmented across providers or misconfigured, you don’t have a hybrid cloud — you have multiple silos with a shared blast radius. The Multi-Cloud Cascading Failure series documents exactly how identity dependency creates outage amplification across providers.

Cost explosion has a taxonomy. The most common causes of runaway cloud spend are well-documented: over-provisioned compute reservations, data egress from unplanned replication, zombie load balancers accumulating across forgotten deployments, and snapshot policies with no expiry logic. The \$7,200 Zombie Load Balancers post dissects a real failure taxonomy. The Your Cloud Bill Quietly Increased in 2026 analysis maps the current cost drivers across providers.

The shim tax is real. Hybrid cloud creates integration seams — identity federation, network bridges, data synchronisation pipelines — each of which carries an operational overhead that doesn’t appear on a provider invoice. The Shim Tax covers the hidden engineering cost of operating across boundaries. Every integration point you add is a failure domain you must now maintain.

The Cloud Architecture Stack

Cloud is not a single platform. It is a layered architecture — and most comparisons evaluate only one layer.

Most cloud outages and cost explosions occur at layer boundaries — identity ↔ network, compute ↔ data, or control plane ↔ provisioning automation. The provider manages each layer’s underlying infrastructure. The architecture of how your layers interact is yours to own. A misconfigured identity boundary doesn’t trigger a provider SLA violation — it triggers your incident response.

Understanding which layer a failure originated in is what separates cloud architects from cloud operators.

Cloud Failure Modes

Cloud doesn’t fail the way on-premises infrastructure fails. The failure modes are architectural — and most of them are preventable.

These failure modes are not theoretical. The Multi-Cloud Cascading Failure series documents the operational chain that connects each one. The pattern is consistent: the architecture worked correctly until a boundary condition the design hadn’t modelled was reached.

Cloud Operating Models

Architecture doesn’t fail in isolation. It fails because the operating model couldn’t sustain it.

The decision about how your teams own cloud infrastructure is as consequential as the decision about where workloads run. Most cloud cost and outage post-mortems trace back to an operating model mismatch — architecture designed for centralized governance being operated by federated teams, or federated product ownership without the cost accountability to match.

Most organizations operate a hybrid of these models — centralized networking and identity with federated compute ownership, or platform engineering with FinOps attribution layered on top. The failure condition is not which model you choose; it is when the architecture assumes a level of governance discipline the operating model cannot deliver.

The Four Cloud Domains

No two cloud providers are architecturally equivalent.

The 2020 assumption — that workloads could be arbitraged across providers with minimal friction — broke against data gravity and platform specificity. In 2026, multi-cloud means best-of-breed silos, not workload mobility. You are not moving VMs between AWS and Azure. You are managing three radically different IAM models, three different networking topologies, and three different cost envelopes simultaneously.

Each domain below has a distinct architectural profile. Sub-pillar pages cover the depth. The decision framework in Section 5 maps workload types to placement logic.

Which Workloads Belong in the Cloud

Not every workload is a cloud workload. This is still an uncomfortable truth in 2026.

The repatriation wave is real. Teams that migrated everything to public cloud between 2018 and 2022 are now selectively moving high-volume, steady-state workloads back on-premises — not because cloud failed, but because the economic model only works for specific workload profiles. Repatriation is not a retreat. It is a correction.

The workload fit model below is not a feature comparison. It is an economic and operational decision framework based on three variables: utilisation pattern, data gravity, and latency sensitivity.

The data gravity argument is critical and underweighted in most cloud migration discussions. When compute moves to cloud but the source-of-truth datasets remain on-premises, you have not escaped data gravity — you have added a latency and egress bill to it. The Law of Data Gravity covers this in full.

The Hybrid vs Multi-Cloud in 2025 analysis maps what hybrid and multi-cloud actually look like operationally — not the marketing diagram, but the IAM fragmentation, the network bridging complexity, and the governance overhead that accompany real hybrid deployments.

For the repatriation decision specifically — which workloads should never leave, which should come back, and how to model the economic break-even — two dedicated posts cover the full framework: Workloads That Should Never Leave The Cloud and Cloud Repatriation: When to Move Workloads On-Prem.

Decision Framework

Platform placement decisions should follow workload physics, not provider relationships.

The table below maps workload profile to recommended platform. It is not exhaustive — edge cases and sovereign requirements will override these defaults — but it reflects the dominant placement logic for enterprise cloud architecture decisions.

The AWS Control Tower vs Azure Landing Zone deep dive maps governance architecture differences for teams operating across both providers. For multi-cloud networking dependencies and the vendor lock-in that happens through connectivity rather than APIs, see Vendor Lock-In Happens Through Networking.

Cloud Architecture Tools

Cost decisions need numbers, not estimates.

The tools below are built for the specific failure modes covered in this pillar: egress exposure, private endpoint misconfigurations, and serverless refactoring break-even. Each one produces a deterministic output from your actual architecture inputs.

Frequently Asked Questions

Additional Resources