AWS Storage Gateway FAQ

Amazon S3 File Gateway는 업계 표준 파일 프로토콜을 사용하여 파일을 원활하게 Amazon S3에 객체로 저장하고 이에 액세스할 수 있는 파일 인터페이스를 애플리케이션에 제공하는 AWS Storage Gateway 서비스 구성입니다.

Amazon S3 File Gateway의 사용 사례로는 (a) 최근에 액세스한 데이터에 대해 빠른 로컬 액세스를 유지하면서 온프레미스 파일 데이터를 Amazon S3로 마이그레이션, (b) 온프레미스 파일 데이터를 Amazon S3에 객체로 백업하고(Microsoft SQL Server와 Oracle 데이터베이스 및 로그 포함) 수명 주기 관리 및 교차 리전 복제와 같은 S3 기능을 사용, (c) 기계 학습, 빅 데이터 분석 또는 서버리스 함수와 같은 AWS 서비스로 처리하기 위해 온프레미스 애플리케이션에서 생성한 데이터를 사용하는 하이브리드 클라우드 워크플로가 있습니다.

Amazon S3 File Gateway를 사용하면 아무런 변경 없이 기존 파일 기반 애플리케이션, 디바이스 및 워크플로에서 Amazon S3를 사용할 수 있습니다. Amazon S3 File Gateway는 파일 콘텐츠와 메타데이터를 모두 객체로 안전하고 안정적으로 저장하면서 동시에 온프레미스 애플리케이션에 캐시된 데이터에 대한 대기 시간이 짧은 액세스를 제공합니다.

Amazon S3 File Gateway는 Amazon S3 Standard, S3 Intelligent-Tiering, S3 Standard - Infrequent Access(S3 Standard-IA) 및 S3 One Zone-IA를 지원합니다. 스토리지 클래스에 대한 자세한 내용은 Amazon S3 설명서를 참조하세요. 게이트웨이가 생성하는 객체에 대한 초기 스토리지 클래스를 구성한 다음, 버킷 수명 주기 정책을 사용하여 Amazon S3에서 Amazon S3 Glacier로 파일을 이동할 수 있습니다. 애플리케이션이 Amazon 파일 게이트웨이를 통해 저장되고 현재 Amazon S3 Glacier에 있는 파일/객체에 액세스하려고 시도하면 일반 I/O 오류가 발생합니다.

Amazon S3 File Gateway는 NFS(네트워크 파일 시스템) 버전 3 및 4.1을 사용하여 게이트웨이에 연결하는 Linux 클라이언트를 지원하고 SMB(서버 메시지 블록) 버전 2 및 3을 사용하여 게이트웨이에 연결하는 Windows 클라이언트를 지원합니다.

AWS Management Console 또는 서비스 API를 사용하여 NFS 또는 SMB 파일 공유를 생성하고 이를 새로운 또는 기존 Amazon S3 버킷에 연결할 수 있습니다. 애플리케이션에서 파일 공유에 액세스하려면 애플리케이션에서 표준 UNIX 또는 Windows 명령을 사용해 이를 탑재합니다. 편의를 위해, 각 환경에 대한 명령줄 예가 관리 콘솔에 표시되어 있습니다.

특정 NFS 클라이언트 또는 네트워크, 읽기 전용 또는 읽기-쓰기로 액세스 제한, 사용자 권한 스쿼싱 활성화와 같은 관리 제어 항목을 사용해 NFS 파일 공유를 구성할 수 있습니다.

Active Directory(AD) 사용자만 액세스하도록 하거나 조직 내 사용자에게 인증된 게스트 액세스 권한을 제공하도록 SMD 파일 공유를 구성할 수 있습니다. 파일 공유에 대한 액세스를 읽기 전용 또는 읽기-쓰기로, 또는 특정 AI 사용자 및 그룹으로 추가로 제한할 수 있습니다.

예. SMB 파일 공유에 대한 액세스 기반 열거를 구성하여 사용자가 자신의 액세스 권한에 따라 열 수 없는 폴더와 파일은 보지 못하도록 할 수 있습니다. 사용자가 Amazon S3 File Gateway의 파일 공유를 탐색할 수 있는지 여부도 제어할 수 있습니다.

예. Amazon S3 File Gateway는 Microsoft Active Directory 온프레미스뿐만 아니라 Managed Microsoft AD와 같은 클라우드 Active Directory 솔루션과도 통합됩니다.

예. 게스트 사용자 이름과 암호를 사용하여 SMB 파일 공유를 내보낼 수 있습니다. 게스트 액세스를 위한 파일 공유를 설정하기 전에 콘솔 또는 서비스 API를 사용하여 기본 암호를 변경해야 합니다.

예.

아니요. 현재 S3 객체 메타데이터로 저장된 소유권과 같은 파일 메타데이터는 다른 프로토콜에 매핑될 수 없습니다.

Amazon S3 File Gateway는 AWS Identity and Access Management(IAM) 역할을 사용하여 S3 버킷에 액세스합니다. IAM 역할을 자체적으로 설정하거나 AWS Storage Gateway 관리 콘솔에서 자동으로 설정하도록 할 수 있습니다. 자동 설정의 경우 AWS Storage Gateway는 사용자 계정에 새 IAM 역할을 생성하고 S3 버킷에 액세스할 수 있도록 이를 IAM 액세스 정책과 연결합니다. IAM 역할과 IAM 액세스 정책은 사용자 계정에 생성되며 사용자가 이를 완벽하게 관리할 수 있습니다.

파일 공유를 사용하려면 애플리케이션에서 표준 UNIX 또는 Windows 명령을 사용해 탑재합니다. 편의를 위해 명령줄 예제를 관리 콘솔에 표시하였습니다.

파일 공유를 S3 버킷의 루트에 매핑할 수도 있고, S3 버킷 내의 S3 접두사에 매핑할 수도 있습니다. 파일 공유를 생성할 때 S3 접두사를 지정하면 해당 파일 공유를 그 S3 접두사에 연결하게 됩니다. 파일 공유를 생성할 때 S3 접두사를 생성하지 않으면 해당 파일 공유는 S3 버킷의 루트와 연결됩니다.

예, 파일 공유 이름이 S3 버킷이나 S3 접두사 이름과 같지 않아도 됩니다.

예, 파일 공유 이름은 변경해도 됩니다.

파일은 S3 버킷에 객체로 저장되고 File Gateway가 생성하는 객체에 대한 초기 스토리지 클래스를 구성할 수 있습니다. 파일과 객체 간에는 일대일 관계가 존재하며 사용자는 Amazon S3 File Gateway가 생성하는 객체에 대한 초기 스토리지 클래스를 구성할 수 있습니다.

객체 키는 파일 시스템 내 파일 경로에서 파생됩니다. 예를 들어 호스트 이름이 file.amazon.com인 게이트웨이가 있고 매핑된 my-bucket/my-prefix가 있다면 File Gateway가 file.amazon.com:/export/my-bucket/my-prefix라는 탑재 지점을 노출합니다. 그런 다음 사용자가 이를/mnt/my-bucket/my-prefix에 로컬로 탑재하고 /mnt/my-bucket/my-prefix/dir 디렉터리에 file.html이라는 파일을 생성하면 이 파일이 my-prefix/dir/file.html 키와 함께 my-bucket 버킷에 객체로서 저장됩니다. 스파스 파일을 생성하면 S3에 0으로 채워진 비스파스 객체가 생성됩니다.

클라이언트는 파일 및 디렉터리를 생성하고 읽고 업데이트하고 삭제할 수 있습니다. 파일 및 폴더의 권한과 소유권을 변경할 수도 있습니다. 파일은 Amazon S3에 개별 객체로 저장됩니다. 디렉터리는 S3의 폴더 객체로 관리되며 S3 콘솔과 같은 구문을 사용합니다. 기호 링크나 하드 링크는 지원되지 않습니다. 링크를 만들려고 하면 오류가 발생합니다. 일반적인 파일 작업 시에는 파일 메타데이터가 변경되므로 현재 S3 객체가 삭제되고 새 S3 객체가 생성됩니다.

이름 바꾸기 작업은 클라이언트에 원자성 작업으로 나타나지만, S3는 객체 이름 바꾸기를 지원하지 않습니다. 파일 또는 디렉터리 이름을 바꿀 때 게이트웨이는 copy-put 요청을 수행하여 S3에서 새 키 아래에 객체의 사본을 생성한 다음 원본 객체를 삭제합니다. 그러면 네트워크를 통해 대규모 파일을 다시 보낼 필요가 없습니다. 많은 수의 파일을 포함하는 디렉터리 이름 바꾸기는 즉각적이지 않고, 이름 바꾸기 작업이 완료될 때까지 S3에 데이터 사본 2개를 저장하며 디렉터리 내 작업은 차단됩니다.

클라이언트는 소유권, 권한 및 타임스탬프를 비롯한 POSIX 스타일 메타데이터에 액세스할 수 있으며, S3에서 파일과 연결된 객체의 사용자 메타데이터에 안정적으로 저장됩니다. 기존 버킷에 파일 공유를 만들면 저장된 메타데이터가 복원되어 클라이언트에서 액세스할 수 있습니다.

각 파일 공유에 대해 업로드된 객체의 MIME 유형 추정 기능을 활성화할 수 있으며, 이 기능은 생성 시 또는 나중에 활성화할 수 있습니다. 활성화된 경우, File Gateway가 파일 이름 확장자를 사용하여 해당 파일의 MIME 유형을 결정하고 이에 따라 S3 객체 Content-Type을 설정합니다. 이는 File Gateway를 사용하여 S3의 객체를 관리하고 있는 경우, 즉 URL을 통해 직접 액세스하거나 Amazon CloudFront를 통해 배포하는 경우에 유용합니다.

예. 객체가 일단 S3에 저장되면, Amazon S3 File Gateway 없이도 클라우드 내 워크로드에 대한 AWS에 있는 객체에 직접 액세스할 수 있습니다. 객체는 객체가 저장된 S3 버킷의 속성(수명 주기 관리, 교차 리전 복제 등)을 상속받습니다.

파일 공유를 사용해 액세스해야 하는 객체는 게이트웨이에서 관리해야 합니다. Amazon S3 File Gateway에서 작성한 객체를 직접 덮어쓰거나 업데이트하는 경우 파일 공유를 통해 객체에 액세스할 때 정의되지 않은 동작이 발생할 수 있습니다.

Amazon S3 File Gateway에서 사용하도록 버킷을 구성할 때 이미 버킷에 객체가 있다면 객체 키를 사용하여 객체를 NFS 및 SMB 클라이언트에 파일로 표시합니다. 이 파일에는 기본 파일 시스템 메타데이터가 제공됩니다.

Amazon S3 요청의 수 및 대기 시간을 줄이기 위해, 사용자가 파일 또는 디렉터리를 명시적으로 나열하면 Amazon S3 File Gateway는 객체와 연결된 파일 메타데이터의 헤더만 검색합니다. 파일 메타데이터는 해당 검사의 일부로서 수집되며, 파일 콘텐츠는 객체를 읽을 때만 다운로드됩니다.

게이트웨이는 버킷에 있는 전체 객체 또는 모든 데이터를 자동으로 다운로드하지 않습니다. 클라이언트에서 명시적으로 액세스하는 경우에만 데이터를 다운로드합니다. 또한, 데이터 전송 오버헤드를 줄이기 위해 File Gateway는 멀티파트 업로드와 copy put을 사용하므로, 파일에서 변경된 데이터만 S3로 업로드됩니다.

File Gateway와 NFS 공유를 사용하지 않고 S3 버킷에 직접 업로드된 객체의 경우, 기본 소유권과 권한을 구성할 수 있습니다.

Amazon S3 File Gateway와 SMB 공유를 사용하지 않고 S3 버킷에 직접 업로드된 객체의 경우, 소유권 및 권한과 같은 메타데이터가 객체의 상위 폴더로부터 상속됩니다. 공유 루트의 권한은 고정되어 있으며 루트 폴더 아래에 바로 생성된 객체는 이러한 고정 권한을 상속받습니다. 게이트웨이 외부에서 생성된 객체의 메타데이터 설정에 대한 설명서를 참조하십시오.

여러 NFS 클라이언트가 하나의 File Gateway에 액세스하도록 할 수 있습니다. 하지만 다른 NFS 서버와 마찬가지로 여러 NFS 클라이언트에서 동시에 변경 작업을 수행하면 예기치 않은 동작이 발생할 수 있습니다. 안전한 방법으로 이를 수행하려면 애플리케이션 수준의 조정이 필요합니다.

아니요. S3 버킷의 객체에 단일 라이터를 사용하는 것이 좋습니다. File Gateway에서 쓴 객체를 직접 덮어쓰거나 업데이트하는 경우 파일 공유를 통해 객체에 액세스할 때 정의되지 않은 동작이 발생할 수 있습니다. 같은 객체를 동시에 변경하면(예: S3 API와 Amazon S3 File Gateway를 통해) 예기치 않은 동작으로 이어질 수 있으므로 이러한 구성은 피하는 것이 좋습니다.

단일 버킷에 여러 개의 라이터를 구성하는 것은 권장하지 않습니다. 예기치 않은 동작으로 이어질 수 있기 때문입니다. 애플리케이션 워크플로를 통해 고유한 객체 이름 또는 접두사를 적용할 수 있습니다. S3 파일 게이트웨이는 설정 등에서 충돌이 발생하면 상태 알림을 보냅니다.

예. Amazon S3 File Gateway에서 관리하는 버킷에 여러 개의 리더를 사용할 수 있습니다. 파일 공유를 읽기 전용으로 구성하고, 여러 개의 게이트웨이가 같은 버킷에서 객체를 읽도록 허용할 수 있습니다. 또한, Storage Gateway 콘솔, 자동화된 주기적 캐시 새로 고침 프로세스 또는 RefreshCache API를 사용하여 게이트웨이가 알고 있는 객체의 인벤토리를 새로 고칠 수 있습니다.

그러나 파일 공유를 읽기 전용으로 구성하지 않으면, Amazon S3 File Gateway가 이러한 리더를 모니터링하거나 실수로 버킷에 쓰지 못하게 제한하지 않습니다. 애플리케이션에 1개의 라이터/여러 개의 리더 구성을 유지할지는 사용자에게 달렸습니다.

예. Amazon CloudWatch 지표를 사용하여 파일 공유 사용을 모니터링하고 CloudWatch 이벤트를 통해 파일 작업 완료 시 알림을 받을 수 있습니다. 자세한 내용은 파일 공유 모니터링을 참조하세요.

Amazon S3 File Gateway로 파일을 파일 공유에 작성하면, 데이터가 먼저 로컬로 저장된 후 비동기식으로 S3 버킷에 업로드됩니다. 개별 파일의 업로드가 완료되면 AWS CloudWatch Events를 통해 알림을 요청할 수 있습니다. 이러한 알림은 현재 S3에 저장된 데이터에 따라 AWS Lambda 함수 또는 Amazon EC2 Systems Manager Automation 호출과 같은 다른 워크플로를 트리거하는 데 사용될 수 있습니다. 자세한 내용은 파일 업로드 알림에 대한 설명서를 참조하세요.

파일 업로드 알림은 Amazon S3 File Gateway를 통해 Amazon S3에 업로드되는 각 개별 파일에 대한 알림을 제공합니다. S3 이벤트 알림은 부분 파일 업로드가 포함된 알림을 제공하므로 S3 이벤트 알림에서는 파일 업로드가 완료되었는지를 알 수 없습니다.

Amazon S3 File Gateway로 파일을 파일 공유에 작성하면, 데이터가 먼저 로컬로 저장된 후 비동기식으로 S3 버킷에 업로드됩니다. 작업 파일 세트의 업로드가 완료되면 Amazon CloudWatch Events를 통해 알림을 요청할 수 있습니다. 이러한 알림은 현재 S3에 저장된 데이터에 따라 AWS Lambda 함수 또는 Amazon EC2 Systems Manager Automation 호출과 같은 다른 워크플로를 트리거하는 데 사용될 수 있습니다. 자세한 내용은 작업 파일 세트 업로드 알림에 대한 설명서를 참조하세요.

예, Amazon S3 File Gateway가 콘솔, 파일 시스템 중심 캐시 새로 고침 프로세스 또는 RefreshCache API를 사용한다는 것을 알고 있는 객체의 인벤토리를 새로 고칠 수 있습니다. RefreshCache API 작업이 완료되면 AWS CloudWatch Events를 통해 알림이 수신됩니다. 이러한 알림은 Amazon Simple Notification Service(SNS)를 사용하여 이메일을 보내거나 업데이트된 콘텐츠를 사용하여 로컬 처리를 트리거하는 데 사용될 수 있습니다. 자세한 내용은 설명서를 참조하세요.

예. 버킷에 대한 교차 계정 액세스에 게이트웨이를 사용할 수 있습니다. 자세한 내용은 교차 계정 액세스에서 파일 공유 사용에 대한 설명서를 참조하세요.

예. 파일 공유를 생성할 때 요청자 지불 S3 버킷에 대한 액세스 권한을 활성화할 수 있습니다. 요청자에게는 요청자 지불 버킷의 데이터 액세스와 관련된 요금이 부과됩니다.

파일 공유 생성 프로세스 중에 S3 접두사를 지정하면 여러 개의 파일 공유를 한 개의 S3 버킷에 대하여 생성할 수 있습니다.

게이트웨이 한 개에서 S3 버킷당 최대 50개의 공유를 생성할 수 있습니다. 여러 게이트웨이에 걸쳐서는 버킷당 파일 공유 수를 제한하지 않지만, 각 게이트웨이별로 공유 수는 50개로 제한됩니다. 그러나, 버킷에 단일 라이터가 있는 것이 좋습니다(S3에 직접 액세스하는 Amazon S3 File Gateway 또는 클라이언트).

예, 파일 공유의 이름은 변경할 수 있습니다.

개별 파일의 최대 크기는 5TB이며 이는 S3에 있는 개별 객체의 최대 크기와 같습니다. 5TB보다 큰 객체를 쓰면 "파일이 너무 큽니다"라는 오류 메시지가 표시되며 파일의 처음 5TB 부분만 업로드됩니다.

게이트웨이는 총 용량으로 큰 수(8EB)를 반환합니다. Amazon S3는 총 스토리지 용량을 제한하지 않습니다.

예. 수명 주기 관리, 교차 리전 복제 및 S3 이벤트 알림에 대한 버킷 정책이 AWS Storage Gateway를 통해 버킷에 저장된 객체에 직접 적용됩니다.

S3 수명 주기 정책을 사용하여 객체의 스토리지 계층을 변경하거나 오래된 객체 또는 객체 버전을 삭제할 수 있습니다. 수명 주기 정책에 따라 삭제된 객체의 경우에는 주기적 캐시 새로 고침 기능을 사용하거나 RefreshCache API를 직접적으로 호출하여 변경 내용을 NFS 클라이언트에 적용해야 합니다.

교차 리전 복제의 대상인 S3 버킷을 사용할 때는 주기적 캐시 새로 고침 기능을 사용하거나 RefreshCache API를 사용하여 게이트웨이 캐시와 S3 버킷을 서로 동기화해야 합니다.

S3 이벤트 알림을 사용하는 경우에는 데이터가 지속적으로 S3에 저장될 수 있도록 게이트웨이에서 생성된 부분 파일의 이벤트가 수신될 수도 있습니다. 게이트웨이에서 캐시 공간을 확보해야 하거나 파일에 대한 쓰기 속도가 빠른 등 몇 가지로 이유로 부분 파일이 발생할 수 있습니다. 이러한 부분 파일은 애플리케이션마다 다를 수 있습니다.

Amazon S3 File Gateway는 SMB 버전 2 및 3과 NFS 버전 3, 4.0 및 4.1을 지원합니다. 당사는 일반적인 백업 앱에 대한 테스트를 계속 진행하고 있습니다. 호환성 테스트를 받아보고자 하는 앱이 있다면 AWS Support나 AWS 계정 팀을 통해 알려주시기 바랍니다.

아니요. Amazon S3 File Gateway를 사용하면 파일을 S3에 객체로 저장할 수 있습니다.

Amazon S3 File Gateway는 표준 파일 시스템 운영을 사용해 S3에 있는 객체를 파일로서 액세스하려고 할 때 사용합니다. 또한, Amazon S3 File Gateway는 대기 시간이 짧은 액세스와 효율적인 데이터 전송을 제공합니다. S3 API는 애플리케이션에서 파일 시스템 작업을 할 필요가 없고 직접 데이터 전송을 관리할 수 있을 때 사용합니다.

게이트웨이의 로컬 디스크 스토리지는 AWS로 전송되어야 하는 변경된 데이터를 임시로 보관하고 대기 시간이 짧은 읽기 액세스를 위해 데이터를 로컬로 캐시할 때 사용됩니다. File Gateway는 클라이언트 읽기 및 쓰기 작업을 기반으로 가장 최근에 액세스한 데이터를 유지하는 캐시를 자동 관리합니다. 데이터는 최근에 사용한 데이터를 더 저장할 공간이 필요한 경우에만 캐시에서 제거됩니다.

쓰기 성능을 극대화하기 위해 게이트웨이는 라이트 백 메커니즘을 사용합니다. 데이터가 디스크에 먼저 보관되었다가 비동기식으로 S3로 업로드되는 메커니즘입니다. 게이트웨이는 읽기 성능을 극대화하기 위해 로컬 캐시에서 데이터를 제공합니다. 데이터가 캐시에 없는 경우 바이트 범위 GET을 사용해 Amazon S3에서 데이터를 동기적이고 효율적으로 가져옵니다.

로컬 캐시는 일반적으로 지연 시간이 짧은 액세스가 필요한 데이터 세트 작업에 맞는 크기로 조정해야 합니다. 캐시가 너무 작으면 읽기 지연 시간이 증가하여 요청한 데이터가 S3에서 분리되어야 하며, 로컬에서 S3로의 업로드를 보류하고 있는 데이터를 저장하기 위한 캐시 여유 공간이 없을 경우 쓰기 작업이 실패할 수 있습니다.

다음을 기준으로 캐시를 프로비저닝해야 합니다.
1/ 지연 시간이 짧은 액세스가 필요한 작업 데이터 세트의 크기. 그러면 S3에서 데이터를 요청하는 빈도를 줄여 읽기 지연 시간을 단축할 수 있습니다.
2/ 애플리케이션에서 게이트웨이에 작성하는 파일의 크기.

캐시 디스크가 더 작으면 S3로 업로드가 보류 중일 때 데이터를 로컬로 저장할 수 있는 여유 캐시 공간이 없는 경우에 쓰기가 진행되는 동안 성능이 떨어지고 오류가 발생할 수 있습니다. 캐시 사용 모니터링에 대한 자세한 내용은 설명서의 파일 공유 모니터링을 참조하세요.

애플리케이션을 통해 또는 Amazon S3 검색을 통해 캐시에 작성된 데이터는 좀 더 최근에 액세스한 데이터를 저장하기 위해 공간이 필요한 경우에만 캐시에서 제거됩니다.

변경 작업 없이 파일이 버킷의 객체에 일대일로 매핑되므로 게이트웨이를 사용하거나 추가 소프트웨어를 배포할 필요 없이 S3의 데이터에 직접 액세스할 수 있습니다.

Amazon S3 File Gateway는 멀티파트 업로드 및 copy put을 사용하기 때문에 S3에는 변경된 데이터만 업로드되어 데이터 전송을 줄일 수 있습니다. 게이트웨이는 버킷에 있는 전체 객체나 모든 데이터를 자동으로 다운로드하지 않습니다. NFS 클라이언트에서 명시적으로 액세스하는 경우에만 데이터를 다운로드합니다.

File Gateway는 버킷이 S3 Transfer Acceleration을 위해 구성된 경우에도 가속화된 엔드포인트를 사용하지 않습니다.

게이트웨이와 AWS 스토리지 간에 전송되는 모든 데이터는 SSL을 사용해 암호화됩니다. 기본적으로 S3에 저장되는 모든 데이터는 Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측에서 암호화됩니다. 각 파일 공유에 대해 선택 사항으로 SSE-KMS를 사용하여 AWS KMS 관리형 키로 객체를 암호화하도록 구성할 수 있습니다. 자세히 알아보려면 Storage Gateway 사용 설명서에서 기능 사용에 대한 중요한 세부 정보가 포함된 ‘AWS Key Management System을 사용한 데이터 암호화’ 섹션을 참조하세요.  

Amazon FSx File Gateway는 Amazon FSx 상의 Windows 파일 공유에 대한 온프레미스 액세스를 최적화하여 사용자는 FSx for Windows File Server 짧은 대기 시간으로 데이터에 쉽게 액세스하고 공유 대역폭을 절약할 수 있습니다. 사용자는 액세스할 수 있는 자주 사용하는 데이터의 로컬 캐시의 이점을 활용해 보다 빠른 성능을 얻고 데이터 전송 트래픽을 줄일 수 있습니다. 파일 읽기 및 쓰기 등의 파일 시스템 작업은 모두 로컬 캐시에 대하여 수행되는 반면, Amazon FSx 파일 게이트웨이는 변경된 데이터를 백그라운드에서 FSx for Windows File Server에 동기화합니다. 이러한 기능을 통해 FSx for Windows File Server 상의 AWS에서 모든 온프레미스 파일 공유 데이터를 통합하고, 보호되고 복원력이 뛰어나며 완벽하게 관리되는 파일 시스템을 활용할 수 있습니다.

많은 온프레미스 데스크톱 애플리케이션은 대기 시간에 민감하며, 이로 인해 최종 사용자에게 지연을 초래하고, 원격 위치에서 AWS 내 파일에 직접 액세스하는 경우 성능이 느려질 수 있습니다. 또한 많은 사용자가 클라우드에 있는 데이터에 직접 액세스하도록 허용하면 AWS Direct Connect 링크와 같은 공유 대역폭 리소스가 정체될 수 있습니다. Amazon FSx 파일 게이트웨이는 사용자가 이러한 워크로드에 대해 Amazon FSx for Windows File Server를 사용하도록 허용하며, 사용자의 온프레미스 스토리지를 AWS 내에 완전 관리형, 확장 가능, 그리고 신뢰성이 아주 높은 스토리지로 교체하여 사용자의 애플리케이션 또는 네트워크에 영향을 미치지 않습니다.

A: Amazon FSx File Gateway는 클라이언트용 SMB 파일 프로토콜 서버를 제공하여 자주 사용하는 데이터의 온프레미스 캐시에 연결하여 AWS 내에서와 동일한 짧은 대기 시간으로 액세스할 수 있도록 합니다. 파일 읽기 및 쓰기 등의 파일 시스템 운영은 모두 로컬 캐시에 대하여 수행되는 반면, Amazon FSx File Gateway는 변경된 데이터를 백그라운드에서 Amazon FSx for Windows File Server에 동기화합니다. Amazon FSx 파일 게이트웨이는 또한 AWS에 대한 네트워크 대역폭을 최적화하며 데이터 전송량을 최소화합니다.

Amazon FSx File Gateway를 사용하려면, 한 개 이상의 Amazon FSx 파일 시스템을 실행하고 VPN 또는 AWS Direct Connect 연결을 통해 Amazon FSx for Windows File Server에 대한 온프레미스 액세스가 가능해야 합니다. FSx for Windows File Server를 시작하려면, 여기에서 설명서를 확인합니다. 그런 다음 Amazon FSx File Gateway VMware 가상 장치 또는 AWS Storage Gateway 하드웨어 어플라이언스를 온프레미스 환경에 다운로드하여 배포하는 것으로 시작합니다. Amazon FSx File Gateway를 설치하면 FSx for Windows File Server에 액세스할 수 있으며, AWS 관리 콘솔을 사용하여 FSx for Windows File Server 파일 시스템에 연결할 수 있습니다. 그런 다음 AWS 관리 콘솔에서 온프레미스에서 파일 공유에 액세스하도록 하는 데 필요한 모든 단계를 안내합니다.

파일 공유를 구성한 다음 클라이언트 시스템은 Amazon FSx File Gateway 상의, 선택된 Amazon FSx 파일 시스템과 일치하는 파일 공유를 탐색 및 연결할 수 있습니다. 파일 공유가 연결되면 사용자는 FSx for Windows File Server의 모든 기능을 활용할 수 있는 동시에 파일을 로컬로 읽고 쓸 수 있습니다. 

Amazon FSx File Gateway는 FSx for Windows File Server가 제공되는 모든 AWS 리전 내 Windows 파일 시스템에 액세스하는 데 사용될 수 있습니다.

A: Amazon FSx File Gateway에 대하여 시간 당 요금이 청구됩니다. 요금에 대한 자세한 내용은 AWS Storage Gateway 요금 페이지를 참조하세요.

Amazon FSx File Gateway는 SMB(서버 메시지 블록) 프로토콜 2.x 및 3.x 버전을 지원합니다. SMB는 Microsoft Windows, MacOS, 및 Linux OS에서 지원됩니다.

A: Amazon FSx File Gateway는 지역 파일 공유 및 콘텐츠를 Amazon FSx for Windows File Server 내에 원격으로 저장된 파일 공유에 매핑합니다. 원격 및 로컬로 보이는 파일 및 공유는 1:1로 상응합니다.

예. Amazon FSx File Gateway 및 AWS 내 Amazon FSx에서 직접 파일 공유에 액세스할 수 있으나 한 번에 하나의 위치에서만 파일을 쓸 수 있는지 확인해야 합니다. 이 릴리스에서는 Amazon FSx File Gateway가 충돌을 일으키는 방식으로 여러 위치의 쓰기를 겹치는 것을 방지하지 않습니다.

FSx for Windows File Server가 제공하는 모든 도구를 사용하는 원격 관리 인터페이스를 통해 Amazon FSx for Windows File Server를 관리할 수 있습니다.

예. 모든 파일 시스템이 동일한 Active Directory 도메인의 구성 요소이면 최대 5개의 파일 시스템에서 공유에 게이트웨이를 연결할 수 있습니다. Amazon FSx File Gateway는 단일 Active Directory 도메인에만 연결할 수 있습니다.

Amazon FSx File Gateway 소프트웨어가 포함된 가상 머신을 VMware ESXi, Microsoft Hyper-V 또는 Linux KVM에 배포하거나 Storage Gateway를 하드웨어 어플라이언스로 배포할 수 있습니다.

