Cloud Architecture Planning

01Purpose and scope

• This manual supports the course Cloud Architecture Planning. It is written as a working reference for people who decide how applications, data, and network services will be arranged in a cloud environment before anything is built. That includes solution architects, infrastructure leads, senior engineers, and project managers who sign off on designs.
• The scope covers the planning stage: gathering requirements, choosing where workloads run, defining account or subscription structure, designing networks and identity, setting security and cost boundaries, and documenting the decisions so builders can implement them. It does not cover detailed infrastructure code, day-to-day operations runbooks, or application development practices, although planning decisions affect all of those.
• The manual assumes you already understand basic cloud service models such as infrastructure, platform, and software as a service. It also assumes you work in an organization where someone else owns budget approval and where changes go through some form of review. Practices differ between a startup with one product and a regulated enterprise with dozens of teams, and this manual notes where those differences matter.

02Core principles

• Start from workload needs rather than from a preferred service catalog. A planning session that begins with a list of services tends to produce a design that fits the tools rather than the business. Ask what the workload does, how much it is used, how sensitive its data is, and how quickly it must recover before naming any product.
• Keep boundaries explicit. Every cloud design depends on where one account, subscription, project, or network ends and another begins. Boundaries control blast radius, billing visibility, and who can change what. Decide them early, because they are expensive to move later.
• Prefer managed services where the operating burden is the main risk, but record the trade-off. A managed database reduces patching work and increases dependence on the provider's availability model and feature limits. Make that dependence a conscious choice.
• Design for failure in the components you control and document the failures you accept. No cloud region is perfectly available, and no service has unlimited quotas. A good plan says which failures are tolerated, which are mitigated by redundancy, and which are accepted as residual risk with an owner.
• Treat identity as the primary control plane. Network rules matter, but in most cloud environments the most common path to compromise is an over-permissioned identity or a leaked credential. Plan roles, groups, and privileged access before finalizing network diagrams.

03Planning and preparation

• Begin by collecting requirements from the people who will own and use the system. Interview product owners for availability and growth expectations, data owners for classification and retention needs, security staff for control requirements, and finance for budget ceilings and approval thresholds. Write the answers down in a short requirements register with a named source for each item. Requirements gathered from memory or from a single meeting usually change within weeks.
• Inventory what exists. Most planning efforts involve a current state, even if it is only a handful of virtual machines in a data center or a set of spreadsheets describing applications. Record each workload's dependencies, data flows, integrations with outside parties, and current performance numbers. Where measurements are not available, mark them as estimates so they are revisited.
• Decide the planning horizon and the review cadence. A design for the next six months looks different from one meant to last three years. Agree on the horizon with stakeholders, because it determines how much flexibility to build into account structure and capacity assumptions.
• Assemble the right people. A useful planning group usually includes an architect who owns the design, a network engineer, a security representative, an identity administrator, a cost or finance partner, and at least one application owner. Keep the group small enough to make decisions. Larger reviews are useful for ratifying decisions, not for making them.
• Confirm the constraints before drawing anything. These include data residency rules, contractual commitments, allowed regions, required encryption standards, existing identity providers, connectivity to on-premises systems, and any preapproved vendor list. Constraints that surface late cause redesign, so list them in the first week. Where rules depend on jurisdiction or sector, identify the current authoritative source, such as the regulator's guidance or your legal team's written position, and do not rely on memory or on this manual.

04Recommended workflow

1. 1
   : Define the workload boundary. Write one paragraph per workload that states its purpose, owner, users, data classes, and business criticality. Group workloads that share a team, data set, or release cadence. The output is a list of candidate design units that will each map to an account, project, or network segment.
2. 2
   : Set availability and recovery targets. For each design unit, record a target availability level, a recovery time objective, and a recovery point objective. Mark any target that is aspirational rather than contractually required. These numbers drive region choices, redundancy patterns, and backup frequency, so they must be agreed before service selection.
3. 3
   : Choose placement and tenancy structure. Decide which regions, zones, or sovereign options each design unit may use. Define the account or subscription hierarchy, naming conventions, and the policy inheritance model. Document why a shared account is used for some units and an isolated account for others. Isolation usually costs more to administer, so the reason should be specific.
4. 4
   : Design the network. Specify address ranges with room for growth, segmentation between tiers, ingress and egress paths, private connectivity to on-premises networks, and name resolution. Record every path that crosses a trust boundary and name the control that governs it, such as a firewall, a gateway, or a private endpoint. Avoid designing address plans that overlap with existing corporate networks, because retrofitting them is slow.
5. 5
   : Define identity, access, and secrets handling. Map each role to the people or service identities that need it, using least privilege as the starting point. Decide how administrators elevate access, how service accounts are created and rotated, and where secrets are stored. Write these decisions into the design as explicit rules, not as a general statement about security.
6. 6
   : Estimate cost and set guardrails. Build a rough model using expected usage, reserved or committed discount options where they apply, data transfer between zones and regions, storage growth, and support charges. Assign budget alerts and spending limits to each account or project. Be clear that estimates are based on assumptions, and list the assumptions next to the figures.
7. 7
   : Record the design and its review conditions. Produce a design document that includes the diagrams, decision records, risks, open items, and owners. Add the conditions under which the design must be revisited, such as a new data class, a change in region availability, or a volume increase above an agreed threshold. Obtain formal sign-off from the people named in the roles section.

05Quality checks, risk controls and compliance

