Azure 리소스 계층 (테넌트, 관리 그룹, 구독, 리소스 그룹)
Microsoft Entra 테넌트 아래 관리 그룹, 구독, 리소스 그룹, 리소스로 이어지는 Azure 의 네 단계 계층과 각 단계가 맡는 일(권한 상속, 정책, 청구, 할당량), 한도, 이름 규칙과 태그, 랜딩 존 설계 요령을 정리합니다.
한눈에 보기
Azure 의 모든 리소스는 정해진 계층 안에 들어갑니다. 위에서부터 Microsoft Entra 테넌트, 관리 그룹, 구독, 리소스 그룹, 리소스 순서입니다. 이 구조가 중요한 이유는 권한(RBAC), 정책(Azure Policy), 예산 같은 설정이 위에서 아래로 상속되기 때문입니다. 관리 그룹에 역할을 하나 주면 그 아래 모든 구독과 리소스에 같은 권한이 생깁니다.
| 단계 | 하는 일 | 대표 한도 (2026-10 기준) |
|---|---|---|
| Entra 테넌트 | 사용자, 그룹, 앱, 관리 ID 같은 ID 의 경계. 구독은 정확히 한 테넌트를 믿음 | 테넌트당 루트 관리 그룹 1개 |
| 관리 그룹 | 여러 구독을 묶어 정책과 권한을 한 번에 적용 | 테넌트당 10,000개, 루트 아래 최대 6단계 |
| 구독 | 청구 단위, 할당량 단위, 권한 경계 | 구독당 리소스 그룹 980개 |
| 리소스 그룹 | 수명이 같은 리소스를 묶는 논리 컨테이너 | 리소스 종류별 800개, 배포 기록 800개 |
| 리소스 | VM, 스토리지 계정, SQL Database 같은 실제 서비스 | 리소스당 태그 50개 |
테넌트와 루트 관리 그룹
테넌트는 Microsoft Entra ID 의 한 디렉터리입니다. 회사 하나에 테넌트 하나가 보통이고, 여러 테넌트를 쓰면 ID 와 권한 관리가 갈라지므로 꼭 필요할 때(인수 합병, 규제 분리)만 나눕니다. 자세한 ID 개념은 Microsoft Entra ID 문서에 있습니다.
모든 테넌트에는 Tenant Root Group 이라는 루트 관리 그룹이 하나 있고, ID 는 테넌트 ID 와 같습니다. 옮기거나 지울 수 없고, 처음에는 아무도 기본 권한이 없습니다. Global Administrator 가 "Azure 리소스에 대한 액세스 관리" 권한을 올려야(elevate) 손댈 수 있습니다. 새 구독은 기본적으로 루트 관리 그룹 아래에 생기므로, 기본 관리 그룹을 따로 정해 두면 정책이 빠진 구독이 생기는 것을 막을 수 있습니다.
관리 그룹
관리 그룹은 구독을 묶는 폴더입니다. 부모는 하나만 가질 수 있고 자식은 여럿 가질 수 있습니다. 깊이는 루트와 구독을 빼고 6단계까지지만, 실제로는 3~4단계면 충분합니다. 깊게 만들수록 어떤 정책이 어디서 왔는지 추적하기 어렵습니다.
# 관리 그룹 만들고 구독 옮기기
az account management-group create --name mg-landingzones --display-name "Landing Zones"
az account management-group create --name mg-corp --parent mg-landingzones
az account management-group subscription add --name mg-corp --subscription "app-prod"팁 관리 그룹은 조직도가 아니라 정책이 달라지는 지점으로 나눕니다. 부서마다 정책이 같다면 부서별 관리 그룹은 필요 없습니다.
구독
구독은 세 가지 경계를 한꺼번에 가집니다.
- 청구 경계: 요금이 구독 단위로 모이고 청구서, 예산, 비용 분석의 기본 단위입니다.
- 할당량 경계: vCPU, 공용 IP, 스토리지 계정 수 같은 할당량이 구독과 리전 단위로 걸립니다. 큰 배포 전에는 할당량 오류 문서를 봅니다.
- 권한 경계: 구독 Owner 는 그 안의 모든 것을 바꿀 수 있습니다.
구독을 나누는 흔한 기준은 환경(prod, dev), 워크로드, 비용 책임자입니다. 플랫폼 팀이 쓰는 connectivity(허브 네트워크), identity, management(로그) 구독을 따로 두고, 앱 팀은 랜딩 존 구독을 받는 구조가 Microsoft 의 Cloud Adoption Framework 권장 모델입니다.
리소스 그룹
리소스 그룹은 같이 만들고, 같이 바꾸고, 같이 지우는 리소스 묶음입니다. 리소스 그룹을 지우면 안의 리소스가 모두 지워집니다.
- 리소스 그룹에도 리전이 있지만 이것은 메타데이터가 저장되는 위치입니다. 안의 리소스는 다른 리전에 있어도 됩니다. 다만 그 리전이 장애이면 리소스 그룹의 관리 작업이 막힐 수 있으니 리소스와 같은 리전을 고릅니다.
- 리소스는 다른 리소스 그룹이나 구독으로 옮길 수 있지만 지원하지 않는 종류가 있고, 옮기는 동안 원본과 대상 그룹 모두 쓰기가 잠깁니다.
- 배포 기록은 리소스 그룹당 800개까지 남고, 한도에 가까워지면 오래된 기록이 자동으로 지워집니다.
이름 규칙과 태그
이름은 나중에 바꿀 수 없는 리소스가 많으므로 처음부터 규칙을 정합니다. Cloud Adoption Framework 의 약어(rg, vnet, snet, st, kv, vm)를 앞에 붙이고 워크로드, 환경, 리전, 번호 순으로 이어 쓰는 방식이 널리 쓰입니다.
| 리소스 | 예시 | 주의 |
|---|---|---|
| 리소스 그룹 | rg-shop-prod-krc-001 | 구독 안에서 고유 |
| 스토리지 계정 | stshopprodkrc001 | 전역 고유, 소문자와 숫자만, 3~24자 |
| Key Vault | kv-shop-prod-krc | 전역 고유, 3~24자 |
| VNet | vnet-shop-prod-krc | 리소스 그룹 안에서 고유 |
태그는 비용 분석과 자동화의 열쇠입니다. env, owner, costCenter, app 정도를 필수로 정하고, Azure Policy 의 "태그 필수" 또는 "리소스 그룹에서 태그 상속" 정책으로 강제합니다. 태그는 기본적으로 리소스 그룹에서 리소스로 상속되지 않는다는 점이 자주 하는 착각입니다.
잠금 (Resource Lock)
운영 리소스 그룹에는 CanNotDelete 잠금을 걸어 실수로 지우는 일을 막습니다. ReadOnly 잠금은 생각보다 많은 작업(스토리지 계정 키 나열, App Service 설정 조회 등)을 막으므로 신중히 씁니다. 잠금도 아래로 상속되고, Owner 라도 잠금을 먼저 풀어야 지울 수 있습니다.
az lock create --name no-delete --lock-type CanNotDelete --resource-group rg-shop-prod-krc-001설계 체크리스트
- 테넌트는 하나로 시작하고, 나눌 이유를 문서로 남깁니다.
- 관리 그룹은 정책이 달라지는 곳에서만 나누고 4단계를 넘기지 않습니다.
- 운영과 개발은 구독을 나눕니다. 할당량과 권한 사고가 서로 번지지 않습니다.
- 리소스 그룹은 수명 기준으로 묶습니다. 네트워크처럼 오래 사는 것과 앱처럼 자주 바뀌는 것을 섞지 않습니다.
- 이름 규칙, 필수 태그, 허용 리전을 Azure Policy로 강제합니다.