AWS Organizations & Account Management Policies
Master AWS Organizations with Service Control Policies (SCPs), account governance, and multi-account security strategies for enterprise-scale management.
📋 Prerequisites
- AWS account with Organizations administrative access and billing permissions.
- Deep understanding of AWS IAM, multi-account strategies, and OU structures.
- Experience with JSON policy syntax, AWS CLI/SDK, and Infrastructure as Code (Terraform).
- Knowledge of enterprise governance frameworks and compliance requirements.
💡 From Single Account Chaos to Enterprise Account Governance
Traditional AWS deployments often start with single accounts that become sprawling, ungovernable environments. AWS Organizations with Service Control Policies transforms account management into structured, policy-driven governance that scales across thousands of accounts while maintaining security and compliance.
What You'll Learn
🏷️ Topics Covered
Building Your AWS Organizations Foundation
AWS Organizations provides centralized management of multiple AWS accounts through organizational units (OUs), service control policies (SCPs), and consolidated billing. This foundation enables enterprise-scale governance while maintaining account isolation and security boundaries.
🎯 Organizations Core Principles
Effective AWS Organizations are built on Account Isolation (workload separation), Centralized Governance (unified policy management), Hierarchical Control (OU-based organization), and Automated Compliance (policy-driven enforcement).
Core Organizations Components
🏛️ Management Account
Central control plane for organization management, billing consolidation, and master governance policies.
📁 Organizational Units
Hierarchical groupings for accounts with inherited policies, governance controls, and access management.
🔐 Service Control Policies
Guardrail policies that define maximum permissions and enforce compliance across accounts and OUs.
💳 Consolidated Billing
Unified billing management with cost allocation, budget controls, and volume discounts across accounts.
Implementing Service Control Policies for Enterprise Governance
Service Control Policies (SCPs) act as guardrails that define the maximum permissions available to accounts within your organization. They enable preventive governance by blocking actions that violate organizational policies, regardless of IAM permissions.
Traditional Account Management
- Manual policy enforcement per account
- Inconsistent security controls
- Reactive compliance monitoring
- Complex cross-account permissions
- Decentralized billing and cost tracking
Organizations with SCPs
- Centralized policy enforcement
- Consistent guardrails across accounts
- Preventive compliance controls
- Simplified permission management
- Consolidated billing and governance
Example 1: Comprehensive Security Baseline SCP
This SCP establishes fundamental security guardrails that prevent common security misconfigurations across all accounts.
🔒 JSON: Security Baseline Service Control Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyRootAccessKeyCreation",
"Effect": "Deny",
"Action": [
"iam:CreateAccessKey",
"iam:DeleteAccessKey",
"iam:UpdateAccessKey"
],
"Resource": "arn:aws:iam::*:user/root"
},
{
"Sid": "DenyUnencryptedS3Objects",
"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::*/*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption": "true"
}
}
},
{
"Sid": "DenyInsecureTransportForS3",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::*/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "DenyUnencryptedEBSVolumes",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:volume/*",
"Condition": {
"Bool": {
"ec2:Encrypted": "false"
}
}
},
{
"Sid": "EnforceIMDSv2",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals": {
"ec2:MetadataHttpTokens": "required"
}
}
}
]
}Example 2: Data Residency and Compliance SCP
This SCP ensures data residency compliance by restricting resource creation to approved regions and enforcing data governance policies.
🌍 JSON: Data Residency Service Control Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideApprovedRegions",
"Effect": "Deny",
"NotAction": [
"iam:*", "organizations:*", "route53:*", "support:*", "cloudfront:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [ "us-east-1", "eu-west-1" ]
}
}
},
{
"Sid": "RequireDataClassificationTags",
"Effect": "Deny",
"Action": [ "s3:CreateBucket", "rds:CreateDBInstance" ],
"Resource": "*",
"Condition": {
"Null": {
"aws:RequestTag/DataClassification": "true"
}
}
},
{
"Sid": "RequireApprovedDataClassificationValues",
"Effect": "Deny",
"Action": [ "s3:CreateBucket", "rds:CreateDBInstance" ],
"Resource": "*",
"Condition": {
"ForAnyValue:StringNotEquals": {
"aws:RequestTag/DataClassification": [ "Public", "Internal", "Confidential" ]
}
}
}
]
}Example 3: Development Environment SCP
This SCP provides appropriate guardrails for development accounts, allowing flexibility while preventing access to production services and high-cost instances.
💻 JSON: Development Environment Service Control Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyProductionServiceAccess",
"Effect": "Deny",
"Action": [ "directconnect:*", "wafv2:*" ],
"Resource": "*"
},
{
"Sid": "DenyHighCostInstances",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"ForAnyValue:StringLike": {
"ec2:InstanceType": [ "*.metal", "p*.*", "g*.*" ]
}
}
},
{
"Sid": "RequireProjectTagging",
"Effect": "Deny",
"Action": [ "ec2:RunInstances", "rds:CreateDBInstance", "s3:CreateBucket" ],
"Resource": "*",
"Condition": {
"Null": {
"aws:RequestTag/Project": "true"
}
}
}
]
}Multi-Account Governance Strategies and Best Practices
Effective multi-account governance requires strategic account design, standardized naming conventions, automated provisioning, and consistent policy application.
Account Factory Automation
Automated account creation with baseline configurations, standard IAM roles, and compliance policies applied from day one.
Cross-Account Access
Centralized identity management with federated access, role-based permissions, and least-privilege principles.
Centralized Logging
Aggregated security logs, compliance monitoring, and centralized incident response across all organizational accounts.
Cost Optimization
Consolidated billing, cost allocation tracking, automated budget controls, and rightsizing recommendations.
Account Strategy Patterns
🏛️ Core Accounts Foundation
- Management Account: Organizations admin, consolidated billing, root governance.
- Security Account: Central security tooling, log aggregation, incident response.
- Log Archive Account: Long-term immutable log retention for compliance and audit.
🏭 Workload Accounts by Environment
- Production Accounts: Live workloads with strict change controls and monitoring.
- Development Accounts: Individual or team development with flexible policies.
- Sandbox Accounts: Experimentation with cost controls and time limits.
Organizational Unit Design and Hierarchy Management
Strategic OU design enables scalable policy management and simplified account administration across complex enterprise structures.
📁 YAML: Enterprise OU Structure Configuration
# Example OU structure defined as code
Root:
ServiceControlPolicies:
- "OrganizationBaseline"
- "SecurityFoundation"
OrganizationalUnits:
Security:
Description: "Central security and compliance accounts"
ServiceControlPolicies:
- "SecurityAdminAccess"
Accounts:
- SecurityTooling
- LogArchive
- IncidentResponse
Infrastructure:
Description: "Shared infrastructure and platform services"
ServiceControlPolicies:
- "NetworkingControls"
Accounts:
- NetworkHub
- SharedServices
Workloads:
Description: "Application workload accounts"
ServiceControlPolicies:
- "WorkloadBaseline"
OrganizationalUnits:
Production:
ServiceControlPolicies:
- "ProductionBaseline"
- "DataProtection"
Accounts:
- WebAppProd
- DataPlatformProd
Development:
ServiceControlPolicies:
- "DevelopmentControls"
- "CostOptimization"
Accounts:
- TeamADev
- TeamBDev
Sandbox:
Description: "Experimentation and learning accounts"
ServiceControlPolicies:
- "SandboxPolicy"
- "StrictCostLimits"
Accounts:
- InnovationSandbox
- TrainingSandboxConsolidated Billing and Cost Management Strategies
Consolidated billing provides unified cost management across your organization with volume discounts, simplified payment processing, and detailed cost allocation tracking.
Cost Allocation Strategy
Implement comprehensive tagging strategies and cost center assignments for accurate chargeback.
Budget Controls & Alerts
Establish automated budget controls, spending alerts, and cost anomaly detection.
Reserved Instance Management
Centralize Reserved Instance and Savings Plan purchases for maximum utilization.
Cost Optimization Automation
Implement automated rightsizing, resource scheduling, and cost optimization recommendations.
Cost Allocation and Tagging Strategy
Use SCPs to enforce your tagging strategy, ensuring all resources are correctly associated with a cost center and environment.
💰 JSON: Cost Allocation Tagging Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RequireCostCenterAndEnvironmentTags",
"Effect": "Deny",
"Action": [
"ec2:RunInstances",
"rds:CreateDBInstance",
"s3:CreateBucket"
],
"Resource": "*",
"Condition": {
"Null": {
"aws:RequestTag/CostCenter": "true",
"aws:RequestTag/Environment": "true"
}
}
},
{
"Sid": "ValidateEnvironmentTagValues",
"Effect": "Deny",
"Action": [
"ec2:RunInstances",
"rds:CreateDBInstance"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringNotEquals": {
"aws:RequestTag/Environment": [
"production",
"staging",
"development",
"sandbox"
]
}
}
}
]
}Automation and Integration Patterns
Automate account lifecycle management, policy deployment, and compliance monitoring through Infrastructure as Code (IaC) and CI/CD pipelines for seamless organizational governance.
Account Factory Automation with Terraform
🏗️ HCL: Automated Account Creation with Terraform
# Main organizations module to create an account
variable "account_name" { type = string }
variable "account_email" { type = string }
variable "target_ou_id" { type = string }
resource "aws_organizations_account" "new_account" {
name = var.account_name
email = var.account_email
parent_id = var.target_ou_id
role_name = "OrganizationAccountAccessRole"
tags = {
ManagedBy = "Terraform"
CreatedDate = timestamp()
}
}
# Provider alias to configure resources within the new account
provider "aws" {
alias = "new_account_provider"
assume_role {
role_arn = "arn:aws:iam::${aws_organizations_account.new_account.id}:role/OrganizationAccountAccessRole"
}
}
# Example of provisioning a baseline resource (CloudTrail) in the new account
resource "aws_cloudtrail" "baseline_trail" {
provider = aws.new_account_provider
name = "organization-level-trail"
s3_bucket_name = "my-central-log-archive-bucket"
s3_key_prefix = "trail-logs/${aws_organizations_account.new_account.id}"
is_multi_region_trail = true
include_global_service_events = true
enable_logging = true
}
# Example of applying a budget to the new account
resource "aws_budgets_budget" "account_budget" {
name = "${var.account_name}-budget"
budget_type = "COST"
limit_amount = "1000"
limit_unit = "USD"
time_unit = "MONTHLY"
cost_filters = {
LinkedAccount = [aws_organizations_account.new_account.id]
}
notification {
comparison_operator = "GREATER_THAN"
threshold = 80
threshold_type = "PERCENTAGE"
notification_type = "ACTUAL"
subscriber_email_addresses = ["finance-alerts@example.com"]
}
}Policy Deployment Pipeline
Use a CI/CD pipeline to validate, test, and deploy SCP changes, ensuring a safe and auditable process.
🔄 YAML: SCP Deployment CI/CD Pipeline
name: SCP Deployment Pipeline
on:
push:
branches: [ main ]
paths: [ 'policies/scps/**' ]
pull_request:
paths: [ 'policies/scps/**' ]
jobs:
validate:
name: Validate SCP Syntax
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Validate JSON syntax
run: |
for file in policies/scps/*.json; do
jq . "$file" > /dev/null
done
plan:
name: Terraform Plan
runs-on: ubuntu-latest
needs: validate
steps:
- uses: actions/checkout@v3
- uses: hashicorp/setup-terraform@v2
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v2
with:
role-to-assume: arn:aws:iam::MANAGEMENT_ACCOUNT_ID:role/cicd-role
aws-region: us-east-1
- name: Terraform Init and Plan
run: |
cd terraform/
terraform init
terraform plan -out=tfplan
deploy:
name: Deploy to Production
runs-on: ubuntu-latest
needs: plan
if: github.ref == 'refs/heads/main'
environment: production
steps:
- uses: actions/checkout@v3
- uses: hashicorp/setup-terraform@v2
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v2
with:
role-to-assume: arn:aws:iam::MANAGEMENT_ACCOUNT_ID:role/cicd-role
aws-region: us-east-1
- name: Terraform Apply
run: |
cd terraform/
terraform init
terraform apply -auto-approve tfplanEnterprise Implementation and Best Practices
🔑 AWS Organizations Best Practices
- Start Simple, Scale Gradually: Begin with basic OU structure and expand as organizational needs grow.
- Policy Testing Strategy: Always test SCPs in non-production OUs before applying to production accounts.
- Principle of Least Privilege: Use SCPs as guardrails while granting minimal necessary permissions through IAM.
- Consistent Naming Conventions: Establish and enforce standardized naming for accounts, OUs, and policies.
- Automated Account Lifecycle: Implement account factory patterns for consistent baseline configuration.
- Cost Allocation Strategy: Implement comprehensive tagging and cost center allocation from day one.
- Security by Design: Embed security controls and monitoring into every account from creation.
- Documentation and Training: Maintain current documentation and provide ongoing training for account administrators.