Table of Contents

• What Problems Organizations & Control Tower Solve
• AWS Organizations Fundamentals
• Service Control Policies (SCPs)
• AWS Control Tower
• Multi-Account Strategy
• Landing Zone Architecture
• Guardrails and Compliance
• Account Factory and Provisioning
• Cost Optimization Strategies
• Integration with Other AWS Services
• Migration and Adoption
• Common Pitfalls
• Key Takeaways

What Problems Organizations & Control Tower Solve

AWS Organizations and AWS Control Tower address critical challenges in managing multiple AWS accounts at enterprise scale.

Without Organizations & Control Tower

Account sprawl and governance gaps:

• Teams create AWS accounts independently without central visibility
• No consistent security policies across accounts
• Difficult to enforce compliance requirements
• Separate billing for each account complicates cost tracking
• No centralized audit logging or monitoring
• Security incidents spread across isolated accounts
• Manual account provisioning takes days or weeks

Real cost: A financial services company with 50 AWS accounts spent $180,000 annually on manual governance tasks (security reviews, compliance audits, account provisioning) and suffered a security breach when a development account with overly permissive IAM policies was compromised, exposing production data through cross-account roles.

With Organizations & Control Tower

Centralized governance and automated compliance:

• Single payer account: Consolidated billing across all accounts with volume discounts
• Organizational units (OUs): Hierarchical structure for grouping accounts by function, environment, or business unit
• Service control policies (SCPs): Centrally enforced guardrails that limit what actions are allowed in member accounts
• Control Tower landing zone: Pre-configured multi-account environment following AWS best practices
• Guardrails: Detective and preventive controls for continuous compliance
• Account Factory: Self-service account provisioning with governance baked in
• Centralized logging: CloudTrail and Config aggregated across all accounts
• Automated compliance: Continuous monitoring against AWS best practices and regulatory frameworks

Measured impact: The same financial services company migrated to Organizations and Control Tower, reducing governance overhead by 75% ($135,000 savings annually), cutting account provisioning time from 2 weeks to 1 hour, and achieving continuous compliance with SOC 2 and PCI-DSS requirements through automated guardrails.

Organizations and Control Tower provide the foundation for secure, scalable, well-governed multi-account AWS deployments.

AWS Organizations Fundamentals

AWS Organizations enables central management and governance of multiple AWS accounts from a single management account.

Core Concepts

Management account (formerly master account):

• Root of the organization
• Pays all charges for member accounts (consolidated billing)
• Has full administrative control over the organization
• Cannot have SCPs applied to it
• Should be used only for billing and organization management (not workloads)

Member accounts:

• Accounts that belong to the organization
• Can only belong to one organization at a time
• Subject to SCPs from parent OUs and the root
• Retain their own IAM policies and permissions
• Can be moved between OUs

Organizational units (OUs):

• Containers for accounts within the organization
• Can be nested up to 5 levels deep
• Inherit SCPs from parent OUs
• Enable policy-based management at scale
• Typically organized by environment (dev/test/prod), business unit, or compliance requirement

Root:

• Top-level container in the organization hierarchy
• Contains all accounts and OUs
• SCPs attached to root apply to all accounts (except management account)

Organization Structure Example

Root
├── Management Account (billing, organization admin)
├── Security OU
│   ├── Log Archive Account (centralized logging)
│   ├── Security Tooling Account (GuardDuty, Security Hub)
│   └── Audit Account (read-only access for auditors)
├── Infrastructure OU
│   ├── Network Account (Transit Gateway, VPCs)
│   └── Shared Services Account (DNS, AD, monitoring)
├── Workloads OU
│   ├── Production OU
│   │   ├── App1 Production Account
│   │   └── App2 Production Account
│   ├── Staging OU
│   │   └── Staging Account
│   └── Development OU
│       ├── Dev Team 1 Account
│       └── Dev Team 2 Account
└── Suspended OU (for decommissioned accounts)

Consolidated Billing Benefits

Volume discounts:

• Usage aggregated across all accounts
• Reach higher volume tiers faster for EC2, S3, data transfer
• Single Reserved Instance or Savings Plan pool shared across accounts

Example savings: Organization with 10 accounts averaging 500 GB S3 storage each:

• Without Organizations: Each account pays $0.023/GB (first 50 TB tier) = $115/month total
• With Organizations: 5,000 GB aggregated still in first tier but benefits from combined purchasing power for Reserved Instances and Savings Plans, reducing effective compute costs by 40-50%

Single invoice:

• One bill for all accounts
• Simplified payment processing
• Easier financial reporting and chargeback

Cost allocation tags:

• Consistent tagging across all accounts
• Cost and usage reports aggregated at organization level
• Detailed chargeback and showback capabilities

AWS Organizations Limits

Creating an Organization

Via AWS Console:

1. Navigate to AWS Organizations in management account
2. Click “Create organization”
3. Choose “All features” (recommended) or “Consolidated billing only”
4. Verify email address for management account
5. Create organizational units
6. Invite or create member accounts

Via AWS CLI:

# Create organization
aws organizations create-organization --feature-set ALL

# Create organizational unit
aws organizations create-organizational-unit \
  --parent-id r-xxxx \
  --name "Production"

