AWS Landing Zone: Getting Started Right

A landing zone is the foundation of your AWS environment. It defines how accounts are structured, how access is managed, how guardrails are enforced, and how logging works across your organization. Getting this right from day one saves months of painful rearchitecture later. Getting it wrong means accumulating technical debt that becomes exponentially harder to fix as your environment grows.

What Is a Landing Zone?

A landing zone is a pre-configured, secure, multi-account AWS environment based on best practices. Think of it as the blueprint for your entire AWS presence. It answers fundamental questions: How are accounts organized? Who can access what? Where do logs go? What is allowed and what is prevented?

Without a landing zone, teams create AWS accounts ad hoc, configure them inconsistently, and build up security and governance gaps that are invisible until something goes wrong. A landing zone ensures every new account starts with the right configuration, the right guardrails, and the right connectivity from the moment it is created.

AWS provides two paths to a landing zone: AWS Control Tower (managed) or a custom-built solution using Organizations, CloudFormation, and your own automation. For most businesses, Control Tower is the right starting point.

Why You Need One: Avoiding Technical Debt

The most expensive AWS decision is not choosing the wrong instance type. It is building on a weak foundation and having to rearchitect once production workloads are running.

Without a landing zone: IAM users proliferate with static credentials. CloudTrail may not be enabled in all regions. Resources get deployed without tagging standards. Security findings have no central place to aggregate. Billing gets tangled across teams with no way to attribute costs.

With a landing zone: Every account gets centralized logging from day one. Identity is federated through a single pane. Guardrails prevent dangerous actions automatically. New accounts are provisioned in minutes with consistent baseline configuration. Your environment scales cleanly.

AWS Control Tower Overview

Control Tower is AWS's managed landing zone service. It sets up a multi-account environment with pre-configured guardrails, centralized logging, and federated access. It builds on top of AWS Organizations, AWS Config, and IAM Identity Center.

What Control Tower provides out of the box: A management account with Organizations, a Log Archive account for centralized CloudTrail and Config logs, an Audit account for security tools and cross-account access, an Account Factory for provisioning new accounts with standard configuration, and a set of preventive and detective guardrails.

When to use Control Tower: If you are starting fresh or have fewer than 50 accounts, Control Tower is the fastest path to a well-governed environment. It handles the heavy lifting of configuring Organizations, setting up centralized logging, and enabling guardrails. You get best practices without building everything from scratch.

Account Structure: Getting the Foundation Right

A well-designed account structure separates concerns and limits blast radius. Here are the core accounts every landing zone needs:

Management account: The root of your Organization. It contains only Organizations configuration, billing, and Control Tower. No workloads should ever run here. Restrict access to a small number of administrators.

Security/Audit account: Houses security tooling like GuardDuty delegated administrator, Security Hub, and cross-account audit roles. Security teams operate from this account to investigate findings across the organization.

Log Archive account: Central destination for all CloudTrail logs, VPC Flow Logs, Config snapshots, and access logs from across the organization. This account should be locked down with minimal access. Logs are immutable and retained according to your compliance requirements.

Sandbox accounts: Low-risk accounts for experimentation and learning. Apply spending limits and aggressive cleanup policies. These let developers explore AWS services without risking production or accumulating forgotten resources.

Workload accounts: Separate accounts for production, staging, and development environments. Each workload or application can get its own account for maximum isolation. This prevents a misconfiguration in development from affecting production.

Guardrails and Service Control Policies

Guardrails are governance rules applied across your organization. Control Tower provides two types:

Preventive guardrails use Service Control Policies (SCPs) to block actions before they happen. Examples: prevent disabling CloudTrail, prevent deleting the Log Archive bucket, prevent creating IAM users with console access, restrict which regions resources can be deployed to. These are hard boundaries that no IAM policy can override.

Detective guardrails use AWS Config rules to identify non-compliant resources after they are created. Examples: detect S3 buckets without encryption, detect security groups allowing unrestricted SSH, detect root user activity. These generate findings rather than blocking actions.

