스토리지 추가기능

SnowFamily

• 보안성이 뛰어난 휴대용 장치의 모음이다.
• AWS 내에서 두 가지 경우에 사용한다.
• 엣지에서 데이터를 수집하고 처리하기 위해 사용 (Snowcone, Snowball Edge)
• AWS 안팎으로 데이터를 마이그레이션할 때 (Snowcore, Snowball Edge, Snowmobile)

Snow Family를 사용한 데이터 마이그레이션

• 대용량의 데이터를 네트워크를 경유해 전송하려면 많은 시간이 걸린다.
• AWS에 빠르게 접속해야 할 때가 있는데 그런 경우에 생기는 문제점은 전송 가능한 데이터의 양이 적다는 것과
  제한된 연결 및 제한된 대역폭 문제와 네트워크를 통한 데이터 전송으로 비용이 발생한다는 것이다.
• 대역폭 문제도 존재한다. AWS에서 영상을 다운로드하는데 그 데이터 크기가 10TB라면 사무실 전체가 차단된다.

이런 이유로 인해 Snow Family가 사용된다

• Snow 제품군은 오프라인에서 데이터 마이그레이션을 실행하는 장치다.
• AWS가 우편으로 물리적 장치를 보내주면 거기에 데이터를 끌어오고 다시 AWS로 전송하는 것
• 일반적으로 데이터 전송 시 네트워크를 사용할 경우 일주일이 넘는 시간이 걸린다면 Snowball 장치를 사용해야 한다.

Snowball Edge

• TB 혹은 PB 크기의 데이터를 AWS 안팎으로 전송할 수 있다.
• 네트워크를 대신해서 데이터를 옮길 수 있고, 데이터 전송 건마다 비용이 청구된다.
• Snowball Edge 인터페이스는 블록 스토리지를 제공하거나 Amazon S3 호환 객체 스토리지를 제공한다.
• Snowball Edge Storage Optimized는 블록 볼륨으로 사용할 수 있도록 80TB의 하드웨어 디스크 용량을 제공하거나 S3 호환 객체 스토리지를 제공한다.
• Snowball Edge Compute Optimized는 42TB의 HDD 용량을 제공한다.
• 따라서 더 큰 스토리지가 필요할 때 사용할 옵션은 Snowball Edge Storage Optimized다.
• Snowball Edge를 데이터 전송에 쓰는 경우는 데이터 센터 폐쇄를 위한 대량의 데이터 클라우드 마이그레이션이나 AWS에 데이터를 백업함으로써 재해 복구를 하는 경우다.

Snowcone

• 엣지 컴퓨팅, 스토리지 및 데이터 전송에 사용되는데 용량이 작을 경우 사용한다.
• Snowcone의 스토리지에는 8TB를 저장할 수 있으며 Snowball Edge Storage Optimized와 비교하면 10배는 적은 용량이다.
• Snowball 사용이 불가능할 때 Snowcone을 쓸 수 있다.
• 예를 들면 공간의 제약을 받는 환경이다. 필요하면 Snowcone을 드론 위에 설치할 수도 있다.
• AWS 오프라인으로 다시 전송될 수 있으며 아니면 네트워크에 연결해서 AWS DataSync를 사용해 데이터를 재전송할 수 있다.
• Snowcone을 데이터 센터에 연결하면 데이터가 자동으로 AWS에 전송됩니다
• 혹은 오프라인으로 AWS에 재전송 할 수도 있죠

Snowmobile

• 실제 트럭으로, Snowmobile가 전송하는 데이터는 EB(엑사바이트)에 달한다.
• 각 Snowmobile의 용량은 100PB이다.
• 보안성이 뛰어나고 온도 조절이 가능하며 GPS 추적 및 연중무휴 비디오 감시로 굉장히 안전한 데이터 전송 방법
• 10PB 이상의 데이터를 전송하려면 Snowball보다 좋은 방법이라고 할 수 있다.

제품군 비교

