Multi-account anti-patterns · ZopDev University

Outcome

By the end of this lesson, you will be able to recognize the five most common multi-account anti-patterns, diagnose them in your own org, and outline a remediation path for each.


Prerequisites	M4.4.L1-L4 (multi-account fundamentals)
Time	8 minutes

1. Concept

Five mistakes turn up again and again, in companies that have nothing else in common.

Each started as a reasonable shortcut when the estate was small. Each then became load-bearing, which is what makes them hard to undo rather than merely wrong.

Recognising yours is the whole of the first step.

ANTI-PATTERN 1   One account for everything
ANTI-PATTERN 2   Per-engineer accounts
ANTI-PATTERN 3   Per-microservice accounts
ANTI-PATTERN 4   Prod and non-prod mixed in same account
ANTI-PATTERN 5   No shared services account

Anti-pattern 1: One account for everything

The most common historical pattern. The company started small, opened one cloud account, and never split it. It works at first; it fails at scale.

SYMPTOMS:
  - One IAM blast radius for the entire org
  - Hard to apply different policies per workload
  - Quotas hit harder than they should
  - Billing all rolled up; per-team attribution requires tags
    that are never quite right
  - One tag-misconfigured Terraform run can affect prod

PROBLEM SCALE:
  Each of these issues gets worse with team size. By the time
  you notice, you have months of debt to unwind.

FIX:
  Phase 1 (most critical): separate prod from non-prod
    Two accounts; mandatory minimum

  Phase 2: separate dev/test/staging
    3-4 accounts; environment isolation

  Phase 3: per-team accounts within each env
    about 10 accounts for a mid-size org; team accountability

  Phase 4: security + audit accounts (the shared-services
    account often comes earlier; see AP5)
    ~12 accounts; well-architected steady state

Each phase delivers value standalone: don’t wait until you have time to do all four. Start with prod/non-prod and earn the credibility to keep going.

Anti-pattern 2: Per-engineer accounts

The opposite extreme: a well-meaning attempt at isolation that overshoots. “Each engineer gets their own AWS account” sounds clean and quickly becomes operational misery.

HISTORICAL CONTEXT:
  Often emerges from a single hard incident (a junior engineer's
  experiment took down prod). The reaction is: never let anyone
  share an account. Per-engineer accounts feel like maximum safety.

SYMPTOMS:
  - 30+ accounts for a 30-engineer team
  - Engineers can't collaborate on shared resources easily
  - Cross-team services impossible
  - Operational overhead enormous (IAM, networking, billing,
    monitoring all multiply by 30)
  - Lock-in to specific engineers (when they leave, their account
    becomes a graveyard)

FIX:
  Per-team accounts, typically 5-12 for a mid-size org. Engineers
  are users within their team's account, sharing infrastructure
  with collaborators. The original incident (a junior breaking
  prod) is fixed by RBAC + production-account access controls,
  not by account proliferation.

If you find yourself with per-engineer accounts, the consolidation is multi-quarter work but the operational reduction is significant.

Anti-pattern 3: Per-microservice accounts

A similar overreach but at the service granularity. “Microservices = isolation = each service gets an account.”

SYMPTOMS:
  - 100+ accounts for an estate of 100 microservices
  - Cross-service networking becomes a major project
  - IAM policies multiply: each service needs to access
    shared resources (S3 buckets, secrets, monitoring)
  - Cost: per-cross-account API call, per-cross-account
    networking, per-account standing infrastructure
  - Engineering velocity drops sharply

FIX:
  Group microservices by team OR by environment. A team's
  10-20 microservices share an account. Within the account,
  each service has its own IAM roles, security groups, etc.,
  but they share the account's networking and observability.

  Per-env (dev/staging/prod) within per-team is usually the
  right granularity.

The microservices-equals-account fallacy comes from confusing two kinds of isolation: service-level (which IAM, security groups, and namespaces provide cheaply) and account-level (which provides blast-radius isolation at much higher operational cost).

Anti-pattern 4: Prod and non-prod mixed

The “we’ll separate them eventually” temporary measure that becomes permanent.

SYMPTOMS:
  - Same IAM policies apply to dev and prod resources
  - Test workloads can accidentally affect prod resources
    (shared VPCs, shared databases, shared S3)
  - Different security postures impossible (prod needs more
    rigorous, dev needs less)
  - Compliance: prod data and non-prod data mingle:
    SOC 2 / ISO findings inevitable
  - Cost-management approaches contradict (schedule non-prod
    aggressively vs leave prod alone: but they're the same
    instances?)