Start with mandatory guardrails and add elective ones as your governance needs mature. Common SCPs to implement early: deny access to unused regions, require encryption on S3 and EBS, prevent modification of security baseline resources, and require specific tags on resource creation.

Identity and Access: IAM Identity Center

IAM Identity Center (formerly AWS SSO) is the single access point for your entire AWS organization. Instead of creating IAM users in every account, teams authenticate once and assume roles in the accounts they need.

Connect your identity provider: Integrate with Azure AD, Okta, or any SAML 2.0 provider. Users authenticate with their corporate credentials and MFA. No separate AWS passwords to manage.

Permission sets: Define reusable permission sets (like AdministratorAccess, ReadOnlyAccess, or custom policies) and assign them to groups for specific accounts. A developer might get PowerUser access to the development account but ReadOnly access to production.

Eliminate long-lived credentials: With Identity Center, nobody needs IAM access keys for console access. Temporary credentials are issued for each session. This eliminates the risk of leaked static credentials and simplifies offboarding when employees leave.

Networking: Shared VPC vs Per-Account VPC

Your landing zone needs a networking strategy. Two main patterns exist:

Shared VPC (via RAM): A central networking account owns the VPCs and shares subnets to workload accounts using Resource Access Manager. Workload accounts deploy resources into shared subnets without managing VPC infrastructure. This centralizes network management and simplifies IP address planning.

Per-account VPC: Each workload account has its own VPC connected through Transit Gateway. This gives teams full control over their network configuration but requires more coordination around CIDR planning and routing. Better for teams that need network-level customization.

Hybrid approach: Many organizations use shared VPCs for common services and per-account VPCs for workloads that need isolation. Transit Gateway connects everything with route table segmentation controlling which VPCs can communicate.

Logging and Monitoring Baseline

Every account in your landing zone should have these enabled from day one:

CloudTrail: Organization-level trail capturing management events across all accounts and regions. Send logs to the Log Archive account S3 bucket with bucket policies preventing deletion.

AWS Config: Record resource configurations across all accounts. Aggregator in the Audit account provides a single view of compliance. Config rules detect drift from your baseline.

GuardDuty: Enable across all accounts with delegated administrator in the Security account. GuardDuty analyzes CloudTrail, VPC Flow Logs, and DNS logs to detect threats automatically.

Security Hub: Aggregates findings from GuardDuty, Config, Inspector, and third-party tools into a single dashboard. Run the AWS Foundational Security Best Practices standard for automated compliance checks across your environment.

Cost Allocation and Tagging Strategy

Multi-account environments make cost attribution easier because each account's spending is tracked separately. Complement this with a consistent tagging strategy:

Mandatory tags: Enforce tags like Environment, Team, Project, and CostCenter through SCPs or tag policies. These enable granular cost reporting in Cost Explorer and accurate chargeback to business units.

Consolidated billing: Organizations provides a single bill across all accounts with volume discounts applied organization-wide. Set up AWS Budgets per account and per organizational unit to catch spending anomalies early.

When to Implement: As Early As Possible

The best time to implement a landing zone is before you deploy your first production workload. The second best time is now. Every month you delay means more resources deployed without governance, more technical debt to clean up, and more risk of a security incident in an ungoverned account.

For greenfield deployments, set up Control Tower before anything else. For existing environments, you can enroll existing accounts into Control Tower and bring them under governance incrementally. The process is non-destructive but requires planning around existing resources.

Retrofitting an Existing Single-Account Setup

If you are running everything in a single AWS account today, the path to a proper landing zone involves:

• Set up Organizations and Control Tower using your existing account as the management account (or create a new management account and invite your existing one).
• Create foundational accounts (Security, Log Archive) and enable organization-wide services like CloudTrail and GuardDuty.
• Migrate workloads incrementally. Start with non-production environments. Use AWS migration tools or infrastructure-as-code to redeploy in new accounts.
• Implement IAM Identity Center and begin migrating users away from IAM users with static credentials.
• Apply SCPs carefully. Start with detective guardrails to understand your current state before enabling preventive controls that might break existing workloads.