여러 EC2 인스턴스 간 폴더 공유: EBS vs EFS 완전 비교 가이드

5개의 EC2 인스턴스가 동일한 디렉토리를 읽고 써야 하는 상황이 생겼다. 처음엔 EBS 볼륨 하나를 여러 인스턴스에 붙이면 되지 않을까 생각했는데, 실제로 해보려고 하면 콘솔에서 막히거나 데이터가 꼬이는 경험을 하게 된다. 이 글은 여러 EC2 인스턴스 간 스토리지 공유 문제를 EBS와 EFS 관점에서 실제 운영 경험 기반으로 정리한다.

TL;DR — EBS vs EFS 핵심 비교

항목 EBS (일반 볼륨) EBS Multi-Attach EFS
동시 다중 인스턴스 마운트 ❌ 불가 ⚠️ 제한적 가능 ✅ 기본 지원
파일시스템 공유 ❌ ❌ (클러스터 파일시스템 필요) ✅ NFS v4.1/4.2
AZ 제약 동일 AZ만 동일 AZ만 리전 전체 (멀티 AZ)
일반적 공유 폴더 용도 ❌ ❌ ✅
운영 복잡도 낮음 높음 낮음

결론부터: 5개 EC2 인스턴스가 동일 폴더를 공유하려면 EFS를 사용해야 한다. EBS는 구조적으로 단일 인스턴스 전용 블록 스토리지이며, Multi-Attach는 공유 파일시스템을 제공하지 않는다.

EBS와 EFS의 동작 원리 — 왜 EBS는 공유가 안 되는가

EBS는 블록 스토리지다. 인스턴스에 마운트되면 해당 OS가 파일시스템(ext4, xfs 등)을 직접 관리한다. 두 인스턴스가 동시에 같은 EBS 볼륨을 마운트하면, 각 OS가 독립적으로 파일시스템 메타데이터를 쓰게 되어 데이터 손상이 발생한다. 이건 AWS 제약이 아니라 블록 스토리지의 근본적인 특성이다.

EBS를 두 인스턴스에 동시 마운트하는 건, 두 사람이 동시에 같은 하드디스크를 각자의 PC에 꽂고 파일을 수정하는 것과 같다. 파일시스템 저널이 충돌하면서 데이터가 조용히 깨진다.

EFS는 완전히 다른 계층에서 동작한다. NFS v4.1/4.2 프로토콜 기반의 관리형 파일시스템으로, 인스턴스들은 네트워크를 통해 EFS 마운트 타겟에 접속한다. 파일시스템 상태는 EFS 서비스가 중앙에서 관리하므로, 수백 개의 인스턴스가 동시에 마운트해도 일관성이 보장된다.

graph TD subgraph EBS_Standard["EBS 일반 볼륨"] EC2A["EC2 Instance A"] -- "독점 마운트" --> EBSVol["EBS Volume (ext4/xfs)"] EC2B["EC2 Instance B"] -. "마운트 불가 (데이터 손상 위험)" .-> EBSVol end subgraph EFS_Share["EFS 공유 파일시스템"] EC2C["EC2 Instance 1"] --> MT["EFS Mount Target (NFS 2049)"] EC2D["EC2 Instance 2"] --> MT EC2E["EC2 Instance 3"] --> MT EC2F["EC2 Instance 4"] --> MT EC2G["EC2 Instance 5"] --> MT MT --> EFSFs["EFS File System (NFS v4.1/4.2)"] end
  1. EBS 단일 마운트: 하나의 EC2 인스턴스만 볼륨을 독점적으로 사용한다. OS 레벨 파일시스템이 블록을 직접 관리한다.
  2. EBS Multi-Attach (io1/io2 한정): 동일 AZ 내 최대 16개 인스턴스에 마운트 가능하지만, 표준 파일시스템(ext4, xfs)은 사용할 수 없다. GFS2, OCFS2 같은 클러스터 파일시스템이 별도로 필요하다.
  3. EFS: 모든 인스턴스가 NFS 프로토콜로 마운트 타겟에 연결한다. 파일 잠금, 일관성, 메타데이터 관리를 EFS 서비스가 처리한다.

