목차
(1) 리소스를 관리 단위로 묶어야 하는 이유
Azure에서 생성하는 가상 머신, 스토리지 계정, 가상 네트워크 등의 개별 항목을 리소스(Resource)라고 한다.
리소스는 과금이 발생하는 최소 단위이기도 하다.
1) 구조 없이 생성했을 때 발생하는 문제
- 소유 주체 불명확: 어떤 리소스가 어느 프로젝트에 속하는지 구분되지 않음
- 비용 추적 불가: 부서나 프로젝트 단위로 사용 비용을 분리할 수 없음
- 삭제 위험: 사용 중인 리소스와 폐기 대상을 구분하지 못해 잘못 삭제할 수 있음
- 잔여 자원 발생: 프로젝트 종료 후 일부 리소스가 삭제되지 않고 과금이 지속됨
- 권한 부여 곤란: 접근 권한을 리소스마다 개별 설정해야 함
Azure는 이 문제를 계층 구조로 해결한다. 각 계층은 권한, 정책, 비용, 수명 주기를 적용하는 경계가 된다.
(2) Azure 관리 계층 구조
| 계층 | 역할 | 경계의 성격 |
|---|---|---|
| Tenant | 조직의 사용자와 그룹을 관리 | ID 경계 |
| Management Group | 여러 구독에 정책과 권한을 일괄 적용 | 정책 경계 |
| Subscription | 과금 단위와 자원 사용 한도를 정의 | 과금·한도 경계 |
| Resource Group | 함께 관리하고 함께 폐기할 리소스를 묶음 | 수명 주기 경계 |
| Resource | 실제로 생성되어 동작하는 개별 자원 | 과금 발생 단위 |
1) Microsoft Entra Tenant
Tenant는 조직의 사용자 계정과 그룹을 관리하는 ID 디렉터리이다.
리소스에 접근하려면 먼저 해당 Tenant에서 인증을 거쳐야 한다.
- 하나의 Tenant에 여러 구독을 연결할 수 있음
- 하나의 구독은 한 번에 하나의 Tenant에만 연결됨
- Tenant는 인증을, 구독은 과금과 자원 관리를 담당하는 별개의 개념
Tenant와 구독은 자주 혼동된다. Tenant는 누가 접근할 수 있는가를, 구독은 무엇을 만들고 누가 비용을 내는가를 결정한다. 구독을 삭제해도 Tenant의 사용자 계정은 그대로 남는다.
2) Management Group
구독이 여러 개일 때, 그 위에서 정책과 권한을 일괄 적용하기 위한 계층이다.
- 부서나 환경(운영·개발) 단위로 구독을 묶어 관리
- 상위 그룹에 적용한 설정이 하위 구독과 리소스로 상속됨
- 구독마다 동일한 규칙을 반복 설정하는 작업을 제거
- 구독이 하나뿐인 소규모 환경에서는 사용하지 않아도 무방
3) Azure Resource Manager
Azure Resource Manager(ARM)는 리소스의 생성, 수정, 삭제 요청을 처리하는 단일 관리 계층이다.
Portal, CLI, PowerShell 등 어떤 도구를 사용하든 모든 요청은 ARM을 거친다.
Portal CLI PowerShell SDK
└─────────┴──────────┴─────────────┘
│
Azure Resource Manager
│
인증 확인 → 권한 확인 → 정책 검증
│
리소스 생성·변경- 도구가 달라도 동일한 인증·권한·정책 검증을 거침
- 여러 리소스를 하나의 작업 단위로 함께 배포 가능
- 리소스 구성을 템플릿 파일로 정의하여 반복 배포 가능
(3) 구독의 역할(논리적 컨테이너, 청구 단위, 관리 경계)
구독(Subscription)은 Azure 리소스를 생성하고 사용한 비용을 청구받는 단위이다.
리소스는 반드시 어떤 구독에 속해야 생성될 수 있다.
1) 구독이 담당하는 경계
- 과금 경계: 사용량이 구독 단위로 집계되어 청구됨
- 한도 경계: 구독마다 생성 가능한 리소스 수량에 상한이 존재
- 정책 적용 경계: 구독 단위로 규정과 제약을 적용 가능
- 권한 부여 경계: 구독 단위로 접근 권한을 부여 가능
2) 구독을 분리하는 기준
- 비용을 분리해서 청구받아야 하는 조직 단위가 다를 때
- 운영 환경과 개발·테스트 환경의 정책을 다르게 적용해야 할 때
- 한 구독의 리소스 한도에 도달했을 때
- 규제 요건이 다른 워크로드를 분리해야 할 때
구독을 나누면 비용과 정책은 명확히 분리되지만, 구독 간 리소스 연결에는 추가 설정이 필요하다. 분리 기준이 명확하지 않다면 구독 대신 리소스 그룹으로 구분하는 편이 관리하기 쉽다.
(4) 리소스 그룹의 역할과 수명 주기(그룹 관리, 수명 주기 관리, 권한 관리 )
리소스 그룹(Resource Group)은 함께 관리하고 함께 폐기할 리소스를 묶는 논리적 컨테이너이다.
1) 구성 규칙
- 모든 리소스는 반드시 하나의 리소스 그룹에 속해야 함
- 하나의 리소스는 동시에 두 개의 리소스 그룹에 속할 수 없음
- 리소스 그룹도 생성 시 위치를 지정하지만, 이는 그룹의 메타데이터가 저장되는 위치이며 리소스의 실제 배치 지역과는 별개임
- 서로 다른 지역의 리소스를 하나의 리소스 그룹에 포함할 수 있음
- 리소스를 다른 리소스 그룹으로 이동할 수 있으나 서비스에 따라 제약이 있음
2) 수명 주기
리소스 그룹의 가장 중요한 성격은 그룹을 삭제하면 그 안의 모든 리소스가 함께 삭제된다는 점이다.
프로젝트 시작 → 리소스 그룹 생성
│
리소스 일괄 배포
│
운영 및 변경 관리
│
프로젝트 종료 → 리소스 그룹 삭제
│
그룹 내 모든 리소스 자동 삭제- 수명 주기가 같은 리소스를 하나의 그룹에 배치하는 것이 원칙
- 테스트 환경을 그룹 단위로 만들고 종료 시 그룹째 삭제하면 잔여 자원이 남지 않음
- 여러 프로젝트가 공용으로 사용하는 리소스는 별도 그룹으로 분리
수명 주기가 다른 리소스를 한 그룹에 함께 두면, 그룹 삭제 시 계속 사용해야 할 리소스까지 함께 삭제된다. 공용 네트워크나 데이터 저장소는 프로젝트용 리소스 그룹과 반드시 분리해야 한다.
(5) 지역에 종속되는 리소스와 전역 서비스
대부분의 리소스는 생성 시 지역을 지정해야 하지만, 일부 서비스는 지역과 무관하게 동작한다.
| 구분 | 지역 서비스(Regional) | 비지역 서비스(Non-regional) |
|---|---|---|
| 지역 지정 | 생성 시 반드시 지정 | 지정하지 않음 |
| 배치 위치 | 특정 지역의 데이터센터 | 전역 인프라에 분산 |
| 지역 장애 영향 | 해당 지역 장애 시 영향받음 | 단일 지역 장애의 영향이 제한적 |
| 예시 | 가상 머신, 가상 네트워크, 관리형 디스크 | 전역 트래픽 관리, ID 서비스 |
1) 서비스 제공 범주
같은 지역이라도 모든 서비스가 동일하게 제공되지는 않는다. 서비스는 제공 우선순위에 따라 구분된다.
| 범주 | 제공 특성 |
|---|---|
| 기본 서비스 | 거의 모든 지역에서 제공되는 핵심 서비스 |
| 주류 서비스 | 수요에 따라 제공 지역이 순차적으로 확대되는 서비스 |
| 전략적 서비스 | 특정 목적이나 한정된 지역에서만 제공되는 서비스 |
| 비지역 서비스 | 지역 개념 없이 전역에서 제공되는 서비스 |
설계 단계에서 필요한 서비스가 선택한 지역에서 제공되는지 먼저 확인해야 한다. 지역을 정한 뒤 서비스가 없다는 사실을 발견하면 구성을 다시 잡아야 한다.
(6) Portal, CLI, PowerShell, Cloud Shell 비교
모든 도구는 동일하게 Azure Resource Manager를 호출하므로, 어떤 도구를 사용해도 결과는 같다. 차이는 조작 방식과 자동화 적합성에 있다.
| 비교 항목 | Azure Portal | Azure CLI | Azure Powershell | Azure Cloud Shell |
|---|---|---|---|---|
| 형태 | 웹 GUI | 명령줄 도구(Command Line) | 명령줄 도구(Command Line) | 브라우저 기반 터미널 |
| 기반 OS | 모든 OS | Windows, macOS, Linux | Windows, macOS, Linux | 웹 브라우저(설치 불필요) |
| 명령어 스타일 | 마우스클릭 | az.. ( 리눅스 스타일 ) | Verb-Noun(동사-명사) | az또는 New-Az 선택 가능 |
| 데이터 처리 | 화면 표시 | JSON 텍스트 | .NET객체 | 선택한 쉘에 따라 다름 |
| 장점 | 직관적, 시각적 확인, 초보자 접근 용이 | 간결함, Bash 친화적, 빠른 타이핑 | 강력한 기능, Windows 친화적 | 설치 0, 어디서나 접속, 자동 로그인 |
| 단점 | 반복 작업 비효율, 자동화 어려움 | 텍스트(JSON)파싱 공부 필요 | 문법이 길고 복잡할 수 있음 | 세션 시간 제한, 로컬 파일 접근 불가 |
| 추천 대상 | 입문자, 모니터링, 단발성 설정 | Linux/Mac 사용자, DevOps 엔지니어 |
Windosw 관리자, 복잡한 스크립팅 | 이동 잦은 관리자, 긴급 점검 |
동일한 작업을 CLI로 수행하면 다음과 같다. 리소스 그룹을 먼저 만들고 그 안에 리소스를 배치하는 순서를 확인할 수 있다.
# 리소스 그룹 생성 (그룹이 없으면 리소스를 만들 수 없음)
az group create --name rg-order-prod --location koreacentral
# 생성한 리소스 그룹 안에 리소스 배치
az vm create --resource-group rg-order-prod --name vm-web-01 ...
# 프로젝트 종료 시 그룹 삭제 → 내부 리소스 전체 삭제
az group delete --name rg-order-prod(7) 프로젝트별 리소스 그룹 설계 예시
온라인 주문 서비스를 운영한다고 가정할 때, 수명 주기와 관리 주체를 기준으로 그룹을 나눈다.
| 리소스 그룹 | 포함 리소스 | 분리 이유 |
|---|---|---|
| rg-order-prod | 운영 웹 서버, 애플리케이션 서비스 | 운영 환경은 삭제 대상이 아니며 접근 권한을 제한 |
| rg-order-dev | 개발·테스트용 서버와 데이터베이스 | 테스트 종료 시 그룹째 삭제하여 잔여 비용 방지 |
| rg-order-data | 운영 데이터베이스, 백업 저장소 | 애플리케이션보다 수명이 길고 삭제 위험을 차단해야 함 |
| rg-shared-network | 가상 네트워크, 연결 게이트웨이 | 여러 프로젝트가 공용으로 사용 |
분리 기준은 조직도가 아니라 언제 함께 삭제되는가와 누가 관리하는가이다.
(8) 삭제와 비용 관리를 고려한 구성 원칙
1) 수명 주기 기준 분리
- 함께 생성되고 함께 폐기되는 리소스만 같은 그룹에 배치
- 공용 리소스와 프로젝트 전용 리소스를 분리
- 운영 환경과 개발·테스트 환경을 분리
- 삭제되면 안 되는 리소스에는 삭제 잠금을 설정
2) 비용 추적 기준
- 리소스 그룹은 비용을 집계하는 기본 단위가 됨
- 비용을 분리해서 보고 싶은 단위와 그룹 구분을 일치시킴
- 태그를 사용하면 그룹 경계를 넘어 부서·용도별로 비용을 재집계 가능
3) 명명 규칙
이름만 보고 용도와 환경을 판단할 수 있어야 관리 비용이 줄어든다.
<리소스 종류>-<업무>-<환경>-<일련번호>
rg-order-prod 리소스 그룹 / 주문 / 운영
vm-web-prod-01 가상 머신 / 웹 / 운영 / 1번
vnet-shared-prod 가상 네트워크 / 공용 / 운영- 규칙은 리소스를 만들기 전에 정해야 하며, 나중에 변경하기 어려움
- 일부 리소스는 이름 변경이 불가능하므로 처음 생성 시 확정해야 함
(9) 자료 외 보완
1) 태그의 역할
태그(Tag)는 리소스에 이름과 값의 쌍으로 부여하는 분류 정보이다.
- 리소스 그룹 경계와 무관하게 부서, 용도, 담당자 기준으로 분류 가능
- 비용 보고서에서 태그 단위로 사용 금액을 집계 가능
- 하나의 리소스는 하나의 그룹에만 속하지만, 태그는 여러 개를 동시에 부여 가능
- 태그는 자동으로 상속되지 않으므로 정책으로 부여를 강제하는 경우가 많음
2) 리소스 그룹과 태그의 차이
| 구분 | 리소스 그룹 | 태그 |
|---|---|---|
| 성격 | 실제 소속 컨테이너 | 논리적 분류 라벨 |
| 중복 적용 | 불가능(1개 그룹만) | 가능(여러 태그 부여) |
| 삭제 영향 | 그룹 삭제 시 리소스도 삭제 | 태그 삭제는 리소스에 영향 없음 |
| 주 용도 | 수명 주기와 권한 관리 | 비용 집계와 검색 분류 |
(10) 핵심 정리
- Azure 관리 구조는 Tenant, Management Group, Subscription, Resource Group, Resource의 계층으로 구성된다.
- Tenant는 ID 경계, 구독은 과금과 한도 경계, 리소스 그룹은 수명 주기 경계를 담당한다.
- 모든 리소스는 하나의 리소스 그룹에만 속하며, 그룹을 삭제하면 내부 리소스가 함께 삭제된다.
- 리소스 그룹의 위치는 메타데이터 저장 위치이며, 서로 다른 지역의 리소스를 함께 담을 수 있다.
- 대부분의 리소스는 지역을 지정해야 하지만, 일부 서비스는 지역 개념 없이 전역으로 제공된다.
- 서비스마다 제공 지역이 다르므로 지역을 정하기 전에 필요한 서비스의 제공 여부를 확인해야 한다.
- Portal, CLI, PowerShell, Cloud Shell은 모두 Azure Resource Manager를 호출하므로 결과는 동일하다.
- 리소스 그룹은 조직 구조가 아니라 수명 주기와 관리 주체를 기준으로 나누는 것이 원칙이다.
(11) 핵심 키워드
| 키워드 | 의미 |
|---|---|
| Azure Portal | 웹 화면으로 Azure 리소스를 관리하는 도구 |
| Subscription | 리소스 생성과 과금이 이루어지는 관리 단위 |
| Resource Group | 함께 관리하고 함께 폐기할 리소스를 묶는 컨테이너 |
| Resource | 가상 머신, 스토리지처럼 실제로 생성되는 개별 자원 |
| Azure CLI | 명령줄로 Azure 리소스를 제어하는 도구 |
| Azure PowerShell | PowerShell 명령으로 Azure를 제어하는 도구 |
| Cloud Shell | 설치 없이 브라우저에서 실행하는 명령 환경 |
| Regional Service | 생성 시 지역을 지정해야 하는 서비스 |
| Non-regional Service | 지역 개념 없이 전역에서 제공되는 서비스 |
| Entra Tenant | 조직의 사용자와 그룹을 관리하는 ID 디렉터리 |
| Management Group | 여러 구독에 정책을 일괄 적용하는 상위 계층 |
| Azure Resource Manager | 모든 리소스 요청을 처리하는 단일 관리 계층 |
| Tag | 리소스에 부여하는 이름과 값 형태의 분류 정보 |
(12) 연결되는 개념
- 상위 개념: Azure 관리 구조
- 선행 개념: Azure 글로벌 인프라와 가용성 구조(개념 04)
- 관련 개념: Azure Resource Manager, 태그, 명명 규칙, 수명 주기 관리
- 다음 학습: 컴퓨팅 서비스(개념 07)
- 대응 실습 후보: 자료를 기준으로 명확한 실습 노트를 확인하기 어려움
(13) 다음 학습
- 컴퓨팅 서비스(개념 07): 이 노트에서 정리한 리소스 그룹 안에 실제로 어떤 리소스를 배치하는지 확인하기 위해 필요하다.
- Azure Policy와 거버넌스(개념 15): 구독과 관리 그룹 계층에 어떤 제약을 적용할 수 있는지 확인하기 위해 필요하다.
- 사용자 권한과 RBAC(개념 19): 각 계층에 권한을 어떤 범위로 부여하는지 확인하기 위해 필요하다.
'Cloud > Part 2. Azure 기반 구조' 카테고리의 다른 글
| 8. 클라우드의 엣지 확장과 IoT (1) | 2026.07.26 |
|---|---|
| 6. Azure 글로벌 인프라와 가용성 구조 (0) | 2026.07.26 |