Amazon FSx File Gateway는 인프라가 AWS Directory Service에 호스팅되거나 또는 온프레미스로 관리되는 경우에도 Active Directory의 구성 요소가 됩니다. Amazon FSx File Gateway가 도메인의 구성 요소가 되면 보안을 강화하기 위해 해당 도메인에 설정된 모든 사용자 및 정책에 액세스할 수 있습니다. 그리고 Amazon FSx File Gateway는 모든 Windows Server와 동일하게 작동하며 Active Directory에 구성된 내용에 따라 모든 해당 파일 액세스 정책을 적용합니다. 

Amazon FSx File Gateway는 네이티브 Windows Access Controls을 사용하며 Microsoft Windows에서 작동하는 기존 정적 액세스 목록과 호환됩니다. ACL의 최대 크기는 64KB 또는 대략 1820 Access Control Entries입니다. 이는 Windows Server 호스트와 동일합니다. 액세스 제어는 FSx Windows File Server에서 설정 및 저장되므로 따라서 한 번만 만들면 연결된 모든 파일 게이트웨이에 반영됩니다.

예. Amazon FSx File Gateway는 최대 최신 SMB v3.1.1 사양까지, AES 128 CCM 및 AES 128 GCM을 포함하는 SMB 암호화를 지원합니다. 호환되는 클라이언트는 암호화를 사용해 자동으로 연결됩니다. 추가적으로 Amazon FSx 파일 게이트웨이는 AWS 내 FSx for Windows File Server와 통신할 때 SMB 암호화를 사용합니다. VPN 또는 AWS에 대한 Direct Connect 링크를 구성하고, SMB 트래픽 및 관리 트래픽을 AWS로 전달하도록 적절한 정책을 설정해야 합니다.

Amazon S3 File Gateway처럼, Amazon FSx File Gateway는 VMware 모니터링 서비스에 연결된 게이트웨이 작동에 대해 일련의 지속적인 상태 확인을 실행하여 고가용성을 달성합니다. 하드웨어, 소프트웨어 또는 네트워크 장애 시 VMware는 호스트가 여전히 작동 중인 경우 새 호스트 또는 기존 호스트에서 게이트웨이 재시작을 트리거합니다. 사용자와 애플리케이션은 다시 시작하는 동안 최대 60초의 가동 중단을 경험합니다. 재시작 후에는 게이트웨이에 대한 연결이 자동으로 다시 설정되므로 수동 개입이 필요가 없습니다. 다시 초기화하면 게이트웨이는 지표를 다시 클라우드로 보내 고객이 가용성 이벤트를 전체적으로 볼 수 있게 합니다. 

VMware HA를 사용하고 애플리케이션 모니터링을 구성한 Amazon FSx File Gateway는 하드웨어 장애, 하이퍼바이저 장애, 네트워크 장애 및 연결 시간 초과 또는 파일 공유 이용 불가를 초래하는 소프트웨어 문제를 감지하고 복구합니다. 

Amazon FSx File Gateway는 단일 인스턴스 구성 내 Amazon FSx File Gateway 인스턴스에 연결된 최대 50개의 공유 및 500개의 액티브 클라이언트 세션을 지원합니다.

S3 Glacier Deep Archive와 함께 테이프 게이트웨이를 사용하여 AWS에 가상 테이프를 저장하는 경우 물리적 테이프를 오프사이트에 보관하는 것과 비교하여 11 9의 데이터 내구성, 정기적인 AWS의 고정성 검사, 데이터 암호화, 복원시 올바른 데이터 및 비용 절감 효과를 얻을 수 있습니다. 우선 S3 Glacier Deep Archive에 저장된 모든 가상 테이프는 지리적으로 분산되어 있는 적어도 3개의 가용 영역에 복제 및 저장되며 11 9의 내구성으로 보호됩니다. 둘째, AWS는 정기적인 고정 검사를 수행하여 데이터를 읽을 수 있고 오류가 없는지 확인할 수 있습니다. 셋째, S3 Glacier Deep Archive에 저장된 모든 테이프는 기본 키 또는 KMS 키를 사용하여 S3 서버 측 암호화에 의해 보호됩니다. 또한, 테이프 이식성과 관련된 물리적 보안 위험을 피할 수 있습니다. 넷째, 테이프 게이트웨이를 사용하여 복원 중에 올바르지 않거나 망가진 테이프를 받을 수 있는 테이프를 오프사이트에 저장하는 경험과 비교할 때 항상 올바른 데이터를 얻을 수 있습니다. 마지막으로, 테이프 오프사이트 저장과 비교하여 S3 Glacier Deep Archive에 데이터를 저장할 때 월간 스토리지 비용을 절약할 수 있습니다.

Tape Gateway는 S3 Standard, S3 Glacier 및 S3 Glacier Deep Archive 스토리지 클래스를 지원합니다. 백업 애플리케이션이 데이터를 테이프에 기록할 때 가상 테이프의 데이터는 Amazon S3의 가상 테이프 라이브러리에 저장됩니다. 백업 애플리케이션에서 테이프를 꺼내면 테이프가 S3 Glacier 또는 S3 Glacier Deep Archive에 아카이브됩니다.

Tape Gateway에서 만들 수 있는 가상 테이프의 최소 크기와 최대 크기는 각각 100GiB와 15TiB입니다. 테이프의 크기가 아니라 각 테이프에 저장된 데이터 양에 대한 비용을 지불한다는 점에 유의하십시오.

하나의 Tape Gateway가 VTL에서 최대 1,500개의 가상 테이프를 보관할 수 있으며 최대 집계 용량은 1PB입니다. 하지만 아카이브할 수 있는 데이터 양 또는 가상 테이프 수에는 제한이 없습니다. 또한, Tape Gateway를 추가로 배포하여 아카이브되지 않은 가상 테이프용 스토리지를 확장할 수 있습니다. 자세한 내용은 Storage Gateway 한도 설명서를 확인하세요.

아카이브할 수 있는 양, 크기 또는 가상 테이프에 대한 제한은 없습니다.

S3 Glacier 또는 S3 Glacier Deep Archive에서 아카이브된 가상 테이프를 S3로 검색할 수 있습니다. S3 Glacier에 아카이브된 테이프는 일반적으로 3-5시간 내에 표준 검색 방법을 사용하여 S3로 검색됩니다. S3 Glacier Deep Archive에 아카이브된 테이프는 일반적으로 12시간 이내에 표준 검색 방법을 사용하여 S3로 검색됩니다.

데이터를 포함하고 있는 가상 테이프는 먼저 가상 테이프 라이브러리에 저장해야 액세스할 수 있습니다. 가상 테이프 라이브러리에 있는 가상 테이프에는 즉시 액세스할 수 있습니다. 데이터를 포함하고 있는 가상 테이프가 아카이브된 경우 AWS Management Console 또는 API를 사용해 가상 테이프를 검색할 수 있습니다. 먼저 가상 테이프를 선택한 다음 가상 테이프를 로드할 가상 테이프 라이브러리를 선택합니다. S3 Glacier 및 S3 Glacier Deep Archive에 보관된 테이프는 일반적으로 각각 3~5시간 이내와 12시간 이내에 S3로 가져올 수 있습니다. 가상 테이프를 가상 테이프 라이브러리에서 사용할 수 있게 되면 백업 애플리케이션에서 가상 테이프를 사용해 데이터를 복원할 수 있습니다.

아니요. Amazon S3 또는 Amazon S3 Glacier API를 통해서는 가상 테이프 데이터에 액세스할 수 없습니다. 하지만 Tape Gateway API를 사용하면 가상 테이프 라이브러리 및 가상 테이프 쉘프를 관리할 수 있습니다.

Storage Gateway 콘솔 또는 API를 통해 새 테이프를 생성 시 아카이브 저장 대상을 S3 Glacier Deep Archive로 설정할 수 있습니다. 백업 소프트웨어가 테이프를 배출하면 S3 Glacier Deep Archive에 아카이브됩니다. S3 Glacier Deep Archive에 아카이브된 가상 테이프는 일반적으로 12시간 이내에 표준 검색 방법을 사용하여 S3로 검색할 수 있습니다.

예. 테이프 게이트웨이에서는 S3 Glacier의 테이프를 S3 Glacier Deep Archive로 이동할 수 있습니다. AWS Storage Gateway Console 또는 API를 사용하여 Glacier Pool에 위치한 테이프를 Deep Archive Pool에 할당할 수 있습니다. 그런 다음 Tape Gateway는 가상 테이프를 S3 Glacier Deep Archive 스토리지 클래스와 연관된 Deep Archive Pool로 이동합니다. S3 Glacier에서 S3 Glacier Deep Archive로 테이프를 이동할 때 테이프 이동 비용이 부과되며, 해당하는 경우 S3 Glacier에서 S3 Glacier Deep Archive로 90일 이전에 테이프를 이동하면 S3 Glacier에 대한 초기 삭제 요금이 부과됩니다.

아니요, S3 Glacier Deep Archive에서 S3 Glacier로 테이프를 이동할 수는 없습니다. S3 Glacier Deep Archive에서 S3으로 테이프를 가져오거나 S3 Glacier Deep Archive의 테이프를 삭제할 수 있습니다.

VTL 인터페이스는 업계 표준 iSCSI 기반 테이프 라이브러리 인터페이스를 사용하는 백업 및 아카이브 애플리케이션과 호환됩니다. 지원되는 백업 애플리케이션의 전체 목록은 Storage Gateway 개요 페이지를 참조하세요.

게이트웨이와 AWS 스토리지 간에 전송되는 모든 데이터는 SSL을 사용해 암호화됩니다. 기본적으로 Tape Gateway에서 S3에 저장하는 모든 데이터는 Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측에서 암호화됩니다.

선택 사항으로 Storage Gateway API를 통해 AWS KMS 관리형 키를 사용하여 테이프를 암호화하도록 구성할 수 있습니다. 관리형 고객 마스터 키(CMK) 중 하나를 KMS 키로 지정할 수 있습니다. 테이프를 암호화하는 데 사용하도록 구성된 CMK는 생성 후에는 변경할 수 없습니다. 자세히 알아보려면 Storage Gateway 사용 설명서에서 기능 사용에 대한 중요한 세부 정보가 포함된 ‘AWS Key Management System을 사용한 데이터 암호화’ 섹션을 참조하세요.

