2.3.6 Multi-Tenant Data Access Patterns

Multi-Tenant Data Access Patterns

Isolation Models

Silo Model

Tenant A → Account A → DynamoDB Table A, S3 Bucket A
Tenant B → Account B → DynamoDB Table B, S3 Bucket B

• Strongest isolation
• Separate AWS accounts hoặc separate resources
• Highest cost, hardest to manage

Pool Model

Tenant A → Shared DynamoDB Table (PK: tenant_a#...)
Tenant B → Shared DynamoDB Table (PK: tenant_b#...)

• Shared resources, data separated by tenant_id
• IAM policies enforce tenant isolation
• Lowest cost, noisy neighbor risk

DynamoDB Multi-Tenant Access Control

{
  "Effect": "Allow",
  "Action": [
    "dynamodb:GetItem",
    "dynamodb:PutItem",
    "dynamodb:Query"
  ],
  "Resource": "arn:aws:dynamodb:*:*:table/SharedTable",
  "Condition": {
    "ForAllValues:StringEquals": {
      "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
    }
  }
}

• dynamodb:LeadingKeys: Restrict access to items where PK matches user’s identity
• Cognito Identity ID as partition key prefix
• Fine-grained access control at item level

S3 Multi-Tenant

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::shared-bucket/${cognito-identity.amazonaws.com:sub}/*"
}

• Prefix-based isolation: each tenant gets own “folder”
• Policy variable ensures tenant can only access own prefix

Row-Level Security (RDS/Aurora)

• Database views filtered by tenant_id
• Row-level security policies (PostgreSQL)
• Application-level filtering (less secure)