• Snowcone, Snowball Edge, Snowmobile이 있고 각각의 스토리지 용량이 서로 다릅니다. (8TB, 80TB, 100 PB)
• AWS에서 권장하는 마이그레이션 크기는 Snowcone이 24TB까지 Snowball Edge는 PB까지다.
• AWS로 오프라인 재전송도 가능하다.
• Snowmobile의 경우 최대 EB 데이터까지 전송 가능하다.
• Snowcone에는 DataSync가 미리 설치되어 있어서 DataSync는 네트워크 연결을 통해 AWS에도 데이터를 전송할 수 있다.
• Snowball Edge에서는 스토리지 클러스터링으로 Snowball Edge 15개를 함께 구축하면 스토리지 크기를 늘릴 수도 있다.

사용 예시

1. 콘솔을 위해 배송을 요청
2. Snowball 클라이언트나 AWS OpsHub를 서버에 설치
3. Snowball을 서버에 연결하고 클라이언트를 사용해서 파일을 복사
4. 준비가 끝나서 장치를 다시 보내면 올바른 AWS 시설로 바로 옮겨진다. E 잉크 마커 덕분
5. 그리고 S3 버킷에 해당 데이터를 불러들이고 나면 가장 높은 보안 조치에 따라 Snowball은 전부 지워진다.
6. 이것이 데이터 마이그레이션인데 Snowball 장치의 유일한 사용 사례

Snow Family를 사용한 엣지 컴퓨팅

엣지 컴퓨팅(Edge Computing)이란?

• 엣지 컴퓨팅은 데이터가 엣지 로케이션에서 생성될 때 실시간으로 처리하는 방식을 뜻한다.
• 엣지 로케이션: 연결이 제한되어 있거나 인터넷 액세스가 없거나 컴퓨팅을 할 수 없는 곳
• 이런 장소에서 컴퓨팅이나 데이터 처리를 해야 할 경우 바로 엣지 컴퓨팅이 필요하다.
• 따라서 Snowball Edge나 Snowcone을 주문해서 엣지 로케이션에 장착시키면 엣지 컴퓨팅을 시작할 수 있게 된다.
• 엣지 컴퓨팅의 예시를 들면 데이터 전처리, 또는 클라우드로 보내지 않고 엣지에서 머신 러닝하는 경우와 사전 미디어 스트림 트랜스코딩 등이 있으며, 최종적으로는 데이터를 AWS로 재전송해야 하는 경우 Snowcone이나 Snowball Edge 장치를 보내면 된다.
• 다시 말해 데이터가 생성되는 곳의 아주 가까이에서 그 데이터를 처리하고, AWS로 보내는 것이다.

Snowcone

• 2 CPUS, 4GB메모리, 유무선 엑세스 Wi-Fi
• USB-C 혹은 선택적 배터리로 작동

Snowball Edge (Compute Optimized)

• 52개의 vCPU를 가지며 200GB의 RAM과 더불어 선택적 GPU가 있다.
• 영상 처리나 머신 러닝을 할 경우
• 그리고 사용 가능한 스토리지는 42TB

Snowball Edge (Storage Optimized)

• 더 적은 40개 vCPU와 80GB RAM을 가진다.
• 여기서는 객체 스토리지 클러스터링을 할 수 있다.

모든 장치들은 내부 EC2 인스턴스나 람다 함수를 실행할 수 있다.

AWS IoT Greengrass라는 서비스를 통해서 가능하다.

장기 배포 옵션을 선택할 수 있다.  장치를 1년에서 3년 빌리면 가격 할인을 받을 수 있다.

OpsHub

• 예전에는 위 장치를 사용할 때 CLI, 즉 명령줄 인터페이스 도구를 써서 처리했으며 방식도 매우 어려웠다.
• 그래서 OpsHub이 등장했다.
• 컴퓨터에 다운로드하여 사용해야만 한다.
• 그리고 연결이 되면 그래픽 인터페이스를 통해 Snow 장치에 연결해서 구성 및 사용할 수 있으니 아주 쉽다.
• 이것으로 단일 장치와 클러스터 장치를 잠금 해제하고 구성할 수 있으며 파일 전송이 가능해지고 Snow 장치에서 실행되는 EC2 인스턴스를 시작 및 관리할 수 있게 된다.
• 또한 장치 메트릭 모니터링과 AWS 호환 서비스 실행이 가능하다. (EC2 인스턴스, DataSync 혹은 네트워크 파일 시스템 등)

