Amazon EFS FAQ

Amazon EFS를 사용하면 페타바이트 규모의 데이터를 저장할 수 있습니다. Amazon EFS 파일 시스템은 탄력적이며 파일을 추가하고 제거함에 따라 자동으로 증가하고 줄어듭니다. 파일 시스템 크기를 사전에 프로비저닝할 필요가 없고, 사용한 만큼만 비용을 지불하면 됩니다.

Amazon EFS는 1개에서 수천 개의 Amazon Elastic Compute Cloud(EC2) 인스턴스가 동시에 파일 시스템에 연결할 수 있도록 지원합니다.

Amazon EFS 한도에 대한 자세한 내용은 Amazon EFS 한도 페이지를 참조하세요.

Amazon EFS 파일 시스템의 예상 성능은 특정 구성(예: 스토리지 클래스 및 처리량(throughput) 모드)과 특정 파일 시스템 작업 유형(읽기 또는 쓰기)에 따라 다릅니다. Amazon EFS 파일 시스템의 예상 지연 시간, 최대 처리량, 최대 IOPS 성능에 대한 자세한 정보는 파일 시스템 성능 문서를 참조하세요.

기본 처리량 모드는 탄력적 처리량이며 대부분의 파일 워크로드에 적합합니다. 기본 탄력적 처리량 모드에서는 워크로드 활동에 따라 성능이 자동으로 확장되며 사용한 처리량(매월 파일 시스템에서 전송된 데이터)에 대해서만 요금이 부과됩니다. 애플리케이션의 피크 처리량 요구 사항을 모르거나 애플리케이션의 변동성이 심하고 기준 활동이 낮은 경우(피크 요구 사항에 맞춰 프로비저닝할 때 평균적으로 용량의 5% 미만을 사용)에는 탄력적 처리량이 적합합니다.

워크로드의 피크 처리량 요구 사항을 알고 있고 애플리케이션의 피크 처리량 용량의 더 많은 부분(평균 5% 이상)이 워크로드에 사용될 것이라고 예상되는 경우라면 처리량 용량을 프로비저닝된 처리량으로 선택적으로 변경할 수 있습니다.

제공할 수 있는 처리량의 양은 선택한 처리량 모드에 따라 다릅니다. 자세한 내용은 파일 시스템 성능에 대한 설명서를 참조하세요.  자세한 내용을 알아보려면 파일 시스템 성능으로 이동하세요.

Amazon CloudWatch를 사용하거나 Amazon EFS 콘솔의 모니터링 탭에서 파일 시스템을 모니터링할 수 있습니다. 자세한 내용은 Amazon EFS 모니터링 설명서를 참조하세요.

Amazon EFS는 내구성 및 가용성 요구 사항에 따라 선택할 수 있는 두 가지 파일 시스템 유형을 제공합니다. EFS Regional 파일 시스템(권장)은 여러 가용 영역에 데이터를 저장하여 최고 수준의 내구성과 가용성을 제공합니다. EFS One Zone 파일 시스템은 단일 가용 영역 내에 데이터를 중복 저장하므로 이러한 파일 시스템의 데이터는 사용할 수 없으며 재해나 가용 영역 내 기타 장애 발생 시 손실될 수 있습니다.

Amazon EFS는 지정된 연도 동안 99.999999999%(9가 11개)의 내구성을 제공하도록 설계되었습니다. EFS 리전 파일 시스템은 AZ가 손실된 경우에도 데이터를 유지하도록 설계되었습니다. EFS One Zone 파일 시스템은 단일 AZ에 데이터를 저장하기 때문에 이러한 스토리지 클래스에 저장된 데이터는 AZ 내의 재해 또는 기타 장애 발생 중에 손실될 수 있습니다.  

여느 환경과 마찬가지로 모범 사례는 백업을 수행하고 실수로 인한 삭제에 대비한 보호 조치를 마련하는 것입니다. Amazon EFS 데이터의 경우, 모범 사례에는 Amazon EFS Replication을 사용하여 리전 간에 파일 시스템을 복제하고, AWS Backup을 사용하여 정상적으로 기능하는 백업을 생성하고 정기적으로 테스트하는 것이 포함됩니다. EFS One Zone 스토리지 클래스를 사용하는 파일 시스템은 파일 시스템 생성 시 기본적으로 파일을 자동 백업하도록 구성됩니다.

각 EFS 리전 파일 시스템 객체(예: 디렉터리, 파일, 링크)는 여러 AZ에 중복 저장됩니다. EFS One Zone 파일 시스템을 사용하면 데이터가 단일 AZ 내에 중복 저장됩니다. Amazon EFS는 중복 손실을 빠르게 감지하고 복구하여 동시에 디바이스 장애가 발생하는 것을 방지하도록 설계되었습니다.  

EFS 파일 시스템 데이터는 가용 영역 내에서 가용성이 높도록 설계된 가용 영역별 EFS 탑재 대상을 사용하여 액세스합니다. EFS Regional 파일 시스템은 EFS 탑재 대상이 위치한 리전의 모든 가용 영역에 있는 EFS 탑재 대상에서의 동시 액세스를 지원합니다. 즉, 리전의 한 가용 영역에서 다른 가용 영역으로 장애 조치하여 최고 수준의 애플리케이션 가용성을 달성하도록 애플리케이션을 설계할 수 있습니다. EFS One Zone 파일 시스템은 단일 가용 영역에서 단일의 고가용성 EFS 탑재 대상만 지원합니다. 즉, 재해나 해당 가용 영역 내의 기타 장애가 발생할 경우 데이터를 사용할 수 없게 될 수 있습니다. 가용성에 대한 자세한 내용은 Amazon EFS 서비스 수준 계약을 참조하세요.

EFS One Zone 파일 시스템은 전체 AZ 운영 중단에 대해 복원력이 없습니다. AZ 중단 중에 파일 시스템 데이터가 다른 AZ로 복제되지 않기 때문에 가용성이 손실됩니다. AZ 내의 재해 또는 장애 발생 중에는 데이터의 모든 복사본이 영향을 받으므로 EFS Backup 또는 EFS Replication을 사용하여 보호되지 않는 데이터는 손실될 수 있습니다. EFS Backup은 모든 EFS One Zone 파일 시스템에 대해 기본적으로 활성화됩니다.

Amazon EFS에서는EFS Standard, EFS Infrequent Access, EFS Archive의 세 가지 스토리지 클래스를 제공합니다. 자주 액세스하는 데이터는 성능 요구 사항이 더 높은 경향이 있으므로 EFS는 1밀리초 미만의 지연 시간을 제공하도록 설계된 SSD 기반 EFS Standard 클래스를 제공합니다. 자주 액세스하지 않는 데이터의 경우 지연 시간이 낮은 두 자릿수 밀리초인, EFS의 두 가지 비용 최적화 스토리지 클래스를 사용할 수 있습니다. EFS Inrequent Access(IA)는 분기에 몇 번만 액세스하는 데이터를 위해 설계되었으며, EFS Archive는 일 년에 몇 번 액세스하지 않는 데이터를 위해 설계되었습니다. EFS IA는 자주 액세스하지 않는 데이터에 대해 EFS Standard보다 비용이 최대 95% 저렴합니다. 콜드 데이터에 비용 최적화된 경험을 제공하는 EFS Archive는 EFS Inrequent Access보다 비용이 최대 50% 저렴하며 데이터 액세스 시에는 요청 요금이 더 높습니다. EFS Archive는 EFS의 기본 탄력적 처리량 모드를 사용하여 EFS 리전 파일 시스템에 최적화되었으며 이를 지원합니다. 자세한 내용은 EFS 스토리지 클래스 및 EFS 요금을 참조하세요.

EFS 수명 주기 관리를 활성화하면 액세스 패턴에 따라 스토리지 클래스 간에 파일을 자동으로 계층화할 수 있습니다. 기본 권장 수명 주기 정책은 30일 연속으로 액세스가 없을 때 EFS Standard에서 EFS IA로 파일을 계층화하고, 90일 연속으로 액세스가 없을 때 EFS Archive로 파일을 계층화합니다. 파일의 마지막 액세스 이후 경과한 일수를 기준으로 스토리지 클래스 간에 파일을 전환하는 사용자 지정 정책을 지정할 수도 있습니다.

또한 EFS Intelligent-Tiering을 활성화하여 EFS IA 및 EFS Archive의 파일을 액세스 시 EFS Standard로 다시 승격할 수 있습니다. 이렇게 하면 이후에 EFS Standard의 더 빠른 밀리초 미만 지연 시간으로 해당 파일을 읽을 수 있습니다. 승격된 후 해당 파일은 수명 주기 정책에 따라 적절한 IA 또는 Archive 스토리지 클래스로 다시 전환됩니다.

EFS Standard 클래스와 비교할 때 EFS IA와 Archive는 동일한 처리량 및 IOPS 확장성을 제공하지만 첫 바이트 지연 시간이 더 깁니다(즉, 읽기 지연 시간이 낮은 두 자릿수 밀리초이지만 EFS Standard의 읽기 지연 시간은 1밀리초 미만). 자세한 내용은 Amazon EFS 성능 설명서를 참조하세요.

EFS IA에는 최소 저장 기간이 없습니다. EFS Archive로 계층화된 데이터의 최소 저장 기간은 90일입니다. 최소 기간 이전에 파일을 삭제하거나 자른 경우 해당 작업 이전의 파일 크기를 기준으로 남은 일수에 대해 비례 할당으로 계산된 요금이 부과됩니다.

EFS의 비용 최적화 스토리지 클래스(IA, Archive)는 일반적으로 대용량 파일로 구성되고 사용 빈도가 낮은 데이터를 저장하도록 설계되었습니다. IA 또는 Archive의 최소 파일 크기는 없지만 128KiB보다 작은 스토리지 클래스로 계층화된 파일에는 128KiB와 동일한 스토리지 요금이 발생합니다.

Amazon EFS Replication은 선택한 리전의 신규 또는 기존 파일 시스템에 파일 시스템 데이터를 복사합니다. 추가 인프라나 사용자 지정 프로세스 없이 증분 변경 사항만 자동으로 전송하여 두 파일 시스템의 동기화를 유지합니다. EFS Replication은 분 단위의 Recovery Point Objective(RPO)와 Recovery Time Objective(RTO)를 제공하도록 설계되었기 때문에 규정 준수 및 비즈니스 연속성 목표를 달성하는 데 도움이 됩니다.

재해 복구, 규정 준수 또는 비즈니스 연속성 계획을 위해 먼 거리에서 파일 시스템의 복제본을 유지 관리하려면 EFS Replication을 사용해야 합니다. 재해가 발생하면 복제본 파일 시스템으로 장애 조치하여 몇 분 내에 비즈니스 크리티컬 애플리케이션의 작업을 재개할 수 있습니다. 재해 이벤트가 끝난 후에는 복제본의 증분 변경 사항만 원래 파일 시스템으로 다시 전송하여 페일백할 수 있습니다. EFS Replication이 활성화되어 있는 동안에는 애플리케이션에서 읽기 전용 모드로 복제본 파일 시스템을 사용하여 네트워크 지연 시간을 단축하면서 여러 리전에 액세스할 수 있습니다. Amazon EFS Replication을 사용하면 원본 파일 시스템과 독립적으로 복제본 파일 시스템을 구성하여 비용 최적화 스토리지 클래스와 짧은 사용 기간 제한 수명 주기 관리 정책을 사용함으로써 비용을 최대 92% 절감할 수 있습니다. 또한 EFS 복제를 사용할 경우 Amazon CloudWatch를 사용하여 RPO 상태를 간편하게 모니터링하고 경보를 제공할 수 있습니다.

아니요. EFS Replication은 시점 일치 복제를 제공하지 않습니다. EFS 복제는 TimeSinceLastSync라는 타임스탬프 지표를 Amazon CloudWatch에 게시합니다. 최소한 게시 시간을 기준으로 소스 파일 시스템에서 변경한 모든 내용이 복제본에 복사됩니다. 기록된 시간 이후 소스 파일 시스템의 변경 사항은 복제되지 않았을 수 있습니다. Amazon CloudWatch를 사용하여 EFS 복제의 상태를 모니터링할 수 있습니다. 재해 복구 이벤트로 인해 복제 프로세스를 중단하는 경우 소스 파일 시스템의 파일이 전송되었지만 아직 최종 위치로 복사되지 않았을 수 있습니다. 이러한 파일과 해당 콘텐츠는 EFS Replication을 통해 복제 파일 시스템의 루트 디렉터리 아래에 생성된 lost+found 디렉터리에서 찾을 수 있습니다.

Amazon EFS Backup은 Amazon EFS 파일 시스템의 백업을 중앙에서 관리하고 자동화하는 완전관리형 백업 서비스인 AWS Backup을 통해 제공됩니다. 파일 시스템의 변동분 복제본을 일정에 따라 자동으로 중앙 위치에 생성하여 데이터 손실로부터 파일 시스템을 보호합니다. AWS Backup은 중앙 집중식 콘솔, 자동화된 백업 일정 관리, 백업 보존 관리 및 복원 활동을 제공합니다. 자세히 알아보려면 AWS Backup 설명서 또는 FAQ를 참조하세요.

Amazon EFS는 AWS Backup과 기본적으로 통합됩니다. EFS 콘솔, API 및 AWS Command Line Interface(AWS CLI)를 사용하여 자동 백업을 활성화할 수 있습니다. 자동 백업은 기본 백업 계획과 AWS Backup 권장 설정을 사용합니다. 초기 백업 중에는 전체 파일 시스템의 복사본이 백업 볼트에 만들어집니다. 해당 파일 시스템의 모든 후속 백업은 기본적으로 증분 백업입니다. 즉, 변경, 추가 또는 제거된 파일 및 디렉터리만 복사됩니다. 각 증분 백업에서 AWS Backup은 전체 복원에 필요한 참조 데이터를 유지합니다. 데이터 손실이 발생한 경우 AWS Backup 콘솔 또는 CLI를 사용하여 파일 시스템의 전체 또는 부분 복원을 수행할 수 있습니다.   

VPC 보안 그룹 규칙 및 IAM 정책을 사용하여 파일 시스템에 액세스할 수 있는 EC2 인스턴스를 제어할 수 있습니다. VPC 보안 그룹을 사용하여 파일 시스템에서 송수신되는 네트워크 트래픽을 제어합니다. IAM 정책을 파일 시스템에 연결하여 어떤 클라이언트가 어떤 권한으로 파일 시스템에 마운트할 수 있는지 제어하고 EFS 액세스 포인트를 사용하여 애플리케이션 액세스를 관리합니다. POSIX 호환 사용자 및 그룹 수준 권한으로 파일과 디렉터리에 대한 액세스를 제어할 수 있습니다.

Amazon EFS 콘솔을 사용하여 루트 액세스를 비활성화하거나, 읽기 전용 액세스를 적용하거나, 파일 시스템에 대한 모든 연결이 암호화되도록 적용하는 등의 일반적인 정책을 파일 시스템에 적용할 수 있습니다. 다른 AWS 계정에 있는 IAM 역할을 포함해 특정한 IAM 역할에 액세스를 부여하는 것과 같은 고급 정책을 적용할 수도 있습니다.

 

EFS 액세스 포인트는 사용자와 애플리케이션이 EFS 파일 시스템에 액세스하고 IAM에 정의된 세분화된 액세스 제어 및 정책 기반 권한에 따라 파일 및 폴더 수준 권한(POSIX)을 적용할 때 사용할 수 있는 네트워크 엔드포인트입니다.

EFS 액세스 포인트를 사용하면 파일 애플리케이션에 사용할 다중 테넌트 환경을 클라우드 네이티브 방식으로 유연하게 생성하고 관리할 수 있으므로 데이터 공유를 간소화하는 데 도움이 됩니다. 파일 시스템 액세스를 제어하는 기존의 POSIX ACL이나 인증을 제어하는 Kerberos는 모두 복잡한 설정, 관리 및 유지 관리가 필요하기 때문에 위험으로 이어지는 경우가 많지만 EFS 액세스 포인트는 IAM과 통합되므로 클라우드 네이티브 애플리케이션에서 POSIX 기반 공유 파일 스토리지를 사용할 수 있습니다. Amazon EFS 액세스 포인트의 이점을 누릴 수 있는 사용 사례로 개발자가 자체적인 컨테이너를 만들어 배포하는 컨테이너 기반 환경, 프로덕션 데이터에 대한 액세스 권한이 필요한 데이터 과학 응용 분야, 파일 시스템에서 다른 AWS 계정과 특정 디렉터리를 공유하는 경우가 있습니다.

Amazon EFS 액세스 포인트를 생성할 때 운영 체제 사용자와 그룹을 구성하고 이를 사용하는 모든 연결에 대한 루트 디렉터리를 구성할 수 있습니다. 루트 디렉터리의 소유자를 지정하면 클라이언트가 액세스 포인트에 처음으로 연결할 때 제공하는 권한으로 EFS는 자동으로 루트 디렉터리의 소유자를 생성할 수 있습니다. 파일 시스템의 IAM 정책을 업데이트하여 액세스 포인트에 적용할 수도 있습니다. 예를 들어 해당 액세스 포인트에 연결하기 위해 특정 IAM 자격 증명이 필요한 정책을 적용할 수 있습니다. 자세한 내용은 Amazon EFS 사용 설명서를 참조하세요.

Amazon EFS에서는 저장 데이터 및 전송 데이터를 암호화하는 기능을 제공합니다.

암호화된 저장 데이터는 작성되면서 투명하게 암호화되고 읽어 들이면서 투명하게 복호화되므로, 애플리케이션을 수정할 필요가 없습니다. 암호화 키는 AWS KMS에서 관리하므로 보안 키 관리 인프라를 구축하고 유지 관리할 필요가 없습니다.

전송 데이터 암호화에서는 업계 표준 TLS(전송 계층 보안) 1.2를 사용하여 클라이언트와 EFS 파일 시스템 간에 전송되는 데이터를 암호화합니다.

저장 데이터 및 전송 데이터 암호화는 고유한 보안 요구 사항에 맞춰 함께 또는 개별적으로 구성할 수 있습니다.

자세한 내용은 암호화에 대한 사용 설명서를 참조하십시오.

AWS KMS는 데이터 암호화에 사용되는 암호화 키를 손쉽게 생성 및 제어할 수 있는 관리형 서비스입니다. AWS KMS는 EFS, EBS 및 S3를 비롯한 AWS 서비스와 통합되므로 사용자는 자신이 관리하는 암호화 키로 데이터를 간단하게 암호화할 수 있습니다. 또한 AWS KMS를 AWS CloudTrail과 통합하면 모든 키 사용에 관한 로그가 제공되므로 각종 규제 및 규정 준수 요구 사항을 충족할 수 있습니다.

EFS 콘솔에서 또는 CLI나 SDK를 사용하여 저장 중 암호화를 사용하도록 설정할 수 있습니다. EFS 콘솔에서 새로운 파일 시스템을 생성할 때 ‘Create File System(파일 시스템 생성)’을 선택하고 확인란을 선택하여 암호화를 사용하도록 설정합니다.

Amazon EFS 탑재 헬퍼를 사용하면 Amazon EFS 파일 시스템과 클라이언트 간에 전송되는 데이터를 암호화할 수 있습니다.

저장 데이터 및 전송 데이터 암호화는 고유한 보안 요구 사항에 맞춰 함께 또는 개별적으로 구성할 수 있습니다.

자세한 내용은 암호화에 대한 사용 설명서를 참조하십시오.

데이터 암호화는 I/O 지연 시간과 처리량에 아주 작은 영향을 미칩니다.

온프레미스에서 EFS 파일 시스템에 액세스하려면 온프레미스 데이터 센터와 Amazon Virtual Private Cloud(VPC) 간에 Direct Connect 또는 AWS VPN 연결을 구성해야 합니다.

NFS v4.1 프로토콜을 통해 파일 시스템 탑재를 위한 표준 Linux 탑재 명령을 사용하여 온프레미스 Linux 서버에 Amazon EFS 파일 시스템을 탑재합니다.

온프레미스 서버에서 Amazon EFS 파일 시스템에 액세스하는 방법을 자세히 알아보려면 설명서를 참조하세요.

표준 Linux 도구와 스크립트 또는 AWS DataSync를 사용하여 온프레미스 서버에 Amazon EFS 파일 시스템을 탑재하고, Amazon EFS에서 파일을 이동할 수 있습니다. Amazon EFS 파일 시스템에서 파일 데이터를 이동할 수 있게 되면 3가지 사용 사례가 가능해집니다.

첫 번째, 온프레미스 데이터 센터에서 데이터를 마이그레이션하여 EFS 파일 시스템에 영구 보관할 수 있습니다.

두 번째, 애플리케이션 처리를 클라우드로 오프로드하여 클라우드 버스트 워크로드를 지원할 수 있습니다. 온프레미스 서버에서 Amazon EFS 파일 시스템으로 데이터를 이동하고, Amazon VPC의 EC2 인스턴스 클러스터에서 이를 분석한 후, Amazon EFS 파일 시스템에 결과를 영구 저장하거나 온프레미스 서버로 결과를 다시 이동할 수 있습니다.

세 번째, 온프레미스 파일 데이터를 주기적으로 Amazon EFS로 복사하여 백업과 재해 복구 시나리오를 지원할 수 있습니다.

예. 현재 온프레미스 데이터 센터의 서버와 Amazon VPC의 EC2 인스턴스에서 Amazon EFS 파일 시스템에 액세스할 수 있습니다. Amazon EFS에서는 파일 시스템에 액세스하는 모든 EC2 인스턴스와 온프레미스 서버 전체에 강력한 데이터 일관성, 파일 잠금 등 동일한 파일 시스템 액세스 의미 체계를 제공합니다.

데이터가 장거리를 이동할 때 수반되는 전파 지연으로 인해 온프레미스 데이터 센터와 Amazon VPC 간 네트워크 연결의 네트워크 지연 시간이 수십 밀리초가 될 수 있습니다. 파일 작업에 순서가 정해져 있다면 네트워크 연결의 지연 시간은 읽기 및 쓰기 처리량에 직접적인 영향을 줍니다. 즉, 일정 기간 읽거나 쓸 수 있는 데이터 볼륨은 각 읽기 및 쓰기 작업이 완료되는 데 걸리는 시간에 따라 결정됩니다. 처리량(throughput)을 극대화하려면 Amazon EFS가 동시에 여러 읽기 및 쓰기를 처리하도록 파일 작업을 병렬화하세요. GNU parallel과 같은 표준 도구는 파일 데이터 복사를 병렬화하는 데 도움이 됩니다. 자세한 내용은 온라인 설명서를 참조하세요.

몇 가지 방법을 사용해 기존 온프레미스 데이터를 Amazon EFS로 복사할 수 있습니다. AWS DataSync는 기존 파일 시스템을 EFS로 안전하게 동기화할 수 있는 빠르고 간단한 방법을 제공하며, AWS Direct Connect를 비롯해 모든 네트워크에서 작동합니다.

AWS Direct Connect는 EFS 파일 시스템에 탑재할 수 있으며 대역폭이 높고 지연 시간이 짧은 전용 네트워크 연결을 제공합니다. 탑재되면, DataSync를 사용하여 표준 Linux 복사 도구보다 최대 10배 빠른 속도로 데이터를 EFS로 복사할 수 있습니다.

AWS DataSync에 대한 자세한 내용은 이 FAQ의 데이터 전송 섹션을 참조하세요.

DataSync는 온프레미스 스토리지와 Amazon EFS 서비스 간에 데이터를 더 빠르고 쉽게 이동할 수 있도록 해주는 온라인 데이터 전송 서비스입니다. DataSync에서는 특별 제작된 프로토콜을 사용하여 인터넷 또는 Direct Connect를 통해 오픈 소스 도구보다 10배 더 빠른 속도로 안전하게 전송합니다. DataSync를 사용하면 일회성 데이터 마이그레이션을 수행하고, 시의적절한 클라우드 내 분석을 위해 온프레미스 데이터를 전송하고, AWS에 대한 복제를 자동화하여 데이터를 보호 및 복구할 수 있습니다.

AWS Transfer Family는 Secure File Transfer Protocol(SFTP), File Transfer Protocol over SSL(FTPS) 및 File Transfer Protocol(FTP)을 지원하는 완전관리형 파일 전송 서비스입니다. AWS Transfer Family는 가용성이 뛰어나고 Auto Scaling 기능을 통해 완전관리형 파일 전송 서비스를 제공하므로 사용자가 파일 전송 관련 인프라를 관리할 필요가 없습니다. 최종 사용자의 워크플로는 변경 없이 그대로 유지되면서, 선택한 프로토콜을 통해 업로드 및 다운로드된 데이터는 Amazon EFS 파일 시스템에 저장됩니다.

DataSync를 시작하려면 콘솔 또는 CLI에서 네트워크 파일 시스템(NFS) 프로토콜을 통해 온프레미스 또는 클라우드 내 파일 시스템에 에이전트를 연결하고, Amazon EFS 파일 시스템을 선택한 후 데이터 복사를 시작하면 됩니다. 두 Amazon EFS 파일 시스템 간에 파일을 복사하는 경우를 제외하고, 먼저 콘솔에서 다운로드할 수 있는 소프트웨어 에이전트를 배포해야 합니다.

AWS Transfer Family를 시작하려면 먼저 AWS Transfer에 할당하려는 POSIX 사용자가 파일 시스템의 디렉터리에 액세스할 수 있는지 확인해야 합니다. 그런 다음 콘솔, CLI 또는 API를 사용하여 Transfer Family 엔드포인트와 사용자를 생성할 수 있습니다. 완료되면 최종 사용자가 SFTP, FTP 또는 FTPS 클라이언트를 사용하여 Amazon EFS 파일 시스템에 저장된 데이터에 액세스할 수 있습니다.

DataSync를 사용하면 다른 AWS 리전의 시스템을 포함하여 두 Amazon EFS 파일 시스템 간에 파일을 전송할 수 있습니다. AWS Transfer Family 엔드포인트는 Amazon EFS 파일 시스템과 동일한 리전에 있어야 합니다.

예. DataSync를 사용하여 다른 AWS 계정의 Amazon EFS 파일 시스템으로 파일을 복사할 수 있습니다.

계정에 액세스 권한이 있기만 하면 AWS Transfer Family에서 다른 계정을 사용하여 액세스할 수 있도록 Amazon EFS 파일 시스템을 구성할 수도 있습니다. 파일 시스템 정책을 통해 외부 AWS 계정에 Transfer Family 권한을 부여하는 방법을 자세히 알아보려면 설명서를 참조하세요.

EFS는 CloudWatch, AWS CloudFormation, CloudTrail, IAM 및 AWS 태깅 서비스를 비롯하여 다수의 다른 AWS 서비스와 통합됩니다.

CloudWatch는 지표를 사용하여 파일 시스템 활동을 모니터링하는 데 도움이 됩니다. CloudFormation은 템플릿을 사용하여 파일 시스템을 생성 및 관리하는 데 도움이 됩니다.

CloudTrail은 로그 파일에 모든 EFS API 호출을 기록하는 데 도움이 됩니다.

IAM은 파일 시스템을 관리할 수 있는 사용자를 제어하는 데 도움이 됩니다. AWS 태깅 서비스는 사용자가 정의한 메타데이터로 파일 시스템에 레이블을 지정하는 데 도움이 됩니다.

AWS Budgets을 사용하면 Amazon EFS 파일 시스템 비용을 계획하고 관리할 수 있습니다. AWS Billing and Cost Management 콘솔에서 AWS Budgets으로 작업할 수 있습니다. AWS Budgets를 사용하려면 Amazon EFS 파일 시스템에 대한 월별 비용 예산을 생성해야 합니다.

Amazon EFS의 잠금은 권고 잠금에 대한 NFS v4.1 프로토콜을 따르며, 애플리케이션에서 전체 파일과 바이트 범위 잠금을 모두 사용할 수 있습니다.

모든 파일 시스템은 전역적으로 고유한 ID 번호를 자동으로 생성합니다. 파일 시스템을 이름으로 태그를 지정할 수 있으며, 이러한 이름이 고유할 필요는 없습니다.

Amazon EFS를 사용할 때는 사용한 기본 및 백업 스토리지와 EFS 파일 시스템에 대한 읽기, 쓰기, 계층화 작업에 대한 비용만 지불하면 됩니다. 탄력적 처리량을 사용한 읽기 및 쓰기 액세스에 대한 요금을 지불하고(단, 프로비저닝된 처리량을 사용하여 처리량 성능을 미리 프로비저닝할 수도 있음), EFS의 Inrequent Access 및 Archive 스토리지 클래스에 데이터를 계층화하는 데 드는 비용을 지불합니다.

Amazon EFS에서는 세 가지 스토리지 클래스를 제공합니다. EFS Standard는 활발하게 사용되는 데이터에 대해 1밀리초 미만의 지연 시간 성능을 제공하고, EFS IA(Inrequent Access)는 분기에 몇 번만 액세스하는 데이터에 대해 비용 최적화되었으며, EFS Archive는 1년에 몇 번 또는 그 미만으로 액세스하는 장기 데이터에 대해 비용 최적화되었습니다.

또한 EFS는 EFS Backup 및 EFS Replication을 통해 파일에 대한 데이터 보호 기능을 제공합니다. EFS 백업을 사용하면 해당 달에 사용한 백업 스토리지의 양과 복원한 백업 데이터의 양에 대해서만 비용을 지불하면 됩니다. 최소 비용이나 설정 비용은 없습니다. 자세히 알아보려면 AWS Backup을 방문하세요. EFS 복제를 사용하면 추가 인프라나 사용자 지정 프로세스를 관리하지 않고도 파일 시스템을 선택한 리전 또는 가용 영역에 복제할 수 있습니다.

Amazon EFS 요금 계산기를 사용해 월별 청구액을 추산할 수 있습니다.

Amazon EFS는 설치 요금이나 약정 없이 사용을 시작할 수 있습니다. 월말에 해당 월 사용액이 자동으로 결제됩니다. Amazon Web Services 계정에 로그인하고 콘솔 프로필에 연결된 ‘Billing Dashboard(빌링 대시보드)’를 선택하여 현재 결제 기간에 대한 요금을 확인할 수 있습니다.

AWS 프리 티어*를 사용하면 프리 티어 사용량이 AWS GovCloud 리전을 제외한 모든 AWS 리전에서 매달 계산되어 청구서에 자동으로 적용됩니다. 월별 미사용 분은 다음 달로 이월되지 않습니다. 신규 EFS 고객은 가입 시 1년 동안 매달 5GB의 Amazon EFS Standard를 받게 됩니다. EFS One Zone 파일 시스템 유형에 저장되는 파일에는 AWS 프리 티어가 적용되지 않습니다. 제한 사항이 적용됩니다. 자세한 내용은 제품 및 서비스 약관을 참조하세요.

Amazon EFS 요금은 다음과 같은 사용 유형에 대해 부과됩니다. 아래 계산은 AWS 프리 티어가 없는 경우를 가정한 것입니다.

사용 스토리지:

한 달에 청구되는 Amazon EFS 요금은 한 달 동안의 스토리지, 처리량 및 데이터 보호 사용량을 기준으로 합니다. 스토리지 비용은 한 달 동안 사용한 평균 스토리지 공간을 기준으로 계산됩니다. 스토리지 사용량은 "GB–월" 단위로 측정되며 이는 월말에 합산되어 월별 요금을 산출합니다. 

다음 예제에서는 시간에 따라 파일 액세스 패턴이 바뀌는 시나리오를 반영하며, 각 EFS IA 및 EFS Archive의 요금 차원을 포함합니다. 이 예제에서는 EFS Standard, EFS Infrequent Access(IA), EFS Archive 사이에서 파일을 이동하는 두 EFS 수명 주기 정책이 설정되었다고 가정합니다.

파일 시스템이 미국 동부(버지니아 북부) 리전에 있다고 가정합니다. 한 달 31일의 월초에 파일 시스템에는 EFS Standard에 200GB, EFS IA에 500GB, EFS Archive에 2TB의 파일이 저장됩니다. 14일 동안 액세스하지 않으면 매월 15일째 되는 날에 지능형 계층화 없이 EFS 수명 주기 관리를 통해 EFS Standard 파일의 50%가 EFS IA 클래스로, EFS IA 파일의 10%가 EFS Archive 클래스로 이동합니다. 평균적으로 클라이언트 애플리케이션은 매달 EFS IA에서 200GB의 파일을 읽고 EFS Archive에서 100GB의 파일을 읽습니다.

먼저 비례 배분된 스토리지 사용량을 계산합니다.

Standard 스토리지:
14일 동안 EFS Standard 스토리지 200GB(GB-시간): 200GB x 14일 x (24시간/일) = 6만 7,200GB-시간
17일 동안 EFS Standard 스토리지 100GB(GB-시간): 100GB x 17일 x (24시간/일) = 4만 800GB-시간
총 EFS Standard 스토리지 사용량(GB-시간): 6만 7,200GB-시간 + 4만 800GB-시간 = 10만 8,000GB-시간

IA 스토리지:
14일 동안 EFS IA 스토리지 500GB(GB-시간): 500GB x 14 x (24시간/일) = 16만 8,400GB-시간
17일 동안 EFS Standard에서 EFS IA로 전송된 파일 100GB(GB-시간) = 100GB x 17 x (24시간/일) = 4만 800GB-시간
EFS IA 450GB(50GB를 EFS Archive로 이동한 후) = 450GB x 17 x (24시간/일) = 18만 3,600GB-시간

