AWS Control Tower is the standard starting point for enterprise-scale multi-account AWS environments — and for government workloads, it provides a structured foundation that aligns with federal cloud security requirements. This article examines how Control Tower works, how it maps to government use cases, and where its guardrails provide genuine security value vs. where custom controls are required.
What AWS Control Tower Provides
AWS Control Tower automates the setup of a multi-account AWS environment called a landing zone. The landing zone includes:
- Management account — Root account; used only for billing and Control Tower management
- Log archive account — Centralized, immutable logging from all accounts (CloudTrail, Config, S3 access logs)
- Audit account — Security tooling and cross-account read access for security reviews
- Organizational units (OUs) — Logical groupings of accounts by workload, classification level, or environment
When a new AWS account is needed, Control Tower's Account Factory creates it using a standardized account template — applying approved configurations, service control policies, and guardrail compliance automatically. This "account vending" capability is one of Control Tower's most valuable features in government environments where new project accounts need to be provisioned rapidly while maintaining consistent security baselines.
Guardrails: Preventive and Detective Controls
Control Tower implements two types of guardrails — security controls applied across all accounts in the landing zone:
Preventive guardrails (implemented via Service Control Policies / SCPs): Enforce security configurations that cannot be overridden at the account level. Examples: - Prohibit disabling CloudTrail in any account - Disallow deletion of the log archive bucket - Restrict root user access - Prevent public access to S3 buckets across all accounts
Detective guardrails (implemented via AWS Config Rules): Monitor for compliance deviations and generate findings in AWS Security Hub. Examples: - Flag EC2 instances without IMDSv2 enabled - Detect unencrypted EBS volumes - Alert on IAM users with console access and no MFA
For government workloads, the Control Tower guardrail set provides a starting point but is not sufficient for full FedRAMP Moderate or High compliance on its own. Agencies and contractors must layer additional controls from the NIST 800-53 control catalog that are not addressed by Control Tower's standard guardrail set.
Control Tower and FedRAMP Alignment
AWS GovCloud (US-East and US-West regions) hosts FedRAMP High-authorized AWS services. AWS Control Tower is available in AWS GovCloud and is itself FedRAMP authorized. Deploying Control Tower in GovCloud provides the combination of: - Physical data sovereignty within US government regions - FedRAMP-inherited controls from AWS's own ATO - Account-level governance through Control Tower's guardrail framework
A control mapping exercise against the applicable NIST 800-53 baseline — typically performed during FedRAMP System Security Plan development — identifies which controls are inherited from AWS, which require customer implementation, and which are shared responsibility. Control Tower covers a meaningful subset of AC (Access Control), AU (Audit and Accountability), and CM (Configuration Management) control families.
Account Structure Patterns for Government Programs
Multi-award, multi-task-order programs benefit from a specific account structure that isolates each contract's resources while sharing security infrastructure:
Management OU
├── Management Account
├── Log Archive Account
└── Audit Account
Workload OU
├── Program Alpha - Production
├── Program Alpha - Non-Production
├── Program Beta - Production
└── Shared Services - Production
Service Control Policies at the OU level enforce classification-specific restrictions — for example, restricting GovCloud-only services at the Workload OU level ensures no regulated data reaches commercial regions even from misconfigured workloads.
Limitations and Common Gaps
Control Tower does not manage data classification: Applying data classification tags, encryption key policies, and DLP controls for Controlled Unclassified Information (CUI) or Personally Identifiable Information (PII) requires additional tooling on top of Control Tower.
External IdP integration requires customization: Government programs using CAC/PIV-based authentication through a SAML 2.0 identity provider require IAM Identity Center configuration that is not fully automated by Control Tower's standard account vending.
Custom SCPs for specific agency requirements: Many government programs have agency-specific configuration standards (DISA STIGs, agency Concept of Operations requirements) that require custom SCPs beyond Control Tower's default set.
Customizations hook: Control Tower's customization mechanism (CfCT — Customizations for Control Tower) allows organizations to apply custom CloudFormation stacks and SCPs to accounts at vending time. This is the right mechanism for adding agency-specific controls to the standard landing zone.
When to Use Control Tower vs. Custom Landing Zone
Control Tower is the right choice when: - The program is starting from scratch and speed of delivery matters - The program expects to grow to 10+ accounts over the contract period - The account governance team wants a managed, AWS-maintained foundation
A custom landing zone (Terraform or CDK-managed) may be preferable when: - Complex existing account structures need integration that Control Tower can't easily adopt - Agency requires specific SCP structures that conflict with Control Tower's assumptions - The program has unique multi-region requirements that exceed Control Tower's current multi-region support
For most new government cloud programs, starting with Control Tower and extending it through CfCT is the most pragmatic approach — it provides an auditable, consistent foundation that scales with the program.
Rutagon provides cloud architecture and DevSecOps advisory services for government and defense programs. Contact us to discuss your cloud governance requirements.
Frequently Asked Questions
Is AWS Control Tower FedRAMP authorized?
Yes. AWS Control Tower is available in AWS GovCloud and carries FedRAMP High authorization through AWS's own FedRAMP package. Deploying Control Tower in GovCloud provides the combination of data sovereignty, FedRAMP-inherited controls, and account-level governance appropriate for federal workloads.
Can Control Tower be used for ITAR-controlled programs?
AWS GovCloud regions have specific features for ITAR-controlled workloads, including restricted access and US-person administration requirements. Control Tower itself is a governance framework that runs in GovCloud. ITAR program requirements go beyond what Control Tower provides — they include personnel security, access controls, data handling procedures, and compliance documentation that exist outside the cloud infrastructure layer.
How does Control Tower handle account deletion and retirement?
Account retirement in Control Tower involves moving an account out of the managed OU structure and handling data retention from the log archive. Control Tower does not automate account deletion — it provides a framework for account lifecycle management that organizations extend with their own retirement procedures. AWS recommends closing accounts rather than leaving them in a suspended state to avoid ongoing billing.
Does Control Tower work with Terraform?
Yes. The Customizations for AWS Control Tower (CfCT) solution can deploy Terraform-based configurations to accounts provisioned through Control Tower. Additionally, Terraform can manage the Control Tower landing zone configuration itself using the AWS Control Tower module in the Terraform AWS provider.