# Create new account (faster than inviting)
aws organizations create-account \
  --email prod-app1@example.com \
  --account-name "App1 Production" \
  --role-name OrganizationAccountAccessRole

# Invite existing account
aws organizations invite-account-to-organization \
  --target-id 123456789012 \
  --notes "Invitation for dev account"

# Move account to OU
aws organizations move-account \
  --account-id 123456789012 \
  --source-parent-id r-xxxx \
  --destination-parent-id ou-xxxx-yyyyyyyy

Features vs. Consolidated Billing Only

All features (recommended):

• Service control policies (SCPs)
• Tag policies (enforce tagging standards)
• AI services opt-out policies
• Backup policies
• Access to AWS Control Tower
• Cannot be downgraded to consolidated billing only once enabled

Consolidated billing only (legacy):

• Only provides consolidated billing
• No SCPs or governance features
• Can be upgraded to all features
• Not recommended for new organizations

Service Control Policies (SCPs)

Service control policies are the primary mechanism for enforcing governance rules across accounts in an organization.

How SCPs Work

Permission boundaries at the account level:

• SCPs define the maximum permissions for accounts and OUs
• They don’t grant permissions; they filter what IAM policies can allow
• Explicit deny in SCP overrides any allow in IAM policies
• SCPs affect all users and roles in an account, including the root user
• Management account is not affected by SCPs

Evaluation logic:

Effective Permissions = IAM Permissions ∩ SCP Permissions

If SCP denies action OR IAM denies action:
  Result: Deny
Else if SCP allows action AND IAM allows action:
  Result: Allow
Else:
  Result: Deny (implicit deny)

Example: If an SCP on the Production OU denies ec2:TerminateInstances, no user in any production account can terminate instances, even if their IAM policy allows it.

SCP Strategies

Strategy 1: Deny list (default):

• Start with FullAWSAccess policy attached to root
• Add specific deny statements for prohibited actions
• Easier to start with, but can lead to policy sprawl
• Good for organizations with mature governance processes

Example deny list SCP (prevent leaving organization):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "organizations:LeaveOrganization"
      ],
      "Resource": "*"
    }
  ]
}

Strategy 2: Allow list (more secure):

• Remove FullAWSAccess from root
• Explicitly allow only required services and actions
• More restrictive and secure
• Requires careful planning and maintenance
• Recommended for highly regulated environments

Example allow list SCP (production accounts):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "rds:*",
        "lambda:*",
        "dynamodb:*",
        "cloudwatch:*",
        "logs:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "ec2:PurchaseReservedInstancesOffering",
        "ec2:ModifyReservedInstances",
        "rds:PurchaseReservedDBInstancesOffering"
      ],
      "Resource": "*"
    }
  ]
}

Common SCP Patterns

1. Region restriction (enforce data residency):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/OrganizationAccountAccessRole"
          ]
        }
      }
    }
  ]
}

2. Require encryption for S3 uploads:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": [
            "AES256",
            "aws:kms"
          ]
        }
      }
    }
  ]
}

3. Prevent disabling security services:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "config:DeleteConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "config:StopConfigurationRecorder",
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "securityhub:DisableSecurityHub",
        "securityhub:DeleteMembers"
      ],
      "Resource": "*"
    }
  ]
}

4. Prevent public S3 buckets:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketPublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "s3:BlockPublicAcls": "false",
          "s3:BlockPublicPolicy": "false",
          "s3:IgnorePublicAcls": "false",
          "s3:RestrictPublicBuckets": "false"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": [
        "s3:PutAccountPublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "s3:BlockPublicAcls": "false"
        }
      }
    }
  ]
}

5. Restrict instance types in non-production:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotLike": {
          "ec2:InstanceType": [
            "t3.*",
            "t3a.*",
            "t4g.*"
          ]
        }
      }
    }
  ]
}

SCP Inheritance

SCPs are inherited down the organization hierarchy:

Root (SCP: DenyRegionRestriction)
├── Production OU (SCP: DenyInstanceTermination)
│   └── App1 Prod Account
│       Effective SCPs: DenyRegionRestriction + DenyInstanceTermination
└── Development OU (SCP: AllowOnlyT3Instances)
    └── Dev Account
        Effective SCPs: DenyRegionRestriction + AllowOnlyT3Instances

Multiple SCPs: If multiple SCPs are attached to an account or OU, all must allow the action (logical AND). If any SCP denies, the action is denied.

Testing SCPs

IAM Policy Simulator:

• Test how SCPs affect IAM permissions
• Simulate actions before applying SCPs to production
• Accessible at https://policysim.aws.amazon.com

CloudTrail analysis:

• Review CloudTrail logs to identify API calls that would be blocked
• Test SCPs in development accounts first
• Monitor for unexpected denials after SCP deployment

Gradual rollout:

1. Apply SCP to test OU with single account
2. Monitor CloudTrail for denied actions
3. Refine SCP based on findings
4. Expand to additional OUs incrementally

AWS Control Tower

AWS Control Tower provides an automated landing zone based on AWS best practices, with built-in governance and compliance.

Control Tower vs. Organizations

When to use Control Tower:

• Starting fresh with multi-account AWS deployment
• Need automated compliance and governance
• Want AWS best practices applied by default
• Require self-service account provisioning
• Have compliance requirements (SOC 2, PCI-DSS, HIPAA)

When to use Organizations alone:

• Already have mature multi-account setup
• Need flexibility beyond Control Tower’s opinionated structure
• Have complex custom requirements
• Want to avoid Control Tower’s specific OU structure

Control Tower Architecture

Core accounts (created automatically):

1. Management account:
   • Billing and organization administration
   • Control Tower setup and management
   • Should not run workloads
2. Log Archive account:
   • Centralized CloudTrail logs from all accounts
   • Config logs and snapshots
   • Read-only access for compliance team
   • Retention policies enforced
3. Audit account:
   • Security Hub aggregator
   • GuardDuty delegated administrator
   • Config aggregator
   • Cross-account read-only access for security audits
   • SNS topics for compliance notifications

Default organizational units:

1. Security OU: Contains Log Archive and Audit accounts
2. Sandbox OU: For experimentation without strict guardrails (optional)
3. Custom OUs: Create additional OUs for Production, Staging, Development

Guardrails

Guardrails are governance rules implemented through SCPs (preventive) or AWS Config rules (detective).

Guardrail categories:

Preventive guardrails (SCPs):

• Block actions before they happen
• Enforce policies at the account level
• Cannot be bypassed
• Examples: Disallow public S3 buckets, restrict regions

Detective guardrails (Config rules):

• Monitor for non-compliant resources
• Alert but don’t prevent
• Provide compliance status
• Examples: Detect unencrypted EBS volumes, identify non-MFA root users

Example mandatory guardrails:

• Disallow changes to CloudTrail (preventive)
• Detect public read access to S3 buckets (detective)
• Disallow changes to AWS Config (preventive)
• Detect unencrypted EBS volumes (detective)
• Disallow internet access for the management account (preventive)

Example strongly recommended guardrails:

• Disallow public write access to S3 buckets (preventive)
• Detect MFA enabled for root user (detective)
• Enable encryption for EBS volumes (detective)
• Detect whether CloudTrail is enabled (detective)

Elective guardrails examples:

• Disallow specific AWS services (EC2, RDS instance types)
• Enforce encryption for specific services
• Restrict use of root user
• Require tags on resources

Guardrail Compliance States

Compliance dashboard: Control Tower provides a centralized view showing guardrail status across all accounts and OUs.

Account Factory

Account Factory enables self-service, automated account provisioning with governance controls.

Features:

• Standardized account baseline: Every account gets CloudTrail, Config, guardrails
• Network configuration: Automated VPC setup or integration with centralized network account
• SSO integration: Automatic user and permission set assignment
• Tagging: Consistent tags applied at creation
• Provisioning time: 20-30 minutes vs. days for manual setup

Account Factory workflow:

1. User requests account via Service Catalog
2. Selects OU (determines which guardrails apply)
3. Provides account name, email, network configuration
4. Control Tower creates account and applies baseline
5. Account appears in organization with full governance

Via AWS Service Catalog:

• Account Factory product available in Service Catalog
• Users with AWSServiceCatalogEndUserFullAccess can provision
• Approval workflows can be added

Via AWS CLI (Account Factory for Terraform - AFT):

# Using Account Factory for Terraform (AFT)
# Define account in Terraform

resource "aws_servicecatalog_provisioned_product" "new_account" {
  name                     = "app1-production"
  product_name            = "AWS Control Tower Account Factory"
  provisioning_artifact_name = "AWS Control Tower Account Factory"

  provisioning_parameters {
    key   = "AccountEmail"
    value = "app1-prod@example.com"
  }

  provisioning_parameters {
    key   = "AccountName"
    value = "App1 Production"
  }

  provisioning_parameters {
    key   = "ManagedOrganizationalUnit"
    value = "Production"
  }

  provisioning_parameters {
    key   = "SSOUserEmail"
    value = "admin@example.com"
  }

  provisioning_parameters {
    key   = "SSOUserFirstName"
    value = "Admin"
  }

  provisioning_parameters {
    key   = "SSOUserLastName"
    value = "User"
  }
}

Account Factory for Terraform (AFT)

AFT extends Account Factory with GitOps workflows and Terraform customization.

Benefits:

• Provision and customize accounts via Terraform
• GitOps workflow for account management
• Global customizations applied to all accounts
• Account-specific customizations via separate Terraform modules
• Pipeline automation with account vending

Architecture:

• AFT management account runs Step Functions pipeline
• Git repositories for account requests and customizations
• CodePipeline triggers on Git commits
• Terraform applies baseline and customizations
• Supports external Terraform modules

Use case: Organization needs to provision 50 accounts with custom networking (Transit Gateway attachments), tagging, IAM roles, and application-specific infrastructure. AFT automates this with version-controlled Terraform, reducing provisioning time from 2 days to 1 hour per account.

Multi-Account Strategy

Effective multi-account strategy balances isolation, governance, and operational efficiency.

Account Segmentation Patterns

1. Environment-based segmentation:

Root
├── Production OU
├── Staging OU
├── Development OU
└── Sandbox OU

