Landing Zone Design Patterns for Enterprise Cloud Adoption

What Is a Landing Zone?

A landing zone is the foundational architecture of your cloud environment — the account structure, networking topology, identity configuration, security controls, logging setup, and governance policies that every workload inherits. Think of it as the pre-built infrastructure that exists before anyone deploys a single application. A well-designed landing zone makes it easy to deploy workloads securely, consistently, and cost-effectively. A poorly designed landing zone — or worse, no landing zone at all — leads to security gaps, inconsistent configurations, uncontrolled costs, and an environment that becomes increasingly difficult to manage as it grows.

This article covers landing zone design patterns for enterprise cloud adoption across AWS, Azure, GCP, and OCI. We examine account and subscription organization, network architecture, identity and access design, security baseline configuration, logging and monitoring setup, and automation. Whether you are building a new landing zone from scratch or improving an existing one, these patterns provide a proven foundation.

Account and Subscription Structure

The first and most important landing zone decision is how to organize your cloud resources into isolated units — accounts on AWS, subscriptions on Azure, projects on GCP, and compartments on OCI. The goal is to provide security isolation (a breach in one unit does not affect others), cost attribution (costs are naturally grouped by business unit or workload), and permission boundaries (administrators of one unit cannot accidentally affect another).

On AWS, the recommended pattern is one account per workload per environment. A single application has separate accounts for production, staging, and development. Shared services (networking hub, logging, security tooling) have dedicated accounts. All accounts are organized under AWS Organizations with organizational units (OUs) for workloads, infrastructure, security, and sandbox environments. This pattern typically results in 10-50 accounts for a mid-size organization and 100-500 accounts for a large enterprise. AWS Control Tower automates the creation of new accounts with pre-configured guardrails, SSO access, and networking.

On Azure, subscriptions serve a similar isolation purpose. The recommended pattern uses management groups to organize subscriptions into a hierarchy: a root management group, platform management groups (connectivity, identity, management), and workload management groups (production, non-production, sandbox). Each workload or team gets a dedicated subscription. Azure Landing Zone Accelerator (formerly Enterprise-Scale) provides reference architectures and Bicep/Terraform templates for deploying this structure automatically.

On GCP, projects provide resource isolation. The recommended pattern uses an organization node with folders for environments (production, staging, development), shared services (networking, security, logging), and workloads. Each application or team gets a project. Google Cloud Foundation Toolkit and the Fabric FAST framework provide Terraform-based landing zone deployment automation. GCP projects are lighter-weight than AWS accounts, so it is common to use more of them — one per microservice or one per team member for development sandboxes.

On OCI, compartments provide hierarchical resource isolation within a tenancy. The recommended pattern creates top-level compartments for network, security, shared services, and workloads, with nested compartments for environments and applications within each. OCI compartment policies control access at each level of the hierarchy, and resources in one compartment are invisible to users who do not have access to that compartment.

Network Architecture

Landing zone network architecture defines how workloads communicate with each other, with the internet, and with on-premises environments. The hub-and-spoke model is the dominant pattern across all four providers, where a central hub network provides shared services (internet egress, VPN/interconnect termination, DNS, firewalls) and spoke networks host individual workloads.

On AWS, the hub is typically a Transit Gateway that connects all VPCs in the organization. The hub VPC contains NAT Gateways, VPN connections or Direct Connect, and centralized firewalls (AWS Network Firewall or third-party NVAs). Spoke VPCs are attached to the Transit Gateway through Transit Gateway attachments. Route tables on the Transit Gateway control traffic flow: production VPCs can communicate with the shared services VPC but not with development VPCs. This architecture scales to hundreds of VPCs and provides centralized network control and visibility.

On Azure, the hub is a Virtual Network containing Azure Firewall, VPN Gateway or ExpressRoute Gateway, Azure Bastion, and shared services. Spoke VNets are connected through VNet peering. Azure Virtual WAN provides an alternative hub architecture that automates routing and scaling for large deployments with many sites and branches. The Azure Landing Zone reference architecture uses hub-spoke with a connectivity subscription and separate spoke subscriptions for workloads.