FIX:
  Mandatory split: prod and non-prod ALWAYS in separate
  accounts. This is the minimum-viable multi-account
  structure. Even single-team orgs should do this.

  Migration is tractable:
    - Stand up new prod account
    - Migrate prod workloads in waves (DNS cutover per service)
    - Lock down the original account; let non-prod live there
    - Optionally: split non-prod further later

This is the single highest-impact split. If you do nothing else, do this.

Anti-pattern 5: No shared services account

Every account runs its own DNS, monitoring, logging, security tools, CI/CD agents. Looks decentralized; is actually wasteful and inconsistent.

SYMPTOMS:
  - DNS records duplicated across accounts (drift inevitable)
  - Monitoring tools running in every account (cost multiplied)
  - Security tools redundant (Cloudtrail in every account,
    paid per-account, but mostly empty)
  - Log aggregation incomplete (no single pane of glass)
  - Engineers maintaining N copies of common infrastructure

FIX:
  Stand up a dedicated shared-services account
  Move there:
    - DNS (Route 53 hosted zones)
    - Monitoring (CloudWatch dashboards, alarms)
    - Log aggregation (CloudWatch Logs destination, S3 archive)
    - Security tools (GuardDuty master, Security Hub)
    - CI/CD runners (shared GitHub Actions runners, etc.)
    - Container registries (shared ECR / Artifact Registry)

  Cross-account access from workload accounts to shared
  services via cross-account IAM (well-understood pattern).

The shared-services account is usually the second account a customer stands up after the prod/non-prod split. The cost savings from deduplication are real; the consistency benefits are larger.

Diagnostic checklist

A 5-minute diagnostic to identify which anti-patterns apply to your org:

QUESTION                                                YOUR ANSWER
──────────────────────────────────────────────────────────────────
1. Do prod and non-prod live in different accounts?      Y / N

2. Account count vs employee count ratio?                _____ : _____
   (per-engineer is ~1:1; per-team is ~1:10-20)

3. Is there a dedicated shared-services account?          Y / N

4. Do microservices have their own accounts?              Y / N

5. Does any one account hold > $500K/mo of spend?         Y / N
   (concentrated risk if yes)

6. Can a single IAM role mutation affect both prod and    Y / N
   non-prod simultaneously?
   (yes = anti-pattern 1 or 4)

Most orgs find one or two anti-patterns in their answers. The fix is rarely all-at-once; phased migration is the norm.

How ZopNight surfaces these

ZopNight does not detect these anti-patterns for you, but you can read the signs in its reports:

SYMPTOM IN ZOPNIGHT                          UNDERLYING ANTI-PATTERN
──────────────────────────────────────────────────────────────────
One cloud-account holds 80%+ of spend         AP1 or AP4
                                              (everything-in-one)

"Unattributed" team spend > 15%               AP1 (no account-level
                                              billing separation)

30+ small cloud-accounts (< $1K each)         AP2 or AP3 (over-isolation)

Same tags appearing in prod and dev           AP4 (mixed-environment)
                                              accounts → audit risk

For customers running into these patterns, ZopNight’s solution architects can advise on phased migration.

2. Demo

A mid-size company at the inflection point:

COMPANY:  ~150 employees, ~70 engineers
CURRENT:  3 AWS accounts (acme-main, acme-test, acme-personal-sandbox)
SPEND:    $2.0M/mo (mostly in acme-main)

DIAGNOSTIC:
  Q1: prod/non-prod separation? Partial (test ≠ main, but main has
      both prod and "developer convenience" workloads)
  Q2: account-to-employee ratio? 3:150 (heavily under-isolated)
  Q3: shared services? None: DNS, monitoring all in acme-main
  Q4: microservice accounts? No (good)
  Q5: concentrated risk? Yes (acme-main holds $1.8M/mo)
  Q6: single IAM role can affect both prod and convenience workloads? Yes

  PRIMARY ANTI-PATTERNS: AP1 (one account for everything) +
                         AP4 (prod and non-prod mixed) +
                         AP5 (no shared services)

