AFT Integration Patterns - When AWS Automation Actually Works

If you've ever manually created AWS accounts in an enterprise environment, you know the pain: 47 different console screens, endless IAM configuration, networking setup that breaks mysteriously, and 2-3 days of your life you'll never get back. AFT exists to solve this nightmare.

AFT combines AWS Control Tower with Terraform to automate the mind-numbing process of manually setting up AWS accounts. Takes about 20-30 minutes to provision an account versus the 1-2 day nightmare of doing it manually through the console. That's assuming your Control Tower setup isn't fucked and your IAM roles actually work on the first try (they won't).

How AFT Actually Works (When It's Not Broken)

AFT runs in a dedicated management account separate from your Control Tower management account. This is critical because mixing them will cause permissions nightmares that'll make you question your career choices. The separation means you need to manage IAM trust relationships between multiple accounts, which is where 80% of your initial setup pain comes from.

The AFT framework uses CodePipeline, Step Functions, and DynamoDB under the hood. Every account request starts with a Terraform file in Git that triggers the pipeline. When it works, it's beautiful. When it breaks, you'll spend hours digging through CloudFormation stack failures wondering why AWSAFTExecution role can't assume AWSControlTowerExecution role even though the trust policy looks correct.

The AFT architecture follows a strict workflow: account request submission, validation, provisioning, global customizations, and targeted customizations. Each stage has its own failure modes that the troubleshooting guide barely covers.

ITSM Integration - Making ServiceNow Suck Less

Most enterprises want AFT to play nice with their ticketing systems. You can build wrapper APIs around the aft-account-request module to translate ServiceNow requests into Terraform JSON without some poor DevOps engineer copy-pasting ticket details into HCL files at 2am. The AFT account customization examples repo shows how to build these integrations properly.

The AFT Blueprints project has pre-built templates for common setups - networking, DNS, backups, the usual shit. The blueprints are actually pretty decent and will save you from reinventing VPC patterns for the 47th time. The AFT Blueprints documentation explains how to implement these patterns, but don't expect them to work perfectly in your environment without customization. The getting started guide covers the basics, though you'll need to adapt everything for your specific requirements.

Version Control Integration - What Actually Works

AFT works with CodeCommit (boring but reliable), GitHub (everyone uses it), Bitbucket (if you're stuck in Atlassian hell), and GitHub Enterprise through CodeConnections.

CodeCommit integration is rock solid because it's AWS-native. GitHub works great until their webhooks randomly decide to take a vacation - usually shows up as CodePipeline execution failed: Unable to access the repository. Please verify the source location and try again even though the repo is fine and webhook events are being delivered. The webhook troubleshooting guide explains why they fail so often but doesn't mention that GitHub's webhook delivery attempts timeout after 10 seconds, which isn't enough if your AFT pipeline is busy.

Bitbucket... well, it's Bitbucket. Works fine if you're already paying Atlassian's enterprise tax for everything else.

If you're using Terraform Cloud or Enterprise, AFT plays nice with managed state through their APIs. Just be ready to pay HashiCorp's licensing fees, which will make your CFO cry. The Terraform Cloud integration guide covers the technical details.

Customizations That Actually Matter

AFT has two types of customizations: global (applies to every account, can't be bypassed) and account-specific (optional per account). Global customizations are perfect for security policies that developers will try to disable if you let them. Account-specific customizations handle things like prod accounts needing hardened networking while dev accounts just need basic connectivity.

The customizations deploy during account creation, which is nice until one fails and leaves you with a half-configured account that's annoying to fix. The account customization options explain the different types available.

The aft_enable_vpc Parameter - AKA The Money Pit

Setting aft_enable_vpc to true puts AFT resources in a VPC with NAT Gateways, VPC endpoints, and all the expensive networking shit. Costs about $200-300/month for basic setups, but scales fast. For 100+ accounts, you're looking at $1000+/month just for the AFT pipeline infrastructure.

The VPC mode adds security by keeping AFT traffic internal to AWS, but most organizations can live without it initially. NAT Gateway charges alone run $45/month per AZ, plus data processing fees. VPC endpoints for S3, CodeCommit, and other services add another $100-200/month. The math gets ugly fast.

If you're on a budget, set it to false and accept the slightly reduced security posture. Your accountants will thank you when the AWS bill doesn't bankrupt the company. You can always enable VPC mode later when the CFO stops asking why the account creation tool costs more than some developer salaries.

Prerequisites That Will Bite You

AFT needs Control Tower working first, which is its own special hell if you have an existing AWS Organizations setup. Control Tower assumes you're starting with a perfect green-field setup and gets angry about pre-existing accounts, OUs, and Service Control Policies. The Control Tower prerequisites list every way your existing setup can break the deployment.

You need the AWSAFTExecution and AWSAFTService IAM roles configured correctly between accounts. The role setup documentation makes it look simple, but trust relationships fail silently. When AFT can't assume roles, it just says "Access Denied" without explaining which specific permission is fucked. The IAM troubleshooting guide has the error patterns you'll see at 3am.

GitOps Workflow - When It Doesn't Break

You commit account request files to Git, AFT detects the change, triggers CodePipeline, and provisions the account. Simple in theory, painful in practice. The AFT GitOps workflow explains the process, but doesn't cover where it breaks.

The pipeline validates Terraform syntax first, which catches obvious typos. Then it checks policy compliance, which fails if your OU structure doesn't match what the request expects. Resource dependency validation comes last and will catch circular dependencies that aren't obvious from reading the HCL. The pipeline troubleshooting guide covers common failures.

Common failure: Account names with spaces break everything silently. The pipeline succeeds but creates accounts with fucked-up names that don't match your naming convention. The account naming requirements are buried in the Organizations documentation.

State Management - Where Dreams Go to Die

AFT uses S3 for Terraform state and DynamoDB for locking. Works fine until someone manually fucks with the state files or the S3 bucket versioning isn't enabled. Then you get state corruption with errors like Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed and have to manually reconcile Terraform state with actual AWS resources, which is about as fun as debugging Lambda functions at 3am.

Pro tip I learned the hard way: if you're using AFT v1.9.2 or earlier, the DynamoDB table doesn't have point-in-time recovery enabled by default. Found this out after a region outage corrupted our lock table and we lost 3 days rebuilding state files from CloudFormation diffs.

Multi-region deployments add complexity because each region needs its own customizations. The state files multiply across regions and accounts. Budget time for S3 cross-region replication setup if you care about disaster recovery, because losing AFT state files means rebuilding your entire account management system from scratch. The multi-region AFT guide covers the complexity you're signing up for.

SCP Integration - Because Developers Need Guardrails

AFT applies Service Control Policies based on which OU you put the account in. Sandbox accounts get loose policies for experimentation. Production accounts get locked down harder than Fort Knox. The integration works well until someone moves an account to a different OU and breaks all the applications because the new SCPs block APIs they were using. The SCP best practices guide explains how to avoid these disasters.

Monitoring - Good Luck Finding the Real Error

AFT generates a shit-ton of logs through CloudTrail, Config, and CloudWatch. The problem is finding the actual error message in the 10,000-line CloudFormation failure dump when things break. AFT customization failures often show up as "Step Functions execution failed" without any useful details about what actually went wrong.

Pro tip: Set up custom CloudWatch alarms for pipeline failures. The default logging is useless for debugging at 2am when someone's emergency account request is stuck. The CloudWatch Logs Insights queries can help filter through the noise.

Security - Don't Fuck This Up

The AFT management account needs privileged access to create accounts and assume roles everywhere. If someone compromises this account, they own your entire AWS org. Lock it down with MFA, IP restrictions, and separate it from your daily operations accounts.

The cross-account role assumptions use time-limited STS tokens, which is good. But the roles themselves are persistent and broadly scoped, which is scary. Audit the role permissions regularly because privilege creep is real. The IAM security best practices guide covers what you need to monitor.

Troubleshooting - Welcome to Hell

Common issues that will ruin your day:

• Terraform state drift when someone manually modifies AFT-managed resources
• Customization failures that leave accounts half-configured
• GitHub webhook failures that silently stop triggering pipelines
• IAM permission changes that break existing account requests

Real talk: we had AFT v1.8.1 running perfectly for 4 months until AWS updated the Control Tower API and suddenly all account requests started failing with InvalidParameterValueException: Invalid OU Id even though the OU IDs hadn't changed. Took 2 weeks and an AWS support case to figure out they changed how OU paths resolve in the background.

AFT module updates break shit randomly. Test in a sandbox environment first, not in production where your CFO is waiting for that new account to deploy the revenue-generating application. The AFT versioning strategy shows what changed between versions, but doesn't warn you what will break.

The Reality Check - Is AFT Worth It?

After implementing AFT in production and dealing with all this complexity, here's the honest assessment: AFT saves you massive amounts of manual work once you get through the initial pain. The 2-3 month implementation timeline is real, but so is the 30-minute account provisioning afterward.

Budget $200-1000/month for the infrastructure, plan for debugging at 3am when things break, and accept that you'll curse AWS's error messages regularly. But when it works, it's fucking magical watching accounts spin up automatically with proper networking, security, and monitoring already configured.

Start simple, test everything in sandbox, and gradually add complexity only when you need it. The alternative is manually clicking through the AWS console for years, and that's a special kind of hell nobody deserves.