13 KiB
title, source_type, status, confidence, url, archive_url, tags, related_projects, related_branches, created, last_reviewed
| title | source_type | status | confidence | url | archive_url | tags | related_projects | related_branches | created | last_reviewed | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Azure Architecture Center — Multitenant SaaS Patterns | official-doc | raw | high | https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/overview |
|
|
|
2026-05-22 | 2026-05-27 |
Azure Multitenant SaaS Architecture Guidance
Layer:
raw/official-docs/— Microsoft Azure Architecture Center 의 multitenant guidance overview. Microsoft 공식 vendor doc (official-vendor-doc / official-reference). Azure 의 multi-tenancy 패턴 (특히 Deployment Stamps) 은 ca-tmpl 이 향후 hybrid 로 발전 시 참고할 baseline.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-tenant-context-policy | 현재 ca-tmpl 의 single stamp / pool 단계가 Azure 의 "tenancy models" 스펙트럼 중 어느 위치인지 자리매김 — fully shared ↔ fully isolated 범위 인식 근거 |
| raw/branch-notes/feature-repository-access-permission-contract | tenant catalog + routing layer 패턴이 capability 검증 layer 와 어떻게 결합되는지의 future-state 참고 |
| raw/project-notes/ca-skeleton-operational-contract | §18. Control Plane Contract (Tenant Context Policy) — Deployment Stamps 도입 시점에 대한 future-state 근거 (stamp 단위 canary, data residency 등) |
컨텍스트 / 왜 저장했는지
Azure 의 multi-tenancy 패턴은 Deployment Stamps (= hybrid) 개념을 가장 잘 정리. ca-tmpl 이 향후 hybrid (중요 tenant 는 isolation, 나머지는 shared) 로 발전 시 참고할 baseline.
출처 / Source
- 원본 URL: https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/overview — 2026-05-27 fetch 성공
- 페이지 metadata:
ms.date: 2025-04-17,updated_at: 2025-10-30,author: johndowns,ms.service: azure-architecture-center - 관련 페이지 (별도 raw 후속 검토 후보): "Deployment Stamps pattern", "Tenancy models to consider for a multitenant solution", "Architectural approaches for multitenancy"
- 저자 / 조직: Microsoft / Azure Architecture Center
- 발행일: 2025-04-17 (마지막 업데이트 2025-10-30)
- 마지막 확인일: 2026-05-27
핵심 인용 / Key quotes (verbatim)
[§Opening] "A multitenant solution is a solution used by multiple customers, or tenants. Tenants are distinct from users. Multiple users from a single organization, company, or group form a single tenant."
[§Opening — examples] "Business-to-business (B2B) solutions, such as accounting software, work tracking, and other software as a service (SaaS) products / Business-to-consumer (B2C) solutions, such as music streaming, photo sharing, and social network services / Enterprise-wide platform solutions, such as a shared Kubernetes cluster that multiple business units within an organization use"
[§Note — terminology distinction] "Microsoft Entra ID also uses the term tenant to refer to individual directories. It defines multitenancy as interactions between multiple Microsoft Entra tenants. The terms are the same, but the concepts differ. To avoid ambiguity, the full term, Microsoft Entra tenant, is used when referring to the Microsoft Entra concept of a tenant."
[§Scope] "Azure is a multitenant service, and some of our guidance is based on our experience with designing and operating large multitenant solutions. However, this series focuses on helping you build your own multitenant services while harnessing the power of the Azure platform."
[§What's in this series — architectural considerations] "This section provides an overview of the key requirements and considerations that you need to know when you plan and design a multitenant solution."
[§What's in this series — architectural approaches] "This section describes the approaches that you can consider when you design and build multitenant solutions by using key cloud resource types. This section includes a discussion about how to build multitenant solutions with compute, networking, storage, data, messaging, identity, AI and machine learning, and Internet of Things components, as well as deployment, configuration, resource organization, governance, compliance, and cost management."
[§What's in this series — service-specific guidance] "This section provides targeted guidance for specific Azure services. It includes descriptions of the tenancy isolation models that you might consider for the components in your solution and any features that are especially relevant for a multitenant solution."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| MT-AZURE-C1 | multitenant solution = 여러 고객 (tenant) 이 공유하는 solution. tenant 와 user 는 다름 — 단일 조직의 여러 user 가 모여 단일 tenant 를 구성 | [§Opening] "A multitenant solution is a solution used by multiple customers, or tenants. Tenants are distinct from users. Multiple users from a single organization, company, or group form a single tenant." | official-vendor-doc |
SaaS / B2B / B2C 전반의 tenant 정의 | tenant ↔ user 매핑이 항상 1조직:1tenant 라는 뜻 아님 — 한 user 가 여러 tenant 에 속할 수 있음 (예: 다중 워크스페이스 SaaS) |
| MT-AZURE-C2 | multitenancy 의 예시 범주: (a) B2B SaaS (회계, work tracking), (b) B2C (음악 스트리밍, 사진 공유, SNS), (c) 조직 내부 platform (예: 여러 사업부가 공유하는 Kubernetes cluster) | [§Opening — examples] "Business-to-business (B2B) solutions ... / Business-to-consumer (B2C) solutions ... / Enterprise-wide platform solutions, such as a shared Kubernetes cluster that multiple business units within an organization use" | official-vendor-doc |
multitenancy 가 적용되는 도메인 분류 | 이 3가지가 전부라는 뜻 아님 — government cloud, regulated industry 등 별도 |
| MT-AZURE-C3 | "tenant" 라는 용어는 Microsoft Entra ID (구 Azure AD) 의 "directory" 와 동일하나 개념이 다름 — Azure Architecture Center 의 multitenant guidance 에서는 "your tenants" (= 자신의 customer) 의 의미 | [§Note — terminology distinction] "Microsoft Entra ID also uses the term tenant to refer to individual directories. ... The terms are the same, but the concepts differ. To avoid ambiguity, the full term, Microsoft Entra tenant, is used when referring to the Microsoft Entra concept of a tenant." | official-vendor-doc |
Azure / Microsoft Entra 환경의 용어 구분 | Entra tenant 와 application tenant 가 항상 1:1 매핑이라는 뜻 아님 — 별도 매핑 정책 필요 |
| MT-AZURE-C4 | Azure 자체도 multitenant service 이며, 본 guidance 는 Azure 위에 자체 multitenant service 를 구축하는 ISV / SaaS / platform 개발자 대상 | [§Scope] "Azure is a multitenant service, and some of our guidance is based on our experience with designing and operating large multitenant solutions. However, this series focuses on helping you build your own multitenant services while harnessing the power of the Azure platform." | official-vendor-doc |
Azure 기반 SaaS / multi-tenant 시스템 개발 | non-Azure (AWS / GCP / on-prem) 에 직접 적용 가능하다는 뜻 아님 — 패턴은 transferable 하지만 service-specific 은 별도 |
| MT-AZURE-C5 | guidance series 의 architectural approaches 섹션은 compute / networking / storage / data / messaging / identity / AI/ML / IoT / deployment / configuration / governance / compliance / cost 등 cloud resource type 별 multi-tenant 패턴을 다룸 | [§What's in this series — architectural approaches] "how to build multitenant solutions with compute, networking, storage, data, messaging, identity, AI and machine learning, and Internet of Things components, as well as deployment, configuration, resource organization, governance, compliance, and cost management." | official-vendor-doc |
multi-tenant 시스템 설계의 전반 영역 | 본 overview 페이지 자체가 각 영역의 구체 패턴을 다룬다는 뜻 아님 — sub-page 로 분기됨 |
| MT-AZURE-C6 | service-specific guidance 섹션은 각 Azure service 별 "tenancy isolation models" 옵션을 기술 | [§What's in this series — service-specific guidance] "It includes descriptions of the tenancy isolation models that you might consider for the components in your solution and any features that are especially relevant for a multitenant solution." | official-vendor-doc |
특정 Azure service (예: Cosmos DB, AKS) 의 tenant isolation 결정 | 본 overview 페이지에 모든 모델이 나열되어 있다는 뜻 아님 — service 별 sub-page 참조 필요 |
| MT-AZURE-C7 | Deployment Stamps 패턴, fully shared ↔ fully isolated 의 tenancy models 스펙트럼은 본 overview 의 sub-section / 별도 페이지에서 다룸 (overview 본문에서는 미상세) | (본 overview 페이지 본문에 직접 인용 없음 — sub-page 별도) | needs-confirmation |
Azure Architecture Center 의 tenancy models / Deployment Stamps 페이지 | 본 overview fetch 결과로는 verbatim 증명 불가 — sub-page (예: /saas-multitenant-solution-architecture/tenancy-models) 별도 fetch 필요 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
C1~C6: Azure Architecture Center 의 multi-tenant 정의, 적용 범주, terminology, scope, guidance 구성
- 이 자료가 증명하지 않는 것:
C7: Deployment Stamps 패턴의 구체 내용 (stamp 정의, routing, monitoring) — overview 본문 미수록. sub-page 별도 fetch 필요- "tenancy models 의 fully shared → isolated stamp → isolated subscription" 같은 구체 spectrum 명명 — overview 본문 미수록
- 한국 / 비-Azure 환경에서의 직접 적용 가능성
- tenant catalog 의 구현 detail (DB schema, lookup 방식)
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- Deployment Stamps 패턴의 verbatim 정의 —
/azure/architecture/patterns/deployment-stamp별도 fetch - tenancy models 스펙트럼의 6단계 명명 —
/azure/architecture/guide/multitenant/considerations/tenancy-models별도 fetch - tenant identification / catalog 패턴 —
/azure/architecture/guide/multitenant/considerations/tenant-mapping별도 fetch - ca-tmpl 의 "single stamp / pool" 단계 정의가 Azure 의 어느 model 과 일치하는지 매핑
- Deployment Stamps 패턴의 verbatim 정의 —
메모 / Notes (내 해석, 미검증)
- isolation 수준 (shared/schema-per-tenant/db-per-tenant):
- Azure는 "tenancy models" 스펙트럼으로 표현: fully shared → shared compute, isolated DB → isolated stamp → isolated subscription. (해석 —
C7참조, 본 overview 본문 미수록) - Deployment Stamps = 동일한 스택을 단위(stamp)로 복제. stamp 안에서 N개 tenant를 pool. tier별로 stamp 크기 다름. (해석 — sub-page 별도)
- Azure는 "tenancy models" 스펙트럼으로 표현: fully shared → shared compute, isolated DB → isolated stamp → isolated subscription. (해석 —
- tenant resolution 방식: subdomain / path / JWT claim 전부 다룸. 권장은 "tenant catalog" + routing layer (Front Door / Application Gateway). (해석)
- scale 한계:
- Single stamp = pool model의 한계와 동일 (noisy neighbor, DB row 수)
- Stamp 추가는 horizontal scale → 사실상 무제한이지만 routing complexity ↑
- 운영 복잡도:
- Stamp별 마이그레이션 rollout (canary 가능 — 일부 stamp에 먼저 배포)
- 모니터링이 stamp 단위로 fanout → 통합 dashboard 필요
- security/compliance: stamp를 region별로 두면 data residency 자연 해결. stamp 단위 compliance 인증.
- 비용: pool보다 비쌈, full silo보다 쌈. tenant 수 증가에 따른 비용이 step function.
- 장점:
- blast radius 제한 (한 stamp 장애가 다른 stamp에 영향 없음)
- 마이그레이션 canary가 자연스러움
- 단점:
- routing layer + tenant catalog 구현 필요
- tenant를 stamp 간 이동시키는 절차가 복잡 (data migration)
- ca-tmpl과의 차이: ca-tmpl은 현재 single stamp / pool 단계. tenant 수가 수백 단위로 늘어나거나 enterprise tier가 생기면 stamp 도입 검토 지점.
Related / 관련
- 같은 주제 다른 raw:
- raw/official-docs/multitenancy-aws-saas-tenant-isolation-whitepaper (AWS 측 silo/pool/bridge)
- raw/official-docs/multitenancy-hibernate-user-guide
- raw/official-docs/multitenancy-microservices-io-pattern
- raw/company-tech-blogs/multitenancy-hybrid-pooled-siloed-mix (AWS APN 의 bridge model 사례)
- raw/company-tech-blogs/multitenancy-stripe-citus-schema-per-tenant
- 인용하는 branch / project:
- 대안 그룹: Topic 6 — Multi-tenancy (대안 6종). 본 source 의 위치: 대안 5 — Deployment Stamps (hybrid).
- 인용한 wiki 요약: (미작성)