AWS S3 Files 기반 온프레미스 SMB 파일 공유 환경 구축하기-1

이승연2026.09.04수정 2026.09.04

들어가며

클라우드 전환을 검토 중인 조직 중에는, IDC 서버를 전부 마이그레이션하기보다 온프레미스 환경은 유지한 채 스토리지만 클라우드로 옮기고 싶어하는 경우가 있습니다. 서버는 그대로 두고 뒤에 물리는 스토리지만 S3로 바꿀 수 있다면, 이관 부담을 크게 줄일 수 있기 때문입니다.

이번 글에서는 AWS S3 Files와 Samba를 이용해 S3 버킷을 SMB로 공유하고, Site-to-Site VPN을 통해 IDC 서버에서 직접 마운트하여 사용하는 방법을 소개합니다. 실제 PoC를 진행하면서 겪은 트러블슈팅 과정도 함께 담았습니다. 비슷한 환경을 구성하려는 분들께 도움이 되길 바랍니다.

S3 Files란?

S3 Files는 AWS S3 버킷을 리눅스 파일시스템처럼 마운트할 수 있게 해주는 AWS의 신규 기능입니다. 기존 S3는 오브젝트 스토리지로, 파일에 접근하려면 API 호출이나 CLI를 통해 오브젝트 단위로 업로드/다운로드해야 했습니다. 일반적인 파일시스템처럼 cat, vi, cp 같은 명령으로 직접 접근하는 것은 불가능했습니다.

S3 Files는 S3 버킷을 NFS 파일시스템으로 마운트할 수 있게 해주어, 기존 애플리케이션의 코드 변경 없이 S3 데이터를 로컬 파일처럼 사용할 수 있게 되었습니다. S3 Files는 이를 AWS에서 직접 지원하는 방식으로, NFS 프로토콜을 기반으로 동작합니다.

주요 특징은 다음과 같습니다:

S3 버킷을 EC2에 파일시스템으로 마운트하여 로컬 디스크처럼 사용 가능
별도의 스토리지 서버 없이 S3의 무제한 용량을 파일 서버로 활용
S3의 높은 내구성(99.999999999%)과 저렴한 비용 유지
기존 파일 기반 애플리케이션과의 호환성 확보

– AWS 공식 문서 (AWS S3 Docs)

S3 Files와 NFS의 관계, 그리고 SMB를 선택한 이유

S3 Files는 기본적으로 AWS 환경 내에서 EC2 등 내부 서비스와 S3 버킷을 파일시스템으로 마운트하여 사용하는 것을 목적으로 설계되었습니다. 즉, S3 Files 자체를 온프레미스에서 직접 연결해서 쓰는 것보다는, EC2에서 S3를 파일시스템처럼 활용하는 AWS 내부 워크로드에 최적화되어 있습니다.

이 구성을 시도하게 된 배경에는 실제 고객의 요청이 있었습니다. 온프레미스 문서 관리 솔루션을 쓰고 있는 한 고객사에서, 스토리지 용량이 포화 상태에 가까워지면서 클라우드 이관을 검토하고 있었습니다. 다만 사용자가 접속하는 프론트엔드까지 새로 개발하는 방식은 부담이 컸고, “기존 온프레미스 문서 관리 솔루션은 그대로 두고, 그 뒤에 물리는 스토리지만 클라우드로 바꿀 수 없을까”라는 요구사항이 있었습니다.

처음에는 “S3를 네트워크 드라이브처럼 마운트해서 온프레미스 서버에 연결하면 되지 않을까”라는 단순한 가정에서 출발했습니다. 그런데 이게 생각보다 간단하지 않았습니다. 고객이 IDC 환경에서 직접 S3 파일에 접근하고 싶다는 요구사항이 있었기 때문에, S3 Files를 EC2에 마운트한 뒤 이를 IDC 서버로 내보내는 방식을 시도하게 되었습니다.

처음 시도: NFS re-export

가장 먼저 시도한 방법은 S3 Files를 EC2에 NFS로 마운트한 뒤, 이를 그대로 IDC 서버로 NFS re-export하는 방식이었습니다.

no_root_squash, crossmnt, nohide, fsid, refer= 등 NFS re-export 관련 옵션을 모두 시도해봤지만, 동일하게 Stale file handle 오류가 발생했습니다.

ls /mnt/s3 # 디렉토리 목록은 보임
cat /mnt/s3/file # → Stale file handle 오류 발생

흥미로운 점은 ls로 디렉토리 목록이 오류와 함께 보이긴한다는 것입니다. 실제 파일에 접근은 불가합니다.

원인 분석: NFS file handle 크기 한계

확인 결과, 이는 권한 문제가 아닌 NFS 프로토콜 자체의 구조적 한계였습니다.

NFS 프로토콜은 file handle의 최대 크기가 RFC에 의해 엄격히 제한되어 있습니다.

NFSv2: 32 bytes

NFSv3: 64 bytes

NFSv4: 128 bytes

“The result must fit into the RFC-mandated filehandle size limits: NFSv2 32 bytes, NFSv3 64 bytes, NFSv4 128 bytes” — Linux Kernel 공식 문서 (docs.kernel.org/filesystems/nfs/reexport)

S3 Files는 내부적으로 EFS 기반의 큰 file handle을 발급합니다. EC2에서 직접 마운트해서 사용할 때는 이 file handle을 그대로 쓰기 때문에 문제가 없습니다.

하지만 이를 NFS로 re-export 하는 순간, Linux knfsd가 file handle을 새로 감싸면서 128 바이트 제한을 초과하게 됩니다.

ls로 디렉토리 목록이 보이는 이유는 readdir이 작은 디렉토리 file handle 하나로 처리되기 때문이고, 실제 파일에 접근할 때는 개별 파일의 file handle이 필요한데 이 크기가 제한을 초과하면서 Stale file handle 오류가 발생하는 것입니다.

SMB(Samba)로 전환: 왜 SMB는 될까?

NFS re-export의 구조적 한계를 확인한 후, SMB(Samba) 방식으로 전환을 시도했고 정상 동작하는 것을 확인했습니다.

SMB가 가능한 이유는 Samba가 파일에 접근하는 방식이 NFS와 근본적으로 다르기 때문입니다.

항목	NFS re-export	SMB(Samba)
접근 방식	file handle을 그대로 클라이언트에 전달	자체 VFS 레이어를 통해 파일 접근
file handle	클라이언트가 직접 사용 (크기 제한 영향)	서버 내부에서만 사용 (클라이언트에 전달 안 함)
re-export 가능 여부	file handle 크기 초과로 불가	VFS 레이어가 추상화하여 가능

NFS는 서버가 발급한 file handle을 클라이언트에게 직접 전달하는 구조입니다. 따라서 S3 Files의 큰 file handle이 그대로 클라이언트로 넘어가면서 크기 제한에 걸립니다.

반면 Samba는 자체 VFS(Virtual File System) 레이어를 통해 파일시스템에 접근합니다. S3 Files의 file handle은 Samba 서버 내부에서만 사용되고, 클라이언트에게는 Samba가 자체적으로 관리하는 별도의 식별자를 전달합니다. 따라서 NFS의 file handle 크기 제한에 전혀 영향을 받지 않습니다.

결론적으로 최종 구성은 아래와 같이 확정되었습니다.

S3 Files(NFS) → EC2 → Samba(SMB) → IDC 서버

S3 Files로 S3 버킷을 EC2에 마운트하고, 그 경로를 Samba가 SMB로 공유하는 브릿지 구조입니다. NFS의 file handle 문제를 Samba의 VFS 레이어가 완전히 추상화해주기 때문에 가능한 구성입니다.

테스트 결과:

Linux / Windows 클라이언트 모두 정상 동작
파일 읽기 / 쓰기 / S3 sync 모두 정상 동작

구성 환경

이번 PoC에서 사용한 환경은 다음과 같습니다.

AWS S3: 파일 저장소
AWS EC2: S3 Files 마운트 + Samba 구성 (SMB 전용 서버, Bastion과 분리)
Site-to-Site VPN: AWS VPC와 IDC 간 BGP 기반 VPN 연결 (터널 2개)
IDC 서버: SMB 클라이언트로 EC2의 공유 폴더를 마운트하여 S3 파일 접근

전체 구성 흐름은 아래와 같습니다.

AWS S3 → EC2 (S3 Files + Samba) → Site-to-Site VPN → IDC 서버 (SMB 마운트)

EC2는 S3 Files를 통해 S3 버킷을 로컬 파일시스템으로 마운트하고, Samba를 통해 SMB로 공유합니다. IDC 서버는 Site-to-Site VPN을 통해 EC2의 SMB 공유를 마운트하여 S3 파일에 접근합니다.

구성 방법

S3files 생성

s3 버킷을 하나 생성합니다

파일시스템 탭으로 가서 s3files도 하나 생성합니다

