The Modern Cloud Architecture Playbook

Cloud architecture decisions made early can shape delivery, reliability, security, and cost for years. Evaluate them against workload and operating constraints.

trigger="A new workload, migration, or production constraint requires a cloud architecture decision." owner="The workload owner accountable for the user outcome, operating risk, and budget." participants={["Application lead", "Platform engineer", "Data owner", "Security reviewer", "SRE or operations owner", "Finance partner"]} prerequisites={[ "A user journey, demand profile, data classification, and inventory of external dependencies.", "Agreed availability, latency, recovery, and cost requirements with their measurement method.", "A named operating team and access to representative testing and billing evidence." ]} outputs={[ "A workload brief and architecture decision record with alternatives and unresolved assumptions.", "A tested production slice, dependency and ownership map, and cost model.", "A release or migration plan with acceptance gates, recovery evidence, and accountable approvals." ]} doneWhen={[ "The chosen architecture satisfies the workload's tested requirements within the agreed operating boundary.", "Identity, data, network, deployment, and recovery controls have named owners and evidence.", "The team can deploy, diagnose, restore, and contain the workload using tested procedures.", "Material risks and untested assumptions are accepted explicitly or block release." ]} />

Start with a workload brief

Cloud architecture decisions made early can shape delivery, reliability, security, and cost for years. A useful design record explains the constraints behind the choice and what evidence would cause the team to change it.

Begin with one user journey. Record what counts as a successful operation, when users need the result, and what happens when a dependency fails. Then describe expected demand, bursts, state growth, sensitive data, and the team's operating capacity.

This guide covers a workload-level design and migration sequence. Cloud cost optimization covers cost experiments, while multi-region versus multi-AZ covers availability topology and recovery. No average savings or delivery improvement is assumed here.

1. Agree requirements and decision authority

The workload owner separates contractual commitments, internal targets, and current measured behavior. A provider service SLA is not the application's availability measurement. Similarly, a desired recovery time becomes credible only after the complete recovery path is tested.

| Requirement | Record | Decision owner | | --- | --- | --- | | User outcome | Success, pending, rejection, and unacceptable failure states | Product and workload owners | | Performance | Workload shape, concurrency, payloads, latency distribution | Application lead | | Reliability | User SLI, target window, dependency assumptions | SRE and workload owners | | Recovery | Failure scenarios, recovery time and data-loss objectives | Data and operations owners | | Data handling | Classification, authorized locations, access, retention | Data and security owners | | Economics | Demand assumptions, allocation, budget, sensitivity | Workload owner and finance | | Delivery | Release frequency, support hours, available skills | Engineering lead |

Define priorities when requirements conflict. A global latency goal, strict consistency requirement, and constrained budget may need a product decision, not another infrastructure component.

Gate: the accountable owners agree what evidence is needed. Unresolved data location or access requirements block selection of a service that would violate them.

2. Inventory dependencies and failure domains

Map identity, DNS, certificates, network paths, compute, data stores, queues, secrets, deployment artifacts, and external APIs. For each, record who operates it, where it can fail, and whether recovery depends on a control-plane action.

Distinguish the paths used to serve traffic from those used to configure or recover the environment. A standby that needs an unavailable identity system, missing image, or unapproved quota increase cannot recover as planned.

Use the map to challenge hidden coupling. Two application replicas may share one database, one outbound route, or one credential. A second region may share a faulty deployment or compromised account. Redundancy only addresses the failure domains the design actually separates.

Build a simple dependency register before a detailed cloud-service diagram. Include required versions, regional availability, quota assumptions, and replacement or degradation behavior.

3. Select compute with a decision table and a test

Compare compute options against the same workload. Product names do not establish equivalent capabilities across providers.

| Workload constraint | Candidate to investigate | Evidence required before selection | | --- | --- | --- | | Existing software requires OS control or unusual agents | Virtual machines | Patch ownership, image rebuild, scaling, recovery, licensing | | Application packages cleanly as a container | Managed container runtime | Networking, resource limits, startup behavior, deployment and support model | | Event-triggered work fits documented execution limits | Function or serverless runtime | Duration, concurrency, state, startup, dependency limits, billing behavior | | Multiple workloads need shared orchestration controls | Kubernetes or another orchestrator | Platform capacity, upgrade process, isolation, scheduling, operational need | | Commodity capability has an acceptable managed offering | Managed service or SaaS | Data controls, service contract, integration, export, failure and exit plan |

Steady traffic does not automatically require virtual machines, and an experienced container team does not automatically need Kubernetes. Measure startup, sustained load, downstream pressure, and total cost for the candidate path.

