Architecture Reference

Appearance

Cloud Infrastructure and IaC ​

Cloud Infrastructure and IaC Graphics Coverage ​

Primary chapter graphic: Cloud Application Stack Layers, Cloud Computing Learning Map, AWS Database Choice Map, AWS Learning Map, Infrastructure as Code Landscape, Cloud Service Families, Object Storage Request Path, Cloud Provider Capability Map, Virtualization Layers, Cloud Data Pipeline Services, Common AWS Service Families. Accepted graphics: 11. Reviewed non-signal pages: 2. Open graphics in review: 0. QA status lives in graphics audit and visual review ledger.

Corpus pages: p. 20-21, p. 53-54, p. 85, p. 106-107, p. 109, p. 145-146, p. 153-154, p. 222, p. 382-385, p. 391-392, p. 415-416 Coverage: 21 pages; low-confidence extraction ranges: p. 20-21, p. 53, p. 382-385, p. 391-392

This chapter is part of Marius's owned architecture build corpus. The text routes decisions; durable implementation signal is carried by accepted graphics, reviewed non-signal decisions, and the linked QA audit.

Chapter Visuals ​

Accepted graphics carry the canonical design signal for this chapter. Each selected source page is either accepted as a graphic or explicitly marked non-signal in the source-faithful ledger. Review and QA state live in visual inventory, visual review ledger, and graphics audit.

Cloud Application Stack Layers ​

Cloud Application Stack Layers

Cloud Computing Learning Map ​

Cloud Computing Learning Map

AWS Database Choice Map ​

AWS Database Choice Map

AWS Learning Map ​

AWS Learning Map

Infrastructure as Code Landscape ​

Infrastructure as Code Landscape

Cloud Service Families ​

Cloud Service Families

Object Storage Request Path ​

Object Storage Request Path

Cloud Provider Capability Map ​

Cloud Provider Capability Map

Virtualization Layers ​

Virtualization Layers

Cloud Data Pipeline Services ​

Cloud Data Pipeline Services

Common AWS Service Families ​

Common AWS Service Families

Open Review Queue ​

  • none

Reviewed Non-Signal Pages ​

  • Cloud Infrastructure And IaC: Authentication + DNS Map: source p. 107; batch 05; status non-signal/reviewed; ledger reason in visual-review-ledger.json
  • Cloud Infrastructure And IaC: Container + Orchestration Map: source p. 21; batch 23; status non-signal/reviewed; ledger reason in visual-review-ledger.json

Use When ​

  • Infrastructure must be repeatable, reviewable, and recoverable across environments.

Avoid When ​

  • A one-off local analysis does not justify provisioned infrastructure.

Core Model ​

  • Infrastructure is product code for networking, compute, storage, identity, policy, and observability.
  • Prefer explicit ownership over accidental coupling. Every boundary should say who owns correctness, cost, data, recovery, and change.
  • Use corpus page pointers for inspection, and keep the chapter notes focused on reusable design decisions.

Implementation Guidance ​

  • Describe resources declaratively, keep environment differences explicit, and rehearse replacement of critical pieces.
  • Write the smallest useful design note: purpose, inputs, outputs, state, failure behavior, observability, and rollback.
  • Choose the first implementation that can be tested against the real workflow without hiding a known production risk.

Tradeoffs ​

  • Managed services lower operations work but add pricing, limits, and provider-specific behavior.
  • Centralization reduces duplicated work but can become a bottleneck when every team needs exceptions.
  • Specialized infrastructure helps at scale, but it must earn its operational cost.

Failure Modes ​

  • Manual console changes drift from source and only appear during incident recovery.
  • The diagram shows boxes but not ownership, retry behavior, data freshness, or user-visible failure.
  • The system has no proof path for the highest-risk assumption.

Decision Checklist ​

  • Version resource definitions, document secrets, tag ownership, and test destroy/recreate on non-production stacks.
  • Name the owner, source of truth, timeout, retry policy, and evidence that the path works.
  • Add one regression check for the failure mode most likely to recur.

Neutral Automation Examples ​

  • A file-processing workflow uses object storage, a queue, and a worker, all declared from one reviewed stack.
  • A neutral internal automation starts with fixtures, then adds credentials, permissions, and production scheduling only after the boundary is tested.
  • A customer-facing workflow keeps irreversible actions behind explicit approval until metrics show it is safe to automate further.