Benefits: Clear environment separation, different guardrails per stage Drawbacks: Can lead to large numbers of accounts as applications scale

2. Application-based segmentation:

Root
├── App1 OU
│   ├── App1 Prod
│   ├── App1 Staging
│   └── App1 Dev
└── App2 OU
    ├── App2 Prod
    └── App2 Dev

Benefits: Application isolation, independent lifecycles Drawbacks: Difficult to enforce environment-level policies

3. Hybrid segmentation (recommended):

Root
├── Core OU
│   ├── Security OU (Log Archive, Audit)
│   └── Infrastructure OU (Network, Shared Services)
├── Workloads OU
│   ├── Production OU
│   │   ├── App1 Prod
│   │   └── App2 Prod
│   ├── Non-Production OU
│   │   ├── App1 Staging
│   │   ├── App1 Dev
│   │   └── App2 Dev
│   └── Sandbox OU (experimentation)
└── Suspended OU (decommissioned accounts)

Benefits: Combines environment and application isolation, flexible policy application Recommended for: Most enterprise deployments

Account Sizing Guidelines

When to use a separate account:

• Different compliance or regulatory requirements
• Different teams with separate ownership
• Separate billing or chargeback requirements
• Isolated blast radius needed (production vs. development)
• Independent lifecycle management

When to use the same account:

• Tightly coupled applications
• Shared resources needed (databases, caching layers)
• Same team owns all components
• Similar security and compliance requirements

Example: E-commerce platform:

• Production Account: Web application, API, database
• Data Analytics Account: Data warehouse, ETL jobs (separate for cost tracking)
• CI/CD Account: Build pipelines, artifact storage (shared across all apps)

Cross-Account Access Patterns

1. IAM cross-account roles (recommended):

// In target account (123456789012)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id"
        }
      }
    }
  ]
}

// In source account (987654321098), attach to user/role
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/CrossAccountRole"
    }
  ]
}

2. Resource-based policies (for services that support them):

// S3 bucket policy allowing cross-account access
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:role/DataProcessor"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::shared-bucket/*"
    }
  ]
}

3. AWS Resource Access Manager (RAM):

• Share resources like Transit Gateway, Route 53 Resolver rules, subnets
• No need for cross-account roles for supported resources
• Centralized management in network account

# Share Transit Gateway with entire organization
aws ram create-resource-share \
  --name "Shared-TGW" \
  --resource-arns "arn:aws:ec2:us-east-1:123456789012:transit-gateway/tgw-xxxx" \
  --principals "arn:aws:organizations::123456789012:organization/o-xxxx"

Landing Zone Architecture

A landing zone is a pre-configured, secure, multi-account AWS environment based on best practices.

Landing Zone Components

1. Identity and access management:

• AWS IAM Identity Center (SSO) for centralized authentication
• Permission sets for role-based access
• MFA enforcement
• Integration with corporate directory (Active Directory, Okta, etc.)

2. Logging and monitoring:

• CloudTrail: Organization trail in Log Archive account
• AWS Config: Aggregator in Audit account
• VPC Flow Logs: Centralized in Log Archive account
• CloudWatch Logs: Cross-account log aggregation
• S3 bucket: Encrypted, versioned, lifecycle policies

3. Security services:

• Security Hub: Aggregated findings in Audit account
• GuardDuty: Delegated administrator in Audit account
• AWS Config: Compliance monitoring with conformance packs
• Detective controls: Config rules for continuous compliance

4. Network architecture:

• Shared VPCs: Centralized network account owns VPCs
• Transit Gateway: Hub-and-spoke connectivity
• Route 53: Private hosted zones shared via RAM
• PrivateLink: Secure access to AWS services
• Network segmentation: Separate subnets for different environments

5. Governance:

• Service control policies: Preventive guardrails
• Tag policies: Enforce tagging standards
• Backup policies: Centralized backup rules
• SCPs for compliance: Region restrictions, encryption requirements

Network Design Patterns

Pattern 1: Centralized network with shared VPCs:

Network Account
├── Shared Production VPC (shared via RAM)
│   ├── Public Subnets (ALB, NAT Gateway)
│   ├── Private Subnets (application tier)
│   └── Data Subnets (databases)
├── Shared Non-Production VPC
└── Transit Gateway (connectivity hub)

Workload Accounts
├── App1 Production (uses shared Production VPC subnets)
└── App2 Production (uses shared Production VPC subnets)

Benefits: Centralized network management, reduced VPC sprawl, easier compliance Drawbacks: Tight coupling with network account, requires RAM sharing

Pattern 2: Distributed VPCs with Transit Gateway:

Network Account
├── Transit Gateway (connectivity hub)
├── Shared Services VPC (DNS, AD, monitoring)
└── Egress VPC (centralized internet egress)

Workload Accounts
├── App1 Production (own VPC, attached to TGW)
└── App2 Production (own VPC, attached to TGW)

Benefits: Application isolation, flexibility, independent network control Drawbacks: More VPCs to manage, potential IP overlap concerns

Pattern 3: Hybrid (recommended for most organizations):

