Azure Storage Account 종류와 선택 기준: Blob, File, Queue, Table

Storage Account는 Azure에서 Blob, File, Queue, Table 데이터를 담는 최상위 컨테이너입니다. 계정 생성 시점에 선택하는 종류(kind)와 성능 계층(performance tier)에 따라 사용 가능한 서비스, 가격 모델, 성능 한도가 달라집니다.

핵심 요약

• Azure Storage Account는 Blob, File, Queue, Table 서비스를 담는 네임스페이스이며, 계정 종류에 따라 사용 가능한 서비스가 달라집니다.
• General-purpose v2(GPv2)가 사실상 표준이며, 대부분의 시나리오에서 기본 선택입니다. GPv1은 2026년 10월 퇴역(retirement) 예정입니다.
• 성능 계층은 Standard(HDD)와 Premium(SSD) 두 가지이며, Premium은 Block Blob, File Shares, Page Blob 세 가지 전용 유형으로 나뉩니다.
• Blob Storage의 접근 티어(Hot, Cool, Cold, Archive)는 저장 비용과 접근 비용의 반비례 관계를 활용해 비용을 최적화합니다.
• 복제 옵션(LRS, ZRS, GRS, GZRS)은 가용성 요구사항과 비용의 균형점에서 선택합니다.

1. 왜 Storage Account 종류를 이해해야 하는가

웹 애플리케이션의 정적 이미지를 저장하려고 Storage Account를 만들었는데, 나중에 같은 계정에 Azure Files를 추가하려고 하니 Premium 성능이 필요합니다. 그런데 이미 만든 계정은 Standard 계층이고, Premium으로 변경하려면 새 계정을 만들어 데이터를 옮겨야 합니다.

이처럼 Storage Account의 종류와 성능 계층은 생성 후 변경할 수 없는 항목이 있습니다. 처음 설계할 때 워크로드 특성을 파악하고 적합한 조합을 선택해야 나중에 마이그레이션 부담을 줄일 수 있습니다.

2. Storage Account가 담는 네 가지 서비스

Storage Account 하나는 최대 네 가지 데이터 서비스를 제공합니다. 각 서비스는 독립적인 API와 데이터 모델을 가집니다.

Azure Storage Account 서비스 구조

서비스	용도	데이터 모델
Blob Storage	비정형 데이터 저장 (이미지, 로그, 백업, 데이터 레이크)	Object (Block Blob, Append Blob, Page Blob)
Azure Files	SMB/NFS 기반 파일 공유	파일 시스템 (디렉터리 + 파일)
Queue Storage	서비스 간 비동기 메시지 전달	메시지 (최대 64KB, TTL 기반)
Table Storage	키-값 기반 반정형 데이터 저장	엔터티 (PartitionKey + RowKey)

실무에서 가장 많이 접하는 조합은 다음과 같습니다.

• 웹 애플리케이션: Blob(정적 파일) + Queue(비동기 작업 큐)
• 레거시 마이그레이션: Azure Files(기존 파일 서버 대체) + Blob(백업)
• 데이터 파이프라인: Blob(Data Lake Storage Gen2) + Table(메타데이터 저장)

Tip
Data Lake Storage Gen2는 별도 서비스가 아니라 Blob Storage 위에 계층적 네임스페이스(Hierarchical Namespace, HNS)를 활성화한 것입니다. HNS를 켜면 디렉터리 수준 작업(rename, delete)이 O(1)로 동작하므로 대규모 분석 워크로드에 적합합니다. 다만 HNS 활성화는 계정 생성 후 변경할 수 없으므로 분석 용도라면 처음부터 설정합니다.

3. Storage Account 종류 (Kind)

Azure는 여러 Storage Account 종류를 제공하지만, 현재 실무에서 신규 생성 시 고려할 유형은 사실상 두 가지입니다.

Azure Storage Account 종류 비교

3.1 General-purpose v2 (GPv2) — 기본 선택

항목	내용
지원 서비스	Blob, Files, Queue, Table 전부
성능 계층	Standard 또는 Premium
접근 티어	Hot, Cool, Cold, Archive (Blob에 적용)
Data Lake Storage Gen2	지원 (HNS 활성화 시)
권장 시나리오	대부분의 워크로드

