---
title: Atlassian — Tenant Context and Isolation in Cloud Platform
source_type: company-tech-blog
url: https://www.atlassian.com/engineering/cloud-architecture-and-guidelines
archive_url:
status: raw
confidence: medium
tags: [ca-multi-tenancy, atlassian, tenant-context, shard]
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
---

# Atlassian Cloud — Tenant Context / Isolation

> Layer: `raw/company-tech-blogs/` — Atlassian Engineering 의 Cloud Architecture and Operational Guidelines. 수십만 tenant 를 운영하는 대표 hybrid (Bridge) 사례; shard 단위 isolation + tenant context (cloudId) 전파 패턴.
> **출처 주의**: company-tech-blog 이므로 본 자료의 권장 사항을 "공식 best practice" 로 일반화 금지. ca-tmpl 미래 hybrid 확장의 사례 reference 로만 사용.
> 검증된 요약은 `/ingest` 후 `wiki/concepts/`에 별도 작성.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-tenant-context-policy]] | Topic 6 Multi-tenancy 대안 6 (hybrid Deployment Stamps / shard) 의 대규모 사례 baseline. tenant context (cloudId/tenantId) 전파 = ca-tmpl 의 SecurityContext → repository 사상과 동일. |
| [[raw/branch-notes/feature-repository-access-permission-contract]] | "Cross-tenant access is explicitly forbidden at the storage layer; tenant context is mandatory in every query" 원칙이 CROSS_TENANT_ADMIN capability 의 명시적 escape hatch 설계 정당화. |
| [[raw/project-notes/ca-skeleton-operational-contract]] | §18 Control Plane Contract (Tenant Context Policy) 의 hybrid 확장 사례 reference. |

## 컨텍스트 / 왜 저장했는지

Atlassian Cloud (Jira, Confluence) 는 수십만 tenant 를 운영하는 대표 사례. **shard 단위 isolation + tenant_id 전파** 패턴은 ca-tmpl 미래 확장 (hybrid) 에 가장 가까운 실제 운영 사례.

## 출처 / Source

- 원본 URL: https://www.atlassian.com/engineering/cloud-architecture-and-guidelines
- 관련 글: "How we manage data residency on AWS", "Tenant context propagation"
- 아카이브 URL: (미수집)
- 저자 / 조직: Atlassian Engineering
- 발행일: rolling docs (페이지 자체에 명시 없음)
- 마지막 확인일: 2026-05-27
- **재검증 결과 (2026-05-27)**: 원본 URL (`https://www.atlassian.com/engineering/cloud-architecture-and-guidelines`) WebFetch 결과 **HTTP 404 Not Found** — 페이지가 이동/삭제됨. Atlassian engineering blog index (`atlassian.com/blog/atlassian-engineering`) 와 developer docs (`developer.atlassian.com/cloud/jira/platform/multi-tenancy/`) 도 redirect 또는 404. archive.org snapshot 도 WebFetch 차단. 2026-05-25 작성 당시 인용된 4개 quote 모두 verbatim 재확인 불가; claim strength `company-case-study` + `needs-confirmation` 유지. wiki 추출 또는 외부 인용 전 다른 출처 corroboration 필수.

## 핵심 인용 / Key quotes (verbatim, 2026-05-22 작성 시 인용)

> needs-confirmation [§Shard assignment — 2026-05-25 capture, 2026-05-27 원본 URL 404] "Each Atlassian Cloud tenant is assigned to a shard — a unit of deployment that hosts many tenants but is operated as a single unit."

> needs-confirmation [§Tenant context propagation — 2026-05-25 capture, 2026-05-27 원본 URL 404] "We propagate a tenant context (cloudId/tenantId) through every service call so that downstream services can enforce tenant-scoped data access."

> needs-confirmation [§Data residency / realm — 2026-05-25 capture, 2026-05-27 원본 URL 404] "Data residency is implemented by placing all of a tenant's data in a specific realm (region), with metadata routing requests to the correct realm."

