devHọc Dev
Bài học

Tuần 6 - Ngày 1: EBS, EFS, FSx Deep Dive

Tuần 6 – Ngày 1

Mục tiêu học tập

  • Chọn đúng EBS volume type theo IOPS/throughput/chi phí và hiểu Multi-Attach
  • Nắm EFS storage classes, performance/throughput modes
  • Chọn đúng biến thể FSx theo protocol và workload (Windows/HPC/NetApp/OpenZFS)

1. EBS Volume Types

┌─────────────────────────────────────────────────────────┐│EBSVOLUMETYPES││││SSD-backed:││├──gp3:Generalpurpose(baseline3000IOPS)││├──gp2:Generalpurpose(IOPSscaleswithsize)││├──io2:ProvisionedIOPS(upto64,000IOPS)││└──io2BlockExpress:(upto256,000IOPS)││││HDD-backed:││├──st1:Throughputoptimized(500MB/s)││└──sc1:ColdHDD(250MB/s,lowestcost)│└─────────────────────────────────────────────────────────┘

Multi-Attach (io1/io2)

  • Attach cùng volume đến 16 instances
  • Same AZ only
  • Cluster-aware file system required (GFS2)
  • Use case: HA applications

2. EBS Snapshots

Fast Snapshot Restore (FSR):
- Eliminate initialization latency
- Per AZ fee
- Good for: Boot volumes, AMIs

Snapshot Archive:
- 75% cost savings
- 24-72 hours retrieval
- Good for: Compliance, long-term backup

3. EFS (Elastic File System)

┌─────────────────────────────────────────────────────────┐│EFS││││StorageClasses:││├──Standard(Multi-AZ)││├──OneZone││├──Standard-IA││└──OneZone-IA││││PerformanceModes:││├──GeneralPurpose(latency-sensitive)││└──MaxI/O(thousandsofclients)││││ThroughputModes:││├──Bursting(scaleswithsize)││├──Provisioned(fixedthroughput)││└──Elastic(auto-scale,new)│└─────────────────────────────────────────────────────────┘

4. FSx Options

ServiceProtocolUse Case
FSx for WindowsSMBWindows apps, AD integration
FSx for LustreLustreHPC, ML, video processing
FSx for NetApp ONTAPNFS, SMB, iSCSIEnterprise, hybrid
FSx for OpenZFSNFSLinux workloads

FSx for Lustre + S3

┌─────────────────────────────────────────────────────────┐│FSxforLustre+S3Integration││││S3Bucket(datarepository)││↕Lazyload/Writeback││FSxforLustre(high-speedprocessing)││↕││ComputeInstances(EC2,ECS,EKS)││││Usecase:ProcesslargedatasetsfromS3│└─────────────────────────────────────────────────────────┘

5. Amazon Data Lifecycle Manager (DLM)

Tự động hoá vòng đời EBS snapshots và EBS-backed AMIs: tạo theo schedule, giữ theo retention rule, xoá khi hết hạn — không cần Lambda/cron tự viết.

┌─────────────────────────────────────────────────────────┐│DATALIFECYCLEMANAGER(DLM)││││LifecyclePolicy(tag-basedtargeting)││├──Target:volumes/instancescótag│││(vd:Backup=true,Env=prod)││├──Schedule:mỗi1/2/3/4/6/8/12/24hhoặccron││├──Retention:giữNbảngầnnhấthoặcNngày││└──Actions:││├──TạoEBSsnapshot/EBS-backedAMI││├──Cross-accountsnapshotcopy(shareDRaccount)││├──Cross-Regioncopy││└──EnableFastSnapshotRestore(FSR)tựđộng│└─────────────────────────────────────────────────────────┘

Điểm Professional cần nắm:

  • Tag-based: gắn tag chuẩn hoá (qua Organizations tag policy) → volume mới tự động được backup, không cần sửa policy.
  • Cross-account copy: policy ở account nguồn share snapshot sang account DR; account đích có thể có policy riêng copy tiếp cross-Region + re-encrypt bằng KMS key của account đích — pattern DR/backup isolation.
  • DLM miễn phí — chỉ trả tiền snapshot storage (và FSR nếu bật).

DLM vs AWS Backup

Tiêu chíDLMAWS Backup
Phạm viChỉ EBS snapshot + EBS-backed AMIĐa dịch vụ: EBS, EC2, RDS, Aurora, DynamoDB, EFS, FSx, S3, Storage Gateway, VMware...
PolicyĐơn giản: tag + schedule + retentionBackup plan tập trung, backup vault
ComplianceKhôngVault Lock (WORM), audit qua Backup Audit Manager
Cross-region/accountSnapshot copy (EBS only)Có, cho mọi dịch vụ hỗ trợ
OrganizationsKhông trực tiếpBackup policies áp toàn Organization
Chi phíMiễn phí (trả tiền snapshot)Trả theo backup storage/restore (một số dịch vụ có phí riêng)

Exam keywords:

  • "automate EBS snapshot lifecycle", "delete snapshots older than N days", "least effort chỉ cho EBS" → DLM
  • "centralized backup across multiple services/accounts", "compliance/immutable backup", "enforce backup policy toàn Organization" → AWS Backup (+ Vault Lock)

6. EFS Access Points

Access Point = entry point per-application vào một EFS file system:

  • Enforce POSIX identity: mọi request qua access point chạy với user/group ID cấu hình sẵn — bỏ qua identity của NFS client (client là root cũng bị map về UID/GID của access point).
  • Root directory riêng (chroot-style): mỗi app chỉ thấy thư mục của mình (vd /app1), tự động tạo với owner/permission khai báo trước.
  • Kết hợp file system policy (IAM resource policy) với condition elasticfilesystem:AccessPointArn → bắt buộc app/role chỉ truy cập qua access point cụ thể, không mount thẳng root.
