Skip to content

PATTERN Cited by 1 source

Multi-account AWS isolation

Use separate AWS accounts as the primary isolation boundary to segregate environments by purpose (training / ingest / serving / analytics), not just by tenant. Distinct from account-per-tenant (which uses accounts to separate customers) — this pattern uses accounts to separate workload purposes within a single product.

Shape

Typical split for an ML-serving product:

  • Ingest / raw-data account — access-restricted; raw PII-bearing data lands here; auto-purge policies + PII-scrubbing pipelines run here. No direct access from other accounts.
  • Training-pipeline account — hosts ground-truth labelling jobs + training pipelines + model registry. Reads anonymised data replicated from the ingest account.
  • Inference / web-app account — serves live production traffic; hosts the end-user application + inference endpoints.
  • Analytics / BI account — dedicated to reporting + trend analysis; BI team develops here without touching production systems.

Data moves between accounts only via explicit, narrow replication paths with access controls on each hop — typically anonymised copies, never the raw PII-bearing artefact.

Why it works

  • PII containment. Raw images / logs / inputs with faces, license plates, identifiers never leave the restricted ingest account; only anonymised derivatives propagate.
  • Blast-radius containment. A bug in the BI analytics account can't corrupt training data. A compromised inference environment can't access raw ingest data. See concepts/blast-radius.
  • Access-control simplicity. IAM policies per account stay small
  • reviewable; cross-account roles are explicit + auditable.
  • Cost / billing attribution. Each workload's spend is its own linked account — identifies runaway compute or storage without tag hygiene.
  • Regulatory alignment. Separate accounts align cleanly with compliance requirements that mandate data-processing segregation (GDPR, HIPAA, PCI).

Distinct from account-per-tenant

Dimension Multi-account isolation (this pattern) concepts/account-per-tenant-isolation
Axis of separation Workload purpose Customer / tenant
Account count Small fixed (~4–10) Proportional to customer count
Primary goal Security + compliance + blast radius Per-tenant cost attribution + quota isolation
Canonical example AWS safety-monitoring (this source) ProGlove Insight (~6,000 accounts)

Both use the AWS account boundary as the structural isolation primitive. They often compose (product uses multi-account-per-purpose on its control side, account-per-tenant on its data side).

Seen in

  • sources/2026-04-01-aws-automate-safety-monitoring-with-computer-vision-and-generative-ai — canonical wiki instance for purpose-axis multi-account separation. "To maintain proper security and operational segregation, the solution is distributed across multiple AWS accounts. We separated the training pipeline, image collection infrastructure, end-user web application, and created a dedicated analytics account for the BI team to develop reporting and insights solutions into distinct environments with appropriate access controls and data isolation." Raw images land in an access-restricted account + auto-purge within days after Rekognition-based face-blurring; anonymised copies then replicate across the training / inference / app / analytics accounts for their specific downstream roles.
Last updated · 200 distilled / 1,178 read