• Review the design against a written checklist before sign-off. Check that each workload has an owner, a data classification, availability and recovery targets, a defined boundary, and a cost guardrail. Confirm that every network path has a named control and that every privileged role has an approval path. A design that cannot answer these questions is not ready, however attractive the diagram looks.
• Run a threat-based review. Walk through how an attacker or an error could move through the design, focusing on identity misuse, exposed storage, misconfigured network rules, and dependency failures. Record each scenario, the existing control, and the residual risk. Assign an owner to every residual risk that is accepted, and set a date for reassessment. Do not describe a risk as mitigated unless the control is in the design and has an owner who can show it working.
• Check cost and capacity assumptions with someone who did not build the model. Common errors include forgetting data egress between regions, ignoring logging and monitoring charges, and assuming that a discounted commitment will be used fully. Compare the model with actual usage from a pilot or from a comparable existing workload if one exists.
• Address compliance explicitly. Cloud architecture touches data protection, records retention, export controls, and sector rules for finance, health, education, and government work. The rules differ by jurisdiction and change over time, so identify the current authoritative source for each applicable rule and record who confirmed compliance. This manual does not replace qualified legal, regulatory, or security professional judgment, and any design touching regulated data needs approval through your organization's required process.
• Plan for change control. Designs drift once teams start building. Decide who may approve a deviation, how deviations are recorded, and when a design is updated. A design that no longer matches the environment is a liability because future planning will rely on it.

06Collaboration and documentation

• Keep one authoritative design record. Scattered slides, chat threads, and diagrams with different versions cause more confusion than most technical errors. Store the design in a versioned repository or document system that the team uses daily, and link decision records to the diagrams they affect.
• Use decision records for choices that are costly to reverse. A short record should state the context, the options considered, the decision, the reasons, and the consequences. Examples include choosing a hub and spoke network over a flat design, selecting a single identity provider, or standardizing on one logging platform. Keep records brief. A two-page essay for every minor choice will not be read.
• Coordinate with application teams early. They know performance characteristics, release schedules, and integration constraints that the planning group may miss. Hold a short working session with each application owner to validate assumptions before the design is finalized.
• Agree on terminology. Words such as environment, tenant, subscription, account, project, and landing zone mean different things to different providers and organizations. Define each term in the design document so that reviewers read the same structure.
• Document operational handoffs. The planning group will not operate the system. Name the team that will run it, the support model, and the escalation path. Record which runbooks must exist before go-live.

07Measures and continuous improvement

• Measure the planning process as well as the resulting environment. Useful indicators include the percentage of workloads with complete owner, classification, and recovery fields; the number of open design exceptions and their average age; the count of accepted residual risks without reassessment dates; and the variance between forecast and actual monthly spend for the first two quarters after go-live. Use these as signals for discussion rather than as targets to hit, because a target can encourage teams to game the numbers.
• Review designs after each significant change. A new data class, a region outage, an acquisition, or a large increase in traffic should trigger a review of the affected design units. Keep the review short and focus on the conditions recorded in the design document.
• Collect lessons from incidents and from cost reviews. When an outage or an unexpected bill occurs, trace the cause back to the planning artifacts. Was a dependency missing from the inventory? Was a guardrail absent? Update the planning checklist so the same gap is less likely to recur.
• Refresh reference patterns periodically. Organizations often build a small library of approved network and account patterns. Retire patterns that no longer match provider capabilities or internal standards, and mark the reasons in the change log.

08Common mistakes and how to prevent them

• Designing before requirements are settled. Teams often begin drawing diagrams during the first meeting. Prevent this by requiring the requirements register and constraint list to be reviewed before any service selection is discussed.
• Overusing a single account or subscription. Putting every workload in one place simplifies early setup but makes access control, billing, and incident containment difficult later. Define boundaries using the workload boundary step, and record any deliberate sharing.
• Ignoring data movement costs and latency. Architects sometimes place a database in one region and its consumers in another without modeling traffic. Prevent this by listing every data flow in the inventory and estimating volume and frequency for the largest ones.
• Writing identity rules as general intent. Statements such as use least privilege give no guidance to the team building roles. Prevent this by naming specific roles, their permitted actions, and the approval path for changes.
• Treating compliance as a final checkbox. Late discovery of a data residency problem can force a redesign. Bring the compliance owner into the constraint review at the start.
• Accepting residual risks without owners or dates. Unowned risks tend to become permanent. Require a name and a reassessment date for each accepted risk.
• Assuming the design is finished at sign-off. Environments change. Schedule reviews and keep the design record current.

09Practical checklist

• Confirm the course purpose, stakeholders, and decision rights for the design before starting.
• Record requirements and constraints in a register with a named source for each item.
• Define workload boundaries, owners, data classes, and recovery targets for every design unit.
• Document the account or subscription hierarchy, naming conventions, and policy inheritance.
• Specify network address plans, segmentation, ingress and egress paths, and the controls on each trust boundary.
• Map roles to identities with least privilege, and record how secrets are stored and rotated.
• Build a cost model with stated assumptions, and set budget alerts and spending limits for each account.
• Review the design with someone outside the planning group, and log every accepted residual risk with an owner and reassessment date.
• Confirm applicable compliance requirements with the current authoritative source and the responsible internal function.
• Publish the design record, decision records, and handoff plan, and set the conditions for the next review.

★Learning sources

• Micro Degree: Cloud Architecture Planning
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics