DEV Community

Cover image for AWS Multi-Account Best Practices: Build a Scalable, Secure Foundation
AWS Community Builders profile image Danny Steenman
Danny Steenman for AWS Community Builders

Posted on • Originally published at towardsthecloud.com

AWS Multi-Account Best Practices: Build a Scalable, Secure Foundation

#aws #landingzone #organizations #governance

Multi-account architecture is AWS's recommended approach for organizations running production workloads. But implementation matters. Get it wrong, and you'll spend months wrestling with operational complexity, compliance gaps, and cost overruns. Get it right, and you'll have a scalable foundation that supports hundreds or thousands of accounts with automated governance.

This guide is broken up into 5 parts, each walking you through a different aspect of a multi-account architecture:

  1. Foundation: AWS Organizations and OU structure
  2. Access: Identity management with IAM Identity Center
  3. Governance: Service Control Policies and cost management
  4. Operations: Centralized logging and security monitoring
  5. Execution: Landing zone deployment and migration strategies

Each aspect contains the best practices for that aspect so you know what is required when you plan on going from a single account to a multi-account architecture.

Is Multi-Account Right for You?

Before diving into implementation, ensure you meet these criteria:

  • Team size: More than 10 people or multiple independent teams
  • Workload isolation: Production and non-production environments need separation
  • Compliance requirements: Frameworks like HIPAA, PCI-DSS, or SOC2 requiring workload isolation
  • Multiple products: Independent applications with different cost centers
  • Security boundaries: Different teams requiring resource isolation

If you're unsure whether multi-account architecture makes sense for your current stage, review our AWS Account Best Practices guide first. This comprehensive guide covers root user security, IAM best practices, logging, cost management, and the single vs multi-account decision framework. Multi-account adds operational complexity, so master these foundational security practices before scaling.

AWS Organizations: The Control Plane

AWS Organizations provides centralized management across multiple AWS accounts. Think of it as the control plane for your entire AWS environment. Without Organizations, you can't implement Service Control Policies, consolidated billing, or any of the advanced governance features required for multi-account success. For a complete understanding of Organizations setup and best practices, see our comprehensive guide: AWS Organizations Best Practices.

Organizations Setup and Structure

AWS Organizations groups accounts into a hierarchical structure with a single management account at the root. The management account creates the organization, invites or creates member accounts, and pays the consolidated bill for all accounts.

Enable Organizations in "All Features" mode, not "Consolidated Billing Only." All Features mode unlocks Service Control Policies, tag policies, backup policies, and AI services opt-out policies. These are essential for multi-account governance.

Here's how to create an organization using AWS CLI:

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

# Verify creation
aws organizations describe-organization
Enter fullscreen mode Exit fullscreen mode

The organization structure follows this hierarchy: Organization Root → Organizational Units (OUs) → Accounts. The organization root is the top-level container, OUs group accounts by function or environment, and accounts contain your actual AWS resources.

Management Account vs. Member Accounts

This is critical: never run workloads in your management account.

The management account has three narrow responsibilities:

  1. AWS Organizations administration
  2. Consolidated billing and payment
  3. IAM Identity Center (AWS SSO) configuration

That's it. No EC2 instances, no Lambda functions, no S3 buckets with application data. Why? Service Control Policies don't apply to the management account. Any workload running there bypasses all your governance guardrails. This creates security risks and compliance violations.

The management account requires special security attention including root user protection, hardware MFA, and CloudWatch alarms for any root activity. For comprehensive guidance on securing any AWS account—including the management account—see our AWS Account Security Best Practices guide covering root user security, IAM controls, and monitoring fundamentals.

Member accounts run your actual workloads. They receive policies from parent OUs, connect to centralized logging, and operate within the security boundaries you define. Keep the management account minimal and strictly controlled.

Organizational Units (OUs): Structure and Strategy

Organizational Units are policy application boundaries. You attach Service Control Policies, tag policies, and other governance controls to OUs, and they cascade down to all member accounts.

Keep your OU structure simple. Flat structures are easier to manage than deep hierarchies. Avoid nesting beyond 5 levels. Each additional level makes policy troubleshooting exponentially harder.

Name OUs based on function, not organizational structure. Teams reorganize frequently, but security boundaries and environments are stable. Use names like "Production," "Security," and "Sandbox" rather than "Engineering-Team-A" or "Finance-Department."

Policy inheritance flows down the OU tree. An account in Production → US-East-1 → Web-Apps inherits policies from Production, US-East-1, and Web-Apps OUs, plus the organization root. This can create unexpected denials if you're not careful.

Recommended OU Structure and Design Patterns

Your OU structure should match your organization's maturity and risk tolerance. The most common mistake is over-engineering too early or under-investing in structure as you scale. Start with a proven pattern, then expand as your organization grows.

Best Practice: Startup/Small Business Architecture

When moving from a single account to multi-account architecture, this pattern provides essential isolation without complexity overhead. It works for organizations from 5 to 50 employees and delivers immediate security and cost allocation benefits.

graph TB
    Root["Root Account<br/>(Management)"]

    subgraph ManagementOU["Management OU"]
        AuditLog["Audit/Log<br/>Archive"]
        Security["Security<br/>Tooling"]
        SharedServices["Shared<br/>Services"]
    end

    subgraph ProductionOU["Production OU"]
        Prod1["Production<br/>Account"]
        Staging1["Staging<br/>Account"]
    end

    subgraph DevOU["Dev OU"]
        Dev1["Development<br/>Account"]
        Sandbox1["Sandbox<br/>Account"]
    end

    Root --> ManagementOU
    Root --> ProductionOU
    Root --> DevOU

    classDef rootStyle fill:#ff9999,stroke:#cc0000,stroke-width:3px,color:#000
    classDef ouStyle fill:#fff,stroke:#e91e63,stroke-width:2px,stroke-dasharray: 5 5,color:#000
    classDef accountStyle fill:#fff,stroke:#e91e63,stroke-width:2px,color:#000

    class Root rootStyle
    class ManagementOU,ProductionOU,DevOU ouStyle
    class AuditLog,Security,SharedServices,Prod1,Staging1,Dev1,Sandbox1 accountStyle

    linkStyle default stroke:#e91e63,stroke-width:2px
