🏆 2024

맛집 분야 크리에이터

🏆 2023

IT 분야 크리에이터

👩‍❤️‍👨 구독자 수

203

✒️ 게시글 수

https://tistory1.daumcdn.net/tistory/4631271/skin/images/blank.png

네이버블로그

🩷 방문자 추이

오늘

어제

전체

🏆 인기글 순위

티스토리 뷰

개발환경/Server

Azure AZ-104 공부하기 3. Azure 내 스토리지 구현 및 관리

돔돔이 2025. 5. 27. 16:09

728x90

이전 글을 보려면 아래 링크를 클릭하세요~

Azure AZ-104 공부하기 1. Azure 관리자 필수 조건

✅ 1. Azure Cloud Shell이란?Azure 리소스를 명령줄로 관리할 수 있는 웹 브라우저로 액세스 가능한 웹기반 명령줄 환경.Microsoft에서 Cloud Shell을 관리하므로 어떤 브라우저에서든 최신 버전의 Azure CLI

domdom.tistory.com

Azure AZ-104 공부하기 2. Azure 내 ID 및 거버넌스 관리

이전 글을 보려면 아래 링크를 클릭하세요~Azure AZ-104 공부하기 1. Azure 관리자 필수 조건https://domdom.tistory.com/766 Azure AZ-104 공부하기 1. Azure 관리자 필수 조건✅ 1. Azure Cloud Shell이란?Azure 리소스를

domdom.tistory.com

✅ 1. Azure Storage란?

최신 데이터 스토리지 시나리오용 Microsoft 클라우드 스토리지 솔루션입니다. 매우 대규모로 확장 가능한 저장소를 제공해, 다양한 형태의 데이터를 저장할 수 있어요. 클라우드를 위한 파일 시스템 서비스, 안정적인 메시징을 위한 메시징 저장소, NoSQL 저장소를 제공합니다.
파일, 메시지, 테이블 및 기타 유형의 정보를 저장하는 데 사용할 수 있는 AI 지원 서비스입니다. 관리자는 파일 공유 같은 애플리케이션에 사용하고, 개발자는 웹사이트, 모바일 앱, 데스크톱 앱의 작업 데이터 저장에 사용합니다. 또한, Azure Storage는 가상 머신(IaaS)과 클라우드 서비스(PaaS)에서도 활용됩니다.

세 가지 데이터 범주를 지원합니다:데이터 종류설명사용하는 Azure 서비스

가상 머신 데이터	가상 머신에 연결되는 영구 디스크 및 파일 공유. 데이터베이스 파일, 웹 사이트 콘텐츠 저장에 사용.	Azure 관리 디스크, 클라우드 파일 공유
비정형 데이터 (예: 이미지, 문서 등)	규칙이 없거나 구조화되지 않은 데이터(사진, 영상 등). 대용량 데이터 저장에 적합.	Azure Blob Storage, Azure Data Lake Storage
정형 데이터 (예: 테이블 데이터)	행과 열로 구성된 구조적 데이터. 관계형 또는 NoSQL 형태로 저장.	Azure Table Storage, Azure Cosmos DB, Azure SQL Database

Azure Storage 구성을 계획하려고 할 때 다음 주요 기능을 고려합니다.
1. 내구성 및 가용성 : Azure Storage는 내구성이 뛰어나고 고가용성입니다. 데이터를 오래 안전하게 보관하고, 갑작스러운 장애(정전, 천재지변 등)에도 서비스를 계속 유지할 수 있도록 복제됩니다.
2. 보안 : 저장된 데이터는 모두 자동으로 암호화되며, 누가 접근할 수 있는지도 세밀하게 설정할 수 있습니다.
3. 확장성(스케일링) : 사용자 수나 데이터량이 늘어나도, 자동으로 필요한 만큼 확장되어 큰 규모의 서비스도 지원할 수 있습니다.
4. 관리 편의성 : 서버 유지보수, 보안 업데이트 등은 Microsoft가 알아서 처리해주므로 사용자는 설정과 사용에만 집중하면 됩니다.
5. 데이터 접근성 : 데이터를 웹주소(HTTP/HTTPS)로 접근할 수 있고, Azure Storage용 SDK를 다양한 언어(.NET, Python, Java 등)로 제공하며, Azure PowerShell 또는 Azure CLI에서 스크립트를 지원하고, 웹 포털에서 쉽게 사용할 수 있습니다. Azure Portal 및 Azure Storage Explorer는 데이터 작업을 위한 간편한 시각적 솔루션을 제공합니다.

1-1. Azure Blob Storage (애저 블롭 스토리지)

클라우드를 위한 Microsoft의 개체 스토리지 솔루션입니다. Blob은 Binary Large Object를 뜻합니다. Blob Storage를 개체 스토리지 또는 컨테이너 스토리지라고도 합니다.
Blob Storage는 텍스트 또는 이진 데이터와 같은 이미지, 문서, 영상 등 대량의 비정형 또는 비관계형 데이터를 저장하는 데 최적화되어 있습니다.
저장된 Blob Storage의 개체파일은 HTTP/HTTPS로 접근 가능하고, URL이나 Azure Storage REST API, Azure PowerShell, Azure CLI 또는 Azure Storage 클라이언트 라이브러리를 통해 Blob에 액세스할 수 있습니다.
Blob Storage가 적합한 경우는 다음과 같습니다.
- 웹 브라우저에 이미지/문서 직접 제공
- 여러 장치에서 접근 가능한 파일 저장 (분산 액세스용 파일 저장)
- 영상/오디오 스트리밍
- 백업/복원, 재해 복구 및 장기 보관용 데이터 저장
- 온-프레미스 또는 Azure 호스팅 서비스에서 분석하기 위한 분석용 데이터 저장.

1-2. Azure Files

Azure Files를 사용하면 고가용성 네트워크 파일 공유를 설정할 수 있습니다.
SMB(서버 메시지 블록)/NFS(네트워크 파일 시스템) 프로토콜을 사용하여 접근 가능한 클라우드 기반 파일 공유 서비스입니다.
여러 가상 머신에서 동시에 읽기 및 쓰기 액세스 권한 모두를 사용하여 동일한 파일을 공유할 수 있습니다.
네트워크 드라이브처럼 탑재 가능하며 고가용성을 보장합니다.
REST 인터페이스 또는 스토리지 클라이언트 라이브러리를 사용하여 파일을 읽을 수도 있습니다.
파일 공유를 사용할 수 있는 여러 가지 일반적인 시나리오는 다음과 같습니다.
- 온-프레미스 애플리케이션에서 클라우드 마이그레이션 (여러 온-프레미스 애플리케이션에서 파일 공유를 사용)
- 여러 VM이 구성 파일 공유
- 개발 도구/유틸리티 공유
- 로그/메트릭/덤프 파일 저장 (파일 공유에 쓰고 나중에 처리하거나 분석할 수 있는 데이터의 세 가지 예로 진단 로그, 메트릭 및 크래시 덤프를 들 수 있습니다.)
파일 공유 액세스에 대한 인증을 제공하기 위해 스토리지 계정 자격 증명이 사용됩니다. 공유가 탑재된 모든 사용자는 공유에 대한 전체 읽기/쓰기 권한이 있어야 합니다.

1-3. Azure Queue Storage (Azure 대기열 저장소)

한 마디로 말하면 해야 할 일(To-Do) 을 잠시 저장해 두는 대기열(Queue) 공간이에요. 메시지를 하나씩 꺼내서 처리할 수 있어요. 메시지를 저장하고 검색하는 데 사용됩니다. 큐 메시지의 크기는 최대 64KB일 수 있고, 한 큐에 엄청 많은 메시지를 저장할 수 있습니다. 큐는 비동기적으로 처리할 메시지 목록을 저장하는 데 사용됩니다. 처리 순서대로 하나씩 꺼내서 처리 가능하며, 여러 작업을 비동기식으로 효율적으로 분산처리할 수 있습니다.

1-4. Azure Table Storage (애저 테이블 저장소)

엑셀처럼 생긴 테이블 형식에 데이터를 저장하는 공간인데, 전통적인 관계형 데이터베이스(SQL) 와는 달리 비관계형 구조화된 데이터(구조화된 NoSQL 데이터라고도 함)를 저장하는 서비스로 자유롭고 유연한 구조를 가졌어요.
스키마 없는 설계로 키/특성 저장소를 제공합니다. 스키마가 없기 때문에 애플리케이션의 요구 사항이 변화함에 따라 데이터를 쉽게 적응시킬 수 있습니다.
Table Storage 데이터에 대한 액세스는 많은 애플리케이션 유형에 대해 빠르고 비용 효율적이며 비슷한 양의 데이터일 때 일반적으로 전통적인 SQL에 비해 비용이 매우 낮습니다. 기존 Azure Table Storage 서비스 외에도, 처리량 최적화 테이블, 전역 배포 및 자동 보조 인덱스를 제공하는 새로운 Azure Cosmos DB Table API 제품이 있습니다.
고객 정보, 로그 데이터, 설정 값 등 간단하고 빠르게 저장하고 조회만 하면 되는 데이터에 적합해요.

1-5. Azure Storage 서비스를 선택할 때 고려해야 할 사항

Azure Storage에 대한 구성 계획을 구상할 때 Azure Storage 유형의 주요 기능과 애플리케이션 요구 사항을 지원하는 옵션을 고려합니다. (각각 저장하는 데이터의 형태나 사용 목적에 따라 적절한 걸 골라야 해요.)
1. 대용량 데이터를 저장할것인가?
  - Azure Blob Storage.
  - Azure Blob Storage는 대량의 비정형 데이터를 저장하는 데 최적화되어 있습니다.
2. 고가용성이 있는 스토리지를 고려하는가? (여러 사용자나 서버가 동시에 파일을 공유해야하는가?)
  - Azure Filees.
  - Azure Files는 고가용성 네트워크 파일 공유를 지원합니다.