• Shared Services VPC in network account (DNS, Active Directory, monitoring)
• Egress VPC for centralized internet access
• Application-specific VPCs in workload accounts
• Transit Gateway for connectivity
• VPC sharing for tightly coupled applications

Identity Center (SSO) Setup

AWS IAM Identity Center provides single sign-on access to multiple AWS accounts and applications.

Benefits:

• Centralized authentication: One set of credentials for all accounts
• Permission sets: Reusable role-based access templates
• MFA enforcement: Consistent security across accounts
• Integration: Supports external identity providers (Okta, Azure AD, Google Workspace)
• Temporary credentials: No long-lived access keys

Permission set example:

// AdministratorAccess permission set
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

// ReadOnlyAccess permission set
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "s3:List*",
        "s3:GetObject",
        "cloudformation:Describe*",
        "cloudwatch:Describe*",
        "logs:Describe*"
      ],
      "Resource": "*"
    }
  ]
}

Assignment pattern:

• Admin group → AdministratorAccess → Production OU (all accounts)
• Developer group → PowerUserAccess → Development OU
• Security Auditor group → ViewOnlyAccess → All accounts
• Finance group → BillingReadOnly → Management account

Session duration: Configure session duration (1-12 hours) based on security requirements. Shorter sessions (1-2 hours) for production, longer (8-12 hours) for development.

Cost Optimization Strategies

Organizations and Control Tower provide centralized cost management and optimization opportunities.

Consolidated Billing Benefits

Reserved Instances and Savings Plans sharing:

• RIs and Savings Plans purchased in any account apply to eligible usage across all accounts
• Optimization recommendations at organization level
• Example: Purchase Compute Savings Plan in management account, automatically applies to EC2 and Fargate in all accounts

Volume discounts:

• S3 storage aggregated across accounts for tiered pricing
• Data transfer pooled across accounts
• EBS snapshot storage combined

Example cost reduction:

• Scenario: 20 accounts, each with 100 GB S3 storage and 5 t3.medium EC2 instances
• Without Organizations: Each account pays standard on-demand rates
• With Organizations + Savings Plans:
  • 1-year Compute Savings Plan (72% discount on t3.medium)
  • Monthly savings: $2,800 (from $7,000 to $4,200)
  • Annual savings: $33,600

Cost Allocation and Chargeback

Cost allocation tags:

• Define tags like Environment, CostCenter, Application, Owner
• Activate tags in management account billing preferences
• Tags appear in Cost and Usage Reports

Tag policies (enforce tagging):

{
  "tags": {
    "Environment": {
      "tag_key": {
        "@@assign": "Environment"
      },
      "tag_value": {
        "@@assign": [
          "Production",
          "Staging",
          "Development",
          "Sandbox"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "s3:bucket",
          "rds:db"
        ]
      }
    },
    "CostCenter": {
      "tag_key": {
        "@@assign": "CostCenter"
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "s3:bucket"
        ]
      }
    }
  }
}

Cost and Usage Report (CUR):

• Enable in management account
• Export to S3 with Athena or QuickSight integration
• Query by account, tag, service, resource
• Build chargeback reports

Example Athena query (monthly cost by account and environment):

SELECT
  line_item_usage_account_id AS account,
  resource_tags_user_environment AS environment,
  SUM(line_item_unblended_cost) AS total_cost
FROM
  cur_database.cost_and_usage_report
WHERE
  year = '2025' AND month = '01'
GROUP BY
  line_item_usage_account_id,
  resource_tags_user_environment
ORDER BY
  total_cost DESC;

Control Tower Cost Optimization

Control Tower itself is free, but you pay for:

• AWS Config rules (per rule per region per account)
• CloudTrail logging (first trail free, additional trails charged)
• S3 storage for logs
• Lambda executions for customizations

Cost estimation for 10-account Control Tower deployment:

• AWS Config: ~$2/rule/region/account/month × 5 mandatory rules × 2 regions × 10 accounts = $200/month
• CloudTrail: Organization trail is free; S3 storage for logs ~$5/month
• S3 log storage: 100 GB × $0.023/GB = $2.30/month
• Total: ~$207/month for governance (offset by consolidated billing savings)

Optimization tips:

• Enable Config rules only in required regions
• Use detective guardrails selectively (each = Config rule)
• Lifecycle policies for log archival to Glacier ($0.004/GB)
• Disable elective guardrails not needed for compliance

Example savings: Organization reduced Config costs by 60% ($200 → $80/month) by:

1. Enabling Config only in 2 primary regions (us-east-1, us-west-2) instead of 6
2. Using only mandatory + strongly recommended guardrails (24 rules) instead of all elective (120+ rules)
3. Lifecycle policy moving logs >90 days to Glacier

Integration with Other AWS Services

Organizations and Control Tower integrate with AWS services for centralized management.

AWS CloudFormation StackSets

Deploy CloudFormation stacks across multiple accounts and regions from a central location.

Use cases:

• Deploy IAM roles for cross-account access
• Enable security services (GuardDuty, Security Hub)
• Configure logging and monitoring baselines
• Create VPC resources in all accounts

Example: Deploy CloudWatch log retention policy to all accounts:

# CloudFormation template
Resources:
  LogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: /aws/lambda/application-logs
      RetentionInDays: 30