Enter fullscreen mode Exit fullscreen mode

Core Account Structure

Essential Accounts (minimum viable separation):

Account Name Purpose Key Functions
Root/Management Account Organizational control plane Houses AWS Organizations, manages consolidated billing, no workloads ever
Production Account Customer-facing services Production applications, production databases, revenue-generating services
Development Account Development and testing Development environments, testing and experimentation, CI/CD pipeline targets
Security & Logging Account Centralized security hub Centralized CloudTrail logs, GuardDuty master, Security Hub aggregation, IAM Identity Center (SSO) configuration
Shared Services Account Common resources Container registries (ECR), artifact repositories, internal tools, service catalogs

Organizational Unit Strategy

Production OU (Strict controls via SCPs):
Apply SCPs that prevent accidental destruction of production resources. Restrict who can delete databases, terminate critical instances, or disable security logging. This OU enforces stricter change management and requires MFA for destructive operations.

Development OU (Relaxed policies for velocity):
Apply SCPs that allow experimentation but prevent expensive mistakes. Developers can spin up resources freely, but SCPs block launching expensive instance types (anything larger than m5.xlarge) and prevent purchasing Reserved Instances. This balances innovation with cost control.

Management OU (Locked down administrative accounts):
Apply the most restrictive SCPs. Only designated security personnel can access these accounts. SCPs prevent workload deployment and restrict access to a minimal set of management operations. This OU protects your audit logs and security tooling from tampering.

Why This Pattern Works

This structure delivers immediate value without overwhelming small teams:

  • Blast radius containment: Production incidents don't affect development, and vice versa
  • Clear cost allocation: See exactly what production versus development costs
  • Simplified compliance: Separate production data from development chaos
  • Rapid iteration: Developers can experiment in dev without production anxiety
  • Policy-based guardrails: SCPs prevent mistakes before they happen

Additional Patterns for Growing Organizations

As your organization scales beyond 50 employees, you'll need more sophisticated patterns with specialized infrastructure services, team-based accounts, and enhanced security posture. For complete architecture patterns including:

  • Mid-Size/Growing Business Architecture (50-500 employees): Team-based accounts, centralized networking, sandbox environments, and enhanced security posture
  • Enterprise Architecture (500+ employees): Regional distribution, specialized infrastructure separation, dedicated forensics accounts, and layered governance at scale
  • Industry-Specific Patterns: Healthcare/HIPAA, Financial Services/PCI-DSS, and SaaS provider architectures
  • Migration Strategies: Consolidating existing accounts and automation approaches

See our comprehensive guide: AWS Multi-Account Strategy: The Right Architecture for Your Growth Stage.

With your organizational structure defined, the next question is: who can access these accounts and what can they do? This requires centralized identity management.

Multi-Account Identity and Access Management

Multi-account environments need centralized identity management. Managing separate IAM users in 50+ accounts is operationally impossible and creates security risks.

IAM Identity Center (AWS SSO) Setup

IAM Identity Center (formerly AWS SSO) provides centralized workforce identity for multi-account environments. Users sign in once and get access to multiple accounts through a single portal. For complete setup instructions and integration options, consult the AWS IAM Identity Center User Guide.

Enable IAM Identity Center in your management account:

# Enable Identity Center (one-time setup)
aws sso-admin create-instance --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxx

# Configure Identity Center directory
aws identitystore list-users --identity-store-id d-xxxxxxxxxx
Enter fullscreen mode Exit fullscreen mode

IAM Identity Center supports three identity sources:

  1. Identity Center directory: Built-in directory for small teams (<100 users)
  2. Active Directory: Connect to on-premises or AWS Managed Microsoft AD
  3. External SAML IdP: Okta, Google Workspace, Entra ID, or any SAML 2.0 provider

For most modern organizations, external SAML IdP integration works best. It leverages your existing identity provider, supports SCIM for automated user/group sync, and provides single sign-on across all applications (not just AWS).

Users access AWS accounts through the AWS access portal: https://d-xxxxxxxxxx.awsapps.com/start. They see a list of accounts and permission sets assigned to them, click to assume a role, and get temporary credentials.

No long-term access keys. No IAM users to manage. No password rotation headaches.

Permission Sets and Multi-Account Assignment

Permission sets define what users can do in accounts. They're templates that create IAM roles in target accounts automatically, providing a simpler alternative to managing roles individually in each account.

Create a custom permission set:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "s3:List*",
        "s3:Get*",
        "cloudwatch:Describe*",
        "cloudwatch:Get*",
        "cloudwatch:List*"
      ],
      "Resource": "*"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Assign this permission set to a group across multiple accounts:

  • ReadOnly permission set → Security-Team group → All accounts in Production OU
  • PowerUser permission set → Engineering group → Development and Staging accounts
  • DatabaseAdmin permission set → DBA group → Production databases only

Changes to permission sets propagate automatically to all assigned accounts. Update the ReadOnly permission set, and it updates in all 50 accounts within minutes.

Use attribute-based access control (ABAC) for fine-grained permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Owner": "${aws:PrincipalTag/Department}"
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

This allows users to manage only resources tagged with their department. SAML attributes from your IdP (like department, cost center, team) become session tags, enabling dynamic permissions without hardcoding user lists.

Integration with External Identity Providers

External identity provider integration gives you centralized user management and single sign-on.

