EFS편집자 확인

EFS는 표준 NFS 프로토콜을 통해 파일 시스템 인터페이스를 제공한다. 주로 NFSv4.0 및 NFSv4.1 프로토콜을 지원하며, 이를 통해 리눅스 기반 EC2 인스턴스, 온프레미스 서버, AWS Lambda 함수, 컨테이너 등 다양한 클라이언트에서 파일을 공유하고 액세스할 수 있다. 이 표준 프로토콜 지원 덕분에 기존 애플리케이션을 수정 없이 EFS로 마이그레이션하는 것이 가능해진다.

클라이언트는 POSIX 파일 시스템 세마포어를 포함한 표준 파일 시스템 작업을 수행할 수 있다. 이는 파일 및 디렉터리 생성, 읽기, 쓰기, 삭제와 같은 기본적인 작업뿐만 아니라 파일 잠금과 같은 고급 기능도 포함한다. POSIX 호환성은 애플리케이션이 기대하는 파일 시스템 동작을 보장하여 호환성 문제를 최소화한다.

네트워크를 통한 접근은 VPC 내의 마운트 타겟을 통해 이루어진다. 클라이언트는 표준 mount 명령이나 Amazon Linux의 amazon-efs-utils와 같은 도구를 사용하여 파일 시스템을 마운트한다. 주요 지원 프로토콜과 특징은 다음과 같다.

이 인터페이스는 완전관리형 서비스로서의 이점과 결합되어, 사용자가 서버 프로비저닝이나 프로토콜 구성과 같은 인프라 관리 부담 없이 완전한 파일 시스템 기능을 활용할 수 있게 한다.

EFS는 데이터의 접근 빈도와 비용 최적화 요구에 따라 선택할 수 있는 여러 스토리지 클래스를 제공한다. 각 클래스는 내구성, 가용성, 성능 및 가격이 다르게 설계되어 다양한 워크로드에 맞춰 유연하게 사용할 수 있다.

주요 스토리지 클래스는 다음과 같다.

사용자는 라이프사이클 관리 정책을 설정하여 파일의 마지막 접근 시간을 기준으로 스토리지 클래스를 자동으로 전환할 수 있다. 예를 들어, 30일 동안 접근하지 않은 파일은 표준 클래스에서 EFS IA로, 90일 동안 접근하지 않은 파일은 EFS Archive로 이동하도록 정책을 구성할 수 있다. 이는 수동 개입 없이도 스토리지 비용을 효과적으로 절감하는 데 도움을 준다.

EFS는 미사용 데이터 암호화와 전송 중 데이터 암호화를 모두 지원하여 데이터 보안을 강화한다. 기본적으로 모든 새로운 EFS 파일 시스템은 생성 시점에 AWS Key Management Service를 사용한 미사용 데이터 암호화가 활성화된다. 이때 AWS KMS의 기본 고객 마스터 키를 사용하거나, 사용자가 직접 생성하고 관리하는 고객 관리형 키를 선택할 수 있다. 암호화는 파일 시스템의 모든 데이터와 메타데이터에 적용된다.

전송 중 데이터 보호를 위해 EFS는 TLS를 통한 암호화된 연결을 지원한다. 클라이언트가 EFS 파일 시스템에 마운트할 때, 암호화된 전송 옵션을 활성화하면 NFS 트래픽이 TLS 1.2를 사용하여 암호화된다. 이는 Amazon EC2 인스턴스, 온프레미스 서버, AWS Direct Connect 또는 VPN 연결을 통한 접근 모두에 적용 가능하다.

암호화 설정은 파일 시스템 생성 과정에서 결정되며, 이후 변경할 수 없다. 따라서 보안 요구 사항을 사전에 평가하는 것이 중요하다. 고객 관리형 키를 사용하면 키 정책, 회전 주기, 접근 제어를 세밀하게 관리할 수 있어 규정 준수 요건을 충족하는 데 유리하다.

라이프사이클 관리는 EFS에서 스토리지 비용을 자동으로 최적화하기 위한 기능이다. 이 기능은 파일 시스템 내 오래되거나 덜 자주 액세스되는 데이터를 더 비용 효율적인 스토리지 티어로 이동하는 정책 기반의 자동화된 프로세스를 제공한다.

사용자는 파일 액세스 패턴을 기반으로 라이프사이클 정책을 구성할 수 있다. 기본적으로 파일은 표준 스토리지 클래스에 저장된다. 사용자가 설정한 기간(예: 7일, 14일, 30일, 60일, 90일) 동안 액세스되지 않은 파일은 EFS가 자동으로 EFS Infrequent Access 스토리지 클래스로 이동시킨다[2]. 이 프로세스는 완전히 관리되며, 애플리케이션에 대한 파일 시스템의 네임스페이스나 접근성에는 변화가 없다.

라이프사이클 관리를 통해 스토리지 비용을 상당히 절감할 수 있다. EFS Infrequent Access 스토리지 클래스는 기가바이트당 요금이 표준 스토리지 클래스보다 낮지만, 파일을 읽거나 쓸 때 적용되는 추가적인 데이터 처리 요금이 존재한다. 따라서 액세스 빈도가 낮은 데이터(예: 백업 아카이브, 오래된 로그 파일, 역사적 데이터 세트)를 저장하는 데 이상적이다. 이 기능은 특히 용량이 지속적으로 증가하는 파일 시스템에서 비용 효율성을 유지하는 데 핵심적인 역할을 한다.

EFS는 컨테이너화된 애플리케이션과 마이크로서비스 아키텍처에 적합한 공유 파일 스토리지를 제공한다. 컨테이너는 기본적으로 무상태(stateless)로 설계되지만, 애플리케이션에 따라 로그, 설정 파일, 업로드된 콘텐츠 또는 세션 데이터와 같은 상태 정보를 유지해야 하는 경우가 있다. EFS는 여러 Amazon EC2 인스턴스나 AWS Fargate에서 실행되는 Amazon ECS 또는 Amazon EKS 태스크/포드가 동시에 접근할 수 있는 영구적이고 탄력적인 공유 볼륨을 마운트할 수 있게 한다.

이를 통해 동일한 데이터 세트에 대한 공유 액세스가 필요한 분산 애플리케이션을 쉽게 구축할 수 있다. 예를 들어, 웹 애플리케이션 팜에서 사용자 업로드 파일을 모든 웹 서버가 접근 가능한 중앙 위치에 저장하거나, 배치 처리 작업들이 공통의 입력 데이터를 읽고 결과를 동일한 출력 디렉터리에 기록하는 시나리오에 적합하다. 컨테이너 오케스트레이션 서비스인 ECS와 EKS는 EFS 볼륨을 태스크 정의나 퍼시스턴트 볼륨(PV)으로 직접 통합하여 사용할 수 있다.

EFS의 주요 장점은 탄력적인 용량 관리와 다중 가용 영역(AZ)에 걸친 내구성이다. 컨테이너 기반 애플리케이션은 수평적으로 확장되거나 축소될 수 있으며, EFS는 이러한 변화에 맞춰 자동으로 용량을 조정한다. 개발자는 스토리지 용량을 미리 프로비저닝하거나 관리할 필요가 없다. 또한 파일 시스템이 여러 AZ에 자동으로 복제되어 단일 AZ 장애로부터 데이터를 보호하므로, 고가용성을 요구하는 마이크로서비스에 안정적인 스토리지 기반을 제공한다.

EFS는 빅 데이터 및 분석 워크로드에서 공유 데이터 소스를 위한 확장 가능한 스토리지 계층으로 활용된다. 여러 EC2 인스턴스, EMR 클러스터의 노드, 또는 AWS Lambda 함수가 동일한 데이터셋에 동시에 접근해야 하는 경우에 적합하다. 예를 들어, 로그 파일, 센서 데이터, 트랜잭션 기록과 같은 대규모 데이터를 중앙 집중식으로 저장하고, 다양한 분석 애플리케이션이 이를 읽어 ETL 작업을 수행하거나 머신러닝 모델 학습에 사용할 수 있다.

주요 장점은 펫바이트 규모까지 자동으로 확장되는 탄력적 용량과, 수천 개의 NFS 클라이언트로부터의 초당 수만 건의 IOPS를 처리할 수 있는 처리량 성능에 있다. 특히 빠른 성능 모드를 선택하면 높은 메타데이터 처리 성능을 제공하여, 수백만 개의 작은 파일로 구성된 데이터 레이크에서도 효율적인 파일 조회가 가능하다. 이는 Apache Spark, Hadoop (HDFS 대체), Presto 등의 분산 처리 프레임워크와 통합되어 사용될 때 유리하다.

다음은 EFS가 빅 데이터 파이프라인에서 주로 사용되는 몇 가지 구체적인 패턴이다.

이러한 워크로드는 표준 스토리지 클래스와 EFS 인프라 액세스 포인트를 결합하여 특정 애플리케이션에 대한 파일 시스템 접근을 제한하고 관리 효율성을 높일 수 있다. 또한, 주기적으로 접근 빈도가 낮아지는 데이터에 대해서는 EFS Intelligent-Tiering 또는 수동으로 EFS One Zone-Infrequent Access 스토리지 클래스로 이동시켜 비용을 최적화할 수 있다[3].

콘텐츠 관리 시스템은 웹사이트의 텍스트, 이미지, 비디오 등 디지털 콘텐츠를 생성, 관리, 게시하는 데 사용되는 애플리케이션입니다. EFS는 이러한 시스템에 필요한 공유 파일 스토리지 레이어를 제공하는 데 적합합니다. 여러 웹 서버 인스턴스가 동일한 파일 시스템에 접근하여 콘텐츠와 애플리케이션 코드를 공유할 수 있게 하여, 확장성과 고가용성을 보장합니다.

EFS를 CMS 백엔드 스토리지로 사용할 때의 주요 이점은 다음과 같습니다. 첫째, 서버 인스턴스 수를 자동으로 조정하는 오토 스케일링 그룹과 쉽게 통합됩니다. 사용자 트래픽이 증가하면 새로운 웹 서버가 프로비저닝되고 기존 EFS 파일 시스템에 즉시 마운트되어 모든 서버가 일관된 최신 콘텐츠를 제공합니다. 둘째, 다중 AZ 내구성 덕분에 단일 가용 영역 장애 시에도 미디어 파일과 업로드된 콘텐츠가 안전하게 보호됩니다.

일반적인 아키텍처는 Amazon EC2 인스턴스나 컨테이너에서 실행되는 WordPress, Drupal, Joomla와 같은 CMS 애플리케이션이 EFS를 공유 스토리지로 사용하도록 구성하는 것입니다. 이때 애플리케이션 코드 자체는 EFS에 저장할 수 있지만, 성능을 위해 로컬 인스턴스 스토리지에 배포하는 것이 더 일반적입니다. 반면 사용자가 업로드한 미디어 파일, 플러그인, 테마 파일, 세션 데이터 등 변경이 빈번한 콘텐츠는 EFS에 저장하여 모든 인스턴스에서 접근 가능하게 합니다.

이러한 구성은 관리형 데이터베이스 서비스인 Amazon RDS와 결합될 때 특히 효과적입니다. 결과적으로 CMS는 완전히 스테이트리스(stateless) 아키텍처로 운영될 수 있으며, 이는 로드 밸런서 뒤의 어떤 웹 서버 인스턴스도 사용자 요청을 처리할 수 있음을 의미합니다.

EFS 파일 시스템을 생성하는 과정은 AWS Management Console, AWS CLI, AWS CloudFormation 또는 Terraform과 같은 인프라스트럭처 코드 도구를 통해 수행된다. 생성 시에는 파일 시스템의 이름, 가용 영역 배치 방식(표준 또는 One Zone), 성능 모드(범용 또는 Max I/O), 처리량 모드(버스팅, 프로비저닝, 탄력적) 등의 기본 속성을 설정한다. 또한 생성 단계에서 AWS Key Management Service를 사용한 데이터 암호화를 활성화할 수 있다.

생성된 파일 시스템은 Amazon EC2, AWS Lambda, Amazon ECS, Amazon EKS 등 다양한 컴퓨팅 서비스에 마운트하여 사용한다. 마운트를 위해서는 클라이언트에 NFS 클라이언트가 설치되어 있어야 하며, EFS 마운트 도우미를 사용하면 마운트 과정을 단순화할 수 있다. 마운트 명령은 파일 시스템의 DNS 이름을 사용하며, 특정 액세스 포인트를 지정하여 마운트할 수도 있다.

마운트 후에는 표준 파일 시스템 명령어를 사용하여 디렉터리 생성, 파일 읽기/쓰기 등의 작업을 수행할 수 있다. EFS는 탄력적이므로 용량을 미리 프로비저닝하거나 확장 작업 없이도 데이터를 추가할 수 있다.

EFS는 두 가지 성능 모드를 제공하여 다양한 워크로드의 처리량과 지연 시간 요구사항에 맞게 최적화할 수 있다. 사용자는 파일 시스템 생성 시 또는 이후에 성능 모드를 선택할 수 있다.

범용 모드는 대부분의 사용 사례에 권장되는 기본 설정이다. 이 모드는 짧은 지연 시간을 유지하면서도 확장성을 제공한다. 반면, 최대 I/O 모드는 수천 개의 EC2 인스턴스나 컨테이너가 동시에 파일 시스템에 접근하는 대규모 병렬 워크로드에 적합하다. 이 모드는 높은 집계 처리량과 초당 IOPS를 제공하도록 설계되었다.

성능 모드는 파일 시스템 생성 후에도 변경할 수 있다. 단, 변경 작업은 몇 분 정도 소요되며, 이 동안 파일 시스템은 사용 가능한 상태를 유지하지만 성능이 일시적으로 저하될 수 있다. 워크로드의 특성과 성능 요구사항을 신중히 평가한 후 적절한 모드를 선택하는 것이 중요하다.

EFS는 AWS Backup 서비스를 통한 자동화된 백업과 파일 시스템 수준의 복구 기능을 제공하여 데이터 보호를 강화한다. 사용자는 AWS Management Console, AWS CLI, 또는 AWS SDK를 통해 백업 계획을 생성하고, 백업 빈도(예: 매일, 매주)와 보존 기간을 정의할 수 있다. 이러한 백업은 자동으로 생성되어 Amazon S3에 안전하게 저장되며, 별도의 관리 오버헤드 없이 데이터의 내구성을 보장한다.

파일 시스템의 특정 시점으로 복구하는 작업은 간단한 프로세스로 수행된다. 사용자는 복원하려는 백업 복사본을 선택하고, 기존 EFS 파일 시스템에 덮어쓰거나 새로운 파일 시스템으로 복원할 수 있다. 이 과정은 파일 시스템의 메타데이터와 실제 데이터를 모두 포함한 완전한 상태를 복구한다.

데이터 손실 위험을 최소화하기 위해 EFS는 기본적으로 다중 가용 영역에 데이터를 저장하여 높은 내구성을 제공한다. 백업 정책은 이러한 내장된 내구성에 추가적인 보호 계층을 형성하며, 실수로 인한 삭제나 악의적인 활동으로부터 데이터를 보호하는 데 핵심적인 역할을 한다.

IAM 정책은 EFS 파일 시스템에 대한 접근 권한을 제어하는 핵심 메커니즘이다. 이 정책은 "누가(Who)" "어떤 리소스에(Which Resource)" "무엇을 할 수 있는지(What Action)"를 정의하는 JSON 형식의 문서이다. IAM 정책은 파일 시스템 수준에서 적용되며, AWS 계정 내의 IAM 사용자, IAM 역할, IAM 그룹 또는 다른 AWS 계정에 대한 세분화된 권한을 부여하거나 거부할 수 있다.

EFS에 적용되는 주요 IAM 정책 요소는 다음과 같다.

정책은 특정 조건(Condition)을 추가하여 더욱 세밀하게 제어할 수 있다. 예를 들어, 특정 VPC나 서브넷에서만 접근을 허용하거나, 암호화가 활성화된 파일 시스템에 대한 작업만 허용하도록 조건을 설정할 수 있다. IAM 정책은 네트워크 접근 제어 목록(NACL)이나 보안 그룹과 같은 네트워크 계층의 제어와는 별개로, 인증된 주체의 행위 자체를 규정한다는 점에서 차이가 있다[5].

정책 관리 시 주의할 점은 최소 권한의 원칙을 따르는 것이다. 예를 들어, 특정 애플리케이션 역할이 특정 EFS에 대해 읽기 전용 접근만 필요하다면, ClientWrite나 ClientRootAccess 권한은 부여하지 않아야 한다. IAM 정책은 AWS Management Console, AWS CLI, 또는 AWS SDK를 통해 생성, 연결 및 관리할 수 있다.

EFS 파일 시스템에 대한 네트워크 수준의 접근은 보안 그룹과 VPC 엔드포인트를 통해 제어된다. 각 EFS 파일 시스템은 특정 VPC 내에 생성되며, 파일 시스템에 접근하려는 EC2 인스턴스나 다른 클라이언트는 동일한 VPC에 위치하거나 VPC 피어링, AWS Direct Connect, VPN 연결 등을 통해 연결되어야 한다. 클라이언트의 실제 접근 허용 여부는 파일 시스템에 연결된 보안 그룹의 인바운드 규칙에 의해 결정된다. 이 보안 그룹 규칙은 특정 IP 주소 범위(CIDR 블록)나 다른 보안 그룹을 소스로 지정하여, 특정 네트워크 트래픽만 NFS 프로토콜(기본 포트 2049)을 통해 파일 시스템에 도달할 수 있도록 한다.

VPC 외부의 온프레미스 서버나 다른 AWS 리전의 서비스에서 EFS에 접근해야 하는 경우, AWS PrivateLink 기술을 기반으로 하는 VPC 엔드포인트를 생성하여 사용할 수 있다. 이 엔드포인트는 퍼블릭 인터넷을 경유하지 않고 프라이빗 IP 주소를 통해 VPC 내부의 EFS 서비스에 안전하게 연결하는 게이트웨이 역할을 한다. 이를 구성하면 온프레미스 네트워크와 VPC 사이에 구축된 연결(VPN 또는 Direct Connect)을 통해 마치 로컬 네트워크에 있는 것처럼 EFS 파일 시스템을 마운트할 수 있다.

네트워크 접근 제어 설정은 일반적으로 다음 단계를 따른다.

이러한 메커니즘을 통해 관리자는 네트워크 경로와 트래픽 소스를 세밀하게 제한함으로써, 허가된 리소스만 EFS 스토리지에 접근할 수 있도록 강력한 네트워크 보안 경계를 구축할 수 있다.

EFS는 저장 및 전송 중 데이터를 암호화하는 기능을 제공하여 민감한 정보를 보호한다. 암호화는 파일 시스템 생성 시 활성화할 수 있으며, 이후에는 변경이 불가능하다. 이 기능을 사용하면 AWS Key Management Service에서 관리하는 고객 마스터 키를 통해 데이터를 암호화한다.

전송 중 암호화는 TLS를 사용하여 구현된다. EC2 인스턴스나 온프레미스 서버가 EFS 파일 시스템에 연결할 때, 암호화된 전송 옵션을 활성화하면 모든 네트워크 트래픽이 보호된다. 이는 NFS 프로토콜을 통한 데이터 이동 시 도청이나 변조를 방지한다.

저장 데이터(데이터 액세스) 암호화는 AES-256 암호화 알고리즘을 사용한다. 암호화 키는 사용자가 선택한 CMK로 관리되며, 키 순환 정책을 설정할 수 있다. 암호화된 파일 시스템의 성능은 암호화되지 않은 파일 시스템과 동일한 수준을 유지한다[6].

파일 시스템의 루트 디렉토리 메타데이터와 모든 파일 및 디렉토리 내용은 암호화 대상에 포함된다. 이는 EFS가 PCI-DSS, HIPAA, FedRAMP와 같은 다양한 규정 준수 요구사항을 충족하는 데 기여한다.

Amazon EFS는 사용 사례와 비용 요구 사항에 맞게 선택할 수 있는 여러 스토리지 클래스를 제공한다. 각 클래스는 성능, 가용성, 비용 측면에서 다른 특성을 가지며, 데이터의 접근 패턴에 따라 적절한 클래스를 선택하면 비용을 효율적으로 관리할 수 있다.

주요 스토리지 클래스는 다음과 같다.

비용 최적화를 위해서는 라이프사이클 관리 기능을 활성화하는 것이 효과적이다. 이 기능을 설정하면, 사용자가 지정한 기간 동안 액세스되지 않은 파일을 자동으로 더 저렴한 스토리지 클래스(EFS IA 또는 EFS Archive)로 이동시킨다. 예를 들어, 30일 동안 액세스되지 않은 파일은 EFS IA로, 90일 동안 액세스되지 않은 파일은 EFS Archive로 이동하는 정책을 구성할 수 있다. 이는 수동으로 데이터를 관리할 필요 없이 스토리지 비용을 자동으로 절감해 준다.

사용자는 애플리케이션의 데이터 접근 패턴을 분석하여 라이프사이클 정책을 세밀하게 조정해야 한다. 너무 공격적인 정책(예: 7일 후 IA로 이동)은 자주 재액세스되는 데이터가 저비용 티어로 이동되어 오히려 더 높은 액세스 비용을 초래할 수 있다. 반면, 너무 보수적인 정책은 비용 절감 효과를 제한한다. 따라서 모니터링 도구를 활용해 파일 시스템의 액세스 패턴을 지속적으로 관찰하고 정책을 조정하는 것이 좋다.

라이프사이클 정책 설정은 Amazon EFS의 비용을 자동으로 최적화하기 위한 핵심 기능이다. 이 정책을 사용하면 사용 빈도가 낮은 파일을 더 저렴한 스토리지 클래스로 자동 이동시켜 전체 스토리지 비용을 절감할 수 있다.

정책은 파일이 마지막으로 액세스된 날짜를 기준으로 작동한다. 관리자는 파일이 액세스되지 않은 상태로 유지되는 기간(예: 7일, 14일, 30일, 60일, 90일)을 설정하여 파일을 EFS Infrequent Access 스토리지 클래스로 전환하도록 라이프사이클 정책을 구성한다. 예를 들어, 30일 정책을 설정하면, 마지막 액세스 후 30일이 지난 파일은 자동으로 표준 스토리지에서 IA 스토리지로 이동한다. 이 전환은 파일 시스템 수준에서 투명하게 이루어지며, 애플리케이션은 파일의 물리적 위치 변경 없이 동일한 경로를 통해 계속 액세스할 수 있다.

라이프사이클 관리는 AWS Management Console, AWS CLI, 또는 AWS SDK를 통해 설정할 수 있다. 정책을 적용할 때는 워크로드의 데이터 액세스 패턴을 신중하게 고려해야 한다. 빈번히 재액세스되는 파일이 IA 티어로 전환되면, 해당 파일을 읽거나 쓸 때 추가적인 요금이 발생할 수 있기 때문이다[8]. 따라서 로그 아카이빙, 미디어 자산 보관, 장기 백업 저장과 같이 액세스 빈도가 시간이 지남에 따라 급격히 떨어지는 사용 사례에 가장 효과적이다.

Amazon FSx는 AWS에서 제공하는 완전관리형 파일 스토리지 서비스군이다. EFS가 NFS 프로토콜을 기반으로 한 범용 파일 시스템이라면, FSx는 특정 워크로드와 프로토콜에 최적화된 여러 종류의 파일 시스템을 제공한다는 점에서 차별점을 가진다.

주요 FSx 제품군은 다음과 같다.

사용자는 애플리케이션 요구사항에 따라 적절한 FSx 파일 시스템을 선택한다. 예를 들어, Windows 서버나 Microsoft SQL Server를 위한 공유 스토리지가 필요하면 FSx for Windows File Server를, 대규모 병렬 처리 작업이 필요한 HPC 워크로드에는 FSx for Lustre를 사용한다. FSx for ONTAP과 FSx for OpenZFS는 각각 NetApp ONTAP과 OpenZFS의 고급 데이터 관리 기능을 완전관리형 서비스로 제공한다.

