Enterprise Hybrid Landing Zone

TL;DR

• Design a governed enterprise foundation for hundreds of teams, hybrid connectivity, private access, centralized security, and migration waves.
• AWS Organizations, OUs, SCPs, Control Tower, and IAM Identity Center define account and access guardrails; this is the foundation for security and cost governance.
• Shared networking (Transit Gateway, Cloud WAN, Direct Connect/VPN, Route 53 Resolver, VPC endpoints) enables connectivity without requiring every team to manage their own WAN.
• Central security accounts aggregate CloudTrail, Config, GuardDuty, Security Hub, Detective, logs, and evidence; a single pane of glass for organization-wide visibility and incident response.
• Account vending, tag policies, backup policies, and IaC pipelines make the platform repeatable and scalable to hundreds of teams without proportional growth in manual work.

Core Concepts

AWS Organizations and Account Hierarchy

AWS Organizations groups accounts into an organizational structure: a root account at the top, organizational units (OUs) as logical groupings (by business unit, environment, workload type, or compliance domain), and member accounts under each OU. This structure enables centralized policy enforcement, cost visibility by unit, and delegation of account creation to different teams (account vending). Service Control Policies (SCPs) are attached to OUs and enforce constraints (no use of unencrypted S3, no public RDS databases, no use of non-approved regions) that apply to all member accounts. SCPs are preventive controls that block disallowed actions before they can be taken.

Control Tower and Guardrails

AWS Control Tower is the prescribed way to set up an AWS landing zone: it creates account structure, applies guardrails (preventive SCPs and detective Config rules), and provides account vending (self-service account creation with pre-configured networking, logging, and budgets). Control Tower guardrails include: preventive guardrails (SCPs that deny actions), detective guardrails (Config rules that detect non-compliance), and elective guardrails (detective rules that flag unusual configurations). The result is a repeatable, compliant baseline that new teams inherit automatically when they request an account.

Shared Networking and Connectivity

A central networking account owns the Transit Gateway (a hub-and-spoke network topology), VPCs for shared services (DNS, NAT, security monitoring), and the connection to on-premises networks (Direct Connect for dedicated connectivity, VPN for encrypted tunnels). Each workload account creates its own VPC and attaches it to the Transit Gateway; traffic between accounts flows through the hub. This eliminates the need for every account to establish its own on-premises connection and replaces complex, messy mesh networking with a scalable topology. Route 53 Resolver endpoints at the hub enable hybrid DNS resolution: on-premises DNS queries are forwarded to on-premises resolvers, AWS DNS queries are resolved locally.

VPC Endpoints and Private Access

VPC endpoints (interface endpoints for API services, gateway endpoints for S3 and DynamoDB) enable resources in a VPC to access AWS services (S3, DynamoDB, SNS, SQS, Bedrock, Secrets Manager) without traversing the internet. This keeps traffic private and within the AWS network, reducing exposure to internet-based attacks. Each VPC defines which endpoints it needs; the central network team provisions shared endpoints in the hub and shares them via Resource Access Manager (RAM). This prevents each account from creating duplicate endpoints and simplifies management.

Identity and Access Management at Enterprise Scale

IAM Identity Center (AWS SSO) provides centralized identity management: employees log in once with corporate credentials (SAML, OIDC, AD) and get temporary credentials for AWS. Teams do not manage long-lived IAM users or access keys; instead, they define permission sets (bundles of IAM policies) and assign them to users or groups. A user assigned the “Developer” permission set to an OU automatically gets those permissions in every account under that OU. This scales identity management from managing thousands of IAM users across hundreds of accounts to managing a few permission sets and group assignments.

Centralized Logging and Security Monitoring

A central security account is the destination for all organization-wide logs: CloudTrail (API calls by whom, when, from where, with what result), Config (resource configuration snapshots and drift detection), GuardDuty (threat detection based on network and API anomalies), Security Hub (aggregated findings from GuardDuty, Config, IAM Access Analyzer, and third-party tools), and CloudWatch Logs (application and infrastructure logs). This central account has read-only access to all member accounts’ logs via CloudTrail organization trail, Config aggregation, and similar mechanisms. A single pane of glass for the CISO replaces hundreds of separate AWS accounts’ logs scattered everywhere.

Preventive vs. Detective Controls

Preventive controls (SCPs, security groups, NACLs, encryption keys) block disallowed actions before they execute. Detective controls (Config rules, CloudTrail, GuardDuty, Security Hub, CloudWatch alarms) detect after-the-fact what was done and alert. An enterprise landing zone uses both: SCPs prevent the most dangerous actions (deleting CloudTrail, disabling encryption), but not every action can be prevented (e.g., “don’t create expensive compute”). Detective controls catch what preventive controls miss. Responsive controls (incident response runbooks, automated remediation) act on detections to fix or escalate.

Account Vending and Baseline Configuration

Account vending is self-service account creation through Control Tower or a custom automation (Terraform, CloudFormation, custom Lambda): a team requests a new account, approval is (optionally) required, and the new account is automatically created with: VPC and network baseline, CloudTrail and Config enabled and forwarding to central account, IAM Identity Center role federated with corporate identity, backup policy applied, cost budget/alert created. This baseline takes hours to set up manually but seconds to automate. Every account inherits the guardrails of its parent OU and the logging baseline of the organization.

Migration Waves and Dependency Mapping

Enterprise migrations (moving workloads from on-premises to AWS) follow waves: first, teams with independent workloads and fast execution; later, teams with complex dependencies on other systems. Before each wave, teams map dependencies (which systems does our workload depend on? which systems depend on us?), define success criteria, plan rollback (can we revert to on-premises if things go wrong?), and agree on cutover time. Waves are not purely technical; they account for team readiness, external dependencies, and business impact.

Landing Zone Architecture Pattern

Production Challenges and Controls

Architect Review Checklist

• Are account structure (root, OUs) and SCP strategy documented? What is the scope of each OU?
• Is the CIDR allocation strategy documented? Is there a registry preventing overlaps?
• What is the source of truth for identity (SAML, OIDC, AD)? Are permission sets managed centrally?
• Are all accounts’ CloudTrail, Config, GuardDuty, and Security Hub logs flowing to a central security account?
• Are preventive controls (SCPs, security groups) documented? Are detective controls (Config rules, CloudWatch alarms) in place for what SCPs don’t cover?
• Is account vending automated? What is the baseline configuration every new account receives?
• Are migration dependencies mapped and runbooks documented for rollback?

Common Pitfalls

• Pitfall: Listing services without explaining why each one satisfies a requirement. Why: creates the illusion of design rigor but masks shallow thinking. Fix: For every service chosen, state the requirement it meets and the alternative approaches rejected.
• Pitfall: Designing only the happy path and ignoring degraded mode. Why: failure is guaranteed in production; a design that only works when everything succeeds is a design that fails. Fix: Define explicit failure mode for every dependency; what happens if the Transit Gateway is down, if Route 53 Resolver is unavailable, if CloudTrail is disabled.
• Pitfall: Forgetting tenant isolation, identity boundaries, certificate lifecycle, and audit evidence. Why: data leakage, cross-account access, and inability to investigate incidents are production catastrophes. Fix: Define explicit data isolation per account and per OU; document identity assumptions; ensure all privilege escalations and policy changes are logged.
• Pitfall: Choosing maximum resilience without proving the business needs or can operate it. Why: over-engineering increases complexity and operational burden. Fix: Define RTO/RPO requirements for the landing zone itself; build only the resilience and redundancy the business needs and the team can operate.