AWS Landing Zone with QuickInfra: Multi-Account Architecture Done Right

Running everything in a single AWS account is the default for most teams when they're starting out. It works until it doesn't. A developer deletes a production resource because they couldn't tell the difference between the dev and prod consoles. An IAM policy written for a test environment gets applied org-wide. A cost spike in one team's workload masks another team's savings. The single-account model has a scaling ceiling.

AWS Landing Zone — built on top of AWS Control Tower — is the answer to this problem at scale. It's an architectural pattern that uses multiple AWS accounts as hard isolation boundaries between environments and between teams, governed from a central management account.

The Account Structure

A typical Landing Zone has three types of accounts. Foundation accounts are managed by the central platform team: the management account (billing and org-level policies only), the log archive account (CloudTrail logs from all accounts flow here), and the security account (GuardDuty, Security Hub, Config aggregation). These accounts have tightly restricted access — almost nobody should be operating resources in them directly.

Shared services accounts host infrastructure used by multiple teams: a central VPC with Transit Gateway connectivity, shared AMI registry, internal DNS, and artefact storage. Workload accounts are where application teams actually operate. Each team typically gets at minimum a development account and a production account. Staging may be in a third account or share a production account depending on your governance requirements.

Control Tower as the Governance Layer

AWS Control Tower sits at the top of this structure and enforces guardrails — mandatory controls that apply across all accounts in your organisation. Preventive guardrails (implemented as Service Control Policies) block actions that violate your governance requirements: no accounts can disable CloudTrail, no accounts can create IAM users without MFA, no S3 buckets can be made publicly accessible. Detective guardrails (implemented as AWS Config Rules) flag policy violations without blocking them — useful for softer requirements where you want visibility without hard enforcement.

QuickInfra's Role

QuickInfra connects to all your workload accounts and provides a unified management interface across the entire Landing Zone. Infrastructure Projects, CI/CD Pipelines, and Custom Scripts in QuickInfra are scoped to specific cloud accounts — a pipeline targeting the development account cannot accidentally run against the production account.

The platform's cross-account cost visibility and compliance scanning aggregate data from all connected accounts into a single dashboard. This gives the platform team the visibility they need without requiring them to log into each individual account's AWS console.

Starting From Scratch

If you're building a Landing Zone for the first time, the recommended path is to use AWS Control Tower to set up the foundation accounts and account vending process, then connect each provisioned account to QuickInfra as a Cloud Account. From that point, all infrastructure in the Landing Zone is managed through QuickInfra, with Control Tower enforcing the governance guardrails above it.

The account vending process — automatically provisioning new workload accounts with the correct baseline configuration when a team needs a new environment — can be implemented using QuickInfra's CloudFormation Stacks feature, deploying the account baseline template to each new account automatically.