EBS vs EFS untuk Multiple EC2 Instance: Cara Berbagi Folder Antar Instance

Saat tim backend kami perlu berbagi direktori konfigurasi antara lima EC2 instance sekaligus, pertanyaan pertama yang muncul adalah: apakah EBS bisa di-mount ke beberapa instance? Jawabannya tidak sesederhana yang terlihat di konsol AWS — dan salah memilih storage di sini bisa menyebabkan data corruption atau arsitektur yang tidak scalable. Artikel ini membahas perbedaan EBS vs EFS secara operasional untuk skenario shared folder antar multiple EC2 instance.

TL;DR: EBS vs EFS untuk Berbagi Folder

Aspek EBS EFS
Mount ke banyak instance Terbatas (lihat catatan Multi-Attach) Ya, tanpa batas jumlah instance
Protokol akses Block device (seperti hard disk) NFS v4.1 / v4.0
Lintas Availability Zone Tidak (terikat satu AZ) Ya (regional, multi-AZ)
Cocok untuk shared folder Tidak direkomendasikan untuk use case ini Ya, dirancang untuk ini
Sistem file yang dibutuhkan ext4, xfs, dll. (dikelola sendiri) Dikelola AWS (POSIX-compliant)
Harga Lebih murah per GB Lebih mahal per GB, bayar per penggunaan

Bagaimana EBS dan EFS Bekerja

EBS adalah block storage — secara konseptual seperti hard disk eksternal yang di-attach ke satu server. Ketika kamu format dan mount EBS volume ke EC2 instance, instance tersebut mendapatkan akses eksklusif ke block device tersebut. Sistem operasi mengelola filesystem di atasnya (ext4, xfs, dll.).

EFS berbeda secara fundamental. Ini adalah layanan network file system berbasis NFS yang dikelola AWS. Instance tidak mendapatkan block device — mereka mount endpoint NFS melalui jaringan, dan AWS menangani semua operasi filesystem di belakang layar. Hasilnya: banyak instance bisa membaca dan menulis ke direktori yang sama secara bersamaan.