Okta Integration:

  1. Create SAML 2.0 application in Okta
  2. Configure attribute mappings (email, groups, department)
  3. Download SAML metadata XML
  4. Import metadata to IAM Identity Center
  5. Enable SCIM for automated user/group provisioning

Google Workspace Integration:

  1. Create custom SAML application in Google Admin
  2. Configure ACS URL: https://d-xxxxxxxxxx.awsapps.com/start/saml2/consume
  3. Map attributes: email → emailAddress, groups → memberOf
  4. Enable application for target organizational units
  5. Configure SCIM provisioning with OAuth token

Entra ID (Azure AD) Integration:

  1. Add AWS IAM Identity Center from Enterprise Applications gallery
  2. Configure single sign-on with SAML
  3. Assign users and groups
  4. Enable automatic user provisioning with SCIM
  5. Set up attribute mappings

SCIM (System for Cross-domain Identity Management) automatically syncs users and groups from your IdP to IAM Identity Center. When you add a user to your Okta Engineering group, they automatically get access to AWS accounts with the Engineering permission set. When they leave the company and you deactivate their Okta account, they lose AWS access immediately.

This is significantly better than managing IAM users per account.

Cross-Account IAM Roles

IAM Identity Center handles human access. Cross-account IAM roles handle service-to-service access and third-party integrations.

Use cross-account roles for:

  • Service access: Lambda in Account A reading data from S3 in Account B
  • Third-party access: Security scanning vendor accessing your accounts
  • Break-glass access: Emergency access when Identity Center is unavailable
  • CI/CD pipelines: Deployment role in pipeline account assuming roles in workload accounts

Create a cross-account role with a trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/DeploymentRole"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id-12345"
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

The external ID prevents the confused deputy problem. Third-party vendors might have access to multiple customers' accounts. Without external IDs, they could accidentally or maliciously use your role ARN with another customer's credentials. External IDs ensure only authorized principals can assume the role.

Assume the role from the trusted account:

aws sts assume-role \
  --role-arn arn:aws:iam::222222222222:role/CrossAccountRole \
  --role-session-name deployment-session \
  --external-id unique-external-id-12345
Enter fullscreen mode Exit fullscreen mode

This returns temporary credentials (access key, secret key, session token) valid for up to 12 hours. Use these credentials to perform actions in the target account.

Cross-account roles with session naming create clear audit trails. CloudTrail shows which account, role, and session assumed the role and what actions they performed.

With identity management in place, you can define what actions are allowed or denied across your organization. This is where Service Control Policies provide scalable governance guardrails.

Service Control Policies (SCPs) for Governance

Service Control Policies define maximum permissions for accounts in your organization. They're the guardrails that prevent security violations and compliance failures at scale. For a complete understanding of SCPs, how to create and test them, see our guide: What are AWS Service Control Policies.

Understanding SCP Evaluation Logic

SCPs don't grant permissions. They set boundaries on what IAM policies can allow. Think of SCPs as permission filters: even if an IAM policy allows an action, an SCP can block it.

Effective permissions = IAM policies AND SCPs. Both must allow an action for it to succeed.

SCPs use deny-by-default evaluation. If an action isn't explicitly allowed by an SCP, it's denied. The default FullAWSAccess SCP allows everything, which is why you need to attach restrictive SCPs to enforce guardrails.

SCPs have critical limitations:

  • They don't apply to the management account (another reason to never run workloads there)
  • They don't affect service-linked roles (AWS-managed roles for services like Auto Scaling)
  • They can't grant permissions, only limit them
  • They inherit down the OU tree (be careful with overlapping policies)

Here's how policy evaluation works:

1. Check if action is allowed by IAM policy
2. Check if action is allowed by all SCPs in hierarchy
3. If both allow → Action succeeds
4. If either denies → Action fails
Enter fullscreen mode Exit fullscreen mode

Essential SCP Patterns (Region, Service, Resource Protection)

Four SCP patterns cover 90% of governance requirements:

1. Region Deny SCP

Restrict all actions to approved AWS Regions. This prevents data residency violations and limits your security monitoring scope.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2",
            "eu-west-1"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/OrganizationAccountAccessRole",
            "arn:aws:iam::*:role/AWSControlTowerExecution"
          ]
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

The ArnNotLike condition exempts the organization access role. Without this exemption, your automation can't manage resources in restricted regions.

2. Root User Deny SCP

Prevent root user usage in member accounts. Root users should only be used in the management account for emergency break-glass scenarios.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Note: This SCP doesn't apply to the management account root user (SCPs never do). Management account root user security requires additional controls like MFA and hardware security keys.

3. Resource Protection SCP