3. 메시지 스토리지를 고려하는가? (메시지를 잠깐 저장해서 처리할 작업 목록이 필요한가?)
  - Azure Queue Storage.
  - Azure Queue Storage를 사용하여 많은 수의 메시지를 저장합니다.
4. 정형 데이터에 대한 스토리지를 고려하는가? (간단한 구조화된 데이터를 빠르고 싸게 저장하고 싶은가?)
  - Azure Table Storage.
  - Azure Table Storage는 구조화된 비관계형 데이터를 저장하는 데 이상적입니다.

💽 2. Azure Storage account (스토리지 계정, 어떤 걸 써야할까?)

Azure에서는 데이터를 저장할 때 스토리지 계정이라는 걸 먼저 만들게 돼요. 이때 두 가지 주요 선택지가 있습니다:
1. 🟦 표준(Standard) 스토리지 계정
  - 표준 스토리지 계정은 마그네틱 HDD(하드 디스크 드라이브)를 통해 지원됩니다. 표준 스토리지 계정은 GB당 비용이 가장 낮습니다. 대량 저장소가 필요하거나 데이터 액세스가 자주 발생하지 않는 애플리케이션에 표준 스토리지를 사용할 수 있습니다.
  - ex) 백업데이터, 로그파일, 일간/주간 보고서 저장
2. 🟨 프리미엄(Premium) 스토리지 계정
  - 프리미엄 스토리지 계정은 SSD(반도체 드라이브)에서 백업되며 일관된 짧은 대기 시간 성능을 제공합니다. 데이터베이스와 같이 I/O 집약적인 애플리케이션에서 Azure 가상 머신 디스크에 대한 프리미엄 스토리지를 사용할 수 있습니다.
  - ex) 실시간 DB, 금융거래시스템, 게임서버
🔁 주의할 점: 표준 ↔ 프리미엄 계정 전환은 불가능. 모든 스토리지 계정 유형은 미사용 데이터에 대해 SSE(스토리지 서비스 암호화)를 사용하여 암호화됩니다.

💡 Azure 스토리지 계정 종류와 각각 언제 쓰면 좋은지스토리지 계정 유형지원되는 서비스권장 사용 시나리오

표준 범용 v2	Blob Storage(Data Lake Storage 포함), Queue Storage, Table Storage, Azure Files	가장 일반적이고 추천되는 기본 계정 유형. 대부분의 기본적인 저장소 시나리오에 적합. 일반적인 이미지, 로그, 웹 앱 파일, 큐 메시지 등에 사용
프리미엄 블록 Blob	Blob Storage(Data Lake Storage 포함)	트랜잭션 속도가 높은 애플리케이션에 권장됩니다. 더 작은 개체로 작업하거나 지속적으로 낮은 스토리지 대기 시간이 필요한 경우 프리미엄 블록 Blob을 사용합니다. 이 스토리지는 애플리케이션에서 스케일링하도록 설계되었습니다.
프리미엄 파일 공유	Azure Files (파일 공유)	엔터프라이즈 또는 고성능 규모의 애플리케이션에 추천됩니다. SMB(서버 메시지 블록) 및 NFS 파일 공유를 모두 지원해야 하는 경우 프리미엄 파일 공유를 사용합니다.
프리미엄 페이지 Blob	Page Blob만 해당	페이지 Blob은 가상 머신 및 데이터베이스에 대한 운영 체제 및 데이터 디스크와 같은 인덱스 기반 데이터와 스파스 데이터 구조를 저장하는 데 적합합니다.

🛡️ 3. replication-strategies (복제 전략 결정)

데이터를 안전하게 지키기 위해 여러 곳에 복사해서 저장하는 방법이에요. 이렇게 하면 갑자기 문제가 생겨도 데이터가 사라지지 않아요
Azure Storage 계정 데이터는 항상 복제되어 내구성 및 고가용성을 보장합니다. 일시적인 하드웨어 오류, 네트워크 또는 정전, 대규모 자연 재해 등이 포함될 수 있습니다. 동일한 데이터 센터, 동일한 지역 내의 영역 데이터 센터 또는 전체 지역에 데이터를 복제하도록 선택할 수 있습니다. 복제를 사용하면 스토리지 계정은 오류 상황에서도 Azure Storage용 SLA(서비스 수준 계약)를 충족하게 됩니다.3-1) 로컬 중복 저장소 (LRS) 🏠3-2) 영역 중복 저장소 (ZRS) 🌐3-3) 지리적 중복 저장소 (GRS) 🌍3-4) 지리적 영역 중복 저장소 (GZRS) 🚀
- 2번(ZRS, 영역 중복 스토리지의 고가용성)과 3번(GRS, 지역 중복 스토리지에서 제공하는 지역 가동 중단에 대한 보호 기능)을 결합한 완전 안전한 방식! - 주 지역에 있는 3개의 Azure 가용성 영역에 복사되며 지역 재해로부터 보호하기 위해 보조 지리적 지역에도 복제됩니다. 각 Azure 지역은 동일한 지리적 위치 내의 다른 지역과 쌍을 이루어 함께 지역 쌍을 만듭니다. (지역 내 여러 데이터 센터와 멀리 떨어진 보조 지역 모두에 저장해요.) 지역 재해나 데이터 센터 장애, 가용성 영역을 사용할 수 없거나 복구할 수 없는 경우에도 데이터를 계속해서 읽고 쓸 수 있습니다. GZRS는 해당 연도 동안 개체에 99.99999999999999%(16개의 9) 이상의 내구성을 제공하도록 설계되었습니다. - 성능도 엄청 좋아서 중요한 데이터에 딱이에요. - 보조 지역 읽기 가능 옵션(RA-GZRS)도 있답니다. - Microsoft는 재해 복구를 위해 최대 일관성, 내구성, 고가용성, 뛰어난 성능, 복원력이 필요한 애플리케이션에 GZRS를 사용하는 것을 권장합니다. 지역 재해가 발생한 경우 보조 지역에 대한 읽기 액세스를 위해 RA-GZRS를 사용하도록 설정합니다.
- 데이터 원본의 기본 위치에서 수백 마일 떨어진 보조 지역에 데이터를 복제합니다. 큰 재해가 와도 데이터가 살아남아요! 데이터 내구성이 아주 높아요. 최소 99.99999999999999%(숫자 9가 16개) 내구성을 제공하도록 설계되었습니다. - 보조 지역에서 읽기만 가능한 옵션(RA-GRS)도 있어요. RA-GRS란? 읽기 액세스 지역 중복 스토리지를 말합니다. RA-GRS를 사용하면 Microsoft에서 주 지역에서 보조 지역으로 장애 조치를 시작하는지 여부에 관계없이 보조 지역에서 읽을 수 있습니다. - 보조 지역의 데이터는 LRS를 사용합니다. 주 지역과 보조 지역은 스토리지 배율 단위 내 개별 장애 도메인과 업그레이드 도메인의 복제본을 관리합니다. 스토리지 배율 단위는 데이터 센터 내의 기본 복제 단위입니다. 이 수준의 복제는 LRS에서 제공합니다.
- 같은 지역 내 떨어진 3곳 데이터 센터에 데이터를 복제하여 한 곳이 문제 생겨도 다른 곳에서 데이터 이용 가능합니다. 아직 모든 지역에서 지원하지는 않습니다. - 각 가용성 영역과 그 안에 포함된 ZRS 클러스터는 자율적으로 사용되며, 별도의 유틸리티와 네트워킹 기능을 갖추고 있습니다. ZRS 계정에 데이터를 저장하면 영역을 사용할 수 없는 경우 데이터에 액세스하여 관리할 수 있습니다. - 뛰어난 성능과 짧은 대기 시간을 제공해 빠른 응답 속도 필요할 때 딱이에요. ⚡ - 다른 데이터 복제 옵션에서 ZRS로 변경하려면 단일 스토리지 스탬프에서 지역 내의 여러 스탬프로의 물리적 데이터 이동이 필요합니다.
- 가장 저렴한 복제본 옵션이며 다른 스토리지보다 내구성이 낮습니다. 화재 또는 홍수와 같은 데이터 센터 수준 재해가 발생하면 모든 복제본이 손실되거나 복구할 수 없을 수 있습니다. - 같은 데이터 센터 안에서만 데이터를 3번 복사해요. - 제한 사항에도 불구하고 LRS는 다음과 같은 여러 시나리오에서 적합할 수 있습니다. - 애플리케이션에서 데이터 손실이 발생하는 경우 쉽게 다시 구성할 수 있는 데이터를 저장하는 경우 - 데이터는 라이브 피드처럼 지속적으로 변경되는 경우

복제 전략데이터 센터 내 노드 다운 시전체 데이터 센터 다운 시지역 전체 중단 시지역 전체 중단 시 원격 지역 읽기 가능 여부지원되는 스토리지 계정 유형

LRS	❌ (접근 불가)	❌ (접근 불가)	❌ (접근 불가)	❌	LRS
ZRS	✅ (접근 가능)	❌ (접근 불가)	❌ (접근 불가)	❌	ZRS
GRS	✅ (접근 가능)	✅ (접근 가능, 보조 지역)	✅ (접근 가능, 보조 지역)	❌ (보조 지역은 읽기 전용)	GRS
RA-GRS	✅ (접근 가능)	✅ (접근 가능, 보조 지역)	✅ (접근 가능, 보조 지역)	✅ (보조 지역에서 읽기 가능)	RA-GRS
GZRS	✅ (접근 가능)	✅ (접근 가능, 보조 지역)	✅ (접근 가능, 보조 지역)	❌ (보조 지역은 읽기 전용)	GZRS
RA-GZRS	✅ (접근 가능)	✅ (접근 가능, 보조 지역)	✅ (접근 가능, 보조 지역)	✅ (보조 지역에서 읽기 가능)	RA-GZRS

4. access-storage (스토리지 액세스)