각 Volume Gateway는 최대 32개의 볼륨을 지원할 수 있습니다. 캐싱 모드에서 각 볼륨 크기는 최대 32TB이며 게이트웨이당 데이터 크기는 최대 1PB입니다(각 32TB의 볼륨 32개). 저장 모드에서 각 볼륨 크기는 최대 16TB이며 게이트웨이당 데이터 크기는 최대 512TB입니다(32개 볼륨, 각 16TB). 자세한 내용은 Storage Gateway 한도 설명서를 참조하세요.

볼륨 게이트웨이는 데이터가 AWS로 전송되기 전에 그리고 AWS에 저장되어 있는 동안 데이터를 압축합니다. 이러한 압축을 통해 데이터 전송 및 스토리지 비용을 절감할 수 있습니다. 볼륨 스토리지는 사전에 프로비저닝되지 않습니다. 생성한 볼륨 크기가 아니라 볼륨에 저장된 데이터 양에 대한 요금만 청구됩니다.

볼륨이 AWS Storage Gateway 서비스에서 관리하는 Amazon S3 버킷에 저장되어 있습니다. AWS Storage Gateway를 통해 I/O 작업을 위해 볼륨에 액세스할 수 있습니다. 고객이 Amazon S3 API 작업을 통해 직접 볼륨에 액세스할 수는 없습니다. Amazon EBS 스냅샷 형식으로 제공되는 게이트웨이 볼륨의 특정 시점 스냅샷을 생성할 수 있고, 이는 Storage Gateway 볼륨 또는 EBS 볼륨으로 전환될 수 있습니다. 파일 게이트웨이를 사용하면 S3에서 기본적으로 데이터를 작업할 수 있습니다.

게이트웨이와 AWS 스토리지 간에 전송되는 모든 데이터는 SSL을 사용해 암호화됩니다. 기본적으로 Volume Gateway에서 S3에 저장하는 모든 데이터는 Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측에서 암호화됩니다.

선택 사항으로 Storage Gateway API를 통해 AWS KMS 관리형 키를 사용하여 AWS의 볼륨에 저장된 데이터에 대해 암호화를 구성할 수도 있습니다. 관리형 고객 마스터 키(CMK) 중 하나를 KMS 키로 지정할 수 있습니다. 볼륨을 암호화하는 데 사용하도록 구성된 CMK는 생성 후에는 변경할 수 없습니다. 자세히 알아보려면 Storage Gateway 사용 설명서에서 기능 사용에 대한 중요한 세부 정보가 포함된 ‘AWS Key Management System을 사용한 데이터 암호화’ 섹션을 참조하세요.

예. API를 사용하여 AWS KMS로 암호화된 볼륨에서 EBS 스냅샷을 생성할 수 있습니다. EBS 스냅샷은 볼륨 암호화에 사용된 것과 동일한 키로 암호화됩니다.

예. API를 사용하여 KMS로 암호화된 EBS 스냅샷에서 암호화된 볼륨을 생성할 수 있습니다. 암호화된 볼륨에는 EBS 스냅샷을 암호화하는 데 사용된 것과 동일한 키를 사용하거나 볼륨 암호화용으로 다른 암호화 키를 지정할 수 있습니다.

Amazon EBS 스냅샷 형식으로 Volume Gateway 볼륨의 특정 시점 스냅샷을 생성할 수 있습니다. 볼륨의 스냅샷을 새 Amazon EBS 볼륨의 기반으로 사용할 수 있으며 그런 다음 Amazon EC2 인스턴스에 연결할 수 있습니다. 이 접근 방식을 사용하면 데이터 처리를 위한 온디맨드 컴퓨팅 파워가 더 필요하거나 재해 복구 목적으로 교체 용량이 필요한 경우, 데이터를 온프레미스 애플리케이션에서 Amazon EC2에서 실행 중인 애플리케이션으로 손쉽게 공급할 수 있습니다.

볼륨 데이터가 이미 Amazon S3에 저장되어 있는 캐싱 볼륨의 경우, 스냅샷을 사용하여 데이터 버전을 보존할 수 있습니다. 이 접근 방식을 사용하면 필요할 때 이전 버전으로 되돌리거나 특정 시점 버전을 새 볼륨으로 사용하도록 용도를 재설정할 수 있습니다. 임의 또는 예약된 일정에 따라 스냅샷을 시작할 수 있습니다. 새 스냅샷을 만들 때 마지막 스냅샷 이후에 변경된 데이터만 저장됩니다. 100GB의 데이터 볼륨이 있지만 마지막 스냅샷 이후 5GB의 데이터만 변경된 경우, Amazon S3에는 5GB의 추가 스냅샷 데이터만 저장됩니다. 스냅샷을 삭제하면 다른 스냅샷이 필요하지 않은 데이터만 제거됩니다.

볼륨 데이터가 온프레미스에 저장되는 저장 볼륨의 경우, 스냅샷이 Amazon S3에 안정적인 오프사이트 백업을 제공합니다. 백업을 복구해야 하는 경우 스냅샷에서 새 볼륨을 생성할 수 있습니다. 또한, Amazon EC2 인스턴스에 연결할 수 있는 새 Amazon EBS 볼륨의 기반으로 볼륨의 스냅샷을 사용할 수 있습니다.

스냅샷은 스냅샷이 요청된 시점의 특정 시점 볼륨 사본을 나타냅니다. 스냅샷에는 새 볼륨으로 데이터(스냅샷 생성 시점)를 복원하는 데 필요한 모든 정보가 들어 있습니다. 스냅샷을 생성하기 전에 애플리케이션에서 볼륨에 작성했지만 아직 AWS로 업로드되지 않은 데이터가 스냅샷에 포함됩니다.

실제로는 스냅샷에 즉시 ID가 지정되고 AWS Management Console과 AWS Command Line Interface(AWS CLI)에서 볼 수 있지만, 초기에는 PENDING 상태로 표시됩니다. 스냅샷 요청 전에 볼륨에 작성된 모든 데이터가 게이트웨이에서 EBS로 업로드되면 AVAILABLE로 상태가 변경됩니다. 그러면 스냅샷을 새 게이트웨이 또는 EBS 볼륨의 기반으로 사용할 수 있습니다.

각 스냅샷에는 AWS Management Console에서 확인할 수 있는 고유 식별자가 부여됩니다. 이 고유 식별자를 지정해 기존의 모든 스냅샷을 기반으로 AWS Storage Gateway 또는 Amazon EBS 볼륨을 생성할 수 있습니다.

AWS Management Console을 사용하여 Amazon S3에 저장한 스냅샷에서 새 볼륨을 생성할 수 있습니다. 그런 다음 이 볼륨을 온프레미스 애플리케이션 서버에 iSCSI 디바이스로 탑재할 수 있습니다.

캐싱 볼륨이 기본 데이터를 Amazon S3에 저장하므로, 스냅샷에서 새 볼륨을 생성할 때 게이트웨이는 스냅샷 데이터를 Amazon S3에 보관하며 이 데이터가 새 볼륨의 기본 데이터가 됩니다.

저장 볼륨이 기본 데이터를 로컬에 저장하므로, 스냅샷에서 새 볼륨을 생성할 때 게이트웨이는 스냅샷 내에 포함된 데이터를 로컬 하드웨어로 다운로드합니다. 이 데이터는 새 볼륨의 기본 데이터가 됩니다.

아니요. 볼륨을 탑재 해제하지 않고 스냅샷을 만들 수 있으며 애플리케이션의 성능에 영향을 주지 않습니다. 그러나 스냅샷은 AWS Storage Gateway 볼륨에 기록된 데이터만 캡처할 수 있으므로 사용자의 애플리케이션 또는 OS를 사용해 로컬로 버퍼링한 데이터는 제외될 수 있습니다.

예. 각 볼륨에 대해 스냅샷 일정을 예약할 수 있습니다. 매일 스냅샷이 생성되는 시간과 간격(1, 2, 4, 8, 12 또는 24시간마다)을 변경할 수 있습니다.

스냅샷 완료에 걸리는 시간은 주로 볼륨의 크기 및 AWS에 연결하는 인터넷 속도에 따라 다릅니다. AWS Storage Gateway는 업로드하기 전에 모든 데이터를 압축하여 스냅샷 생성 시간을 줄입니다.

아니요. 스냅샷은 AWS Storage Gateway와 Amazon EBS에서만 액세스할 수 있으며, Amazon S3 API를 사용하여 직접 액세스할 수 없습니다.

단일 게이트웨이가 생성할 수 있는 스냅샷 수 또는 스냅샷 데이터 양에는 제한이 없습니다.

AWS Backup을 사용하여 Volume Gateway 볼륨을 백업하면 백업 관리가 간소화되고 중앙 집중화되므로, 운영 부담이 줄고 모든 AWS 리소스에 걸쳐 규정 준수 요구 사항을 더 쉽게 충족할 수 있습니다. AWS Backup을 사용하면 백업 요구 사항에 맞춰 사용자 지정 가능한 예약 백업 정책을 설정할 수 있습니다. AWS Backup을 사용하면 백업 보존 및 만료 규칙을 설정할 수 있으므로, 더 이상 사용자 지정 스크립트를 개발하거나 볼륨 게이트웨이 볼륨의 특정 시점 백업을 수동으로 관리할 필요가 없습니다. 마지막으로 여러 볼륨 게이트웨이 및 다른 AWS 리소스(EBS 볼륨, RDS 데이터베이스 등)의 백업을 중앙 집중식으로 관리하고 모니터링할 수 있습니다.

AWS Backup을 사용하여 일회성 백업을 수행하거나 Volume Gateway 볼륨의 백업 일정을 정의할 수 있습니다. 볼륨 백업은 Amazon S3에 Amazon EBS 스냅샷으로 저장되며 AWS Backup 콘솔 또는 Amazon EBS 콘솔에서 확인할 수 있습니다. AWS Backup으로 생성된 볼륨 백업은 AWS Backup 콘솔에서 수동 또는 자동으로 삭제할 수 있습니다.