REMEDIATION PLAN (target state, 4 quarters):
  Q1: Stand up acme-management, acme-security, acme-shared-services
      Migrate DNS, monitoring, security tools to shared services

  Q2: Stand up acme-prod, acme-staging
      Migrate prod workloads from acme-main to acme-prod
      Decommission convenience workloads in acme-main

  Q3: Stand up per-team accounts (5-7 teams)
      Migrate team-specific workloads

  Q4: Steady state: ~12 accounts, well-architected
      Decommission acme-main

TARGET STRUCTURE (12 accounts):
  acme-management
  acme-security
  acme-shared-services
  acme-prod
  acme-staging
  acme-dev-shared
  acme-platform-team
  acme-product-team
  acme-data-team
  acme-ops-team
  acme-experiments
  acme-sandbox

EFFORT: ~2 engineers part-time across 4 quarters.
PAYOFF: blast radius dropped 10×; per-team accountability;
        compliance-ready structure.

3. Hands-on (5 min)

Audit your own structure:

CURRENT ACCOUNT COUNT:    _____
EMPLOYEE COUNT:           _____
RATIO (accounts:employees): _____

DIAGNOSTIC CHECKLIST (✓ / ✗):
  □ prod and non-prod in different accounts
  □ at least one dedicated shared-services account
  □ at least one security/audit account
  □ no microservice-per-account structure
  □ no account holds >50% of total spend
  □ tagging discipline > 90% (low if structurally needed)

ANTI-PATTERNS IDENTIFIED:
  □ AP1 (single account)
  □ AP2 (per-engineer)
  □ AP3 (per-microservice)
  □ AP4 (prod + non-prod mixed)
  □ AP5 (no shared services)

REMEDIATION PRIORITY (rank by impact):
  1. __________
  2. __________
  3. __________

NEXT QUARTER TARGET:    __________

If no anti-patterns surface, that’s a healthy multi-account posture: confirm with the rest of the checklist before declaring victory.

4. Knowledge check

Q1

“30 per-engineer accounts” is:

A. Best practice: maximum isolation
B. Anti-pattern
C. Required for compliance
D. Reasonable while the team is under fifty people

Show answer

Correct: B. Per-engineer isolation defeats collaboration, multiplies operational overhead, and creates engineer-specific lock-in. Per-team accounts (5-12 typical for mid-size) is the right balance. The original safety concern is addressed by RBAC, not by account proliferation. Per-engineer is too granular. RBAC handles the safety concern with much less operational cost.

Q2

A company has 1 AWS account for everything. The right first step:

A. Stay single-account; tags will solve attribution
B. Stand up 50 accounts immediately
C. Split prod from non-prod. Then per-team accounts
D. Move everything into a single new organisation first

Show answer

Correct: C. This is the highest-impact single change: addresses the biggest compliance risk (prod and non-prod mingling) and the biggest blast-radius concern. Then shared services. Phased over multiple quarters. Phased migration starting with prod/non-prod. The other splits earn their value once the foundation is right.

Q3

A microservices estate with 100+ services. Per-service accounts:

A. Optimal isolation
B. Required for microservice purity
C. Correct, since each service owns its own blast radius
D. Anti-pattern

Show answer

Correct: D. Group services by team or by environment The operational cost (per-account networking, IAM, observability) exceeds the isolation benefit, which IAM and namespaces provide at much lower cost. Per-service is too granular; per-team-per-env is usually right. Service-level isolation lives in IAM, not in account boundaries.

5. Apply

Audit your structure annually. The anti-patterns crystallize over time: what was a small workaround becomes a structural problem. The ZopNight Solution Architects can review the structure as part of onboarding or quarterly reviews.

For new orgs, start with the canonical 3-account split (management / security / workloads); expand to the 12-account well-architected pattern as the org grows past 50 employees.

Glossary terms touched

Shared services account

Module quiz

Complete M4.4 → 10-question module quiz.

Outcome

1. Concept

Anti-pattern 1: One account for everything

Anti-pattern 2: Per-engineer accounts

Anti-pattern 3: Per-microservice accounts

Anti-pattern 4: Prod and non-prod mixed

Anti-pattern 5: No shared services account

Diagnostic checklist

How ZopNight surfaces these

2. Demo

3. Hands-on (5 min)

4. Knowledge check

Q1

Q2

Q3

5. Apply

Related lessons

Glossary terms touched

Module quiz

Start with the bill.