Scaling Landing Zone Customizations on AWS

2 May, 2025

By Masoom Tulsiani, Cloud Solution Architect, Rackspace Technology

Introduction

As organizations adopt multi-account strategies to support cloud workloads at scale, platform engineering teams are under increasing pressure to automate account provisioning while meeting security and compliance needs. AWS Control Tower helps by providing a consistent landing zone architecture with built-in guardrails — but for many teams, the need to scale custom configurations across accounts calls for a more flexible, infrastructure-as-code approach.

That’s where AWS Control Tower Account Factory for Terraform (AFT) comes in.

AFT enables platform teams to manage account provisioning and customization using Terraform, bringing automation and GitOps workflows to AWS Control Tower environments. Whether you need to integrate external identity providers, provision custom VPCs, or apply security controls across dozens — or hundreds — of AWS accounts, AFT offers a structured and scalable way to meet those needs without sacrificing governance.

This blog explores how AFT and the Landing Zone Accelerator (LZA) can help you scale AWS landing zone customizations, avoid the pitfalls of ad hoc approaches, and build a compliant, extensible foundation for your organization’s cloud architecture.

Understanding the challenge: Scaling customizations in AWS Control Tower

While AWS Control Tower provides a strong foundation for multi-account environments, scaling beyond the out-of-the-box configuration can present challenges. As individual teams require specific networking, security, or identity features, platform engineers often struggle to strike a balance between flexibility and standardization.

Common areas of customization

Enterprise landing zones often require changes in one or more of the following categories:

Identity and access management (IAM): Integration with external identity providers, custom permission sets, and fine-grained role policies.
Security and compliance: Additional security tooling, encryption standards, and custom Service Control Policies (SCPs).
Networking: Custom VPC configurations, IP addressing schemes, Transit Gateway usage, and centralized firewall rules.
Logging and governance: Tailored AWS Config rules, CloudTrail configurations, resource tagging strategies, and preapproved product catalogs.

Trade-offs between flexibility and control

Customizing a landing zone to meet enterprise requirements often means diverging from AWS-provided blueprints and guardrails. While necessary, this introduces several risks:

Fragmented implementations: Bespoke configurations increase complexity and make future upgrades or audits more difficult.
Inconsistent policies across accounts: Without centralized enforcement, security and governance policies can drift.
Operational overhead: Manually implementing or managing customizations across accounts is error-prone and time-consuming.

Organizations in regulated industries face additional pressure to align custom configurations with compliance frameworks like HIPAA, PCI-DSS or GDPR. This makes automation, repeatability, and visibility critical in any landing zone customization strategy.

Solution overview: Automating account provisioning with AFT

AWS Control Tower Account Factory for Terraform (AFT) helps platform teams automate account provisioning and customization workflows using Terraform. AFT operates from a dedicated management account and follows a GitOps-based model — enabling account creation, tagging, and customization based on code changes in version control.

Here’s how the AFT pipeline works:

Account request submission – Requests are pushed to a version-controlled repository and ingested by the pipeline in a first-in, first-out manner.
Account provisioning – AFT provisions each account within the AWS Control Tower management account, including required metadata and IAM roles.
Global customizations – A customization pipeline applies standard Terraform configurations to all provisioned accounts.
Targeted customizations – For accounts with specific configuration needs, AFT can apply scoped changes based on the request parameters. (Note: for existing accounts, customization must be manually initiated.)

Key features of AFT

Infrastructure-as-code provisioning of AWS accounts
GitOps-driven workflows integrated with AWS CodePipeline
Automated tagging and metadata storage
Support for both global and account-specific customizations
Audit and tracing built in via DynamoDB and AWS Step Functions
Partial support for importing existing Control Tower accounts

This automation not only accelerates the onboarding of new accounts but also enforces consistency, traceability, and policy compliance across your cloud environment.

Choosing the right landing zone customization framework

In addition to AFT, AWS offers other tools for extending and customizing Control Tower environments — most notably the Landing Zone Accelerator (LZA) and Customizations for AWS Control Tower (CfCT). Each solution has different strengths depending on your organization’s scale, compliance requirements, and preferred tooling.

Here’s a high-level comparison:

AFT limitations to keep in mind

While AFT offers strong automation and customization benefits, it also comes with some caveats:

Deprovisioning is not natively supported — removing an account from the pipeline doesn't fully clean up resources.
SSO user assignment is mandatory during provisioning.
External IdP integration requires additional customization effort.
Account creation is asynchronous — workflows pause until provisioning is complete.
Existing pipelines or landing zone tools must be retired before switching to AFT.
SSO permission sets for new accounts require custom automation (no built-in support yet).

A closer look at AFT architecture

To support automated account provisioning and customization, AWS Control Tower Account Factory for Terraform (AFT) deploys several AWS-native services as part of its architecture. These resources are managed from a dedicated AFT management account and follow a modular, event-driven design that integrates tightly with AWS CodePipeline, DynamoDB, Step Functions and IAM.

At the core of the solution is a Terraform-based GitOps pipeline that detects changes in version control, triggers provisioning workflows, and applies customizations based on repository structure and input parameters.

Core roles and accounts

AFT relies on multiple IAM roles across accounts to securely orchestrate provisioning and customization:

AWSAFTAdmin: Deployed in the AFT management account, this role allows the pipeline to assume other AFT roles and coordinate cross-account operations.
AWSAFTService: Handles actions related to the provisioning of new AWS accounts.
AWSAFTExecution: Created within each provisioned account. This role grants AFT permission to apply Terraform-based customizations and access the Account Factory portfolio.

The AWSAFTAdmin role is central to cross-account orchestration. It assumes the AWSAFTExecution role in target accounts — including the audit, log archive, and member accounts — to perform customization actions and apply configuration baselines.

The diagram below illustrates how these roles interact across management, audit, log archive, and member accounts within an AWS Control Tower environment:

How CodePipeline integrates with Terraform and DynamoDB

The AWS CodePipeline created by AFT monitors version-controlled repositories for changes to account request and customization configurations. When a change is detected — such as the creation of a new account request — the pipeline launches a CodeBuild job that applies the corresponding Terraform configuration.

As part of this process, AFT generates a DynamoDB item containing the account specification and metadata. This enables AFT to track and audit provisioning activity, and to apply consistent configurations across environments.

One example is the aft-global-customizations-terraform project, which includes a backend.tf file to configure remote state management for Terraform using S3 and DynamoDB. This ensures reliable state locking and secure storage of infrastructure definitions during global customization deployments.

Example: backend.tf configuration used by CodeBuild in the AFT global customizations project:

AFT customization through modular repositories

AFT uses a modular approach to automation, relying on a set of Git-backed repositories that map to different stages of the account lifecycle. These repositories are monitored by AWS CodePipeline and used to automate both provisioning and customization workflows.

Key AFT module repositories

aft-account-request: This repository is the entry point for provisioning. It contains the configuration files that define new AWS account requests, including metadata such as OU placement, tags and customization parameters.
aft-global-customizations: Used to define Terraform or Python-based resources that should be deployed across all accounts provisioned through AFT. This ensures a consistent baseline configuration for security, networking or compliance tooling.
aft-account-customizations: This repository enables targeted customizations for individual accounts. Custom behavior is triggered based on the account_customizations_name parameter specified in the account request, allowing for per-account variations (e.g., sandbox vs. production).
aft-account-provisioning-customizations: Focused on customizing the provisioning pipeline itself, this repository defines logic executed by AWS Step Functions during account creation. It supports integration with external systems via AWS Lambda, ECS, or Fargate, and can communicate with other systems through Amazon SNS or SQS for more advanced orchestration.

Together, these modules give platform teams fine-grained control over how AWS accounts are created, configured, and governed — all within a fully automated, version-controlled environment.

AFT Pipeline

Step-by-step account automation inside the AFT pipeline

Once a new account request is submitted via the aft-account-request repository, the AFT pipeline automates every step of the provisioning and customization process. This ensures that each account is delivered in a consistent, secure, and fully compliant state — ready to support your organization’s AWS workloads.

AFT pipeline stages