Snowball에서 Glacier까지

• Snowball은 Glacier에 데이터를 직접 끌어올 순 없다.
• 그렇게 하려면 먼저 Amazon S3를 사용해서 수명 주기 정책을 생성하여 Amazon Glacier로 객체를 전환해야 한다.
• Snowball이 데이터를 Amazon S3로 가져오면 S3의 수명 주기 정책을 통해 해당 데이터가 Amazon Glacier로 전환된다.

Amazon FSx

• AWS에서 완전 관리형 서비스로 타사 고성능 파일 시스템을 실행한다.
• RDS에서 AWS에 MySQL나 Postgres를 실행하는 것과 같은 개념이다.
• RDS가 FSx로 바뀌었고 파일 시스템을 실행한다는 점이 다르다.

Fsx for Lustre

• Lustre는 원래 분산 파일 시스템으로 대형 연산에 쓰인다.
• Lustre는 Linux와 클러스터(Cluster)를 합친 단어로 머신 러닝과 HPC, 즉 고성능 연산에 쓰인다.
• 동영상 처리나 금융 모델링 전자 설계 자동화 등의 애플리케이션에서 쓰이고 확장성이 상당히 높다.
• 초당 수백 GB의 데이터에 수백만 IOPS로 확장되고 밀리초보다 짧은 지연 시간을 자랑한다.
• 스토리지 옵션은 두 가지다.
• 낮은 지연 시간의 SSD나 워크로드가 많거나, 크기가 작은 무작위 파일 작업이 많으면 IOPS도 사용 가능하다.
• 처리량이 많은 워크로드나 크기가 큰 시퀀스 파일 작업에는 HDD를 쓸 수 있다.
• SSD가 HDD보다 비용은 많이 나간다.
• FSx for Lustre는 VPN과 직접 연결을 통해 온프레미스 서버에서 사용할 수 있다.

FSx for NetApp ONTAP

• AWS의 관리형 NetApp ONTAP 파일 시스템으로 NFS, SMB, iSCSI 프로토콜과 호환 가능하다.
• FSx for NetApp ONTAP 파일 시스템을 사용하여 온프레미스 시스템의 ONTAP이나 NAS에서 실행 중인 워크로드를 AWS로 옮길 수 있다.
• 다양한 운영 체제에서 사용 가능하다.
  (Linux, Windows, MacOS AWS의 VMware Cloud, Workspaces, Appstream EC2, ECS,  EKS)
• 즉, 호환 가능한 폭이 아주 넓고 그리고 스토리지는 자동으로 확장 및 축소된다. (오토스케일링)
• 복제와 스냅샷 기능도 지원. 비용도 적게 들고 데이터 압축이나 데이터 중복제거도 가능하다.
• NetApp ONTAP에서 중복 파일을 찾을 수 있다.
• 아주 유용한 지정 시간 복제 기능이 있는데 새 워크로드 등을 테스트할 때 상당히 유용하다.
• 파일 시스템에서 신속히 복제가 가능하고 스테이징 파일 시스템을 둘 수 있다.

FSx for Windows File Server

