Tame AWS Account Sprawl with Control Tower + When Cloud Makes Sense and How to Do It
In This Issue:
Control Tower & AFT Turn AWS Account Chaos into Infrastructure as Code
Listen to the podcast or keep scrolling to read Steven Black 's blog post...
AWS Account Factory for Terraform (AFT) is a game-changer for businesses managing multiple AWS accounts. It optimizes the creation, management, and removal of AWS accounts through Terraform, meeting the growing need for standardized processes in multi-account environments. AFT automates account lifecycle management, enabling users to request fully configured accounts with minimal code.
The implementation involves three key steps: setting up a Control Tower landing zone, configuring AFT repositories, and deploying the AFT root module to provision resources efficiently. By maintaining configuration consistency and preventing resource sprawl, AFT offers organizations of all sizes the benefits of efficient AWS account management.
Let’s walk through what AWS Control Tower is, how it works with AFT, and why you’d want to use this powerful combination.
What is AWS Control Tower?
Our introduction covers what Control Tower’s function is but what is it made out of? And how does AFT fit into all this?
AWS Control Tower vs. AFT
AWS Control Tower is an AWS service that provides best-practices for a multi-account cloud environment. Part of that solution is an Account Factory. Control Tower comes with an Account Factory but they also provide AFT to users who are interested in using Terraform to manage their accounts.
Core Components of AWS Control Tower & AFT
Control Tower is, at present, set up through the AWS console. The AFT portion is written in terraform which deploys several AWS services including DynamoDB, AWS SQS, Lambdas, CodeBuild, CodePipeline, and State Machines. These perform the automations which create and customize the AWS accounts requested through AFT.
Exploring AWS Control Tower’s Architecture & GitHub Resources
The whole solution is open sourced on GitHub so you can pry through all the individual resources if you’re so curious. For a visual overview check out their provisioning workflow diagram.
How to Implement AWS Control Tower and AFT
The details of how to best implement AWS Control Tower and AFT are going to depend on the use-case. We’ll explain this at a high-level so that anyone familiar with AWS can grok it. AWS provides more in-depth documentation. Basically it consists of four steps, including provisioning your first accounts:
1. Create a Control Tower landing zone
Creating a landing zone is super simple when done through the console. This is a one-time task when setting up AFT and the console walks you through it. The only gotcha I ran into was that AWS Config needed to be disabled because Control Tower takes control (haha) of that service going forward.
So far all the instances of Control Tower we’ve deployed are into existing AWS Organizations with existing separation of concerns. For the most use-cases the AWS recommendations are good so don’t be afraid to click through and accept all the defaults.
AWS recently released APIs to create Landing Zones and they have documentation for doing this with the CLI. For most organizations creating the Control Tower Landing Zone is a one-time operation so there is low ROI from automating this process.
2. Create / modify the AFT repos
Creating the AFT repos is a little more involved, a lot more technical, and not strictly necessary because AFT will create these repos in CodeCommit if you don’t create them yourself. We created them along with most of our other code, on GitHub. AFT uses four repos stored in the same repo as the main module. These are for:
You may be asking, as I did, “How does AWS get access to our private repos in GitHub?” Setting up the GitHub to AWS connection involves creating an “AWS CodeConnections” which is on the developer tools (the same console as CodeCommit) console under settings. It gets created in the next step when we launch AFT.
Launch AFT
The AFT root module will deploy all the resources necessary to set up the AFT app. Just apply it to the Account Factory account which was created during the Control Tower setup. The best high-level explanation of the machinations underlying this application is the diagram on the AFT Architecture page. We created a bespoke repository to maintain the AFT configuration but given that the aft-account-provisioning-customizations repo runs against the same account I wonder if you could get away with applying out of that repo and then migrating state to the correct place after the initial apply to prevent the resources from getting duplicated. That’s a little meta and more a curiosity than something useful.
module "control_tower_account_factory" { source = "aws-ia/control_tower_account_factory/aws" version = "1.11.1" # Configuration Vars aft_feature_delete_default_vpcs_enabled = true aft_metrics_reporting = false aft_vpc_endpoints = false cloudwatch_log_group_retention = 365 ct_home_region = "us-east-1" # VCS Config account_customizations_repo_branch = "master" account_customizations_repo_name = "rhythmictech/rhythmictech-aft-account-customizations" account_provisioning_customizations_repo_branch = "master" account_provisioning_customizations_repo_name = "rhythmictech/rhythmictech-aft-account-provisioning-customizations" account_request_repo_branch = "master" account_request_repo_name = "rhythmictech/rhythmictech-aft-account-request" global_customizations_repo_branch = "master" global_customizations_repo_name = "rhythmictech/rhythmictech-aft-global-customizations" vcs_provider = "github" # Account IDs aft_management_account_id = "0123456789" audit_account_id = "9012345678" ct_management_account_id = "8901234567" log_archive_account_id = "7890123456" }
Why Use AWS Control Tower and AFT for Multi-Account Setup
AWS is recommending customers use a multi-account setup. This isn’t just for the large companies anymore, but for small and medium sized companies that want to use accounts to separate concerns and reduce the risk of security breaches to an infrastructure account. The drawback is this distributed setup can lead to configuration divergence and resource sprawl. AFT standardizes this process so that you can request a fully-formed account with a few lines of code (example below). Then it automates account creation along with maintaining configuration. Having all the resources defined with Infrastructure As Code (IAC) allows systems administrators control. Not only is the IAC itself auditable but Control Tower provides guardrails to prevent undesirable divergence and unwanted resources from being created.
Here’s an example for creating a “data warehouse” account with the aft requests repo:
module "datawarehouse_uat" { source = "./modules/aft-account-request" account_customizations_name = "workload" account_tags = { "env" = "infra" "vended" = "true" "managed_by" = "ct-terraform" } change_management_parameters = { change_requested_by = "Nevets Kcalb" change_reason = "creating data warehouse account" } control_tower_parameters = { AccountEmail = "aws-dwhuat@example.com" AccountName = "aws-example-dwhuat" ManagedOrganizationalUnit = "Data Warehouse (ou-gon2-getit)" SSOUserEmail = "tatertotlover@hotmail.com" SSOUserFirstName = "Nevets" SSOUserLastName = "Kcalb" } custom_fields = { environment = "uat" namespace = "workload" tfassume_account_id = 0123456789 tfassume_external_id = "rofljk+lolol" vpc_availability_zones = "[\"us-east-1a\", \"us-east-1b\", \"us-east-1c\"]" vpc_cidr = "10.186.160.0/20" vpc_public_subnets = "[\"10.186.160.0/24\", \"10.186.161.0/24\", \"10.186.162.0/24\"]" vpc_private_subnets = "[\"10.186.164.0/23\", \"10.186.166.0/23\", \"10.186.168.0/23\"]" } }
This example was really used to provision an entire AWS account complete with a CloudTrail, SSO, and a VPC attached to a central transit gateway. It’s been slightly modified to protect anonymity.
Alternative to AFT: The Service Catalog Approach
While we’ve focused here on AFT as our recommended implementation method, it’s worth acknowledging that AWS Control Tower offers another approach through its native Service Catalog. The Service Catalog method is often integrated with IT Service Management (ITSM) systems or helpdesks, allowing non-technical staff to create accounts through established request workflows. This can be advantageous in environments with formalized IT processes or where account creation needs to be handled by operations teams rather than developers. However, we generally prefer AFT for its DevOps-oriented approach, infrastructure-as-code capabilities, and better alignment with how modern cloud-native organizations operate. For small and medium businesses (SMBs) without complex ITSM requirements, AFT typically offers a more flexible and automation-friendly solution that scales better with your growing cloud environment.
Real-World Impact
AFT transforms AWS account management from a manual, error-prone process into a streamlined, code-based workflow. Organizations gain operational consistency across accounts while reducing administration overhead. The solution scales efficiently from small business deployments to enterprise environments. As multi-account architectures become standard practice, AFT provides the automation foundation that makes compliance, security, and resource management practical for teams of any size.
When to Cloud, How to Cloud Matters More Than Simply Being There
Listen to the podcast or keep scrolling to read Cristopher Daniluk's blog post...
Your organization’s infrastructure decisions should align with your business realities, not just industry hype. That said, let’s be clear: the cloud should be your default choice for most workloads. Its scalability, flexibility, and access to cutting-edge services make it the best option for the vast majority of modern businesses. On-premises or dedicated infrastructure? That’s the exception, not the rule. High-profile “cloud exits” like Basecamp’s departure from AWS in June 2023 don’t disprove this. They underscore the need for intentional cloud adoption tailored to specific needs. For most, the cloud is a strategic game-changer, not just a tool.
When to Cloud: Making Strategic Decisions
The cloud isn’t a coin toss against on-premises, it’s the starting point. Its ability to scale dynamically, reach globally, and deliver managed services outpaces traditional infrastructure for most use cases. Still, there are exceptions where on-premises or dedicated setups shine. Here’s how to think about it:
For example, if you’re running a predictable, high-performance workload—like a trading platform needing constant max throughput—and you’ve got the capital and team to optimize it, on-premises might work. But for most workloads (think variable demand, growth potential, or customer-facing apps), the cloud’s elasticity and services win every time. Basecamp’s move off AWS for their HEY email service? A rare case of stable, predictable usage better suited to dedicated hardware—not a signal to ditch the cloud.
Security: Not a Cloud Dealbreaker
Security concerns, like protecting PHI or banking data, don’t rule out the cloud. Modern providers offer compliance-ready solutions (e.g., HIPAA, PCI DSS) with thoughtful controls like encryption, access management, and audit logging. The catch? It’s easier to mess up, especially for smaller firms with lean teams. Misconfigured permissions or overlooked best practices can expose vulnerabilities. But that’s not a cloud flaw. It’s a design and expertise issue. With proper planning, the cloud is as secure as (or more secure than) on-premises setups.
Costs: Manageable with Discipline
Cloud costs can spiral—oversized instances, idle resources, or unchecked data transfers can sting. Smaller firms, with less margin for error, feel this acutely. But here’s the truth: escalating costs reflect poor management, not a problem with the cloud itself. Design systems to leverage auto-scaling, monitor usage, and follow best practices (more on that later), and the cloud becomes predictable and often cheaper than maintaining hardware.
When to Cloud: TCO Calculation Model
A solid Total Cost of Ownership (TCO) analysis proves the cloud’s edge. Look beyond sticker prices:
Run 3-year and 5-year models with growth scenarios. For most, the cloud’s flexibility and lower operational overhead outweigh initial costs. Smaller firms might hesitate at training expenses, but the payoff in agility and reduced CapEx is worth it.
When to Cloud: Industry Fit
The cloud adapts to every sector. Manufacturers with IoT needs, banks with compliance rules, retailers with seasonal spikes, and governments with tight budgets. All can thrive in the cloud. Even regulated industries benefit from compliance-ready offerings. Hybrid setups (cloud + on-premises) make sense for sensitive workloads, but they’re not the default. Use them only when regulations or legacy systems demand it.
How to Cloud: Building Your Foundation
Before migrating, set up:
This ensures governance, skills, and security. For smaller firms, start lean—focus on security and cost tracking first.
A phased approach builds confidence and cuts risks—crucial for resource-strapped teams.
How to Cloud: Optimization and Operations
Keep the cloud humming:
Smaller firms can lean on provider tools (e.g., AWS Cost Explorer) to stay on track.
How to Cloud: Managing Risk
Mitigate risks:
Cloud reliability is stellar (e.g., S3’s 11-nines durability), but smart planning adds peace of mind.
How to Cloud: The Human Element
Cloud success needs people onboard:
Resistance to cloud migration is natural. Address it by creating cross-functional cloud champions, implementing “paired migration” approaches where traditional and cloud teams work side-by-side, and demonstrating early wins with metrics that matter to specific stakeholder groups.
Smaller firms can tap cloud champions and free provider training to bridge gaps.
How to Cloud: Emerging Tech
Boost your cloud with:
These amplify the cloud’s value, even for lean teams.
The Path Forward
The cloud is your default for a reason. Use on-premises only when it’s unavoidable. It’s not about trends; it’s about strategy. With thoughtful design, even smaller firms can harness its power securely and cost-effectively. Success comes from understanding that cloud is a tool to be wielded skillfully, not a destination in itself. The future isn’t about leaving or staying in the cloud. It’s about using it wisely. That’s where we step in.
Rhythmic On the Go
Kathie Kinde Clark is back at HQ2 on May 19th. If you'd like to meet with Kathie while she's in DC, just reach out! Around the corner, look for us at the AWS DC Summit in June and the AWS New York Summit in July. We're planning something that will make a splash in New York. More to come!
Rhythmic in the Community
Rhythmic Technologies runs several AWS User Groups and assists in planning AWS Community days.
Find this information valuable? Please subscribe and share!