# StackSet deployment
aws cloudformation create-stack-set \
  --stack-set-name "log-retention-policy" \
  --template-body file://log-retention.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false

aws cloudformation create-stack-instances \
  --stack-set-name "log-retention-policy" \
  --deployment-targets OrganizationalUnitIds=ou-xxxx-yyyyyyyy \
  --regions us-east-1 us-west-2

Auto-deployment: When enabled, StackSets automatically deploy to new accounts added to target OUs.

AWS Security Hub Integration

Security Hub aggregates findings from GuardDuty, Config, Inspector, and third-party tools.

Organization integration:

• Designate Audit account as Security Hub administrator
• Automatically enable Security Hub in new accounts
• Aggregate findings across all accounts
• Centralized compliance dashboard

Control Tower automation: Security Hub automatically enabled in Audit account with delegated administrator permissions.

AWS Systems Manager Integration

Parameter sharing across accounts:

• Share Systems Manager parameters across organization
• Centralize configuration values
• Update parameters once, available in all accounts

Session Manager:

• Connect to EC2 instances without SSH keys
• Audit all sessions via CloudTrail
• SCP can restrict Session Manager access by OU

AWS RAM (Resource Access Manager)

Share resources across accounts without duplicating them.

Shareable resources:

• VPC subnets (shared VPCs)
• Transit Gateway
• Route 53 Resolver rules
• License Manager configurations
• Aurora DB clusters
• CodeBuild projects
• EC2 Capacity Reservations
• Resource Groups

Example: Share Transit Gateway with entire organization:

aws ram create-resource-share \
  --name "Organization-TGW" \
  --resource-arns "arn:aws:ec2:us-east-1:123456789012:transit-gateway/tgw-xxxx" \
  --principals "arn:aws:organizations::123456789012:organization/o-xxxx" \
  --permission-arns "arn:aws:ram::aws:permission/AWSRAMDefaultPermissionTransitGateway"

Benefit: Central network team manages Transit Gateway in network account; application teams in workload accounts can attach VPCs without cross-account roles.

Migration and Adoption

Migrating existing AWS accounts to Organizations and Control Tower requires careful planning.

Migration Strategies

Strategy 1: Greenfield (new organization):

• Create fresh organization with Control Tower
• Migrate workloads from existing accounts to new accounts
• Decommission old accounts

Best for: Small number of accounts, simple architectures, willingness to rebuild Timeline: 1-3 months depending on workload complexity

Strategy 2: Brownfield (migrate existing accounts):

• Create organization and Control Tower in new management account
• Invite existing accounts to organization
• Apply Control Tower baseline via customizations

Best for: Large number of accounts, complex production workloads, minimize disruption Timeline: 3-6 months for large organizations

Strategy 3: Hybrid (gradual migration):

• Create organization with Control Tower
• Migrate non-production accounts first
• Create new accounts for greenfield projects
• Gradually migrate production workloads

Best for: Most organizations; balances risk and timeline Timeline: 6-12 months for enterprise-scale migrations

Migration Steps (Brownfield)

Phase 1: Planning (2-4 weeks):

1. Inventory existing accounts, resources, dependencies
2. Design target OU structure
3. Define guardrails and SCPs
4. Plan network architecture (Transit Gateway, shared VPCs)
5. Identify customizations needed
6. Create migration runbook

Phase 2: Pilot (4-6 weeks):

1. Create organization in new management account
2. Set up Control Tower
3. Invite 1-2 non-production accounts
4. Test SCPs and guardrails
5. Validate logging and monitoring
6. Document issues and refine approach

Phase 3: Non-Production Migration (8-12 weeks):

1. Invite remaining development and staging accounts
2. Apply SCPs gradually (monitor for impact)
3. Enable guardrails incrementally
4. Configure cross-account access
5. Migrate logging to Log Archive account
6. Validate security controls

Phase 4: Production Migration (12-16 weeks):

1. Migrate production accounts during maintenance windows
2. Test all functionality post-migration
3. Enable production SCPs and guardrails
4. Configure alerting and monitoring
5. Document operational procedures
6. Train teams on new workflows

Phase 5: Optimization (ongoing):

1. Review SCP effectiveness
2. Tune guardrails based on findings
3. Optimize costs with consolidated billing
4. Implement additional security controls
5. Automate account provisioning via Account Factory

Inviting Existing Accounts

Invitation process:

# From management account
aws organizations invite-account-to-organization \
  --target-id 123456789012 \
  --notes "Invitation to join organization for centralized governance"

# From target account
aws organizations accept-handshake \
  --handshake-id h-xxxx

Post-invitation steps:

1. Move account to appropriate OU
2. Apply SCPs (test in isolation first)
3. Enable Config, CloudTrail to Log Archive account
4. Register with Security Hub in Audit account
5. Update IAM roles for cross-account access
6. Configure network connectivity (VPC peering, Transit Gateway)

Control Tower Enrollment

Enrolling an existing account into Control Tower applies the baseline configuration.

What enrollment does:

• Creates AWSControlTowerExecution role in account
• Enables AWS Config
• Creates CloudTrail trail
• Applies guardrails from parent OU
• Adds account to Security Hub and GuardDuty in Audit account