EFS와의 핵심적인 비교는 프로토콜 지원과 확장 모델에 있다. EFS는 리눅스 중심의 NFSv4 프로토콜만 지원하며, 사용량에 따라 자동으로 확장되는 탄력적인 용량 모델을 가진다. 반면, FSx 서비스들은 특정 프로토콜(SMB, Lustre 등)에 최적화되어 있으며, 용량을 프로비저닝하거나 사용량 기반으로 설정할 수 있다. 또한, EFS는 기본적으로 다중 가용 영역(AZ)에 데이터를 분산 저장하지만, FSx 제품별로 단일 AZ 또는 다중 AZ 배포 옵션이 상이하다.

Amazon S3(Simple Storage Service)는 AWS가 제공하는 객체 스토리지 서비스이다. EFS가 파일 시스템 인터페이스를 제공하는 네트워크 파일 스토리지인 반면, S3는 RESTful API를 통해 접근하는 객체 기반의 무제한 스토리지 서비스이다. 데이터는 버킷(Bucket)이라는 컨테이너에 객체(Object) 형태로 저장되며, 각 객체는 고유한 키와 메타데이터를 가진다.

두 서비스의 주요 차이점은 데이터 접근 방식과 사용 사례에 있다. EFS는 표준 파일 시스템 프로토콜(NFS)을 사용하여 여러 EC2 인스턴스나 온프레미스 서버에서 동시에 공유 접근이 필요한 워크로드에 적합하다. 반면 S3는 웹 규모의 데이터 레이크, 정적 웹사이트 호스팅, 백업 및 아카이브, 데이터 분석과 같이 대규모 비정형 데이터를 저장하고 애플리케이션 수준에서 접근하는 데 최적화되어 있다.

다음은 EFS와 S3의 핵심 특성을 비교한 표이다.

따라서, 애플리케이션이 파일 시스템 의미 체계(예: 파일 잠금, 디렉터리 계층 구조)를 필요로 하거나 여러 컴퓨팅 노드에서 동일한 데이터 세트에 동시에 액세스해야 하는 경우에는 EFS를 선택한다. 반면, 거의 무제한의 확장성과 내구성이 필요하며 애플리케이션이 객체 기반 API를 통해 데이터를 관리할 수 있는 경우에는 S3가 더 적합한 선택이 된다.

EBS 볼륨은 단일 가용 영역에 연결된 블록 스토리지 서비스이다. 주로 단일 EC2 인스턴스에 영구적인 디스크 볼륨을 제공하기 위해 설계되었다. EBS 볼륨은 인스턴스에 물리적으로 연결된 하드 드라이브처럼 작동하며, 파일 시스템을 포맷하고 운영 체제 및 애플리케이션 데이터를 저장하는 데 사용된다.

EFS와의 주요 차이점은 액세스 방식과 확장성에 있다. EBS 볼륨은 일반적으로 연결된 단일 EC2 인스턴스에서만 액세스할 수 있다. 반면 EFS는 NFS 프로토콜을 통해 다수의 인스턴스, 컨테이너, 서버리스 함수 등에서 동시에 공유 액세스가 가능한 네트워크 파일 시스템이다. 또한 EBS 볼륨의 용량은 프로비저닝 시 미리 결정되며, 필요 시 수동으로 확장해야 하지만, EFS는 사용량에 따라 자동으로 탄력적으로 확장된다.

다음 표는 EFS와 EBS 볼륨의 핵심 특성을 비교한다.

따라서, 단일 인스턴스에 고성능의 낮은 지연 시간 블록 스토리지가 필요하거나 데이터베이스 워크로드를 운영할 경우 EBS 볼륨이 적합하다. 반면, 여러 컴퓨팅 리소스가 공통 데이터 세트에 동시에 액세스해야 하는 분산 애플리케이션에는 EFS가 더 적절한 선택이다.