The application lead defines a representative experiment: realistic request sizes, concurrency, state, and dependency limits. Include a cold start or restart, a failed dependency, and a deployment. Set the test load from the demand model and failure scenario instead of using a universal multiplier.

Gate: the selected compute path meets the requirements and the operating team can support it. Document why the alternatives were rejected.

4. Design state, integration, and recovery together

The data owner chooses stores from transaction boundaries, access patterns, durability, growth, backup, and restore requirements. A read replica may help read traffic but does not replace a recovery design. A cache needs an authority and invalidation policy.

For asynchronous work, define durable acceptance, operation identity, retries, expiry, and reconciliation. For synchronous calls, define timeout budgets and ambiguous outcomes. A service mesh can supply some traffic controls; it does not decide business idempotency or compensate a failed payment.

Specify backup scope and recovery artifacts. Include application configuration, secrets or their recovery mechanism, infrastructure definitions, keys, and external integration settings. Replication can propagate a bad write, so also consider recovery from corruption or unauthorized deletion.

AWS's disaster-recovery guidance distinguishes backup and restore, pilot light, warm standby, and active-active approaches. Use it to structure options, then test the chosen workload. Its architecture categories do not establish your recovery time.

5. Establish the security and operating foundation

The platform and security owners define environments, identity boundaries, least-privilege roles, secret handling, network exposure, audit evidence, and authorized emergency access. Shared platform controls need an exception process with an owner and expiry.

Manage repeatable infrastructure through reviewed, versioned definitions. If emergency changes occur through a console, capture the reason and reconcile the actual state back into the managed configuration. An undocumented emergency fix becomes a future recovery surprise.

Protect the deployment path as well as the running application. Verify artifact provenance, environment selection, approval rules, and the permissions used by automation. Keep production credentials out of local examples and test fixtures.

The operations owner prepares health signals, dependency dashboards, actionable alerts, and a runbook. Test access during the exercise: an excellent runbook is unusable if the on-call engineer cannot reach the required account.

6. Compare the whole operating cost

The finance partner and workload owner model compute, storage, requests, network transfer, observability, licenses, support, redundant capacity, and engineering operations. Identify which costs vary with successful user operations and which remain fixed.

For a migration, include parallel-running environments, data transfer, temporary adapters, test capacity, and retirement work. Do not compare the old steady-state bill with only the target's compute line.

Use a demand range and explain uncertainty. If a design depends on sustained utilization or a specific traffic pattern, test whether the economic case survives lower demand, a burst, or a failed replica.

Tag or otherwise allocate resources to workload and owner using mechanisms supported by each service. Reconcile the cost report with billing evidence. A tag policy alone does not guarantee complete allocation.

7. Choose a migration strategy per workload

AWS's current migration taxonomy uses seven Rs. Use the names consistently when referencing that framework:

| Strategy | Decision to make | | --- | --- | | Retire | Can the capability be removed after dependencies and retention duties are resolved? | | Retain | Should it stay in its current environment under an owned reassessment plan? | | Rehost | Can the application move with limited architectural change? | | Relocate | Does a supported platform-level move fit the current estate? | | Repurchase | Can a replacement product meet the functional, data, and exit requirements? | | Replatform | Which bounded changes improve the target without a broad redesign? | | Refactor or re-architect | Is deeper redesign justified by a defined outcome and migration capacity? |

No strategy is automatically the fastest, cheapest, or most valuable for every application. Vendor compatibility, data gravity, contractual terms, and coexistence determine the real work.

Assign migration waves around dependencies and business risk. Preserve data authority and reconciliation through each transition. The target accepting writes may change whether rollback is possible; a routing switch alone cannot repair incompatible state.

8. Prove a production slice before expanding

The first slice should exercise the intended operating path: identity, deployment, user operation, state change, telemetry, and recovery. It can be small, but it must test the assumptions driving the design.

"type": "flow", "title": "Carry evidence from architecture choice into release", "steps": [ ], "caption": "A failed gate returns the design to the relevant decision. A successful deployment alone does not close data, security, cost, or recovery risks." }} />

The AWS Well-Architected Framework provides a structured architecture review. Use relevant questions alongside the workload evidence; a checklist is not certification or proof of a business result.

9. Test failure and define rollback boundaries

| Exercise | Required evidence | Owner | | --- | --- | --- | | Instance, zone, or dependency loss | User impact and remaining capacity match the selected scenario | Operations owner | | Bad application release | Prior compatible artifact restores service, or repair-forward is defined | Application lead | | Data corruption or deletion | Approved restore reaches a verified recovery point | Data owner | | Lost access to a deployment dependency | Recovery artifacts and permissions remain usable | Platform owner | | Demand exceeds admission capacity | Work is rejected or deferred according to the product contract | Workload owner | | Cost rises outside the model | Attribution identifies the cause and approved containment | Finance and service owners |

