How users, service accounts, and workloads authenticate and receive permissions. Covers the identity provider (federated or native), group structure, role definitions, and the principle of least privilege as an enforced baseline — not an aspiration. This domain governs both human access (operators, developers, administrators) and machine access (workloads calling cloud APIs).
02
Account / subscription / project / tenancy structure
The logical boundary model for cloud resources. This is the primary isolation mechanism: AWS uses accounts, Azure uses subscriptions, Google Cloud uses projects, OCI uses compartments within a tenancy. The hierarchy — and the rationale for it — determines policy inheritance, billing boundaries, blast radius of an incident, and the scope of governance controls. Changing this structure after workloads are running is expensive and disruptive.
The network architecture that connects workloads, shared services, on-premises environments, and the internet. Typically a hub-and-spoke model with centralised inspection and routing. Decisions include: CIDR allocation strategy (non-overlapping ranges across all environments), transit model (Transit Gateway, Virtual WAN, Cloud Interconnect, DRG), internet ingress and egress points, and DNS resolution strategy. Network topology decisions are effectively permanent — re-IPing a live environment is a major project.
The minimum security controls applied to every workload in the landing zone by default. Includes: encryption at rest and in transit (enforced, not optional), secrets management (no plaintext credentials), vulnerability scanning, endpoint detection, and network traffic inspection. The security baseline is not a checklist to be completed at deployment — it is an enforced architectural constraint that workloads must satisfy to be accepted into the landing zone.
The mechanism by which the enterprise enforces architectural and security standards across all accounts, subscriptions, or projects. This includes preventive controls (deny non-compliant resource configurations at the API level), detective controls (identify drift from baseline), and corrective controls (automated remediation or alert-and-track). Policy scope, exceptions process, and the governance body responsible for policy changes must be defined and documented.
Centralised collection, retention, and analysis of logs — API activity, platform events, network traffic, and application logs. Logging is a governance requirement, not a technical preference. Decisions: what is logged, where logs are stored, retention period, who can access logs, and how logs are used for security investigation and compliance evidence. The logging architecture must be independent of the workloads it observes — workloads must not be able to disable or modify their own audit trail.
The policy for protecting data and workloads from loss or failure. Covers backup schedules, retention periods, restore testing, cross-region or cross-zone replication, and Recovery Time Objective (RTO) and Recovery Point Objective (RPO) requirements by workload criticality tier. Backup and resilience decisions are made at the landing zone level — workloads onboarded to the zone inherit the applicable tier unless an explicit exception is recorded.
How cloud spend is attributed, monitored, and controlled across accounts or projects. Includes: tagging policy (mandatory cost allocation tags, enforced at the account boundary), budget alerts, cost anomaly detection, chargeback or showback model, and the governance process for commitment purchases (Reserved Instances, Savings Plans, Committed Use Discounts). Cost management is a landing zone function — it cannot be delegated to individual workload teams without a shared foundation.
Centralised capabilities that workloads consume rather than build. Typically includes: DNS resolution, centralised logging pipeline, secrets management, certificate authority, patch management, and container image registry. Shared services are deployed into the landing zone foundation — workloads reference them rather than replicating them. Decisions about what becomes a shared service and what remains workload-local are architectural decisions with cost, operational, and governance implications.
How infrastructure and application code moves from source control to cloud environments. Includes: the CI/CD tooling approved for use in the landing zone, the deployment patterns (infrastructure-as-code standard, code review gates, approval workflows), environment promotion sequence (development → test → staging → production), and the access model for deployment automation (role assumptions, federated identity for pipelines, no static credentials). Deployment pipeline design is a security and governance control, not just a developer convenience.
The process by which a new workload or team is admitted to the landing zone. Covers: the request and approval workflow, the standard account or project structure provisioned for new workloads (account vending machine or project factory), mandatory baseline controls that must be in place before go-live, and the handover checklist. Onboarding is a governance gate — it enforces the landing zone standards at the point where workloads enter the environment, not retrospectively.
How the landing zone itself is operated, maintained, and evolved over time. Includes: ownership of the landing zone components (who is responsible for the network hub, the logging pipeline, the policy engine), the change process for landing zone components, incident response responsibilities for shared services, and the cadence and process for landing zone upgrades. The operations model is an organisational decision as much as a technical one — unclear ownership of the landing zone is a recurring governance failure pattern.
The formal process for requesting, approving, documenting, and reviewing deviations from landing zone standards. Exceptions are inevitable — the absence of a formal process does not prevent exceptions, it prevents them from being tracked. The exception register is an architecture artefact: it records what the deviation is, why it was approved, who approved it, what compensating controls are in place, and when it will be reviewed. Exceptions without a review date become permanent technical debt.
The structured collection of evidence that demonstrates the landing zone meets applicable regulatory, contractual, or organisational requirements. Not a one-time audit artefact — continuous compliance means the evidence is generated automatically from the environment (policy compliance reports, configuration snapshots, log archives) and is available on demand. The compliance evidence model must be designed into the landing zone — retrofitting auditability into a running environment is difficult and incomplete.