총 EFS IA 스토리지 사용량(GB-시간): 16만 8,000GB-시간 + 4만 800GB-시간 + 32만 6,400GB-시간 = 39만 2,400GB-시간

Archive 스토리지:
31일 동안 EFS IA 2TB(GB-시간): 1,000GB x 14 x (24시간/일) = 148만 8,000GB-시간
17일 동안 EFS IA에서 EFS Archive로 전송된 파일 50GB(GB-시간): 50GB x 17 x (24시간/일) = 2만 400GB-시간
총 EFS Archive 스토리지 사용량(GB-시간): 148만 8,000GB-시간 + 2만 400GB-시간 = 150만 8,400GB-시간

다음으로, 스토리지 사용량을 월별 GB로 변환하고, 스토리지 요금을 계산합니다.
총 EFS Standard 스토리지 요금: 10만 8,400GB-시간 x (1개월/744시간) x 0.30 USD/GB-월 = 43.55 USD
총 EFS IA 요금: 39만 2,400GB-시간 x (1개월/744시간) x 0.0165 USD/GB-월 = 8.70 USD
총 EFS Archive 요금: 150만 8,400 GB-시간 x (1개월/744시간) x 0.008 USD/GB-월 = 16.22 USD
총 EFS 스토리지 요금: 43.55 USD + 8.70 USD + 16.22 USD = 68.47 USD

다음으로, EFS IA 및 EFS Archive의 파일에 대한 액세스 요금을 계산합니다.

IA 데이터 계층화:
데이터 계층화(EFS Standard에서 EFS IA로 이동한 파일): 100GB * 0.01 USD/GB = 1.00 USD
IA 읽기 액세스 요금: 200GB * 0.01 USD/GB = 2.00 USD

탄력적 처리량 읽기 요금: 200GB * 0.03 USD/GB = 6.00 USD

총 EFS IA 계층화 및 액세스 요금: 1.00 USD + 2.00 USD + 6.00 USD = 9.00 USD

Archive 데이터 계층화:
데이터 계층화(Infrequent Access에서 Archive로 이동한 파일): 50GB * 0.03/GB = 1.50 USD
아카이브 읽기 액세스 요금: 100GB * 0.03 USD/GB = 3.00 USD

탄력적 처리량 읽기 요금: 100GB * 0.03 USD/GB = 3.00 USD

총 EFS IA 계층화 및 액세스 요금: 1.50 USD + 3.00 USD + 3.00 USD = 7.50 USD

총 EFS 계층화 및 액세스 요금: 9.00 USD + 7.50 USD = 16.50 USD

마지막으로 월별 총 EFS 요금을 계산합니다.

총 월별 요금 = 총 스토리지 요금 + 총 액세스 요금 = 68.47 USD + 16.50 USD = 84.97 USD(TCO - 0.0315 USD/GB)

탄력적 처리량을 사용하여 읽기 및 쓰기 작업을 위해 데이터에 액세스할 수 있습니다. 탄력적 처리량을 사용하면 워크로드 활동에 따라 성능이 자동으로 조정되며 사용한 처리량(매월 파일 시스템에서 전송된 데이터)에 대해서만 요금이 부과됩니다. 한 달에 청구되는 탄력적 처리량은 한 달 내에 전송된 읽기 및 쓰기 데이터를 기준으로 하며 ‘전송된 GB’ 단위로 측정됩니다.

애플리케이션의 처리량 사용량과 최대 처리량 요구 사항을 알고 있는 경우 프로비저닝된 처리량을 사용할 수 있습니다. 한 달에 청구되는 프로비저닝된 처리량은 해당 월에 EFS Standard에서 허용하는 한도를 초과하여 AWS 리전의 일반적인 버스팅 기준 처리량 한도까지 프로비저닝된 평균 처리량을 기준으로 하며 ‘MB/s-월’ 단위로 측정됩니다.

탄력적 처리량 예제:

파일 시스템이 미국 동부(버지니아 북부) 리전에 있고 31일 한 달간 100GB의 EFS Standard 스토리지를 사용할 수 있다고 가정합니다. 워크로드의 데이터 전송 중 읽기 작업은 75%, 쓰기 작업은 25%이고 하루 3시간 주 3일 동안 최대 처리량은 100MB/s이며 남은 시간 동안은 유휴 상태로 유지된다고 가정합니다.  

총 월별 탄력적 처리량 요금

전송된 모든 데이터는 EFS Standard 스토리지에 대한 것이라고 가정할 때 월말의 사용량(GB)은 다음과 같습니다.

해당 월의 총 탄력적 처리량 데이터(GB): 100MB/s x (60분 x 60초 x 3시간) x 3일 x 4주/1000 = 1만 2,960GB 
총 탄력적 처리량 읽기 데이터(GB): 75% x 1만 2,960GB = 9,720GB
총 탄력적 처리량 쓰기 데이터(GB): 25% x 1만 2,960GB = 3,240GB

이제 탄력적 처리량에 대한 총 월별 요금을 계산합니다. 

탄력적 처리량 읽기 데이터 요금: 9,720GB x 0.03 USD/GB = 291.60 USD 
탄력적 처리량 쓰기 데이터 요금: 3,240GB x 0.06 USD/GB = 194.40 USD
이제 탄력적 처리량에 대한 총 월별 요금을 계산합니다.
총 월별 탄력적 처리량 요금 = 291.60 USD + 194.40 USD = 486.00 USD

프로비저닝된 처리량 예제:

위의 탄력적 처리량 예와 동일한 사항을 가정합니다. 파일 시스템은 미국 동부(버지니아 북부) 리전에 위치하며 한 달 31일 동안 100GB의 EFS Standard 스토리지를 사용할 수 있습니다. 워크로드의 데이터 전송 중 읽기 작업은 75%, 쓰기 작업은 25%이고 하루 3시간 주 3일 동안 최대 처리량은 100MB/s이며
남은 시간 동안은 유휴 상태로 유지됩니다. 월 단위로 비용이 청구되는 처리량은 해당 월에 EFS Standard 스토리지에서 허용하는 크기를 초과하여 프로비저닝된 평균 처리량에 기반합니다(Standard 스토리지 1GB당 50KBps의 기준 처리량).

기준 처리량(MB/s-월) =100GB Standard 스토리지 * 50KBps/1,000 = 5MB/s-월
청구 가능한 총 프로비저닝된 처리량(MB/s-월) = 구성된 처리량 –
기준 처리량 = 100MB/s-월 – 5 MB/s-월 = 95MB/s-월
총 월별 프로비저닝된 처리량 요금 = 95MB/s-월 * 6 USD/MB/s-월 = 570.00 USD

EFS Replication 또는 AWS Backup을 선택적으로 사용하여 데이터를 보호할 수 있습니다. EFS Replication을 사용할 때는 대상 파일 시스템이 다른 AWS 리전에 있는 경우 스토리지, Inrequent Access 및 Archive 클래스의 액세스 요금, 데이터 전송 변경에 대한 요금이 부과됩니다. AWS Backup을 사용하는 경우 한 달에 백업 및 복원한 평균 데이터 양에 대한 요금이 부과됩니다.

복제

이 예제는 EFS Replication을 사용하여 리전 간에 파일 시스템을 복제하는 시나리오를 반영합니다. 이 예제에서는 EFS Replication과 직접적으로 연관된 비용을 중점적으로 살펴봅니다.

미국 동부(버지니아 북부) 리전에 1TB의 데이터가 저장된 EFS 파일 시스템이 있다고 가정해보겠습니다. 이 파일 시스템을 미국 서부(오레곤) 리전에 복제하는 중입니다. 대상 파일 시스템에서 7일 EFS 수명 주기 관리 정책을 사용하여 파일을 EFS IA 클래스로 옮긴다고 가정합니다.

복제를 처음으로 활성화하면 전체 소스 파일 시스템이 대상 파일 시스템에 복사됩니다. 복제된 데이터는 먼저 대상 파일 시스템의 EFS Standard 클래스에 저장됩니다. EFS 수명 주기 관리 정책(7일)의 기간 동안 파일에 액세스하지 않을 경우 파일이 EFS IA 클래스로 옮겨집니다.

초기 동기화:

먼저 대상 파일 시스템의 비례 배분된 스토리지 사용량을 계산합니다.
총 EFS Standard 사용량(시간당 GB): 1,000GB x 7일 x (24시간/일) = 시간당 168.000GB
총 EFS IA 사용량(GB-시간): 1,000GB x 24일 x (24시간/일/한 달 31일) = 57만 6,000GB-시간

다음으로, 스토리지 사용량을 월별 GB로 변환하고, 대상 파일 시스템의 스토리지 요금을 계산합니다.

총 EFS Standard 요금: 16만 8,000 x (1개월/744시간) x 0.30 USD/GB-월 = 67.74 USD
총 EFS IA 요금: 57만 6,000 * (1개월/744시간) * 0.025 USD/GB-월 = 19.36 USD
초기 동기화를 위한 총 스토리지 요금 = 67.74 USD + 19.36 USD = 87.10 USD
그런 다음 소스 파일 시스템에서 대상 파일 시스템으로의 초기 복제에 대한 데이터 전송 요금을 계산합니다.
1TB 데이터의 총 EFS 복제 데이터 전송 요금: 1,000GB * GB당 0.02 USD = 20.00 USD

초기 동기화를 위한 총 요금 = 초기 동기화를 위한 총 스토리지 요금 + 초기 동기화를 위한 총 데이터 전송 요금 = 87.10 USD + 20.00 USD = 107.10 USD

증분 복제:

7일 후에 소스 파일 시스템에서 150GB의 새 데이터가 추가된다고 해보겠습니다. 새 데이터가 대상 파일 시스템에 복제되고 이전과 마찬가지로 수명 주기 관리 정책에 따라 7일간 EFS Standard 클래스에 상주합니다. 새 데이터 150GB의 비례 배분된 스토리지 사용량은 다음과 같이 계산됩니다.

총 EFS Standard 사용량(시간당 GB): 150GB x 7일 x (24시간/일) = 시간당 25,200GB
총 EFS IA 사용량(GB-시간): 150GB x 17일 x (24시간/일) = 6만 1,200GB-시간

다음으로, 스토리지 사용량을 월별 GB로 변환하고, 대상 파일 시스템에 추가된 150GB의 새 데이터에 대한 스토리지 요금을 계산합니다. 

총 EFS Standard 요금: 2만 5,200 x (1개월/744시간) x 0.30 USD/GB-월 = 10.16 USD
총 EFS IA 요금: 6만 1,200 * (1개월/744시간) * 0.025 USD/GB-월 = 2.06 USD
증분 복제를 위한 총 스토리지 요금 = 10.16 USD + 2.06 USD = 12.22 USD

마지막으로, 150GB의 증분 데이터에 대해 데이터 전송 요금을 계산합니다.

증분 복제를 위한 총 데이터 전송 요금: 150GB * 0.02 USD/GB = 3.00 USD
증분 복제를 위한 총 요금 = 증분 복제를 위한 총 스토리지 요금 + 증분 복제를 위한 총 데이터 전송 요금 = 12.22 USD + 3.00 USD = 15.22 USD

EFS Replication 관련 총 요금 = 초기 동기화를 위한 총 요금 + 증분 복제를 위한 총 요금 = 107.10 USD + 15.22 USD = 122.32 USD

백업

백업 요금 예시는 AWS Backup 요금을 참조하세요.

자세한 EFS 요금 정보는 Amazon EFS 요금 페이지를 참조하세요.

달리 명시하지 않는 한 가격에는 VAT 및 해당 판매세를 포함한 관련 조세 공과가 포함되지 않습니다. 청구지 주소가 일본으로 되어 있는 고객의 경우 AWS 서비스 사용 시 일본 소비세의 적용을 받게 됩니다. 자세히 알아보세요.

아래 솔루션 예제는 Amazon EFS TCO와 스토리지 및 처리량 탄력성을 고려한 Amazon EFS의 실질적 TCO를 보여줍니다. Amazon EFS를 사용하면 스토리지 및 처리량이 자동으로 확장 또는 축소되므로 사용하지 않은 스토리지 또는 처리량 용량에 대해 비용을 지불하지 않아도 됩니다. EFS는 고가용성과 내구성을 위해 여러 AZ에 데이터를 자동으로 복제하고, 핫 스토리지 및 콜드 스토리지 클래스 간에 데이터를 자동으로 계층화하여 비용을 최적화합니다.

이에 반해 비탄력적(프로비저닝된) 클라우드 솔루션을 사용하면 사용량이 가장 많을 때 스토리지 및 처리량 용량을 관리해야 하기 때문에 용량 감소가 가능하지 않습니다. 대부분의 프로비저닝된 솔루션 제공업체는 스토리지 증가를 고려하여 스토리지 사용률을 30~50%로 유지하고 처리량 급증을 고려하여 처리량 사용률을 50%로 유지하는 것을 권장합니다. 사용하지 않는 추가 스토리지나 처리량이 필요하지 않은 EFS의 탄력적 모델을 비교하면 실질적 TCO가 최대 60% 저렴합니다.

예제 1 - 범용 워크로드
파일 시스템이 미국 동부(버지니아 북부) 리전에 있고 특정 달의 평균 스토리지 크기가 2.7TB라고 가정해 보겠습니다. 애플리케이션은 25MBps의 최대 처리량으로 연속 읽기 작업을 수행하여 한 달 이내에 총 300GB의 데이터가 전송됩니다.

