Automating AWS Control Tower
Landing Zones with AI

The Problem with Traditional Landing Zone Delivery

Every regulated enterprise that adopts AWS at scale eventually arrives at the same problem. The cloud platform team is asked to hand new application teams a landing zone — a multi-account AWS environment, governed by Control Tower, wired into the company's identity provider, peered into the right networks, and locked down by a hierarchy of Service Control Policies that match the team's data classification, regulatory regime, and blast-radius requirements.

On paper this is a configuration problem. In practice it is a four-to-six week delivery cycle of meetings, ticket queues, copy-pasted Terraform modules, brittle IAM Identity Center mappings, and a final day of manual verification before the team is handed the keys. Every landing zone is subtly different. Every landing zone is a snowflake. And every snowflake is a future audit finding waiting to happen.

We rebuilt this delivery process around a multi-agent system powered by Claude. The result is an architecture in which a platform engineer describes the workload in plain English — "a HIPAA-bound data-science workspace for Team Helix, two regions, VPC-only egress, no internet ingress, separate Dev/Test/Prod accounts" — and a coordinated set of LLM agents produces a fully reviewed, policy-validated, deployment-ready landing zone in under three hours.

Why This Is an Agentic Problem, Not a Template Problem

The natural first instinct for any engineer reading this is to ask: why not just write better Terraform modules? We tried. We had a catalogue of 40+ modules, an internal "platform-as-a-product" portal, and a team of four engineers maintaining them. The catalogue still could not absorb the long tail of variation that real teams bring. Some workloads need an egress-only Transit Gateway attachment. Some need Macie classification jobs scoped to a specific bucket prefix. Some need a Permissions Boundary that allows S3 but only with KMS-CMK encryption and only in two regions.

The combinatorial space of account topology × network design × identity model × data-class controls × regulatory regime is too large to template exhaustively. But it is not too large to reason about. That is the gap an agentic system fills: it composes existing modules in workload-specific ways, validates the composition against policy, and self-corrects when validation fails — which is exactly the kind of multi-step, dynamic, tool-using work that single-prompt LLM calls cannot reliably do.

We built the system on the DOE pattern described in our earlier write-up. A planner agent decomposes the request into a dependency graph. An orchestrator routes subtasks to specialist agents — one per concern (networking, IAM, SCPs, logging, cost, compliance). Each specialist owns a narrow tool surface and a narrow prompt, which keeps hallucinations contained and makes individual agents independently testable.

System Architecture

The system runs as a long-lived workflow inside our internal platform. The intake is a Slack command or a structured form. The output is a pull request against the platform monorepo, containing Terraform plans, generated SCPs, an architecture diagram, a cost estimate, and an evidence pack for the security review board.

Two design choices matter more than the rest. First, every agent is bounded by a tool whitelist. The networking agent cannot touch IAM. The IAM agent cannot touch SCPs. This compartmentalisation is what makes the system auditable — and what makes it safe to give it write access to a CI pipeline.

Second, no agent ever calls a mutating AWS API directly. Agents produce Infrastructure-as-Code. Humans (or, increasingly, our policy gate) approve a Terraform plan. Pipelines apply it. This separation is non-negotiable: it is the difference between a system you can trust with a production AWS organisation and a very expensive science project.

The Specialist Agents

The orchestrator dispatches to five specialist agents. Each has its own system prompt, its own tool surface, and its own evaluation suite. Adding a new concern — say, FinOps tagging policies — means adding a sixth agent, not modifying the existing five.

An End-to-End Walkthrough

To make this concrete, here is the actual flow for a recent intake — a HIPAA-bound analytics workspace for an internal team, three accounts, two regions, no public ingress. The full run took two hours and forty minutes from Slack command to merged PR.

# Auto-generated by Guardrail Agent · run_id 7f3e2a · attached to OU /Workloads/Helix-PHI
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedS3PutObject",
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    },
    {
      "Sid": "DenyRegionsOutsideAllowList",
      "Effect": "Deny",
      "NotAction": ["iam:*", "organizations:*", "support:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2"]
        }
      }
    }
  ]
}

Two things to notice. The SCP composition is not freeform LLM output — it is a composition of fragments from the curated library, each fragment hand-written by the security team. The agent's job is to pick the right fragments for the workload and parameterise them (allowed regions, KMS key alias, etc.). That single design choice is what makes the output safe to merge.

Manual vs. Agent-Driven Delivery

The contrast with our prior process is sharp on every axis we care about:

The Guardrails We Wish We'd Built First

The honest version of any agentic-systems story is the list of mistakes that shaped the production design. Ours fall into four categories, and skipping any of them in your own rollout will hurt.

Non-Negotiable Guardrails

If you take only one thing from this article, take this list. These are the controls without which we would not have shipped the system to production.

• Read-only AWS access for agents. No agent has iam:*, no agent has organizations:*Create*. Mutating actions go through the pipeline, behind a human approval, every time.
• Composition over generation. Agents pick from vetted fragments; they do not write security-critical IaC from scratch. The catalogue is the trust boundary.
• Policy-as-code as a non-bypassable gate. Conftest, Checkov, tfsec, and our internal OPA bundle all run on every PR. An agent cannot self-approve past a failing policy.
• Replay before deploy. Every SCP change is dry-run against recent CloudTrail from a comparable workload before the PR is opened.
• Bounded retry budget. Three attempts per agent, then the run halts and a human is paged. Agents that loop are agents that hallucinate.
• Full traceability. Every artifact is signed with the run ID, the agent that produced it, the model version, the prompt hash, and the input spec hash. We can reconstruct any decision the system has ever made.

What This Generalises To

Landing-zone provisioning is one instance of a much broader class of problems: structured configuration generation against a policy boundary. Kubernetes platform onboarding fits the same shape. Snowflake/Databricks workspace provisioning fits the same shape. Salesforce sandbox vending, internal CA issuance, VPN tunnel pairing, secret-store onboarding — all of them are problems where the space of valid outputs is infinite, the space of safe outputs is constrained by policy, and the work of producing one output sits awkwardly between configuration and code.

The pattern that worked for us — a planner, a small set of bounded specialists, a curated catalogue of building blocks, policy-as-code as the validation gate, and a hard separation between authoring and applying change — is the pattern we now reach for whenever we see this shape of problem. Agents do not replace platform engineering. They turn platform engineers from builders of one-off zones into curators of the catalogue agents compose from. That is a much better job.