GPv2는 Azure가 공식적으로 권장하는 기본 계정 유형입니다. 모든 Storage 기능을 지원하며, 접근 티어를 활용한 비용 최적화가 가능합니다.

3.2 Premium 전용 유형 — 낮은 지연 시간이 필요할 때

Premium 성능이 필요한 경우, 워크로드별로 세 가지 전용 계정 유형을 선택합니다.

Premium 유형	지원 서비스	사용 시나리오
Premium Block Blob	Block Blob, Append Blob	IoT 스트리밍, AI/ML 학습 데이터, 트랜잭션이 많은 앱
Premium File Shares	Azure Files (SMB/NFS)	데이터베이스 로그, 고성능 파일 공유, NFS가 필요한 Linux 워크로드
Premium Page Blob	Page Blob	비관리 디스크 (레거시), 커스텀 VHD

주의
Premium 계정은 SSD 기반으로 일관된 낮은 지연 시간(밀리초 이하)을 제공하지만, Hot/Cool/Archive 접근 티어를 지원하지 않습니다. 또한 Premium Block Blob 계정에는 Azure Files를 함께 사용할 수 없습니다. 워크로드를 분리해서 각각 적합한 계정을 만드는 것이 일반적입니다.

3.3 레거시 유형 (신규 생성 비권장)

유형	상태
General-purpose v1 (GPv1)	2026년 10월 퇴역 예정. 신규 생성 차단됨
BlobStorage	GPv2로 대체됨. 기능 제한

GPv1 계정을 아직 운영 중이라면 GPv2로 업그레이드를 검토해야 합니다. 업그레이드는 다운타임 없이 수행 가능하며 데이터 복사가 필요하지 않습니다.

4. 성능 계층: Standard vs Premium

성능 계층은 Storage Account의 물리적 저장 매체와 성능 특성을 결정합니다. 계정 생성 후 변경할 수 없습니다.

Azure Storage 성능 계층 비교

기준	Standard	Premium
저장 매체	HDD (Magnetic)	SSD (Solid State)
지연 시간	수 밀리초	밀리초 이하 (sub-millisecond)
처리량	계정당 최대 60 Gbps (egress)	워크로드별 상이, 단일 Blob당 높은 IOPS
과금 모델	저장 용량 + 트랜잭션 + 데이터 전송	프로비저닝된 용량 기반 (사용량 무관)
접근 티어	Hot, Cool, Cold, Archive	없음 (단일 티어)
비용 특성	저장 비용 낮음, 트랜잭션 비용 있음	저장 비용 높음, 트랜잭션 포함

선택 기준

Standard를 선택하는 경우: - 대부분의 일반 워크로드 (웹 앱 정적 파일, 로그, 백업) - 비용이 우선이고, 수 밀리초 지연 시간이 허용되는 경우 - 접근 티어를 활용한 비용 최적화가 필요한 경우

Premium을 선택하는 경우: - 일관된 낮은 지연 시간이 필수인 워크로드 (데이터베이스 로그, 실시간 분석) - 높은 트랜잭션 빈도에서 Standard의 트랜잭션 비용이 Premium 프로비저닝 비용을 초과하는 경우 - NFS 프로토콜이 필요한 Linux 파일 공유

Tip
Premium이 항상 비싼 것은 아닙니다. 트랜잭션이 매우 빈번한 워크로드에서는 Standard의 트랜잭션 비용 합계가 Premium의 프로비저닝 비용보다 높아질 수 있습니다. 비용 비교는 예상 트랜잭션 수와 저장 용량을 함께 계산해야 합니다.

5. 접근 티어 (Access Tier) — Blob Storage 비용 최적화

접근 티어는 Standard GPv2 계정의 Blob Storage에 적용되며, 데이터 접근 빈도에 따라 저장 비용과 접근 비용의 균형을 조절합니다.

Azure Blob Storage 접근 티어 비용 구조

티어	저장 비용	접근 비용	최소 보존 기간	데이터 상태
Hot	높음	낮음	없음	온라인 (즉시 접근)
Cool	중간	중간	30일	온라인 (즉시 접근)
Cold	낮음	높음	90일	온라인 (즉시 접근)
Archive	매우 낮음	매우 높음	180일	오프라인 (리하이드레이션 필요)