Azure 스토리지에 저장된 모든 파일이나 데이터에는 고유한 인터넷 주소(URL)가 있습니다. 이 주소를 통해 언제든지 저장된 데이터에 접근할 수 있죠.
스토리지 계정 이름은 URL 주소의 하위 도메인 부분을 형성합니다. 하위 도메인과 도메인 이름의 조합은 각 서비스와 관련되며 스토리지 계정의 엔드포인트 를 구성합니다.
- ex) 스토리지 계정 이름이 mystorageaccount인 경우 다음 표와 같이 스토리지 계정의 기본 엔드포인트가 Azure 서비스에 대해 구성됩니다. - 컨테이너 서비스 //mystorageaccount.blob.core.windows.net - 테이블 서비스 //mystorageaccount.table.core.windows.net - 큐 서비스 //mystorageaccount.queue.core.windows.net - 파일 서비스 //mystorageaccount.file.core.windows.net
사용자 지정 도메인 구성
- 기본 URL 말고, 내가 가진 도메인 이름으로도 접근할 수 있게 설정할 수 있어요. 이렇게 하려면 DNS에 CNAME 레코드를 만들어야 해요. 이게 도메인 이름을 Azure 스토리지 주소로 연결해주는 역할을 하죠.

5. secure-storage-endpoints (스토리지 앤드포인트 보호)

스토리지 계정 접근제어를 하기 위해 방화벽과 가상네트워크 설정을 사용하여 스토리지계정에 누가 접근할 수 있는지를 설정합니다. (내 스토리지 계정에 접근할 수 있는 가상 네트워크(VNet)를 직접 지정)
스토리지 계정에 대한 서비스 엔드포인트는 Azure Storage의 모든 Blob, 큐, 테이블 또는 파일 개체에 대한 기준 URL을 제공합니다. 이 기준 URL을 사용하여 지정된 리소스에 대한 주소를 구성합니다.
하나 이상의 공용 IP 범위에 대한 액세스를 허용하도록 서비스를 구성할 수 있습니다.
서브넷 및 가상 네트워크는 스토리지 계정과 동일한 Azure 지역 또는 지역 쌍에 있어야 합니다.

6. Azure Blob Storage 구현

Blob Storage는 세 가지 리소스를 사용하여 데이터를 저장하고 관리합니다. (Azure Blob Storage의 주요 세가지 구성 요소)
1. Azure Storage 계정 : 모든 데이터가 들어가는 큰 '저장소'
2. Azure Storage 계정의 컨테이너 : 스토리지 계정 안에서 데이터를 담는 '폴더'
3. 컨테이너의 Blob : 실제 저장하는 데이터 파일 (예: 이미지, 동영상, 문서)
Blob Storage를 구현할 때 필요한 설정들
1. Blob 컨테이너 옵션 : 폴더처럼 컨테이너를 어떻게 만들지 정함
2. Blob 형식 및 업로드 옵션 : 어떤 파일 형식을 어떻게 올릴지 결정
3. Blob Storage 액세스 계층 : 저장된 데이터가 자주 쓰이는지, 아니면 가끔 쓰이는지에 따라 비용과 속도 조절
4. Blob 수명 주기 규칙 : 오래된 데이터는 자동으로 삭제하거나 다른 계층으로 이동시키는 규칙
5. Blob 개체 복제 옵션 : 데이터를 여러 곳에 복사해서 안전하게 보관하는 방법

Blob Storage를 사용할 때 고려할 점들
- 웹 브라우저 업로드: 사용자가 웹에서 사진이나 문서를 바로 올릴 수 있게
- 분산 액세스: 여러 곳에서 동시에 파일을 쓸 때도 안정적
- 스트리밍: 동영상이나 음악을 끊김 없이 재생 가능
- 보관 및 복구: 중요한 데이터를 백업하거나 재해가 났을 때 복구하는 데 적합
- 애플리케이션 접근: 다른 프로그램이나 분석 툴에서 데이터를 쉽게 불러와 사용할 수 있음. 온-프레미스 또는 Azure 호스팅 서비스에서 분석하기 위해 Blob Storage에 데이터를 저장할 수 있습니다.

6-1. Blob 컨테이너 만들기

Blob 컨테이너는 lob(파일들)을 모아두는 '폴더' 같은 공간으로, 컨테이너 리소스를 사용하여 Blob 집합을 그룹화합니다. Blob은 단독으로 존재할 수 없으며 무조건 컨테이너 리소스 안에 있어야 합니다.
컨테이너 안에 Blob 개수 제한은 없고, 스토리지 계정 안에 컨테이너 개수 제한도 없습니다.
컨테이너 이름은 Azure Storage 계정 내에서 고유해야 합니다. 이름에는 소문자, 숫자 및 하이픈만 사용할 수 있습니다. 이름은 문자 또는 숫자로 시작해야 합니다.
퍼블릭 액세스 수준: 액세스 수준은 컨테이너 및 해당 Blob에 공개적으로 액세스할 수 있는지 여부를 지정합니다. 기본적으로 컨테이너 데이터는 비공개되고 계정 소유자에게만 표시됩니다. 세 가지 액세스 수준 선택 항목이 있습니다.
1. 프라이빗: (기본값) 컨테이너 및 Blob에 대한 익명 액세스를 금지합니다.
2. Blob: Blob에 대한 익명의 퍼블릭 읽기 권한만 허용합니다.
3. 컨테이너: Blob을 포함하여 전체 컨테이너에 대한 익명의 퍼블릭 읽기 및 목록 액세스를 허용합니다.

6-2. Blob 액세스 계층 할당 🔥❄️📦

Azure Blob Storage는 데이터를 저장할 때 사용 목적과 액세스 빈도에 따라 4가지 계층을 선택할 수 있습니다. 각 계층마다 비용과 성능 차이가 있어서, 데이터 사용 패턴에 맞게 골라야 합니다.
1. 핫(Hot) 계층 🔥
  - Azure Storage 계층의 개체를 자주 읽고 쓰는 시나리오에 최적화.
  - 활발하게 처리되는 데이터가 대표적인 사례입니다.
  - 자주 액세스하거나 수정하는 데이터를 저장하는 데 최적화된 온라인 계층입니다.
  - 스토리지 비용(저장비용)이 가장 높지만 액세스 비용은 가장 낮습니다.
2. 쿨(Cool) 계층 ❄️
  - 자주 액세스하지 않는 대량의 데이터를 저장하는 데 최적화. (가끔 액세스하는 데이터용)
  - 이 계층은 최소 30일 동안 쿨 계층에 남아 있는 데이터에 사용됩니다.
  - 단기 백업 및 재해 복구 데이터 세트와 오래된 미디어 콘텐츠에 사용됩니다.
  - 이 콘텐츠를 자주 볼 수는 없지만 즉시 사용할 수 있어야 합니다.
  - 저장 비용은 핫보다 낮고, 액세스할 때 비용 더 높습니다.
3. 콜드(Cold) 계층 📦
  - 자주 액세스하지 않는 대량의 데이터를 저장하는 데 최적화.
  - 최소 90일 동안 계층에 남아 있을 수 있는 데이터를 위한 것입니다. (오래된 기록, 드물게 열어보는 자료)
  - 쿨보다 저장 비용 더 저렴함, 액세스 비용은 더 비쌉니다.
4. 보관(Archive) 계층 🗃️
  - 거의 안 쓰고 오래 저장해야 하는 데이터용으로, 몇 시간의 검색 대기 시간을 허용할 수 있는 데이터에 최적화된 오프라인 계층.
  - 데이터는 최소 180일 동안 보관 계층에 남아 있어야 합니다. 그렇지 않으면 초기 삭제 요금이 부과됩니다. (법적 보관 자료, 오래된 백업 데이터)
  - 보관 계층의 데이터에는 보조 백업, 원래 원시 데이터 및 법적 필수 규정 준수 정보가 포함됩니다.
  - 데이터를 저장하는 데 사용할 수 있는 가장 비용 효율적인 옵션입니다. 저장 비용이 가장 저렴하지만, 데이터에 액세스하는 것이 비용이 많이 듭니다.

비교핫 액세스 계층쿨 액세스 계층콜드 액세스 계층보관 액세스 계층

가용도	99.9%	99%	99%	99%
가용성 (RA-GRS 읽기)	99.99%	99.9%	99.9%	99.9%
대기 시간 (첫 번째 바이트까지 시간)	밀리초	밀리초	밀리초	시간
최소 스토리지 기간	해당 없음	30일	90일	180일

6-3. Blob 수명 주기 관리 규칙 추가

모든 데이터 세트에는 고유한 수명 주기가 있습니다. 데이터 세트 초반에는 일부 데이터에 자주 액세스하지만, 시간이 지날수록 전체 데이터에 대한 액세스는 크게 줄어듭니다. 어떤 데이터는 클라우드에 유휴 상태로 보관되면서 가끔만 액세스되기도 하며, 일부는 생성 후 며칠 또는 몇 달 내에 만료되기도 합니다. 반면, 데이터 수명 주기 내내 활발히 읽고 수정되는 데이터도 존재합니다.
Azure Blob Storage는 이러한 데이터 수명 주기 관리를 지원하며, GPv2 및 Blob Storage 계정에서 규칙 기반의 풍부한 수명 주기 정책을 제공합니다. 수명 주기 정책 규칙을 사용하여 데이터를 적절한 액세스 계층으로 전환하고, 수명 주기가 끝난 데이터는 만료(삭제)할 수 있습니다.
Blob을 핫 스토리지에서 쿨, 보관 계층 등으로 전환하여 비용과 성능을 최적화할 수 있습니다.
데이터 수명 주기가 끝나면 Blob을 자동으로 삭제할 수 있습니다.
수명 주기 정책 규칙은 Azure Storage 계정 단위에서 하루에 한 번 실행됩니다.
규칙을 특정 컨테이너 또는 Blob 하위 집합에만 적용할 수 있습니다.
수명 주기 관리 정책 규칙 구성
- Azure Portal에서 여러 설정을 지정하여 Azure Storage 계정에 대한 수명 주기 관리 정책 규칙을 만듭니다. Azure Portal에서 수명 주기 관리 정책을 만들 때, 각 규칙은 If - Then 구조로 설정합니다.
  - If 절: Blob 데이터에 적용할 평가 조건(예: Blob이 마지막으로 액세스된 지 N일이 지난 경우) - if절 주요 조건 [More than (days ago)]: 평가 조건에서 사용할 기간(일)입니다.
  - Then 절: 평가 조건이 참일 때 실행할 작업(예: Blob을 쿨 계층으로 이동, 보관 계층으로 이동, 삭제 등) - Then 절을 사용하여 Blob 데이터에 대한 전환 작업을 설정합니다. 수명 주기 관리 기능은 설정에 따라 데이터를 전환합니다.

