A cloud landing zone is more than a collection of accounts, subscriptions or compartments. It is the foundation that defines how cloud services are organised, secured, connected, governed and operated.
A good landing zone gives teams enough freedom to deliver services while maintaining consistent controls. A poor one either leaves too much open to individual interpretation or becomes so restrictive that teams work around it.
Start with the operating model
Before choosing technical controls, it helps to understand who will operate the platform. The right landing zone for a centralised infrastructure team may be very different from one used by several product teams or business units.
The design should define who owns identity, network services, security, logging, cost management and policy. It should also distinguish between responsibilities held by internal teams and those delegated to an MSP or other service provider.
Without that ownership model, technical controls can exist without anyone being clearly responsible for maintaining them.
Structure the cloud environment deliberately
Every major cloud platform provides ways to separate workloads and governance boundaries. OCI uses tenancies and compartments, AWS uses organisations and accounts, and Azure uses management groups, subscriptions and resource groups.
The structure should support security, operational separation, billing and lifecycle management. Production and non-production services often need clear boundaries, while shared services such as networking, logging and security may require dedicated areas.
The objective is not to create the maximum number of containers. It is to create a structure that makes access and ownership easier to understand.
Identity is the control plane
Identity design should be treated as part of the landing zone rather than something added afterwards.
Administrators should authenticate through controlled identities, privileged access should be limited and service-to-service access should use workload identities where supported. Shared accounts and long-lived credentials should be reduced wherever practical.
Federation, multi-factor authentication, role design, emergency access and joiner-mover-leaver processes should all be considered. The goal is to make the normal secure way of working the easiest way of working.
Network architecture needs room to grow
Cloud networks can become difficult to change once many workloads depend on them. Address ranges, segmentation, routing, DNS, internet access and connectivity to other environments should therefore be planned early.
The landing zone should define which networks are shared, which are workload-specific and how traffic is inspected or controlled. It should also identify the expected connectivity to on-premises environments, other cloud platforms and external services.
Network security should be based on required communication paths rather than broad allow rules. Clear standards for security groups, firewall policies and routing make later troubleshooting and review much easier.
DNC’s Cloud Architecture and Engineering services include landing-zone and network architecture across OCI, AWS, Azure and hybrid environments.
Logging should be central from day one
Central logging is one of the controls most often regretted when it is missing.
The landing zone should define which audit, platform and security logs are collected, where they are stored and how long they are retained. Access to logging data should also be controlled so that operational teams can investigate incidents without allowing unnecessary alteration or deletion.
Metrics and alarms should be designed alongside logs. The objective is not simply to collect telemetry, but to make it useful for operations and security.
Guardrails should prevent the most damaging mistakes
Cloud policy engines and security services can enforce or detect configuration standards. These guardrails should focus on controls that materially reduce risk.
Examples can include restricting public storage, requiring encryption, limiting approved regions, enforcing tags, protecting log storage and controlling privileged services. Some organisations also use preventative controls to stop non-compliant resources being deployed at all.
Controls need to be tested against real workload requirements. An overly broad restriction can push teams towards exceptions, while a weak policy provides little practical governance.
Build security into the platform
Security tooling is most effective when it is part of the default platform rather than an optional add-on for individual projects.
That can include vulnerability management, cloud posture monitoring, secret management, key management, threat detection and configuration review. Findings should feed into a process with clear ownership and prioritisation.
DNC’s Cyber Security and Ethical Hacking services can support independent validation of cloud configuration, access and external exposure.
Tagging and cost controls should be useful
Cost management begins with being able to identify who owns a resource and why it exists.
A landing zone should therefore establish naming and tagging standards that support cost allocation, ownership and environment classification. Budgets and alerts can then be aligned to real organisational boundaries.
Cost controls work best when technical teams can see the financial effect of architecture choices, rather than receiving an unexpected bill after the event.
Automation makes the foundation repeatable
Infrastructure as Code can make landing-zone controls easier to reproduce and review. It can also reduce configuration drift between environments.
The value comes from repeatability, not from automation for its own sake. The codebase should be understandable, version-controlled and supported by an approval process appropriate to the organisation.
Changes to foundational networking, identity or security controls should be treated with the same discipline as other significant production changes.
Design for resilience, but base it on business need
A landing zone should make resilient architecture possible, but not every workload requires the same level of availability.
Region selection, availability zones or domains, backup locations and disaster recovery patterns should be based on service requirements. Recovery objectives should inform the platform options available to application teams.
It is important to distinguish between platform resilience and application resilience. A highly available cloud platform cannot compensate for an application that stores critical state in a single fragile component.
Document the standards
A good landing zone is not complete if only the original engineers understand it.
Documentation should describe the structure, identity model, networking, security controls, deployment patterns, exceptions process and operational responsibilities. High Level Design explains the architecture and principles, while Low Level Design can provide the implementation detail needed to build and support it.
This is particularly valuable when multiple suppliers or internal teams share responsibility for the platform.
Common landing-zone mistakes
One common mistake is copying a reference architecture without adapting it to the organisation. Another is treating the landing zone as a one-off project rather than a platform that will need to evolve.
Other problems include overly broad administrator access, inconsistent network controls, poor logging, unclear ownership and too many policy exceptions. Complexity itself can also become a risk when the platform is difficult for operational teams to understand.
What good looks like
A good landing zone gives teams a secure and predictable starting point. Identity and networking are controlled, logs are available, guardrails are understandable, costs are visible and standard deployment patterns are repeatable.
It also has a clear exception process. Not every workload will fit the standard model, but departures should be deliberate, documented and reviewed rather than accidental.
Conclusion
The purpose of a landing zone is to make good cloud architecture easier to deliver repeatedly. It provides the structure and guardrails that allow individual projects to focus on their workloads without rebuilding foundational controls every time.
If you are creating a new cloud foundation or reviewing an existing one, DNC can help with landing zones, current-state discovery and cloud architecture. You can also discuss your requirements with us.