Azure Storage account 및 PrivateEndpoint , ServiceEndpoint 관련 정리

개인적으로 운영을 하면서 알아가는 점을 정리할려고한다.

 

Azure Storage account란?

https://learn.microsoft.com/ko-kr/azure/storage/common/storage-account-overview

Storage 계정 개요 - Azure Storage

 

처음에 Azure를 접할때는 account? 로그인 계정인가? 싶었는데

그게 아니라 AWS S3처럼 클라우드 스토리지 서비스이다.

둘은 상당히 비슷하지만 써본 결과 개인적으로 Azure Storgae Account가 관리가 쉽고 더 나은듯하다.

 

우선적으로 AWS S3에서는 Config 설정을 할려면 GUI로 클릭하는 형태도 있었지만 GUI가 제공을 안해서 JSON으로 해야하는것들이 꽤나 있었다.

예를 들면 접근 권한설정이 대표적이였다.

 

초반에 배울때 꽤나 고전했던걸로 기억한다.

 

그에 비해 Azure는 모두 GUI이고 한글화도 꽤나 잘되어있어 초보자도 쉽게 접근제어를 관리할 수 있다.

vnet의 특정 서브넷을 전체로 권한을 줄 수도 있다.

물론 KEY형태로도 접근가능하다.

 

하지만 헷갈리는게 있는데..위 링크에도 있지만 기본 종류가 다양하게 많다..

Azure Storage 플랫폼에는 다음과 같은 데이터 서비스가 포함됩니다. Azure Blob: 텍스트 및 이진 데이터에 대한 확장성이 뛰어난 개체 저장소입니다. 또한 Data Lake Storage Gen2를 통한 빅 데이터 분석 지원도 포함합니다. Azure Files: 클라우드 또는 온-프레미스 배포에 대한 관리되는 파일 공유입니다. -> EFS Azure Elastic SAN (미리 보기): Azure에서 SAN 배포, 크기 조정, 관리 및 구성을 간소화하는 완전히 통합된 솔루션입니다. Azure 큐: 애플리케이션 구성 요소 간에 안정적인 메시징을 위한 메시징 저장소입니다. -> SQS Azure 테이블: 구조화된 데이터의 스키마 없는 스토리지를 위한 NoSQL 스토리지입니다. -> simpleDB,DynamoDB Azure 디스크: Azure VM용 블록 수준 스토리지 볼륨입니다. -> 이건 디스크이다(AWS EBS랑 같다)

S3의 경우에는 사용기한 엑세스빈도관련해서만 즉 티어관련해서만 주로 조정 했는데

Azure는 Blob이니 Files니 queue이니 AWS의 SQS등 서비스 이름 부터 다르게 분화되어있는데
Azure는 일단 Storage accout라는 큰 틀에서 세분화 한것이다.

 

PrivateEndpoint , ServiceEndpoint란?

우선 엔드포인트가 뭔지 알아야한다.

간단히 말하면 통신하는 URL 주소이고 정확히 말하면 시스템간 통신을 위한 경로 끝점 이라는 뜻이다.

S3업로드 경로 Azure Storage account 업로드 경로라고 보면된다!

 

Azure Storage account는 기본적으로 서비스엔드포인트를 제공한다

스토리지 서비스엔드포인트

Blob Storage	https://<storage-account>.blob.core.windows.net
정적 웹 사이트(Blob Storage)	https://<storage-account>.web.core.windows.net
Data Lake Storage Gen2	https://<storage-account>.dfs.core.windows.net
Azure 파일	https://<storage-account>.file.core.windows.net
Queue Storage	https://<storage-account>.queue.core.windows.net
Table Storage	https://<storage-account>.table.core.windows.net

 

기본적으로 S3와 같이 공인 IP로 할당되어 공인으로 통신을 한다.

하지만 Private Link , Endpoint 라는 기능으로 Private한 네트워크로도 통신이 가능하다.

Azure는 Sotrage Account 처럼 서비스엔드포인트를 제공하는 서비스의 경우 Networking 탭에 가면
Private Endpoint cennection이 있다.

 

여기서 Private Endpoint를 만들면
Private IP를 가진 NIC를 만들고 해당 IP를 Private DNS에 해당 도메인값이 등록이 되고
해당 DNS와 NIC는 새로운 서비스 포인트로 동작하게된다.

Private DNS는 기존 서비스 엔드포인트 앞에 privatelink.가 더 붙는다
예를 들면 abcde.privatelink.blob.core.windows.net 라는 DNS 레코드가 생성되고 Private IP가 A Type으로 선언되어있다.

 

그림을 보면 아래와 같다.

인터넷 공인 IP로 접근하는게 아닌 10.0.06 이나 192.168.0.5인 Private IP로 접근할 수 있다는 것이다.

이경우 내부 통신만 사용해서 좀 더 안전하다는 장점이 있다.

 

우선 특히한게 Private Endpoint를 만드는순간 기존에 있던

abcde.blob.core.windows.net은 abcde.privatelink.blob.core.windows.net으로 alias 처리된다.

즉 privatelink를 제거해서 DNS 쿼리 요청을해도 Privatelink가 붙은 값을 조회해서 확인을 한다는 뜻이다.

 

이말은 즉 Private DNS를 아는 환경들은 무조건 Private IP로 응답이 온다는 뜻이다.

내부환경은 Private IP로 외부환경은 Public IP로 조회된다.

 

 보안적으로 안전하고 상대적으로 안정적인 트래픽 사용이 가능하지만 몇가지 단점이있다.

 

우선 확인한건 따로 비용이 부과되어서 비용 부담이 있다.

또 추가적으로 vnet에 Private DNS가 생기면 private.이 붙은 모든 도메인은 해당 DNS에서 레코드 값을 확인하게 되는데..

PrivateEnd포인트가 생기는 순간 무조건private link가 alias 된다.

그럼 Private DNS가 조회가능한 환경에서 내가 운영중이지 않은
즉 레코드값을 모르는 Private Endpoint가 있는 서비스로 쿼리 자체가 불가하게된다.
만약 Private DNS가 없었더라면 Service Endpoint로 쿼리를해서 공인 IP로 쿼리가능할텐데!

 

예)A회사에 Vnet에는 abcde를 PrivateLink로 운영하고있으면
Private DNS, privatelink.blob.core.windows.net 레코드에 abcde.privatelink.blob.core.windows.net는 있고 

B회사에서 Vnet에는 xyz.privatelink.blob.core.windows.net 운영하고있으면

 

A회사의 abcde가 있는 Vnet환경에서는
xyz.blob.core.windows.net쿼리시 외부 인터넷에서 xyz.privatelink.blob.core.windows.net으로 alias로 응답
A회사 Vnet 기준에서  privatelink.blob.core.windows.net은 Private DNS에 있는 Privatelink DNS의 레코드를 먼저 확인함

하지만 값이 없으니 IP를 돌려주지 못함

그러면 통신이 불가함

하지만 A회사에서 Private Link를 안쓰는 vnet 환경에서는
xyz.privatelink.blob.core.windows.net으로 alias로 응답 하여도
참고하는 Private DNS와 privatelink DNS가 없으니
Root 쿼리나 Azure DNS 쿼리로 가서 서비스엔드포인트로 응답함

 

보안상 문제되는게 없다면 서비스엔드포인트만 쓰는것도 좋을 듯 하다