한눈에 보기
- 대기업용 ‘랜딩 존’은 과하고, 1인·소규모에 맞는 최소한의 구독·리소스 그룹 구조를 제안합니다.
- 핵심: 환경(운영/개발) 분리와 리소스 그룹은 수명주기 단위로.
- 태그·예산 알림만 얹어도 충분히 정돈됩니다.
‘랜딩 존’이라 하면 거창해 보이지만, 핵심은 ‘나중에 후회 안 할 최소한의 정리 구조’입니다. 1인·소규모라면 복잡한 관리 그룹 위계 없이도 충분합니다.
구독은 어떻게 나눌까
소규모라면 보통 구독 1~2개면 됩니다. 운영과 개발/테스트의 비용·권한을 확실히 가르고 싶으면 구독을 둘로(운영 / 비운영) 나누는 게 깔끔합니다. 그 이상 쪼개는 건 대개 과합니다.
리소스 그룹은 ‘수명주기’ 단위로
함께 만들고 함께 지우는 것끼리 한 리소스 그룹에 둡니다. 예: 한 서비스의 웹앱+DB+스토리지를 하나로. 그러면 정리할 때 그룹째 삭제하면 됩니다.
| 구분 | 예시 | 기준 |
|---|---|---|
| 구독 | 운영 / 개발 | 비용·권한 경계 |
| 리소스 그룹 | rg-blog-prod | 함께 생성·삭제되는 단위 |
| 태그 | env, owner | 추적·비용 분석 |
꼭 얹어야 할 3가지
- 일관된 이름 규칙 — rg-{서비스}-{환경}, vm-{용도}-{번호}처럼 한 패턴으로.
- 예산 알림 — 구독에 월 예산과 80%/100% 알림을 걸어 폭탄 방지.
- 기본 태그 — env·owner만이라도 전 리소스에 일관 적용.
# 예산 알림(개념 예시)
az consumption budget create --budget-name monthly \
--amount 50 --time-grain Monthly --category Cost흔한 실수
- 처음부터 관리 그룹 위계를 과하게 — 소규모엔 관리 부담만 늘어납니다.
- 리소스 그룹을 리전·종류별로 잘게 — 수명주기 기준이 더 실용적입니다.
- 예산 알림 미설정 — 비용 사고의 가장 흔한 원인입니다.
자주 묻는 질문(FAQ)
- Q. 구독을 꼭 나눠야 하나요? A. 필수는 아닙니다. 운영/개발 비용·권한을 확실히 가르고 싶을 때 둘로 나누면 깔끔합니다.
- Q. 리소스 그룹 기준이 헷갈려요. A. ‘같이 만들고 같이 지우는가’를 기준으로 묶으면 거의 맞습니다.
- Q. 나중에 구조를 바꿀 수 있나요? A. 리소스 이동·구독 변경이 가능하지만 번거롭습니다. 초기에 최소 규칙만 잡아두면 이전이 쉽습니다.
마치며
소규모 랜딩 존은 ‘구독으로 환경 분리, 리소스 그룹은 수명주기, 태그·예산 알림 얹기’ 세 줄이면 충분합니다. 과한 위계보다 일관성이 중요합니다.