본문으로 건너뛰기
azure검색
기초

Azure 리소스 계층 (테넌트, 관리 그룹, 구독, 리소스 그룹)

Microsoft Entra 테넌트 아래 관리 그룹, 구독, 리소스 그룹, 리소스로 이어지는 Azure 의 네 단계 계층과 각 단계가 맡는 일(권한 상속, 정책, 청구, 할당량), 한도, 이름 규칙과 태그, 랜딩 존 설계 요령을 정리합니다.

관리 그룹구독리소스 그룹테넌트랜딩 존태그2026-10 기준, 약 7분

한눈에 보기

Azure 의 모든 리소스는 정해진 계층 안에 들어갑니다. 위에서부터 Microsoft Entra 테넌트, 관리 그룹, 구독, 리소스 그룹, 리소스 순서입니다. 이 구조가 중요한 이유는 권한(RBAC), 정책(Azure Policy), 예산 같은 설정이 위에서 아래로 상속되기 때문입니다. 관리 그룹에 역할을 하나 주면 그 아래 모든 구독과 리소스에 같은 권한이 생깁니다.

Microsoft Entra 테넌트 (사용자, 그룹, 서비스 주체, 관리 ID) Tenant Root Group 루트 관리 그룹, ID = 테넌트 ID 관리 그룹: Platform ID, 연결, 관리 구독 관리 그룹: Landing Zones Corp, Online (최대 6단계) 구독: connectivity 허브 VNet, Firewall 구독: app-prod 청구, 할당량 단위 구독: app-dev 예산 경고 따로 rg-app-prod 수명이 같은 것끼리 rg-data-prod 메타데이터는 한 리전 리소스: VM, 스토리지 계정, SQL Database, Key Vault ... 상속 RBAC 역할 할당 Azure Policy 예산과 태그 정책 위 범위에 걸면 아래 모두에 적용
Azure 리소스 계층과 상속
단계하는 일대표 한도 (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 Vaultkv-shop-prod-krc전역 고유, 3~24자
VNetvnet-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

설계 체크리스트

  1. 테넌트는 하나로 시작하고, 나눌 이유를 문서로 남깁니다.
  2. 관리 그룹은 정책이 달라지는 곳에서만 나누고 4단계를 넘기지 않습니다.
  3. 운영과 개발은 구독을 나눕니다. 할당량과 권한 사고가 서로 번지지 않습니다.
  4. 리소스 그룹은 수명 기준으로 묶습니다. 네트워크처럼 오래 사는 것과 앱처럼 자주 바뀌는 것을 섞지 않습니다.
  5. 이름 규칙, 필수 태그, 허용 리전을 Azure Policy로 강제합니다.

공식 문서

이 문서에서