┌─────────────────────────────────────────────────────────┐│EFSACCESSPOINTS(multi-tenant)││││AppA(EC2)LambdaFnAppB(ECS)│││││││▼▼▼││AccessPoint1AccessPoint2AccessPoint3││UID/GID1001UID/GID1002UID/GID1003││root:/app-aroot:/lambdaroot:/app-b│││││││└────────────────┼────────────────┘││▼││┌─────────────────────────────┐│││EFSFileSystem(1cái)││││/app-a/lambda/app-b│││└─────────────────────────────┘│└─────────────────────────────────────────────────────────┘

Use cases chính:

  • Multi-tenant shared EFS: nhiều team/app dùng chung 1 file system nhưng isolate dữ liệu + identity — không cần quản lý UID/GID trên từng client.
  • Lambda + EFS: Lambda bắt buộc mount EFS qua access point (không mount thẳng file system) — dùng cho ML model lớn, shared state giữa các invocation, thư viện > giới hạn /tmp.
  • Least privilege: file system policy deny mọi truy cập không qua access point → mỗi app chỉ đọc/ghi được thư mục của mình.

Exam keywords: "multiple applications share one EFS with isolated directories", "enforce POSIX permissions regardless of client", "Lambda needs shared persistent storage" → EFS Access Points.

7. Câu hỏi ôn tập

  1. Khi nào chọn gp3 thay vì io2?

    Xem đáp án

    gp3: baseline 3.000 IOPS/125 MBps, provision thêm độc lập với size tới 16.000 IOPS — rẻ hơn gp2 ~20% và đủ cho đa số workload. io2 (Block Express): khi cần > 16.000 IOPS, latency sub-ms ổn định, durability 99.999%, hoặc Multi-Attach — database tier khắt khe (SAP HANA, Oracle, SQL Server). Exam keyword: "most cost-effective, 10.000 IOPS" → gp3 (không cần io2); "64.000+ IOPS single volume" → io2 Block Express.

  2. EBS Multi-Attach có những ràng buộc gì?

    Xem đáp án

    Chỉ io1/io2, tối đa 16 instances, tất cả trong cùng AZ, và cần cluster-aware file system (GFS2...) — ext4/XFS thường sẽ corrupt vì không điều phối write. Multi-Attach không phải giải pháp shared file storage tổng quát: cần share file across AZ/nhiều instances → EFS; Windows → FSx for Windows. Đây là bẫy phổ biến trên đề.

  3. EFS Elastic vs Provisioned vs Bursting throughput?

    Xem đáp án

    Bursting: throughput tỉ lệ với dung lượng (burst credits) — file system nhỏ dễ cạn credit. Provisioned: cố định theo mức trả tiền, cho workload cần throughput cao nhưng dung lượng nhỏ. Elastic (mặc định mới, recommended): tự scale theo workload, pay-per-use — chọn khi traffic khó dự đoán, "least operational overhead". IA class + Lifecycle management giảm chi phí file ít truy cập ~92%.

  4. Scenario nào chọn FSx for NetApp ONTAP thay vì EFS?

    Xem đáp án

    Khi cần: multi-protocol (NFS + SMB + iSCSI cùng data), tính năng NetApp (SnapMirror replication từ on-prem NetApp — migration path nhanh nhất, snapshots, cloning, dedup/compression), hoặc client Windows + Linux cùng truy cập. EFS chỉ NFS/Linux. FSx for OpenZFS cho NFS thuần Linux cần latency thấp; FSx for Windows cho SMB + AD; Lustre cho HPC scratch + S3 integration.

  5. Khi nào chọn DLM, khi nào chọn AWS Backup?

    Xem đáp án

    DLM: chỉ cần tự động tạo/giữ/xoá EBS snapshots hoặc EBS-backed AMIs theo tag + schedule — miễn phí, đơn giản, "least effort" cho riêng EBS. AWS Backup: cần backup tập trung đa dịch vụ (EBS, RDS, DynamoDB, EFS, FSx, S3...), cross-account/cross-region, hoặc compliance — backup vault + Vault Lock (WORM), backup policies áp qua Organizations. Exam: "automate EBS snapshot lifecycle" → DLM; "centralized/immutable backup across services and accounts" → AWS Backup.

  6. EFS Access Point giải quyết vấn đề gì trong kiến trúc multi-tenant?

    Xem đáp án

    Mỗi app/tenant mount qua access point riêng: bị enforce POSIX UID/GID cấu hình sẵn (bỏ qua identity của NFS client — root trên client cũng bị map lại) và bị chroot vào root directory riêng — isolate dữ liệu trên cùng 1 EFS mà không cần quản lý permission trên từng client. Kết hợp file system policy (IAM) với condition theo Access Point ARN để bắt buộc role chỉ vào đúng access point của mình. Lưu ý: Lambda bắt buộc mount EFS qua access point.

8. Bài tập thực hành

  1. gp2 → gp3 migration: tạo volume gp2 100GB, modify sang gp3 (elastic volume, không downtime), tăng IOPS lên 6.000 độc lập với size — so sánh chi phí tháng 2 cấu hình bằng pricing calculator.

  2. EFS multi-AZ mount: tạo EFS + mount targets 2 AZ, mount từ 2 EC2 instances khác AZ, ghi file từ instance này đọc từ instance kia; bật lifecycle policy chuyển IA sau 7 ngày.

  3. FSx for Lustre + S3: tạo FSx for Lustre scratch file system link tới S3 bucket, verify lazy-load object từ S3 qua file system và export ngược (lfs hsm_archive) về S3.

Tài liệu tham khảo chính thức

Ngày tiếp theo: RDS & Aurora Deep Dive