• 완전 관리형 Windows 파일 서버 공유 드라이브로 Windows를 사용하기 때문에 SMB 프로토콜과 Windows NTFS를 지원한다.
• Microsoft Active Directory 통합을 지원하므로 사용자 보안을 추가할 수 있고 ACL로 사용자 할당량을 추가해 액세스를 제어할 수 있다.
• FSx for Windows File Server의 특징으로는 겉보기에는 Windows에서만 사용할 수 있는 것 같지만 Linux EC2 인스턴스에도 마운트할 수 있다.
• 기존에 온프레미스 등에 Windows 파일 서버가 있는 경우 Microsoft 분산 파일 시스템인 DFS 기능을 이용해서 파일 시스템을 그룹화할 수 있다.
• 성능 면에서는 초당 수십 GB에 수백만 IOPS 그리고 수백 PB의 데이터까지 확장될 수 있으며 FSx for Windows File Server의 스토리지 옵션으로는 SSD로 지연 시간이 짧아야 하는 워크로드를 저장할 수 있다. 데이터베이스, 미디어 처리 데이터 분석 등이 들어간다.
• 혹은 더 비용이 싼 HDD로 넓은 스펙트럼의 워크로드를 저장할 수 있다. 홈 디렉터리나 CMS를 예시로 들 수 있다.
• FSx for Windows File Server는 프라이빗 연결로 온프레미스 인프라에서 액세스할 수 있다.
•  고가용성 다중 AZ에 대해 FSx for Windows File Server를 구성할 수 있다.
• 모든 데이터는 재해 복구 목적으로 Amazon S3에 매일 백업된다.

FSx for OpenZFS

• AWS의 관리형 OpenZFS 파일 시스템으로 여러 버전에서의 NFS 프로토콜과 호환이 가능하다.
• 주로 ZFS에서 실행되는 워크로드를 내부적으로 AWS로 옮길 때 사용한다.
• Linux, Mac, Windows에서 사용할 수 있다.
• 성능이 상당히 좋아서 백만 IOPS까지 확장 가능하고 지연 시간은 0.5 밀리초 이하다.
• 스냅샷, 압축을 지원하고 비용이 적지만 데이터 중복제거 기능은 없다.
• NetApp ONTAP처럼 역시 지정 시간 동시 복제 기능이 있어서 새 워크로드 테스트 시에 유용하다.

FSx File System Deployment Options

FSx의 파일 시스템 배포 옵션에는 스크래치 파일 시스템과 영구 파일 시스템이 있다.

스크래치파일 시스템 

• 스크래치 파일 시스템은 임시 스토리지로 데이터가 복제되지 않는다.
• 즉 기저 서버가 오작동하면 파일이 모두 유실된다.
• 하지만 최적화로 초과 버스트를 사용할 수 있다.
• 영구 파일 시스템보다 성능을 여섯 배 높일 수 있다.
• TiB 처리량당 초당 200MB의 속도가 나온다. 아주 규모가 크다.
• 스크래치 파일 시스템은 단기 처리 데이터에 쓰이며 데이터 복제가 없어 비용을 최적화할 수 있다.
• FSx가 있으면 컴퓨팅(Compute) 인스턴스가 AZ 1과 AZ 2에 연결하는데 이때 FSx for Lustre 스크래치 파일 시스템을 사용하면 우측에 보이는 도식처럼 데이터의 사본이 하나만 존재한다.
• 또한 데이터 저장소에 추가로 S3 버킷을 둘 수도 있다.

영구 파일 시스템

• 영구 파일 시스템은 장기 스토리지로 동일한 가용 영역에 데이터가 복제된다.
• AZ 간은 아니라 동일한 AZ 내에서만 복제된다.
• 다시 말하면 기저 서버가 오작동했을 때 단 몇분 내에 해당 파일이 대체된다.
• 영구 파일 시스템의 예시는 이름에서 알 수 있듯 민감한 데이터 장기 처리 및 스토리지를 들 수 있다.

Storage Gateway

• Amazon S3는 독점 스토리지 기술로 NFS 규정 준수 파일 시스템인 EFS와는 다르다.
• AWS Storage Gateway가 S3와 여러분의 온프레미스 인프라를 이어주는 가교의 역할을 한다.
• AWS의 스토리지 클라우드 네이티브 옵션을 보면 Amazon EBS나 EC2 인스턴스 같은 블록 스토리지가 있다.
• Amazon EFS나 Amazon FSx 같은 파일 시스템도 있다.
• Amazon S3나 Amazon Glacier 같은 객체 수준 스토리지도 있다.
• AWS Storage Gateway를 이용해서 온프레미스 데이터를 클라우드로 이동시킨다.