Prevent deletion or modification of security controls like CloudTrail, Config, and GuardDuty.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ProtectConfig",
      "Effect": "Deny",
      "Action": [
        "config:DeleteConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "config:StopConfigurationRecorder"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ProtectGuardDuty",
      "Effect": "Deny",
      "Action": [
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "guardduty:StopMonitoringMembers"
      ],
      "Resource": "*"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

This ensures your security monitoring can't be disabled by compromised credentials or accidental API calls.

4. Service Restriction SCP

Limit to approved AWS services. Useful for compliance frameworks requiring service whitelisting.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedServices",
      "Effect": "Deny",
      "NotAction": [
        "ec2:*",
        "s3:*",
        "rds:*",
        "lambda:*",
        "cloudformation:*",
        "iam:*",
        "sts:*"
      ],
      "Resource": "*"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Be careful with service restrictions. They can block legitimate use cases. Test thoroughly before production deployment.

OU-Specific SCP Examples

Different OUs require different guardrails based on their risk profile:

Production OU SCPs:

  • Region restriction to approved Regions only
  • Prevent deletion of production resources (require MFA + specific IAM role)
  • Block instance types above certain size (cost control)
  • Require encryption for all storage services
  • Prevent public S3 buckets and RDS instances

Sandbox OU SCPs:

  • Monthly cost cap (deny actions when spend exceeds $500)
  • Instance type limits (prevent expensive GPU instances)
  • Auto-shutdown outside business hours
  • No cross-account access to production
  • Aggressive resource deletion policies

Security OU SCPs:

  • Minimal restrictions (security tools need broad access)
  • Allow security-related API calls
  • Prevent modification of security tool infrastructure

For production-ready SCP examples for each OU type, see our comprehensive guide: AWS Service Control Policy (SCP) Examples by Organizational Unit with tested, customizable policies you can deploy immediately.

Testing and Deploying SCPs Safely

Never deploy untested SCPs to production. They apply immediately upon attachment and can break production workloads instantly.

Use this testing workflow:

  1. Create Policy Staging OU with a test account mirroring production configuration
  2. Attach new SCP to Policy Staging OU only
  3. Verify expected behavior (denials work, exceptions work, no unintended blocks)
  4. Test automation roles (CI/CD, infrastructure deployment, monitoring)
  5. Document the SCP (what it blocks, why, which accounts it affects)
  6. Roll out incrementally: Staging → Development → Production OUs

If an SCP causes production issues, detach it immediately. SCPs take effect instantly, so rollback is fast.

Maintain a rollback procedure document:

# Emergency SCP detachment
aws organizations detach-policy \
  --policy-id p-xxxxxxxx \
  --target-id ou-xxxx-xxxxxxxx

# Verify detachment
aws organizations list-policies-for-target \
  --target-id ou-xxxx-xxxxxxxx \
  --filter SERVICE_CONTROL_POLICY
Enter fullscreen mode Exit fullscreen mode

Keep this in your incident response runbooks. When production is down, you don't want to be searching AWS documentation.

Multi-Account Cost Management

Multi-account architecture provides natural cost allocation boundaries and enables volume discounts through consolidated billing. Alongside SCPs, cost management is a key governance concern.

Consolidated Billing Benefits

The management account receives a single consolidated bill covering all member accounts. AWS aggregates usage across accounts for volume pricing tiers.

Benefits of consolidated billing:

  • Volume discounts: S3 usage aggregates across accounts, reaching higher discount tiers faster
  • Reserved Instances sharing: RIs purchased in one account apply to matching usage in other accounts
  • Savings Plans sharing: Compute Savings Plans and EC2 Instance Savings Plans share across the organization
  • Single payment: One credit card, one invoice, simpler accounting
  • Detailed reporting: Cost and Usage Report (CUR) breaks down costs by account

Enable Cost and Usage Report for detailed analysis:

aws cur put-report-definition \
  --report-definition \
    ReportName=organization-cur \
    TimeUnit=DAILY \
    Format=Parquet \
    Compression=Parquet \
    S3Bucket=cur-reports-111111111111 \
    S3Prefix=cur \
    S3Region=us-east-1 \
    AdditionalSchemaElements=RESOURCES
Enter fullscreen mode Exit fullscreen mode

The CUR includes every line item across all accounts: which instance, in which account, tagged how, at what rate. This enables sophisticated cost analysis and chargeback.

Reserved Instance and Savings Plans sharing happens automatically across accounts in the organization. Buy RIs in a centralized Infrastructure account, and they apply to matching instance usage in all accounts. No configuration needed.

Cost Allocation Across Accounts

Account structure creates natural cost boundaries. Production account costs separate from development account costs automatically.

But you need more granularity. Tag-based cost allocation provides this.

Activate cost allocation tags in the management account:

aws ce create-cost-category-definition \
  --name "Team" \
  --rules \
    '[
      {
        "Value": "Engineering",
        "Rule": {
          "Tags": {
            "Key": "Team",
            "Values": ["engineering"]
          }
        }
      },
      {
        "Value": "Data",
        "Rule": {
          "Tags": {
            "Key": "Team",
            "Values": ["data"]
          }
        }
      }
    ]'
Enter fullscreen mode Exit fullscreen mode

Cost categories group costs by custom dimensions (team, product, environment) regardless of which account they're in. This enables chargeback reporting: "Data team spent $47K this month across 12 accounts."

Tag backfill activates historical tags retroactively for up to 12 months. If you enable a cost allocation tag today, you can backfill it and get historical cost reporting.

Tag Policies for Governance

Tag policies enforce consistent tagging across the organization. Without enforcement, tagging degrades quickly and cost allocation breaks.

Create a tag policy requiring CostCenter and Project tags:

{
  "tags": {
    "CostCenter": {
      "tag_key": {
        "@@assign": "CostCenter"
      },
      "tag_value": {
        "@@assign": [
          "1000",
          "2000",
          "3000"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume",
          "rds:db",
          "s3:bucket"
        ]
      }
    },
    "Project": {
      "tag_key": {
        "@@assign": "Project"
      },
      "enforced_for": {
        "@@assign": [
          "ec2:*",
          "rds:*",
          "s3:*"
        ]
      }
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Apply this tag policy to the Workloads OU. Now any EC2 instance, RDS database, or S3 bucket created in workload accounts must have valid CostCenter and Project tags. Non-compliant resource creation fails.

Use AWS Config rules to detect existing non-compliant resources and create automated remediation to apply default tags or notify resource owners.

FinOps at Scale

Financial operations (FinOps) at scale requires automation and culture change.

Cost Anomaly Detection identifies unusual spending patterns:

aws ce create-anomaly-monitor \
  --monitor-name organization-anomaly-monitor \
  --monitor-type DIMENSIONAL \
  --monitor-dimension SERVICE

aws ce create-anomaly-subscription \
  --subscription-name high-anomaly-alerts \
  --monitor-arn arn:aws:ce::111111111111:anomalymonitor/xxxxxxxx \
  --subscribers \
    Address=cloud-team@company.com,Type=EMAIL \
  --threshold-expression '{"Dimensions": {"Key": "ANOMALY_TOTAL_IMPACT_ABSOLUTE", "Values": ["100"]}}'
Enter fullscreen mode Exit fullscreen mode

This alerts when daily spending spikes $100 above predicted costs. Catch runaway instances, forgotten resources, and cost attacks early.

Automated Resource Cleanup prevents waste. Schedule Lambda functions to run daily across all accounts to delete unattached EBS volumes, old snapshots, and unused Elastic IPs.

Compute Optimizer Recommendations provide right-sizing guidance:

aws compute-optimizer get-ec2-instance-recommendations \
  --account-ids 111111111111 222222222222 \
  --filters \
    name=Finding,values=OVER_PROVISIONED
Enter fullscreen mode Exit fullscreen mode

Review recommendations monthly. Over-provisioned instances are spending money you don't need to spend.

Monthly FinOps reviews should cover:

  1. Top 10 cost drivers across organization
  2. Month-over-month cost changes by account and service
  3. Compute Optimizer and Trusted Advisor recommendations
  4. Reserved Instance and Savings Plans utilization
  5. Cost anomaly patterns and root causes
  6. Tag compliance rates by account

Make cost visibility part of your engineering culture. Engineers should know what their infrastructure costs.

With access controls and governance policies defined, you need visibility into what's happening across all accounts. Centralized logging and security monitoring make this possible.

Centralized Logging and Security Monitoring

Multi-account environments need centralized visibility. Managing logs and security findings in 50+ accounts individually is impossible.

CloudTrail Organization Trails

Organization trails capture API activity from all accounts in your organization automatically. Every CreateInstance, DeleteBucket, and UpdateSecurityGroup call gets logged centrally.

Enable an organization trail in the management account:

aws cloudtrail create-trail \
  --name organization-trail \
  --s3-bucket-name org-cloudtrail-logs-111111111111 \
  --is-organization-trail \
  --enable-log-file-validation \
  --is-multi-region-trail
Enter fullscreen mode Exit fullscreen mode

Organization trails automatically collect logs from all member accounts. Individual member accounts cannot disable or modify the organization trail, ensuring consistent audit coverage.

Deliver logs to a dedicated Log Archive account, not the management account. The Log Archive account should have:

  • Strict access controls (read-only for security team, append-only for CloudTrail)
  • KMS encryption for all logs
  • MFA Delete enabled on the S3 bucket
  • Lifecycle policies transitioning logs to Glacier after 90 days

Prevent CloudTrail deletion with an SCP:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectOrganizationTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "arn:aws:cloudtrail:*:*:trail/organization-trail"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

This ensures your audit logs remain intact even if an account is compromised.

Config Multi-Account Aggregation

AWS Config records resource configurations and evaluates compliance. Config aggregation consolidates findings from all accounts into a central Audit account.

Enable Config in every account using CloudFormation StackSets to deploy the ConfigurationRecorder and DeliveryChannel consistently.

Create a Config aggregator in the Audit account:

aws configservice put-configuration-aggregator \
  --configuration-aggregator-name organization-aggregator \
  --organization-aggregation-source \
    RoleArn=arn:aws:iam::111111111111:role/ConfigAggregatorRole \
    AllAwsRegions=true
Enter fullscreen mode Exit fullscreen mode

Deploy conformance packs organization-wide for compliance frameworks:

aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name cis-aws-foundations-benchmark \
  --template-s3-uri s3://conformance-packs/cis-1.4.0.yaml
Enter fullscreen mode Exit fullscreen mode

Config aggregation gives you a single dashboard showing compliance status across all accounts. You can query: "Show me all unencrypted EBS volumes across the organization" or "Which accounts have publicly accessible RDS instances?"

Automated remediation reduces manual intervention. Configure remediation actions that automatically fix violations—for example, enabling versioning on S3 buckets or encrypting unencrypted EBS volumes.

Security Hub and GuardDuty Delegated Administrators

Security Hub and GuardDuty need delegated administrators, not management account access.

Designate a Security Tooling account as the delegated administrator:

# Enable Security Hub delegated admin
aws securityhub enable-organization-admin-account \
  --admin-account-id 333333333333

# Enable GuardDuty delegated admin
aws guardduty enable-organization-admin-account \
  --admin-account-id 333333333333
Enter fullscreen mode Exit fullscreen mode

From the Security Tooling account, enable Security Hub and GuardDuty in all member accounts:

# Auto-enable Security Hub for new accounts
aws securityhub update-organization-configuration \
  --auto-enable

# Enable AWS Foundational Security Best Practices
aws securityhub batch-enable-standards \
  --standards-subscription-requests StandardsArn=arn:aws:securityhub:us-east-1::standards/aws-foundational-security-best-practices/v/1.0.0

# Auto-enable GuardDuty for new accounts
aws guardduty update-organization-configuration \
  --detector-id a1b2c3d4e5f6g7h8i9j0 \
  --auto-enable

# Enable S3 and Malware Protection
aws guardduty update-detector \
  --detector-id a1b2c3d4e5f6g7h8i9j0 \
  --data-sources S3Logs={Enable=true},MalwareProtection={Enable=true}
Enter fullscreen mode Exit fullscreen mode

Security Hub aggregates findings from GuardDuty, Config, IAM Access Analyzer, Macie, and third-party integrations. It runs continuous compliance checks against CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices.

Automate responses using EventBridge:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": {
        "Label": ["CRITICAL", "HIGH"]
      }
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Route high-severity findings to Lambda functions that automatically isolate compromised instances, revoke credentials, or create incident tickets.

Centralized Log Archive Account

The Log Archive account stores all logs from all accounts:

  • CloudTrail organization trails
  • Config snapshots and history
  • VPC Flow Logs
  • S3 access logs
  • Application logs from CloudWatch Logs

Security requirements for the Log Archive account:

Access Control:

  • Read-only access for security team
  • Append-only write access for AWS services
  • No delete permissions for anyone
  • MFA required for all human access

Encryption:

  • KMS encryption for all S3 buckets
  • Customer-managed KMS keys
  • Key policies restricting decryption to authorized principals

Immutability:

  • MFA Delete enabled on all log buckets
  • Object Lock for compliance requirements (WORM storage)
  • S3 Versioning enabled

Cost Optimization:

  • Lifecycle policies: Standard → Glacier after 90 days
  • Delete after 7 years (or your compliance retention requirement)
  • Intelligent-Tiering for variable access patterns

S3 bucket policy for append-only access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowLogsDelivery",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::log-archive-bucket/*"
    },
    {
      "Sid": "DenyDelete",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion"
      ],
      "Resource": "arn:aws:s3:::log-archive-bucket/*"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

This prevents accidental or malicious log deletion while allowing AWS services to deliver logs.

Now that you understand the components of a multi-account architecture, you need a way to deploy and maintain all of this consistently. This is where a landing zone becomes essential.

Landing Zone: Deploy and Maintain Everything Consistently with Infrastructure as Code

A landing zone is a well-architected, multi-account AWS environment based on AWS best practices. It's the implementation vehicle that deploys everything you've learned so far: Organizations, OU structure, SCPs, IAM Identity Center, centralized logging, and security monitoring.

For a deep dive into landing zone concepts and architecture, see our comprehensive guide: What is an AWS Landing Zone? which explains the components, benefits, and design patterns.

What a Landing Zone Includes

Think of a landing zone as the infrastructure blueprint for your entire AWS organization. It includes:

  • Account baseline: Every new account gets CloudTrail, Config, GuardDuty, Security Hub automatically enabled
  • Security controls: Service Control Policies enforcing guardrails across all accounts
  • Networking hub: Transit Gateway or Network Firewall for centralized connectivity
  • Centralized logging: CloudTrail organization trails, Config aggregation, VPC Flow Logs
  • Identity management: IAM Identity Center with permission sets and group mappings
  • Cost management: Budget alerts, cost anomaly detection, tag policies

Without a landing zone, you'll manually configure security baselines in every account, leading to configuration drift and compliance gaps. With a landing zone, new accounts inherit the complete security and governance baseline automatically.

Landing Zone Options: IaC vs. Control Tower

You have two primary approaches for implementing a landing zone:

AWS Control Tower: AWS's managed landing zone service. Point-and-click deployment through the console. Includes Account Factory (AWS Service Catalog) for provisioning new accounts and pre-built guardrails (implemented as SCPs and Config rules).

Infrastructure as Code: Custom landing zone built with AWS CDK or Terraform. Every resource defined in code, version-controlled in Git, deployed via CI/CD pipelines.

Here's how they compare:

Aspect Control Tower IaC Landing Zone
Deployment Point-and-click console Code-based (CDK/Terraform)
Cost $500+/month ~$100/month
Customization Limited, predefined guardrails Fully customizable
Version Control Configuration via console Git-tracked infrastructure
Automation Account Factory (Service Catalog) GitHub Actions / CI/CD
Guardrails Managed, cannot extend Custom SCPs + Config rules
Maintenance AWS manages updates You control updates

Control Tower works if you need a quick start and can accept its constraints. However, Control Tower is ClickOps—you're back to managing infrastructure through console clicks rather than code. This creates several problems:

  • No version control for configuration changes
  • No code review process for infrastructure updates
  • Difficult to replicate across environments
  • Limited audit trail for who changed what and why

IaC landing zones require more upfront investment but provide significantly better long-term flexibility, cost efficiency, and operational control.

Why We Recommend CDK-Based Landing Zones

Infrastructure as Code landing zones give you five critical advantages:

Full Control: Every resource is defined in code. You know exactly what's deployed, where, and why. No hidden resources created by managed services. When compliance auditors ask questions, you point them to version-controlled infrastructure code.

Cost Efficiency: Control Tower charges $500+ monthly for Account Factory orchestration, Landing Zone dashboards, and managed guardrails. An IaC landing zone costs about $100/month (CloudTrail, Config, GuardDuty, Security Hub). That's 1/5th the ongoing operational cost.

Customization: Control Tower's guardrails are predefined. You can't modify them, only enable or disable. IaC landing zones let you implement exactly the security controls your organization needs. Custom SCPs, tailored Config rules, specific compliance frameworks.

Automation: GitHub Actions or GitLab CI/CD pipelines deploy infrastructure changes. Pull requests trigger validation, approvals gate production changes, and deployment history lives in Git. This is proper infrastructure management.

Compliance: A well-built CDK landing zone achieves 100% CIS AWS Foundations Benchmark compliance out of the box. It includes GuardDuty, Security Hub, Config, centralized logging, encrypted backups, and security monitoring configured correctly from day one.

Our CDK landing zone includes 18+ pre-configured CloudFormation StackSets covering:

  • Organization trails with log file validation
  • Config recording in all regions with multi-account aggregation
  • Security Hub with CIS and AWS Foundational Security Best Practices
  • GuardDuty with S3 Protection and Malware Protection
  • IAM password policy and access analyzer
  • Cost anomaly detection and budget alerts
  • GitHub Actions CI/CD pipeline with OIDC authentication
  • Automated account baseline deployment

New accounts get provisioned in minutes, not hours. Changes deploy through Git workflows with full audit trails. Compliance scores remain at 100% as you scale.

Professional Landing Zone Implementation

Building a production-ready landing zone takes 2-3 months if you're learning as you go. You'll implement security controls, test SCPs, configure monitoring, build account vending automation, and validate compliance.

Or you can get a production-ready landing zone deployed in one week with 100% compliance scores.

We've deployed CDK-based landing zones to YC-backed startups and growing businesses, achieving full CIS benchmark compliance and cutting implementation time by 70%. The landing zone code gets delivered to your repository. The GitHub Actions CI/CD pipeline is included. You own everything.

If you want to skip the learning curve and start with a secure, compliant foundation from day one, explore our AWS CDK Landing Zone service. Available via AWS Marketplace with deployment in under a week.

Implementation Checklist

Whether you're transitioning from a single account to multi-account, or you already have multiple accounts but haven't configured them properly beyond Organizations and SSO, this checklist covers what you need to implement.

Phase 1: Foundation

Set up the organizational structure that everything else depends on.

  • [ ] AWS Organization created in "All Features" mode
  • [ ] Management account secured (no workloads, minimal access, MFA enforced)
  • [ ] Core OUs created (Security, Infrastructure, Workloads, Sandbox)
  • [ ] Essential accounts provisioned:
    • Log Archive account (centralized logging)
    • Security Tooling account (delegated admin for security services)
    • Production and Development accounts
  • [ ] IAM Identity Center enabled

If you already have an Organization, audit your current setup against these requirements before proceeding.

Phase 2: Access Management

Establish centralized identity before defining governance policies.

  • [ ] IAM Identity Center fully configured
  • [ ] External IdP integration (Okta, Google Workspace, Entra ID) if applicable
  • [ ] Permission sets created for each team type:
    • ReadOnly for auditors and support
    • PowerUser for developers
    • Admin for platform team
  • [ ] Permission sets assigned to appropriate groups and accounts
  • [ ] Cross-account access patterns tested
  • [ ] Access request procedures documented

Phase 3: Governance Policies

Define what's allowed and enforce it consistently.

  • [ ] Core SCPs deployed:
    • Region restriction (limit to approved regions)
    • Root user deny (prevent root usage in member accounts)
    • Resource protection (prevent deletion of security controls)
  • [ ] SCPs tested in Policy Staging OU before production deployment
  • [ ] Tag policies created and attached to Workloads OU
  • [ ] Cost allocation tags activated
  • [ ] Budget alerts configured per account
  • [ ] Cost anomaly detection enabled

Phase 4: Centralized Operations

Enable visibility across all accounts.

  • [ ] Organization CloudTrail trail created and delivering to Log Archive account
  • [ ] Log Archive account secured (append-only, KMS encrypted, MFA Delete)
  • [ ] Config recording enabled in all accounts
  • [ ] Config aggregation configured in Audit/Security Tooling account
  • [ ] Security Hub delegated administrator set up
  • [ ] GuardDuty enabled organization-wide with auto-enable for new accounts
  • [ ] Conformance packs deployed for applicable compliance frameworks

Phase 5: Landing Zone Automation

Move from manual configuration to Infrastructure as Code.

  • [ ] Landing zone deployed (CDK-based LZ recommended over Control Tower)
  • [ ] Baseline StackSets deploying security controls to all accounts automatically
  • [ ] Account provisioning automated (new accounts inherit all baselines)
  • [ ] CI/CD pipeline for infrastructure changes (GitHub Actions, GitLab CI)
  • [ ] Compliance validation (target: 100% CIS, 95%+ Security Hub score)
  • [ ] Operational runbooks documented

For Existing Organizations

If you already have AWS Organizations with member accounts but incomplete configuration:

Pre-implementation audit:

  • Backup current SCPs and tag policies
  • Document existing account configurations
  • Identify conflicting resources (standalone CloudTrail trails, individual Config recorders)
  • Communicate changes to all account owners

Clean up conflicts before deploying centralized controls:

# Disable existing Config recorder (will be replaced by organization configuration)
aws configservice stop-configuration-recorder \
  --configuration-recorder-name default

# Delete conflicting trails (will be replaced by organization trail)
aws cloudtrail delete-trail --name existing-trail
Enter fullscreen mode Exit fullscreen mode

Deploy incrementally:

  1. Centralized logging first (organization trail, Config aggregation)
  2. Security monitoring (Security Hub, GuardDuty delegated admin)
  3. SCPs to test OU first, then expand to other OUs
  4. IAM Identity Center and migrate from IAM users

For Workload Migration

If you're moving workloads from a single account to the new multi-account structure:

Resource migration approaches:

  • S3 Buckets: Cross-account replication, then DNS cutover
  • Databases (RDS): Cross-account snapshot copy, DMS for continuous replication
  • Compute (EC2, ECS, Lambda): Redeploy via Infrastructure as Code, blue-green deployment
  • Networking: Set up Transit Gateway or VPC peering before moving applications

Migration order:

  1. Development workloads first (lowest risk, validate process)
  2. Staging workloads (test production-like migration)
  3. Non-critical production
  4. Critical production (planned maintenance windows)

Keep old resources running for 7-14 days after cutover in case you need to roll back.

Ongoing Operations

After initial implementation, maintain the environment:

Weekly:

  • Review Security Hub and GuardDuty findings
  • Check cost anomaly detection alerts
  • Validate backup completion across accounts

Monthly:

  • FinOps review: top cost drivers, optimization opportunities
  • Access reviews: remove unused IAM Identity Center assignments
  • Review Compute Optimizer recommendations

Quarterly:

  • Well-Architected Framework reviews
  • SCP and tag policy optimization
  • Account lifecycle review (decommission unused accounts)
  • Disaster recovery testing

Common Mistakes to Avoid

These mistakes create security vulnerabilities, operational headaches, and compliance failures. Use this as a checklist before and during implementation.

Management Account Misuse

Mistake 1: Running workloads in management account

SCPs don't apply to the management account. Any production workload running there bypasses all governance guardrails. An attacker who compromises a production instance in the management account can modify Organizations, delete accounts, or disable security controls.

Prevention: Deploy an SCP to all OUs that prevents deploying workloads (won't apply to management account, but documents policy). Conduct quarterly audits of management account resources.

Mistake 2: Not using delegated administrators

Managing Security Hub, GuardDuty, and other services directly from the management account increases its attack surface. Every service integration creates additional access paths.

Prevention: Designate a Security Tooling account as delegated administrator for all compatible services. This isolates security management from organizational management.

For more on why delegated administrators are critical for security and how to set them up, see our guide: Why AWS Delegated Administrators Are Essential for Multi-Account Architectures.

Mistake 3: Over-permissioned management account access

The management account should have the fewest users and most restrictive access. It's not a general "admin" account.

Prevention: Limit management account access to 3-5 people (founders, CTO, VP Engineering). All access requires MFA. Review access quarterly.

Over-Engineering Too Early

Mistake 1: 50 accounts for 5-person team

Each account adds operational overhead: monitoring, security configuration, cost tracking, access management. If you have 5 engineers and 50 accounts, you're spending more time managing accounts than building products.

Prevention: Start with 6-8 accounts (Management, Log Archive, Security Tooling, Production, Staging, Development, Sandbox). Add accounts when you have specific isolation requirements.

Mistake 2: Deep OU hierarchies

Prod → US-East-1 → Team-A → Microservice-1 → Feature-X is 6 levels deep. Policy troubleshooting requires checking 6 levels of inherited SCPs. Nobody can debug why actions are denied.

Prevention: Limit OU depth to 3-4 levels maximum. Flat structures are easier to manage.

Mistake 3: Creating accounts for every microservice

10 microservices = 10 accounts. Now you're managing 10x the security baseline, 10x the monitoring configuration, 10x the networking complexity.

Prevention: Group related microservices in accounts based on isolation requirements, not service boundaries. Use IAM roles, VPCs, and security groups for isolation within accounts.

SCP and Policy Mistakes

Mistake 1: Deploying untested SCPs to production

SCPs apply immediately. An overly restrictive SCP can break production workloads instantly, blocking legitimate API calls your applications depend on.

Prevention: Always test SCPs in Policy Staging OU first. Verify all automation roles have necessary exceptions.

Mistake 2: Missing exceptions for automation roles

Your CI/CD pipeline assumes the OrganizationAccountAccessRole to deploy infrastructure. You deploy an SCP restricting EC2 actions. The SCP has no exception for the automation role. Deployments break.

Prevention: All SCPs must include exceptions for OrganizationAccountAccessRole and other automation principals.

Mistake 3: No SCP documentation

Six months later, engineers can't deploy infrastructure. They don't know which SCP is blocking them or why it exists. They request SCP removal, potentially creating security vulnerabilities.

Prevention: Document every SCP with: what it blocks, why it exists, which workloads it protects, and how to request exceptions.

Operational Anti-Patterns

Mistake 1: Manual account provisioning

Creating accounts through the console, manually enabling Config, manually deploying security controls. By account 20, you have 20 slightly different configurations. Configuration drift creates security gaps.

Prevention: Automate account provisioning with Infrastructure as Code. Every account gets identical baseline configuration.

Mistake 2: No centralized logging

Each account has its own CloudTrail trail, Config recorder, and VPC Flow Logs. When you need to investigate a security incident spanning 10 accounts, you're checking 10 different log locations.

Prevention: Organization trails and Config aggregation from day one.

Mistake 3: No account lifecycle management

Accounts accumulate. Proof-of-concept accounts from two years ago still running, accruing costs. Nobody knows what they're for or who owns them.

Prevention: Tag all accounts with Owner, Purpose, and ExpirationDate. Review quarterly. Decommission unused accounts.

While these mistakes are critical in multi-account environments, many teams also miss important configurations in AWS Organizations itself. Learn about the critical Organizations configurations most teams miss including the 8 policy types and 15+ service integrations.

Conclusion

Multi-account architecture requires upfront investment but provides security isolation, operational scalability, and compliance frameworks that support growth from 10 to a few hundred accounts.

Key takeaways:

  1. AWS Organizations forms the foundation - Without it, you can't implement SCPs, consolidated billing, or centralized governance
  2. Access before governance - Establish identity management with IAM Identity Center before defining what actions are allowed
  3. Infrastructure as Code landing zones provide better control - CDK-based landing zones give you full customization, version control, and cost efficiency compared to Control Tower's ClickOps approach
  4. SCPs are your scalable guardrails - They prevent security violations and compliance failures automatically across hundreds of accounts
  5. Centralized logging is non-negotiable - Organization trails, Config aggregation, and delegated administrators provide visibility
  6. Operational excellence requires automation - Manual processes don't scale beyond 10-20 accounts

For a complete overview of building a secure AWS environment, see our AWS Cloud Foundation guide which covers this topic and related best practices.

Next steps:

  1. Assess readiness using the prerequisites checklist
  2. Plan OU structure based on organizational needs and compliance requirements
  3. Establish identity management with IAM Identity Center
  4. Deploy governance policies (SCPs, tag policies)
  5. Enable centralized logging and security monitoring
  6. Deploy a landing zone foundation to automate everything with Infrastructure as Code
  7. Establish operational processes for account lifecycle management

Multi-account architecture is not a one-time project. It's an ongoing operational practice. Success requires balancing security, operational efficiency, and developer productivity. Start with the foundation (Organizations and identity), layer on governance (SCPs and tag policies), enable security monitoring (Security Hub and GuardDuty), deploy automation (IaC landing zone), and continuously optimize.

Written by Danny, Founder @ towardsthecloud → Helping startups cut costs and ship faster on AWS.

FYI; I'm also building cloudburn.io → Help developers catch expensive infra in PR's before they deploy on AWS Cloud.

Top comments (0)