Before a live change, record the last reversible checkpoint, operator, stop signals, traffic handling, and data reconciliation. If rollback could discard accepted work, stop and use the approved recovery decision rather than executing it automatically.

10. Hand the workload to an operating owner

Architecture acceptance is incomplete until a receiving operator can use the design under normal and degraded conditions. Give the operator the workload brief, dependency map, deployed versions, access path, service objectives, alerts, runbook, recovery assets, cost owner and current exceptions. Links should resolve for the receiving role, not only the architect.

Run a handoff exercise with one representative alert and one failed dependency. The operator should identify the affected user operation, determine whether the workload should continue, degrade or stop, find the accountable dependency owner, and execute or explain the approved recovery step. Include a lost-credential or unavailable-delivery-system condition so emergency access is tested rather than assumed.

Verify that automation permissions are narrower than the cloud account. The NIST Secure Software Development Framework includes practices for protecting software and producing well-secured releases. Apply the relevant practices to source, build, artifact and deployment boundaries without presenting the framework as a certification of this workload.

The handoff record should name support hours, escalation, provider contact, change authority, backup owner, key recovery owner and the person who accepts residual risk. If continuous support is required, confirm that staffing and access exist across that period. A document cannot create operational coverage.

Before closing the transition, remove temporary migration roles, test endpoints and duplicate resources or assign them explicit owners and expiry. Reconcile emergency or console changes into the managed configuration. Confirm that the cost and inventory systems identify the workload and its recovery resources.

11. Detect architectural drift through decision-linked evidence

Drift is not limited to infrastructure differing from code. It also includes unsupported component versions, new external dependencies, changed data locations, widened permissions, bypassed delivery paths, unowned resources and recovery procedures that no longer match the system.

Attach review triggers to the decision record. Useful triggers include a material traffic or data-shape change, new regulatory or contractual constraint, provider deprecation, repeated incident class, cost outside the modeled range, a new integration, failed restore exercise, or changed ownership. Each trigger should route to a named decision owner.

Use automated inventory and policy checks where they provide reliable evidence, but keep a human review for business meaning. A tool may detect an open network rule but not know whether a new partner flow is authorized. It may detect a version mismatch but not whether the upgrade changes a persisted format.

Sample the running workload periodically. Compare actual routes, identities, stores, queues, regions, artifacts and provider dependencies with the architecture record. Ask the service owner to explain differences. Update the record for accepted evolution; remediate or formally accept unauthorized divergence.

Track evidence freshness. A restore test from last year, a pricing quote from another region or a support statement for a different edition should not remain green indefinitely. Record source, configuration, date and recheck condition for material claims.

When drift invalidates recovery or security assumptions, contain the exposure before expanding features. The immediate response may be to restrict a route, pause deployment, preserve the last supported version or schedule a new recovery test. Do not redraw the diagram and call the gap resolved.

Close the architecture review with explicit conditions

The final review records the accepted workload scope, tested demand, supported versions, approved locations, operating owner, cost range, recovery evidence and unresolved limitations. Conditions such as a pending quota increase, provider support case or security exception need owners and dates.

Separate permission to run the bounded slice from authorization to migrate the full workload. Expansion may introduce different data volumes, user populations, dependencies or support requirements. Reuse evidence only where the assumptions remain valid.

If the design is rejected, retain the reason and the smallest next investigation. The decision may be to keep the current system, repair a single bottleneck, use a managed capability, or retire the workload. Cloud adoption is not the objective by itself.

At the next review, begin with the conditions and triggers rather than reconstructing the original debate. This makes the architecture a maintained operating decision instead of a static presentation.

Reusable architecture decision record

Keep the workload and owner; requirements and priorities; current dependency map; alternatives; selected services and versions; source documentation date; test inputs and outcomes; data and security decisions; cost assumptions; migration strategy; rollback boundary; residual risks; approvers; and reassessment triggers.

"The design traces to a measured workload and explicit business requirements.", "Compute choices have a textual rationale and representative test evidence.", "Every critical dependency has an owner and a failure or degradation path.", "Data restore, deployment rollback, and migration reconciliation are distinguished.", "Security controls cover runtime, automation, and emergency access.", "The cost model includes parallel running, redundancy, and operations.", "Unresolved risks are owned and accepted explicitly before release." ]} />

Limitations and reassessment

This guide does not prescribe a universal cloud stack or promise outcome improvements. Reassess the decision when demand, data obligations, provider capabilities, pricing, or operating ownership changes. Keep the failed experiments and rejected alternatives with the record so the next review starts from evidence.