On GCP, Shared VPC is the primary mechanism for landing zone networking. A host project owns the VPC and its subnets, and service projects attach to the Shared VPC to deploy resources into specific subnets. This eliminates the need for VPC peering between workload projects while maintaining centralized network control. For organizations with multiple Shared VPCs (e.g., production and non-production), VPC peering or Cloud VPN connects them. Cloud NAT, Cloud Router, and Cloud Interconnect in the host project provide shared egress and hybrid connectivity.

On OCI, the hub is a VCN with a Dynamic Routing Gateway (DRG) that connects to spoke VCNs through local peering, to other regions through remote peering, and to on-premises through FastConnect or IPSec VPN. The hub VCN hosts shared network services: NAT Gateway, Service Gateway, and OCI Network Firewall. Spoke VCNs for each workload are peered to the hub through the DRG, which acts as a transit routing hub similar to AWS Transit Gateway.

Identity and Access Design

Landing zone identity design establishes how humans and services authenticate to your cloud environment and what permissions they receive. The core principles are: centralized identity (one source of truth for user accounts), federated authentication (users authenticate through your identity provider, not cloud-specific accounts), least-privilege access (start with minimal permissions and add as needed), and temporary credentials (no long-lived access keys or service account keys).

On AWS, use IAM Identity Center (formerly AWS SSO) connected to your corporate identity provider (Azure AD, Okta, Google Workspace) through SAML or SCIM. Define permission sets that map to IAM roles in each account, and assign permission sets to identity provider groups. Engineers access accounts through the Identity Center portal, receiving temporary credentials that expire after a configurable duration. For service authentication, use IAM roles with instance profiles, task roles, and pod identity rather than access keys.

On Azure, Microsoft Entra ID (formerly Azure AD) is the identity backbone. Configure Conditional Access policies to enforce MFA, device compliance, and location-based access controls. Use Privileged Identity Management (PIM) for just-in-time elevation of administrative roles — administrators request elevation when needed and receive time-limited access that automatically expires. For workload identity, use managed identities for Azure resources and Workload Identity Federation for external services.

On GCP, use Cloud Identity or Google Workspace as the identity provider, or federate with an external provider. Configure Organization Policies to enforce security constraints. Use IAM Conditions for context-aware access (allow access only from specific networks or during business hours). For workload identity, use Workload Identity for GKE pods and Workload Identity Federation for external workloads. Avoid service account keys entirely.

On OCI, configure Identity Domains with federation to your corporate identity provider. Use Dynamic Groups for service-to-service authentication, allowing compute instances and functions to access OCI resources without managing credentials. Define IAM policies at the compartment level using the OCI policy language, which provides clear, readable access rules.

Security Baseline

The landing zone security baseline ensures that every new account, subscription, project, or compartment starts with the minimum required security controls. These controls should be applied automatically through organization-level policies and infrastructure-as-code, not manually configured after account creation.

Critical security baseline components include: audit logging enabled and centralized (CloudTrail to logging account, Azure Activity Log to central workspace, GCP audit logs to logging project, OCI Audit to logging compartment), threat detection enabled (GuardDuty, Defender for Cloud, Security Command Center, Cloud Guard), encryption enforced (default EBS encryption, storage account encryption, CMEK policies), network restrictions (no public access by default, VPC endpoints or Private Link for service access), and access guardrails (SCPs, Azure Policy, Organization Policies, compartment policies that prevent dangerous actions regardless of individual permissions).

Each provider offers a compliance framework tool that evaluates your environment against security best practices. AWS Security Hub with the Foundational Security Best Practices standard, Azure Defender for Cloud with Secure Score, GCP Security Command Center with Security Health Analytics, and OCI Cloud Guard with detector recipes. Enable these tools in the landing zone baseline and route findings to a central security team for remediation.