6-4. Blob 개체 복제 확인

Blob 개체 복제는 구성한 정책 규칙에 따라 원본 컨테이너의 Blob을 비동기적으로 대상 컨테이너로 복사하는 기능입니다. 복제 과정에서 다음 항목들이 원본에서 대상 컨테이너로 복사됩니다.
- Blob 콘텐츠
- Blob 메타데이터 및 속성
- Blob과 연결된 모든 데이터 버전
Blob 개체 복제에 대한 구성을 계획할 때 유의해야 할 몇 가지 고려 사항이 있습니다.
1. Blob 버전 지정 활성화 필요 : 개체 복제를 사용하려면 원본과 대상 Azure Storage 계정 모두에서 Blob 버전 지정을 반드시 활성화해야 합니다.
2. Blob 스냅샷 미지원 : 개체 복제는 Blob 스냅샷을 복제하지 않습니다. 즉, 원본 계정에서 생성한 Blob 스냅샷은 대상 계정으로 복제되지 않습니다.
3. 다양한 액세스 계층 지원 : 원본 및 대상 계정이 핫, 쿨, 콜드 계층 중 어느 곳에 있든 개체 복제가 가능합니다. 원본과 대상이 서로 다른 계층일 수도 있습니다.
4. 복제 정책 구성 : 개체 복제를 설정하려면 원본 및 대상 스토리지 계정을 지정하는 복제 정책을 만들어야 합니다. 이 정책에는 원본 컨테이너와 대상 컨테이너를 지정하는 하나 이상의 규칙이 포함되어, 어떤 Blob을 복제할지 정의합니다.
Blob 개체 복제를 사용하면 많은 이점이 있습니다. 다음 시나리오를 고려하고 복제가 어떻게 Blob Storage 전략의 일부가 될 수 있는지 고려하세요.
1. 대기 시간 단축 : 지리적으로 가까운 지역에 데이터를 복제하여 클라이언트의 읽기 요청 대기 시간을 줄일 수 있습니다.
2. 컴퓨팅 워크로드 효율성 개선 : 동일한 Blob 데이터를 여러 지역에서 처리 가능해져 컴퓨팅 워크로드의 병렬성과 효율성을 높일 수 있습니다.
3. 데이터 배포 최적화 : 데이터 분산을 위해 구성을 최적화합니다. 특정 지역에서 데이터를 처리하거나 분석한 후, 필요한 결과만 다른 지역으로 복제하는 등 데이터 분산 전략을 최적화할 수 있습니다
4. 비용 절감 방안 : 구성을 관리하고 스토리지 정책을 최적화합니다. 복제된 데이터에 대해 수명 주기 관리 정책을 적용해 오래된 데이터를 보관 계층으로 전환함으로써 스토리지 비용을 절감할 수 있습니다.

6-5. Blob 업로드

Blob은 어떤 유형의 데이터든, 크기가 큰 파일도 저장할 수 있습니다.
Azure Storage에서는 크게 세 가지 유형의 Blob을 제공합니다:
1. 블록 Blob(Block Blob)
  - 블록 Blob은 여러 데이터 블록이 조합되어 하나의 Blob을 구성합니다. 대부분의 Blob Storage 사용 사례에서 가장 많이 사용하는 유형이며, 텍스트 파일, 이미지, 비디오 등 다양한 바이너리 데이터를 저장하는 데 적합합니다. 새 Blob을 만들 때 별도로 지정하지 않으면 기본적으로 블록 Blob으로 생성됩니다.
2. 추가 Blob (Append Blob)
  - 추가 Blob 역시 데이터 블록으로 구성되지만, 데이터를 이어서 계속 추가하는 데 최적화되어 있습니다. 특히 로그 파일과 같이 데이터가 지속적으로 누적되는 시나리오에 적합합니다.
3. 페이지 Blob (Page Blob)
  - 페이지 Blob은 최대 8TB 크기까지 지원하며, 읽기/쓰기 작업이 빈번한 데이터에 효율적입니다. Azure Virtual Machines에서 운영 체제 디스크나 데이터 디스크 용도로 주로 사용됩니다.
Blob을 만든 후에는 형식을 변경할 수 없습니다.
Blob 업로드 도구를 사용할 때 고려해야 할 사항
- Azure Storage 계정에 Blob을 업로드하는 방법은 다양합니다. 주요 도구들을 살펴보고 요구 사항에 맞는 방법을 선택하세요.
  1. AZCopy : 사용하기 쉬운, Windows 및 Linux에서 사용 가능한 명령줄 도구로, Blob Storage 내, 컨테이너 전반, 그리고 스토리지 계정 전반에 걸쳐 데이터 복사 및 관리가 쉽습니다.
  2. Azure Data Box Disk : 네트워크 제약으로 대용량 데이터를 직접 업로드하기 어려운 경우, 온-프레미스 데이터를 Microsoft에서 제공하는 SSD 디스크를 이용해 데이터를 복사 후 전송하는 서비스입니다.
  3. Azure Import/Export : 사용자가 직접 제공한 하드 드라이브를 통해 대용량 데이터를 Azure Storage로 전송하는 서비스입니다.
Blob 버전 관리 : Blob 버전 관리 기능을 활성화하면 Blob의 이전 버전을 자동으로 저장하여 관리할 수 있습니다. 이 기능을 사용하면 데이터가 수정되거나 삭제된 경우에도 이전 버전으로 복구할 수 있어 데이터 보호에 도움이 됩니다.

6-6. Blob Storage 가격 책정

Azure Storage 계정은 Blob Storage 계층별로 가격이 책정됩니다. 블록 Blob Storage 비용은 다음 요소들에 의해 결정됩니다.
- 저장된 데이터의 양 (매월 기준)
- 수행된 작업의 종류와 횟수 + 데이터 전송 비용
- 선택한 데이터 중복성 옵션
Azure Storage 계정 및 Blob Storage에 대한 다음 청구 고려 사항을 검토합니다.
- 성능 계층 : Blob Storage 계층은 저장된 데이터의 양과 데이터를 저장하는 데 드는 비용을 결정합니다.
- 데이터 액세스 비용 : 계층이 차가워질수록 데이터 액세스 요금이 증가합니다. 쿨 및 보관 계층에 있는 데이터의 경우 읽기에 대해 기가바이트당 데이터 액세스 요금이 부과됩니다.
- 트랜잭션 비용 : 모든 계층에는 트랜잭션당 요금이 있습니다. 쿨 및 보관 계층은 트랜잭션 비용이 핫 계층보다 더 높습니다.
- 지역 간 복제 데이터 전송 비용 : GRS(Geo-Redundant Storage)나 RA-GRS(읽기 액세스 지역 중복 저장)를 사용하는 계정의 경우, 지역 간 복제되는 데이터에 대해 기가바이트당 요금이 부과됩니다.
- 아웃바운드 데이터 전송 비용 : Azure에서 외부로 나가는 데이터 전송(대역폭 사용)에도 기가바이트당 요금이 발생합니다. 이는 범용 Azure Storage 계정에 공통적으로 적용됩니다.
- 저장소 계층 변경에 따른 비용 : 쿨 → 핫 계층으로 변경할 때는, 모든 기존 데이터를 ‘읽는’ 작업이 발생하는 것과 같은 요금이 부과됩니다. 핫 → 쿨 계층으로 변경할 때는, 모든 데이터를 쿨 계층에 ‘쓰는’ 것과 같은 요금이 부과됩니다. (GPv2 계정에 한함)

6-7. 대화형 랩 시뮬레이션 (simulation-blobs)

조직에서 기존 스토리지를 Azure 스토리지로 마이그레이션하고 있는 중, Azure 관리자로서 해야 할 작업:
- 스토리지 계정 구성
- 이미지 업로드 및 관리
- 스토리지 계정 모니터링 및 문제 해결
작업내용
- 작업 1: 스토리지 계정 만들기
  - 로컬 중복 스토리지(Local Redundant Storage, LRS)를 사용하여 지역에 스토리지 계정을 만듭니다.
  - 생성 후 스토리지 계정 정상 생성 여부 확인 (포털, CLI, PowerShell 등)
- 작업 2: Blob Storage 사용하기
  - 개인 Blob 컨테이너 생성 : 컨테이너의 접근 수준을 ‘Private’으로 설정 (권한이 있는 사용자만 접근 가능)
  - 컨테이너에 파일 업로드 : 이미지 파일 등 원하는 데이터 업로드
- 작업 3: 스토리지 컨테이너 모니터링
  - 일반적인 스토리지 문제 및 문제 해결 가이드를 검토합니다.
  - 성능, 가용성 및 용량에 대한 인사이트를 검토합니다.

🔐 7. Azure Storage 보안 구성

Azure Storage는 저장된 데이터를 보호하기 위해 여러 보안 계층을 제공합니다. 자격 증명, 파일 권한, 프라이빗 서명을 사용한 암호화, 인증, 권한 부여, 사용자 액세스 제어가 포함됩니다. Azure Storage는 데이터를 보호하는 데 도움이 되는 일반적인 전략을 기반으로 하는 보안 기능 제품군을 제공합니다.