Storage Gateway 콘솔 또는 AWS Backup 콘솔에서 시작하여 백업을 관리할 수 있습니다. Storage Gateway 콘솔에서 시작하면 AWS Backup 콘솔로 이동하여 백업 계획 구성을 완료하거나 온디맨드 백업을 시작할 수 있습니다. 또는 AWS Backup 콘솔에서 시작하여 볼륨 게이트웨이 볼륨의 백업 계획을 구성하거나 온디맨드 백업을 시작할 수 있습니다.

아니요. 모든 기존의 볼륨 게이트웨이 스냅샷 기능과 기존의 Amazon EBS 스냅샷은 그대로 유지되며 변경되지 않습니다. 계속 Storage Gateway 콘솔을 사용하여 EBS 스냅샷에서 볼륨을 생성하고 Amazon EBS 콘솔을 사용하여 스냅샷을 보거나 삭제할 수 있습니다.

예. 계속 볼륨 게이트웨이의 기존 스냅샷 기능을 사용하여 Amazon EBS 스냅샷을 생성하고 복원 목적으로 이전에 생성된 스냅샷을 사용할 수 있습니다. AWS Backup의 백업 일정은 Volume Gateway 예약 스냅샷과 독립적으로 작동하며 모든 백업 및 보존 정책을 중앙에서 관리할 수 있는 추가적인 방법을 제공합니다.

예. AWS Backup은 볼륨 암호화에 사용된 것과 동일한 키를 사용하여 Volume Gateway의 KMS 암호화된 볼륨을 백업합니다.

AWS Backup은 AWS Backup이 작동하는 동일한 리전 내에서 Volume Gateway 볼륨의 백업을 지원합니다.

AWS Storage Gateway는 하드웨어 어플라이언스로 제공됩니다. 즉, 검증된 서버 구성으로 Storage Gateway 소프트웨어가 미리 설치되어 있습니다. AWS Console에서 어플라이언스를 관리합니다.

하드웨어 어플라이언스는 NFS 및 SMB 인터페이스를 통해 Amazon S3 File Gateway를, SMB를 통해 Amazon FSx File Gateway를, iSCSI를 통해 Volume Gateway 캐시 볼륨을, iSCSI-VTL를 통해 Tape Gateway를 지원합니다.

하드웨어 어플라이언스는 기존 가상 서버 인프라, 적절한 디스크 및 메모리 리소스 또는 하이퍼바이저 관리 기술을 갖춘 직원이 부족한 원격 사무실 및 부서와 같은 IT 환경을 위한 AWS Storage Gateway 온프레미스의 배포 및 관리를 더욱 간소화합니다. 따라서 로컬 Storage Gateway VM 어플라이언스를 운영하기 위해 가상 환경에 필요한 추가 인프라를 조달할 필요가 없습니다.

5TB 또는 12TB의 로컬 SSD 캐시를 제공하는 두 가지 모델이 있습니다.

하드웨어 어플라이언스는 검증된 서버 구성에 기반합니다. 사양은 Storage Gateway Hardware Appliance 제품 페이지를 참조하세요.

하드웨어 어플라이언스는 미국 동부(북부 버지니아, 오하이오), 미국 서부(캘리포니아 북부, 오레곤), 캐나다(중부), 남아메리카(상파울루), EU(아일랜드, 프랑크푸르트, 런던, 파리, 스톡홀름), 및 아시아 태평양(뭄바이, 서울, 싱가포르, 시드니, 도쿄)를 포함한 16개 AWS 리전에서 지원됩니다.

로컬 하드웨어 어플라이언스 콘솔을 통해 IP 주소를 구성하고 AWS Storage Gateway 콘솔에서 이 IP 주소를 사용하여 어플라이언스를 활성화합니다. 이렇게 하면 하드웨어 어플라이언스가 AWS 계정에 연결됩니다. 하드웨어 어플라이언스가 활성화되면 하드웨어 어플라이언스에서 실행할 게이트웨이 유형을 생성합니다. 그러면 선택된 게이트웨이 유형이 어플라이언스에서 활성화됩니다. 가상 어플라이언스와 마찬가지로 AWS Console에서 Storage Gateway 하드웨어 어플라이언스를 관리하고 사용할 수 있습니다. 자세한 내용은 하드웨어 어플라이언스 설명서를 참조하세요.

아니요. 하드웨어 어플라이언스에서는 한 번에 하나의 게이트웨이만 실행할 수 있습니다.

예. 게이트웨이가 하드웨어 어플라이언스에 설치된 후에 유형을 변경하려면, Storage Gateway 콘솔에서 게이트웨이 제거를 선택하면 됩니다. 그러면 게이트웨이와 모든 관련 리소스가 삭제됩니다. 이때 하드웨어 어플라이언스에서 새로운 게이트웨이를 시작할 수 있습니다.

5TB 모델 어플라이언스에 SSD 5개를 추가하는 방법으로 스토리지를 추가하여 로컬 캐시의 가용 용량을 12TB까지 늘릴 수 있습니다. 어플라이언스를 이미 활성화하고 AWS 계정과 연결한 경우, 더 많은 스토리지를 추가하기 전에 어플라이언스를 출하 시 설정으로 초기화해야 합니다.

아니요. 어플라이언스 제조사에서 제공하는 SSD만 추가하세요. 이러한 SSD는 Storage Gateway 하드웨어 어플라이언스로 사용할 수 있도록 인증을 받았습니다.

예. 하드웨어 어플라이언스는 소프트웨어 기반 ZFS RAID를 사용하며 스토리지 드라이브 장애로부터 보호합니다. 5TB 모델은 SSD 장애 1개를 허용하고 12TB 모델은 SSD 장애를 최대 2개까지 허용합니다.

Storage Gateway는 VMware 모니터링 서비스에 연결된 게이트웨이 작동에 대해 일련의 지속적인 상태 점검을 실행하여 고가용성을 달성합니다. 하드웨어, 소프트웨어 또는 네트워크 장애 시 VMware는 호스트가 여전히 작동 중인 경우 새 호스트 또는 기존 호스트에서 게이트웨이 재시작을 트리거합니다. 사용자와 애플리케이션은 다시 시작하는 동안 최대 60초의 가동 중단을 경험합니다. 재시작 후에는 게이트웨이에 대한 연결이 자동으로 다시 설정되므로 수동 개입이 필요가 없습니다. 다시 초기화하면 게이트웨이는 지표를 다시 클라우드로 보내 고객이 가용성 이벤트를 전체적으로 볼 수 있게 합니다.

현재 Storage Gateway 고가용성은 VMware HA를 사용하고 공유 볼륨 스토리지를 사용할 수 있는 클러스터링된 VMware vSphere 환경에서 사용할 수 있습니다.

고가용성 통합이 활성화된 상태에서 Storage Gateway를 실행하는 데 드는 추가 비용은 없습니다.

VMware HA를 사용하고 애플리케이션 모니터링을 구성한 Storage Gateway는 하드웨어 장애, 하이퍼바이저 장애, 네트워크 장애 및 연결 시간 초과 또는 파일 공유, 볼륨 또는 가상 테이프 라이브러리를 이용 불가를 초래하는 소프트웨어 문제를 감지하고 복구합니다.

예.

File Gateway에 연결하는 NFS 클라이언트는 게이트웨이가 다시 시작되는 동안 읽기 또는 쓰기 작업에서 최대 60초 동안 중단을 경험할 수 있으며 고객이 권장 탑재 설정을 사용하는 경우, 이후에 연결이 재시도됩니다. SMB 클라이언트는 클라이언트 설정에 따라 다시 시작하는 동안 파일 읽기 또는 쓰기를 거부할 수 있습니다. 게이트웨이를 재시작하는 동안 볼륨 게이트웨이 및 테이프 게이트웨이에 대한 모든 iSCSI 읽기 및 쓰기가 정지된 다음, 자동으로 재시도됩니다.

예. 게이트웨이는 동일한 기본 공유 스토리지를 사용하여 다시 초기화되어 로컬 캐시 및 업로드 대기열을 유지합니다.

아니요. 게이트웨이는 동일한 기본 공유 스토리지를 사용하여 다시 초기화되어 로컬 캐시 및 업로드 대기열을 유지합니다.

VMware HA가 활성화된 상태에서 게이트웨이가 VMware에 배포된 경우 VMware vSphere 관리 센터에서 Storage Gateway VM의 재시작 민감도를 구성할 수 있습니다. Storage Gateway VM 하트비트를 사용하면 특정 제한 시간 초과 시 게이트웨이를 자동으로 다시 시작할 수 있습니다.

VMware HA는 스토리지 및 네트워킹과 같은 기본 인프라를 모니터링합니다. Storage Gateway는 파일 시스템 가용성, SMB 엔드포인트 가용성과 게이트웨이의 모든 중요 작업을 모니터링하는 NFS 엔드포인트 가용성과 같은 다양한 상태 확인을 제공하여 사용자와 애플리케이션이 기본 인프라뿐만 아니라 전체 인프라를 지속적으로 사용할 수 있도록 합니다.

예. 추가 요구 사항 없이 VMware Cloud에서 Storage Gateway 고가용성을 사용할 수 있습니다. VMware Cloud on AWS에는 기본적으로 VMware HA가 활성화되어 있으며 공유 볼륨을 사용할 수 있습니다.

새로운 VMware용 게이트웨이를 설정할 때 HA 테스트 옵션이 제공됩니다. 콘솔에서 "Test VMware HA" 작업을 선택하여 배포된 게이트웨이가 HA를 지원하는지 테스트할 수도 있습니다.

AWS Storage Gateway 콘솔은 게이트웨이를 다시 시작하는 동안 로그 테이블에 가용성 이벤트를 표시하고 성능 그래프에 중단 사항을 표시합니다.

예. CloudWatch와의 통합을 구성한 경우 게이트웨이에서 트리거된 가용성 이벤트는 CloudWatch를 통해 확인할 수 있습니다.

CloudWatch와의 통합을 구성한 경우 다시 초기화하면 CloudWatch 이벤트가 트리거됩니다. 또한 성능 그래프에는 활성 세션 수를 포함하여 게이트웨이의 작동 지표가 표시됩니다.

예. 관리자는 vSphere 콘솔에서 지정된 시간(초) 동안 게이트웨이에 도달할 수 없는 경우 서비스를 다시 시작하는 시간 초과를 설정할 수 있습니다.