Usecase

• 먼저 재해 복구 목적으로 온프레미스 데이터를 클라우드에 백업할 수 있다.
• 혹은 백업과 복구 목적으로 클라우드 마이그레이션, 혹은 온프레미스에서 클라우드 간 스토리지 확장을 사용할 수 있다.
• 클라우드에는 콜드 데이터를 두고 온프레미스에는 이보다 더 자주 쓰는 웜 데이터를 두는 방식
• 데이터 중 대부분을 AWS에 저장하고 파일 액세스 지연 시간을 줄이기 위해 AWS Storage Gateway를 온프레미스 캐시로 사용하는 방법도 있다. 

S3 파일 게이트웨이

• S3 버킷에는 원하는 스토리지 클래스를 임의로 사용할 수 있다. (Glacier 제외 전부 가능)
• S3 버킷을 온프레미스 상의 애플리케이션 서버에 연결하려는데 이때 표준 네트워크 파일 시스템을 활용하고자 한다.
• 이를 위해 S3 파일 게이트웨이를 생성하여 애플리케이션 서버가 NFS나 SMB 프로토콜을 사용하도록 한다.
• 이 프로토콜을 통해 S3 파일 게이트웨이는 해당 요청을 HTTPS 요청으로 변환시켜 Amazon S3 버킷으로 보낸다.
• 따라서 애플리케이션 서버가 보기에는 일반적인 파일 공유 액세스로 보이나 실제로는 Amazon S3 버킷을 사용하는 셈이다.
• 이렇게 S3 객체를 온프레미스 애플리케이션 서버를 통해 가져올 수 있다.
• 해당 객체를 아카이브하고자 하는 경우 S3 버킷에 수명 주기 정책을 생성하여 S3 Glacier로 객체를 옮겨서 아카이브되도록 한다.
• 따라서 S3 파일 게이트웨이로 구성한 모든 버킷은 NFS 및 SMB 프로토콜을 이용해서 액세스할 수 있고 이 외에도 사용된 데이터는 신속한 액세스를 위해 파일 게이트웨이에 캐시로 저장된다.
• 따라서 전체 S3 버킷이 아닌 최근에 사용한 파일만 파일 게이트웨이에 있다.
• S3 버킷에서는 여러 스토리지 클래스를 지원하며 수명 주기 정책을 사용하면 S3 Glacier로도 옮길 수 있다.
• 이제 버킷에 액세스하려면 각 파일 게이트웨이마다 IAM 역할을 생성해야 한다.
• Windows 파일 시스템 네이티브인 SMB 프로토콜을 사용하는 경우에는 사용자 인증을 위해 Active Directory와 통합해야 한다.
• 이렇게 하면 S3 파일 게이트웨이에 사용자가 액세스할 때 인증을 거치며 결국 S3 버킷에 액세스할 때도 인증을 거친다고 할 수 있다.

FSx 파일 게이트웨이

• Amazon FSx 파일 게이트웨이가 있는데 이는 Amazon FSx for Windows File Server에 네이티브 액세스를 제공한다.
• 게이트웨이를 생성하면 자주 액세스하는 데이터의 로컬 캐시를 확보할 수 있다.
• 즉 중요한 파일의 로컬 캐시가 회사 데이터 센터에 쌓이고 액세스 시 지연 시간을 단축시킬 수 있다.
• 이것이 바로 FSx for Windows File Server와 더불어서 Amazon FSx 파일 게이트웨이를 함께 사용하는 이유다.
• 파일 게이트웨이에서 Windows 네이티브인 SMB, NTFS Active Directory가 호환 가능하다.
• 따라서 그룹 파일 공유나 온프레미스를 연결할 홈 디렉터리로 사용할 수 있다.

볼륨 게이트웨이