EBS Multi-Attach — 오해하기 쉬운 함정

Multi-Attach를 보고 '이걸로 공유하면 되겠다'고 생각하는 경우가 많다. 실제로 해보면 마운트는 되는데, 두 번째 인스턴스에서 mount 명령을 실행하는 순간 첫 번째 인스턴스의 파일시스템이 손상되거나 읽기 전용으로 전환된다.

Multi-Attach의 실제 용도는 고가용성 클러스터링이다. Pacemaker + DRBD 같은 클러스터 소프트웨어가 파일시스템 접근을 조율하는 구조에서만 안전하게 쓸 수 있다. 일반적인 '폴더 공유' 시나리오에는 적합하지 않다.

Multi-Attach 제약사항 (AWS 문서 기준):

  • io1 또는 io2 볼륨 타입만 지원
  • 동일 가용 영역(AZ) 내 인스턴스만 가능
  • 최대 16개 인스턴스
  • 클러스터 인식 파일시스템 필수 — 표준 파일시스템으로는 데이터 손상 발생
  • 부트 볼륨으로 사용 불가

EFS로 여러 EC2 인스턴스 간 폴더 공유 구성하기

실제 5개 인스턴스에 EFS를 마운트하는 전체 흐름을 단계별로 정리한다.

sequenceDiagram participant Admin as 관리자 participant EFS as EFS 서비스 participant SG as 보안 그룹 participant EC2 as EC2 인스턴스들 Admin->>EFS: 1. 파일시스템 생성 EFS-->>Admin: FileSystemId 반환 Admin->>SG: 2. EFS용 SG 생성 (2049/tcp 인바운드) Admin->>EFS: 3. AZ별 마운트 타겟 생성 EFS-->>Admin: 마운트 타겟 available Admin->>EC2: 4. amazon-efs-utils 설치 Admin->>EC2: 5. mount -t efs (TLS) EC2->>EFS: NFS 연결 수립 EFS-->>EC2: 파일시스템 마운트 완료 Admin->>EC2: 6. /etc/fstab 등록 (재부팅 대비)

Step 1: EFS 파일시스템 생성

EFS 파일시스템을 생성한다. 성능 모드와 처리량 모드는 워크로드 특성에 따라 선택한다. 일반적인 공유 폴더 용도라면 기본값(범용 성능 모드, 탄력적 처리량)으로 시작하는 것이 적절하다.

aws efs create-file-system \
  --performance-mode generalPurpose \
  --throughput-mode elastic \
  --encrypted \
  --region us-east-1 \
  --tags Key=Name,Value=shared-folder-efs

출력에서 FileSystemId를 기록해둔다. 이후 단계에서 계속 사용한다.

Step 2: 마운트 타겟용 보안 그룹 생성

EFS 마운트 타겟은 NFS 포트(2049)로 통신한다. EC2 인스턴스의 보안 그룹에서 인바운드 2049/tcp를 허용하는 별도 보안 그룹을 EFS에 붙인다. 인스턴스 보안 그룹을 소스로 지정하면 불필요한 IP 범위 개방 없이 최소 권한을 유지할 수 있다.

# EFS 마운트 타겟용 보안 그룹 생성
aws ec2 create-security-group \
  --group-name efs-mount-sg \
  --description 'Security group for EFS mount targets' \
  --vpc-id vpc-0123456789abcdef0 \
  --region us-east-1

# EC2 인스턴스 보안 그룹(sg-ec2instances)에서 NFS 인바운드 허용
aws ec2 authorize-security-group-ingress \
  --group-id sg-0efs1234567890abc \
  --protocol tcp \
  --port 2049 \
  --source-group sg-0ec2instances1234 \
  --region us-east-1

Step 3: 각 AZ에 마운트 타겟 생성

