apointoo.
Request access
HIPAA

DynamoDB Tenant Partitioning: Keys, Queries, and Limits

cmsapointoo··10 min read

Short answer: DynamoDB tenant partitioning can make access patterns predictable, but a partition key is not a database-enforced tenant boundary. As of 2026-08-15, Amazon Web Services documents access-pattern-first modeling, request and storage pricing, and condition-based controls. A protected workload still needs server-side membership checks, least-privilege identities, negative tests, and a clear plan for scans, exports, backups, and support access.

AWS service fit and regional boundary

DynamoDB is a good fit only when known access patterns drive the model. The AWS Data Modeling Foundations guide starts with the questions an application must answer, then maps those questions to keys and indexes. The pricing page adds request, storage, and index cost inputs. Neither page says that a table partition is a legal or regulatory boundary, so the article’s safe claim is narrower: DynamoDB can support a tenant-aware design when application and identity controls are verified around it.

Decide the residency unit first. A table in one region is not automatically suitable for every tenant, and a global replication feature changes the data path. Record each tenant’s home region, table or account assignment, key location, log destination, backup location, and support route. A browser-provided region must never select the destination. The authenticated server-side membership record should resolve the tenant and its home region.

Partitioning is an access-pattern decision, not an isolation slogan. Start with operations such as read one booking, list a tenant’s recent events, write an idempotent outcome, reconcile one opaque reference, and export an approved tenant dataset. For each operation, identify its partition key, sort key, index, authorization check, and expected failure when the caller lacks membership.

Operation Model input Required proof
Tenant list Tenant key and bounded sort order Same-tenant results only
Single record Tenant key plus opaque record key Wrong-tenant read denied
Event write Idempotency key and server tenant Replay does not cross tenant
Export Approved scope and operator identity Scope and audit review

Read DynamoDB LeadingKeys conditions for an identity-control layer, and compare the model with RDS PostgreSQL and DynamoDB before treating a rewrite as a cost choice.

Request, data, key, and identity path

The request must carry less authority than the server can derive. Do not accept a tenant key from the browser as proof. Resolve the caller, membership, and home region on the server, then construct the DynamoDB key from that trusted context. A request that supplies another tenant prefix should either be rejected before DynamoDB or produce no data and an auditable denial.

Use a stable namespace that cannot be confused with user input. A conceptual key such as TENANT#<server-tenant-id> with a sort key such as BOOKING#<opaque-record-id> can make the intended pattern visible, but the string itself is not enforcement. Every helper that creates a key must receive a server-resolved tenant, and every alternate read path must be reviewed. Tests should cover list, point read, update, delete, transaction, batch, and index operations.

Do not put unnecessary personal or clinical detail into a shared item. For an attribution record, a generic event name, event time, currency, value, and approved opaque reference may be enough. Never design an advertising payload around a patient name, email, phone, hashed identifier, service name, treatment detail, or free-text note. Keep a booking source of truth separate from analytics reconciliation data.

authenticated caller
  -> server membership lookup
  -> immutable tenant and home region
  -> key builder using server context
  -> DynamoDB operation
  -> scoped result or denial
  -> redacted audit event

Keys, indexes, and IAM conditions must agree. An index can introduce a query that was not in the first design. A batch operation can hide multiple tenant keys. A transaction can combine records from an unintended namespace. Add these variants to the design review rather than declaring the primary query safe.

Queue, audit, backup, and failure handling

Partitioning fails where an unreviewed operation bypasses the intended key. Review Scan, Query against every index, BatchGet, BatchWrite, transactions, exports, administrative consoles, backup restores, and support tooling. A successful point-read test proves only that point-read path. It does not prove that a report job or recovery operator cannot enumerate another tenant.

Use explicit denial tests. Create synthetic records for two tenants, authenticate as each, and run every read and write path. Attempt a key substitution, an index query, a scan, a batch containing mixed keys, and a restore into a test table. The expected result is denial, empty scope, or a controlled review queue according to the operation. Record which layer made the decision.

Audit events should describe the action without copying the item. Include principal, server tenant, operation, result, timestamp, and reason code. A failed conditional write can produce useful evidence without exposing the full booking record. Keep queue and dead-letter payloads equally narrow. If a retry needs a database lookup, let it use an authorized identity rather than carrying a complete sensitive object.

Backups preserve the model but do not preserve authorization automatically. A restore test must reapply table policies, role policies, key access, and application checks. A support export must be a separately authorized operation with an explicit tenant scope, expiration, and audit record. Set retention from the risk analysis, contracts, and operational need instead of keeping every record indefinitely.