graph LR subgraph EBS_Model ["EBS: Block Storage — Satu Instance"] EBS1["EBS Volume
(gp3/io2)"] EC2A["EC2 Instance A"] EC2B["EC2 Instance B"] EC2C["EC2 Instance C"] EC2A -- "Mount (OK)" --> EBS1 EC2B -. "Tidak bisa mount
bersamaan" .-> EBS1 EC2C -. "Tidak bisa mount
bersamaan" .-> EBS1 end subgraph EFS_Model ["EFS: Network File System — Banyak Instance"] EFSFS["EFS File System"] MT1["Mount Target AZ-1"] MT2["Mount Target AZ-2"] I1["Instance 1"] I2["Instance 2"] I3["Instance 3"] I4["Instance 4"] I5["Instance 5"] I1 -- "NFS Mount" --> MT1 I2 -- "NFS Mount" --> MT1 I3 -- "NFS Mount" --> MT1 I4 -- "NFS Mount" --> MT2 I5 -- "NFS Mount" --> MT2 MT1 --> EFSFS MT2 --> EFSFS end
  1. EBS Volume hanya bisa di-attach ke satu EC2 instance dalam satu AZ (dengan pengecualian Multi-Attach yang terbatas).
  2. EFS File System di-mount oleh banyak instance dari berbagai AZ melalui Mount Target di setiap AZ.
  3. Instance mengakses EFS melalui protokol NFS — tidak ada block device yang terlibat.
  4. Data EFS tersimpan secara redundan di seluruh AZ dalam satu Region secara default.

Mengapa EBS Tidak Cocok untuk Shared Folder Antar Instance

EBS standard (tipe gp2, gp3, io1, io2, st1, sc1) hanya bisa di-attach ke satu EC2 instance dalam satu waktu, dan volume tersebut harus berada di AZ yang sama dengan instance-nya. Kamu tidak bisa mount satu EBS volume ke lima instance berbeda menggunakan mekanisme standar.

Ada fitur bernama EBS Multi-Attach, tapi ini bukan solusi untuk shared folder umum. Multi-Attach hanya tersedia untuk volume tipe io1 dan io2, hanya bekerja dalam satu AZ yang sama, dan semua instance yang terlibat harus menggunakan filesystem yang mendukung concurrent access (seperti cluster-aware filesystem). Tanpa filesystem yang tepat, menulis dari dua instance ke EBS Multi-Attach secara bersamaan akan menyebabkan data corruption — AWS sendiri mendokumentasikan bahwa aplikasi harus mengelola write concurrency secara eksplisit.

Bayangkan EBS seperti flashdisk USB — kamu bisa colok ke satu laptop, cabut, lalu colok ke laptop lain. Tapi kamu tidak bisa colok ke lima laptop sekaligus dan berharap semua bisa tulis file tanpa konflik.

Untuk skenario berbagi folder antara lima EC2 instance, EFS adalah jawaban yang tepat.

EFS untuk Multiple EC2 Instance: Cara Kerjanya

EFS menggunakan arsitektur Mount Target — untuk setiap AZ tempat instance kamu berada, kamu buat satu Mount Target di subnet yang sesuai. Instance kemudian mount filesystem tersebut menggunakan NFS client standar.

graph TD EFS["EFS File System
(fs-0abc123456789def0)"] MT_AZ1["Mount Target
AZ us-east-1a"] MT_AZ2["Mount Target
AZ us-east-1b"] MT_AZ3["Mount Target
AZ us-east-1c"] SG["Security Group
Port 2049 NFS"] I1["EC2 Instance 1
(AZ 1a)"] I2["EC2 Instance 2
(AZ 1a)"] I3["EC2 Instance 3
(AZ 1b)"] I4["EC2 Instance 4
(AZ 1b)"] I5["EC2 Instance 5
(AZ 1c)"] EFS --> MT_AZ1 EFS --> MT_AZ2 EFS --> MT_AZ3 SG --> MT_AZ1 SG --> MT_AZ2 SG --> MT_AZ3 I1 -- "mount -t efs" --> MT_AZ1 I2 -- "mount -t efs" --> MT_AZ1 I3 -- "mount -t efs" --> MT_AZ2 I4 -- "mount -t efs" --> MT_AZ2 I5 -- "mount -t efs" --> MT_AZ3
  1. Satu EFS File System bisa memiliki Mount Target di beberapa AZ dalam satu Region.
  2. Instance di AZ-1 dan AZ-2 sama-sama mount ke EFS File System yang sama.
  3. Semua instance melihat direktori dan file yang identik — perubahan dari satu instance langsung terlihat oleh instance lain.
  4. Security Group pada Mount Target mengontrol akses NFS (port 2049).

Implementasi EFS: Langkah-Langkah Operasional

Berikut langkah konkret untuk membuat EFS dan mount ke EC2 instance. Pastikan kamu sudah memiliki VPC dan subnet yang sesuai.

Langkah 1: Buat EFS File System

Buat file system EFS di Region yang sama dengan EC2 instance kamu. Parameter --performance-mode dan --throughput-mode disesuaikan dengan kebutuhan workload.

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

Catat nilai FileSystemId dari output (format: fs-xxxxxxxxx). Kamu akan membutuhkannya di langkah berikutnya.

Langkah 2: Buat Security Group untuk Mount Target

Mount Target membutuhkan Security Group yang mengizinkan traffic NFS (port 2049) dari Security Group EC2 instance kamu. Ini layer pertama yang sering terlewat saat troubleshooting koneksi EFS.

aws ec2 create-security-group \
  --group-name efs-mount-target-sg \
  --description 'Security group for EFS mount targets' \
  --vpc-id vpc-0123456789abcdef0 \
  --region us-east-1
aws ec2 authorize-security-group-ingress \
  --group-id sg-0efs1234567890abc \
  --protocol tcp \
  --port 2049 \
  --source-group sg-0ec2instance1234 \
  --region us-east-1

Langkah 3: Buat Mount Target di Setiap AZ

Buat satu Mount Target per AZ tempat instance kamu berjalan. Jika instance tersebar di tiga AZ, kamu butuh tiga Mount Target. Ini penting — instance yang mencoba mount ke Mount Target di AZ berbeda akan mengalami latensi lebih tinggi dan dikenakan biaya transfer data lintas AZ.

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

Ulangi perintah ini untuk setiap subnet di AZ yang berbeda, ganti nilai --subnet-id sesuai subnet masing-masing AZ.

Langkah 4: Install EFS Mount Helper dan Mount di EC2

AWS menyediakan amazon-efs-utils yang menyederhanakan proses mounting dan mendukung enkripsi in-transit via TLS. Install di setiap EC2 instance yang perlu akses.

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

# Untuk Ubuntu / Debian
sudo apt-get install -y amazon-efs-utils
# Buat direktori mount point
sudo mkdir -p /mnt/shared-folder

# Mount EFS dengan enkripsi in-transit
sudo mount -t efs -o tls fs-0abc123456789def0:/ /mnt/shared-folder

Langkah 5: Konfigurasi Auto-Mount via /etc/fstab

Agar mount otomatis setelah instance restart, tambahkan entri ke /etc/fstab. Tanpa ini, setiap kali instance reboot kamu harus mount ulang secara manual — sesuatu yang mudah terlupakan di production.

echo 'fs-0abc123456789def0:/ /mnt/shared-folder efs _netdev,tls 0 0' | sudo tee -a /etc/fstab

Verifikasi mount berhasil dari semua instance:

df -h /mnt/shared-folder
ls -la /mnt/shared-folder

Langkah 6: IAM Policy untuk Akses EFS (Jika Menggunakan EFS Access Points)

Jika kamu menggunakan EFS Access Points untuk isolasi direktori per aplikasi atau per tim, EC2 instance membutuhkan IAM permission yang sesuai. Berikut contoh policy minimal:

🔽 Klik untuk melihat IAM Policy EFS 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:ClientMount",
        "elasticfilesystem:ClientWrite",
        "elasticfilesystem:ClientRootAccess"
      ],
      "Resource": "arn:aws:elasticfilesystem:us-east-1:123456789012:file-system/fs-0abc123456789def0"
    }
  ]
}