EC2 인스턴스가 여러 AZ에 분산되어 있다면, 각 AZ의 서브넷에 마운트 타겟을 생성해야 한다. 마운트 타겟이 없는 AZ의 인스턴스는 EFS에 연결할 수 없다. 같은 AZ 내 마운트 타겟을 사용하는 것이 네트워크 비용과 지연 시간 측면에서 유리하다.

# AZ별로 마운트 타겟 생성 (서브넷 ID는 실제 환경에 맞게 변경)
aws efs create-mount-target \
  --file-system-id fs-0123456789abcdef0 \
  --subnet-id subnet-0az1example1234 \
  --security-groups sg-0efs1234567890abc \
  --region us-east-1

aws efs create-mount-target \
  --file-system-id fs-0123456789abcdef0 \
  --subnet-id subnet-0az2example5678 \
  --security-groups sg-0efs1234567890abc \
  --region us-east-1

Step 4: EC2 인스턴스에 EFS 마운트 (EFS 마운트 헬퍼 사용)

AWS는 amazon-efs-utils 패키지를 제공한다. 이 마운트 헬퍼를 사용하면 TLS 암호화, IAM 인증, 자동 재마운트 등을 간단하게 설정할 수 있다. 직접 NFS 마운트보다 이 방법을 권장한다.

# Amazon Linux 2 / Amazon Linux 2023
sudo yum install -y amazon-efs-utils

# Ubuntu
sudo apt-get install -y amazon-efs-utils

# 마운트 포인트 생성
sudo mkdir -p /mnt/shared

# EFS 마운트 (TLS 활성화)
sudo mount -t efs -o tls fs-0123456789abcdef0:/ /mnt/shared

재부팅 후에도 자동으로 마운트되도록 /etc/fstab에 등록한다.

# /etc/fstab에 추가
fs-0123456789abcdef0:/ /mnt/shared efs _netdev,tls 0 0

5개 인스턴스 모두에 동일하게 적용하면, /mnt/shared 디렉토리가 모든 인스턴스에서 동일한 내용을 보여준다.

Step 5: IAM 정책 — EFS 접근 제어

EFS는 리소스 기반 정책(파일시스템 정책)과 IAM 정책을 모두 지원한다. EC2 인스턴스 역할에 EFS 접근 권한을 부여하려면 아래 정책을 참고한다.

🔽 EFS 접근 IAM 정책 예시 (클릭하여 펼치기) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEFSAccess",
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:ClientMount",
        "elasticfilesystem:ClientWrite",
        "elasticfilesystem:ClientRootAccess"
      ],
      "Resource": "arn:aws:elasticfilesystem:us-east-1:123456789012:file-system/fs-0123456789abcdef0"
    }
  ]
}

IAM 기반 인증을 사용하려면 마운트 시 iam 옵션을 추가한다.

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

Step 6: 마운트 상태 및 연결 확인

마운트 타겟 상태와 실제 파일시스템 연결을 확인한다. 마운트 타겟이 'available' 상태가 되기 전에 마운트를 시도하면 연결이 실패한다.

# 마운트 타겟 상태 확인
aws efs describe-mount-targets \
  --file-system-id fs-0123456789abcdef0 \
  --region us-east-1

# 인스턴스에서 마운트 확인
df -h | grep efs

# 파일 쓰기/읽기 테스트 (인스턴스 A에서 쓰고 인스턴스 B에서 읽기)
# 인스턴스 A:
echo 'hello from instance-A' | sudo tee /mnt/shared/test.txt

# 인스턴스 B:
cat /mnt/shared/test.txt

실제 운영에서 마주친 문제 — EFS 마운트 실패 트러블슈팅

증상: mount 명령은 응답 없이 타임아웃되고, /var/log/messages에는 Connection timed out만 남는다. EFS 콘솔에서는 파일시스템이 정상으로 표시된다.

처음엔 EFS 파일시스템 정책 문제라고 생각해서 IAM 설정을 한참 뒤졌다. 실제 원인은 보안 그룹이었다. EC2 인스턴스의 보안 그룹에서 EFS 마운트 타겟 보안 그룹으로 나가는 아웃바운드 2049/tcp가 막혀 있었고, 마운트 타겟 보안 그룹의 인바운드 규칙은 소스를 EC2 보안 그룹 ID로 지정했는데 실제로는 다른 보안 그룹 ID가 인스턴스에 붙어 있었다.

