Cloud Multi Account Strategy

This is a set of engineering practices for structuring cloud infrastructure across multiple accounts, designed to manage access, isolation, and operational complexity at scale. It applies when deploying systems that span multiple teams, environments, or compliance domains and require distinct account boundaries for security, billing, or governance.

When to Apply This Strategy

Use this approach when you have more than one team managing cloud resources, need different levels of access control, or must isolate workloads by compliance domain, business unit, or environment type. It's particularly relevant when your organization has grown beyond a single shared account and needs clear boundaries without abandoning the benefits of centralized tooling.

Account Structure and Naming

Define a consistent naming scheme for accounts that reflects their purpose. For example:

company-frontend-prod
company-backend-staging
company-data-lake-dev
company-security-audit

Use a standard prefix across all accounts to enable automation. Avoid account names that depend on specific platform features, as these are not portable.

Cross-Account Access Patterns

To grant access from one account to another, use IAM roles with trust policies. The role in the target account must trust the source account's principal:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

This trust policy allows the account with ID 123456789012 to assume the role in the current account.

Identity Federation and Cross-Account Access

Set up identity federation using a directory service (such as Active Directory or Okta) that supports SAML or OIDC. Configure each account's IAM identity provider to trust tokens from your identity provider. The federation must be set up in each account where access is needed.

Example: Create an IAM identity provider with the following configuration:

ProviderName: "saml-provider"
ProviderType: "SAML"
MetadataDocument: |
  <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://your-idp.example.com/saml">
    <!-- SAML metadata -->
  </EntityDescriptor>

The role in the target account must have a trust policy that includes the federated identity provider's ARN:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/example.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity"
    }
  ]
}

Use resource-based policies to allow cross-account access to resources like S3 buckets or DynamoDB tables. For example, to allow another account to read from an S3 bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:root"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Shared Services and Resource Ownership

Establish a pattern where shared services (like logging, monitoring, or IAM) are owned by one account and made available to others. The consuming accounts use roles or resource-based policies to access these shared resources.

For example, a central logging account might own an S3 bucket for logs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::central-logs/*"
    }
  ]
}

Access Control and Role Management

Avoid granting direct access to accounts. Instead, create roles that teams assume for specific tasks. This includes the use of temporary credentials when accessing resources from one account while operating in another.

When creating roles, always set a maximum session duration:

RoleName: "DeveloperAccess"
MaxSessionDuration: 3600

Cost Allocation and Billing

Implement cost allocation tags that can be used across accounts to track usage. Each resource should have a tag indicating the team, environment, or project it belongs to.

Example tag structure:

{
  "CostCenter": "Engineering",
  "Environment": "production",
  "Project": "web-app"
}

These tags must be applied consistently across all accounts and resources to enable accurate billing allocation.

Operational Considerations

Keep a central inventory of account IDs, names, and owners. Use automation to manage this list, and ensure it's regularly updated. The inventory should include:

Account ID
Account Name
Owner Team
Purpose (e.g., Production, Development)
Contact Information

Multi-Account Deployment Considerations

When deploying resources across multiple accounts, use infrastructure-as-code tools that support cross-account operations. For example, when using Terraform, specify the account ID in each provider block:

provider "aws" {
  region = "us-east-1"
  profile = "production"
  assume_role {
    role_arn = "arn:aws:iam::123456789012:role/DeploymentRole"
  }
}

IAM Role Trust Policy Gotchas

The trust policy in the target account must explicitly include the principal that will assume the role. If a user in account A tries to assume a role in account B, but account B's trust policy doesn't include account A, the operation fails with:

AccessDenied: User: arn:aws:iam::123456789012:user/developer is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::987654321098:role/TargetRole

Resource-Based Policy Limitations

Resource-based policies work only for specific services. S3 and DynamoDB support them, but EC2 does not. For EC2 resources, use IAM roles with trust policies to provide access.

Cross-Account Access Failures

A common failure mode occurs when a role in one account has the correct trust policy, but the role itself lacks sufficient permissions for the target operation. For example, if you assume a role that allows you to read from S3 but not to list buckets, you might get:

AccessDenied: User: arn:aws:iam::123456789012:user/developer is not authorized to perform: s3:ListBuckets on resource: arn:aws:s3:::*

Shared Resource Ownership Challenges

When multiple accounts share a resource (like an S3 bucket), ensure that the role used by each account has the correct permissions. If one account modifies the resource-based policy and removes access for another, that account will lose access.

Cost Allocation Tagging Failures

If tags are missing from resources or applied inconsistently, cost allocation reports become inaccurate. Ensure all new resources include appropriate tags during creation.

Account Migration and Drift

When moving resources between accounts, ensure that IAM policies, resource-based policies, and trust relationships are updated accordingly. A resource may appear to work but fail when accessed from a different account due to missing access controls.

Multi-Account Monitoring and Logging

Centralize monitoring across accounts by configuring cross-account log aggregation. Use CloudWatch Logs Insights or similar tools to query logs from multiple accounts. Ensure that the IAM roles used for log aggregation have appropriate permissions in each account.

Cross-Account Backup and Disaster Recovery

When implementing backups, ensure that backup roles have access to all relevant accounts. If a backup role is configured only for one account, it will fail when trying to back up resources in other accounts.

Cross-Account VPC Peering

When peering VPCs across accounts, ensure that route tables and security groups are properly configured in both accounts. A VPC peering connection can be established, but if the routing is not set up correctly in both directions, communication will fail silently.

IAM Policy Evaluation and Permissions

Use IAM policy simulator tools to verify access before deploying. The simulator helps identify when a user or role has insufficient permissions for operations they expect to perform.

Multi-Account Security and Compliance

Each account should have its own security baseline. Implement guardrails using AWS Config rules, CloudTrail logging, and IAM policies that enforce security requirements in each account independently.

Operational Tooling

Use CLI tools like aws sts assume-role to test cross-account access:

aws sts assume-role \
  --role-arn arn:aws:iam::987654321098:role/TargetRole \
  --role-session-name TestSession

The response will include temporary credentials that can be used for further operations.

Cross-Account Resource Dependencies

When one account depends on resources in another, create explicit dependencies in your infrastructure-as-code. For example, when creating a Lambda function that reads from an S3 bucket in another account, ensure the Lambda's execution role has permissions to read from that bucket.

Identity Provider Configuration Errors

If identity federation fails, check that:

The identity provider is correctly configured in each account
The trust policy includes the correct ARN for the identity provider
Session policies are properly applied
The federation endpoint is accessible from the user's location

Cross-Account Resource Tagging Standards

Enforce tagging standards across all accounts. A common mistake is inconsistent use of tag keys or values, which breaks cost allocation and resource management.

Access Control Testing

Regularly test cross-account access using tools like aws sts get-caller-identity to ensure the role being assumed has the expected permissions and account context.

Cross-Account Audit Trails

Enable CloudTrail in all accounts and centralize logs. Ensure that the IAM roles used for logging have appropriate permissions to write to the central logging account.

Role Session Duration Management

Set consistent session duration limits across all accounts. Shorter durations (like 1 hour) provide better security, while longer durations (like 8 hours) reduce credential rotation overhead.

Cross-Account Policy Drift

Monitor for policy changes that may affect cross-account access. A change in the trust policy of a role can silently break access from other accounts without notice.

This strategy provides a framework for managing cloud infrastructure across multiple accounts while maintaining clear boundaries, consistent access patterns, and operational reliability.

This page was rewritten on 16 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.