✅ 휴지 상태의 암호화 (데이터 저장 시 암호화)
- Azure는 256비트 AES 암호화를 사용하는 SSE(스토리지 서비스 암호화)로 Azure Storage에 저장되는 모든 데이터를 자동으로 암호화해요.
- SSE(스토리지 서비스 암호화) 덕분에 사용자는 신경 안 써도 되고, 추가 요금이나 성능 저하도 없음.
- 디스크 암호화가 필요한 경우, Windows는 BitLocker, Linux는 dm-crypt를 사용해서 VHD를 암호화해요.
✅ 전송 중 암호화 (데이터 이동 중 보호)
- Azure와 클라이언트 간에 전송 수준 보안을 사용하도록 설정하여 데이터를 안전하게 유지합니다.
- 데이터를 주고받을 때는 HTTPS를 항상 사용해서 도청 방지. 보안 전송을 사용하도록 설정되면 HTTP를 사용하는 연결이 거부됩니다. HTTP로 전송되면 쉽게 탈취당할 수 있어요. 반드시 HTTPS로 전송해야 합니다.
- REST API를 호출하여 스토리지 계정의 개체에 액세스하는 경우 스토리지 계정에 대한 보안 전송 을 요구하여 HTTPS 사용을 적용할 수 있습니다.
- 모든 파일을 공유할 때는 SMB 3.0을 요구하여 SMB를 통한 전송 보안을 적용합니다
✅ 암호화 모델 지원
- Azure 관리 키 사용 : Azure는 서비스 관리 키를 사용하는 서버 쪽 암호화. 가장기본.
- 고객이 Key Vault에서 직접 키 관리
- 고객 하드웨어에서 직접 키 관리
- 원하는 경우, 클라이언트 쪽 암호화를 통해 직접 본인이 키를 보관하여 온-프레미스 또는 다른 안전한 위치에서 키를 관리하고 저장할 수 있습니다.
✅ 요청 권한 부여
- 가장 안전한 방식은 Microsoft Entra ID + 관리 ID를 함께 사용하는 것. 이 방식은 공유 키보다 더 안전하고 편리해요.
✅ RBAC (역할 기반 액세스 제어)
- 특정 사용자/앱에만 필요한 권한을 부여해서 불필요한 접근을 차단 : 스토리지 계정의 리소스가 원하는 경우에만 액세스할 수 있도록 하고 액세스 권한을 부여한 사용자 또는 애플리케이션에만 액세스할 수 있도록 합니다.
- 스토리지 리소스에 역할을 정확히 지정하면 보안이 강화돼요.
✅ 스토리지 분석
- Azure Storage Analytics는 스토리지 계정에 대한 로깅을 수행하여 모든 요청을 로그로 저장합니다. 이를 통해 이용 현황 분석, 문제 진단 등을 할 수 있어요.

7-1. Azure Storage에 대한 요청에 권한을 부여 전략

Microsoft Entra ID : Microsoft의 클라우드 기반 ID 관리 서비스로, RBAC(역할 기반 액세스 제어)를 사용해 사용자, 그룹, 앱에게 세분화된 액세스 권한을 할당할 수 있음. 보안수준 매우 높음.
공유키(Shared key) : Azure Storage 계정의 액세스 키를 사용해 요청을 인증. 요청에 암호화된 서명 문자열을 포함시켜 보내요. 강력하긴 하지만, 키가 노출되면 전체 계정에 접근 가능하므로 주의가 필요해요.
공유 액세스 서명 (SAS: Shared Access Signature) : 특정 자원에 한정된 권한을 주고, 정해진 시간 동안만 유효하게 만들어서 외부에 공유할 수 있어요. ex) 1시간만 파일다운로드가능
익명 액세스 (Public Access) : 공용 컨테이너나 Blob에 대해 익명 읽기 허용. 누구나 권한 없이 접근 가능하기 때문에 보안상 주의 필요. ex) 공개용 이미지, 공개 문서 배포

7-2. create-shared-access-signatures (공유 액세스 서명 만들기)

SAS (Shared Access Signature)는 Azure Storage 리소스에 제한된 시간과 권한으로 접근할 수 있게 해주는 보안 링크(URL)입니다.
계정 키를 노출하지 않고도 특정 사용자나 앱에게 한정된 리소스에, 정해진 시간 동안만 접근을 허용할 수 있어요. 접근시간을 짧게 유효하도록 설정하여 SAS가 유출되더라도 피해를 최소화할 수 있어요.
일반적으로 사용자가 스토리지 계정에서 자신의 데이터를 읽고 쓰는 서비스에 SAS를 사용합니다.
권장사항
- 클라이언트가 SAS를 자동 갱신 : SAS 만료 전에 클라이언트가 자동으로 미리 갱신하게 하세요. 장애 발생 시 대처할 시간이 생깁니다.
- 시작 시간 주의 : SAS 시작 시간을 지금(now)으로 설정하면 시간 오차(Clock Skew) 때문에 처음에 오류가 날 수 있어요. 일반적으로 15분 전으로 설정하거나 아예 생략하는 게 안전합니다.
- 최소 권한 부여 : 사용자가 꼭 필요한 권한만 주어야 합니다. 예: 읽기만 필요하면 쓰기, 삭제 권한은 부여하지 않기
- 작성된 데이터 유효성 검사 : SAS로 들어오는 데이터가 항상 신뢰된 건 아니에요. 서버 측에서 유효성 검사를 꼭 하세요.
- SAS가 항상 정답은 아님 : 어떤 상황에서는 SAS보다 중간 서버나 공개 설정이 더 낫습니다. 필요에 따라 다른 방법도 고려하세요.

SAS 종류설명사용 예시

사용자 위임 SAS	Microsoft Entra 자격 증명을 기반으로 함 Blob Storage 및 Data Lake Storage에 대해 지원	로그인된 사용자에게 임시 권한 부여.
계정 수준 SAS	스토리지 계정 전체의 다양한 리소스에 액세스 허용 계정 수준 SAS를 사용하여 파일 시스템을 만들 수 있습니다	컨테이너 생성, 큐 생성 등
서비스 수준 SAS	특정 리소스에 한정된 액세스 제공 파일 시스템의 파일 목록을 검색하거나 파일을 다운로드할 수 있도록 허용	Blob 다운로드, 파일 업로드 등
저장된 액세스 정책	SAS를 그룹화하고 더 정밀하게 제어 가능 SAS 권한을 쉽게 관리하거나 취소할 수 있어요. 계정 키를 변경하지 않아도 되니 훨씬 안전합니다.	SAS 만료 시간/권한을 서버 측에서 관리.

7-3. ✅ SAS URI 구조 이해하기

SAS(Shared Access Signature, 공유액세스서명)는 Azure Storage 리소스에 대해 제한된 시간 동안 제한된 권한을 부여할 수 있도록 해주는 서명입니다.
SAS(공유 액세스 서명)를 만들 때 매개 변수 및 토큰을 사용하여 URI(Uniform Resource Identifier)를 만듭니다. URI는 Azure Storage 리소스 URI 및 SAS 토큰으로 구성됩니다.
- <리소스 URI>?<SAS 매개변수들>
- 예제: https://myaccount.blob.core.windows.net/
  ?restype=service
  &comp=properties
  &sv=2015-04-05
  &ss=bf
  &st=2015-04-29T22:18:26Z
  &se=2015-04-30T02:23:26Z
  &sr=b
  &sp=rw
  &sip=168.1.5.60-168.1.5.70
  &spr=https
  &sig=F%6GRVAZ5Cdj2Pw4...

매개변수예시설명

리소스 URI	https://myaccount.blob.core.windows.net/?restype=service&comp=properties	Azure Storage 엔드포인트 및 기타 매개 변수를 정의합니다. 이 예제에서는 Blob Storage에 대한 엔드포인트를 정의하고 SAS가 서비스 수준 작업에 적용된다는 것을 나타냅니다. GETURI를 사용하면 Storage 속성이 검색됩니다. SETURI를 사용하면 스토리지 속성이 구성됩니다.
스토리지 버전	sv=2015-04-05	Azure Storage 버전을 나타냅니다. 스토리지 서비스 버전: SAS 토큰을 처리하는 데 사용하는 API 버전
스토리지 서비스	ss=bf	SAS가 적용되는 Azure Storage를 지정합니다. 스토리지 서비스 유형: b = Blob, f = File, q = Queue, t = Table
시작 시간	st=2015-04-29T22%3A18%3A26Z	(선택 사항) SAS의 시작 시간을 UTC 시간으로 지정합니다. SAS의 유효 시작 시각. 생략 시 즉시 유효
만료 시간	se=2015-04-30T02%3A23%3A26Z	SAS의 만료 시간을 UTC 시간으로 지정합니다. SAS의 유효 종료 시각.
자원	sr=b	srt 또는 sr. SAS를 통해 액세스할 수 있는 리소스를 지정합니다. 리소스 유형: b는 Blob, c는 컨테이너 등
권한	sp=rw	부여할 권한을 나열합니다. 권한: r = 읽기, w = 쓰기, d = 삭제, l = 목록 등
IP 범위	sip=168.1.5.60-168.1.5.70	허용 IP 범위: 이 IP 범위의 요청만 허용
프로토콜	spr=https	허용 프로토콜: https 또는 https,http 가능. 보안상 https만 권장
서명	sig=F%6GRVAZ5Cdj2Pw4tgU7IlSTkWgn7bUkkAg8P6HESXwmf%4B	Hash-Based HMAC(메시지 인증 코드) 서명을 사용하여 리소스에 대한 액세스를 인증하도록 지정합니다. 서명은 SHA256 알고리즘을 사용하여 키로 계산되고 Base64 인코딩을 사용하여 인코딩됩니다.
리소스의 종류 지정	restype=service	리소스의 종류 지정. 예: 서비스 수준 작업 대상
작업의 세부 컴포넌트	comp=properties	작업의 세부 컴포넌트. 예: 속성 조회

7-4. Azure Storage encryption (Azure Storage 암호화 확인)