네트워크 레이어가 막히면 IAM 오류 메시지조차 나오지 않는다. 연결 자체가 성립하지 않으니까.

# 보안 그룹 인바운드 규칙 확인 (EFS 마운트 타겟 SG)
aws ec2 describe-security-groups \
  --group-ids sg-0efs1234567890abc \
  --query 'SecurityGroups[*].IpPermissions' \
  --region us-east-1

# EC2 인스턴스에 실제로 붙은 보안 그룹 확인
aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[*].Instances[*].SecurityGroups' \
  --region us-east-1

두 명령의 출력을 대조해서 소스 SG ID가 실제 인스턴스 SG와 일치하는지 확인하는 것이 첫 번째 진단 단계다. 콘솔에서 EFS가 '정상'으로 보여도 네트워크 경로가 막히면 마운트는 무조건 타임아웃된다.

EFS 성능 모드와 처리량 모드 선택 기준

공유 폴더 용도라면 대부분 기본값으로 충분하지만, 워크로드 특성에 따라 선택이 달라진다.

옵션 선택 기준 주의사항
범용 성능 모드 (General Purpose) 대부분의 워크로드, 지연 시간 민감한 경우 기본값, 권장
최대 I/O 성능 모드 (Max I/O) 수백 개 인스턴스 동시 접근, 높은 집계 처리량 필요 지연 시간 증가 가능성 있음
탄력적 처리량 (Elastic) 예측 불가능한 워크로드, 버스트 필요 사용량 기반 과금
프로비저닝된 처리량 (Provisioned) 일관된 높은 처리량이 필요한 경우 처리량 별도 과금

성능 모드는 파일시스템 생성 후 변경할 수 없다. 처리량 모드는 생성 후 변경 가능하다. 처음에는 탄력적 처리량으로 시작해서 CloudWatch 메트릭(MeteredIOBytes, PermittedThroughput)을 모니터링한 뒤 프로비저닝 여부를 결정하는 것이 현실적이다.

가격과 처리량 한도는 리전과 설정에 따라 달라지므로 AWS EFS 공식 요금 페이지에서 확인한다.

EBS vs EFS — 언제 무엇을 써야 하는가

graph TD Start(["스토리지 선택 시작"]) --> Q1{"여러 인스턴스가 동시에 접근해야 하나?"}; Q1 -- "아니오" --> Q2{"고성능 블록 I/O 필요?"}; Q2 -- "예" --> EBS["EBS gp3 / io2"]; Q2 -- "아니오" --> EBS2["EBS gp3 (기본)"]; Q1 -- "예" --> Q3{"파일 공유 (공통 디렉토리)?"}; Q3 -- "예" --> EFS["EFS (권장)"]; Q3 -- "아니오" --> Q4{"클러스터 SW (GFS2 등) 사용?"}; Q4 -- "예" --> MultiAttach["EBS Multi-Attach (io1/io2, 동일 AZ)"]; Q4 -- "아니오" --> EFS2["EFS 사용 권장 (Multi-Attach 위험)"];

결정 기준을 정리하면:

  • 단일 인스턴스 전용 고성능 블록 스토리지 → EBS (gp3, io2)
  • 여러 인스턴스 간 파일 공유, 공통 설정/로그/미디어 디렉토리 → EFS
  • 클러스터 소프트웨어가 관리하는 공유 블록 디바이스 → EBS Multi-Attach (io1/io2, 동일 AZ)
  • 정적 파일, 대용량 객체 저장 → S3

마무리 및 다음 단계 — EFS로 EC2 인스턴스 간 폴더 공유

5개 EC2 인스턴스 간 폴더 공유는 EFS가 정답이다. EBS는 구조적으로 다중 인스턴스 파일 공유를 지원하지 않으며, Multi-Attach는 클러스터 파일시스템 없이는 데이터 손상 위험이 있다. EFS는 NFS 기반으로 수백 개 인스턴스의 동시 마운트를 지원하고, 멀티 AZ 가용성을 기본으로 제공한다.