모든 게이트웨이 어플라이언스 유형과 AWS 스토리지 간에 전송되는 모든 데이터는 SSL을 사용해 암호화됩니다. 기본적으로 AWS Storage Gateway가 S3에 저장하는 모든 데이터는 Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측에서 암호화됩니다. 또한, Storage Gateway API를 통해 AWS Key Management Service(KMS)를 사용하여, 저장된 데이터를 암호화하도록 각기 다른 게이트웨이 유형을 선택적으로 구성할 수 있습니다. File Gateway, Tape Gateway 및 Volume Gateway별 KMS 지원에 대한 자세한 내용은 아래를 참조하세요.

예. AWS Storage Gateway는 HIPAA 적격 서비스입니다. AWS와 비즈니스 제휴 계약(BAA)을 체결했다면 Storage Gateway를 사용하여 또한 HIPAA 적격 서비스인 Amazon S3, Amazon S3 Glacier, Amazon S3 Glacier Deep Archive, Amazon FSx for Windows File Server 및 Amazon EBS를 비롯한 확장 가능하고 비용 효율적이며 안전한 AWS 스토리지 서비스에 개인 건강 정보(PHI)를 저장, 백업 및 아카이브할 수 있습니다.

AWS의 HIPAA 적격 서비스에 관한 정보는 HIPAA 규정 준수 페이지에서 확인할 수 있습니다. 또한 여기에서 AWS와 BAA를 체결할 수 있습니다. Storage Gateway의 HIPAA 적격성은 모든 게이트웨이 유형(파일, 볼륨 및 테이프)에 적용됩니다.

예. AWS Storage Gateway는 최신 평가를 기준으로 PCI DSS(지불 카드 보안 표준)를 준수합니다. 기존 고객은 AWS Management Console에서 AWS Artifact를 통해 규정 준수 증명(AOC) 및 PCI 책임 요약 보고서를 다운로드할 수 있습니다. 잠재 고객은 AWS 영업 팀을 통해 보고서를 요청할 수 있습니다.

예, AWS Storage Gateway는 AWS GovCloud(미국) 리전에서 High 권한 부여 수준, AWS 미국 상용 리전에서 Moderate 권한 부여 수준으로 FedRAMP 규정을 준수합니다. 자세한 내용은 AWS FedRAMP 규정 준수 페이지를 참조하세요.

A: S3 File Gateway, Amazon FSx File Gateway, Volume Gateway 및 Tape Gateway는 FIPS 140-2 준수 엔드포인트를 지원합니다.

AWS Storage Gateway는 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(캘리포니아 북부), 미국 서부(오레곤), 캐나다(중부), GovCloud(미국 서부) 및 GovCloud (미국 동부) AWS 리전에서 FIPS 140-2 준수 엔드포인트를 지원합니다.

AWS Storage Gateway에 사용 가능한 FIPS 엔드포인트 목록은 AWS Storage Gateway 엔드포인트 참조 안내서 또는 AWS GovCloud(미국) 사용 설명서를 참조하세요.

아니요. AWS Storage Gateway 하드웨어 어플라이언스는 FIPS 140-2를 준수하지 않습니다.

예. File Gateway 감사 로그를 사용하여 SMB 파일 공유 내의 폴더 및 파일에 대한 클라이언트 작업을 모니터링할 수 있습니다.

각 SMB 공유의 공유 수준에서 폴더 및 파일에 대한 사용자 작업을 모니터링하도록 File Gateway 감사 로그를 구성할 수 있습니다.

File Gateway 감사 로그는 SMB 공유를 지원합니다.

파일 및 디렉토리에 대해 기록된 작업(열기, 삭제, 읽기, 쓰기, 이름 변경, 권한 변경 및 파일 작업 성공)에 대한 세부 정보를 볼 수 있습니다. 타임스탬프, Active Directory 도메인, 사용자 이름 및 클라이언트 IP 주소를 비롯한 각 작업에 대한 사용자 정보도 기록됩니다.

Amazon CloudWatch에서 File Gateway 감사 로그에 액세스할 수 있습니다. 감사 로그는 CloudWatch에서 원하는 Amazon S3 버킷으로 보낼 수도 있습니다. 감사 로그는 Amazon Athena를 사용하여 Amazon S3에서 볼 수 있으며, 분석을 위해 타사 보안 정보 및 이벤트 관리 애플리케이션(SIEM)으로 내보낼 수도 있습니다.

예. Tape Gateway에서 새 가상 테이프를 수동으로 생성하거나 자동 테이프 생성 구성을 사용하는 경우 WORM 테이프 유형을 선택할 수 있습니다. WORM 가상 테이프의 데이터는 의도적으로든 실수로든 백업 애플리케이션에서 삭제할 수 없습니다. 또한 테이프 게이트웨이의 테이프 보존 잠금 기능은 아카이브된 가상 테이프가 일정 시간 동안 또는 무기한으로 삭제되는 것을 방지합니다.

예. AWS Direct Connect를 사용하여 온프레미스 게이트웨이와 AWS 간에 전용 네트워크 연결을 설정함으로써 처리량을 높이고, 네트워크 비용을 줄일 수 있습니다. AWS Storage Gateway는 인터넷 대역폭을 효율적으로 사용해 온프레미스 애플리케이션 데이터를 AWS로 업로드하는 속도를 개선합니다.

예. Volume Gateway와 Tape Gateway는 온프레미스 게이트웨이와 AWS 간 SOCKS5(Socket Secure 버전 5) 프록시 구성을 지원합니다. 파일 게이트웨이는 HTTP(HyperText Transfer Protocol) 프록시 구성을 지원합니다.

예. Storage Gateway를 라우팅이 불가능한 프라이빗 네트워크에 배포할 수 있습니다. 단, 이 경우 네트워크가 DX 또는 VPN을 통해 Amazon VPC에 연결되어 있어야 합니다. Storage Gateway 트래픽은 AWS PrivateLink를 통해 구동되는 VPC 종단점을 통해 라우팅됩니다. AWS PrivateLink는 Elastic Network Interface(ENI)를 사용하는 AWS 서비스와 VPC 내 프라이빗 IP 간의 프라이빗 연결을 지원하는 기술입니다. PrivateLink에 대해 자세히 알아보려면 PrivateLink 설명서를 참조하세요. Storage Gateway에 대해 AWS PrivateLink를 설정하려면 Storage Gateway용 AWS PrivateLink 설명서를 참조하세요.

예. 이 서비스는 모든 게이트웨이 유형(파일/볼륨/테이프)에 대해 PrivateLink를 지원합니다.

VPC 종단점이 프로비저닝되어 있는 동안 시간당 요금이 청구됩니다. 또한 데이터 처리 요금은 트래픽 소스나 대상과 관계없이 VPC 엔드포인트를 통해 처리된 각 기가바이트에 적용됩니다.

PrivateLink 사용 게이트웨이는 AWS 콘솔을 통해 활성화할 수 있습니다. 단, 이 경우 웹 브라우저가 인터넷과 프라이빗 네트워크에 모두 액세스할 수 있거나, 게이트웨이의 기반이 되는 리전의 CLI를 통해 액세스할 수 있어야 합니다.

온프레미스 File Gateway를 PrivateLink 및 프라이빗 가상 인터페이스(VIF)와 함께 사용하여 Amazon S3 버킷에 액세스하려면 Amazon EC2 기반 프록시 서버를 설정해야 합니다. 프라이빗 네트워크를 통해 Amazon S3에 액세스하려면 S3의 게이트웨이 엔드포인트를 사용해야 합니다. 이러한 엔드포인트는 온프레미스 환경에서는 직접 액세스할 수 없습니다. 프록시 서버는 S3용 VPC 종단점을 통한 액세스를 제공하여 온프레미스 파일 게이트웨이에서 액세스할 수 있도록 합니다. 네트워크 대역폭에 최적화된 EC2 인스턴스 패밀리를 사용하는 것이 좋습니다.

아니요.

Volume Gateway와 Tape Gateway는 S3에 대한 프록시 없이도 Storage Gateway VPC 엔드포인트를 통해 AWS 서비스에 직접 연결합니다.

제대로 작동하려면 하드웨어 어플라이언스 네트워크 인터페이스에서 AWS 퍼블릭 엔드포인트와 통신할 수 있어야 합니다. 하지만 PrivateLink를 사용하고 VPC 엔드포인트와만 통신하도록 게이트웨이 VM 가상 인터페이스를 구성할 수 있습니다.

AWS Storage Gateway는 애플리케이션과 Amazon 스토리지 서비스 사이에 있습니다. 경험하는 성능은 Storage Gateway 소프트웨어를 실행하기 위해 사용하는 호스트 플랫폼(하드웨어 어플라이언스, 가상 머신, Amazon EC2 인스턴스)과 다른 몇 가지 요소에 따라 달라집니다. 이러한 요소에는 iSCSI 이니시에이터 또는 NFS 클라이언트 및 게이트웨이 간 네트워크 대역폭, 기본 로컬 디스크의 속도 및 구성, VM 구성, 게이트웨이에 할당된 로컬 스토리지 크기, 게이트웨이와 Amazon 스토리지 간 대역폭이 포함됩니다. AWS 기술 설명서는 최고의 성능을 내도록 AWS Storage Gateway 환경을 최적화하는 방법에 대한 지침을 제공합니다.

가상 머신 또는 Amazon EC2 인스턴스에서 AWS Storage Gateway를 실행하는 데 대해서는 AWS Storage Gateway 사용 설명서에서 요구 사항 섹션을 참조하십시오. 또한 AWS Storage Gateway는 사전에 검증된 사양에 따라 하드웨어 어플라이언스로 제공됩니다.

Volume Gateway와 Tape Gateway는 전송 데이터와 저장 데이터를 압축하여 데이터 전송 및 스토리지 비용을 모두 절감할 수 있습니다. AWS Storage Gateway는 변경된 데이터만 업로드하므로 인터넷을 통해 전송되는 데이터 양을 최소화할 수 있습니다.

예. 볼륨 및 Tape Gateway의 일정에 따라 데이터를 AWS와 동기화하기 위해 게이트웨이에 사용되는 네트워크 대역폭을 조절할 수 있습니다. 인바운드 및 아웃바운드 트래픽에 대한 요일, 시간 및 대역폭 속도를 지정할 수 있습니다.