핵심 원칙: 접근 빈도가 낮을수록 저장 비용은 줄지만, 읽을 때 비용과 시간이 늘어납니다.

5.1 티어별 실무 시나리오

시나리오	권장 티어	이유
웹 앱 이미지/동영상	Hot	사용자 요청마다 읽히므로 접근 비용이 낮아야 함
30일 이상 된 로그 파일	Cool	가끔 조회하지만 빈번하지 않음
90일 이상 된 감사 로그	Cold	규정상 보관하지만 거의 조회하지 않음
연간 백업, 규제 아카이브	Archive	년 단위 보관, 복원 시 수 시간 허용

5.2 최소 보존 기간과 조기 삭제 비용

Cool/Cold/Archive 티어에는 최소 보존 기간이 있습니다. 이 기간 전에 데이터를 삭제하거나 다른 티어로 이동하면 조기 삭제 비용(early deletion charge)이 발생합니다.

예를 들어 Cool 티어에 데이터를 넣고 10일 후에 삭제하면, 나머지 20일분의 저장 비용이 추가 청구됩니다. 이 점을 고려하면 자주 변경되는 데이터는 처음부터 Hot 티어에 두는 것이 비용 효율적입니다.

5.3 Archive 리하이드레이션

Archive 티어의 데이터는 오프라인 상태이므로 읽기 전에 리하이드레이션(rehydration)이 필요합니다.

리하이드레이션 우선순위	소요 시간	비용
Standard	최대 15시간	낮음
High	최대 1시간 (10GB 미만)	높음

주의
Archive에서 데이터를 복원하는 데 최대 15시간이 걸릴 수 있으므로, 즉시 복원이 필요한 재해 복구(DR) 시나리오에는 적합하지 않습니다. DR 용도의 백업은 Cool 또는 Cold 티어를 검토합니다.

5.4 Smart Tier (자동 티어링)

2026년 4월에 GA된 Smart Tier 기능은 접근 패턴을 자동으로 분석해 데이터를 Hot → Cool → Cold로 이동합니다.

• 30일 미접근 → Cool로 이동
• 추가 60일 미접근 → Cold로 이동
• 다시 접근하면 → Hot으로 즉시 복귀

수동으로 티어를 관리하기 어려운 대규모 환경에서 운영 부담 없이 비용을 절감할 수 있습니다. Smart Tier가 관리하는 오브젝트에는 티어 전환 비용, 조기 삭제 비용, 데이터 검색 비용이 부과되지 않으며 월별 모니터링 비용만 발생합니다. 128KB 미만의 작은 오브젝트는 Hot에 유지되며 모니터링 비용도 부과되지 않습니다.

다만 Archive 티어로의 자동 이동은 포함되지 않으므로 장기 보관은 수명 주기 관리 정책(Lifecycle Management Policy)으로 별도 설정합니다.

6. 복제 옵션 (Redundancy) — 가용성 설계

Azure Storage는 항상 데이터를 여러 복사본으로 유지합니다. 복제 수준에 따라 보호 범위와 비용이 달라집니다.

Azure Storage 복제 옵션 비교

옵션	복제 범위	복사본 수	SLA (읽기)	적합한 시나리오
LRS	단일 데이터센터 내	3개	99.9%	비용 우선, 데이터 재생성 가능
ZRS	같은 리전의 3개 가용영역	3개	99.9%	단일 데이터센터 장애 보호
GRS	주 리전 LRS + 보조 리전 LRS	6개	99.9% (RA-GRS: 99.99%)	리전 장애 대비, 보조 리전 읽기 불필요
GZRS	주 리전 ZRS + 보조 리전 LRS	6개	99.9% (RA-GZRS: 99.99%)	최고 수준 가용성, 리전+존 장애 보호

6.1 선택 기준

개발/테스트 환경 → LRS (비용 최소화)
프로덕션, 단일 리전 → ZRS (데이터센터 장애 보호)
프로덕션, 리전 장애 대비 → GRS 또는 GZRS
규제 산업, 최고 가용성 → RA-GZRS (보조 리전 읽기 가능)

6.2 RA-GRS/RA-GZRS: 보조 리전 읽기

