12 KiB
title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_projects | related_branches | created | last_reviewed | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AWS SaaS Tenant Isolation Strategies (Whitepaper) | official-doc | https://docs.aws.amazon.com/whitepapers/latest/saas-tenant-isolation-strategies/saas-tenant-isolation-strategies.html | raw | high |
|
|
|
2026-05-22 | 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:
- 인용하는 project:
- 인용한 wiki 요약: (미작성)