Enterprise AWS account governance using Control Tower: automated account vending, preventive and detective guardrails, and a scalable multi-account foundation.
2–4 weeks
$18k–$40k
AWS Control Tower is an orchestration layer over several AWS services — AWS Organizations (account structure and SCPs), AWS IAM Identity Center (formerly SSO), AWS Config (compliance rules), AWS CloudTrail (audit logging), and AWS Service Catalog (account vending). It does not replace these services; it configures and coordinates them according to AWS best practices codified into a Landing Zone.
When you enable Control Tower, it creates the Landing Zone: a structured account hierarchy with a Management account, a Security OU containing Log Archive and Audit accounts, and guardrails applied consistently across your OUs. The Log Archive account receives immutable CloudTrail and Config logs from all accounts. The Audit account hosts Config aggregation and cross-account read access for security tooling.
Managing AWS Organizations manually gives you flexibility but requires significant operational investment: you must build account vending automation yourself, write and maintain SCPs, configure CloudTrail and Config in each account, and ensure consistency across the environment. This works for small teams with strong platform engineering resources.
Control Tower is the right choice when you want AWS to manage the orchestration — consistent guardrail enforcement, automatic CloudTrail configuration in new accounts, integrated SSO, and a governed account vending workflow. The trade-off is that Control Tower has opinions: you cannot arbitrarily deviate from the Landing Zone structure, and customizing beyond the standard guardrails requires CfCT or AFT.
The Control Tower Landing Zone creates a specific OU structure:
Root → Management OU: the management account — billing, organization-level policies, no workloads
Root → Security OU: Log Archive (immutable centralized logs) and Audit accounts — do not add workloads
Root → Infrastructure OU: shared services — network hub (Transit Gateway), shared DNS, CI/CD infrastructure
Root → Sandbox OU: developer experimentation with relaxed guardrails
Root → Workloads OU: production and non-production application accounts
Root → Suspended OU: closed accounts awaiting deletion
The native Account Factory in Control Tower uses AWS Service Catalog to provision accounts through a web form. This works but is limited: customizations are applied via CloudFormation StackSets, there is no code review process for new accounts, and the configuration is not version-controlled.
Account Factory for Terraform (AFT) is the recommended approach for most enterprise environments. AFT is an open-source Terraform module that creates a GitOps pipeline for account vending — you define a new account as a Terraform resource in a Git repository, merge the PR, and a CodePipeline pipeline provisions the account, applies your account customizations, and enrolls it in Control Tower. Account creation takes 20–40 minutes from PR merge to fully operational account.
AFT separates concerns cleanly: account requests (which accounts exist, their names, emails, OU placement) and account customizations (what infrastructure is deployed into every account — baseline VPC, security tooling, IAM roles, etc.). Global customizations run in every account; account-specific customizations allow individual accounts to differ where needed.
CfCT is a separate mechanism for deploying CloudFormation StackSets or SCPs to specific OUs or accounts within your landing zone. It is complementary to AFT — AFT handles account creation and initial customization; CfCT handles ongoing customization of existing accounts at the OU level. Use CfCT for cross-account security tooling deployment (GuardDuty master enrollment, Security Hub aggregation, Macie configuration).
Control Tower ships with three categories of guardrails:
Preventive guardrails (SCPs): enforced at the API level. When a request violates a preventive guardrail, the API call is blocked before it executes. Mandatory preventive guardrails cannot be disabled. Strongly recommended and elective guardrails can be opted out per OU.
Detective guardrails (AWS Config rules): detect non-compliant configurations after the fact. When a resource violates a detective guardrail, a finding is generated. Mandatory detective guardrails run in every account.
Control Tower ships with over 300 optional guardrails covering everything from S3 bucket public access to EC2 security group configuration to RDS encryption. We curate and apply a guardrail library appropriate to your security requirements during the engagement.
Control Tower creates an IAM Identity Center instance and a directory. We integrate this with your existing identity provider (Okta, Azure AD, Google Workspace) using SAML/SCIM, so your existing groups and users are synchronized into Identity Center. Permission Sets define what each team can do in each account — developers get read-only prod access and admin dev access; security team gets read-only across all accounts.
AFT pipeline with account request and customization repositories
Guardrail library configured for your security posture
Identity Center connected to your IdP with permission sets per team
Account customization pipeline: VPC baseline, security tooling, IAM roles
Runbooks for account vending, guardrail management, and drift remediation
Control Tower upgrade procedure documentation
Tell us about your current environment and goals. We'll review the details and respond with a proposed engagement structure and timeline.
Typical response time: 1–2 business days.
Prices and timelines are estimates for typical engagements, not offers. Scope, price and terms are set in a written agreement after we understand your situation. Terms of use.