Cloud
Architecture
Learning Path
Constraints, then authority — a seven-stage architecture decision model for cloud strategy.
>_ Cloud Is Not a Location Decision
Cloud architecture is not provider selection. It is distributed control plane design — the engineering of programmable fabrics that abstract compute, storage, networking, and identity at scale. The provider is an implementation detail. The architectural decisions that determine blast radius, cost topology, workload portability, and operational authority are made before the provider is chosen, and they outlast any contract.
This cloud architecture learning path is a maturity-guided reading sequence for senior enterprise infrastructure architects, structured around a single progression: the first three stages establish the constraints an architecture operates under — what it depends on, what controls its movement, and what determines its economics. The remaining four stages establish authority — what governs the architecture, how that authority is operationalized, who governs it strategically, and how it survives dependency failure. Each stage builds on the architectural decisions established before it.
What This Path Is Not
- Not certification prep — no exam objectives, no flashcard sequences
- Not vendor training — no preferred platforms, no product tutorials
- Not beginner tutorials — foundational mechanics are covered, not hand-held
- Not feature documentation — the focus is tradeoffs, failure domains, and operational consequence
>_ Estimated Reading Depth
| Path Depth | Approx Time | Coverage |
|---|---|---|
| Essential Sequence | 3–4 hours | CS1 + CS4 — dependency foundations and the control plane authority pivot |
| Constraints Sequence | ~7 hours | CS1–CS3 — dependency, movement, and economic architecture |
| Full Domain Path | 16–20 hours | All seven stages in sequence |
>_ Where to Enter This Path
Not every reader starts at CS1. Start at the stage that matches your current operational context.
| Audience | Recommended Entry | Reason |
|---|---|---|
| Engineers new to cloud architecture | CS1 — Dependency Architecture | What a workload depends on is the prerequisite for every constraint and authority question that follows |
| Architects managing migration or platform-change decisions | CS2 — Movement Architecture | Movement constraints determine whether a workload can change placement — and at what cost |
| Architects whose cost optimization initiatives keep failing to hold | CS3 — Economic Architecture | Cost signals read as architectural evidence reveal whether a workload remains economically free or has become constrained |
| Architects who can identify ownership but not authority | CS4 — Control Plane Architecture | The pivot stage — distinguishes who owns a system from what actually governs the decisions made within it |
| Platform and operations teams acting on an authority map | CS5 — Operational Architecture | How authority becomes action — runbooks, lifecycle ownership, and day-2 operating models |
| Architects working on sovereignty, identity, or compliance authority | CS6 — Strategic Governance | Who governs authority itself — policy ownership, trust boundaries, and legitimacy |
| Architects modeling dependency failure, repatriation, or exit | CS7 — Strategic Resilience | How authority and architecture survive when a dependency fails or a provider relationship ends |
>_ The Architecture Maturity Spine
This Domain Path uses seven stages organized into two halves. CS1–CS3 read the architecture’s constraints — what it depends on, what controls its movement, and what determines its economics. CS4–CS7 read the architecture’s authority — what governs it, how that authority is operationalized, who governs it strategically, and how it survives dependency failure.
| Stage | Name | Maturity Level | Architectural Question |
|---|---|---|---|
| CS1 | Dependency Architecture | Foundation | What are we dependent on? |
| CS2 | Movement Architecture | Operational | What controls our movement? |
| CS3 | Economic Architecture | Operational | What determines our economic structure? |
| CS4 | Control Plane Architecture | Strategic | What governs the architecture? |
| CS5 | Operational Architecture | Strategic | How is authority operationalized? |
| CS6 | Strategic Governance | Strategic | Who governs authority? |
| CS7 | Strategic Resilience | Resilient | How does authority survive failure? |
Constraints (CS1–CS3) establish what the architecture operates under. Authority (CS4–CS7) establishes what governs it, how that authority acts, who governs it strategically, and how it survives failure. CS1–CS4 are live. CS5–CS7 are in development.
>_ Cloud Architecture Reading Sequence
The sequence below follows the maturity spine. CS1–CS3 map the constraints an architecture operates under. CS4–CS7 map its authority — where it resides, how it acts, who governs it, and how it survives failure. Each stage page is the curriculum for that maturity level; the articles listed below are the current reading inventory for each stage.
Dependency Architecture
What are we dependent on? The foundation stage — provider control plane mechanics, shared responsibility boundaries, and the dependency and storage-coupling decisions every later stage assumes are already mapped.
Movement Architecture
What controls our movement? Cloud-native and distributed design patterns read here as movement-enabling structures — the architectural decisions that determine whether a workload can change placement, and at what cost, once CS1’s dependencies are mapped.
Economic Architecture
What determines our economic structure? Reads egress charges, idle capacity, reservation commitments, and exit premiums as architectural evidence — anchored by the Economic Gravity Boundary (Framework #131).
Control Plane Architecture
What governs the architecture? The pivot stage — from constraints to authority. Identifies the Control Plane Ownership Boundary (Framework #135): where responsibility for a system diverges from authority over its operation. The articles below include the stage’s own discovery clusters plus prior reading that surfaces authority concentration from a different angle.
Operational Architecture
How is authority operationalized? This is where authority becomes action — platform engineering, Kubernetes operations, service mesh, scaling, and delivery pipelines, read as the execution layer that acts on the authority map CS4 produces. Stage page in development; current reading inventory below.
Strategic Governance
Who governs authority? This is where authority becomes legitimacy — sovereignty, identity, trust boundaries, policy ownership, and security architecture as governance questions: who can authorize execution, who can override policy, who defines trust. Stage page in development; current reading inventory below.
Strategic Resilience
How does authority survive failure? This is where authority becomes survivability — repatriation, sovereign infrastructure, multi-cloud reality, and continuity architecture, read as the architecture’s response when a dependency fails or a provider relationship ends. Stage page in development; current reading inventory below.
>_ Common Cloud Architecture Failure Patterns
>_ Deterministic Infrastructure Tools
>_ Where Do You Go From Here
>_ Continue Your Architecture Reading Sequence
Five Domains. One Maturity Framework.
The Cloud Architecture Domain Path is one of five structured reading sequences across the Rack2Cloud platform. Each path follows the same maturity spine — applied to the operational realities of its domain.
>_ Frequently Asked Questions
Q: What is the Cloud Architecture Learning Path?
A: The Cloud Architecture Learning Path is a maturity-guided reading sequence for senior enterprise infrastructure architects, structured around seven stages in two halves. CS1–CS3 establish the constraints an architecture operates under: what it depends on, what controls its movement, and what determines its economics. CS4–CS7 establish authority: what governs the architecture, how that authority is operationalized, who governs it strategically, and how it survives dependency failure. It sequences published analysis from this site by architectural consequence and operational complexity — not by provider, certification objective, or feature category.
Q: How is this different from AWS, Azure, or GCP certification training?
A: Certification training sequences content around exam objectives and provider feature coverage. This path sequences content around the architectural decisions you face in production — dependency mapping, movement constraints, economic gravity, and control plane authority. The goal is architectural judgment that applies across providers, not credential familiarity with a single platform’s service catalog.
Q: Why does the path move from constraints to authority?
A: The first three stages establish what exists, what it costs to move, and what it costs to keep. Those are constraint questions — they describe the architecture’s operating envelope. CS4 onward asks a different question: given those constraints, what actually governs the decisions made within them? Authority questions are meaningless without a constraint model to apply them to — which is why CS4 (Control Plane Architecture) cannot be the starting point, but is the pivot once CS1–CS3 are understood.
Q: Where should I start if I already run cloud infrastructure at scale?
A: Start at CS2 (Movement Architecture) if migration or platform-change decisions are live. Start at CS3 (Economic Architecture) if cost optimization initiatives keep failing to hold. Start at CS4 (Control Plane Architecture) if you can identify who owns each system but not what governs the decisions made within it — this is the most common entry point for architects who already have CS1–CS3 covered informally. The entry point table in the Where to Enter This Path section maps each audience profile to its recommended stage.
Q: What is the Control Plane Ownership Boundary, and why is CS4 the pivot stage?
A: The Control Plane Ownership Boundary (Framework #135) is the point at which responsibility for a system diverges from authority over its operation — where the formal owner of a system can be identified, but the decisions that matter are made, or overridden, somewhere else. CS4 is the pivot because it is the first stage to ask an authority question rather than a constraint question. CS1–CS3 map what an architecture depends on, how it can move, and what it costs. CS4 asks what actually governs the decisions made within those constraints — the precondition for CS5 (operationalizing authority), CS6 (governing authority), and CS7 (authority surviving failure).
Q: Are CS5, CS6, and CS7 available yet?
A: CS1 through CS4 are live stage pages with dedicated reading sequences and named frameworks. CS5 (Operational Architecture), CS6 (Strategic Governance), and CS7 (Strategic Resilience) are in development — their stage URLs are live and their reading inventories are populated with currently published articles, but their dedicated stage pages with cluster structures and stage-anchor frameworks are still being built. The stage questions and maturity levels for CS5–CS7 are locked; only the dedicated curriculum pages remain to be published.
Q: How often is the reading sequence reviewed and updated?
A: The architecture sequence is reviewed when significant changes occur — major provider pricing structure changes, platform deprecations, new published analysis that changes the recommended reading order, new framework numbers being locked, or new stage pages publishing. The last review date is shown in the governance metadata block above the reading sequence. Articles remain in the sequence as long as the architectural principles they cover remain accurate.