Amazon CloudWatch를 사용하여 사용자 게이트웨이의 성능 지표 및 경보를 모니터링할 수 있습니다. 이를 통해 스토리지, 대역폭, 처리량 및 대기 시간에 대한 인사이트를 얻을 수 있습니다. 이러한 지표 및 경보는 CloudWatch에서 직접 액세스할 수 있으며, AWS Storage Gateway 콘솔에 있는 링크를 클릭하면 보고 있는 리소스에 대한 CloudWatch 지표 또는 경보로 바로 이동할 수 있습니다. 자세한 내용은 CloudWatch 세부 정보 및 요금 페이지를 참조하십시오.

CachePercentDirty, CacheHitPercent, CacheFree 및 CachePercentUsed를 비롯한 Amazon CloudWatch 지표를 사용하면 됩니다. AWS Storage Gateway 콘솔에 있는 게이트웨이 세부 정보 탭에서 Monitoring 링크를 클릭하면 지표를 볼 수 있습니다.

CloudBytesUploaded 및 CloudBytesDownloaded를 비롯한 Amazon CloudWatch 지표를 사용하면 됩니다.

AWS Storage Gateway 콘솔에서 새 게이트웨이를 생성할 때 또는 새 게이트웨이를 생성한 후 권장 Amazon CloudWatch 경보를 생성할 수 있습니다. Amazon CloudWatch 콘솔에서도 게이트웨이에 대한 경보를 생성할 수 있습니다.

AWS Storage Gateway는 중요 업데이트와 소프트웨어 패치를 게이트웨이 가상 머신(VM)에 주기적으로 배포합니다. 주간 유지 관리 일정을 설정하여 해당 업데이트가 게이트웨이에 적용되는 시점을 제어할 수 있습니다. 또는 AWS Storage Gateway 콘솔이나 API를 사용하여 업데이트가 제공될 때 수동으로 이를 적용할 수 있습니다. 몇 분 안에 업데이트가 완료됩니다. 자세한 내용은 AWS 설명서에서 게이트웨이 업데이트 관리 섹션을 참조하세요.

AWS Storage Gateway 요금은 스토리지, 요청 및 데이터 전송이라는 3가지 요소에 따라 청구됩니다. 요금에 대한 자세한 내용은 AWS Storage Gateway 요금 페이지를 참조하세요.

File Gateway는 데이터를 Amazon S3에 직접 저장합니다. File Gateway에 의해 저장된 객체와 File Gateway가 보낸 요청에 대한 Amazon S3 요금이 부과됩니다. 자세한 내용은 Amazon S3 요금 페이지를 참조하세요.

AWS에 저장한 볼륨 및 가상 테이프 데이터 양에 대한 요금이 청구됩니다. 이 요금은 일별로 비례 할당되어 계산되며 요금은 리전별로 다릅니다. 프로비저닝된 리소스 크기에 상관없이 실제 사용한 볼륨 또는 가상 테이프 용량만큼만 청구됩니다. 모든 볼륨 및 가상 테이프 데이터는 AWS로 전송되기 전에 게이트웨이에 의해 압축되므로 스토리지 비용이 절감됩니다. 요금에 대한 자세한 내용은 AWS Storage Gateway 요금 페이지를 참조하세요.

Amazon EBS가 Storage Gateway 볼륨에서 생성된 EBS 스냅샷을 저장하고 요금을 청구합니다. 스토리지 비용을 줄이기 위해 새 스냅샷을 생성할 때 마지막 스냅샷 이후에 변경된 데이터만 저장됩니다. 자세한 내용은 Amazon EBS 요금 페이지를 참조하세요.

게이트웨이가 데이터를 AWS에 쓸 때 AWS로 작성된 데이터 1GB당 0.01 USD로 일정한 요금이 부과되며 게이트웨이당 월별 최대 요금은 125 USD입니다. AWS에서 데이터를 읽는 데는 비용이 부과되지 않습니다. 게이트웨이에서는 캐싱, 대역폭 최적화, 압축(볼륨 및 테이프 게이트웨이의 경우)을 수행하므로, AWS로 작성된 데이터 양은 애플리케이션에서 게이트웨이에 작성한 데이터 양보다 적을 수 있습니다. 제공되는 Amazon CloudWatch 지표를 통해 게이트웨이가 AWS에 작성하는 데이터 양을 모니터링하고, 게이트웨이에 대한 대역폭 제한을 설정하여 비용을 관리할 수 있습니다.

S3 Glacier에 아카이브된 가상 테이프를 검색하는 경우 테이프에 저장된 데이터 GB당 0.01 USD로 일정한 요금이 부과됩니다. 예를 들어 100GB가 각각 들어있는 테이프 5개를 검색하는 요금은 5 x 100GB x 0.01 USD = 5.00 USD가 됩니다.

S3 Glacier에 아카이브 되고 3개월 이내 또는 S3 Glacier Deep Archive에 아카이브 되고 6개월 이내에 가상 테이프를 삭제하면 조기 삭제 수수료가 부과됩니다. 가상 테이프를 S3 Glacier에 3개월 이상 저장하거나 S3 Glacier Deep Archive에 6개월 이상 저장한 경우에는 삭제 비용이 부과되지 않습니다.

미국 동부(버지니아 북부) 리전에서는 3개월 이내에 삭제 시 GB당 0.012 USD의 조기 삭제 비용이 비례 할당으로 계산되어 부과됩니다. 예를 들어 1 GB의 데이터가 포함된 가상 테이프 1개를 S3 Glacier에서 아카이빙한 지 1개월 후에 삭제하는 경우 0.008 USD의 조기 삭제 비용이 부과됩니다. 만약 같은 가상 테이프를 2개월 후에 삭제한다면 조기 삭제 비용으로 0.004 USD가 부과됩니다.

S3 Glacier Deep Archive에 저장된 가상 테이프에는 S3 Glacier Deep Archive 스토리지 클래스 요금이 부과됩니다. Storage Gateway 요금 웹 페이지에서 Tape Gateway 요금을 확인할 수 있습니다.

Deep Archive Pool에 저장하는 가상 테이프의 사용량과 비용은 AWS Storage Gateway 및 비용과 별도로 AWS Storage Gateway Deep Archive의 월별 AWS 청구서에 독립 서비스 라인 항목으로 표시됩니다. 하지만 AWS 비용 관리 도구를 사용하는 경우 Deep Archive Pool에 저장하는 가상 테이프의 사용량과 비용은 AWS Storage Gateway의 월별 세부 사용 보고서에 포함되며 별도의 서비스 라인 항목으로 분리되지 않습니다.

AWS 미국 동부(버지니아 북부) 지역의 경우 S3 Glacier에 아카이브된 가상 테이프를 S3 Glacier Deep Archive로 이동할 때 테이프에 저장된 데이터의 GB당 0.032 USD의 요금이 부과됩니다. 예를 들어 S3 Glacier에 아카이브된 100GB 테이프를 S3 Glacier Deep Archive로 이동하려면 100GB x 0.032 USD/GB = 3.2 USD가 필요합니다. S3 Glacier에서 90일 미만으로 아카이브된 테이프를 S3 Glacier Deep Archive로 이동하면 S3 Glacier의 테이프 스토리지에 대한 초기 삭제 비용도 부과됩니다.

AWS에서 게이트웨이로 다운로드한 GB 단위의 인터넷 데이터 전송량에 따라 청구됩니다. AWS 업로드가 목적인 데이터 전송은 모두 무료입니다.

결제 및 비용 관리 콘솔은 AWS Storage Gateway 볼륨과 가상 테이프를 비롯한 서비스별 이번 달 현재까지 사용량 추정치를 보여줍니다. 개별 볼륨이나 가상 테이프별 사용 내역의 경우, 세부 결제 보고서를 사용하여 일일 리소스별 사용량을 확인합니다.

사용자는 S3의 파일을 객체로 저장하고 검색하기 위해 File Gateway에서 대신 발생한 S3 요청에 대해 요금을 지불하게 됩니다. 게이트웨이는 사용자가 할당하는 로컬 디스크의 용량까지 데이터를 캐시하여, 데이터 검색을 위한 비용을 줄이는 데 도움을 줄 수 있습니다.

File Gateway 감사 로그를 구성한 경우 Amazon CloudWatch Logs, Amazon CloudWatch Events 및 Amazon CloudWatch Metrics에 대한 표준 요금이 부과됩니다.

청구 시스템은 협정세계시(UTC)를 따릅니다. 월은 매달 첫 번째 날의 자정(UTC 기준)에 시작됩니다.

달리 명시하지 않는 한 가격에는 VAT 및 해당 판매세를 포함한 관련 조세 공과가 포함되지 않습니다. 청구지 주소가 일본으로 되어 있는 고객의 경우 아시아 태평양(도쿄) 리전을 사용하면 일본 소비세의 적용을 받게 됩니다.

예. AWS Premium Support는 AWS Storage Gateway의 사용과 관련된 문제를 지원합니다. 자세한 내용 및 요금은 AWS Premium Support 세부 정보 페이지를 참조하세요.

AWS Storage Gateway 토론 포럼을 통해 기존의 AWS 커뮤니티에 있는 방대한 지식을 활용할 수 있습니다.

AWS Storage Gateway 소프트웨어 및 서비스 지원을 제공하는 AWS Support에 연락하면 됩니다. AWS Support는 또한 하드웨어 제조사의 지원팀과 모든 하드웨어 관련 사례를 조정합니다. AWS Premium Support를 구매하는 것이 좋습니다.

하드웨어 어플라이언스에 대한 서비스 태그는 AWS Storage Gateway 콘솔의 하드웨어 보기에서 찾을 수 있습니다.

AWS Support는 하드웨어 지원을 위해 하드웨어 제조사와 협조합니다. 어플라이언스 구매에는 하드웨어 지원이 포함되어 있으며 36개월 동안 연중무휴 24시간 전화 지원 및 부품 교체를 위한 다음 영업일 현장 지원이 포함되어 있습니다.

하드웨어 어플라이언스는 3년 보증을 제공하며 하드웨어 제조사가 제공하는 부품 교체를 위한 다음 영업일 현장 지원이 포함되어 있습니다. 여기에서 보증 정보를 확인할 수 있습니다.