multi-account-from-day-one

name: multi-account-from-day-one description: "This skill should be used when the user is setting up a new cloud project, designing account or project structure, creating environment isolation, configuring organization units or management groups, implementing landing zones, or deciding how to separate dev and prod workloads. Covers multi-account strategy, blast radius isolation, landing zone setup, and organizational governance." version: 1.0.0

Separate Accounts Before You Write a Single Resource

Running development and production in a single cloud account is the most common shortcut in early-stage infrastructure, and it is cheap to fix on day one -- one afternoon of work. Six months later, when production databases share IAM policies with developer sandboxes, when billing is an undifferentiated blob, and when a misconfigured dev deployment takes down prod, the fix becomes a full migration measured in weeks. Multi-account isolation is not a scale concern. It is a day-one concern.

Why Single-Account Fails

A single cloud account creates invisible couplings that compound over time:

The longer you wait, the worse each problem gets. Resources accumulate. IAM policies intertwine. Developers build tooling that assumes a single account. Every day you delay makes the eventual migration more expensive.

The Minimum Viable Account Structure

Start with six accounts or projects. This is the minimum that provides meaningful isolation:

Organization Root
├── Management Account          -- SSO, billing, organization policies
│
├── Security OU                 -- (GCP: Folder, Azure: Management Group)
│   ├── security                -- Centralized security services
│   └── log-archive             -- Immutable, centralized audit logs
│
├── Sandbox OU
│   └── sandbox                 -- Unrestricted experimentation, no prod access
│
└── Workloads OU
    ├── dev                     -- Development workloads
    └── prod                    -- Production workloads

Six accounts. One afternoon. This gives you environment isolation, a dedicated security boundary, centralized audit logging, a safe experimentation space, and clean billing separation from day one. All three major cloud providers (AWS Control Tower, GCP Cloud Foundation Toolkit, Azure Landing Zones) include a centralized logging account by default.

When to Add More Accounts

As your team and workloads grow, expand the structure:

Do not create person-specific accounts. Use team-based identities and shared accounts with role-based access. Person-specific accounts create credential sprawl and make offboarding a security risk.

Landing Zones: Automate Account Governance

Manually creating accounts and configuring guardrails does not scale past three accounts. Use your cloud provider's landing zone tooling to automate account provisioning, enforce baseline policies, and centralize governance.

A landing zone provides:

• Automated account provisioning with baseline security configuration
• Guardrails (preventive and detective) applied organization-wide
• Centralized logging routed to a dedicated log archive
• Identity federation configured once, inherited by all accounts

Good Pattern: Landing Zone with Guardrails

# Organization structure -- Terraform manages the hierarchy
resource "cloud_organization" "root" {
  feature_set = "ALL"
}

resource "cloud_organizational_unit" "security" {
  name      = "Security"
  parent_id = cloud_organization.root.roots[0].id
}

resource "cloud_organizational_unit" "workloads" {
  name      = "Workloads"
  parent_id = cloud_organization.root.roots[0].id
}

resource "cloud_organizational_unit" "workloads_prod" {
  name      = "Production"
  parent_id = cloud_organizational_unit.workloads.id
}

resource "cloud_organizational_unit" "workloads_dev" {
  name      = "Development"
  parent_id = cloud_organizational_unit.workloads.id
}

Bad Pattern: Everything in One Account with Tags

# DO NOT DO THIS -- "environment" tags are not isolation boundaries
resource "cloud_instance" "web" {
  instance_type = "t3.micro"
  tags = {
    Environment = "prod"   # This tag does NOT prevent dev from touching it
  }
}

resource "cloud_instance" "web_dev" {
  instance_type = "t3.micro"
  tags = {
    Environment = "dev"    # Same account, same IAM, same blast radius
  }
}

Tags are metadata, not security boundaries. An IAM policy that grants ec2:* in a single account grants it to both "prod" and "dev" tagged resources. Only account-level separation provides true isolation.

Identity and Access Across Accounts

Centralize identity in the management account. Federate from an external identity provider (Google Workspace, Okta, Microsoft Entra ID) so that disabling a person in the IdP immediately revokes all cloud access.

Three Permission Tiers

Developers should have full access in dev and sandbox but only read-only access in production. Targeted exceptions allow specific actions like viewing logs, connecting to debugging sessions, or reading container registries. No one should have permanent write access to production -- use time-boxed elevated access for incident response.

CI/CD Authentication: No Static Credentials

CI/CD pipelines authenticate to each account via workload identity federation (OIDC), not static API keys. Each account has its own CI/CD role with a trust policy restricting which repositories can assume it. This means zero stored secrets in your CI/CD system -- no API keys to rotate, no credentials to leak.

The multi-account angle: every account needs its own OIDC role. The trust policy in the dev account allows broader repository access (any branch), while the production account restricts to tag refs only (see the tag-based-production-deploys skill for the tag-driven deployment model). For the complete OIDC setup (provider configuration, trust policies, subject claim restrictions, per-provider Terraform), see the zero-static-credentials skill.

Account Email Convention

Use distribution lists or group aliases for account root emails, never personal addresses:

cloud-management@mycompany.com     -- Management/root account
cloud-security@mycompany.com       -- Security account
cloud-log-archive@mycompany.com    -- Log archive account
cloud-sandbox@mycompany.com        -- Sandbox account
cloud-dev@mycompany.com            -- Development account
cloud-prod@mycompany.com           -- Production account

Personal email addresses tied to accounts create single points of failure. When that person leaves, account recovery becomes a support ticket nightmare.

Cloud Provider Translation

Examples

Working implementations in examples/:

• examples/organization-structure.md -- Terraform module that creates a six-account organization with OUs, account email conventions, and baseline policies
• examples/cross-account-roles.md -- Terraform configuration for CI/CD OIDC federation and developer cross-account access with least-privilege permissions

Review Checklist

When designing or reviewing cloud account structure:

• Dev and prod workloads run in separate accounts or projects, never co-located
• A dedicated security account exists for centralized security services
• A dedicated log-archive account exists for immutable, centralized audit logs
• A sandbox account exists for unrestricted experimentation, isolated from dev and prod
• The management/root account contains no application workloads
• Landing zone automation is used for account provisioning and guardrails
• Account root emails use team distribution lists, not personal addresses
• Identity is federated from an external IdP, not managed natively in the cloud provider
• Developers have full access in dev but read-only access in prod
• CI/CD uses OIDC federation per account, not static credentials
• No person-specific accounts exist; all accounts are team-based
• Each account has independent state files and deployment pipelines
• Service quotas are monitored per account to prevent cross-environment interference
• Billing is reviewable per account without relying solely on tags