• 블록 스토리지로 Amazon S3가 백업하는 iSCSI 프로토콜을 사용한다.
• 볼륨이 EBS 스냅샷으로 저장되어 필요에 따라 온프레미스 볼륨을 복구할 수 있다.
• 볼륨 게이트웨이에는 두 가지 유형이 있는데 하나는 캐시 볼륨으로 최근 데이터 액세스 시 지연 시간이 낮다.
• 다른 하나는 저장 볼륨으로 전체 데이터 세트가 온프레미스에 있으며 주기적 Amazon S3 백업된다.
• 이렇게 애플리케이션 서버 백업이 필요한 경우 iSCSI 프로토콜로 볼륨 게이트웨이를 생성하고 이 볼륨 게이트웨이가 Amazon S3에 저장되는 Amazon EBS 스냅샷을 생성한다.
• 볼륨 게이트웨이도 온프레미스 서버에 볼륨을 백업하는 것이 중요하다.

테이프 게이트웨이

• 테이프 게이트웨이로는 물리적으로 테이프를 사용하는 백업 시스템이 있는 회사가 백업에 테이프 대신에 클라우드를 활용해 데이터를 백업할 수 있게 해준다.
• 가상 테이프 라이브러리(VTL)는 Amazon S3와 Glacier를 이용한다.
• 테이프 기반 프로세스의 기존 백업 데이터를 iSCSI 인터페이스를 사용하여 백업한다.
• 업계를 선도하는 백업 소프트웨어 벤더가 사용하는 서비스다.
• 도식을 보면 테이프 기반인 회사 데이터 센터의 백업 서버가 있을 때 테이프 게이트웨이가 이를 클라우드에 연결하여 Amazon S3나 Amazon Glacier에 해당 테이프를 저장하는 방식이다.

Hardware appliance

• 게이트웨이는 우리의 회사 데이터 센터에 설치되어야한다. 회사 데이터 센터 내에서 운영해야 한다.
• 하지만 종종 게이트웨이를 실행할 가상 서버가 없는 경우가 있다.
• 이 경우 AWS의 하드웨어를 사용할 수 있다.
• 이 서비스를 Storage Gateway 하드웨어 어플라이언스라고 하며 온프레미스에 서버가 없는 경우 Storage Gateway 하드웨어 어플라이언스를 사용할 수 있는데 amazon.com에서 주문할 수 있다.
• 미니 서버가 될 하드웨어 어플라이언스를 여러분의 인프라에 설치한 후 파일 게이트웨이, 볼륨 게이트웨이 혹은 테이프 게이트웨이로 설정하면 된다.
• 물리적으로 설치해야 하는데 제대로 작동하려면 충분한 CPU, 메모리 네트워크, 그리고 SSD 캐시 리소스가 필요하다.
• 소규모 데이터 센터의 일일 NFS 백업처럼 가상화가 없는 경우 상당히 유용하다.

AWS Transfer Family

• Amazon S3 또는 EFS의 안팎으로 데이터를 전송하려고 하는데 오직 FTP만 사용할 때  AWS Transfer Family을 사용한다.
• 우선 FTP(파일 전송 프로토콜)의 AWS 전송을 지원한다.
• 참고로 FTP는 암호화되지 않는 반면에 FTPS와 SFTP는 전송 중에 암호화된다.
• FTP 프로토콜을 사용해서 S3 혹은 EFS에 업로드할 수 있다.
• 전송 제품군은 완전 관리형 인프라이며 확장성, 안정성이 높고 가용성 또한 높다.
• 시간당 프로비저닝된 엔드 포인트 비용에 전송 제품군 안팎으로 전송된 데이터의 GB당 요금을 더한다.
• 또 서비스 내에서 사용자 자격 증명을 저장 및 관리할 수도 있다.
• 다음과 같은 기존의 인증 시스템과 통합할 수도 있다. (Microsoft Active Directory, LDAP Okta, Amazon Cognito, 사용자 지정 소스)
• 사용 사례는 물론 Amazon S3나 EFS의 FTP 인터페이스를 갖기 위해서다.
• 파일 공유 및 공개 데이터셋 공유를 위해 그리고 CRM, ERP 등을 하기 위해서다.
• 사용자는 FTP의 엔드 포인트를 통해 직접 액세스하거나 선택적으로 Route 53라는 이름의 DNS를 사용하여 FTP 서비스에 고유의 호스트 이름을 제공할 수 있다.
• 그리고 FTP 서비스의 전송에는 IAM 역할이 있어서 Amazon S3나 Amazon EFS의 파일을 보내거나 읽도록 한다.
• AWS Transfer Family의 보안을 위해 외부 인증 시스템을 통해서 사용자를 인증할 수 있는데 는 Active Directory, LDAP 등이 있다.