Verifikasi Koneksi dan Troubleshooting Umum

Setelah mount, cara tercepat memverifikasi shared access adalah menulis file dari satu instance dan membacanya dari instance lain.

# Di Instance A
echo 'test dari instance A' > /mnt/shared-folder/test.txt

# Di Instance B (jalankan segera setelah)
cat /mnt/shared-folder/test.txt

Jika mount gagal, urutan pemeriksaan yang benar adalah: pertama cek status Mount Target, baru cek Security Group. Banyak engineer langsung memeriksa Security Group padahal Mount Target belum dalam status available.

# Cek status Mount Target
aws efs describe-mount-targets \
  --file-system-id fs-0abc123456789def0 \
  --region us-east-1

Output yang diharapkan: LifeCycleState bernilai available untuk setiap Mount Target. Jika masih creating, tunggu beberapa menit sebelum mencoba mount.

# Cek Security Group pada Mount Target
aws efs describe-mount-target-security-groups \
  --mount-target-id fsmt-0abc123456789def0 \
  --region us-east-1

Pengalaman Lapangan: Misdiagnosis yang Sering Terjadi

Di satu deployment, tim kami mengalami situasi di mana mount berhasil di tiga instance tapi gagal di dua instance lainnya. Asumsi awal: masalah Security Group. Setelah satu jam memeriksa inbound rules, ternyata dua instance yang gagal berada di AZ ketiga yang belum memiliki Mount Target.

Gejalanya: perintah mount hang tanpa error message yang jelas, timeout setelah beberapa menit. Log di /var/log/messages menunjukkan NFS connection timeout — bukan permission denied. Perbedaan ini krusial: permission denied mengarah ke Security Group atau IAM, sementara connection timeout mengarah ke routing atau ketersediaan Mount Target.

Perbaikannya: buat Mount Target di subnet AZ ketiga, tunggu status available, lalu mount ulang. Selesai dalam lima menit setelah masalah teridentifikasi dengan benar.

Mount Target adalah 'pintu masuk' EFS per AZ. Tidak ada pintu, tidak ada akses — tidak peduli seberapa benar konfigurasi Security Group kamu.

Kapan Tetap Menggunakan EBS (dan Kapan Tidak)

EBS tetap pilihan tepat untuk workload yang membutuhkan performa block storage tinggi dan akses dari satu instance: database seperti MySQL atau PostgreSQL, volume boot OS, atau aplikasi yang memerlukan IOPS deterministik tinggi. Untuk semua skenario ini, EBS lebih murah dan lebih performa dibanding EFS.

EFS Multi-Attach (via EBS io1/io2) adalah opsi yang ada di dokumentasi AWS, tapi dalam praktiknya jarang digunakan untuk shared folder umum karena kompleksitas manajemen concurrency yang harus ditangani di level aplikasi. Kecuali kamu memiliki kebutuhan spesifik untuk cluster-aware filesystem, EFS adalah jalur yang jauh lebih aman untuk use case berbagi folder.

