[AWS] Storage Gateway란? 쉽게 개념 정리 (File Gateway, Tape Gateway, Volume Gateway, Cached&Stored volume)

◇  공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇

 

 

Storage Gateway

Storage Gateway: 하이브리드 클라우드 스토리지 서비스

AWS Storage Gateway는 온프레미스 환경과에서 AWS 환경의 스토리지 서비스(ex. Amazon S3)를 연동시키는 서비스이다. (주로 온프레미스의 데이터를 백업으로써 AWS 환경의 S3로 이동시킬 때 사용한다.)

 

[On-Premise ↔ AWS] : 하이브리드 클라우드 스토리지

온프레미스의 데이터를 AWS의 스토리지에 백업시켜 연동된 상태로 만들고자 할 때 Storage Gateway를 사용한다.

 

이를 통해 기업은 데이터를 안전하게 백업하여 미래에 다른 AWS 리소스를 활용할 수 있다.

 

Storage Gateway 종류

1. S3 File Gateway: On-Premise → S3 File Gateway  → S3
   • 온프레미스의 데이터를 S3에 저장하는 게이트웨이
2. FSx File Gateway: On-Premise → FSx File Gateway → FSx for Windows File Server
   • 온프레미스의 데이터를 FSx for Windows File Server에 저장하는 게이트웨이
3. Tape Gateway: On-Premise → Tape Gateway  → S3 or S3 Glacier
   • 온프레미스의 물리 tape를 대신하여 S3나 S3 Glacier로 데이터를 백업하는 게이트웨이
4. Volume Gateway: On-Premise → Volume Gateway  → S3
   • 온프레미스의 데이터를 S3에 저장하여 캐시형 또는 보관형 모드로 동작시킨다.

S3 File Gateway

FSx File Gateway

Tape Gateway

Volume Gateway

 

 

File Gateway

Amazon S3 File Gateway: S3에 저장 (SMB & NFS 지원)

Amazon S3 File Gateway

온프레미스에서 S3 File Gateway까지는 NFS 또는 SMB 프로토콜을 사용한다. (즉 Window & Linux 동시 지원한다)

그리고 HTTPS로 AWS에 연결.

S3의 여러 스토리지 클래스를 선택할 수 있다.

https://aws.amazon.com/storagegateway/file/s3/

 

Amazon FSx File Gateway: FSx에 저장 (SMB 지원)

Amazon FSx File Gateway

온프레미스에서 FSx File Gateway까지 SMB 프로토콜을 사용한다. 즉 윈도우를 지원한다.
AWS 환경까지도 SMB 프로토콜로 연결한다.

FSx File Gateway은 낮은 latency와 높은 퍼포먼스를 갖는다.

https://aws.amazon.com/storagegateway/file/fsx/

 

Tape Gateway: S3에 저장 (iSCSI 지원)

Tape Gateway

온프레미스까지 iSCSI 프로토콜로 연결하고 AWS까지는 HTTPS로 연결한다.

S3 또는 S3 Glacier에 데이터를 저장한다.

물리 테이프 대신 사용하기 때문에 관리를 단순화하고 비용을 줄일 수 있다.

https://aws.amazon.com/storagegateway/vtl/

 

Volume Gateway: (iSCSI  지원, Block Storage) 

Volume Gateway

• 온프레미스까지는 iSCSI 프로토콜로 연결하고 AWS까지는 HTTPS로 연결
• Volume Storage는 Amazon S3와 Amazon EBS에 데이터를 저장할 수 있다. 
• AWS Backup을 사용해서 백업을 EBS Snapshot으로 저장 가능하다.

 

Volume Gateway의 2가지 유형

• Cached volumes (캐시 모드)
• Stored volumes (보관 모드)

Cached volumes (캐시 모드) - 온프레미스에 캐시만 저장, AWS에 모든 데이터 저장

모든 데이터를 S3에 저장하고, 빈번하게 사용되는 데이터만 온프레미스의 캐시 스토리지에 캐시로 저장된다.

캐시에 데이터가 없을 경우 S3에 액세스하므로 지연이 발생하지만, 온프레미스 스토리지 용량을 절약할 수 있다.

• On-Premise에 캐시 저장
• AWS(예: S3, EBS, S3 Glacier)에 데이터의 대부분을 백업/저장

Stored volumes (보관 모드) - 온프레미스에 모든 데이터 저장, AWS에 백업만 저장

모든 데이터를 온프레미스의 볼륨 스토리지에 저장하고, S3에 비동기적으로 백업을 저장한다.

캐시형과는 달리 모든 데이터에 대한 접근이 온프레미스에서 이루어지므로, S3에 접근할 때 발생하는 지연이 없다.

• On-Premise에 모든 데이터를 저장
• AWS(예: S3, EBS, S3 Glacier) 에는 데이터의 스냅샷 (백업)만 저장

 

---

 

🤔 SAA-C03 문제)

온프레미스에 있는 여러 Windows 클라이언트에서 AWS의 스토리지를 이용해 파일 공유를 하고자 할 때, 가장 적절한 방법은 무엇입니까?

