스토리지 계정 (종류, 중복성, 보안)
스토리지 계정 하나에 들어가는 서비스(Blob, Files, Queue, Table), 계정 종류와 성능 계층, LRS 부터 RA-GZRS 까지 중복성 고르는 법, 키 대신 Entra 인증, 공용 액세스와 네트워크 차단, 데이터 보호 기능, 한도와 비용 요령을 정리합니다.
스토리지 계정이 담는 것
스토리지 계정은 Azure 스토리지의 최상위 리소스이고 이름이 전역 고유한 주소(https://<계정>.blob.core.windows.net)가 됩니다. 한 계정 안에 네 가지 데이터 서비스가 있습니다.
| 서비스 | 용도 | 엔드포인트 |
|---|---|---|
| Blob | 파일, 이미지, 백업, 로그, 데이터 레이크 | blob.core.windows.net, dfs.core.windows.net (ADLS Gen2) |
| Files | SMB, NFS 파일 공유 | file.core.windows.net |
| Queue | 간단한 메시지 큐 | queue.core.windows.net |
| Table | 키 값 NoSQL | table.core.windows.net |
계정 종류
| 종류 | 성능 | 용도 |
|---|---|---|
| Standard 범용 v2 (StorageV2) | HDD 기반 표준 | 거의 모든 경우의 기본 |
| Premium 블록 Blob | SSD | 작은 객체를 매우 많이, 낮은 지연으로 |
| Premium 파일 공유 | SSD | 고성능 Azure Files |
| Premium 페이지 Blob | SSD | 특수한 페이지 Blob 워크로드 |
범용 v1 과 예전 Blob Storage 계정은 새로 만들지 않습니다. 기존 계정은 범용 v2 로 업그레이드할 수 있습니다.
중복성 고르기
| 옵션 | 복사본 | 견디는 장애 | 비고 |
|---|---|---|---|
| LRS | 한 데이터센터에 3개 | 디스크, 랙 장애 | 가장 쌈 |
| ZRS | 리전 안 3개 영역에 1개씩 | 데이터센터(영역) 장애 | Korea Central 운영 기본 추천 |
| GRS | LRS + 쌍 리전에 LRS | 리전 장애 (장애 조치 뒤) | 보조 리전은 쌍으로 고정 |
| GZRS | ZRS + 쌍 리전에 LRS | 영역과 리전 장애 | 가장 튼튼 |
| RA-GRS, RA-GZRS | 위와 같음 + 보조 리전 읽기 | 리전 장애 중에도 읽기 | -secondary 엔드포인트 |
Korea Central 의 쌍 리전은 Korea South 이므로 GRS 계열의 보조 복사본은 부산에 있습니다. 리전 간 복제는 비동기이므로 장애 조치 때 마지막 몇 분의 데이터를 잃을 수 있습니다(Last Sync Time 확인). Blob 의 자동 계층인 smart tier 는 ZRS, GZRS, RA-GZRS 계정에서만 됩니다 (Blob 계층 참고).
az storage account create -g rg-shop-prod -n stshopprodkrc -l koreacentral \
--sku Standard_ZRS --kind StorageV2 --min-tls-version TLS1_2 \
--allow-blob-public-access false --allow-shared-key-access false \
--public-network-access Disabled인증: 키보다 Entra
| 방식 | 특징 | 권장 |
|---|---|---|
| 계정 키 (공유 키) | 계정 전체 권한. 유출되면 끝 | 끄기 (allowSharedKeyAccess=false) |
| SAS 토큰 | 범위와 기간 제한 | 꼭 필요하면 사용자 위임 SAS (Entra 기반) |
| Microsoft Entra ID | RBAC 역할로 데이터 평면 권한 | 기본 |
| 익명 공용 읽기 | 누구나 읽음 | 끄기. 정적 콘텐츠는 Front Door 뒤에 |
키 인증을 끄면 앱은 관리 ID 와 Storage Blob Data Reader, Contributor 같은 데이터 역할이 필요합니다. Contributor 만 있으면 403 이 나는 이유는 RBAC 와 Policy의 제어 평면, 데이터 평면 설명을 봅니다. 일부 도구(오래된 SDK, 일부 서드파티 백업 제품)는 키만 지원할 수 있으니 끄기 전에 확인합니다.
네트워크 차단
- 공용 네트워크 액세스 사용 안 함 + Private Endpoint: 가장 닫힌 구성. 서비스(blob, dfs, file)마다 Private Endpoint 와 Private DNS 영역이 따로 필요합니다.
- 선택한 네트워크만 허용: 방화벽 규칙(IP 범위), VNet 서비스 엔드포인트, 리소스 인스턴스 규칙(특정 Azure 서비스 인스턴스 허용).
- 신뢰할 수 있는 Microsoft 서비스 예외: Azure Backup, Event Grid 같은 서비스가 관리 ID 로 들어오게 허용.
데이터 보호
| 기능 | 막아 주는 것 |
|---|---|
| Blob 소프트 삭제 | 실수로 지운 Blob (보존 기간 1~365일) |
| 컨테이너 소프트 삭제 | 실수로 지운 컨테이너 |
| Blob 버전 관리 | 덮어쓰기. 이전 버전으로 복원 |
| 특정 시점 복원 | 블록 Blob 을 과거 시점으로 되돌림 |
| 불변 저장소 (WORM) | 정해진 기간 동안 수정, 삭제 금지. 규제 보관 |
| 리소스 잠금 | 계정 자체 삭제 |
운영 계정은 소프트 삭제(7~30일)와 버전 관리를 기본으로 켜고, 버전이 쌓여 비용이 늘지 않게 수명 주기 관리로 오래된 버전을 지웁니다. 계정 자체를 지우는 것은 소프트 삭제로 막을 수 없으므로 CanNotDelete 잠금을 겁니다.
성능과 한도
- 계정 하나의 처리량과 요청 수에 한도가 있습니다(리전, 중복성마다 다름). 아주 큰 워크로드는 계정을 나눕니다.
- 같은 접두사(prefix)에 요청이 몰려도 Azure 가 파티션을 자동으로 나누지만, 시간 순 이름(
2026/10/21/...)에 폭발적인 쓰기가 몰리면 일시적인 503(ServerBusy)이 날 수 있습니다. 재시도는 SDK 의 지수 백오프에 맡깁니다. - 구독, 리전당 만들 수 있는 스토리지 계정 수에도 한도가 있습니다. 계정을 앱마다 무한정 만들지 말고 구독 한도 문서를 확인합니다.
비용 요령
- 중복성은 비용에 바로 반영됩니다. 다시 만들 수 있는 데이터(빌드 산출물, 캐시)는 LRS 로 충분합니다.
- 접근이 드문 데이터는 Cool, Cold, Archive 로 내립니다. 단, 최소 보관 기간과 읽기 요금이 있습니다.
- 트랜잭션 요금이 의외로 큽니다. 작은 파일 수백만 개를 자주 나열(list)하는 패턴은 비용과 성능 모두 나쁩니다.
- 같은 리전 안 VM 과 스토리지 사이 전송은 무료지만, 인터넷으로 나가는 데이터는 Bandwidth 요금이 붙습니다.