파일시스템의 탑재 대상 보안그룹에 NFS(2049)를 각각 추가합니다.

탑재대상을 선택하고 편집을 눌러 보안그룹을 수정해줍니다 탑재대상 전부 다 각각 보안그룹을 수정해주어야 합니다.

탑재 대상 보안그룹: EC2 보안그룹을 소스로 2049(NFS) 인바운드 허용

EC2 서버

게이트웨이 ec2서버를 생성합니다.

생성 시 스토리지 구성 부분에 s3파일 부분을 선택하면 위에서 생성한 s3files를 연동할 수 있습니다.

S3 Files를 마운트하려면 EC2 인스턴스에 액세스 역할과 관리형 정책(AmazonS3FilesClientFullAccess)이 연결되어 있어야 합니다. 정책을 생성하고 EC2인스턴스와 연결이 필요합니다.

또한 EC2 보안그룹에 IDC 대역(또는 VPN CIDR)을 소스로 445(SMB) 인바운드 허용되어야 합니다

# 1. ec2 생성 시 나온 마운트 명령어를 이용하여 설치

curl https://amazon-efs-utils.aws.com/efs-utils-installer.sh | sudo sh -s -- --install-launch-wizard \ --mount-s3files [s3files이름] [마운트 경로]

# 2. 마운트 잘 되었는지 확인

df -h [마운트 경로]

# 3. s3files 연동 최종 확인

ls [마운트 경로]

지금까지는 ec2와 s3files를 연동하는 과정이였습니다.

이제는 idc서버와 SMB 연결을 위한 작업입니다. Samba 설정 파일 수정을 위해 root권한을 보유하고 있다는 전제로 진행됩니다.

# 4. Samba 및 관련 패키지 설치

sudo dnf install -y samba samba-client cifs-utils

# 5. Samba 설정 파일 편집

[global] 아래 다른 여러 설정이 많지만 생략했습니다. nas 부분만 추가로 넣어 수정해줍니다.

cat /etc/samba/smb.conf

sudo vi /etc/samba/smb.conf

[global]

workgroup = WORKGROUP

security = user

map to guest = Bad User

unix charset = UTF-8

dos charset = CP949

…

[nas]

path = /smb/s3files

browseable = yes

writable = yes

guest ok = yes

public = yes

create mask = 0664

directory mask = 0775

force user = root

보안 관련 리뷰: force user = root + guest ok = yes 조합은 익명 접근자가 root 권한으로 파일을 쓰게 됩니다.
이 글에서는 빠른 체험과 이해를 돕기 위해 이런 naive한 구성을 택했지만, 운영 환경 적용 시에는 인증과 권한을 강화해야 합니다.

# 6. Samba 서비스 시작 및 자동 시작 등록

sudo systemctl enable --now smb

# 7. SMB 공유 목록 확인

smbclient -L //localhost -N

IDC 서버

# 1. cifs-utils 설치

sudo dnf install -y cifs-utils

# 2. 마운트 포인트 생성

sudo mkdir -p [마운트 경로]

# 3. SMB 마운트

sudo mount -t cifs //[중간 ec2계정 ip]/nas [마운트 경로] -o guest,vers=3.0

# 4. 확인

ls [마운트 경로]

마치며

이번 PoC를 통해 AWS S3 Files와 Samba를 활용하면 온프레미스 서버에서도 S3를 파일 서버처럼 손쉽게 활용할 수 있다는 것을 확인했습니다.

NFS re-export 방식은 S3 Files의 EFS 기반 file handle이 NFS의 128 바이트 제한을 초과하는 구조적 한계가 있어 사용할 수 없었지만, SMB(Samba)의 VFS 레이어가 이를 완전히 추상화해주어 문제를 해결할 수 있었습니다.

구성 자체는 정상적으로 동작하는 것을 확인했지만, “그래서 실제로 얼마나 빠른가”는 별개의 질문입니다. 다음 글에서는 동일 리전 내 VPC 간 Site-to-Site VPN으로 재현 가능한 환경을 구성해, fio 기반으로 순차/랜덤 I/O 성능과 동시 접속 시나리오를 실측한 결과를 다뤄보겠습니다.

AWS의 파트너사인 MegazoneCloud 소속으로 AWS AI Ambassador 후보자로 활동하며 작성한 내용입니다.
AWS의 서비스를 소개하고, 실제 업무에서 사용한 사례들에 대한 내용들을 담고 있습니다.

Written By. Seungyeon Lee

S3files