AWS Account Vending

Scaling AWS: Why a Multi-Account Strategy is Non-Negotiable

Organizations constantly struggle with how to structure their cloud footprint across different business units, budgets, and cost centers. While putting everything into a single shared AWS account might seem simpler on day one, it quickly creates operational bottlenecks that throttle developer velocity.

If you are scaling a cloud environment, adopting a strict multi-account architecture provides a few critical advantages:

• No More Rate Limit Collisions: When teams share an account, they compete for the same regional AWS service quotas (e.g., EC2 vCPU limits, VPC endpoints). During peak deployments, this triggers AWS API rate limits and crashes CI/CD pipelines.
• Preventing Configuration Bleed: Isolating teams into dedicated accounts eliminates overlapping IAM policies, naming collisions on shared resources, and the reality of one team accidentally altering another team’s infrastructure.
• Clean Cost Allocation: Tracking costs at the AWS account level is deterministic. It completely avoids the headache of untangling complex, easily broken tag-based chargeback models.
• Blast Radius Containment: Keeping Development, Staging, and Production in entirely separate accounts ensures that a misconfiguration in a sandbox cannot take down production workloads.

Zero-Touch Provisioning with AFT

You can’t manually provision AWS accounts for an enterprise with hundreds of teams without paralyzing your pipeline. Automating this at scale requires an event-driven approach.

One of the most effective solutions I deploy for this is Account Factory for Terraform (AFT)—an open-source framework built by AWS.

AFT enforces a GitOps workflow. Instead of submitting a ticket and waiting weeks for network and IAM approvals, a developer simply commits a new account request Terraform file to a repository. That commit triggers a pipeline that provisions the account via the AWS Control Tower API.

From that single commit, AFT handles the AWS Organization enrollment, Service Catalog association, and all post-provisioning customizations (like security baselines and network routing). For more complex workflows, you can extend it using supplemental Terraform manifests or Lambda functions invoked directly by Step Functions.

Fixing the Monolithic State File Problem

If you’ve spent enough time engineering infrastructure, you know that a monolithic Terraform state file is a massive liability.

Before adopting AFT, I dealt with the pain of using a single state file to manage global resources across dozens of accounts. State refreshes were painfully slow, and routine terraform apply executions were regularly stretching to 30 minutes or more.

AFT solves this by breaking down state management. Rather than lumping hundreds of accounts into one massive file, each provisioned target account is managed by three distinct, isolated state files:

1. account-provisioning-state: Sets up the account-level CodePipeline infrastructure.
2. global-customizations-state: Tracks baseline Terraform code applied to all accounts in the organization, ensuring baseline compliance.
3. account-customizations-state: Tracks Terraform code applied only to this specific account, giving application teams flexibility without breaking global guardrails.

Splitting state by account and customization layer restores speed to the deployment pipeline and drastically minimizes the blast radius if an apply fails.

The Architecture Under the Hood

AFT is installed into a dedicated AFT Management Account inside your AWS Organization. This account acts as the centralized brain, hosting the core pipelines, Step Functions state machines, EventBridge rules, and logs.

It uses cross-account IAM roles to execute actions securely:

• Main Control Tower Account: Orchestrates SSO, OU movements, and account baseline enrollment.
• Target Account: Provisions environment-specific resources like VPCs, S3 buckets, and application IAM roles.

The Bottom Line

If you are currently managing a growing AWS footprint manually, or wrestling with 30-minute monolithic Terraform state files just to provision an account, your engineers are fighting your infrastructure instead of shipping product. AFT bridges the gap between Control Tower’s rigid governance and Terraform’s agile IaC workflow seamlessly.

(Reference Diagram: AWS AFT Architecture)
(Source Repository: terraform-aws-control_tower_account_factory)

Navigating your own multi-account scaling challenges?

I frequently talk shop with other engineering leaders about untangling legacy AWS architecture, scaling Internal Developer Platforms, and eliminating ‘TicketOps.’ If your team is navigating these hurdles, feel free to reach out—always happy to connect and compare notes.