Validate the account request
The pipeline checks that input parameters meet required formatting and governance policies before provisioning begins.
Retrieve account metadata
Once the account is created, AFT captures key details — such as the AWS account ID — for use in downstream automation.
Store metadata in DynamoDB
Account data is written to a DynamoDB table in the AFT management account, supporting traceability and auditability.
Create the AWSAFTExecution IAM role
This role is deployed into the new account, giving AFT the necessary permissions to perform customizations and access the Account Factory portfolio.
Apply account tags
Tags defined in the request — such as environment, owner, or cost center — are applied to support governance and billing visibility.
Apply AFT feature options
Default configuration options set during AFT deployment (e.g., deleting default VPCs, enabling CloudTrail data events) are applied to the new account.
Run provisioning customizations
A Step Functions state machine triggers a Terraform workflow from the aft-account-provisioning-customizations repository. These infrastructure definitions are applied during provisioning to meet specific configuration requirements.
Create an account-level customization pipeline
A dedicated AWS CodePipeline is generated for each new account to support further global or targeted customizations.
Invoke the account customizations pipeline
Additional configurations — such as IAM policies, VPCs, security tooling, or SCPs — are applied through the pipeline defined in aft-account-customizations.
Send success or failure notifications
A notification is published to an Amazon SNS topic, indicating whether the account provisioning and customization process completed successfully or encountered issues.

By automating these ten steps, AFT delivers an end-to-end pipeline that streamlines AWS account creation while maintaining compliance with Control Tower guardrails and organizational standards.

Step functions for orchestrating the provisioning workflow

As part of the AFT pipeline, AWS Step Functions plays a critical role in coordinating the account provisioning process. The state machine acts as the orchestration engine for sequential tasks such as role creation, tagging, customization, and pipeline setup.

Each step in the state machine corresponds to a distinct operation in the lifecycle of a newly provisioned AWS account. This structured flow makes the AFT framework more resilient, auditable, and modular.

The image below illustrates the state machine architecture used by the aft-account-provisioning pipeline:

State machine workflow overview

Validate account request input
Ensures all required parameters are present and conform to policy.
Retrieve account details
Captures the new account’s metadata, including the account ID.
Store metadata in DynamoDB
Writes account information to the AFT management account’s DynamoDB table.
Create AWSAFTExecution IAM role
Deploys the role in the new account, enabling AFT to perform customizations.
Apply account tags
Adds metadata tags for identification, billing, and automation.
Apply feature options
Activates any feature flags defined during AFT setup (e.g., VPC removal, CloudTrail data events).
Run provisioning customizations
Executes the customization logic defined in the provisioning framework repository.
Create CodePipeline for customizations
Spins up a dedicated pipeline for post-provisioning configurations.
Invoke the customization pipeline
Triggers targeted infrastructure, security, or governance tasks.
Send SNS notification
Publishes a success or failure message to an SNS topic for status monitoring.

This state machine-driven model makes AFT a robust and scalable solution for managing account provisioning at enterprise scale.

DynamoDB tables used by AFT

As part of the AFT deployment, five DynamoDB tables are created in the AFT management account. These tables store metadata, track account provisioning requests and support the automation and auditability of AFT workflows.

Below are the core DynamoDB tables associated with AFT:

==> Go to aft-request table -> Click on Export and streams

This contains the lambda functions that get triggered when update comes to the DynamoDB tables.

Triggers are used to invoke Lambda function every time a DD item is changed.

The Triggers are:

aft-account-request-action-trigger - actual implementation of new accounts

aft-account-request-audit-trigger – prepares audit

SQS

The below SQS queues (Type: FIFO) are created as part of aft-account-request:

Step Functions

Below shows the state machine of the aft-account-provisioning framework.

AFT Customizations

AWS Control Tower Account Factory for Terraform (AFT) natively supports both global and account-specific customizations, facilitating the automated creation and management of baseline AWS resources for accounts provisioned or imported into AFT. During the pipeline execution process, Terraform providers are dynamically instantiated for each account via a Jinja template, ensuring the application of both global and account-specific configurations in a streamlined and consistent manner.

Customizing the AWS Account Created via AFT After deploying a new account using AFT, you can implement customizations to meet your organization's specific requirements. AFT supports the following customization capabilities:

Custom Configuration Templates:
- Define custom templates that apply specific IAM roles, service control policies (SCPs), or security configurations to the newly created accounts.
Terraform Modules for Custom Resources:
- Create additional Terraform modules to provision resources such as VPCs, EC2 instances, and S3 buckets within the newly created account.
Automated Compliance and Governance Policies:
- Leverage AFT’s integration with AWS Control Tower to enforce security best practices, applying preventive or detective controls through guardrails and SCPs.
Post-Provisioning Automation:

Customize the post-provisioning process to include operational tasks such as account tagging, logging configurations, or CloudFormation stack deployments. These tasks can be automated using Terraform scripts as part of your AFT pipeline.

AFT Customization: IAM Role & Policies

You can include custom IAM roles and policies in the aft-account-customizations repository.

