Multi-Tenant

Multi-tenancy means serving many customers from one deployment while keeping their data and access isolated. Axis gives you the primitives; the pattern is how you arrange them. This is a composition sketch — there is no dedicated multi-tenant example project, so treat the shapes below as a starting point to adapt.

Data isolation

The common Axis approach is a tenant partition key: a single AtfDynamo table whose partition key encodes the tenant (TENANT#<id>), so every query is naturally scoped and one table serves all tenants. A GSI can support cross-tenant admin queries where genuinely needed. The alternative — a table per tenant — trades operational simplicity for stronger blast-radius isolation and is a raw-CDK extension, not a config-array pattern.

Access isolation

Carry the tenant identity in the auth token (AtfCognito custom claims) and enforce it in service code — a request for tenant A must never resolve tenant B’s partition. The auth matrix decides who authenticates; your service code decides what they can reach.

Where the boundary sits

The framework does not enforce tenant isolation for you — it can’t know your tenancy model. The boundary is your service code plus your key design. Axis makes both explicit and testable (partition keys in typed config, auth in typed route configs), which is the point.

Where to go next

• DynamoDB Tables for the key and GSI design.
• The Auth Matrix for carrying tenant identity.