1. AWS Storage Gateway의 볼륨 게이트웨이(캐시형)에서 SMB를 사용하여 FSx for Windows File Server의 볼륨에 접근하기
2. AWS Storage Gateway의 볼륨 게이트웨이(보관형)에서 SMB를 사용하여 FSx for Windows File Server의 볼륨에 접근하기
3. AWS Storage Gateway의 S3 파일 게이트웨이에서 NFS를 사용하여 S3 버킷에 접근하기
4. AWS Storage Gateway의 FSx 파일 게이트웨이에서 SMB를 사용하여 온프레미스에서 FSx for Windows File Server의 볼륨에 접근하기

정답

정답. 4번

AWS Storage Gateway의 FSx 파일 게이트웨이에서 SMB를 사용하여 온프레미스에서 FSx for Windows File Server의 볼륨에 접근하기

 

[SMB (Server Message Block) ]

여러 Windows 클라이언트에서 파일을 공유하려면 SMB 프로토콜을 사용하는 것이 적절하다. SMB는 서버 등에 저장된 파일을 여러 클라이언트가 공유하기 위한 네트워크 프로토콜(통신 절차)로, 주로 Windows 계열 OS에서 사용된다.

 

[Amazon FSx File Gateway]
AWS Storage Gateway의 FSx File Gateway는 온프레미스에서 SMB를 사용해 FSx for Windows File Server에 접근할 수 있도록 하는 게이트웨이 유형이다.
로컬에 캐시 스토리지를 보유하고 있어 낮은 지연 시간으로도 접근이 가능하다.

오답

1번. AWS Storage Gateway의 볼륨 게이트웨이(보관형)에서 SMB를 사용하여 FSx for Windows File Server의 볼륨에 접근하는 방법
2번. AWS Storage Gateway의 볼륨 게이트웨이(캐시형)에서 SMB를 사용하여 FSx for Windows File Server의 볼륨에 접근하는 방법
AWS Storage Gateway의 볼륨 게이트웨이는 iSCSI 연결을 통한 블록 스토리지를 사용할 수 있는 서비스이다.
SMB는 지원하지 않으므로 이 방법들도 잘못되었다.

 

 

3번. AWS Storage Gateway의 S3 파일 게이트웨이에서 NFS를 사용하여 S3 버킷에 접근하는 방법
NFS는 주로 UNIX 계열 OS에서 사용되는 파일 공유 프로토콜이다.
Windows 클라이언트에서 파일을 공유할 때는 SMB를 사용하는 것이 적절하므로 이 방법은 잘못되었다.

 

다른 SAA-C03 예시 문제

A company uses NFS to store large video files in on-premises network attached storage. Each video file ranges in size from 1 MB to 500 GB. The total storage is 70 TB and is no longer growing. The company decides to migrate the video files to Amazon S3. The company must migrate the video files as soon as possible while using the least possible network bandwidth. Which solution will meet these requirements?

1. Create an S3 bucket. Create an IAM role that has permissions to write to the S3 bucket. Use the AWS CLI to copy all files locally to the S3 bucket.
2. Create an AWS Snowball Edge job. Receive a Snowball Edge device on premises. Use the Snowball Edge client to transfer data to the device. Return the device so that AWS can import the data into Amazon S3. Most Voted
3. Deploy an S3 File Gateway on premises. Create a public service endpoint to connect to the S3 File Gateway. Create an S3 bucket. Create a new NFS file share on the S3 File Gateway. Point the new file share to the S3 bucket. Transfer the data from the existing NFS file share to the S3 File Gateway.
4. Set up an AWS Direct Connect connection between the on-premises network and AWS. Deploy an S3 File Gateway on premises. Create a public virtual interface (VIF) to connect to the S3 File Gateway. Create an S3 bucket. Create a new NFS file share on the S3 File Gateway. Point the new file share to the S3 bucket. Transfer the data from the existing NFS file share to the S3 File Gateway.

정답

정답. 3번

 

2. On a Snowball Edge device you can copy files with a speed of up to 100Gbps. 70TB will take around 5600 seconds, so very quickly, less than 2 hours. The downside is that it'll take between 4-6 working days to receive the device and then another 23 working days to send it back and for AWS to move the data onto S3 once it reaches them. Total time: 6-9 working days. Bandwidth used: 0.

3. File Gateway uses the Internet, so maximum speed will be at most 1Gbps, so it'll take a minimum of 6.5 days and you use 70TB of Internet bandwidth.

4. You can achieve speeds of up to 10Gbps with Direct Connect. Total time 15.5 hours and you will use 70TB of bandwidth. However, what's interesting is that the question does not specific what type of bandwidth? Direct Connect does not use your Internet bandwidth, as you will have a dedicate peer to peer connectivity between your on-prem and the AWS Cloud, so technically, you're not using your "public" bandwidth. The requirements are a bit too vague but I think that B is the most appropriate answer, although D might also be correct if the bandwidth usage refers strictly to your public connectivity.