Azure Storage는 미사용 데이터(At-Rest)를 자동으로 암호화하여 보안 및 규정 준수 요구사항을 충족합니다. 애플리케이션이나 코드 수정 없이도 데이터는 안전하게 보호됩니다.
스토리지 계정을 만들면 Azure는 해당 계정에 대해 2개의 512비트 스토리지 계정 액세스 키를 만듭니다. 이러한 키는 공유 키 권한 부여를 통하거나 또는 공유 키로 서명된 SAS 토큰을 통해 스토리지 계정의 데이터에 대한 액세스 권한을 부여할 수 있습니다.
Azure Key Vault를 사용하여 액세스 키를 관리하고, 키를 정기적으로 회전하고 다시 생성할 것을 권장합니다. Azure Key Vault를 사용하면 애플리케이션을 중단하지 않고 쉽게 키를 회전할 수 있습니다. 키를 수동으로 회전할 수도 있습니다.
Azure Storage 암호화의 특성
- 자동 암호화 : 데이터가 Azure Storage에 저장되기 전에 자동으로 AES 256비트로 암호화됩니다.
- 자동 암호 해독 : 데이터에 액세스하면 자동으로 복호화되며, 사용자나 앱은 이를 인식할 필요가 없습니다.
- 사용자 개입 불필요 : 암호화/복호화는 백그라운드에서 자동 처리됩니다.
- 모든 계정에 적용 : 새로 만들거나 기존의 모든 스토리지 계정에 암호화가 기본 활성화되어 있으며 비활성화 불가입니다.
- Azure Storage에 기록된 모든 데이터는 256비트 AES(고급 암호화 표준) 암호화를 통해 암호화됩니다. AES는 가장 강력한 블록 암호 중 하나입니다.
Azure Storage 암호화 구성
- Azure Storage에서는 암호화 유형을 선택하여 데이터를 보호할 수 있으며, 기본적으로 Microsoft 관리 키(PMK)를 사용하지만, 고객 관리 키(CMK)로 전환도 가능합니다.
  1. 인프라 암호화 : 전체 스토리지 계정 또는 계정 내의 암호화 범위에 대해 사용하도록 설정할 수 있습니다. 데이터는 두 가지 암호화 알고리즘과 두 가지 키를 사용하여 서비스 수준에서 한 번, 인프라 수준에서 한 번씩 두 번 이중암호화됩니다. 고도 보안이 요구되는 환경에서 사용 권장.
  2. 플랫폼 관리형 키(PMK) : Azure에서 완전히 생성, 저장 및 관리되는 암호화 키로, Microsoft가 키를 소유하고 관리합니다. 고객은 PMK와 상호 작용하지 않습니다. Azure 미사용 데이터 암호화에 사용되는 키는 기본적으로 PMK입니다. 일반적인 보안 수준에 적합.
  3. 고객 관리형 키(CMK) : 한 명 이상의 고객이 읽고, 만들고, 삭제하고, 업데이트하고, 관리하는 키. 고객 소유 키 자격 증명 모음(Key Vault) 또는 HSM(하드웨어 보안 모듈)에 저장된 키는 CMK입니다. BYOK(Bring Your Own Key)는 고객이 외부 스토리지 위치에서 키를 가져오는 CMK 시나리오입니다. 높은 보안/규정 준수 요구 시 적합
    - 유연성과 제어가 향상됩니다.
    - 암호화 키에 대한 액세스 제어를 만들고, 사용하지 않도록 설정하고, 감사하고, 회전하고, 정의할 수 있습니다.
    - Azure Storage 암호화와 함께 사용할 수 있습니다. Azure 스토리지 계정 및 키 자격 증명 모음은 동일한 지역에 있어야 하지만 서로 다른 구독에 있을 수도 있습니다.

7-5. Azure Storage 보안 모범 사례 적용

Azure Storage의 보안을 강화하고 안정성을 확보하기 위해 Storage Insights와 Azure 보안 기능을 적극적으로 활용해야 합니다. Storage 인사이트는 Azure Storage 계정에 대한 포괄적인 모니터링을 제공합니다. Storage Insights는 Azure Storage 서비스 성능, 용량 및 가용성에 대한 통합 보기를 제공합니다.
Storage 인사이트의 이점
1. 자세한 메트릭 및 로그: 스토리지 작업에 대한 가시성을 향상시키는 자세한 메트릭, 로그 및 진단 정보를 제공. 대기 시간, 처리량, 용량 사용률 및 트랜잭션과 같은 KPI(핵심 성과 지표)를 모니터링하는 데 도움이 됩니다.
2. 향상된 보안 및 규정 준수: 보안 문제를 신속하게 식별하고 해결하는 데 도움이 되는 실행 가능한 인사이트 및 경고를 제공합니다.
3. Role-Based RBAC(Access Control): RBAC(역할 기반 액세스 제어), Microsoft Entra ID, 연결 문자열 및 ACL(액세스 제어 목록) 권한을 비롯한 Azure의 보안 기능과 통합됩니다.
4. 통합 보기: 스토리지 계정의 보안 및 효율성을 유지하는 데 중요한 Azure Storage 서비스의 성능, 용량 및 가용성에 대한 통합 보기를 제공합니다.
🛡️ Storage Insights를 활용한 보안 강화
1. Real-Time 모니터링: Azure Storage Insights를 사용하면 스토리지 계정을 실시간으로 모니터링할 수 있으므로 사용 추세를 추적하고, 성능을 모니터링하고, 변칙에 대한 경고를 설정할 수 있습니다.
2. 보안 감사: 규정 준수를 보장하고 보안 문제를 식별하는 데 필수적인 포괄적인 모니터링 및 자세한 로그를 제공하여 보안 감사를 지원합니다.
3. 상태 분석 및 최적화 : 스토리지 계정의 상태 분석 및 최적화를 지원하여 보안 및 최적의 성능을 보장합니다.

8. Azure Files 구성

Azure Files는 Microsoft Azure에서 제공하는 완전 관리형 파일 공유 서비스(PaaS)입니다 SMB(서버 메시지 블록), NFS(네트워크 파일 시스템) 및 HTTP 프로토콜을 사용하여 Windows, Linux, macOS에서 접근 가능하며 Azure 파일 공유에 액세스할 수 있습니다. 클라이언트는 Windows, Linux 및 macOS 디바이스에서 Azure 파일 공유에 연결할 수 있습니다. 기존 파일 서버처럼 사용 가능합니다.
Azure Files의 특성
1. 서버리스 배포 : VM, OS, 패치 불필요. 인프라 관리 없이 사용 가능. 인프라를 필요로 하지 않는 완전 관리형 파일 공유의 PaaS.
2. 대용량 저장소 : 거의 무제한 스토리지. 단일 Azure 파일 공유는 최대 100TiB(테비바이트) 파일 저장가능. 단일파일 크기는 최대 4TiB. 파일은 계층 구조의 폴더 구조로 구성됩니다.
3. 데이터 암호화 : 저장 시, 전송 중 모두 암호화 적용.
4. 광범위 액세스 : 어디서나 액세스. 인터넷만 연결되면 어디서든 접근 가능
5. ID 기반 액세스 제어 : Microsoft Entra ID 또는 AD DS와 연동하여 Azure 파일 공유에 대한 액세스를 제어할 수 있습니다. 온-프레미스 파일 서버에 액세스할 때와 동일한 방식으로 Azure 파일 공유에 액세스할 수 있습니다.
6. 이전 버전 / 백업 지원 : 파일 탐색기에서 이전 버전 기능과 통합되는 Azure 파일 공유 스냅샷을 만들 수 있습니다. 또한 Azure Backup을 사용하여 Azure 파일 공유를 백업할 수 있습니다.
7. 데이터 중복성 : Azure 파일 공유 데이터는 동일한 Azure 데이터 센터 또는 여러 Azure 데이터 센터의 여러 위치에 복제됩니다. 파일 공유를 포함하는 Azure 스토리지 계정의 복제 설정이 데이터 중복성을 제어합니다. 동기화/복제를 통한 고가용성 보장.

📊 8-1. Azure Files(파일공유) Vs. Azure Blob Storage(Blob) 비교

항목Azure FilesAzure Blob Storage

설명	어디서든 저장된 파일에 액세스하는 데 사용할 수 있는 SMB 및 NFS 프로토콜, 클라이언트 라이브러리 및 REST 인터페이스를 제공합니다.	비정형 데이터를 블록 Blob에서 대규모로 저장 및 액세스하는 데 사용할 수 있는 클라이언트 라이브러리 및 REST 인터페이스를 제공합니다.
액세스 방식	SMB, NFS, REST API, 클라이언트 라이브러리	REST API, 클라이언트 라이브러리
파일 구조	실제 디렉터리 기반 (계층형) 실제 디렉터리 개체	단일 구조의 네임스페이스 (가상 디렉터리)
공유 액세스	여러 VM 또는 사용자 간 파일 공유에 적합	컨테이너 단위의 객체 저장소
운영체제 통합	Windows, Linux, macOS에서 네트워크 드라이브처럼 마운트 가능	일반적으로 애플리케이션을 통해 직접 접근
리프트 앤 시프트	기존 파일 기반 앱을 클라우드로 그대로 이전하기 적합	새로운 클라우드 앱의 비정형 데이터 저장소로 적합
사용 사례	구성 파일, 개발 도구, 진단 로그, 공유 설정 저장	이미지, 비디오, 로그, 백업 파일 등 대용량 비정형 데이터
접근성	SMB 또는 NFS로 탐색기 수준 접근 가능	HTTP(S)로 프로그램 수준 접근
성능 특화	파일 읽기/쓰기, 공유 시나리오 중심	스트리밍, 대규모 업로드/다운로드, 임의 접근에 최적화
가격 구조	파일 단위 과금	Blob 단위 과금 (Hot, Cool, Archive Tier 존재)
버전 관리 및 스냅샷	스냅샷 및 Azure Backup 지원	버전 관리, Soft delete, 복원 등 다양한 내장 기능