> needs-confirmation [§Storage layer enforcement — 2026-05-25 capture, 2026-05-27 원본 URL 404] "Cross-tenant access is explicitly forbidden at the storage layer; tenant context is mandatory in every query."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| ATL-MT-C1 | Atlassian Cloud 의 각 tenant 는 shard (many tenant 를 호스팅하지만 single unit 로 운영되는 deployment 단위) 에 할당 | needs-confirmation [§Shard assignment] "Each Atlassian Cloud tenant is assigned to a shard — a unit of deployment that hosts many tenants but is operated as a single unit." | `company-case-study` + `needs-confirmation` | Atlassian Jira / Confluence Cloud 운영 사례 | shard 크기 / tenant 배분 알고리즘 / rebalancing 메커니즘은 본 인용에 없음 |
| ATL-MT-C2 | Tenant context (cloudId/tenantId) 가 모든 service call 을 통해 전파되어 downstream service 가 tenant-scoped data access 를 enforce | needs-confirmation [§Tenant context propagation] "We propagate a tenant context (cloudId/tenantId) through every service call so that downstream services can enforce tenant-scoped data access." | `company-case-study` + `needs-confirmation` | Atlassian internal RPC / microservices 운영 | propagation 의 구체 transport (HTTP header / gRPC metadata / message header) 는 본 인용에 없음 |
| ATL-MT-C3 | Data residency 는 tenant 의 모든 data 를 특정 realm (region) 에 배치 + metadata routing 으로 구현 | needs-confirmation [§Data residency / realm] "Data residency is implemented by placing all of a tenant's data in a specific realm (region), with metadata routing requests to the correct realm." | `company-case-study` + `needs-confirmation` | Atlassian Cloud 의 GDPR / 데이터 주권 요구 시나리오 | realm 간 tenant 이동 / 복제 / 장애 시 failover 정책은 본 인용에 없음 |
| ATL-MT-C4 | Cross-tenant access 는 storage layer 에서 명시적으로 금지; tenant context 는 모든 query 에 mandatory | needs-confirmation [§Storage layer enforcement] "Cross-tenant access is explicitly forbidden at the storage layer; tenant context is mandatory in every query." | `company-case-study` + `needs-confirmation` | Atlassian 의 internal multi-tenancy enforcement | 정확한 enforcement 메커니즘 (RLS / ORM filter / static analysis) 은 본 인용에 없음 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `ATL-MT-C1` ~ `C4`: Atlassian 의 shard + tenant context propagation + storage layer enforcement 운영 사례 (단, 인용 verbatim 재확인 실패)
- **이 자료가 증명하지 않는 것**:
  - shard 모델이 모든 SaaS 의 best practice 라는 일반화 (company-tech-blog → 사례, 표준 아님)
  - 한국 fintech / 금융권 규제에서 shard 가 충분한 isolation 으로 인정되는지 (Atlassian 은 글로벌 enterprise SaaS, 규제 컨텍스트 다름)
  - tenant context propagation 의 specific 구현 (HTTP header / JWT claim / Thread-local) 권장
  - shard rebalancing / tenant migration 의 운영 절차 (블로그에 명시 없음)
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - ca-tmpl 이 shard 모델로 확장될 trigger 조건 (tenant 수 / 단일 deployment 부하 / 규제)
  - "storage layer enforcement" 의 ca-tmpl 구현 방식 — Hibernate Filter + CROSS_TENANT_ADMIN capability 의 조합이 Atlassian 의 "mandatory in every query" 와 동등한 강도인지
  - 본 raw 인용 verbatim 의 정확성은 페이지 사람 검증 또는 archive.org snapshot 으로 보강
  - "company-tech-blog" 이므로 wiki 추출 시 AWS / Hibernate 공식 자료와 corroboration 필요 (공식 best practice 로 단정 금지)

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- isolation 수준 (shared/schema-per-tenant/db-per-tenant):
  - shard 안에서는 shared DB + tenant_id (pool에 가까움)
  - shard 자체가 deployment stamp 역할 → 실질적으로 **hybrid (Bridge)**
- tenant resolution 방식: cloudId(=tenant_id)를 모든 internal RPC header/context로 전파. 외부 진입은 OAuth token 안의 tenant claim.
- scale 한계: shard 추가로 horizontal scale. 단일 shard 크기는 운영적으로 cap.
- 운영 복잡도:
  - shard rebalancing (tenant 이동) 매우 복잡
  - 전체 fleet rollout이 shard별 canary로 진행됨 → 안전하지만 시간 소요
- security/compliance: realm으로 GDPR/data residency 해결. tenant context propagation 자체가 security boundary.
- 비용: 단순 pool보다 비쌈. 전부 silo보다 훨씬 쌈.
- 장점:
  - blast radius 제한
  - tenant 단위 SLA 차등 가능
  - data residency 자연 지원
- 단점:
  - 모든 서비스가 tenant context를 강제로 요구 → 초기 framework 투자 필요
  - 회사 규모(수십~수백 명 인프라 팀) 없이는 운영 어려움
- ca-tmpl과의 차이:
  - ca-tmpl은 현재 단일 deployment + opt-in tenant_id. shard 개념 없음.
  - **tenant context propagation (header/JWT → SecurityContext → repository)** 자체는 ca-tmpl과 동일한 사상.

## Related / 관련

- 같은 주제 다른 raw:
  - [[raw/official-docs/multitenancy-aws-saas-tenant-isolation-whitepaper]] — AWS 의 Silo/Pool/Bridge 분류 (Atlassian shard ≈ Bridge)
  - [[raw/official-docs/multitenancy-hibernate-user-guide]] — Hibernate ORM 의 3 strategy
  - [[raw/official-docs/multitenancy-microservices-io-pattern]] — microservices.io database-per-service
  - [[raw/company-tech-blogs/multitenancy-stripe-citus-schema-per-tenant]] — schema-per-tenant 한계치 사례
- 인용하는 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 요약: (미작성)