116 lines
12 KiB
Markdown
116 lines
12 KiB
Markdown
---
|
|
title: AWS SaaS Tenant Isolation Strategies (Whitepaper)
|
|
source_type: official-doc
|
|
url: https://docs.aws.amazon.com/whitepapers/latest/saas-tenant-isolation-strategies/saas-tenant-isolation-strategies.html
|
|
archive_url:
|
|
status: raw
|
|
confidence: high
|
|
tags: [ca-multi-tenancy, aws, isolation, silo, pool, bridge]
|
|
related_projects: [ca-skeleton-operational-contract]
|
|
related_branches: [feature-tenant-context-policy, feature-repository-access-permission-contract]
|
|
created: 2026-05-22
|
|
last_reviewed: 2026-05-27
|
|
---
|
|
|
|
# AWS SaaS Tenant Isolation Strategies
|
|
|
|
> Layer: `raw/official-docs/` — AWS Whitepaper "SaaS Tenant Isolation Strategies" (AWS SaaS Factory, 2020-08-01 publication). ca-tmpl 의 Pool 모델 (opt-in shared DB + tenant_id column) 결정의 대안 분류 baseline (Silo/Pool/Bridge).
|
|
> 검증된 요약은 `/ingest` 후 `wiki/concepts/`에 별도 작성.
|
|
|
|
## Parent / 활용 branch (필수)
|
|
|
|
| Branch | 이 자료가 정당화하는 결정 |
|
|
|---|---|
|
|
| [[raw/branch-notes/feature-tenant-context-policy]] | Topic 6 Multi-tenancy 대안 분류 (Silo/Pool/Bridge) 의 업계 표준 용어 baseline. ca-tmpl 의 Pool (shared schema + tenant_id) 채택의 isolation 강도 vs 비용 trade-off 근거. |
|
|
| [[raw/branch-notes/feature-repository-access-permission-contract]] | CROSS_TENANT_ADMIN capability 의 isolation enforcement 레이어 결정 — "Authentication is not isolation" 원칙에 따라 resource 레이어 enforcement 정당화. |
|
|
| [[raw/project-notes/ca-skeleton-operational-contract]] | §18 Control Plane Contract (Tenant Context Policy) 의 AWS baseline 분류 reference. |
|
|
|
|
## 컨텍스트 / 왜 저장했는지
|
|
|
|
ca-tmpl의 **opt-in tenant + shared DB + tenant_id column** 결정의 대안 분류 기준. AWS 분류 (Silo/Pool/Bridge) 는 업계 표준 용어로 흔히 인용되며 isolation 강도 vs 비용 trade-off 를 가장 명확히 정리한 문서.
|
|
|
|
## 출처 / Source
|
|
|
|
- 원본 URL: https://docs.aws.amazon.com/whitepapers/latest/saas-tenant-isolation-strategies/saas-tenant-isolation-strategies.html
|
|
- 관련: "SaaS Storage Strategies" whitepaper, AWS SaaS Lens (Well-Architected)
|
|
- 아카이브 URL: (미수집)
|
|
- 저자 / 조직: AWS SaaS Factory
|
|
- 발행일: 2020-08-01 (Publication date — 2026-05-27 재확인 시점에 페이지 노출됨; "This whitepaper is for historical reference only" 배너 표시)
|
|
- 마지막 확인일: 2026-05-27
|
|
- **재검증 결과 (2026-05-27)**: 메인 페이지 (Abstract / Introduction) 의 3개 quote 는 WebFetch 로 verbatim 재확인 완료 → strength `official-vendor-doc` 로 upgrade. Sub-page (`/general-isolation-concepts-and-considerations.html`, `/isolation-models.html`) 는 WebFetch 가 페이지 title 만 반환하고 본문 truncated — Silo/Pool/Bridge 정의 + "Authentication is not isolation" + Tenant isolation 정의 4개 quote 는 verbatim 재확인 불가, 계속 `needs-confirmation` 유지.
|
|
|
|
## 핵심 인용 / Key quotes (verbatim)
|
|
|
|
> [§Abstract — 2026-05-25 capture, 2026-05-27 verified] "Tenant isolation is fundamental to the design and development of software as a service (SaaS) systems. It enables SaaS providers to reassure customers that—even in a multitenant environment—their resources cannot be accessed by other tenants."
|
|
|
|
> [§Introduction — 2026-05-25 capture, 2026-05-27 verified] "Tenant isolation is one of the foundational topics that every software as a service (SaaS) provider must address."
|
|
|
|
> [§Introduction — 2026-05-25 capture, 2026-05-27 verified] "Crossing this boundary in any form would represent a significant and potentially un-recoverable event for a SaaS business."
|
|
|
|
> needs-confirmation [§Tenant Isolation (정의) — 2026-05-25 capture, 2026-05-27 sub-page WebFetch truncated to title only] "Tenant isolation is explicitly focused on the mechanisms used to ensure that each tenant is provided a runtime environment that limits and controls access to its resources."
|
|
|
|
> needs-confirmation [§Silo/Pool/Bridge models — 2026-05-25 capture, 2026-05-27 sub-page WebFetch truncated to title only] "A silo model represents an architecture where tenants are running fully siloed stacks of resources. ... A pool model represents an architecture where tenants share infrastructure."
|
|
|
|
> needs-confirmation [§Bridge model — 2026-05-25 capture, 2026-05-27 sub-page WebFetch truncated to title only] "The bridge model attempts to mix silo and pool, allowing some resources to be siloed while others are pooled."
|
|
|
|
> needs-confirmation [§Authentication vs Isolation — 2026-05-25 capture, 2026-05-27 sub-page WebFetch truncated to title only] "Authentication is not isolation. ... You must enforce isolation at the resource layer."
|
|
|
|
## Claims Extracted / 추출된 주장
|
|
|
|
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|
|
|---|---|---|---|---|---|
|
|
| AWS-TENANT-C1 | Tenant isolation 은 SaaS 시스템 설계의 fundamental 토픽으로, multi-tenant 환경에서도 한 tenant 의 resource 가 다른 tenant 에 의해 접근되지 않도록 보장하는 mechanism | [§Abstract] "Tenant isolation is fundamental to the design and development of software as a service (SaaS) systems. It enables SaaS providers to reassure customers that—even in a multitenant environment—their resources cannot be accessed by other tenants." | `official-vendor-doc` | 모든 SaaS multi-tenant 아키텍처 | 특정 구현 방식 (column-level vs schema-level vs db-level) 의 권장은 본 인용에 없음 |
|
|
| AWS-TENANT-C2 | Tenant boundary 위반은 SaaS 비즈니스에 significant 하고 잠재적으로 un-recoverable 한 사건 | [§Introduction] "Crossing this boundary in any form would represent a significant and potentially un-recoverable event for a SaaS business." | `official-vendor-doc` | SaaS provider 의 boundary breach 시나리오 | 구체적 incident response / recovery 절차 권장은 본 인용에 없음 |
|
|
| AWS-TENANT-C3 | Tenant isolation 의 정의 — "각 tenant 에게 resource 접근을 제한/제어하는 runtime environment 제공 메커니즘" (2026-05-25 capture, 2026-05-27 sub-page body 재확인 실패) | needs-confirmation [§Tenant Isolation 정의] "Tenant isolation is explicitly focused on the mechanisms used to ensure that each tenant is provided a runtime environment that limits and controls access to its resources." | `needs-confirmation` | AWS whitepaper 정의 사용 시 | 본 문장이 페이지의 현재 verbatim 인지는 manual 재확인 필요 |
|
|
| AWS-TENANT-C4 | Silo model = tenant 별로 완전 분리된 resource stack; Pool model = tenant 들이 infrastructure 공유 (2026-05-25 capture, 2026-05-27 sub-page body 재확인 실패) | needs-confirmation [§Silo/Pool models] "A silo model represents an architecture where tenants are running fully siloed stacks of resources. ... A pool model represents an architecture where tenants share infrastructure." | `needs-confirmation` | AWS 분류 사용 시 | "silo" "pool" 용어 자체가 AWS 가 originator 라는 주장은 아님 — 업계 통용 용어, AWS 가 명료화 |
|
|
| AWS-TENANT-C5 | Bridge model = silo 와 pool 의 혼합, 일부 resource 는 silo / 일부는 pool (2026-05-25 capture, 2026-05-27 sub-page body 재확인 실패) | needs-confirmation [§Bridge model] "The bridge model attempts to mix silo and pool, allowing some resources to be siloed while others are pooled." | `needs-confirmation` | hybrid tenant isolation 전략 분류 | Bridge 의 구체 구성 (e.g., DB silo + app pool) 권장은 본 인용에 없음 |
|
|
| AWS-TENANT-C6 | Authentication 은 isolation 이 아니며 resource layer 에서 isolation enforce 필수 (2026-05-25 capture, 2026-05-27 sub-page body 재확인 실패) | needs-confirmation [§Authentication vs Isolation] "Authentication is not isolation. ... You must enforce isolation at the resource layer." | `needs-confirmation` | tenant isolation 설계 원칙 | 정확한 enforcement 기술 (IAM policy vs RLS vs application code) 권장은 본 인용에 없음 |
|
|
|
|
## Usage Boundaries / 적용 경계
|
|
|
|
- **이 자료가 직접 증명하는 것**:
|
|
- `AWS-TENANT-C1`, `C2`: tenant isolation 의 SaaS 필수성과 boundary breach 의 비즈니스 영향 (2026-05-27 main 페이지 verbatim 재확인 완료, `official-vendor-doc`)
|
|
- **이 자료가 증명하지 않는 것**:
|
|
- `AWS-TENANT-C3` ~ `C6`: 2026-05-25 인용 verbatim 의 현재 페이지 존재 여부 (2026-05-27 sub-page WebFetch 가 페이지 title 만 반환 — body truncated; manual 브라우저 검증 또는 archive.org snapshot 필요)
|
|
- 특정 AWS 서비스 (Cognito / API Gateway / IAM) 가 tenant isolation 에 권장된다는 직접 보증 (본 인용 범위 밖)
|
|
- 한국 fintech / 금융권 규제에서 Silo 가 강제된다는 일반화 (AWS whitepaper 는 글로벌 SaaS 관점)
|
|
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
|
|
- ca-tmpl 의 "opt-in Pool" 변형이 AWS 분류 어디에 정확히 매핑되는지 (Pool 의 sub-variant 인지 별도 카테고리인지)
|
|
- AWS 의 "resource layer enforcement" 권장이 Spring Boot / Hibernate 의 `@TenantId` 또는 Hibernate Filter 적용으로 충족되는지 (별도 검증 필요)
|
|
- Silo/Pool/Bridge 의 정확한 verbatim 정의는 archive.org snapshot 또는 페이지 사람 검증으로 보강
|
|
|
|
## 메모 / Notes (내 프로젝트 해석)
|
|
|
|
> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
|
|
|
|
- isolation 수준 (shared/schema-per-tenant/db-per-tenant):
|
|
- **Silo** = db-per-tenant + 별도 compute/network까지 분리
|
|
- **Pool** = shared schema + tenant_id 컬럼 (ca-tmpl의 활성화 모드)
|
|
- **Bridge** = 일부는 silo, 일부는 pool (e.g. DB는 silo, app server는 pool)
|
|
- tenant resolution 방식: JWT claim (Cognito) 또는 API Gateway authorizer가 권장. header 단독은 약함.
|
|
- scale 한계:
|
|
- Silo: tenant 수 증가 시 infra 비용 선형. AWS 계정/limit 부딪힘.
|
|
- Pool: noisy neighbor, hot tenant가 전체 영향. row 수가 수억 넘어가면 partition 필요.
|
|
- 운영 복잡도:
|
|
- Silo: 마이그레이션이 tenant 수만큼 반복. 백업도 tenant별.
|
|
- Pool: 단일 schema. 마이그레이션 1회. 다만 tenant별 backup/restore가 어려움.
|
|
- security/compliance: 규제(HIPAA, FedRAMP, 금융권)는 silo 선호. data residency가 region별 분리를 요구하면 silo 불가피.
|
|
- 비용: silo > bridge > pool 순으로 비쌈.
|
|
- 장점: 분류 체계가 명확. tenant tier별로 다른 isolation 적용 가능 (free=pool, enterprise=silo).
|
|
- 단점: bridge 구현 시 routing/billing이 복잡.
|
|
- ca-tmpl과의 차이: ca-tmpl은 **Pool** 모델의 변형. 다만 multi-tenancy를 **opt-in**으로 두어 single-tenant deployment에서는 tenant column 자체를 비활성화함. AWS whitepaper는 "처음부터 multi-tenant 가정" 전제.
|
|
|
|
## Related / 관련
|
|
|
|
- 같은 주제 다른 raw:
|
|
- [[raw/official-docs/multitenancy-hibernate-user-guide]] — Hibernate ORM 의 DATABASE/SCHEMA/DISCRIMINATOR 공식 strategy
|
|
- [[raw/official-docs/multitenancy-microservices-io-pattern]] — microservices.io 의 database-per-service 패턴 (database-per-tenant 확장 baseline)
|
|
- [[raw/company-tech-blogs/multitenancy-stripe-citus-schema-per-tenant]] — Citus 의 schema-per-tenant 한계치 사례
|
|
- [[raw/company-tech-blogs/multitenancy-atlassian-tenant-context]] — Atlassian 의 shard + tenant context 운영 사례
|
|
- 인용하는 branch:
|
|
- [[raw/branch-notes/feature-tenant-context-policy]]
|
|
- [[raw/branch-notes/feature-repository-access-permission-contract]]
|
|
- 인용하는 project:
|
|
- [[raw/project-notes/ca-skeleton-operational-contract]] (§18)
|
|
- 인용한 wiki 요약: (미작성)
|