Cloud landing zones
Review the shared dependency that can stop every workload
A central service simplifies some operations and concentrates others. Check its failure path before making it mandatory for the whole environment.
In this article
Identify what depends on it
For a proposed shared DNS, network or deployment service, list the workloads and operations that require it. Distinguish runtime dependence from deployment-only dependence.
A deployment service outage may prevent releases while applications continue serving users. A name-resolution outage may interrupt live requests immediately. These deserve different recovery priorities.
Include administrative recovery paths. A team should not need the failed shared service to reach the tools required to restore it unless a tested alternative exists.
Examine the failure scope
Determine whether a configuration error, capacity issue or identity failure can affect all consumers at once. Regional redundancy may not help if every instance receives the same incorrect configuration.
Review change rollout and rollback for the shared component. A global update needs evidence appropriate to its scope, even when the code change is small.
Look for isolation between workloads where it matters. One application's traffic or logging burst should not silently consume all available capacity for others.
Test the operating alternative
Decide what workloads do when the shared service is unavailable. Some can continue with cached or existing state. Others must pause or fail clearly.
Do not invent a fallback that bypasses a required access boundary. A recovery route needs the same deliberate authority model as normal operation.
Rehearse the alternative with the workload team, not only the platform team. The application may respond differently from the infrastructure component's own health check.
Confirm the centralisation benefit
Ask which concrete benefit justifies the shared dependency: consistent control, reduced duplication, specialist operation or measurable cost improvement.
If that benefit is unclear, a simpler workload-owned capability may be easier to support. Conversely, duplicating a complex security function across every team can create its own risk and effort.
Approve the shared service with a named owner, capacity model and tested recovery path. The review should explain why its scope is appropriate and how its failure is contained, rather than accepting centralisation as an automatic best practice.
Primary sources
Microsoft: Azure landing zonesReferences checked 11 September 2026.