GRS와 GZRS의 Read-Access 버전(RA-GRS, RA-GZRS)은 보조 리전에서 데이터를 읽을 수 있습니다. 주 리전에 장애가 발생해도 보조 리전의 읽기 전용 엔드포인트(-secondary 접미사)로 데이터를 조회할 수 있어 서비스 연속성을 높일 수 있습니다.

다만 비동기 복제이므로 RPO(Recovery Point Objective)는 보통 15분 이내입니다. 가장 최근 15분간의 데이터는 보조 리전에 아직 반영되지 않았을 수 있습니다.

Security Note
GRS/GZRS 계정에서 장애 조치(failover)를 수행하면 보조 리전이 새로운 주 리전이 됩니다. 이 과정에서 접근 키는 변경되지 않지만, Private Endpoint나 방화벽 규칙이 보조 리전의 네트워크와 맞는지 사전에 확인해야 합니다.

7. 실무 설계 시나리오

시나리오 1: 웹 애플리케이션 정적 파일 + 비동기 작업

전자상거래 사이트에서 상품 이미지를 저장하고, 주문 이벤트를 큐로 전달해야 합니다.

선택: Standard GPv2, Hot 티어, ZRS

결정	이유
GPv2	Blob + Queue를 한 계정에서 사용
Standard	이미지 서빙은 수 밀리초면 충분, CDN과 조합
Hot	상품 이미지는 상시 접근됨
ZRS	프로덕션이므로 단일 DC 장애 보호 필요

비용 절감 포인트: Azure CDN을 Blob 앞에 배치하면 원본 접근 횟수(트랜잭션)를 줄이고, CDN 엣지에서 응답하므로 사용자 지연 시간도 개선됩니다.

시나리오 2: 대규모 로그 아카이빙

보안 감사 로그를 5년간 보관해야 하는 규제 환경입니다. 로그는 쓰기 후 거의 조회하지 않습니다.

선택: Standard GPv2, Lifecycle Management Policy 적용, GRS

결정	이유
GPv2	접근 티어 활용 필수
Standard	아카이브 워크로드에 Premium 불필요
Lifecycle Policy	30일 후 Cool → 90일 후 Cold → 365일 후 Archive 자동 전환
GRS	규제 요건상 리전 장애 시에도 데이터 보존 필요

Lifecycle Management Policy 예시:

{
  "rules": [
    {
      "name": "audit-log-tiering",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToCold": { "daysAfterModificationGreaterThan": 90 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 365 },
            "delete": { "daysAfterModificationGreaterThan": 1825 }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["audit-logs/"]
        }
      }
    }
  ]
}

시나리오 3: AI/ML 학습 데이터 저장소

ML 모델 학습 시 수백만 개의 작은 파일을 빠르게 읽어야 합니다. 트랜잭션 수가 매우 많고 지연 시간이 학습 속도에 직접 영향을 줍니다.

선택: Premium Block Blob, LRS

결정	이유
Premium Block Blob	높은 IOPS와 밀리초 이하 지연 시간 필수
LRS	학습 데이터는 원본에서 재생성 가능, 비용 절감

이 경우 Standard 대비 트랜잭션당 비용이 없으므로, 수백만 트랜잭션이 발생하는 학습 워크로드에서는 오히려 총 비용이 낮아질 수 있습니다.

8. 보안 고려사항

항목	권장 설정
공용 접근	기본 비활성화 (컨테이너 수준 public access 차단)
네트워크	Private Endpoint + 서비스 방화벽으로 접근 제한
인증	Managed Identity + RBAC (접근 키 사용 최소화)
암호화	기본 Microsoft 관리 키, 민감 데이터는 고객 관리 키(CMK)
불변성	규제 데이터는 Immutable Blob Storage (WORM) 적용
전송 보안	HTTPS만 허용 (Secure transfer required 활성화)

Security Note
Storage Account의 접근 키(Access Key)는 계정의 모든 데이터에 대한 전체 권한을 부여합니다. 운영 환경에서는 접근 키 대신 Microsoft Entra ID + RBAC(예: Storage Blob Data Reader)를 사용하는 것이 안전합니다. 접근 키가 필요한 레거시 시나리오에서는 키 순환(rotation)을 자동화합니다.

9. 비용 구조 이해

Azure Storage 비용은 단순히 GB당 가격이 아니라 여러 요소의 합산입니다.