Cost and proof gate

DynamoDB pricing is dominated by assumptions about requests, storage, indexes, and traffic shape. The AWS pricing page is volatile, so any estimate should state region, on-demand or provisioned mode, read and write sizes, index count, storage, backups, data transfer, and retrieval date. The key design can lower unnecessary reads, but it cannot remove the cost of logs, recovery, review, and tests.

Do not use low request cost to justify weak isolation. A new access pattern may require an index or denormalized item, while a report may require a separate controlled path. Price the engineering work to model and test the patterns. If the workload needs ad hoc relational reporting, compare the rewrite and operating floor with PostgreSQL instead of forcing every question into a key-value shape.

  • Write the access-pattern inventory before table creation.
  • Assign one server-side tenant context to every operation.
  • Test indexes, batch calls, transactions, scans, exports, and restores.
  • Keep queue and audit payloads minimum necessary.
  • Recalculate current AWS rates before any commercial or migration decision.

Runnable partitioning review

The minimum useful proof is a two-tenant negative test. Use synthetic data and a separate test table. The test should fail the build or review when an operation returns a record from the wrong tenant.

  1. Create distinct records for tenant A and tenant B.
  2. Authenticate each tenant and run point reads, lists, updates, deletes, batch calls, transactions, and index queries.
  3. Attempt a Scan and an export using the tenant role.
  4. Attempt an administrative restore using a separate operator role.
  5. Inspect logs, queues, backups, and support artifacts for unnecessary data.
  6. Repeat after changing key builders, indexes, IAM policies, and deployment configuration.

Keep a matrix of operation, identity, tenant context, expected result, observed result, and reviewer. If one operation remains application-enforced, say so plainly. That limitation is more useful than calling a partition key a complete boundary. For the regional alternative, see why DynamoDB global tables can break residency.

Record the model as a contract, not only as a diagram. Each access pattern should name the caller, server-side tenant source, key builder, index, operation, expected result, denial result, audit event, and recovery behavior. When a new report or export is requested, update the inventory before adding an index or broad role. This keeps the partition design aligned with actual product behavior.

Watch for data copied into convenience surfaces. A search index, cache, analytics table, notification queue, or support export can lose the original tenant key. If the copy is necessary, carry a server-controlled scope and test it like the primary table. If it is not necessary, do not create it. Deletion and offboarding should find every copy, including test and recovery records.

Cost estimates should include the shape of those patterns. A point read, a list query, an index query, and a report can have very different read and storage behavior. Measure representative synthetic records, then label the estimate with date, region, item size, index count, retention, and traffic. The global-table residency review adds another gate when the same key model is considered across regions.

Review schema changes as security changes. A new index, denormalized item, batch operation, or report can expose a path that the original table design did not cover. Require a tenant-aware access-pattern entry before shipping it. Include query scope, returned fields, identity, region, audit, retry, export, backup, and restore in the entry.

Keep a protected data inventory separate from an analytics inventory. If a report needs totals, compute them in a controlled job and return aggregate results rather than copying every record. If an outbox event needs reconciliation, use the minimum generic event fields and a server-side internal reference. Do not send patient names, email addresses, phone numbers, hashed identifiers, service names, treatment details, or clinical text to advertising systems.

During offboarding, enumerate primary items, indexes, queues, exports, backups, and test tables. A partition prefix can help locate records but does not guarantee complete deletion. Record who approved the action, which scope was selected, what was deleted, and what retention or legal hold remains.

Keep an engineering fallback. If a query requires many indexes, broad scans, or a second reporting store, compare the accumulated proof and operating work with PostgreSQL. The design goal is a stable, testable contract, not a particular database label.

Frequently asked questions

Does a DynamoDB partition key isolate tenants?

No. It organizes records and supports a query pattern. Tenant isolation still depends on server-side membership, key construction, identity policy, operation coverage, and negative tests for alternate paths.

What should be modeled first?

List every required read, write, update, report, export, retry, restore, and support operation. Map each to keys and indexes, then attach an authorization check and a denial test before selecting the table design.

Why test Scan?

Scan is an enumeration path that differs from a tenant-keyed query. A design that proves point reads may still expose a broad operation to a role or job. Test it explicitly and deny it when the workload does not need it.

When should PostgreSQL be compared?

Compare it when the workload needs relational constraints, flexible reporting, transactions, or database-enforced row policies. The comparison is about contracts and proof burden, not a claim that one product guarantees compliance.

References

Related articles