Wrap-Up: EBS vs EFS untuk Shared Folder di Multiple EC2 Instance

Untuk berbagi folder antara lima EC2 instance, gunakan EFS. EBS dirancang sebagai block storage untuk satu instance, bukan untuk concurrent multi-instance access. EFS dirancang tepat untuk use case ini: banyak instance, satu filesystem, akses NFS yang konsisten lintas AZ.

Langkah selanjutnya yang direkomendasikan:

  • Pertimbangkan EFS Access Points jika kamu perlu isolasi direktori per aplikasi dengan permission berbeda.
  • Aktifkan EFS Lifecycle Management untuk memindahkan file yang jarang diakses ke storage class IA (Infrequent Access) dan mengurangi biaya.
  • Evaluasi EFS Performance Mode — generalPurpose untuk sebagian besar workload, maxIO untuk workload dengan concurrency sangat tinggi.
  • Baca dokumentasi resmi: Amazon EFS User Guide dan Amazon EBS User Guide.

Glosarium

Istilah Penjelasan
EBS (Elastic Block Store) Layanan block storage AWS yang di-attach ke EC2 instance sebagai virtual disk. Terikat pada satu AZ.
EFS (Elastic File System) Layanan network file system terkelola AWS berbasis NFS yang bisa di-mount oleh banyak instance secara bersamaan.
Mount Target Endpoint jaringan EFS di setiap AZ yang digunakan instance untuk terhubung ke file system via NFS.
NFS (Network File System) Protokol standar untuk berbagi file melalui jaringan. EFS menggunakan NFS v4.1 dan v4.0.
EBS Multi-Attach Fitur EBS yang memungkinkan satu volume io1/io2 di-attach ke beberapa instance dalam satu AZ, dengan syarat aplikasi mengelola write concurrency sendiri.

Related Posts

Komentar

Posting Komentar

Postingan populer dari blog ini

Memahami Instance T3 Burstable: Cara Kerja CPU Credits dan Kenapa Server Tiba-tiba Melambat

Anda baru saja deploy aplikasi di instance T3, semua berjalan lancar selama beberapa menit — lalu tiba-tiba response time melonjak, CPU usage turun drastis, dan pengguna mulai mengeluh. Tidak ada error di log aplikasi, tidak ada masalah jaringan. Ini adalah gejala klasik CPU credit exhaustion pada instance T3 burstable, dan memahami mekanisme di baliknya adalah kunci untuk menghindari insiden serupa di production. TL;DR: CPU Credits pada Instance T3 Aspek Penjelasan Apa itu CPU Credit? Satuan yang merepresentasikan hak pakai CPU penuh selama 1 menit pada 1 vCPU Kapan credit bertambah? Saat CPU usage di bawah baseline instance Kapan credit berkurang? Saat CPU usage melebihi baseline instance Mode default T3 Unlimited — instance dapat burst melampaui credit balance dengan biaya tambahan Gejala credit h...
Baca selengkapnya

EC2 Tidak Bisa Akses Internet di Custom VPC: Cara Pasang Internet Gateway dan Update Route Table

Kamu baru saja membuat custom VPC, meluncurkan EC2 instance di public subnet, lalu mencoba ping google.com — dan tidak ada respons sama sekali. Ini adalah salah satu jebakan paling umum saat pertama kali bekerja dengan EC2 no internet access di custom VPC , dan penyebabnya hampir selalu kombinasi dari tiga hal: tidak ada Internet Gateway, route table yang belum diupdate, atau Security Group yang memblokir traffic. TL;DR: Checklist EC2 Tidak Bisa Internet di Custom VPC Komponen Yang Harus Dicek Kondisi Benar Internet Gateway Sudah dibuat dan di-attach ke VPC State: attached Route Table Ada route 0.0.0.0/0 ke IGW Target: igw-xxxxxxxx Subnet Association Public subnet terhubung ke route table yang benar Subnet ID muncul di associations Security Group Inbound HTTP/HTTPS/ICMP diizinkan Rule eksplisit untuk port 80, 443, atau ICMP Public IP Instance punya public IP atau Elastic IP PublicIpAddress tidak n...
Baca selengkapnya