Example: To include a custom IAM policy, place it in the following relative path:
aft-account-customizations/<environment>/terraform/iam.tf

AFT customization – VPC

The AFT module includes an aft_enable_vpc parameter that determines whether AWS Control Tower provisions account resources within a VPC in the AFT management account. By default, this parameter is set to true.

If set to false, AFT is deployed without creating private networking resources such as NAT Gateways or VPC endpoints.

You can create a custom VPC as part of account-specific customizations by placing the Terraform configuration in the following relative path:
aft-account-customizations/SANDBOX/terraform/vpc.tf

AFT IAM roles for SSO

AWSAFTAdmin – Created during AFT deployment in the AFT management account.
The aft-account-provisioning pipeline uses this role to assume the AWSAFTExecution role in the management account and attach a permission set to an existing AWS SSO group.

An iam.tf file supports this behavior using the following Terraform resources:

aws_ssoadmin_account_assignment
aws_ssoadmin_permission_set_inline_policy

These resources reference the ARN of the target SSO group.

Example: AWS IAM Identity Center configuration with Terraform

The example below shows how to configure AWS IAM Identity Center using Terraform, including the creation of permission sets and attachment of inline policies.

Some customers require the ability to attach permission sets to newly vended AWS accounts as part of the account provisioning process.

The diagram below illustrates a customer use case that shows how a custom permission set is attached to an existing SSO group during account creation via the AFT aft-account-provisioning workflow.

This solution manages the attachment of permission sets to an SSO group as part of both the AFT provisioning and customization stages.
It uses the following Terraform resources:
- aws_ssoadmin_account_assignment
- aws_ssoadmin_permission_set_inline_policy

For more details, see the Terraform Registry documentation.

AFT IAM roles for SSO integration

AWSAFTAdmin – Created during AFT deployment in the AFT management account.
The aft-account-provisioning pipeline uses this role to assume the AWSAFTExecution role in the management account and attach a permission set to an existing AWS SSO group.

This setup is defined in an iam.tf file using the following Terraform resources:

aws_ssoadmin_account_assignment
aws_ssoadmin_permission_set_inline_policy

These resources reference the ARN of the SSO group to complete the assignment.

Workflow sequence for SSO permission set attachment

The aft-account-request pipeline is triggered when a new account request is submitted.
Next, the aft-account-provisioning pipeline runs, using an AWS Step Functions state machine to manage the provisioning workflow.
During provisioning, the pipeline uses the AWSAFTAdmin role to assume the AWSAFTExecution role in the management account and attach a permission set to the existing AWS SSO group.

This process is defined in the iam.tf file using the following Terraform resources:

aws_ssoadmin_account_assignment
aws_ssoadmin_permission_set_inline_policy

These reference the ARN of the target SSO group.

Integration with Microsoft Entra ID

AFT also supports SSO configurations that integrate with external identity providers such as Microsoft Entra ID (formerly Azure AD).

Implementation Strategy

Setting Up AWS Control Tower Account Factory for Terraform (AFT)

To set up AFT in your AWS environment, start by creating a main.tf file that calls the AFT module. This module streamlines the provisioning and customization of AWS accounts within Control Tower, ensuring a consistent and automated infrastructure‐as‐code process.

You'll need to provide six essential parameters when configuring the module:

ct_management_account_id: The ID of your AWS Control Tower management account.
log_archive_account_id: The ID of your Log Archive account.
audit_account_id: The ID of your Audit account.
aft_management_account_id: The ID of your AFT management account.
ct_home_region: The AWS Region where AWS Control Tower is deployed.
tf_backend_secondary_region: The secondary region for backend replication.

Optional parameters include:

terraform_distribution (default: open-source Terraform)
vcs_provider (default: AWS CodeCommit)

These options can be customized to match your environment requirements.

CloudFormation template for AWSControlTowerExecution role

The example below shows a CloudFormation template used to configure the AWSControlTowerExecution IAM role in a target account. This enables the management account to assume the role via AWS STS during stack set operations:

Prerequisites for enrolling existing accounts into AWS Control Tower

Before enrolling existing AWS accounts (such as Audit or Log Archive accounts) into Control Tower, you must ensure that AWS Config is fully cleaned up. This prevents conflicts during the setup of Control Tower–managed trails and guardrails.

AWS Config overview

