Cloud target architecture and landing zones

Plain sentence first: choosing cloud is choosing where and how the enterprise's technology will run. The correct technical framing is that this belongs in Phase D, the technology architecture phase of the architecture method, because it is a decision about technology services, hosting, and infrastructure patterns. It is not a separate cloud strategy that overrides the business, information, and application work done earlier. It is a translation of that work into a running platform.

That framing matters because it changes the first question. The weak question is "which cloud provider should we pick?" The architecture question is "what platform characteristics does the enterprise need to support the application boundaries, data-authority model, and resilience posture already decided, and does a cloud target meet them better than the alternatives?" A cloud target architecture that cannot be traced back to those upstream decisions is a procurement preference with architecture language applied afterwards, the exact failure Phase D exists to prevent.

A cloud target architecture is therefore a normal Phase D output. It describes the target technology estate in the cloud: the account or subscription structure, the platform services workloads will use, the network and identity design, the resilience posture, and the integration foundations. It sits inside the Architecture Definition Document alongside the business, information, and application sections, and it feeds candidate components into the architecture roadmap. Nothing about it escapes the discipline that governs the rest of the technology architecture.

Plain sentence first: a landing zone is the ground you prepare once so that every workload can be built on it safely and consistently. The correct technical term is a landing zone, and the idea is standard across the major cloud providers: a pre-built, governed environment that establishes shared foundations before any application is deployed into it. The point is that a workload team should not have to design identity, network, security, and logging from scratch. Those are set once, by a central platform function, and inherited.

A useful way to hold the concept is the split between two kinds of zone. A platform landing zone is the shared foundation that a central team builds and runs once: identity, connectivity, and management services that every workload depends on. An application landing zone is the space a single workload is deployed into, one per application or environment, which inherits the platform baselines rather than re-inventing them. This is the layered structure the figure below shows.

The five baselines a platform landing zone should publish are worth naming explicitly, because they are the guardrails that turn cloud from nine private clouds into one governed estate.

• Subscription and resource organisation. A tenancy hierarchy that scopes every policy and every cost line, so a control or a budget can be applied to the right slice of the estate rather than account by account.
• Identity and access. One directory, least-privilege roles, and no long-lived static credentials, so who can do what is decided centrally and audited consistently.
• Network topology and connectivity. A segmented private network with controlled egress and no public exposure by default, so workloads are connected on purpose rather than by accident.
• Security baseline. Encryption, secrets management, threat detection, and a deny-by-default posture applied before any workload lands, not bolted on after an incident.
• Logging, monitoring, and governance. A central log sink, policy guardrails, and cost controls applied by default, so evidence exists from the first day and non-compliant configurations are prevented rather than discovered.

Return to the opening story with these five in mind. The breach was slow to trace because none of the five was shared: identity was set nine times, logging was optional, and there was no central place to look. A landing zone would have made the same five decisions once, and every account would have carried them.

Plain sentence first: in the cloud, some of the security work is done by the provider and some is done by the enterprise, and confusion about the boundary is where most cloud incidents begin. The correct technical term is the shared responsibility model. It divides duties between the cloud provider, who is responsible for the security of the cloud, and the customer, who is responsible for security in the cloud.

The practical reading for an architect is that the landing zone baselines from Section 68.2 are precisely the customer's side of this boundary. The provider secures the data centres and the platform; the enterprise still owns identity, network configuration, the security baseline, and its data. A landing zone is the enterprise doing its half of the model once, well, and by default, rather than leaving each workload team to rediscover the boundary alone.

Plain sentence first: a good cloud design has to balance several qualities that pull against each other, and pretending they do not is how expensive mistakes get made. The major providers publish a well-architected framework: a set of named quality areas, called pillars, that a workload should be assessed against. They are not a checklist to maximise all at once. They are a set of concerns to balance deliberately.

The trade-offs are the part that turns this from a poster into a design tool. A few worked tensions make the point.

• Reliability against cost.Running a workload across two regions survives a regional outage, but it roughly doubles the standing cost. The question is not "do we want reliability?" but "does this workload's business impact justify multi-region spend, or is a single-region design with a tested recovery path the right fit?"
• Security against operational simplicity. A strict deny-by-default network and short-lived credentials reduce the attack surface, but they add friction to delivery. The design has to decide where the friction is worth it and where it merely slows teams without reducing real risk.
• Performance against cost. Over-provisioning compute keeps response times low under any load, but it pays for capacity that mostly sits idle. Right-sizing and autoscaling trade a little peak headroom for a much lower bill.

A cloud target architecture should state, for each significant workload, which pillar it favours and what it trades away to do so. That statement is what lets the Architecture Board govern the design: it can challenge a trade-off it can see, and it cannot challenge one that was never made explicit.