8-2. manage-file-shares (Azure 파일 공유 관리)

📁 Azure Files 프로토콜 지원
- Azure Files는 두 가지 표준 파일 시스템 프로토콜인 SMB(서버 메시지 블록) 프로토콜과 NFS(네트워크 파일 시스템) 프로토콜을 지원합니다. 동일한 스토리지 계정 내에서 SMB와 NFS Azure 파일 공유를 각각 따로 만들 수 있지만 Azure 파일 공유는 동일한 파일 공유에서 SMB와 NFS 프로토콜을 동시에 지원하지 않습니다.

📦 Azure 파일 공유 유형

Azure Files는 Premium과 Standard 두 가지 스토리지 계층을 제공합니다. 표준 파일 공유는 범용(GPv2) 스토리지 계정에 생성되는 반면 프리미엄 파일 공유는 FileStorage 스토리지 계정에 생성됩니다.구분프리미엄 (Premium)표준 (Standard)

스토리지 계정 유형	FileStorage 스토리지 계정 유형에만 사용가능	GPv2(범용 버전 2) 스토리지 계정 유형으로 배포됨
백엔드 디스크 유형	SSD(반도체 드라이브)에 데이터를 저장	HDD(하드 디스크 드라이브)에 데이터를 저장
성능 특성	고성능, 저지연(짧은대기시간), 일관성	일반 파일 공유 및 개발/테스트 환경과 같은 워크로드에 대한 성능을 제공(일반성능), 적당한 지연
주요 용도	높은 IOPS, 짧은 대기 시간 요구 엔터프라이즈 워크로드 DB 백업 등	일반적인 파일 공유 개발/테스트 환경 문서 저장소 등
지원 중복성 옵션	LRS (기본), 일부 지역 ZRS 지원	LRS, ZRS, GRS, GZRS 모두 지원
지원 지역	일부 지역에서는 ZRS를 사용할 수 있는 LRS 중복성이 유지됩니다. 일부 Azure 지역에서는 지원되지 않습니다.	모든 Azure 지역에서 LRS, ZRS, GRS 및 GZRS에 대한 표준 파일 공유 가능

8-3. 🔐 Azure Files 인증 형식 비교

인증 방법설명장점주의사항 / 단점

SMB를 통한 ID 기반 인증	Azure AD 또는 온-프레미스 AD를 기반으로 파일 공유에 대한 SSO(싱글 사인온) 제공	- 사용자 기반 권한 제어 가능 - 조직 정책과 연계 쉬움 - 보안성 우수	- 설정이 복잡할 수 있음 - SMB 전용 (REST API 불가)
액세스 키	스토리지 계정에 기본 제공되는 정적 키로 모든 권한 부여 오래되고 유연성이 낮은 옵션입니다. Azure 스토리지 계정에는 Azure Files를 포함하여 스토리지 계정에 대한 요청을 할 때 사용할 수 있는 두 개의 액세스 키가 있습니다. 액세스 키는 정적이며 Azure Files에 대한 모든 권한을 제공합니다.	- 간단한 설정 - 다양한 도구와 호환	- 모든 권한 부여됨 (보안상 취약) - 액세스 키 유출 시 치명적 - 권한 분리가 불가능
SAS (Shared Access Signature, 공유 액세스 서명)	스토리지 액세스 키를 기반으로 만든 동적으로 생성된 URI로, 제한된 액세스 권한을 제공. 제한에는 허용된 권한, 시작 및 만료 시간, 요청을 보낼 수 있도록 허용된 IP 주소 및 허용된 프로토콜이 포함됩니다.	- 필요한 권한만 최소 범위로 설정 가능 - 특정 시간/조건에서만 유효 - REST API에 적합	- 액세스 키 기반이므로 키 유출 시 토큰 생성 가능 - 파일 공유 마운트용으로는 사용 불가

8-4. 📌 SMB Azure 파일 공유 만들기

- SMB Azure 파일 공유를 만들고 구성할 때 알아야 하는 두 가지 중요한 설정이 있습니다.
1) 포트 445 열기
   - SMB 프로토콜은 TCP 445번 포트를 통해 통신합니다. 클라이언트 컴퓨터(또는 온프레미스) 방화벽에서도 TCP 포트 445가 열려있어야 Azure Files에 접근 가능합니다.
   - 포트 445를 차단 해제할 수 없는 경우 : 온-프레미스에서 Azure 네트워크로의 VPN 또는 ExpressRoute 연결이 필요하며, Azure Files는 프라이빗 엔드포인트를 사용합니다.
2) Secure transfer required (보안 전송 설정)
   - 스토리지 계정의 보안연결(HTTPS/SMB over TLS)만 스토리지 계정에 대한 요청을 허용하여 스토리지 계정의 보안을 향상시킵니다.
   - REST API는 반드시 HTTPS를 사용하여 연결하고, SMB 연결 시 TLS 사용이 필요합니다.
   - HTTP/비암호화 SMB 연결은 거부됨

8-5. 파일 공유 스냅샷 만들기

Azure Files는 파일 공유의 스냅샷을 공유하는 기능을 제공하는데, 파일 공유 스냅샷이란 Azure Files에서 제공하는 데이터의 읽기 전용 시점 복사본을 의미합니다.
데이터의 읽기 전용 시점 복사본은 전체 파일 공유 단위로 캡처되며, 증분 스냅샷 형태로, 가장 최근 스냅샷 이후 변경된 데이터만 저장됩니다.
Azure Files 공유 스냅샷 기능은 파일 공유 수준에서 제공됩니다.
파일 공유 스냅샷 주요 특성
1. 📦 증분 방식 : 변경된 데이터만 저장되어 스토리지 비용 절감 및 빠른 스냅샷 생성 가능
2. 📁 파일 단위 복원 가능 : 공유 전체 복원이 아닌, 개별 파일 복원이 가능
3. 🧾 파일 수준 보호 : 실수로 인한 수정, 삭제에 대비할 수 있음
4. ⚠️ 공유 삭제 시 스냅샷도 삭제됨 : 파일 공유가 삭제되면 스냅샷도 함께 삭제됨
5. 📅 정기 생성 권장 : 정기적인 스냅샷 생성을 통해 백업 및 감사, 재해 복구 목적에 활용 가능
✅ 파일 공유 스냅샷 도입 시 이점
1. 🔐 애플리케이션 오류 및 데이터 손상으로부터 보호 : 애플리케이션 배포 전에 스냅샷을 찍어 문제 발생 시 롤백 가능
2. 🗑️ 실수로 인한 삭제 또는 의도하지 않은 변경으로부터 복구 : 사용자가 실수로 삭제하거나 덮어쓴 파일을 복원 가능
3. 💾 백업 및 복구 지원 : 정기적 스냅샷 생성으로 백업 및 감사 로그, 재해 복구 용도로 활용 가능

8-6. Azure Files에 대한 일시 삭제 기능 (Soft Delete)

일시 삭제를 사용하면 삭제된 파일과 파일 공유를 복구할 수 있습니다. (실수로 삭제되거나 손상된 데이터를 복구가능)
파일 공유 수준에서 활성화되며, 일시 삭제된 상태에서 복구 가능한 기간을 설정할 수 있습니다.
보존 기간: 일시 삭제된 파일 공유는 1일에서 365일까지 보존 기간을 설정할 수 있습니다.
이 기능은 데이터 복구, 비즈니스 연속성, 랜섬웨어 보호 등 다양한 시나리오에 매우 효과적입니다.
- ex) 🔄 업그레이드 실패 후 복원 : 업그레이드 실패 후 이전 안정적인 상태로 복원 가능
- ex) 🦠 랜섬웨어 보호 : 랜섬웨어로 인한 파일 손상 후, 사이버 범죄자에게 지불 없이 데이터 복구
- ex) 📚 장기 보존 : 장기 데이터 보존을 위해 일시 삭제 사용
- ex) 🔁 비즈니스 연속성 유지 : 업무 중단 없이 고가용성 유지 가능, 빠른 복원으로 다운타임 최소화. 인프라가 중요한 워크로드에 대해 고가용성을 갖도록 준비합니다.

8-7. Azure Storage Explorer

Azure Storage Explorer는 Windows, macOS, Linux에서 실행되는 독립형 애플리케이션으로, Azure Storage 데이터를 쉽게 사용하고, 리소스를 시각적으로 관리할 수 있게 도와주는 도구입니다.
Azure Storage Explorer를 사용하여 여러 계정 및 구독에 액세스하고 모든 스토리지 콘텐츠를 관리할 수 있습니다.
주요 기능
- 여러 Azure 계정 및 구독에 대한 스토리지 리소스 관리
- 스토리지 계정, 컨테이너, Blob, 큐, 테이블 등 데이터 직접 관리 가능
- 리소스에 대한 모든 권한을 허용하려면 Azure Storage Explorer에 관리 권한(Azure Resource Manager)과 데이터 계층 권한이 모두 필요합니다. 스토리지 계정, 계정의 컨테이너, 컨테이너의 데이터에 액세스하려면 Microsoft Entra ID 권한이 필요합니다.
🔑 Azure Storage Explorer 연결 방식 및 시나리오
- ☁️ Azure 구독 연결 : 현재 사용자의 Azure 구독에 속한 스토리지 계정에 직접 연결
- 🖥️ 로컬 스토리지 연결 : Azure Storage 에뮬레이터 또는 Azurite를 통해 개발 환경에서 테스트
- 🌐 외부 스토리지 계정 연결 : 다른 구독 또는 국가별 Azure 클라우드의 스토리지 계정을 계정 이름 + 키 및 앤드포인트를 사용하여 연결
- 🔐 SAS URL로 연결 : SAS(공유 액세스 서명) 토큰을 사용하여 특정 스토리지 리소스에 제한적으로 접근
- 📦 SAS로 Blob, 큐, 테이블 직접 연결 : Blob 컨테이너, 큐, 테이블 등의 서비스에 대해 세분화된 권한 부여 가능
🧭 외부 스토리지 계정 연결 방법
- Azure Storage Explorer를 사용하면 외부 스토리지 계정에 연결하여 스토리지 계정을 쉽게 공유할 수 있습니다.
- 연결을 만들려면 외부 스토리지 계정 이름 및 계정 키가 필요합니다. 사용자 지정 스토리지 계정 엔드포인트 도메인을 입력합니다.
🔐 액세스 키
- 액세스 키는 전체 스토리지 계정에 대한 액세스를 제공합니다.
- 다른 키를 다시 생성하는 동안 키를 사용하여 연결을 유지 관리할 수 있도록 🔑 2개의 액세스 키가 제공됩니다. (Key1 / Key2를 교대로 사용해 안전하게 회전 가능)
- 🔄 키 재생성 시 주의 : 액세스 키를 다시 생성하는 경우, 새 키를 사용하도록 이 스토리지 계정에 액세스하는 모든 Azure 리소스 및 애플리케이션에 새로운 키를 반영하여 업데이트해야 합니다. 이 작업은 가상 머신의 디스크에 대한 액세스를 중단하지 않습니다.