Data Sync

• Data Sync는 데이터를 동기화하며 대용량의 데이터를 한 곳에서 다른 곳으로 옮길 수 있다.
• 온프레미스나 AWS의 다른 클라우드로 데이터를 옮길 수 있는데 이때 여러분의 서버를 NFS, SMB HDFS 또는 다른 프로토콜에 연결해야 하고 옮길 위치인 온프레미스나 연결할 다른 클라우드에 에이전트가 있어야 한다.
• 클라우드 → 클라우드, 온프레미스 → 클라우드, 클라우드 → 온프레미스 모든 경우에 가능하다.
• 모든 Amazon S3의 Glacier를 포함하여 모든 스토리지 클래스에 동기화할 수 있다.
• Amazon EFS로 네트워크 파일 시스템에 저장할 수도 있다.
• Amazon FSx는 다양한 운영 체제에서 사용 가능하다. (Windows, Lustre, NetApp, OpenZFS)
• 복제 작업은 계속 이루어지지 않고 일정을 지정하여 DataSync가 매 시간, 매일, 혹은 매주 실행되도록 할 수 있다.
• 지연이 발생하긴 하지만 일정에 맞춰서 데이터가 동기화된다.
• DataSync에는 파일 권한과 메타데이터 저장 기능이 있다.
• 보안과 관련되어 NFS POSIX 파일 시스템 그리고 SMB 권한을 준수한다.
• 파일을 한 곳에서 다른 곳으로 옮길 때 이를 이용하여 파일의 메타데이터를 보존할 수 있다. (시험에서 중요)
• DataSync 에이전트 하나의 태스크가 초당 10Gb까지 사용할 수 있으며 네트워크 성능을 초과하고 싶지 않은 경우 대역폭에 제한을 걸 수 있다.
• 가끔 시험에서 DataSync를 이용하고자 하지만 네트워크 용량이 따라 주지 못하는 경우가 나온다. 이때 AWS Snowcone 장치를 사용할 수 있다.
• Snowcone 장치에는 DataSync 에이전트가 사전에 설치되어 있다.
• 온프레미스에서 Snowcone을 실행하고 데이터를 가져온 다음 DataSync 에이전트를 실행하면 다시 에이전트가 AWS 리전으로 전송되면서 AWS의 스토리지 리소스 외부에 데이터를 동기화할 수 있다.
• DataSync 에이전트를 이용하여 다른 클라우드에서 동기화할 때도 같다.
• DataSync를 통해 서로 다른 AWS 스토리지 서비스 간 동기화도 가능하다.
• Amazon S3, Amazon EFS 또는 Amazon FSx를 Amazon S3, Amazon EFS Amazon FSx로 다시 동기화하려는 경우 AWS DataSync 서비스를 사용하여 데이터 복사본을 만든다.
• 서로 다른 AWS 스토리지 서비스 간 메타데이터 또한 유지된다. (시험에서 중요)
• DataSync로 거의 대부분의 데이터를 동기화할 수 있으나 지속적이지는 않고 일정에 따라 움직인다. 매 시간, 매일, 혹은 매주 진행할 수 있다.
• 메타데이터와 파일 권한은 보존된다.
• 끝으로 NFS 또는 SMB 서버에 연결하려면 DataSync 에이전트를 실행해야 한다.