14.2 AWS Control Tower Landing Zone & Guardrail Framework

14.2 AWS Control Tower Landing Zone & Guardrail Framework

Establishing a secure, production-ready multi-account foundation requires coordinating multiple foundational services, directory integrations, and compliance mechanisms. Manually wiring together AWS Organizations, IAM Identity Center, AWS Config, and CloudTrail across dozens of accounts introduces human error and operational drift. AWS Control Tower provides an automated service wrapper that provisions and manages a compliant multi-account Landing Zone according to AWS best practices.

---

Landing Zone Architecture & Core Baseline

A Control Tower Landing Zone automatically configures an orchestrated organizational hierarchy with specialized core accounts, centralized identity access, and pre-configured audit trails.

Loading diagram...

Foundational Accounts in the Core OU

Control Tower sets up two foundational member accounts within a Core (or Foundational) Organizational Unit:

1. Log Archive Account: Functions as the central immutable clearinghouse for organizational telemetry. It contains dedicated Amazon S3 buckets that aggregate multi-Region CloudTrail logs and AWS Config configuration history from every account in the organization. S3 Object Lock, strict bucket policies, and cross-account access restrictions prevent any single account administrator from tampering with historical audit evidence.
2. Audit Account (Security Tooling Account): Serves as the operational hub for security operations center (SOC) analysts and compliance auditors. Control Tower automatically configures cross-account IAM roles granting read-only and remediation access into all member accounts from this account. It is the designated primary target for Delegated Administration of centralized security services.

---

Account Factory: Standardized Automated Account Vending

Account proliferation without automated governance creates security blind spots. Account Factory is the built-in account vending mechanism in AWS Control Tower. It standardizes account creation, network baselines, and security configurations across the enterprise.

How Account Factory Operates

Account Factory is delivered as an AWS Service Catalog product in the Management account:

• Self-Service Vending: Authorized teams invoke the Account Factory product via the AWS Service Catalog console, API, or automated CI/CD pipelines.
• Network Baselines: Account Factory automatically provisions a standardized VPC topology, specifies authorized CIDR blocks, creates public and private subnets, configures internet connectivity, and disables default VPCs across selected regions.
• Identity Integration: Automatically integrates the new account with IAM Identity Center, mapping administrative and developer permission sets to federated directory groups.
• Baseline Enrollment: Enrolls the account directly into the specified Organizational Unit, instantly inheriting all active guardrails and monitoring rules.

Extending Account Factory: CfCT and AFT

For enterprise infrastructure-as-code (IaC) governance, AWS provides two architectural extensions:

• Customizations for AWS Control Tower (CfCT): Uses AWS CodePipeline, AWS CodeCommit, and CloudFormation StackSets to deploy custom security baselines (such as custom IAM roles, default KMS keys, and endpoint monitors) across member accounts whenever a new account is vended or an OU is modified.
• Account Factory for Terraform (AFT): Enables platform engineering teams to define account vending and customization pipelines using Terraform. AFT provisions a dedicated pipeline architecture featuring an AFT management account, Git-driven workflow repositories, and DynamoDB state tracking.

---

Control Classifications: Guidance Levels

In AWS Control Tower, governance rules are formally termed Controls (formerly referred to as Guardrails). Control Tower classifies controls into three guidance categories:

---

Implementation Mechanisms: Preventive, Detective & Proactive

Control Tower implements governance controls through three distinct technical mechanisms across the resource lifecycle:

Loading diagram...

Comprehensive Mechanism Comparison

---

Proactive Governance via CloudFormation Hooks

A critical architectural innovation in modern landing zones is the adoption of Proactive Controls. In traditional environments, a developer might deploy an unencrypted Amazon S3 bucket via CloudFormation. A detective AWS Config rule evaluates the resource minutes later, flags it as non-compliant, and triggers a remediation Lambda function to encrypt the bucket or delete it. During that intervening window, unencrypted data may have already been written, creating a compliance breach.

CloudFormation Hooks intercept stack creation and update events in the deployment engine:

• When a stack operation begins, CloudFormation invokes registered proactive hooks at the preCreate or preUpdate lifecycle points.
• The hook evaluates the target resource configurations against defined compliance policies (such as verifying that BucketEncryption is enabled on AWS::S3::Bucket).
• If the configuration violates the policy, the hook returns a FAILURE status with a descriptive error message, causing CloudFormation to abort the stack operation and roll back before any cloud resource is instantiated.

Exam Tip: For the exam, recognize the lifecycle timing: Proactive controls stop non-compliant CloudFormation deployments before resources exist; Preventive controls block unauthorized API calls at execution time; Detective controls flag non-compliant resources after they are provisioned.

---

Managing Governance Drift & Baseline Re-Registration

Governance Drift occurs when the actual state of accounts, OUs, or guardrails within the organization diverges from the baseline configured by AWS Control Tower. Drift introduces hidden security exposures and audit non-compliance.

Common Sources of Drift

• Manual Policy Alteration: An administrator with Management account access directly edits or detaches a Control Tower SCP in the AWS Organizations console.
• Moved or Removed Member Account: An enrolled account is moved to another OU, or removed from the organization, in the Organizations console instead of through Control Tower.
• Deleted Control Tower Resources: A Control Tower role, OU (such as the Security OU), or control is deleted or changed from outside Control Tower. (Member-account users can't simply turn off the Config recorder, because mandatory controls deny changes to Control Tower's AWS Config and CloudTrail settings.)
• Landing Zone Version Lag: AWS releases updates to the Control Tower baseline that have not been applied to existing accounts.

Detecting and Remediating Drift

1. Console Visibility: Control Tower continuously audits organizational state and flags drifted components with a status of Drifted in the Landing Zone dashboard.
2. Re-registering an OU: When drift occurs at the OU level (for example, if member accounts within an OU lack mandatory SCPs or baseline roles), the administrator executes Re-register OU in the Control Tower console. This action reapplies all baseline configurations, provisions missing StackSets, and attaches mandatory guardrails across all accounts in that OU.
3. Updating the Account or Landing Zone: A moved account is fixed by updating it in Account Factory (or re-registering its OU). Landing-zone-level drift, such as a deleted Security OU account or role, is fixed with Reset or a landing zone update, which is also how you adopt new landing zone versions.

---

Specialty Exam Traps & Architectural Pitfalls

1. Relying Solely on Preventive Controls for Compliance Audits: Preventive controls (SCPs) prevent unauthorized API actions, but they cannot report on the compliance posture of existing resources created before the SCP was attached. True compliance requires Detective controls (AWS Config) to audit historical and current resource state.
2. Assuming Proactive Controls Block Direct AWS CLI Calls: CloudFormation Hooks only evaluate infrastructure deployed via AWS CloudFormation. If a developer uses the AWS CLI to execute aws s3api create-bucket, the proactive hook is completely bypassed. To block direct manual resource creation, organizations must enforce Preventive controls (SCPs) that restrict direct provisioning permissions.
3. Resolving Drift by Deleting Accounts: When Control Tower reports an account or OU as drifted, never delete or disassociate the account. The standard, non-destructive resolution is to use the Re-register OU or Enroll Account action in the Control Tower console.
4. Preventive Guardrail Immunity in the Management Account: Control Tower preventive guardrails (SCPs) do not apply to the Management account. If a workload is mistakenly deployed into the Management account, it will operate completely unconstrained by Control Tower preventive guardrails.