다음 단계로 고려할 사항:

  • EFS 액세스 포인트를 사용해 인스턴스별 디렉토리 격리 및 POSIX 권한 제어
  • EFS 수명 주기 관리로 비활성 파일을 EFS-IA(Infrequent Access) 스토리지 클래스로 자동 전환해 비용 절감
  • CloudWatch에서 PercentIOLimit 메트릭 모니터링 (범용 성능 모드 사용 시)
  • AWS EFS 공식 문서에서 최신 기능 및 제약사항 확인

핵심 용어 정리

용어 설명
EBS (Elastic Block Store) EC2 인스턴스에 연결하는 블록 스토리지. 기본적으로 단일 인스턴스 전용.
EFS (Elastic File System) NFS v4.1/4.2 기반 관리형 파일시스템. 다수 인스턴스 동시 마운트 지원.
Multi-Attach EBS io1/io2 볼륨을 동일 AZ 내 최대 16개 인스턴스에 마운트하는 기능. 클러스터 파일시스템 필수.
마운트 타겟 (Mount Target) EFS 파일시스템에 접근하기 위한 AZ별 네트워크 엔드포인트. NFS 포트 2049 사용.
amazon-efs-utils AWS 제공 EFS 마운트 헬퍼 패키지. TLS 암호화, IAM 인증, 자동 재마운트 지원.

Related Posts

댓글

댓글 쓰기

이 블로그의 인기 게시물

EC2 SSH 연결 타임아웃 완전 해결 가이드: Security Group 인바운드 규칙부터 라우팅까지

새로 생성한 EC2 인스턴스에 SSH로 접속하려는데 'Connection timed out' 에러가 뜨는 상황은, AWS를 처음 쓰는 엔지니어뿐 아니라 경험 있는 운영자도 종종 마주친다. 문제는 단순히 Security Group 포트 하나가 아니라, Security Group → Network ACL → 라우팅 테이블 → 인스턴스 상태 까지 여러 레이어가 겹쳐 있다는 점이다. 이 글에서는 EC2 SSH 연결 타임아웃의 실제 원인을 레이어별로 진단하고, CLI 기반으로 빠르게 수정하는 방법을 다룬다. TL;DR — EC2 SSH 연결 타임아웃 빠른 진단표 진단 레이어 확인 항목 가장 흔한 원인 Security Group (인바운드) TCP 22 허용 여부, 소스 IP 포트 22 규칙 누락 또는 소스 0.0.0.0/0 미설정 Network ACL 인바운드 22 허용, 아웃바운드 임시 포트 허용 아웃바운드 임시 포트(1024-65535) 차단 라우팅 테이블 Internet Gateway 연결 여부 Public Subnet에 IGW 라우트 없음 퍼블릭 IP / EIP 인스턴스에 퍼블릭 IP 할당 여부 퍼블릭 IP 없이 직접 접속 시도 인스턴스 상태 Status Check 통과 여부 System/Instance reachability 실패 EC2 SSH 연결이 어떻게 동작하는가 SSH 연결 요청이 EC2에 도달하기까지 거치는 경로를 이해하지 않으면, 어느 레이어에서 막혔는지 추측에 의존하게 된다. 패킷은 인터넷 → IGW → 서브넷 → Network ACL → Security Group → 인스턴스 순서로 흐른다. 각 레이어는 독립적으로 동작하며, 하나라도 막히면 클라이언트 입장에서는 동일하게 타임아웃으로 보인다. graph LR Client["클라이언트"] ...
자세한 내용 보기

EC2 SSH 연결 시간 초과: 확인해야 할 보안 그룹(Security Group) 규칙