Via AWS Console:

1. Navigate to Control Tower → Organization
2. Select account
3. Click “Enroll account”
4. Choose OU
5. Enrollment takes 20-30 minutes

Limitations:

• Account must not have existing Config recorder or delivery channel (must delete first)
• Existing CloudTrail trail may conflict (rename or delete)
• SCPs may block existing workloads (test carefully)

Rollback considerations: Unenrolling removes Control Tower management but doesn’t restore previous state. Plan carefully and test in non-production first.

Common Migration Challenges

1. Existing IAM roles conflict with Control Tower roles:

• Issue: Control Tower creates AWSControlTowerExecution role; may conflict with existing roles
• Solution: Rename or remove conflicting roles before enrollment

2. SCP blocks critical operations:

• Issue: Production workload uses API that’s denied by SCP
• Solution: Test SCPs in non-production; use CloudTrail to identify blocked calls; refine SCPs before production

3. CloudTrail conflicts:

• Issue: Existing CloudTrail trail with same S3 bucket
• Solution: Disable or rename existing trail; Control Tower creates organization trail

4. Config recorder conflicts:

• Issue: Existing Config recorder in account
• Solution: Delete existing recorder and delivery channel before enrollment

5. Cross-account access breaks:

• Issue: Existing cross-account roles rely on specific trust relationships
• Solution: Update trust policies to work within organization; use aws:PrincipalOrgID condition

6. Network architecture changes:

• Issue: Moving to centralized network model requires re-architecting
• Solution: Gradual migration; use Transit Gateway for hybrid connectivity during transition

Common Pitfalls

1. Management Account Misuse

Issue: Running workloads in the management account exposes billing and organizational controls to application risk.

Why it happens: Teams start with a single account and grow into multi-account without migrating workloads.

Impact:

• Security breach in workload can compromise entire organization
• Accidental deletion or misconfiguration affects all accounts
• Cannot apply SCPs to management account
• Difficult to isolate blast radius

Solution:

• Use management account only for billing and organization administration
• Move all workloads to member accounts
• Restrict access to management account (MFA, IP restrictions)
• Monitor CloudTrail in management account closely

Prevention: From day one, create separate accounts for workloads, even if starting small.

2. Overly Restrictive SCPs in Production

Issue: Deploying restrictive SCPs without testing blocks critical production operations.

Example: SCP denying ec2:ModifyInstanceAttribute prevents updating security groups on running instances, blocking routine operations.

Impact:

• Production incidents prolonged by inability to make changes
• Emergency exceptions create governance gaps
• Team frustration and SCP resistance

Solution:

• Test SCPs in development accounts first
• Use CloudTrail to identify API calls that would be blocked
• Start with deny list strategy (less restrictive)
• Implement SCPs gradually with monitoring period
• Document SCP exceptions process for emergencies

Prevention: Use IAM Policy Simulator and CloudTrail analysis before applying SCPs to production OUs.

3. Config Recorder Conflicts During Enrollment

Issue: Enrolling an account with existing Config recorder fails because Control Tower requires exclusive Config management.

Error message: “Account already has a Config recorder or delivery channel.”

Solution:

# Delete existing Config recorder before enrollment
aws configservice stop-configuration-recorder \
  --configuration-recorder-name default

aws configservice delete-delivery-channel \
  --delivery-channel-name default

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

Prevention: Document pre-enrollment checklist; automate cleanup with script.

4. Guardrail Costs Exceed Budget

Issue: Enabling all elective guardrails across many accounts and regions creates unexpectedly high AWS Config costs.

Example: Organization with 20 accounts, 4 regions, enabling 50 guardrails:

• Cost: 20 accounts × 4 regions × 50 Config rules × $2/rule/month = $8,000/month
• Budget shock: Expected $500/month for Control Tower

Solution:

• Enable only mandatory and strongly recommended guardrails (24 rules)
• Use detective guardrails selectively based on compliance requirements
• Enable Config only in primary regions (2-3 regions instead of all)
• Set up billing alerts before expanding guardrails
• Calculate Config costs before enabling elective guardrails

Prevention: Cost estimation during planning phase; phased guardrail rollout with cost monitoring.

5. Lack of Exception Process for SCPs

Issue: No documented process for handling SCP exceptions during incidents leads to chaos or governance bypasses.

Scenario: Production incident requires API call blocked by SCP. Team has no process to request temporary exception, leading to:

• Incident resolution delayed
• Unauthorized SCP modifications
• Permanent exceptions that weaken security posture

Solution:

• Document SCP exception process:
  1. Exception request template (business justification, duration, scope)
  2. Approval workflow (security team, compliance)
  3. Temporary exception implementation (time-limited SCP override)
  4. Post-incident review and exception removal
• Communicate process to all teams
• Track exceptions in ticketing system
• Regular review of exceptions (quarterly)

Prevention: Establish governance processes before deploying restrictive SCPs.

6. IAM Identity Center (SSO) Single Point of Failure

Issue: IAM Identity Center outage or misconfiguration locks users out of all accounts.

Impact:

• Cannot access AWS Console or CLI in any account
• Break-glass procedures not documented
• Incident response delayed

Solution:

• Create break-glass IAM users in critical accounts (management, production)
• Store credentials in secure vault (1Password, Keeper)
• Regularly test break-glass access (quarterly)
• Document emergency access procedures
• Set up CloudWatch alarm for Identity Center service issues

Break-glass user policy (MFA-protected, full access):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

Prevention: Establish break-glass procedures during Control Tower setup; test regularly.

7. Inadequate Log Retention and Analysis

Issue: Logs in Log Archive account fill S3 bucket without lifecycle policies, driving up costs and making analysis difficult.

Example: 20 accounts generating 500 GB CloudTrail logs per month:

• Year 1: 6 TB logs × $0.023/GB = $138/month
• Year 2: 12 TB logs × $0.023/GB = $276/month (no lifecycle policy)
• Querying massive log volume becomes slow and expensive

Solution:

• S3 lifecycle policy for Log Archive bucket:
  • Logs >90 days → Glacier ($0.004/GB) = 90% cost reduction
  • Logs >1 year → Glacier Deep Archive ($0.00099/GB) = 95% cost reduction
• CloudTrail Lake for queryable log storage (separate from S3 archive)
• Athena for ad-hoc log queries
• CloudWatch Logs Insights for real-time analysis

S3 lifecycle policy example:

{
  "Rules": [
    {
      "Id": "ArchiveOldLogs",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        },
        {
          "Days": 365,
          "StorageClass": "DEEP_ARCHIVE"
        }
      ]
    }
  ]
}

Prevention: Configure lifecycle policies during Log Archive account setup; monitor storage costs monthly.

8. Forgetting to Update OU Structure as Organization Grows

Issue: Initial OU structure doesn’t scale as organization adds teams, applications, and compliance requirements.

Example: Starting with flat structure:

Root
├── Production OU (50 accounts)
└── Development OU (30 accounts)

Problem: Cannot apply different policies to subsets of production or development accounts; everything gets same SCPs.

Solution:

• Plan for growth with nested OU structure from the start:

  Root
  ├── Core OU
  │   └── Security OU
  ├── Workloads OU
  │   ├── Production OU
  │   │   ├── High-Security OU (PCI-DSS accounts)
  │   │   └── Standard-Security OU
  │   └── Non-Production OU
  │       ├── Staging OU
  │       └── Development OU
  └── Sandbox OU
  

• Review OU structure quarterly
• Move accounts to appropriate OUs as requirements change
• Use nested OUs for policy inheritance flexibility

Prevention: Design OU hierarchy with future growth in mind; avoid flat structure.

Key Takeaways

AWS Organizations provides centralized multi-account management:

• Consolidated billing with volume discounts and cost allocation
• Service control policies (SCPs) for governance at scale
• Organizational units (OUs) for hierarchical policy management
• Centralized logging and security monitoring
• Foundation for Control Tower and advanced governance

AWS Control Tower automates landing zone setup:

• Pre-configured multi-account environment following AWS best practices
• Mandatory, strongly recommended, and elective guardrails for compliance
• Account Factory for self-service account provisioning with governance
• Centralized logging, monitoring, and compliance dashboard
• Integration with IAM Identity Center (SSO) for centralized access

Effective multi-account strategy balances isolation and operational efficiency:

• Separate accounts for production, staging, development, and security functions
• Hybrid OU structure (environment + application-based) works best for most organizations
• Cross-account access via IAM roles and resource sharing (RAM)
• Centralized network architecture with Transit Gateway or shared VPCs
• Break-glass procedures for emergencies

Service control policies enforce preventive governance:

• SCPs define maximum permissions at the account level
• Deny list strategy (easier to start) vs. allow list strategy (more secure)
• Common patterns: region restriction, encryption requirements, preventing security service disablement
• Test SCPs in non-production before applying to production
• Document exception process for emergencies

Cost optimization through Organizations:

• Consolidated billing enables Reserved Instances and Savings Plans sharing across accounts
• Volume discounts for S3, data transfer, and other services
• Cost allocation tags and tag policies for chargeback
• Cost and Usage Reports (CUR) for detailed analysis
• Control Tower costs primarily from AWS Config rules; optimize by limiting regions and elective guardrails

Migration requires careful planning:

• Greenfield (new organization) vs. brownfield (migrate existing) vs. hybrid approaches
• Phase migration: non-production first, then production
• Address conflicts (Config recorders, CloudTrail, IAM roles) before enrollment
• Test SCPs and guardrails in isolation before broad deployment
• Establish break-glass procedures and exception processes

Common pitfalls to avoid:

• Running workloads in management account (security risk)
• Deploying restrictive SCPs without testing (blocks production operations)
• Enabling all elective guardrails without cost analysis (budget overruns)
• No break-glass IAM users (locked out during SSO outage)
• Inadequate log retention policies (storage costs balloon)
• Flat OU structure that doesn’t scale (difficult to apply granular policies)

Organizations and Control Tower are essential for enterprise AWS governance. They transform multi-account management from manual, error-prone processes into automated, compliant, cost-optimized operations. Start with Control Tower for greenfield deployments; migrate carefully for existing environments. Invest in planning OU structure, SCPs, and guardrails upfront to avoid costly rework later.