EFS를 사용하는 경우 이 애플리케이션은 스토리지의 평균 5%(145TB)를 SSD에 저장하고, 스토리지의 최대 20%(527TB)를 Infrequent Access에 저장하고, 나머지 2,027TB의 스토리지를 Archive에 저장하면서 스토리지 비용 총합은 68.47 USD가 됩니다. 추가로 사용 빈도가 낮은 데이터를 Infrequent Access 및 Archive 클래스로 계층화하는 데 워크로드에 2.50 USD가 청구되고, 300GB 데이터를 전송하는 데 드는 탄력적 처리량에 대해 14.00 USD가 청구되어 월별 GB당 0.0315 USD의 TCO가 발생합니다.

프로비저닝된 클라우드 솔루션을 사용하면 애플리케이션에서 압축과 같은 스토리지 최적화의 이점을 활용하면서 총 스토리지 크기를 50%(1,350TB) 줄일 수 있습니다. 사용량 패턴을 기반으로 핫 데이터의 5%(68TB)가 SSD에 저장될 것으로 예상됩니다. 이 솔루션은 프로비저닝된 클라우드 솔루션이며 자동으로 확장/축소되지 않으므로 50%의 스토리지 사용률로 운영하고 136TB를 프로비저닝하는 것이 권장됩니다. 나머지 95%의 스토리지(1,282TB)는 사용 빈도가 낮은 스토리지 클래스에 저장되므로 스토리지 비용은 90.15 USD가 됩니다. 추가로 50% 사용률로 처리량을 운영하라는 권장 사항에 따라 처리량을 50MBps로 프로비저닝하면서 TCO는 월별 GB당 0.0797 USD가 됩니다.

 

	EFS	프로비저닝된 솔루션
스토리지
평균 총 스토리지(월별 GB당)	2,700	2,700
평균 총 유료 스토리지(월별 GB당)	2,700	*1,350
SSD 기반 스토리지(월별 GB당)	145	**136
IA 스토리지(월별 GB당)	527	**1,282
Archive 스토리지(월별 GB당)	2,027	0
SSD 스토리지(월별 USD)	43.55 USD	34.00 USD
콜드 스토리지(월별 USD)	8.70 USD	56.15 USD
Archive 스토리지(월별 USD)	16.22 USD
총 스토리지 비용	68.47 USD	90.15 USD
데이터 계층화	2.50 USD
처리량
프로비저닝된 처리량(MBps)		***50
전송된 총 데이터(GB)	300
처리량 비용	14.00 USD	125.00 USD
총 비용	84.97 USD	215.15 USD
실질적 GB당 USD	0.0315 USD	0.0797 USD
EFS 절감(%)	60%

*압축과 같은 최적화를 통한 50% 스토리지 감소 혜택을 가정

**압축된 데이터의 5%가 SSD 클래스에 저장되고, 50% 사용률로 실행되도록 프로비저닝되고, 월별 GB당 0.25 USD의 요금이 부과된다고 가정합니다. 압축된 데이터의 나머지 95%는 사용 빈도가 낮은 스토리지 클래스에 월별 GB당 0.0483 USD의 요금으로 저장됩니다.
***처리량이 MBps당 2.50 USD의 요금에 50% 사용률로 프로비저닝되었다고 가정합니다.

 

 

예제 2 - 스크래치 데이터 워크로드

주식 시장 모델링 워크로드가 하루 2시간 동안 분석을 실행하고 2시간의 실행 동안 임시 데이터를 저장해야 한다고 가정해 보겠습니다. 파일 시스템이 미국 동부(버지니아 북부) 리전에 있고 2시간의 실행 도중 1,024GB의 평균 SSD 스토리지 크기를 포함한다고 가정해 보겠습니다. 애플리케이션은 500MBps의 최대 처리량으로 연속 읽기 및 쓰기 작업을 수행하여 매일 총 175GB의 데이터가 전송됩니다.

EFS를 사용하면 이 애플리케이션은 매달 60시간(30일 동안 매일 2시간) 동안 데이터를 SSD에 저장하고 5,250GB의 데이터를 전송하므로, 총 비용은 월 222.48 USD입니다.

프로비저닝된 클라우드 솔루션을 사용하면 파일 시스템에서 스토리지 공간을 50%까지 줄일 수 있는 압축과 같은 스토리지 최적화의 이점을 누릴 수 있지만 최대 스토리지 지원을 위해 30% 버퍼를 추가로 구성해야 하므로(1,024GB * 50% 압축 + 30% 버퍼 = 666GB) 총 비용은 월별 GB당 1,416.50 USD가 됩니다.

EFS의 탄력성 혜택을 사용하면 사용한 만큼만 비용을 지불하고 TCO를 84% 절감할 수 있습니다.

 

	EFS	프로비저닝된 솔루션
스토리지
총 스토리지(월별 GB당)	1,024	***666
월별 SSD 스토리지 사용 시간	*60	720
SSD 월별 스토리지 비용(월별 USD)	25.60 USD	166.50 USD
처리량
프로비저닝된 처리량(MBps)		500
월별 전송된 데이터(GB)	5,250
처리량 비용	**196.88 USD	1,250.00 USD
총 비용	222.48 USD	1,416.50 USD
실질적 GB당 USD	0.2172 USD	1.3822 USD
EFS 절감(%)	84%

* EFS 데이터가 30일 동안 하루 2시간 저장된다고 가정합니다.

** 전송된 Gb당 0.0375 USD의 혼합 탄력적 처리량 비용을 가정

***압축과 같은 최적화를 통한 50% 스토리지 감소 혜택과 최대 사용량 지원을 위한 추가 30% 버퍼를 가정

예. 태스크 정의에서 EFS 파일 시스템을 참조하여 EC2 및 Fargate 시작 유형 모두를 사용해 Amazon ECS에서 시작된 컨테이너식 애플리케이션에서 EFS에 액세스할 수 있습니다. 시작하는 방법에 대한 지침은 ECS 설명서를 참조하세요.

예. EFS CSI 드라이버를 사용하는 EC2 또는 Fargate 시작 유형으로 Amazon EKS에서 시작된 컨테이너식 애플리케이션에서 EFS에 액세스할 수 있습니다. 시작하는 방법에 대한 지침은 EKS 설명서를 참조하세요.

예. 함수 설정의 EFS 파일 시스템을 참조하여 Lambda에서 실행하는 함수에서 EFS에 액세스할 수 있습니다. 시작하는 방법에 대한 지침은 Lambda 설명서를 참조하세요.

예. CreateTrainingJob 요청에서 EFS 파일 시스템을 참조하여 Amazon SageMaker 훈련 작업으로부터 EFS의 훈련 데이터에 액세스할 수 있습니다. EFS는 SageMaker Studio에서 생성된 홈 디렉터리에도 자동으로 사용됩니다.