Plain sentence first: in the cloud, cost is a design and operating decision made continuously by many teams, not a fixed number set once by procurement. On-premises, capacity was a large purchase made in advance. In the cloud, spend follows usage, which means an engineering choice made on a Tuesday afternoon can change the monthly bill. Something has to make that spend visible and accountable, and that discipline has a name.

A workable FinOps posture rests on a few habits that a landing zone makes possible. Because the tenancy hierarchy from Section 68.2 scopes cost lines, spend can be attributed to the team, product, or environment that caused it, rather than arriving as one unallocated bill.

• Visibility. Every resource is tagged and every cost is attributed, so teams can see the price of their own choices in near real time rather than at month end.
• Optimisation. Right-sizing, autoscaling, removing idle resources, and using committed-use discounts for steady baseline load turn the same workload into a smaller bill without changing what it does.
• Accountability. Budgets and alerts sit against the scopes in the hierarchy, and a forecast that will breach a budget triggers a conversation before the spend happens, not a surprise after it.

Notice how this closes the loop with the well-architected trade-offs. Cost Optimization is one of the pillars, and FinOps is the operating practice that keeps it honest over time. A cloud target architecture that names its trade-offs but has no FinOps posture will drift: the cost pillar that was balanced on paper quietly loses every argument to delivery pressure once the estate is live.

For a leader who will never configure a network, the landing zone is worth understanding as a governance instrument rather than a technical artefact. It is the point at which an enterprise decides its cloud controls once, deliberately, and makes them the default that every team inherits. The alternative, seen in the opening story, is that the same controls get decided many times, inconsistently, by teams under delivery pressure who were never asked to own them.

The strategic value is the same as the value of any good default. A default that is safe, consistent, and inherited turns governance from a series of late reviews into a property of the platform. Security, compliance evidence, and cost attribution stop being things the enterprise chases after the fact and become things the ground was already prepared to provide. For a regulated enterprise, that shift is the difference between being able to answer a regulator quickly and having to reconstruct the answer account by account.

The FinOps posture carries a parallel leadership message. Cloud spend that is attributed and forecast is a spend the enterprise can steer. Cloud spend that arrives as one unallocated bill is a spend the enterprise can only react to. The choice between those two is made in the landing-zone design, long before the first large invoice, which is exactly why it is an architecture decision and not merely a finance one.

London Grid Distribution serves 2.3 million customers across Greater London with around 4,000 staff, 36,000 km of cable, and 77 primary substations, all under Ofgem regulation and the RIIO-ED2 price control. Its asset-data platform holds the record of what equipment exists on the network, where it is, and its condition. The analytics team wants to move that platform to public cloud so it can scale and combine data more easily. The point of this section is to make that a traceable Phase D decision rather than a lift-and-hope.

The upstream decisions the cloud target must honour

The information-authority model already says the asset-data platform is an analytical and planning system, not an operational control system. The resilience principle already says operational technology must recover independently of enterprise IT. Both point the same way: the asset-data platform can move to cloud precisely because it is not on the operational control path. This is the traceability test from Phase D applied directly. The cloud choice is defensible because it supports decisions taken earlier, not because cloud is fashionable.

What the landing zone establishes before the platform lands

• Organisation. A subscription for the asset-data platform under a management scope that keeps its policy and cost separate from any operational workload, reinforcing the OT and IT separation at the tenancy level.
• Identity. Access through the enterprise directory with least-privilege roles, so an analyst can read asset data without holding credentials that reach anywhere near operational systems.
• Network. A private, segmented network with controlled egress and no public exposure, connected to the enterprise for data ingestion but never to the operational control network.
• Security.Encryption of asset data at rest and in transit, secrets managed centrally, and threat detection on by default, so the regulator's expectations are met from day one rather than retrofitted.
• Logging and governance. A central log sink and policy guardrails, giving the auditable evidence trail that a regulated DNO needs to show how published and analytical data has been handled.

The trade-offs stated openly

The asset-data platform is important but not life-critical: an hour of unavailability is an inconvenience for planners, not a network safety event. So the cloud target favours cost and operability over maximum reliability. It uses a single region with a tested recovery path rather than always-on multi-region, and it right-sizes compute with autoscaling. Those choices are written into the target architecture as explicit trade-offs the Architecture Board can see and challenge, not buried as defaults.

The FinOps posture from the start

Because the platform sits in its own scoped subscription, its cost is attributed to the analytics function from the first day. Resources are tagged, a budget with alerts sits against the subscription, and committed-use discounts cover the steady baseline load while autoscaling handles peaks. When the analytics team wants to add a large new dataset, the cost of doing so is visible before the work starts. Under RIIO-ED2, where the DNO must justify its spend to the regulator, that attributable, forecastable cost is not a nicety. It is evidence.