8-8. Azure 파일 동기화

Azure 파일 동기화(Azure File Sync) 는 온-프레미스 Windows Server 또는 클라우드 가상머신에서 여러 Azure Files의 캐시 서버로 활용할 수 있게 해주는 기능입니다. 이를 통해 로컬 서버의 성능 및 프로토콜 호환성은 유지하면서도, Azure Files의 중앙 집중형 클라우드 스토리지를 활용할 수 있습니다.
주요 특징
1. ⚡ 빠른 로컬 캐시 제공 : 자주 사용하는 파일은 Windows Server에 캐시되어 빠르게 액세스 가능
2. 🔄 양방향 동기화 : 온-프레미스 ↔ Azure Files 간 읽기/쓰기 동기화 지원
3. 🌐 여러 지점에서 공유 가능 : 여러 지역/지점 서버에서 동일 Azure 파일 공유 캐시 가능
4. 🔐 기존 프로토콜 호환 : SMB / NFS / FTPS 등 Windows Server에서 지원하는 모든 프로토콜 사용 가능
5. 🧩 클라우드 계층화 지원 : 자주 사용하지 않는 파일은 Azure에 저장, 서버에는 포인터(재분석 지점)만 유지
☁️ 클라우드 계층화(Cloud Tiering)
- 클라우드 계층화는 Azure 파일 동기화의 선택적 기능으로, 자주 액세스하는 파일만 서버에서 로컬 서버로 캐시하고, 나머지는 정책 설정에 따라 Azure Files에 저장하여 스토리지 용량 최적화를 실현하는 기능입니다.
- 📂 로컬에는 포인터만 유지 : 파일이 계층화되면 Azure 파일 동기화는 로컬에서 파일을 포인터로 바꿉니다. 포인터를 재분석 지점이라고 합니다. 계층화된 파일은 로컬에서 ‘재분석 지점(포인터)’으로 대체.
- 🔄 자동 데이터 호출 : 사용자가 계층화된 파일을 열면, Azure Files에서 자동으로 파일을 불러옴. 사용자는 파일이 Azure에 저장되어 있음을 몰라도 됩니다.
- 💾 오프라인 파일 아이콘 : 클라우드 계층화 파일에는 사용자가 파일이 Azure에만 있다는 것을 사실을 알 수 있도록 하기 위해, Windows 탐색기에서 회색 "오프라인(O)" 아이콘으로 표시
Azure 파일 동기화 장점
1. 🚀 애플리케이션 리프트 앤 시프트 : Azure 파일 동기화를 사용하여 Azure와 온-프레미스 시스템 간에 액세스해야 하는 애플리케이션을 이동합니다. 기존 SMB 접근 방식을 유지하면서 Azure Files에 연결. Windows Server와 Azure Files 간에 동일한 데이터에 대해 쓰기 액세스를 제공합니다.
2. 🏢 지점(Branch Office) 지원 : Azure 파일 동기화를 사용하여 파일을 백업해야 하는 지점을 지원합니다. 각 지점 서버에 Azure File Sync 설치 → 중앙 Azure Files를 캐시하여 지점 간 파일 일관성 확보
3. 🔄 백업 및 재해 복구 : Azure Backup을 통해 온-프레미스 데이터를 백업합니다. Azure Files에 저장된 데이터를 백업 → 장애 발생 시 메타데이터 즉시 복원 가능
4. 📦 클라우드 기반 파일 보관 : 클라우드 계층화를 사용한 파일 보관을 고려합니다. 오래된 파일은 자동으로 클라우드로 계층화하여 최근에 액세스한 데이터만 로컬 서버에 저장합니다. 로컬 디스크 용량 절감 및 보관 정책 구현

문제!

문1) 관리 팀은 스토리지 계정 이름에 대한 요구 사항을 알고 있어야 합니다. 스토리지 계정 이름은 어느 정도까지 고유해야 하나요?

: 이름은 전역적으로 고유해야 합니다. ( 구독내에서 고유 X, 리소스그룹내에서 고유 X. 전역적 고유 O)

문2) 제조 부서의 요구 사항을 지원하는 최적의 스토리지 계정 솔루션은 무엇인가요?

: 로컬 중복 스토리지

문3) 회사에서 Azure Blob Storage를 사용하여 비디오 클립을 범주로 구성하려고 합니다. 클립을 그룹화하려면 어떤 리소스를 사용해야 하나요?

: 컨테이너

문4) 두 Azure Blob Storage 계정 간의 성공적인 개체 복제를 방지할 수 있는 것은 무엇인가요?

: 원본 또는 대상 계정에서 Blob 버전 관리가 사용되지 않습니다.

문5) 조직에서 Azure Blob Storage를 사용하여 클라이언트 읽기 요청에 대한 대기 시간을 줄여야 합니다. 이 목표를 달성하기 위해 어떤 구성을 적용해야 하나요?

: 클라이언트가 가까운 지역의 데이터에 액세스할 수 있도록 개체 복제를 구현합니다.

문6) 조직은 Azure Blob Storage를 사용하여 컴퓨팅 워크로드가 지역 전체에서 일관된 데이터에 액세스할 수 있도록 합니다. 이를 위해 구현해야 하는 구성은 무엇입니까?

: 여러 지역에서 동일한 Blob에 액세스할 수 있도록 개체 복제를 설정합니다.

문7) 수명 주기 관리 규칙이 예상대로 실행되지 않고 로그에 오류가 표시되지 않습니다. 문제를 진단할 수 있는 다음 단계는 무엇인가요?

: 규칙 조건을 확인하고 의도한 정책 논리와 일치하는지 확인합니다.

문8) 한 달 후에 거의 액세스하지 않는 데이터의 스토리지 비용을 줄이기 위해 사용할 수 있는 수명 주기 관리 정책 규칙은 무엇인가요?

: 보관 계층으로 데이터 이동

문9) 회사에서 Azure Blob Storage를 사용하여 여러 지역에 걸쳐 데이터 배포를 최적화하려고 합니다. 결과를 다른 지역에 복제하기 전에 한 위치에서 효율적인 데이터 처리 및 분석을 보장하기 위해 어떤 전략을 사용해야 하나요?

: 처리된 결과를 다른 지역에 복사하도록 개체 복제를 설정합니다.

문10) 두 Azure Blob Storage 계정 간에 개체 복제를 구성하려면 어떤 조건을 충족해야 합니까?

: 원본 계정과 대상 계정 모두에서 Blob 버전 관리가 사용하도록 설정되어야 합니다.

문11) 읽기 요청의 대기 시간을 최소화하는 데 도움이 되는 Azure Blob Storage 복제 기능은 무엇입니까?

: 클라이언트가 가까운 지역의 데이터를 사용할 수 있도록 설정

문12) 비용 효율성을 고려할 때 고가용성이 필요하고 여러 지리적 위치에 저장되는 비디오 클립에 대해 어떤 데이터 중복 옵션을 선택해야 하나요?

: RA-GRS(읽기 액세스 지역 중복 스토리지)

문13) 수명 주기 관리 정책을 구성한 후에는 데이터가 의도한 대로 90일 후에 핫 계층에서 보관 계층으로 전환되지 않는 것으로 확인됩니다. 이 동작의 잠재적인 이유는 무엇인가요?

: 규칙에는 데이터가 쿨 계층에 먼저 있어야 하는 것과 같이 충족되지 않는 조건이 있을 수 있습니다.

문14) 회사는 보관 계층에 있지 않는 한 1년보다 오래된 모든 데이터가 삭제되도록 해야 합니다. 어떤 수명 주기 관리 규칙을 적용해야 하나요?

: 보관 계층에 있지 않은 경우 1년보다 오래된 Blob을 삭제합니다.

문15) 회사에서 데이터 배포를 위해 지역 중복 스토리지 대신 Azure Blob Storage 개체 복제를 사용하도록 선택하는 이유는 무엇인가요?

: 필요한 데이터 결과만 특정 지역에 복제하려면 스토리지 비용을 최소화합니다.

문16) 조직에서 로컬 액세스를 유지하면서 Azure Files에서 파일 공유를 중앙 집중화하도록 Azure 파일 동기화를 설정하고 있습니다. Windows Server에서 캐시된 데이터에 로컬로 액세스하는 데 사용할 수 있는 프로토콜은 무엇입니까?

: SMB (Server Message Block)

문17) 회사에서는 지점이 최신 파일 버전에 액세스할 수 있도록 Azure 파일 동기화를 구현하려고 합니다. Azure 파일 동기화는 이 목표를 어떻게 달성하나요?

: 로컬 서버에서 Azure 파일 공유를 캐싱하여

문18) Azure Storage Explorer를 사용하여 다른 Azure 구독의 스토리지 리소스를 관리해야 합니다. 이러한 리소스에 연결하는 데 사용해야 하는 방법은 무엇입니까?

: SAS를 사용하여 스토리지 계정 연결