NOTE: https://github.com/aws-ia/terraform-aws-control_tower_account_factory.git

The Account Factory for Terraform (AFT) is organized into multiple Terraform modules that together automate and manage AWS Control Tower account provisioning. These modules have dependencies on each other, so you must deploy them in a certain order.

---

1. Packaging Module

• What it does:
  Packages Lambda functions and other artifacts into archives (zipped files), preparing them for deployment.

• Why first?
  Other modules need the file paths and hash values from these archives to deploy Lambdas correctly.

• Key detail:
  It generates and uploads artifacts (Lambda code, etc.) used downstream.

---

2. Account Request Framework

• What it does:
  Manages requests for new AWS accounts, including:

  • DynamoDB tables (state storage)

  • SQS queues and SNS topics (messaging)

  • VPC setup for network isolation

• Dependencies:
  Needs artifact info from Packaging.

• Why now?
  Sets the core infrastructure for handling account requests.

---

3. Lambda Layer Module

• What it does:
  Creates shared Lambda layers (libraries) used by provisioning and customization Lambdas.

• Dependencies:
  Uses KMS keys (encryption), VPC info, and archives from previous modules.

• Why now?
  Lambdas in later modules depend on this shared layer for code reuse and size reduction.

---

4. Account Provisioning Framework

• What it does:
  Contains Step Functions and Lambdas that automate provisioning new AWS accounts from requests.

• Dependencies:
  Requires SNS topics, KMS keys, Lambda layers, and archives from earlier modules.

• Why now?
  This module is the engine that actually creates accounts.

---

5. Backend Infrastructure

• What it does:
  Sets up S3 buckets and DynamoDB tables to store Terraform state and other persistent data.

• Dependencies:
  Independent, but needed by many modules to save state/configuration.

• Why now?
  Needs to be available early for modules that store their state remotely.

---

6. Code Repositories

• What it does:
  Creates/configures code repos (e.g., AWS CodeCommit) for storing provisioning/customization code.

• Dependencies:
  Needs VPC info and backend storage from previous modules.

• Why now?
  Provides the place where account customization code lives.

---

7. Customizations

• What it does:
  Manages pipelines and orchestration for customizing accounts (post-provisioning).

• Dependencies:
  Requires backend, provisioning framework, and code repos.

• Why now?
  Runs after accounts are provisioned to customize them.

---

8. Feature Options

• What it does:
  Enables optional features like CloudTrail data events, support enrollment, VPC deletion.

• Dependencies:
  Depends on frameworks and Lambda layers.

• Why now?
  Deployed after core provisioning and customizations are ready.

---

9. IAM Roles

• What it does:
  Defines IAM roles used for cross-account access and internal permissions.

• Dependencies:
  Depends on the setup of foundational accounts.

• Why now?
  Deploys after foundational modules/accounts are ready to assign roles securely.

---

10. SSM Parameters

• What it does:
  Stores configuration and metadata in AWS Systems Manager Parameter Store.

• Dependencies:
  Uses outputs from nearly all other modules.

• Why last?
  Collects all config and metadata after everything else is deployed.

---

How This Maps to the GitHub Repo (https://github.com/aws-ia/terraform-aws-control_tower_account_factory)

The GitHub repo is the official AWS-provided Terraform module for Control Tower Account Factory, which contains all these submodules and their logic.

• The modules/aft-archives corresponds to your Packaging Module.

• The modules/aft-account-request-framework is the Account Request Framework.

• aft-lambda-layer, aft-account-provisioning-framework, and others exactly match your deployment plan.

• The repo README and docs explain usage and dependencies between these modules.

• Each module folder in the repo contains Terraform code to deploy the specific resources mentioned in your plan.

---

Summary — Why This Order Matters

• Packaging artifacts must exist before any Lambda functions can be deployed.

• Account request infrastructure (queues, tables) is foundational for managing lifecycle.

• Shared Lambda layers must be ready before Lambdas depending on them are deployed.

• Backend storage (S3/DynamoDB) must be ready early for state management.

• Code repos and customizations come after core provisioning to allow customization pipelines.

• IAM roles and SSM parameters are finalized last to secure access and centralize config.