EC2 SSH 연결 시간 초과(Connection timeout)는 새 인스턴스를 시작할 때 가장 흔히 발생하는 장애물 중 하나입니다. 해결 방법은 거의 항상 보안 그룹(Security Group)의 인바운드 규칙이 누락되었거나 잘못 구성된 경우입니다. 요약 — 한눈에 보는 진단 단계 단계 확인할 사항 일반적인 해결 방법 1 보안 그룹(Security Group) 인바운드 규칙 사용자 IP로부터의 SSH (TCP 22) 추가 2 서브넷 라우팅 테이블(Route table) 0.0.0.0/0이 인터넷 게이트웨이(IGW)로 라우팅되는지 확인 3 네트워크 ACL(Network ACL) 규칙 인바운드 TCP 22 및 임시(ephemeral) 반환 포트 허용 4 인스턴스 퍼블릭 IP / 탄력적 IP(Elastic IP) 퍼블릭 IP가 할당되었는지 확인 5 키 페어(Key pair) 및 SSH 사용자 이름 올바른 프라이빗 키 및 AMI 전용 사용자 이름 사용 SSH 연결이 거부(Refused)되지 않고 시간 초과(Timeout)되는 이유 연결 거부(Connection refused) 오류는 TCP 핸드셰이크가 호스트에 도달했으나 대기 중인 서비스가 없음을 의미합니다. 반면 연결 시간 초과(Connection timed out) 오류는 패킷이 도달하지 못했거나 응답이 돌아오지 못했음을 의미합니다. EC2에서 이러한 무응답은 거의 항상 OS 수준의 문제가 아닌 네트워크 계층에서의 차단 때문입니다. 인스턴스 수준의 상태 저장(stateful) 방화벽인 보안 그룹(Security Group)이 가장 먼저 의심해야 할 빈번한 원인입니다. blockquote> 비유: 보안 그룹을 인스턴스 문 앞의 경비원이라고 생각해 보세요. SSH(포트 22)가 게스트 목록에 없으면 패킷은 거부 알림도 받지 못한 채 밖에서...
자세한 내용 보기

IAM User vs IAM Role 차이점 완전 정리 — EC2에서 S3 접근 시 무엇을 써야 하는가

IAM User와 IAM Role의 차이를 명확히 이해하지 못하면, EC2 인스턴스에서 S3에 접근할 때 자격증명을 하드코딩하거나 불필요하게 장기 키를 발급하는 실수를 반복하게 된다. 이 글은 두 개념의 구조적 차이와, EC2 인스턴스가 S3에 접근하는 실제 운영 시나리오 에서 어떤 선택이 올바른지를 명확히 설명한다. TL;DR — IAM User vs IAM Role 핵심 비교 EC2 인스턴스에서 S3에 접근할 때는 IAM Role(인스턴스 프로파일)을 사용하는 것이 AWS 공식 권장 방식이다. IAM User의 액세스 키를 인스턴스에 직접 저장하는 방식은 키 노출 위험이 있고, 자격증명 교체 비용이 높다. 항목 IAM User IAM Role 자격증명 유형 장기 액세스 키 (Access Key ID + Secret) 임시 보안 토큰 (STS 발급) 주체(Principal) 사람 또는 애플리케이션 AWS 서비스, 계정, 사람 등 자격증명 수명 명시적으로 삭제하기 전까지 유효 기본 1시간, 최대 12시간 (설정에 따라 다름) EC2 사용 권장 여부 ❌ 비권장 (키 하드코딩 위험) ✅ 권장 (인스턴스 프로파일) 자격증명 자동 교체 수동 교체 필요 STS가 자동 갱신 멀티 계정 접근 제한적 Cross-account Role Assumption 지원 IAM User와 IAM Role의 작동 원리 IAM User는 AWS 계정 내에 영구적으로 존재하는 자격증명 주체다. 콘솔 로그인용 패스워드와 API 호출용 액세스 키를 가지며, 이 키는 명시적으로 비활성화하거나 삭제하지 않는 한 계속 유효하다. 사람이 직접 AWS 콘솔이나 CLI를 사용하는 경우에 적합하다. IAM Role은 자격증명을 '소유'하는 개체가 아니라, 특정 조건에서 '위임'받아 사용하는 권한 집합이...
자세한 내용 보기