비용 항목	설명
저장 용량	GB/월 단위, 티어별 단가 다름
트랜잭션	읽기/쓰기 요청 10,000건당 과금 (티어별 단가 다름)
데이터 검색	Cool/Cold/Archive에서 읽을 때 GB당 추가 비용
데이터 전송 (egress)	Azure 외부로 나가는 트래픽 GB당 과금
조기 삭제	최소 보존 기간 미달 시 잔여 기간분 청구

주의
접근 티어를 Cool로 내려 저장 비용을 줄였더라도, 예상보다 접근이 잦으면 트랜잭션+검색 비용이 Hot 티어 저장 비용보다 높아질 수 있습니다. 티어 선택 전에 접근 패턴을 분석하거나, Smart Tier를 활용해 자동 최적화를 검토합니다.

10. 선택 의사결정 흐름

전체 의사결정을 요약하면 다음과 같습니다.

Azure Storage Account 선택 의사결정 흐름

1. 밀리초 이하 지연 시간이 필요한가?
   ├─ Yes → Premium (Block Blob / File Shares / Page Blob 중 선택)
   └─ No → Standard GPv2

2. 어떤 서비스가 필요한가?
   ├─ Blob + Queue + Table → Standard GPv2
   ├─ File Shares (NFS) → Premium File Shares
   └─ Block Blob (고성능) → Premium Block Blob

3. 복제 수준은?
   ├─ 개발/테스트 → LRS
   ├─ 프로덕션(단일 리전) → ZRS
   └─ 프로덕션(리전 장애 대비) → GRS 또는 GZRS

4. Blob 접근 패턴은? (Standard만 해당)
   ├─ 상시 접근 → Hot
   ├─ 월 1회 이하 → Cool
   ├─ 분기 1회 이하 → Cold
   └─ 연 1회 이하 → Archive (또는 Lifecycle Policy로 자동 전환)

11. 자주 하는 실수

1. 모든 데이터를 Hot 티어에 방치하는 것: 생성 후 접근하지 않는 데이터가 Hot에 남아 있으면 불필요한 저장 비용이 발생합니다. Lifecycle Management Policy를 초기부터 설정합니다.
2. Premium이 필요 없는데 선택하는 것: Premium은 SSD 기반으로 비용이 높고 접근 티어를 지원하지 않습니다. 일반적인 파일 저장이나 백업에는 Standard가 적합합니다.
3. 계정 하나에 모든 워크로드를 넣는 것: Storage Account에는 IOPS와 대역폭 한도가 있습니다. 서로 다른 성능 요구사항을 가진 워크로드는 계정을 분리해야 한 쪽의 부하가 다른 쪽에 영향을 주지 않습니다.
4. 복제 옵션을 비용만으로 선택하는 것: LRS가 가장 저렴하지만 데이터센터 장애 시 데이터 손실 위험이 있습니다. 프로덕션 데이터는 최소 ZRS를 검토합니다.
5. Archive 티어에 DR 백업을 넣는 것: 복원에 최대 15시간이 걸리므로 즉시 복구가 필요한 시나리오에는 적합하지 않습니다.

12. 정리

• Storage Account 종류는 GPv2를 기본으로 선택합니다. Premium이 필요한 경우에만 전용 유형을 사용합니다.
• 성능 계층(Standard/Premium)은 생성 후 변경할 수 없으므로, 워크로드의 지연 시간 요구사항을 먼저 파악합니다.
• 접근 티어는 저장 비용과 접근 비용의 반비례 관계를 활용합니다. 접근 패턴이 예측 어려우면 Smart Tier 또는 Lifecycle Policy를 활용합니다.
• 복제 옵션은 가용성 요구사항(단일 DC, 단일 리전, 리전 간)과 비용의 균형점에서 선택합니다.
• 보안은 Private Endpoint + RBAC + HTTPS 전용을 기본으로 설계합니다.

참고 문서

• Azure 공식 문서: Storage Account 개요
• Azure 공식 문서: Blob Storage 접근 티어
• Azure 공식 문서: 데이터 복제(Redundancy)
• Azure 공식 문서: GPv1 퇴역 안내
• Azure 공식 문서: Lifecycle Management Policy
• Azure 공식 문서: Smart Tier