Logging and Monitoring Architecture

Centralized logging is a non-negotiable landing zone component. Every account and subscription should send audit logs, VPC flow logs, DNS query logs, and application logs to a centralized, protected logging destination. This destination must be accessible to the security and operations teams but protected from modification by workload administrators — otherwise, an attacker who compromises a workload account can delete the logs of their activity.

On AWS, create a dedicated logging account in your organization. Configure organization-wide CloudTrail with logs delivered to an S3 bucket in the logging account with object lock for immutability. Use CloudWatch cross-account observability to view metrics and logs across all accounts from a central monitoring account. Configure VPC Flow Logs in every VPC with delivery to the central S3 bucket.

On Azure, create a dedicated management subscription with a central Log Analytics workspace. Configure Diagnostic Settings at the management group level to send activity logs from all subscriptions to this workspace. Use Azure Lighthouse to provide the operations team read access to monitoring data across all subscriptions without requiring separate account credentials.

On GCP, create a dedicated logging project. Configure organization-level log sinks to export all audit logs to BigQuery or Cloud Storage in the logging project. Use aggregated log sinks at the folder level for environment-specific log routing. Set IAM policies on the logging project to restrict access to the security team.

On OCI, create a dedicated logging compartment. Configure Audit policies to retain audit logs in this compartment. Use Service Connectors to route logs from all compartments to the central logging infrastructure. OCI Logging Analytics provides centralized log analysis across the tenancy.

Automation and Infrastructure as Code

A landing zone is only as good as its automation. Manually configured landing zones drift over time, new accounts miss required configurations, and the process of creating a new workload environment takes days or weeks instead of minutes. Every aspect of the landing zone should be defined in infrastructure-as-code and deployed through automated pipelines.

Each provider offers landing zone automation frameworks. AWS Control Tower with Account Factory for Terraform (AFT) automates account creation with pre-configured guardrails, networking, and SSO access. Azure Landing Zone Accelerator provides Bicep and Terraform modules for deploying the reference architecture. GCP Cloud Foundation Toolkit and Fabric FAST provide Terraform modules for organization setup, networking, and project creation. OCI Resource Manager provides Terraform-based stack management for landing zone deployment.

Beyond the initial landing zone deployment, automate the account or subscription vending process. When a team needs a new workload environment, they should submit a request (through a service catalog, Jira ticket, or Git pull request) that triggers an automated pipeline to create the account/subscription/project, configure networking, apply the security baseline, set up logging, create IAM roles, and notify the team. This process should take minutes, not days, and produce a consistent, compliant environment every time.

Governance and Policy Enforcement

Landing zone governance ensures that the rules and standards you establish are enforced consistently, even as the environment grows and more teams deploy workloads. Governance operates at two levels: preventive controls (policies that prevent non-compliant actions from occurring) and detective controls (checks that identify non-compliant configurations after they exist).

Preventive controls include: AWS SCPs that deny dangerous actions (disabling CloudTrail, creating public S3 buckets, deploying in unauthorized regions), Azure Policies with Deny effect that block non-compliant resource creation, GCP Organization Policies that restrict resource types, locations, and configurations, and OCI IAM policies that limit actions to specific compartments and resources. These controls are enforced at the API level — no user or service can bypass them regardless of their individual permissions.

Detective controls include: AWS Config rules that evaluate resource configurations against compliance rules, Azure Policy with Audit effect that flags non-compliant resources without blocking them, GCP Security Health Analytics findings that identify misconfigurations, and OCI Cloud Guard problems that detect deviations from security recipes. Detective controls complement preventive controls by catching configurations that are technically allowed but violate organizational standards.

Implement both preventive and detective controls in your landing zone. Preventive controls protect against the most dangerous actions (data exposure, logging disruption, unauthorized access). Detective controls catch everything else and provide continuous compliance monitoring.