Skip to main content

Multi-Workspace Patterns

This page describes the practical patterns for using multiple workspaces inside a single tenant. If you're new to the model, read Accounts, Tenants & Workspaces first.

The TL;DR: a single workspace is enough for most customers. Add workspaces when you need hard data isolation between environments under the same tenant.

Pattern 1 — Prod / Staging / Lab​

The simplest multi-workspace pattern. You have one customer organization (one tenant) but multiple environments that should never share assets, findings, or credentials.

Tenant "Acme Corp"
├── Workspace "prod"     (default)
├── Workspace "staging"
└── Workspace "lab"
  • Each workspace gets its own AWS credentials (least-privilege scoped to that environment)
  • Discovery runs are independent — staging issues never appear in prod findings
  • Compliance posture is measured per workspace
  • All three workspaces share the same users (members of Acme Corp tenant) — a tenant-admin sees all three

When to use: anytime you want hard environment separation without setting up a separate billing relationship.

Pattern 2 — Multiple AWS Accounts​

You have one company but several AWS accounts (commonly: shared services, prod, dev, govcloud).

Tenant "Defense Co"
├── Workspace "aws-prod"
├── Workspace "aws-dev"
├── Workspace "aws-govcloud"
└── Workspace "on-prem"
  • Each workspace gets credentials for one AWS account
  • Use Infracast's IAM role chaining to keep credentials read-only and scoped
  • Cross-account asset relationships (e.g. peering, cross-account IAM trust) won't appear automatically — you'd need to model these as Business Services or manually as edges if needed
  • Compliance frameworks can be configured differently per workspace (govcloud might require FedRAMP-High while corporate runs FedRAMP-Moderate)

When to use: when AWS Organizations has split your real estate and you want each account scoped independently.

Pattern 3 — MSP Customer Workspaces​

You're an MSP managing many customer environments under one billing relationship.

Two ways to structure this:

Account "Acme MSP"
├── Tenant "Customer A"   ──► Workspace "default"
├── Tenant "Customer B"   ──► Workspace "default"
└── Tenant "Customer C"   ──► Workspace "default"
  • Strong user isolation — Customer A's IT staff can't see Customer B's data even if added to the wrong list
  • Each tenant has its own user roster, MFA policy, branding
  • MSP staff get account-level membership and can switch between tenants
  • Customer-facing reports show only their tenant's data

Option B: Workspaces per customer (simpler for small MSPs)​

Account "Acme MSP"
└── Tenant "Acme MSP Operations"
      ├── Workspace "customer-a"
      ├── Workspace "customer-b"
      └── Workspace "customer-c"
  • Simpler to manage — one user roster, one set of policies
  • All MSP staff see all customers
  • No customer self-service (customers can't log in directly)
  • Less isolation; suitable when MSP fully owns the relationship and customers don't have direct access

Recommendation: use Option A unless you're certain customers will never need direct access.

Pattern 4 — Compliance Scope Separation​

You operate systems with different compliance requirements and need to keep them clearly separated for auditors.

Tenant "Federal Contractor"
├── Workspace "cmmc-l2"      (CMMC Level 2 enclave)
├── Workspace "fedramp"      (FedRAMP Moderate)
└── Workspace "corporate-it"  (Corporate IT, no scope)
  • Each workspace has its own enabled compliance frameworks
  • Evidence and POA&M items don't cross workspace boundaries
  • Auditor reports are generated per workspace, with no risk of in-scope data leaking out
  • A breach finding in corporate-it doesn't pollute the CMMC posture report

When to use: mandatory for any environment with strict scope-control requirements.

Pattern 5 — Subsidiary Isolation​

A holding company with subsidiaries that share billing but isolate data.

Account "ParentCo Holdings"
├── Tenant "ParentCo"        ──► Workspace "default"
├── Tenant "SubsidiaryA"     ──► Workspace "default"
└── Tenant "SubsidiaryB"     ──► Workspace "default"
  • Each subsidiary has its own users (subsidiary staff can't see other subs' data)
  • Billing rolls up at the Account level
  • ParentCo executives with account-level membership can see consolidated reports
  • Subsidiaries can independently add multiple workspaces if their structure warrants it

This is essentially Pattern 3 Option A applied to a corporate structure.

Anti-patterns​

❌ "One workspace per discovery job"​

Don't create workspaces to organize jobs — workspaces are for isolation, not organization. Use scan schedules, business services, or tags to organize within a workspace.

❌ "Workspace per cloud provider"​

If your AWS prod and Azure prod are part of the same operational environment, put them in one workspace. The asset graph is more useful when it shows the full picture, including cross-cloud relationships.

❌ "Workspace per team"​

Use RBAC roles and business service ownership to scope access by team. A workspace is for hard data isolation; team-level scoping doesn't require it.

❌ "Workspace for archives / old data"​

If you need to retain old findings, generate a report and store it. Don't create a workspace just to park stale data — workspaces are licensed (some plans cap workspace count) and incur ongoing cost.

Limits and licensing​

  • Default plan: 1 workspace per tenant (the default workspace, auto-created)
  • Pro plan: up to 5 workspaces per tenant
  • Enterprise plan: unlimited workspaces per tenant
  • Asset count: node licensing is enforced at the Account level (sum across all tenants and workspaces), not per workspace

Check your Settings → Account page for current usage and limits.

Migrating from one workspace to many​

Workspaces are isolation boundaries — there is no built-in "move data between workspaces" operation. If you've been operating in a single workspace and want to split into multiple:

  1. Create the new workspaces (Settings → Workspaces → New)
  2. Configure credentials in each new workspace (you'll need to re-create them; they don't move)
  3. Run discovery in the new workspaces (each workspace will discover its own assets independently)
  4. Once new workspaces are populated, optionally delete stale data from the original workspace using Settings → Cache & Data purge tools

This is intentional. Splitting environments is a deliberate operational decision, and re-running discovery against the new structure is the most reliable way to ensure data is correctly scoped.