AWS Config uses a configuration recorder to track changes in resource configurations. A configuration recorder must be active before AWS Config can log resource changes. Each AWS Region in an account supports a single recorder and delivery channel.

Steps to prepare existing accounts:

Disable AWS Config
If the account has existing AWS Config resources, they must be fully removed before enrollment.
Delete the existing configuration recorder and delivery channel
This step ensures that Control Tower can create and manage its own trails without interference.

Use the AWS CLI to delete the default configuration recorder:

bash

CopyEdit

aws configservice delete-configuration-recorder --configuration-recorder-name default

In each region (e.g., eu-central-1), delete the following:

Default configuration recorder (Control Tower will create a new one)
Default delivery channel

For example, PowerShell users can use Remove-CFGConfigurationRecorder to delete the recorder. After deletion, AWS stops tracking configuration changes, but previously recorded data can still be accessed using Get-ResourceConfigHistory. Note that historical data will no longer be visible in the AWS Config console.

More details can be found in the Control Tower troubleshooting guide.

Additional resources and guidance

For more detailed instructions on stopping AWS Config and cleaning up existing resources, refer to the official AWS documentation:

Important notes:

After deleting the configuration recorder, AWS stops recording configuration changes — but previously recorded data is retained. You can still retrieve this historical data using the Get-ResourceConfigHistory cmdlet, though it will no longer be available via the AWS Config console.
To delete a delivery channel using PowerShell, you must first stop the configuration recorder. Use Stop-CFGConfigurationRecorder before running Remove-CFGDeliveryChannel.

Example: Check and delete existing delivery channels

Use the AWS CLI or PowerShell to list and remove any existing delivery channels prior to Control Tower enrollment. This ensures there are no conflicts when Control Tower provisions its own configuration recorder and delivery channel.

Check if the delivery channel is deleted

Required IAM role and trust relationship

To enroll an existing AWS account into Control Tower, the account must already contain the AWSControlTowerExecution IAM role.

Before attempting enrollment, ensure the following role and trust relationship are configured in the target account:

Role name: AWSControlTowerExecution
Permissions: Attach the AWS managed policy AdministratorAccess
Trust relationship:
json

CopyEdit

{

"Version": "2012-10-17",

"Statement": [

    {

      "Effect": "Allow",

      "Principal": {

        "AWS": "arn:aws:iam::<Management Account ID>:root"

      },

      "Action": "sts:AssumeRole",

      "Condition": {}

    }

]

}

This trust relationship allows the Control Tower management account to assume the role and manage resources in the enrolled account.

For more information, refer to the official AWS documentation.

Required policy: AWSServiceCatalogEndUserFullAccess

To enroll accounts using the AWS Control Tower console, you must be signed in as a user (not the root account) with the following permissions:

AWSServiceCatalogEndUserFullAccess policy
Administrator access to use the AWS Control Tower console

Root user credentials are not supported for this operation.

Case study: Munster Technological University (MTU)

Munster Technological University (MTU) is one of Ireland’s most prestigious technical universities. It is leading innovation in quantum computing through the launch of QCloud — Ireland’s first quantum cloud computing environment. This project gives researchers access to quantum compute resources and helps accelerate scientific research across Ireland and beyond.

MTU partnered with Rackspace Technology to design and deploy a secure, scalable AWS infrastructure that supports the QCloud initiative.

Challenges

MTU needed a secure, cost-governed AWS Landing Zone to onboard multiple universities while supporting a wide range of quantum workloads. Key challenges included:

Designing a scalable AWS Landing Zone with granular IAM permissions
Supporting both EC2-based and AWS Braket–based quantum workloads
Enforcing project-level budget controls and account-level isolation

What Rackspace delivered

Rackspace designed and implemented a multi-OU Landing Zone using AWS Control Tower Account Factory for Terraform (AFT). The environment included account customization workflows, centralized cost control, and a runbook to manage provisioning for additional universities.

Delivered components included:

AWS Control Tower Landing Zone and AFT customization pipeline
Terraform runbook for AFT configuration and account onboarding
Budget-aware account provisioning with centralized cost tracking
Scalable, multi-account architecture supporting both EC2 and AWS Braket workloads

Outcomes

Enabled external university onboarding under GÉANT EU OCRE framework
Centralized user, cost, and infrastructure management for all participating institutions
Promoted national and international collaboration across research teams

______________________________________________________________________________

Best practices for AFT deployments

The following best practices can help you deploy, manage, and scale AFT-based landing zones more effectively:

Modularize Terraform configurations
Break up modules for account creation, customization, and governance.
Use version control for all code
Store Terraform configurations in Git to enable collaboration and auditability.
Adopt a GitOps workflow
Use Git as the source of truth and trigger pipelines from repository changes.
Define baseline configurations
Use AFT to enforce standards for IAM, security, and networking.
Implement least privilege access
Limit admin roles and policies to only what's needed.
Monitor and audit accounts
Enable AWS Config, CloudTrail, and GuardDuty for visibility and compliance.
Use the AFT account vending process
Automate new account provisioning with built-in policy enforcement.
Enforce a tagging strategy
Apply consistent resource and account tags for cost allocation and automation.
Secure state management
Store Terraform state in S3 with encryption and use DynamoDB for locking.
Automate account customizations
Use AFT pipelines to apply SCPs, StackSets, and environment-specific settings.
Implement CI/CD for Terraform
Validate and deploy changes automatically using CI/CD pipelines.
Manage account lifecycle
Automate account decommissioning and cleanup to minimize risk.
Use environment segmentation
Create separate accounts for dev, test, and prod to isolate workloads.
Turn off VPC endpoints when not needed
Reduce unnecessary costs by disabling unused VPC endpoints.
Delete existing AWS Config resources before enrollment

Remove configuration recorders and delivery channels via CLI to avoid conflicts.

Pricing considerations

Below is a sample of baseline AWS Control Tower–related costs for a customer environment using AFT in the eu-central-1 region. Actual costs will vary depending on your workload size, API activity, and account structure.

Sample monthly costs and resource usage

Amazon CloudWatch
- ~$0.03 total
- $0.0094 per 1,000 metrics requested (GetMetricData API)
AWS Service Catalog
- ~$0.09 (first 1,000 API calls are included in the free tier)
- Example: 1,200 API calls = $0.14
AWS Config
- 4,010 configuration items recorded = ~$9.84
- Rate: $0.00282 per item (Ireland region)
AWS CloudTrail
- ~$34 per month (with all regions enabled)
- $0.00002 per paid event
- Tip: Enable CloudTrail only in selected regions to reduce cost
- Example: 8,000 events = ~$0.16
NAT Gateways
- 2 public NAT Gateways in the AFT management VPC = ~$60/month
- AFT creates two default VPCs with NAT Gateway attachment
VPC Endpoints
- 24 PrivateLink endpoints created as part of the AFT management VPC
- Estimated cost: $175–$200/month
- 23 of these are interface-type endpoints
Amazon S3 (Terraform state and snapshots)
- Example usage: 119.2 MB (under the 1 GB free tier)
- Current cost: ~$0.02
AFT CodePipelines
- 3–4 pipelines (e.g., ct-aft-account-request, ct-aft-customization, ct-aft-account-provisioning-customizations)
- Total cost: ~$6/month
AWS KMS (encryption)
- 2 KMS keys used by AFT = ~$5/month
Amazon DynamoDB

5 tables in the AFT management/account factory account
Estimated cost: <$3 currently; up to ~$29/month if scaling to 1 GB

Current usage: <50 KB total, ~120 bytes per item on average

Streamlining account lifecycle management with AFT

AWS Control Tower Account Factory for Terraform (AFT) offers a powerful framework for organizations adopting Infrastructure as Code to manage AWS accounts at scale. It not only simplifies account provisioning but also supports advanced customization, automation, and policy enforcement — all within the guardrails of AWS Control Tower.

In this guide, you explored how to create new accounts using AFT and apply both global and account-level customizations. By integrating Terraform into the account lifecycle, organizations can build a more efficient, repeatable, and secure cloud foundation that supports growth without sacrificing governance.

Sources and references cited in this blog post:

https://aws.amazon.com/blogs/mt/deploy-and-customize-aws-accounts-using-account-factory-for-terraform-in-aws-control-tower/

https://docs.aws.amazon.com/config/latest/developerguide/stop-start-recorder.html

https://medium.com/cloud-native-daily/automate-aws-sso-using-terraform-2f219a45c16f

https://aws.amazon.com/blogs/mt/import-existing-aws-control-tower-accounts-to-account-factory-for-terraform/

https://docs.aws.amazon.com/controltower/latest/userguide/existing-config-resources.html

https://medium.com/cloud-native-daily/automate-aws-sso-using-terraform-2f219a45c16f