Skip to main content

3.1. Services - Storage: EBS, instance store, EFS, FSx và S3 cơ bản

Mục lục​

1. EBS: block storage của AWS​

Nhắc lại block storage​

Cách block storage hoạt động là cắt dữ liệu thành các block, rồi lưu từng block như một mảnh riêng, mỗi mảnh có một unique identifier của nó. Các block đó sau đó được lưu rải ra trên nhiều thiết bị vật lý khác nhau.

Một tập hợp block có thể được trình ra cho operating system dưới dạng một volume. Có volume rồi thì trình nó cho operating system và tạo file system lên trên volume đó.

Điểm hay của block storage là không chỉ trình được các block dưới dạng volume. Nó còn trình được dưới dạng hard drive, nghĩa là cài hẳn một operating system lên đó và biến nó thành bootable. Operating system cài trực tiếp lên chính block device.

Nói lại cho rõ, block storage có hai cách trình ra:

  • Dưới dạng volume, rồi tạo file system lên trên.
  • Dưới dạng hard drive, rồi làm cho nó bootable.

💡 Hình dung: block storage giống một ổ cứng rời cắm vào máy. Hệ điều hành nhìn thấy một thiết bị trống trơn và toàn quyền quyết định format nó theo định dạng nào, chia bao nhiêu phân vùng, hay thậm chí cài luôn một hệ điều hành lên đó rồi boot từ nó. Phần mềm quyết định mọi thứ, phía thiết bị chỉ cung cấp các block trống có địa chỉ.

Vậy block storage vừa mountable vừa bootable. Đây là điểm cần nhớ cho kỳ thi Solutions Architect: với block storage thì cả mount được file system lên, cả boot được từ nó. Hai mục sau về EFS và S3 sẽ cho thấy đúng tiêu chí này là cái phân biệt ba loại storage.

EBS là gì​

Service block storage của Amazon tên là Elastic Block Storage, viết tắt EBS. Mỗi khi nói tới block storage trong phạm vi AWS thì đang nói tới chính service này.

EBS cung cấp block-level storage volume cho EC2 instance. EC2 instance nhìn thấy các block device được attach vào, rồi từ đó tạo file system lên trên, ví dụ XFS, EXT3 hoặc EXT4.

Điểm hay nhất của EBS là EBS volume tách rời khỏi EC2 instance. Nghĩa là attach volume vào một EC2 instance, rồi detach ra, rồi attach vào một EC2 instance khác, và toàn bộ dữ liệu trong EBS volume đó vẫn được giữ nguyên. Cách này cho phép dịch chuyển dữ liệu từ EC2 instance này sang EC2 instance khác mà không gặp vấn đề gì, miễn là dữ liệu nằm trong EBS volume.

Multi-attach​

Thông thường một EBS volume chỉ attach được vào một EC2 instance duy nhất. Tuy nhiên có một số volume type cho phép multi-attach, tức nhiều instance attach cùng một volume.

Khi dùng multi-attach thì application phải đủ thông minh để không cho nhiều EC2 instance ghi vào cùng một dữ liệu tại cùng một thời điểm, vì việc đó cuối cùng sẽ làm hỏng dữ liệu.

Ví dụ thường gặp của tình huống này là một database cluster. Database cluster thường đã đủ thông minh để có một master node chịu trách nhiệm ghi dữ liệu, còn các node còn lại chỉ đọc. Các node tổ chức election để bảo đảm có một và chỉ một database instance đang thực sự ghi vào storage.

EBS gắn với một Availability Zone​

EBS volume được provision trong một Availability Zone. EBS volume có khả năng chịu lỗi trong phạm vi một Availability Zone: có redundancy dựng sẵn bên trong Availability Zone đó, nên nó chịu được một thiết bị vật lý chết, nhưng dữ liệu mất nếu cả Availability Zone sập.

Hệ quả trực tiếp: để attach một EBS volume vào một EC2 instance thì cả EC2 instance và EBS volume phải nằm trong cùng một Availability Zone. Không nối được một EC2 instance ở Availability Zone này với một EBS volume ở Availability Zone khác.

Luồng hoạt động​

Đặt vào bối cảnh có nhiều Availability Zone thì luồng như sau.

  1. Tạo một volume trong EBS, cấu hình volume đó.
  2. Attach EBS volume vào một EC2 instance. Volume được trình ra thành một block device trên operating system của EC2 instance.
  3. Muốn chuyển toàn bộ dữ liệu sang một EC2 instance khác trong cùng Availability Zone thì detach khỏi instance hiện tại rồi attach volume vào instance mới. Không có vấn đề gì.
  4. Nếu EC2 instance mới nằm ở Availability Zone khác, cùng region nhưng khác Availability Zone, thì không attach được, vì cả hai phải cùng Availability Zone. Cách giải quyết thô là tạo hẳn một EBS volume mới trong Availability Zone thứ hai rồi attach vào instance đó, nhưng volume mới thì trống.

Vấn đề thật là: làm sao di chuyển dữ liệu từ Availability Zone một sang Availability Zone hai. Đây là chỗ feature snapshot xuất hiện.

Snapshot​

Cách làm là chụp một snapshot của volume ở Availability Zone một. Snapshot tạo ra một image được lưu trong S3 và chứa toàn bộ dữ liệu của volume.

Từ snapshot đó, triển khai một EBS volume hoàn toàn mới trong bất kỳ Availability Zone nào muốn, bởi vì S3 khả dụng trên mọi Availability Zone trong một region. Volume mới sẽ có đủ dữ liệu của volume gốc, và lúc này attach nó vào EC2 instance ở Availability Zone hai được.

Vậy cách chuyển dữ liệu giữa các Availability Zone là: chụp snapshot, rồi triển khai một EBS volume mới từ snapshot đó. Snapshot nằm trong S3.

Chuyển dữ liệu giữa hai region​

Snapshot chỉ nằm trong S3 bucket của cùng region, nên muốn mang dữ liệu từ Region One sang Region Two thì thêm một bước copy:

  1. Chụp snapshot của EBS volume, snapshot được lưu trong một S3 bucket trong cùng region.
  2. Copy snapshot sang S3 bucket ở region thứ hai. Về bản chất snapshot cũng chỉ là dữ liệu, giống như lưu một file bất kỳ trong một S3 bucket.
  3. Từ snapshot đã copy, tạo volume.
Phạm vi cần chuyểnThao tác
Cùng Availability ZoneDetach volume rồi attach vào EC2 instance khác
Khác Availability Zone, cùng regionSnapshot, rồi tạo volume từ snapshot trong Availability Zone đích
Khác regionSnapshot, copy snapshot sang region đích, rồi tạo volume từ snapshot đã copy

Các EBS volume type​

Amazon EBS cung cấp các volume type khác nhau về đặc tính performance và giá, để chọn được mức storage performance và chi phí khớp với nhu cầu của application.

NhómVolume type
General purpose SSDgp2, gp3
Provisioned IOPS SSDio1, io2, io2 Block Express
Throughput optimized hard disk drivest1
Cold hard disk drivesc1
Magneticstandard

General purpose SSD​

Ý chính của general purpose SSD là đây là các volume được backed bởi solid-state drive. Chúng cân bằng giữa giá và performance, và rất phù hợp cho nhiều loại transactional workload, gồm:

  • Virtual desktop.
  • Medium-sized single-instance database.
  • Latency-sensitive interactive application.
  • Development và test environment.

Nhìn chung nhóm này được khuyến nghị cho phần lớn workload. Khi chưa chắc cần volume type nào thì khởi đầu bằng SSD, nó phủ được hầu hết các workload cần xử lý.

Bên trong general purpose SSD có hai loại:

  • gp3 là generation mới nhất của general purpose SSD volume và là SSD volume có giá thấp nhất mà Amazon EBS cung cấp. Volume type này giúp có đúng mức cân bằng giữa giá và performance cho phần lớn application. Nó còn cho phép scale volume performance độc lập với volume size, nghĩa là provision được mức performance cần thiết mà không phải provision thêm dung lượng block storage. Ngoài ra gp3 có giá mỗi gigabyte thấp hơn hai mươi phần trăm so với general purpose SSD gp2.
  • gp2 là generation trước của general purpose SSD. Nó cung cấp storage tiết kiệm chi phí, lý tưởng cho một phổ rộng các transactional workload, nhưng với gp2 thì performance scale theo volume size, không tách rời được như gp3.

Về loại volume mặc định: AMI Amazon Linux 2023 mặc định cấp gp3, chỉ các AMI Amazon Linux 2 đời cũ mới mặc định gp2. Loại volume đổi được ngay tại bước launch instance, không phải cấu hình bất biến.

Provisioned IOPS SSD​

Nhóm này cũng được backed bởi solid-state drive, và được xếp là EBS storage volume có performance cao nhất, thiết kế cho các workload IOPS-intensive và throughput-intensive đòi hỏi low latency.

Bên trong provisioned IOPS SSD có ba phiên bản: io2, io2 với Block Express, và io1.

Khác biệt giữa io2 và io1: hai loại này gần như giống nhau một trăm phần trăm. Điểm khác duy nhất là durability.

Hạng mụcio1io2io2 Block Express
Durability99,8% tới 99,9%99,999%99,999%
Max volume size16 TB16 TB64 TB
Max IOPS mỗi volume64.00064.000256.000
Max throughput mỗi volume1.000 MB/s1.000 MB/s4.000 MB/s

Mọi specification khác giữa io2 và io1 là giống nhau, chỉ durability khác.

Khác biệt giữa io2 và io2 Block Express nằm ở bốn con số trong bảng trên: max volume size, max IOPS mỗi volume, max throughput mỗi volume. Do đó các workload cần latency dưới một millisecond, cần sustained IOPS trên 64.000, hoặc cần throughput trên 1.000 megabyte, thì phải dùng io2 Block Express. Nếu không cần phần performance thừa đó thì io1 hoặc io2 là đủ.

So general purpose SSD với provisioned IOPS SSD:

Hạng mụcGeneral purpose SSDio1 / io2io2 Block Express
Max IOPS mỗi volume16.00064.000256.000
Max throughput mỗi volumegần tương đương io1/io21.000 MB/s4.000 MB/s
Multi-Attachkhông hỗ trợhỗ trợhỗ trợ

Điểm cần nhớ cho kỳ thi: provisioned IOPS SSD được thiết kế để đáp ứng workload I/O-intensive, đặc biệt là các database workload nhạy cảm với storage performance và tính nhất quán. Nghĩ tới provisioned IOPS SSD là nghĩ tới performance, còn general purpose là loại làm mọi thứ ở mức khá. Khi cần phần performance thừa đó thì chuyển sang provisioned IOPS SSD.

Hard disk drive-backed volume​

Nhóm volume type tiếp theo là các volume backed bởi hard disk drive. Khác với solid-state drive, đây là ổ cứng cơ, có bộ phận chuyển động, nên chậm hơn các volume type truyền thống dựa trên SSD.

Hard disk drive-backed volume của Amazon EBS chia làm hai loại:

  • Throughput optimized hard disk drive (st1): hard disk drive giá thấp, thiết kế cho các workload throughput-intensive được truy cập thường xuyên.
  • Cold hard disk drive (sc1): hard disk drive giá thấp nhất, thiết kế cho các workload ít được truy cập hơn.
Hạng mụcThroughput optimized HDD (st1)Cold HDD (sc1)
Durabilitygiống nhaugiống nhau
Use casebig data, data warehouse, log processingthroughput-oriented storage cho dữ liệu ít được truy cập, các tình huống mà chi phí storage thấp nhất là yếu tố quan trọng
Max volume size16 TiB16 TiB
IOPS mỗi volumecao hơn sc1thấp hơn st1
Throughput mỗi volumecao hơn sc1thấp hơn st1
Multi-attachkhôngkhông
Boot volumekhôngkhông

Cold hard disk drive là loại rẻ nhất trong các lựa chọn. Giữa hai loại hard disk drive thì cold hard disk drive kém performance hơn một chút.

Nhìn tổng thể, hard disk drive là phương án rẻ hơn so với solid-state drive. Xếp từ performance cao nhất xuống thấp nhất:

  1. Provisioned IOPS SSD.
  2. General purpose SSD.
  3. Hard disk drive-backed volume.

Magnetic​

Volume type cuối cùng là magnetic standard volume, một generation trước, backed bởi magnetic drive. Nó phù hợp cho workload có tập dữ liệu nhỏ, dữ liệu được truy cập không thường xuyên, và performance không phải yếu tố quan trọng hàng đầu.

Các volume này cho khoảng 100 IOPS trung bình, với khả năng burst lên hàng trăm IOPS, và kích cỡ nằm trong khoảng 1 gigabyte tới 1 terabyte.

Pricing của EBS​

Với Elastic Block Storage thì chỉ trả tiền cho phần đã provision. Mức tính là mỗi gigabyte mỗi tháng: provision càng nhiều gigabyte thì trả càng nhiều.

Chi phí mỗi gigabyte thay đổi theo volume type được chọn. Volume type có IOPS nhanh hơn thì đương nhiên đắt hơn.

EBS snapshot cũng được tính theo mỗi gigabyte mỗi tháng. Theo nguồn gốc thì đây là full snapshot, không phải incremental snapshot chỉ theo dõi phần thay đổi, nên phần trả là trọn chi phí.

Tóm tắt mục này​

  • Block storage cắt dữ liệu thành các block rồi lưu từng block như một mảnh riêng, mỗi mảnh có unique identifier.
  • Một tập hợp block trình ra cho operating system thành một volume.
  • Boot và mount được từ block storage. Đây là điểm rất quan trọng cho kỳ thi Solutions Architect: thứ phân biệt block storage với file system storage và object storage chính là khả năng vừa boot vừa mount.
  • Elastic Block Storage cung cấp block-level storage volume để dùng với EC2 instance.
  • EBS volume được provision trong một Availability Zone.
  • Để copy dữ liệu từ một EBS volume sang Availability Zone khác: tạo EBS snapshot, rồi tạo volume từ snapshot đó trong Availability Zone mong muốn.
  • EBS cung cấp nhiều volume type cho các nhu cầu storage khác nhau.
  • Chỉ trả tiền cho phần đã provision, tính theo mỗi gigabyte mỗi tháng.

2. Thực hành: EBS trong cùng một Availability Zone​

Môi trường chuẩn bị trước​

Để không mất thời gian vào các việc lặp lại, môi trường được dựng sẵn gồm bốn EC2 instance. Khác biệt duy nhất giữa chúng là vị trí:

InstanceRegionAvailability Zone
server oneNorthern Virginia (us-east-1)us-east-1a
server twoNorthern Virginia (us-east-1)us-east-1a
server threeNorthern Virginia (us-east-1)us-east-1b
server fourOhio (us-east-2)us-east-2a

Cách bố trí này để minh họa đúng cái cần minh họa: Elastic Block Store được triển khai vào một Availability Zone cụ thể và chỉ attach được vào EC2 instance trong cùng Availability Zone.

Bước 1: tạo EBS volume​

Volume phải nằm trong đúng Availability Zone của server one. Cách xác định là mở trang chi tiết của instance và đọc Availability Zone, ở đây là us-east-1a.

Vào trang EC2, cuộn xuống mục Volumes, bấm Create volume:

  • Volume type: để mặc định gp2.
  • Size: 10 gigabyte, giữ đơn giản cho phần minh họa.
  • Availability Zone: đây là phần quan trọng, chọn us-east-1a.
  • Snapshot: bỏ qua ở bước này.
  • Encryption: tắt, vì đây chỉ là minh họa đơn giản.

Bấm Create volume. Volume hiện ra ở trạng thái available. Đặt tên cho nó, ví dụ demo volume.

Bước 2: attach volume vào EC2 instance​

Khi volume đã available, chọn Actions rồi Attach Volume. Console sẽ chỉ liệt kê các EC2 instance trong cùng Availability Zone, nên danh sách hiện ra đúng hai cái: server one và server two.

Chọn server one. Console cho biết block storage này sẽ xuất hiện dưới tên /dev/sdf, kèm một lưu ý: trên các Linux kernel mới hơn, device có thể bị đổi tên thành /dev/xvdf cho tới /dev/xvdp ở bên trong hệ thống, dù tên device nhập ở đây khác. Nghĩa là tên thực tế có thể là tên đã nhập, hoặc là một trong các tên được nhắc trong lưu ý đó.

Bấm Attach volume. Volume giờ đã attach vào EC2 instance.

Bước 3: kiểm tra block device trên server one​

Mở terminal tới server one. Lệnh liệt kê toàn bộ block device đang attach vào máy là lsblk:

lsblk
# NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
# xvda    202:0    0   8G  0 disk
# └─xvda1 202:1    0   8G  0 part /
# xvdf    202:80   0  10G  0 disk

Ở đây xvda là root partition, chính là block device đã attach vào máy lúc provision instance. Phía dưới là xvdf, dung lượng 10 gigabyte, đúng bằng kích cỡ đã chỉ định cho Elastic Block Store.

Kết quả này xác nhận hai điều: block storage đã attach thành công vào EC2 instance, và tên device đã bị đổi thành xvdf đúng như lưu ý đọc được trong console lúc attach.

Bước 4: kiểm tra xem đã có file system chưa​

Việc đầu tiên cần làm với block device này là xác minh xem trên nó đã có file system nào chưa. Lệnh dùng là sudo file -s trỏ vào đúng block device đó:

sudo file -s /dev/xvdf
# /dev/xvdf: data

Thấy chữ data nghĩa là chưa có file system nào trên device tại thời điểm này. Đúng như mong đợi với một volume mới.

Bước 5: tạo file system​

sudo mkfs -t xfs /dev/xvdf
# meta-data=/dev/xvdf              isize=512    agcount=4, agsize=655360 blks
# ...
# Discarding blocks...Done.

Cờ -t chỉ định loại file system muốn tạo, ở đây chọn XFS, rồi truyền vào /dev/xvdf.

Chạy lại lệnh kiểm tra ở bước trước để xác minh file system đã được tạo thành công:

sudo file -s /dev/xvdf
# /dev/xvdf: SGI XFS filesystem data (blksz 4096, inosz 512, ...)

Lần này kết quả cho thấy đã có một XFS file system trên block storage đó.

Bước 6: mount file system​

Mount file system này vào một directory, ví dụ đường dẫn EBS-demo. Về root directory rồi tạo directory để mount vào:

cd /
sudo mkdir EBS-demo

Lệnh mount chỉ cần hai tham số, block device và directory:

sudo mount /dev/xvdf /EBS-demo

Xác minh file system đã mount bằng df -k:

df -k
# Filesystem     1K-blocks    Used Available Use% Mounted on
# /dev/xvda1       8376300 1659096   6717204  20% /
# /dev/xvdf       10474496   32992  10441504   1% /EBS-demo

Thấy /dev/xvdf đang được mount tại /EBS-demo.

Bước 7: giữ mount qua reboot​

Phần này không riêng của AWS và cũng không quan trọng cho kỳ thi Solutions Architect, nhưng cần biết để làm việc thực tế. Thao tác mount vừa làm chỉ là tạm thời: reboot máy là mount biến mất, nó không tồn tại qua reboot. Muốn directory tự mount lại mỗi lần server reboot thì cần thêm vài bước.

Việc đầu tiên là lấy unique identifier của EBS volume:

sudo blkid
# /dev/xvda1: LABEL="/" UUID="a1b2c3d4-..." TYPE="xfs"
# /dev/xvdf: UUID="e5f6a7b8-9012-3456-7890-abcdef123456" TYPE="xfs"

Tìm dòng của /dev/xvdf, đó là unique identifier cần dùng. Copy giá trị đó lại.

Tiếp theo là sửa file /etc/fstab:

sudo vi /etc/fstab

Quan sát cách các mount có sẵn được khai: truyền vào unique identifier, vị trí muốn mount, loại file system, rồi vài option khác. Thêm một dòng mới:

UUID=e5f6a7b8-9012-3456-7890-abcdef123456  /EBS-demo  xfs  defaults,nofail  0 0

Các option dùng ở đây là defaults và nofail. Phần chi tiết của từng option không quan trọng cho kỳ thi Solutions Architect nên không đi sâu. Lưu file rồi đóng lại.

Mount ở bước trên đã thực hiện rồi, dù chỉ tạm thời. Nếu trước đó chưa mount và chỉ vừa sửa file này, thì mount được tự động mọi thứ liệt kê trong /etc/fstab bằng:

sudo mount -a

Bước 8: tạo một file để đánh dấu​

Tạo một file trong volume để sau này nhận ra dữ liệu có đi theo volume hay không. Cách thứ nhất là echo rồi redirect vào một file tên demo.txt, nhưng việc này cần quyền sudo ở đúng chỗ, nên cách gọn hơn là mở thẳng bằng vi:

cd /EBS-demo
echo "I made this file on server one" > demo.txt
# bash: demo.txt: Permission denied

sudo vi demo.txt
# nội dung file: I made this on server one

Kiểm tra lại:

ls
# demo.txt

Bước 9: unmount và detach khỏi server one​

Phần tiếp theo cho thấy EBS volume hoàn toàn tách rời khỏi EC2 instance: detach nó khỏi instance này rồi attach vào instance khác.

Việc đầu tiên là unmount file system. Lệnh đúng là umount, không phải unmount:

sudo umount /EBS-demo
# umount: /EBS-demo: target is busy.

Lỗi này xuất hiện vì shell đang đứng trong chính folder đó. Đi lên một directory rồi chạy lại:

cd ..
sudo umount /EBS-demo

Xác minh bằng df -k:

df -k
# Filesystem     1K-blocks    Used Available Use% Mounted on
# /dev/xvda1       8376300 1659096   6717204  20% /

/dev/xvdf không còn trong danh sách, nghĩa là đã unmount xong. Đó là toàn bộ việc cần làm trên máy này. Tắt máy cũng được, nhưng unmount đơn giản hơn.

Về console, vào EBS volume, chọn Actions rồi Detach Volume. Có thể cần refresh để trạng thái cập nhật.

Bước 10: attach vào server two và đọc lại dữ liệu​

Khi volume đã detach, mở Actions rồi Attach Volume lần nữa và chọn server two. Bấm Attach volume. Volume giờ attach vào server two.

Việc này làm được vì server two nằm cùng Availability Zone với volume.

Về terminal, chuyển sang server two và xác minh volume đã attach:

lsblk
# NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
# xvda    202:0    0   8G  0 disk
# └─xvda1 202:1    0   8G  0 part /
# xvdf    202:80   0  10G  0 disk

xvdf với 10 gigabyte chính là EBS volume giờ đã attach vào server two.

Kiểm tra xem trên block device đã có file system chưa:

sudo file -s /dev/xvdf
# /dev/xvdf: SGI XFS filesystem data (blksz 4096, inosz 512, ...)

Lần này đã có file system, vì XFS file system được tạo từ máy trước và nó nằm trong volume, không nằm trong instance.

Mount file system này để bắt đầu đọc ghi dữ liệu. Mount vào đâu cũng được, ở đây tạo cùng tên folder EBS-demo trong root directory:

cd /
sudo mkdir EBS-demo
sudo mount /dev/xvdf /EBS-demo
cd /EBS-demo
ls
# demo.txt
cat demo.txt
# I made this on server one

File demo.txt còn nguyên cùng nội dung được ghi từ server one.

Kết luận của phần thực hành này​

Dữ liệu lấy từ một máy và trỏ sang một máy khác được, vì mọi thứ nằm trong Elastic Block Store, tách rời khỏi EC2 instance.

Ứng dụng thực tế: khi cần bảo trì, hoặc khi cần migrate dữ liệu sang một EC2 instance khác, chỉ cần unmount EBS volume khỏi instance này rồi chuyển sang instance khác. Xong việc bảo trì thì chuyển ngược lại. Không bao giờ phải lo chuyện lấy dữ liệu ra khỏi máy, vì dữ liệu nằm trên EBS chứ không nằm trên chính EC2 instance.

3. Thực hành: chuyển dữ liệu EBS qua Availability Zone và qua region​

Mục trên kết thúc ở chỗ EBS volume đã chuyển từ server one sang server two. Việc đó không gặp vấn đề gì vì hai instance cùng một Availability Zone, đúng Availability Zone mà EBS volume đang nằm. Volume chuyển được sang bất kỳ EC2 instance nào trong cùng Availability Zone.

Phần này thử chuyển EBS volume sang server three, instance nằm ở us-east-1b, một Availability Zone khác.

Bước 1: unmount và detach​

sudo umount /EBS-demo

Lưu ý lệnh là umount, không phải unmount.

df -k
# Filesystem     1K-blocks    Used Available Use% Mounted on
# /dev/xvda1       8376300 1659096   6717204  20% /

Không còn file system nào của volume được mount.

Về console, refresh, vào mục EBS volume, chọn volume rồi Detach volume. Trạng thái có thể còn in-use một lúc, refresh thêm vài lần cho tới khi nó về available.

Bước 2: xác nhận không attach được qua Availability Zone​

Chọn volume, bấm Attach volume, và thử chọn server three. Kết quả: server three không xuất hiện trong danh sách. Chỉ có server one và server two, bởi vì server three nằm ở Availability Zone khác.

Đây đúng là hành vi đã nêu ở phần lý thuyết. Cách vượt qua rào này là snapshot.

Bước 3: tạo snapshot​

Chọn volume, bấm Create Snapshot. Có thể điền description, ví dụ my snapshot. Bấm tạo snapshot của volume này.

Về bản chất thao tác này chụp lại toàn bộ dữ liệu trong volume đó, tức tạo một bản copy.

Snapshot hiện ra trong danh sách kèm description my snapshot. Ban đầu nó chưa khả dụng, tiến độ hiển thị kiểu 7%. Chờ cho tới khi snapshot chuyển sang trạng thái available.

Bước 4: tạo volume mới từ snapshot trong Availability Zone đích​

Khi snapshot đã available, chọn nó, mở Actions rồi Create volume from snapshot.

Thao tác này nghĩa là: đã có snapshot của volume, giờ tạo một volume hoàn toàn mới, và tạo volume mới đó trong Availability Zone mong muốn.

  • Volume type: đổi được nếu muốn.
  • Size: tăng được nếu muốn.
  • Availability Zone: đây là phần thực sự quan trọng, chọn us-east-1b, tức Availability Zone mà server three đang nằm.
  • Encryption: có tùy chọn bật nếu muốn.
  • Tag Name: đặt là EBS clone.

Bấm tạo. Vào mục Volumes sẽ thấy EBS clone, và cụ thể hơn, nó nằm ở us-east-1b.

Bước 5: attach vào server three và kiểm tra dữ liệu​

Chọn volume clone, mở Actions rồi Attach Volume. Lần này server three xuất hiện và attach được.

Mở terminal tới server three rồi làm đúng các bước như trên hai máy trước.

lsblk
# NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
# xvda    202:0    0   8G  0 disk
# └─xvda1 202:1    0   8G  0 part /
# xvdf    202:80   0  10G  0 disk
sudo file -s /dev/xvdf
# /dev/xvdf: SGI XFS filesystem data (blksz 4096, inosz 512, ...)

Đã có XFS file system, đúng như mong đợi.

cd /
sudo mkdir EBS-demo
sudo mount /dev/xvdf /EBS-demo
cd /EBS-demo
ls
# demo.txt

File demo.txt nằm ở đó, vì snapshot là một bản copy đầy đủ của toàn bộ block storage, và volume mới được tạo từ bản copy đó. Nó có đủ dữ liệu đã có trên block storage gốc.

Đó là cách chuyển dữ liệu từ một Availability Zone sang Availability Zone khác.

Bước 6: vấn đề khi đích nằm ở region khác​

Câu hỏi tiếp theo: làm sao để cùng block storage đó attach được vào một EC2 instance ở region khác. server four nằm ở Ohio, còn block store gốc nằm ở Northern Virginia.

Thử cách cũ: vào mục snapshot, chọn snapshot, mở Actions, chọn Create volume from snapshot. Form này không cho chỉ định region để triển khai volume vào.

Vậy thay vì tạo volume trực tiếp từ snapshot, phải copy snapshot sang region đích trước, rồi tạo volume từ snapshot đã copy. Nói cách khác, copy nó sang một S3 bucket, hay chính xác hơn là copy sang region muốn triển khai volume.

Bước 7: copy snapshot sang region khác​

Chọn snapshot, bấm Copy Snapshot. Điền description, ví dụ copy of my snapshot.

Tại đây có ô chỉ định destination region. Ohio là us-east-2. Bấm copy snapshot.

Chuyển console sang region us-east-2, vào mục snapshot, sẽ thấy copy of my snapshot. Ban đầu nó còn đang trong quá trình copy. Chờ cho tới khi hoàn tất.

Bước 8: tạo volume từ snapshot đã copy rồi attach​

Khi snapshot đã hoàn tất, chọn nó rồi bấm Create volume from snapshot.

Trước đó cần biết Availability Zone của server đích. server four nằm ở us-east-2a, nên triển khai volume vào us-east-2a.

Vào mục Volumes, volume đã được tạo và ở trạng thái available. Chọn nó, bấm Attach volume, chọn server four, rồi attach.

BướcThao tác
1Unmount file system trên instance đang dùng
2Detach volume
3Create snapshot của volume
4Copy snapshot sang destination region
5Create volume from snapshot trong Availability Zone của instance đích
6Attach volume vào instance đích rồi mount file system

4. Instance store​

Instance store là gì​

Instance store cung cấp temporary block level storage cho EC2 instance. Tùy theo EC2 instance type, AWS có thể cấp kèm một instance store, và đó là block level storage mang tính tạm thời.

Các instance store này nằm vật lý trên đĩa gắn vào host computer. Đây là điểm khác EBS: dữ liệu EBS được lưu trên một máy riêng và instance kết nối tới đó từ xa qua một protocol như iSCSI. Còn instance store nằm ngay trên host computer đang chạy EC2 instance.

Vì vậy instance store chỉ nên dùng cho storage tạm thời hoặc cho thông tin thay đổi liên tục, kiểu temporary content hoặc scratch data.

💡 Hình dung: instance store giống ổ cứng gắn bên trong chính cái máy đang ngồi làm việc, còn EBS giống một ổ NAS trong phòng máy. Khi đổi sang một cái máy khác thì ổ NAS vẫn ở đó và cắm vào máy mới được, còn ổ cứng bên trong cái máy cũ thì ở lại với cái máy cũ.

Cơ chế hoạt động​

Hình dung vài EC2 instance đang chạy trên một host machine. Instance store là đĩa vật lý nằm trên chính host machine đó, nên khi một EC2 instance có instance store thì đó chỉ là một ổ đĩa vật lý trên local host machine.

Điểm cần nhấn: nếu EC2 instance sập rồi lên lại, chẳng hạn vừa reboot, nó vẫn truy cập được instance store. Dù là storage tạm thời, chừng nào EC2 instance còn ở trên host đó thì nó vẫn luôn truy cập được đúng instance store đó. Instance thứ hai trên cùng host cũng luôn truy cập được instance store của riêng nó.

Vấn đề phát sinh khi EC2 instance sập và lên lại trên một EC2 host khác, điều này hoàn toàn có thể xảy ra. Tắt EC2 instance đi, khi bật lại nó có thể bị chuyển sang host khác. Lúc đó nó không truy cập được instance store cũ, vì instance store đó nằm trên một host hoàn toàn khác. Thay vào đó, khi lên trên host mới, nó truy cập được một instance store khác, instance store của host mới.

Và điểm quan trọng: toàn bộ dữ liệu đã có trên instance store cũ giờ đã mất. Instance bắt đầu lại với một trang trắng trên instance store mới.

Chính vì vậy nó được gọi là temporary storage: nếu vì lý do nào đó EC2 instance bị chuyển từ host này sang host khác thì toàn bộ dữ liệu mất và không truy cập lại được. Chỉ nên dùng cho dữ liệu tạm hoặc scratch data không quan trọng.

Tóm tắt mục này​

  • Instance store chỉ nên dùng cho dữ liệu tạm thời.
  • Nếu một EC2 instance bị chuyển từ host này sang host khác thì nó mất toàn bộ dữ liệu của instance store ban đầu.
  • Instance store là block-level storage. Không phải loại storage nào khác, nó là block storage.

5. Thực hành: instance store​

Điểm chính của phần này: mỗi khi EC2 instance di chuyển từ một physical host sang một physical host khác thì dữ liệu lưu trên instance store sẽ mất, bởi vì sang host mới là nhận một instance store hoàn toàn mới, nên toàn bộ dữ liệu bị xóa sạch.

Điều cần nhớ: mọi thứ lưu trên instance store chỉ nên là dữ liệu tạm, kiểu scratch data, những thứ không cần tồn tại lâu. Vì nếu phải stop rồi start EC2 instance thì dữ liệu đó sẽ mất.

Bước 1: launch instance có instance store​

Vào EC2, bấm Launch instance:

  • Name: instance-demo.
  • Image: chọn Amazon Linux 64-bit.
  • Instance type: đây là chỗ cần chú ý. Không phải mọi EC2 instance type đều hỗ trợ instance store, chỉ một số loại có. Nên không dùng được t2.micro và không ở lại trong diện free tier được. Nói chung không dùng được các instance nằm trong Free Tier, mà phải chọn một instance đắt hơn để có instance store.
  • Key pair: chọn key pair muốn dùng.
  • Mọi thứ còn lại để mặc định.

Một lưu ý về chi phí trước khi deploy: mốc "750 giờ t2.micro mỗi tháng trong 12 tháng" chỉ còn đúng với account mở trước 15/07/2025. Account mở sau ngày đó nhận 100 USD credit cộng tối đa 100 USD nữa, và phần credit hết hạn sau 6 tháng. Thêm nữa, từ 01/02/2024 mọi public IPv4 address bị tính 0,005 USD mỗi giờ kể cả khi đang gắn vào instance đang chạy, nên một instance để quên vẫn phát sinh phí dù phần compute được miễn. Phần dọn dẹp ở cuối bài vì vậy là thao tác cần làm, không phải thao tác cho gọn.

Phần cấu hình storage cho thấy một root volume 8 gigabyte, và phía dưới nó là phần instance store: một instance store 75 gigabyte, kèm device name của nó là /dev/nvme0n1.

Bảo đảm auto-assign public IP đang bật để kết nối được vào instance. Bấm deploy.

Bước 2: kiểm tra block device​

Về tab Instances, lấy public IP của instance rồi kết nối vào. Khi đã có terminal, chạy đúng các lệnh đã dùng trong phần thực hành EBS.

lsblk
# NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
# nvme0n1     259:0    0     8G  0 disk
# └─nvme0n1p1 259:1    0     8G  0 part /
# nvme1n1     259:2    0  69.8G  0 disk

nvme0n1 là root volume, nơi operating system được cài. Còn instance store 75 gigabyte là nvme1n1, và dung lượng hiển thị là 69,8 gigabyte.

Bước 3: tạo file system và mount​

Từ đây các bước giống hệt phần EBS.

sudo file -s /dev/nvme1n1
# /dev/nvme1n1: data

Kết quả data nghĩa là chưa có file system.

sudo mkfs -t xfs /dev/nvme1n1
# meta-data=/dev/nvme1n1           isize=512    agcount=4, ...
# Discarding blocks...Done.
sudo file -s /dev/nvme1n1
# /dev/nvme1n1: SGI XFS filesystem data (blksz 4096, inosz 512, ...)

Đã có XFS file system. Tạo directory để mount vào rồi mount:

sudo mkdir instance-demo
sudo mount /dev/nvme1n1 instance-demo

Kiểm tra bằng df -k trước khi vào folder:

df -k
# Filesystem     1K-blocks    Used Available Use% Mounted on
# /dev/nvme0n1p1   8376300 1659096   6717204  20% /
# /dev/nvme1n1    73108456   33016  73075440   1% /instance-demo

Thấy instance-demo đang gắn với /dev/nvme1n1. Vào folder đó và tạo một file có nội dung bất kỳ để đánh dấu.

Bước 4: reboot không làm mất dữ liệu​

Phần tiếp theo cho thấy đây thực sự là dữ liệu tạm. Instance store chỉ bị mất khi và chỉ khi EC2 instance vì lý do nào đó chuyển sang một physical host khác.

Chuyện gì làm EC2 instance chuyển host thì hơi dễ nhầm. Có thể nghĩ reboot sẽ làm điều đó, nhưng thực tế thì không. Reboot vẫn làm EC2 instance lên lại trên cùng physical EC2 host.

Cách kiểm chứng: chọn instance rồi bấm Reboot. Và cách dễ nhất để biết instance có bị chuyển host hay không là xem IP address. Public IP address đổi thường có nghĩa là instance đã bị chuyển sang EC2 host khác.

Sau khi reboot xong, public IP address vẫn như cũ, đúng cái trước khi reboot. Đó là dấu hiệu cho biết EC2 instance không chuyển sang physical host khác.

SSH trở lại vào server:

lsblk
# NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
# nvme0n1     259:0    0     8G  0 disk
# └─nvme0n1p1 259:1    0     8G  0 part /
# nvme1n1     259:2    0  69.8G  0 disk

Instance store volume vẫn còn đó. Nhưng:

df -k
# Filesystem     1K-blocks    Used Available Use% Mounted on
# /dev/nvme0n1p1   8376300 1659116   6717184  20% /

Volume không còn được mount. Nguyên nhân là lệnh sudo mount đã chạy trước đó chỉ có tác dụng tạm thời. Reboot máy thì mount không được lập lại. Muốn giữ qua reboot thì phải sửa /etc/fstab.

Chỉ cần chạy lại lệnh mount một lần nữa:

sudo mount /dev/nvme1n1 instance-demo
cd instance-demo
ls
# test

File test vẫn còn. Nghĩa là reboot không làm instance chuyển sang physical host khác, nên instance store vẫn đúng là instance store cũ.

Bước 5: stop rồi start thì dữ liệu mất​

Về EC2 console, lần này thay vì reboot thì stop instance, chờ vài phút, rồi start lại. Việc này sẽ làm instance chuyển sang một EC2 host khác.

Ghi lại IP address trước khi stop, ví dụ 54.198.242.218. Stop, chờ vài phút, rồi start lại.

Sau khi start, IP address bắt đầu bằng số ba, nghĩa là đã khác hẳn. Đó là xác nhận instance đã bị chuyển sang một EC2 host khác, và nó sẽ nhận một instance store volume hoàn toàn mới, không có dữ liệu, tồn tại trên host mới, bởi vì cái cũ nằm trên physical host kia.

SSH vào máy với IP mới:

lsblk
# NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
# nvme0n1     259:0    0     8G  0 disk
# └─nvme0n1p1 259:1    0     8G  0 part /
# nvme1n1     259:2    0  69.8G  0 disk

Instance store volume vẫn tên y như cũ, nvme1n1, vẫn 75 gigabyte. Nhưng:

sudo file -s /dev/nvme1n1
# /dev/nvme1n1: data

Kết quả là data, nghĩa là không có file system nào trên đó. Toàn bộ dữ liệu đã ghi khi instance còn ở physical host cũ giờ đã mất, vì đây là một EC2 instance store volume mới hoàn toàn trên host mới.

Hai điểm cần nhớ cho kỳ thi​

  • Instance store volume không dùng cho dữ liệu cần tồn tại lâu dài. Nó chỉ dành cho dữ liệu tạm, vì mỗi khi EC2 instance chuyển từ host này sang host khác là mất dữ liệu.
  • Reboot EC2 instance thì instance không chuyển sang EC2 host khác. Stop rồi start thì có.

6. EFS: file system storage cho Linux​

EFS là gì​

Mục này nói về file system storage, cụ thể hơn là service file system storage của AWS tên Elastic File System.

Amazon Elastic File System là service file system storage thứ nhất trong hai service loại này mà Amazon cung cấp, cái còn lại là Amazon FSx.

EFS hỗ trợ protocol Network File System (NFS), nên mọi application dùng protocol đó đều làm việc trơn tru với Amazon Elastic File System storage.

Với EFS, cách dùng là tạo một file system, rồi EC2 instance và các compute service khác kết nối từ xa tới file system đó và mount nó.

Hai đặc tính quan trọng:

  • EFS không làm việc với EC2 instance chạy Windows, chỉ Linux.
  • Một EFS file system mount được lên nhiều EC2 instance cùng lúc. Nhờ vậy dữ liệu được chia sẻ giữa nhiều EC2 instance.

Mount target​

Để triển khai EFS thì triển khai nó vào một VPC, nên nó gắn với VPC cụ thể. Khái niệm VPC, subnet và security group đã được mổ xẻ ở bài về networking.

Một EFS file system được làm cho khả dụng bên trong một VPC thông qua mount target. Cách làm là chỉ định các subnet muốn triển khai mount target vào. Khi mount target đã được triển khai vào một subnet, nó nhận một IP address. Và đó chính là bản chất của mount target: nó chỉ là một IP address.

EC2 instance sau đó kết nối tới EFS file system bằng cách chỉ định IP address của mount target. Mount target chính là đường để kết nối tới EFS file system.

Để bảo đảm high availability thì cần có mount target ở nhiều Availability Zone. Khi một Availability Zone sập thì vẫn kết nối được qua mount target khác.

Storage class của EFS​

EFS cung cấp các storage class sau cho nhiều use case khác nhau:

NhómStorage classĐặc tính
StandardEFS Standard, EFS Standard-Infrequent Accessmulti-AZ resilience, mức durability và availability cao nhất
One ZoneEFS One Zone, EFS One Zone-Infrequent Accesstiết kiệm thêm chi phí bằng cách chỉ lưu dữ liệu trong một Availability Zone

Performance mode và throughput mode​

Ngoài storage class, EFS còn cung cấp các performance mode khác nhau, xử lý các nhu cầu throughput, IOPS và latency khác nhau cho một phổ rộng workload:

  • General Purpose performance mode: lý tưởng cho các application nhạy cảm với latency như web application, content management system, home directory, và general file serving.
  • Elastic Throughput mode: thiết kế để tự động scale throughput performance lên hoặc xuống theo nhu cầu hoạt động của workload.
  • Max I/O performance mode: scale lên được mức aggregate throughput và số operation mỗi giây cao hơn. Đánh đổi là các file system này có latency cao hơn cho các file system operation.
  • Provisioned throughput mode: chỉ định một mức throughput mà file system có thể đạt, độc lập với kích cỡ file system hoặc burst credit balance.
  • Bursting throughput mode: cung cấp throughput scale theo lượng storage trong file system, và hỗ trợ burst lên mức cao hơn tới mười hai giờ mỗi ngày.

Cài đặt và mount EFS trên EC2 Linux instance​

Có hai việc cần làm. Việc thứ nhất là cài Amazon EFS Utils:

sudo dnf -y install amazon-efs-utils

Hoặc dùng package manager khác tùy distro:

sudo apt install amazon-efs-utils
sudo yum install amazon-efs-utils

Lệnh này cài toàn bộ EFS utility cần thiết.

Việc thứ hai là mount EFS file system vào một directory cụ thể:

sudo mount -t efs <file-system-id> /mnt/efs

Loại efs truyền vào -t đến từ chính bộ EFS utility vừa cài, nghĩa là đang mount một EFS file system. Tiếp theo là ID của EFS file system đã cấu hình, và ID đó lấy từ AWS console. Cuối cùng là directory muốn mount vào.

Về bản chất việc này giống mount bất kỳ loại file system nào khác. Khác biệt chỉ là phải lấy EFS ID và phải chỉ định rằng đang mount một file system loại EFS.

Tóm tắt mục này​

  • EFS là service file system storage do Amazon cung cấp.
  • EFS hỗ trợ protocol Network File System, nên mọi application dùng protocol đó đều làm việc trơn tru với EFS.
  • EFS không hỗ trợ EC2 instance chạy Windows, chỉ Linux.
  • EFS file system mount được lên nhiều EC2 instance cùng lúc.
  • EFS file system được làm cho khả dụng bên trong một VPC thông qua mount target. IP address của mount target là đường để hệ thống kết nối tới EFS file system.
  • EFS cung cấp hai nhóm storage class, Standard và One Zone, và có hai performance mode là general purpose performance mode và elastic throughput mode.
  • EFS mount được nhưng không boot được. Không cài operating system lên EFS. Đây là khác biệt lớn giữa block storage và file system storage: file system storage mount được nhưng không boot được, còn EBS volume thì boot được.

7. Thực hành: EFS mount trên hai EC2 instance​

Môi trường chuẩn bị trước​

Môi trường gồm một VPC đơn giản có hai subnet, cụ thể là hai subnet nằm ở hai Availability Zone khác nhau. server one chạy ở một Availability Zone và server two chạy ở Availability Zone kia, tức us-east-1a và us-east-1b.

Mục tiêu: tạo một Elastic File System, rồi mount file system đó lên cả hai server để thấy nhiều server mount được cùng một Elastic File System và cùng đọc ghi vào đó đồng thời.

Bước 1: tạo Elastic File System​

Vào trang EFS, bấm tạo Elastic File System. Form hiện ra là menu quick create. Muốn tùy biến đầy đủ thì bấm Customize, và đây là cách làm trong phần này.

  • Name: EFS demo.
  • Storage class: có hai lựa chọn. Một loại lưu dữ liệu dư thừa qua nhiều Availability Zone. Loại One Zone chỉ lưu trong một Availability Zone duy nhất, nhưng dữ liệu vẫn dư thừa bên trong Availability Zone đó. Nghĩa là một máy trong Availability Zone đó chết thì dữ liệu vẫn an toàn, nhưng cả Availability Zone sập thì mất dữ liệu.
  • Automatic backups: bật hoặc tắt tùy nhu cầu.
  • Lifecycle management: dữ liệu có nhiều storage class khác nhau và di chuyển được giữa các storage class đó. Có class IA, viết tắt của infrequently accessed, nghĩa là dữ liệu nào không được truy cập thường xuyên thì lưu ở storage class này với giá rẻ hơn. Phần này cho phép khai kiểu: các file đã tồn tại trên ba mươi ngày thì tự động chuyển sang storage class infrequently accessed để tiết kiệm tiền. Đây là các rule và policy để di chuyển dữ liệu giữa các storage class. Ở phần này để mặc định.
  • Encryption: bật hoặc tắt tùy nhu cầu, ở đây để tắt.
  • Throughput mode: xem tài liệu để biết mode nào phù hợp hơn với workload cụ thể. Lựa chọn gồm Elastic và Provisioned.
  • Performance mode: lựa chọn gồm General Purpose và Max I/O.

Ở đây để mọi thứ mặc định rồi bấm Next.

Bước 2: chọn VPC và cấu hình mount target​

Chọn VPC đang chứa các EC2 instance, ở đây là Demo VPC.

Console tự động cấu hình mount target trong từng Availability Zone. VPC này chỉ có subnet ở hai Availability Zone, us-east-1a và us-east-1b, nên có hai mount target.

Cần có mount target ở mọi Availability Zone trong VPC để có dự phòng. Trong mỗi Availability Zone thì chọn subnet nào cũng được, chọn một subnet bất kỳ là xong.

Tiếp theo là chỉ định security group. Form đang dùng default security group, nhưng ở đây đã tạo sẵn một security group riêng cho EFS file system.

Bước 3: security group cho EFS​

Mở một tab khác, vào EC2 rồi vào mục Security groups, mở security group tên EFS security group.

Mục đích duy nhất của security group này là cho phép traffic đến từ các EC2 instance. Rule đang khai là cho phép mọi loại traffic từ nguồn là security group của các EC2 instance. Lý tưởng thì nên siết xuống chỉ cho đúng EFS traffic, nhưng ở đây để mọi loại traffic cho đơn giản.

Cách khai "mọi traffic đến từ bất kỳ EC2 instance nào của tôi" là: gán cho tất cả EC2 instance cùng một security group, ở đây tên là EC2 instances. Rồi trong EFS security group đặt rule với source chính là security group đó, nghĩa là traffic nào đến từ một instance mang security group đó thì được cho qua.

Soi lại các EC2 instance thì thấy chúng đều mang security group đó, và security group đó đang cho phép SSH cùng all traffic.

Chọn EFS security group cho cả hai mount target. Vậy đã có mount target và security group, bấm Next.

Bước 4: hoàn tất​

Trang tiếp theo cho phép khai các policy nếu muốn, ở đây bỏ qua và bấm Next. Xác nhận lại mọi thứ rồi bấm Create. Chờ vài phút cho file system được tạo xong.

Bước 5: tạo directory mount trên cả hai server​

Khi EFS file system đã sẵn sàng thì mở terminal tới server one và server two.

Tạo directory để mount file system vào. Chọn directory nào cũng được, ở đây là /EFS-demo, và làm trên cả hai server:

sudo mkdir /EFS-demo

Bước 6: cài amazon-efs-utils trên cả hai server​

Cần cài package amazon-efs-utils, đây là thứ cho phép làm việc với EFS file system một cách đơn giản:

sudo dnf -y install amazon-efs-utils
# Installing:
#  amazon-efs-utils    noarch    ...
# Complete!

Ở đây dnf là package manager được dùng, và thư viện cần cài tên là amazon-efs-utils. Cờ -y nghĩa là không phải tự tay nhập y ở prompt hỏi có chắc muốn tải package này không, nó sẽ tự động làm. Chạy lệnh này trên cả server one và server two.

Bước 7: mount EFS file system​

Cấu trúc lệnh mount như sau: sudo, rồi mount, rồi cờ -t. Cờ -t sẽ liệt kê các loại file system mount được, và ở đây chọn efs. Loại này đến từ package vừa cài, nên trước khi cài thì không có lựa chọn đó.

Tiếp theo phải truyền vào file system ID. ID này lấy ở AWS console: chọn EFS file system rồi copy ID của nó. Cuối cùng là directory muốn mount vào.

sudo mount -t efs fs-0123456789abcdef0 /EFS-demo

Xác minh bằng df -k:

df -k
# Filesystem      1K-blocks  Used        Available Use% Mounted on
# /dev/xvda1        8376300  1659096       6717204  20% /
# 127.0.0.1:/    9007199254739968     0  9007199254739968   0% /EFS-demo

Thấy EFS file system đang được mount tại /EFS-demo. Làm đúng việc này trên server two, dán cùng lệnh vào.

Bước 8: kiểm tra chia sẻ dữ liệu giữa hai server​

Vào /EFS-demo trên server one và tạo một file:

cd /EFS-demo
sudo vi file1
# nội dung file: I made this on server one

Sang server two, vào đúng directory đó:

cd /EFS-demo
ls
# file1
cat file1
# I made this on server one

File file1 nằm ở đó cùng nội dung được ghi từ server one.

Thử theo chiều ngược lại, tạo một file trên server two:

sudo vi file2
# nội dung file: I made this on server two

Về server one:

ls
# file1  file2

Thay đổi hiện ra ngay. Vậy cả hai máy đồng thời kết nối được tới Elastic File System và cùng thay đổi các file đó.

Tóm tắt phần thực hành này​

Tạo một Elastic File System chỉ gồm: vào console, tạo EFS file system với các setting mong muốn, bảo đảm khai mount point ở mọi Availability Zone trong VPC, rồi cài package amazon-efs-utils và mount bằng một lệnh đơn giản.

Lưu ý quan trọng: mount theo cách này không tồn tại qua reboot. Muốn giữ qua reboot thì phải mở /etc/fstab và sửa file đó. Hướng dẫn chi tiết nằm trong tài liệu của AWS. Về cơ bản nó giống phần đã làm với EBS, chỉ khác vài option riêng của EFS.

8. FSx: bốn flavor file system storage​

FSx là gì​

FSx là service fully managed cung cấp file storage high-performance cho một phổ rộng workload, thiết kế để việc dựng và quản lý file storage trên cloud trở nên dễ hơn cho doanh nghiệp và tổ chức.

Nghĩa là thay vì phải chịu đựng việc provision và quản lý file server, AWS xử lý toàn bộ phần việc đó.

Về bản chất nó rất giống EFS: cũng là file system storage được quản lý, do Amazon cung cấp. Khác biệt then chốt: EFS chỉ làm việc với Linux. Có máy chạy Windows thì không dùng được EFS. Thay vào đó dùng FSx, service này cho phép dùng file system storage cho operating system Windows, cùng nhiều operating system khác.

Lợi ích của một managed file system storage​

Với một service file system storage được quản lý như FSx thì không còn phải lo:

  • Provision file server hoặc storage volume.
  • Replicate dữ liệu, Amazon sẽ làm.
  • Patch file server.
  • Xử lý các vấn đề hardware.
  • Thực hiện backup bằng tay.

Toàn bộ các việc này do Amazon làm, đúng như Amazon làm với EFS. Đây là managed service, mục tiêu là đơn giản hóa việc có file system storage trên cloud mà không phải tự provision và tự quản một server.

Feature và lợi ích của FSx​

  • Storage: cho một chỗ để lưu file, giống như dùng ổ cứng của máy tính để lưu tài liệu, ảnh và video.
  • Managed: AWS lo toàn bộ phần kỹ thuật, nên không phải lo dựng server hoặc xử lý các hệ thống storage phức tạp.
  • Scalable: tăng hoặc giảm storage dễ dàng theo nhu cầu, giống như thêm kệ vào tủ tài liệu khi có thêm tài liệu.
  • Shared access: FSx cho phép nhiều người hoặc nhiều máy truy cập cùng các file tại cùng thời điểm, rất phù hợp cho công việc cộng tác.
  • Backup: cung cấp các lựa chọn backup tự động để không mất file khi có sự cố.

Nhìn chung FSx đơn giản hóa việc dựng và quản lý file storage trên cloud, dù là workload chạy trên nền Windows hay cần file storage high-performance cho các tác vụ compute-intensive.

Bốn flavor của FSx​

FSx có bốn flavor, tùy theo nhu cầu của workload và operating system đang dùng.

Amazon FSx for Windows File Server​

File system loại này được thiết kế tương thích hoàn toàn với Windows File Server. Nó dựa trên operating system Windows Server và cung cấp các feature quen thuộc với người dùng và administrator Windows.

  • Hỗ trợ protocol SMB, protocol được dùng phổ biến trong môi trường Windows để chia sẻ và truy cập file.
  • Tích hợp dễ dàng với Microsoft Active Directory.
  • Hỗ trợ data deduplication.
  • Đặt được quota.

Amazon FSx for Lustre​

File system loại này được tối ưu cho high-performance parallel file processing. Nó thường được dùng trong các tình huống như scientific computing, machine learning và data analytics.

  • Cung cấp truy cập dữ liệu low-latency, high-throughput, phù hợp cho các workload cần xử lý dữ liệu cường độ cao.
  • Được xây trên Lustre file system, một lựa chọn phổ biến cho high-performance computing và các application data-intensive.
  • Tích hợp trơn tru với các service AWS khác như Amazon S3, AWS DataSync và AWS Batch, phục vụ các workflow xử lý và lưu trữ dữ liệu.
  • Scale được capacity và throughput của file system theo nhu cầu của workload.

Amazon FSx for ONTAP​

Điểm làm loại này khác biệt: nó là file system xây trên ONTAP file system của NetApp.

  • Cung cấp storage high-performance truy cập được từ nhiều operating system khác nhau: Linux, Windows và macOS.
  • Truy cập qua nhiều protocol khác nhau: NFS, SMB và iSCSI.
  • Scale file system lên hoặc xuống theo nhu cầu của workload.
  • Thực hiện được nhiều feature như snapshot, clone, replication và nhiều thứ khác.

Amazon FSx for OpenZFS​

Đây là service file storage fully managed chạy trên OpenZFS file system.

  • Xây trên OpenZFS file system mã nguồn mở.
  • Hỗ trợ truy cập từ Linux, Windows và macOS qua NFS.
  • Tận dụng các khả năng mạnh của OpenZFS, gồm data compression, snapshot và data cloning.
  • Có sẵn các feature data protection và security.

Deployment option​

FlavorSingle-AZMulti-AZ
FSx for Windows File Servercócó
FSx for ONTAPcócó
FSx for OpenZFScócó
FSx for Lustrecókhông, chỉ single-AZ

Bảng so sánh đầy đủ các flavor trong tài liệu của AWS cho biết: từng flavor hỗ trợ operating system nào (NetApp hỗ trợ Windows, Linux, macOS; Lustre chỉ hỗ trợ Linux), dùng được protocol nào để nói chuyện với nó, các mức latency, max throughput, và max file system size. Bảng đó cho ý niệm tốt về phiên bản FSx nào phù hợp nhất cho workload cụ thể.

Tóm tắt mục này​

  • Amazon FSx là service fully managed cung cấp file storage high-performance cho một phổ rộng workload.
  • Amazon FSx có bốn flavor: FSx for Windows, FSx for Lustre, FSx for ONTAP, FSx for OpenZFS.
  • Amazon FSx for Windows cung cấp một Windows file server fully managed, dựa trên protocol SMB và tích hợp với Windows Active Directory để authentication.
  • Amazon FSx for Lustre được tối ưu cho high performance và parallel file processing, rất phù hợp cho scientific computing và machine learning. Nó dựa trên Lustre file system.
  • Amazon FSx for ONTAP được xây trên ONTAP file system của NetApp và dùng các protocol NFS, SMB và iSCSI.
  • Amazon FSx for OpenZFS được xây trên OpenZFS file system mã nguồn mở, và truy cập được từ các compute instance Linux, Windows và macOS bằng protocol NFS.

9. S3 là gì​

Định nghĩa​

S3 là viết tắt của Simple Storage Service. Có ba chữ S, nên tên là S3.

S3 là service object storage của Amazon, cung cấp mức scalability, data availability, security và performance dẫn đầu ngành.

Nói cho đơn giản thì nó chẳng là gì khác ngoài một chỗ để lưu file. Hình dung nó giống Dropbox hoặc Google Drive, nhưng do Amazon vận hành.

💡 Hình dung: S3 giống một kho gửi đồ khổng lồ. Mỗi lần gửi thì nhận một mã, và muốn lấy lại thì đưa mã ra. Không mở được một thùng ra để sửa đúng một trang giấy bên trong rồi đóng lại, thao tác là lấy cả thùng ra hoặc gửi cả thùng mới vào. Đó chính là ý nghĩa của object storage: đơn vị làm việc là cả object.

Vì là phần của hệ sinh thái AWS, nó tích hợp tốt với mọi service khác mà AWS cung cấp, ví dụ EC2, Lambda, và quan trọng nhất là có sẵn IAM. Nghĩa là đã có ngay một công cụ rất mạnh để siết chặt ai có quyền truy cập file, ai mở được, ai sửa và xóa được. Tất cả tích hợp gọn với IAM policy và role.

Ngoài ra, giống mọi service khác, S3 truy cập được qua console, CLI, SDK và REST API.

Object storage khác gì các loại khác​

S3 là một loại storage cụ thể: object-based storage. Loại này khác NFS và khác block-based storage.

Điểm then chốt của object-based storage: nó được dùng khi một hệ thống cần truy cập toàn bộ một object hoặc toàn bộ một file.

Khác biệt với NFS, tức file-based storage: không dùng S3 làm nguồn NFS được, bởi vì trong S3 không có file system, không có directory, nó chỉ là một hệ thống phẳng lưu các object. Cần NFS thì dùng offering của Amazon dành cho việc đó, là EFS.

Ngoài ra không mount được S3 bucket vào một server. Nên không dùng nó như block-based storage truyền thống. Cần block-based storage thì dùng EBS.

Nhắc lại cho rõ: S3 thuần là object-based storage, không dùng được trong môi trường NFS, và không dùng được cho những việc vốn cần block-based storage.

Use case thường gặp​

  • Lưu log file của application.
  • Lưu media: ảnh, video, audio mà application hoặc web app dùng.
  • Lưu artifact sinh ra từ CI/CD pipeline.

Còn rất nhiều cơ hội dùng S3 khác không thể kể hết. Trong thực tế có rất nhiều use case cho nó khi triển khai application.

Ví dụ thực tế: S3 trong một website​

Khi có một website thì có vài thành phần tham gia.

Thành phần thứ nhất là một web server nằm đâu đó trong một data center, chứa toàn bộ file liên quan tới website. Có nhiều loại file, nhưng chủ yếu là một file HTML: mỗi lần truy cập một website trên browser thì thực chất là đang gửi request tới một web server để lấy file HTML, rồi render nó ra màn hình. Ngoài HTML còn có các file khác như CSS và JavaScript. Trên hết, web server còn lưu toàn bộ media của website: ảnh, nhạc, audio, video mà website cần dùng.

Luồng của một website truyền thống:

  1. Gửi request tới website, web server trả về HTML của website, chứa toàn bộ cấu trúc.
  2. File HTML có link tới toàn bộ ảnh và video mà nó cần render ra, và các file đó cũng nằm trên web server.
  3. Người dùng gửi tiếp request cho những ảnh và video đó tới web server.
  4. Web server trả về ảnh và video.

Vấn đề của mô hình này: hình dung đây là một website như YouTube hoặc Netflix, nơi có hàng gigabyte, thậm chí hàng petabyte video lưu trên server. Lưu video trên web server rất đắt. Và không chỉ có một web server: thực tế scale lên hàng nghìn web server rải khắp toàn cầu. Có hàng nghìn server thì mỗi server sẽ phải lưu từng video một trong toàn bộ database của Netflix hoặc YouTube. Việc đó không scale được. Đó chính là vấn đề của mô hình truyền thống: lưu hết file trên web server không phải phương án scale tốt nhất, và storage trên web server cũng rất đắt.

Khi đưa S3 vào bức tranh thì mô hình đổi:

  1. Vẫn có một web server, vẫn lưu các file HTML trên web server.
  2. Nhưng toàn bộ video và media được đẩy sang S3. Thay vì lưu các file đó trên một server nơi storage đắt đỏ, lưu chúng trên một service được thiết kế riêng cho storage và đã được tối ưu cho storage.
  3. Người dùng gửi request tới web server và nhận lại file HTML.
  4. File HTML chứa một URL trỏ về S3, tức vị trí của toàn bộ media có thể tải.
  5. Thay vì phải tới web server, người dùng gửi request tới S3, và S3 trả về toàn bộ video cần lấy.

Với phương án này, web server chỉ còn chịu trách nhiệm cho vài file web nhỏ, tức vài file HTML, CSS và JavaScript. Còn S3 gánh phần chứa, lưu, replicate và backup toàn bộ media, hàng terabyte dữ liệu, để web server không phải tự làm việc đó.

Thuật ngữ: bucket và object​

Bucket: file trong S3 được nhóm lại trong một bucket. Hình dung nó chẳng là gì khác ngoài một folder, một directory để chứa một loạt file có liên quan tới nhau.

Một account có nhiều hơn một bucket, và chia thế nào cũng được: mỗi application một bucket riêng, hoặc một application nhiều bucket, ví dụ một bucket cho log và một bucket cho media.

Object: object chỉ là các file được upload lên S3. Mỗi file là một object. Upload ba file PDF nghĩa là có ba object trong S3 bucket.

Một object có vài property đi kèm:

PropertyÝ nghĩa
keytên của file
valuedữ liệu thật của file
version IDcó khi bật versioning trên bucket
metadatavà vài thứ khác

Ví dụ: upload một bài hát MP3 tên mysong.mp3 thì mysong.mp3 là tên file, tức key. Còn chính file MP3, dữ liệu thật, là value.

Các property khác không cần quan tâm nhiều. Những thứ cần tập trung là key, value, và nếu bật versioning trên S3 bucket thì thêm version ID.

Cấu trúc file phẳng​

S3 bucket có cấu trúc file phẳng. Hình dung chỉ có đúng một directory duy nhất, và toàn bộ file nằm trong folder đó. Không có nested directory, đó không phải một lựa chọn. Chỉ một folder, mọi file upload vào đó, nên khi upload file thì chỉ thấy một loạt file trong một cấu trúc phẳng.

Tuy nhiên, mở AWS console và xem S3 bucket thì sẽ thấy thứ trông như một folder. Điều này dễ gây nhầm lẫn, ví dụ thấy một folder tên music.

Đây là một ảo giác. Khi tạo object trong S3 với cấu trúc đặt tên kiểu song one, song two, song three nhưng prepend tất cả bằng một tiền tố như music, thì S3 sẽ trình mọi file có cùng prefix đó trong một cấu trúc giống folder. Vì tất cả đều mang /music nên S3 đặt chúng vào một folder tên music.

Trên UI thì nó trông như một folder, nhưng thực tế nó chỉ là các file với tên /music/song one, /music/song two và /music/song three.

Nhắc lại: luôn luôn là cấu trúc file phẳng. Chính tên của key quyết định S3 trình nó ra trong một cấu trúc giống folder như thế nào.

Durability và replication​

Khi upload một file lên S3 thì có vài việc xảy ra bên dưới mà người dùng không thấy, và đây là chỗ AWS lo hết.

Thực tế thì mỗi khi upload một file, cuối cùng file đó phải được lưu trên một server nào đó. Trên một Availability Zone nào đó, trên một virtual machine hoặc server nào đó, file được lưu lại để lấy ra sau.

Vấn đề: mất server đó là mất file. Điểm hay của S3 nằm ở durability và high availability, nó được thiết kế để chịu được việc server chết mà không bao giờ mất file. Cách làm là replicate file lên nhiều server. Một server chết thì không sao, file đã có trên server khác.

Nhưng nếu toàn bộ server đó nằm trong một Availability Zone thì mất Availability Zone là mất file. Điểm hay của S3 là nó chịu được việc mất nhiều Availability Zone: nó replicate file qua nhiều server, qua nhiều Availability Zone. Availability Zone một sập thì vẫn còn Availability Zone hai và ba.

Đó là một trong các lợi ích lớn của S3: nó lo phần replicate qua nhiều Availability Zone và nhiều server để file được an toàn và chịu được việc mất một server hoặc mất một Availability Zone.

Bucket name phải unique toàn cầu​

Khi tạo một bucket thì phải đặt tên cho nó, và tên đó phải unique toàn cầu, trên mọi AWS account.

Lý do: tên bucket được nhúng vào một URL duy nhất gắn với bucket. Mỗi khi cần tham chiếu file trong bucket thì URL đó được dùng, và tên bucket nằm trong URL.

Giả sử một người dùng ở account một tạo một bucket tên my-demo-bucket-2026. Nếu một người dùng ở account khác cũng thử tạo một bucket tên my-demo-bucket-2026 thì phát sinh vấn đề, vì không thể có hai URL giống nhau trỏ về hai bucket khác nhau hoặc hai server khác nhau. Vì vậy việc đó bị cấm, và tên bucket phải unique trên mọi AWS account. Tên đã bị một người lấy thì người khác không lấy được nữa.

Các giới hạn của S3​

Hạng mụcGiới hạn
Số object trong S3không giới hạn, upload bao nhiêu dữ liệu cũng được, AWS tự scale
Kích cỡ tối đa của một file5 terabyte, không file đơn lẻ nào upload được quá mức này
Số bucket mỗi AWS accountmặc định 100, nâng được lên 1.000 bằng cách gửi service limit increase

Tóm tắt mục này​

  • S3 là service object storage của Amazon, cung cấp scalability, data availability, security và performance dẫn đầu ngành.
  • Use case thường gặp: lưu media file, log, trace, và host static website nếu muốn.
  • S3 là object storage, nghĩa là nó có cấu trúc file phẳng. Và không boot cũng không mount được từ S3, đây là điểm cần nhớ cho kỳ thi Solutions Architect.
  • Object chẳng là gì khác ngoài file. Chúng có key là tên object, và value là nội dung file, cộng thêm các metadata khác.
  • Bucket là container chứa object, hình dung như folder cha chứa toàn bộ object. Một bucket cho một application hoặc cho một mục đích cụ thể, một bucket khác cho việc khác.
  • Bucket name phải unique toàn cầu trên mọi AWS account, bởi vì mỗi bucket nhận một URL unique toàn cầu.
  • S3 xử lý được số object không giới hạn, nó tiếp tục scale lên vô hạn.
  • Kích cỡ tối đa của một object là 5 terabyte.
  • Multipart upload cho phép chia một object thành nhiều phần trước khi upload vào S3 bucket.

So sánh ba loại storage​

LoạiService của AWSMountBootĐơn vị truy cập
Block storageEBS, instance storecócóblock
File system storageEFS, FSxcókhôngfile
Object storageS3khôngkhôngcả object

Dòng cột Boot là điểm hay bị hỏi nhất trong kỳ thi: chỉ block storage boot được.

10. Thực hành: tạo bucket S3 đầu tiên​

Bước 1: mở trang S3 và hiểu global namespace​

Tìm service S3 trong ô search. Khi chưa có bucket nào thì trang hiện ra một chỗ để tạo bucket ngay. Nếu đã tạo bucket trước đó thì trang hiện danh sách toàn bộ bucket, và tạo bucket mới bằng nút ở góc.

Trước khi làm tiếp, cần để ý phần trên của trang: nó ghi Global và không chọn region nào. Lý do là S3 theo một global namespace. Nên không chọn region muốn làm việc trong đó, vì trang này liệt kê toàn bộ bucket trên mọi region. Thay vào đó, khi tạo bucket thì mới chỉ định region mà bucket đó gắn vào.

Bước 2: tạo bucket​

Bấm Create bucket. Phải đặt tên cho bucket, và tên này phải unique toàn cầu.

Chọn một tên kiểu demo thì gần như chắc chắn đã có người nào đó trên thế giới tạo bucket tên demo rồi. Nên khi bỏ qua mọi bước khác và bấm tạo bucket, console sẽ báo lỗi kiểu a bucket with the same name already exists, tức tên này đã bị lấy.

Vậy phải đặt một tên unique. Ở đây dùng my-demo-bucket-2026.

Muốn xem quy tắc đặt tên bucket thì bấm link ngay cạnh ô tên, nó mở trang tài liệu liệt kê tên nào được phép và tên nào không.

Sau đó chọn region, ở đây là us-east-1. Nếu đã có bucket sẵn và muốn copy toàn bộ setting của nó thì có một ô làm việc đó.

Còn vài setting nữa, không đi sâu vì mục này chỉ là phần giới thiệu:

  • Object Ownership: quyết định ai sở hữu object nào khi object được upload. Có mục riêng về chủ đề này ở phần sau của bộ tài liệu này.
  • Block public access settings for this bucket: theo mặc định bucket bị khóa kín. Chỉ người tạo bucket truy cập được. Không ai khác truy cập được: không ai trên internet, không public user, không anonymous user. Muốn mở ra thì bỏ chọn ô này, việc đó mở bucket ra cho public, hoặc cho phép cấu hình để public user truy cập được file. Ở đây để nguyên trạng thái chặn.
  • Bucket Versioning: có mục riêng về versioning ở phần sau.
  • Encryption: tương tự.
  • Advanced settings: có các thứ như Object Lock.

Bấm Create bucket. Bucket hiện ra với tên my-demo-bucket-2026, kèm region nó nằm trong và thời điểm được tạo.

Bước 3: các tab của một bucket​

Chọn bucket để vào trang chi tiết của nó.

Objects: khung này chứa toàn bộ file đã upload lên bucket. Hiện đang trống vì bucket mới tạo.

Properties: chứa thông tin rất cơ bản về cách bucket được cấu hình:

  • Region.
  • ARN, tức unique identifier của riêng bucket này.
  • Thời điểm bucket được tạo.
  • Trạng thái versioning, hiện là Disabled.
  • Tags, hiện không có.
  • Encryption, đang dùng loại encryption mặc định.
  • Các thông tin khác: server access logging, CloudTrail data events, event notifications, transfer acceleration, object lock, requester pays, và static website hosting.

Các mục này được cập nhật theo các thay đổi thực hiện trên bucket.

Permissions: tab này quản lý ai có quyền truy cập bucket và truy cập toàn bộ object trong bucket. Theo mặc định bucket bị khóa kín, nên chỉ người tạo truy cập được. Trong mục bucket policy thì khai được các rule và policy khác nhau để cho một số user truy cập một số file, và user khác truy cập file khác.

Metrics: xem toàn bộ CloudWatch metric liên quan tới bucket, ví dụ đang dùng bao nhiêu dữ liệu trong bucket, có bao nhiêu object đã upload lên.

Management: khai các lifecycle policy, các replication rule nếu muốn copy object từ bucket này sang bucket khác, các inventory configuration, và access point. Access point là feature nâng cao hơn, được bàn ở phần sau của bộ tài liệu này.

Bước 4: upload file đầu tiên​

Về trang Objects, bấm Upload. Có thể chọn Add files, Add folder, hoặc kéo thả thẳng vào, và đây là cách dùng ở đây.

Kéo một tấm ảnh vào. Console hiển thị kích cỡ file, ở đây khoảng 2,7 megabyte, và cho biết nó nhận ra đây là một image, cụ thể là JPEG image. Nó cũng cho biết file đang được upload vào bucket nào.

Tại đây đổi được vài chi tiết, hoặc bật versioning. Permissions sẽ theo permission mặc định của bucket. Còn Properties là chỗ có các storage class của S3: S3 cung cấp nhiều storage class khác nhau với mức truy cập dữ liệu, resiliency và chi phí khác nhau. Ở đây để mọi thứ mặc định.

Bấm Upload. Khi xong thì hiện dấu check màu xanh, nghĩa là file đã upload. Bấm Close. Trong mục Objects, bucket giờ có một file.

Bước 5: thông tin của một object​

Bấm vào file để xem thông tin:

  • Region của file, chính là region của bucket.
  • Kích cỡ, thời điểm last modified.
  • URI unique của object này. URI luôn là URI của bucket cộng với tên key của object, tức tên file.
  • ARN của file.
  • ETag.
  • Object URL, nơi truy cập được file.

Cuộn xuống còn các setting khác: object lock, storage class, server-side encryption, checksums, tags. Rất nhiều trong số các property này là theo từng object, không phải theo bucket. Nghĩa là mỗi object có cấu hình riêng khác nhau được.

Bước 6: Access Denied và vì sao​

Thử mở file bằng cách bấm vào object URL. Kết quả là Access Denied.

Vì sao lại bị từ chối khi đây là file của chính mình? Bởi vì bấm nút đó nghĩa là mở file từ góc nhìn của một public user, tức một user chưa authenticate, public, anonymous. Giống như bất kỳ ai ở bất kỳ đâu trên thế giới bấm vào URL đó và thử truy cập file, họ sẽ bị từ chối. Vì mặc định mọi thứ bị khóa kín.

Muốn mở file với tư cách user đang authenticate thì bấm nút Open. URL lúc này trông khác, nó nhúng toàn bộ thông tin authentication vào trong đó, và file hiện ra được.

Điểm cần nhớ: theo mặc định bucket và toàn bộ file trong đó bị khóa kín, chỉ chủ sở hữu truy cập được. Nhưng đổi cấu hình thì mở được ra cho public, và việc đó có thể cần thiết khi dựng một web app muốn lưu toàn bộ media của website trong S3 bucket.

Bước 7: folder chỉ là prefix​

Về bucket, lần này tạo một folder. Nhắc lại là S3 không thực sự có khái niệm folder, nó chỉ mô phỏng chức năng của folder. Bấm Create folder, đặt tên food.

Mở folder đó rồi upload vài file ảnh vào. Quy trình giống như trên, bấm Upload. Với ảnh high-resolution thì mất một lúc.

Về bucket thì thấy ảnh gốc ở ngoài, và một mục food có icon khác, được dán nhãn hẳn là folder, dù bản chất là một hệ thống file phẳng. Vào trong thì thấy toàn bộ ảnh.

Điểm quan trọng: đây không phải folder thật. Chọn một file trong đó, ví dụ burger.jpg, rồi xem URI hoặc ARN của nó: chỉ là tên bucket, cộng tên file gốc, và được prepend bởi tên folder. Nghĩa là mọi file đều nằm trong một directory duy nhất, chỉ là mọi file trong directory food đều được prepend bằng /food. S3 biết cách trình nó ra như một folder cho người dùng, nhưng ở dưới hệ thống thì tất cả nằm trong một directory.

Thử mở file này: bấm object URL thì bị khóa, vì đó là truy cập với tư cách user chưa authenticate. Bấm Open thì mở được với tư cách user đã authenticate.

Bước 8: xóa file​

Xóa một file đơn giản như upload. Về bucket, chọn file muốn xóa rồi bấm Delete. Console yêu cầu nhập chữ permanently delete để xác nhận chắc chắn một trăm phần trăm muốn xóa file này.

Vì bucket chưa bật versioning, nên xóa là mất vĩnh viễn. Bấm delete, console báo thành công, và file gốc đã biến mất.

Bước 9: tạo folder và move object​

Trong UI của S3 cũng tạo được folder và di chuyển chúng. Tạo một folder tên test, rồi di chuyển ảnh steak vào folder test.

Chọn ảnh steak, mở Actions rồi chọn Move. Tiếp theo phải điền đường dẫn đầy đủ muốn move tới.

Thực chất khi move sang một folder khác thì chỉ đang đặt cho object một cái tên khác. Nhắc lại là không có folder, chỉ đang đổi tên.

Cú pháp là s3:// rồi tên bucket, rồi phần prefix mới. Muốn move nó vào folder test nằm trong folder food thì key mới là /food/test:

s3://my-demo-bucket-2026/food/test

Không muốn tự gõ thì bấm Browse, chọn bucket, tìm đúng folder, console sẽ tự điền vào. Việc duy nhất đang xảy ra là đổi prefix của tên key thành food/test.

Bấm Move. Vào folder test thì thấy ảnh steak ở đó.

Bước 10: xóa bucket​

Về Buckets, chọn bucket rồi bấm Delete. Console báo lỗi: bucket không xóa được vì nó không rỗng. Nghĩa là chỉ xóa được bucket rỗng.

Bấm nút được gợi ý trong thông báo lỗi để làm rỗng bucket. Lại phải nhập chữ Permanently delete. Ở bước này chưa xóa bucket, đang xóa nội dung của bucket, vì bucket không rỗng thì không xóa được.

Bấm Empty. Bucket đã được làm rỗng, bấm Exit. Vào trong kiểm tra thì không còn gì. Giờ bucket đã rỗng nên Delete được. Console yêu cầu nhập tên bucket để xác nhận chắc chắn muốn xóa. Xong, bucket đã bị xóa.

11. S3 storage class​

Vì sao có storage class​

AWS cung cấp một dải storage class với các mức data access, resiliency và cost khác nhau.

Lý do: AWS hiểu rằng không phải mọi user truy cập dữ liệu theo cùng một pattern. Mỗi người truy cập dữ liệu khác nhau với tần suất khác nhau, lưu loại dữ liệu khác nhau, kích cỡ dữ liệu khác nhau. Nếu chỉ có một mức giá thì một số khách hàng sẽ phải trả nhiều tiền hơn mức thực sự cần, vì họ ít dùng dữ liệu S3 của họ.

Nên AWS cung cấp các storage class khác nhau, về bản chất là các scheme tính giá khác nhau dựa trên cách user truy cập dữ liệu.

S3 Standard​

Đây là storage class mặc định. Mỗi khi upload một file lên S3 mà không chỉ định storage class thì nó mặc định về S3 Standard.

  • Object được replicate qua ít nhất ba Availability Zone, nghĩa là chịu được hai Availability Zone sập đồng thời.
  • Durability mười một số chín (11 nines).
  • Tính tiền mỗi gigabyte mỗi tháng lưu trên S3.
  • Low latency: file khả dụng ngay, request là có trong vòng vài millisecond.
  • File làm public được. Dùng web app và muốn lưu toàn bộ media file trên S3 thì phải dùng một storage class cho phép làm file public.
  • Egress bị tính phí. Upload dữ liệu lên S3 là ingress và không bao giờ bị tính phí. Lấy dữ liệu ra khỏi S3 là egress và bị tính mỗi gigabyte egress.
  • Không có retrieval fee, không có minimum size, không có minimum duration.

S3 Standard-IA​

IA là viết tắt của infrequent access. Chỉ cần nhìn tên là đoán được loại dữ liệu phù hợp: dữ liệu không cần truy cập thường xuyên như dữ liệu dùng với S3 Standard.

Standard-IA rất giống S3 Standard, chỉ khác vài chi tiết:

  • Giống S3 Standard: object được replicate qua ít nhất ba Availability Zone, chịu được hai Availability Zone sập đồng thời.
  • Giống S3 Standard: durability mười một số chín.
  • Giống S3 Standard: tính tiền mỗi gigabyte mỗi tháng, nhưng khác biệt là giá rẻ hơn S3 Standard rất nhiều. Đó chính là ý tưởng của class này: dữ liệu ít được truy cập thì giá lưu rẻ hơn hẳn.
  • Giống S3 Standard: low latency, file khả dụng ngay trong vài millisecond, và file làm public được.

Phần khác biệt nằm ở các khoản phí:

  • Vẫn bị tính mỗi gigabyte egress, không tính ingress.
  • Nhưng mỗi lần lấy dữ liệu ra thì có thêm retrieval fee, một khoản phụ thu cộng lên trên phí egress mỗi gigabyte.
  • Minimum duration 30 ngày. Lưu một file rồi xóa sau năm ngày thì vẫn bị tính đủ 30 ngày.
  • Minimum size 128 kilobyte mỗi object. Upload một object một kilobyte thì vẫn bị tính 128 kilobyte.

Nghĩa là storage class này phù hợp cho dữ liệu không cần truy cập thường xuyên, cần được lưu ít nhất ba mươi ngày, và không phải loại object rất nhỏ. Nhưng về bản chất chỉ ba thứ đó cộng với giá rẻ hơn mỗi gigabyte mỗi tháng là khác với S3 Standard.

S3 One Zone-IA​

Tên đầy đủ là S3 One Zone-Infrequent Access.

  • Object không được replicate qua nhiều Availability Zone. Chúng chỉ nằm trong một Availability Zone duy nhất. Nhờ vậy chi phí mỗi gigabyte lưu rẻ hơn nhiều, rẻ hơn cả S3 Standard và S3 Standard-IA.
  • Giống hai class trên: file khả dụng ngay trong vài millisecond, và file làm public được.
  • Chỉ tính phí egress, không tính ingress.
  • Các khoản phí giống Standard-IA: có retrieval fee, minimum duration 30 ngày, và minimum size 128 kilobyte mỗi object. File rất nhỏ cũng bị tính như thể nó là ít nhất 128 kilobyte.

Class này dành cho dữ liệu ít được truy cập mà không cần chịu được một Availability Zone sập. Lưu ý: dữ liệu vẫn được replicate bên trong Availability Zone đó, nên không phải là dễ mất. Chỉ khi mất cả Availability Zone thì file không truy cập được.

Nên về bản chất class này gần như giống hệt S3 Standard-IA một trăm phần trăm. Khác biệt duy nhất là không replicate qua nhiều Availability Zone.

S3 Glacier Instant Retrieval​

Đây là phần của chuỗi Glacier, các storage class dành cho dữ liệu rất ít được truy cập. Hình dung kiểu dữ liệu archival.

  • Phương án storage chi phí thấp cho dữ liệu đã archive và rất ít được truy cập.
  • Điểm hay: data retrieval trong vài millisecond. Dù dành cho dữ liệu archive, dữ liệu vẫn truy cập được ngay khi cần.
  • Performance và durability giống hệt S3 Standard: replicate qua nhiều Availability Zone, cùng durability mười một số chín, và latency là ngay lập tức.
  • Tính phí mỗi gigabyte egress, không tính ingress.
  • Có retrieval fee.
  • Minimum duration 90 ngày: bị tính như thể file nằm trong đó tối thiểu 90 ngày.
  • Minimum size 128 kilobyte mỗi object.
  • Vẫn tính mỗi gigabyte mỗi tháng, nhưng vì dành cho dữ liệu archive nên mức đó thấp hơn nhiều so với các storage class khác.

Tóm lại: storage rất rẻ, chi phí retrieval cao, minimum duration dài hơn các class trước. Rất phù hợp cho dữ liệu không cần truy cập thường xuyên, nhưng khi cần thì cần ngay. Đó chính là lý do tên nó là Instant Retrieval.

S3 Glacier Flexible Retrieval​

Cũng thuộc chuỗi Glacier, nên thường là dữ liệu không cần truy cập thường xuyên, kiểu archival, dù về mặt kỹ thuật thì không nhất thiết.

Điểm làm class này khác các class trước: đây là storage class đầu tiên mà object không khả dụng ngay. Request một object thì không lấy lại được ngay trong vài millisecond. Hình dung các object này đang ngủ, và phải đánh thức chúng từ một trạng thái lạnh.

Và vì không khả dụng ngay, chúng không làm public được.

Về phí:

  • Tính mỗi gigabyte mỗi tháng, mức thấp hơn S3 Standard.
  • Khi lấy dữ liệu ra thì có phí egress mỗi gigabyte, cộng vài khoản khác giống S3 Glacier Instant Retrieval: retrieval fee, minimum duration 90 ngày, và minimum size 40 kilobyte mỗi object.

Retrieval fee thay đổi theo mức độ nhanh của việc lấy dữ liệu. Đó là lý do tên nó là Flexible Retrieval. Có ba lựa chọn:

Lựa chọnThời gian lấy dữ liệu
Expedited1 tới 5 phút
Standard3 tới 5 giờ
Bulk5 tới 12 giờ

Càng muốn dữ liệu nhanh thì retrieval fee càng cao.

Khi lấy object ra thì S3 tạm thời lưu object đó trong class S3 Standard-IA, và việc này chỉ là tạm thời trong lúc lấy object.

S3 Glacier Deep Archive​

Đây là storage class rẻ nhất. Giống S3 Glacier Flexible Retrieval, file không khả dụng ngay: phải coi chúng là đang ngủ và phải đánh thức. Và vì không truy cập được ngay, chúng cũng không làm public được.

  • Tính mỗi gigabyte mỗi tháng, mức rẻ nhất trong tất cả, và các khoản phí cũng rẻ nhất.
  • Lấy file ra thì có phí egress mỗi gigabyte, không tính ingress, và có retrieval fee.
  • Minimum duration 180 ngày.
  • Minimum size 40 kilobyte mỗi object.

Về lấy dữ liệu thì có hai lựa chọn:

Lựa chọnThời gian lấy dữ liệu
Standardtrong vòng 12 giờ
Bulktrong vòng 48 giờ

Lấy object càng nhanh thì phí càng cao, nên tùy mức cần gấp. Không cần gấp thì chọn phương án rẻ hơn là Bulk.

Và giống S3 Glacier Flexible Retrieval, dữ liệu đang được lấy ra sẽ được lưu tạm trong class S3 Standard-IA.

S3 Intelligent-Tiering​

Storage class cuối cùng. Khi không thực sự biết storage class nào lý tưởng nhất cho object của mình thì dùng S3 Intelligent-Tiering, class này tự động giảm chi phí storage bằng cách chuyển dữ liệu một cách thông minh sang access tier tiết kiệm nhất.

Nhờ vậy nó gỡ bỏ gánh nặng phải tự chạy toàn bộ phép tính để tìm ra phương án tối ưu nhất.

Về chi phí: ngoài chi phí của chính storage class mà nó chuyển object sang, còn phải trả thêm một khoản monitoring và automation, tính theo mỗi một nghìn object.

Bảng so sánh các storage class​

Storage classSố AZKhả dụng ngayLàm public đượcRetrieval feeMinimum durationMinimum size
S3 Standardtừ 3cócókhôngkhôngkhông
S3 Standard-IAtừ 3cócócó30 ngày128 KB
S3 One Zone-IA1cócócó30 ngày128 KB
S3 Glacier Instant Retrievalnhiềucócócó90 ngày128 KB
S3 Glacier Flexible Retrievalnhiềukhôngkhôngcó90 ngày40 KB
S3 Glacier Deep Archivenhiềukhôngkhôngcó180 ngày40 KB
S3 Intelligent-Tieringtheo tier đíchtheo tier đíchtheo tier đíchtheo tier đíchtheo tier đíchtheo tier đích, cộng phí monitoring và automation mỗi 1.000 object

Cây quyết định chọn storage class​

Khi mới học thì dễ nhầm lẫn class nào là class nào, nên dưới đây là trình tự quyết định.

Câu hỏi thứ nhất: có cần truy cập object ngay lập tức không, tức khi cần object thì có cần nó trong vài millisecond không.

Nếu CÓ cần ngay, hỏi tiếp: truy cập thường xuyên tới mức nào.

  • Truy cập thường xuyên, liên tục: dùng S3 Standard.
  • Truy cập không thường xuyên, hỏi tiếp: có cần replicate qua nhiều Availability Zone không.
    • Có: S3 Standard-Infrequent Access.
    • Không: S3 One Zone-IA.
  • Rất ít khi dùng dữ liệu: S3 Glacier Instant Retrieval. Tức gần như không bao giờ cần dữ liệu, nhưng khi cần thì cần ngay.

Nếu KHÔNG cần ngay, hỏi tiếp: cần nó thường xuyên tới mức nào.

  • Gần như không bao giờ cần: S3 Glacier Deep Archive, phương án rẻ nhất.
  • Rất ít khi, thỉnh thoảng mới cần: S3 Glacier Flexible Retrieval. Đắt hơn S3 Glacier Deep Archive một chút, nhưng vẫn rẻ hơn rất nhiều so với toàn bộ các phương án còn lại.

Tóm tắt mục này​

  • Storage class cung cấp các mức data access, resiliency và cost khác nhau khi lưu và lấy object trong một S3 bucket.
  • Chọn đúng class là quan trọng, để không bị tính quá nhiều tiền so với pattern truy cập dữ liệu thực tế.
  • Để đặt storage class trên một object cụ thể, cách làm là upload object và đặt request header x-amz-storage-class để chỉ định storage class mà object sẽ được lưu vào khi upload lên S3.

12. Thực hành: đặt storage class cho object​

Phần này làm hai việc: đặt storage class lúc upload một file lên S3, và sửa storage class trên một file đã có sẵn trong S3.

Bước 1: tạo bucket​

Tạo nhanh một bucket, đặt tên storage-class-demo-2026, chữ sc trong tên là viết tắt của storage class. Mọi setting còn lại để mặc định.

Bước 2: đặt storage class lúc upload​

Khi bucket đã tạo xong, bấm Upload rồi chọn một file bất kỳ.

Trong mục Properties chính là chỗ đặt storage class. Theo mặc định nó luôn được đặt là S3 Standard.

Lần này chọn One Zone-Infrequent Access, rồi bấm Upload. Đóng thông báo.

Giờ file đã nằm trong bucket, và ở cột Storage class nó hiển thị One Zone-Infrequent Access.

Bước 3: sửa storage class của file đã có​

Cần đổi storage class sau khi upload thì vào Properties của object, tìm mục Storage Class rồi sửa.

Muốn đổi file này thành S3 Standard thì chọn giá trị đó, và storage class của nó trở thành S3 Standard.

Kết luận của phần thực hành này​

  • Storage class được đặt lúc upload file.
  • Cần đổi về sau thì vào mục Properties của chính object đó và đổi storage class.

13. Versioning trên S3​

Hành vi khi versioning bị tắt​

Toàn bộ các phần làm việc với S3 ở trên đều chưa bật versioning. Cần thấy rõ hành vi khi versioning bị tắt để hiểu vì sao versioning được tạo ra.

Giả sử có một S3 bucket với năm file tên file one, file two, file three, file four, file five.

Trường hợp một: xóa. Xóa file one thì file đó mất vĩnh viễn, không bao giờ lấy lại được. Mà lấy lại được file luôn là điều tốt, vì người dùng có thể mắc lỗi và xóa nhầm.

Trường hợp hai: ghi đè. Upload một file mới tên file5.txt lên bucket, trong khi bucket đã có một file tên file5.txt. Khi upload một object có cùng key với một object đã tồn tại trong S3, nó sẽ thay thế version cũ. Nghĩa là version trước đó đã bị xóa vĩnh viễn và bị thay bằng version mới.

Vậy nếu vô tình upload các file có tên đã tồn tại trong S3 thì có thể ghi đè lên các object đang cần.

Đó chính là lý do versioning được tạo ra: để xử lý đúng các tình huống này, để khi mắc lỗi, khi xóa nhầm object, hoặc khi vô tình thay thế object, thì vẫn lấy lại được các version cũ.

Versioning được bật ở mức bucket​

Versioning được bật trên bucket, không phải trên từng object. Không bật versioning cho một object riêng lẻ. Nó được áp toàn cục trên chính bucket, nên áp cho mọi object trong bucket. Không có cách nào nói chỉ bật versioning cho vài object.

Bucket ở một trong ba trạng thái:

Trạng tháiÝ nghĩa
Unversionedversioning bị tắt, đây là trạng thái mặc định
Versioning enabledversioning đang bật
Versioning suspendedversioning bị tạm ngưng

Bucket khởi đầu ở trạng thái unversioned, tức versioning bị tắt. Từ đó bật versioning lên thì bucket ở trạng thái versioning-enabled.

Điểm quan trọng: một khi đã bật versioning thì không tắt được nữa. Việc duy nhất làm được là suspend versioning, và suspend không giống với tắt hẳn versioning. Nó chỉ tạm ngưng. Và sau khi suspend thì luôn bật lại được.

Nói lại cho rõ: đã bật versioning thì không bao giờ tắt được, chỉ suspend được.

Cơ chế bên dưới​

Khi upload một object trong lúc versioning đang bật, S3 gán cho nó một version ID. Ví dụ version ID là 1. Lưu ý các ID thật là một chuỗi unique rất dài, con số 1 ở đây chỉ để minh họa cho dễ hiểu.

Khi upload một file hoặc object mới với đúng cùng một key, thay vì thay thế object cũ, nó được upload thành một version mới, tức version ID 2. Làm lần nữa thì version tiếp theo có version ID 3.

Version mới nhất của một object được gọi là latest version hoặc current version. Trong ví dụ trên, version ID 3 là latest version, và đó là version mà người dùng thấy. Khi chỉ yêu cầu file1.txt mà không chỉ định version cụ thể thì nhận được latest version, tức version ba.

Trong S3 console thì nó hiện ra như sau: mỗi version đã upload cho file1.txt có một version ID khác nhau. File cha hiển thị ở trên chính là latest version hay current version. Khi yêu cầu file one thì nhận được version này, nhưng toàn bộ các version trước vẫn được lưu và nhìn thấy ở dưới. Thứ tự upload cũng đọc được: version đầu tiên upload lúc 10:47, version tiếp theo lúc 10:48.00, và version gần nhất lúc 10:48.25.

Khi versioning bị tắt thì property version ID của mỗi object được đặt là null.

Delete marker​

Khi xóa một object mà không chỉ định version ID, một version đặc biệt của object đó gọi là delete marker sẽ được thêm vào.

Delete marker về mặt kỹ thuật là một version mới của object, nhưng nó không xóa gì cả. Nó chỉ làm cho mọi thứ trông như các file đã bị xóa. Marker đó che toàn bộ các version trước của object.

Muốn undelete một object thì chỉ cần xóa chính cái delete marker đó, và delete marker xóa được như mọi object khác. Vào S3 console, xóa object đó, và object đã được undelete. Version nào là mới nhất sẽ trở thành latest version.

Xóa một version cụ thể​

Khi chỉ định một version ID cụ thể lúc xóa một object, ví dụ thay vì nói xóa file1.txt thì nói xóa file1.txt version ID 2, thì việc đó xóa vĩnh viễn object đó, hay chính xác hơn là xóa vĩnh viễn version đó. Sau đó version nào mới nhất sẽ trở thành current version hay latest version.

Pricing khi bật versioning​

Điều duy nhất cần biết: bị tính tiền cho toàn bộ các version của một object đang được lưu trong bucket, toàn bộ, không trừ version nào.

Ví dụ: có file1.txt với hai version, version một nặng 10 gigabyte và version hai nặng 15 gigabyte, thì bị tính 25 gigabyte.

Nên nếu lưu rất nhiều version khác nhau của các file rất lớn thì bị tính tiền cho toàn bộ các file đó.

Hành vi khi suspend versioning​

Khi suspend versioning thì toàn bộ các object cũ cùng toàn bộ version của chúng vẫn còn. Hệ thống không vào xóa các version cũ và chỉ giữ version mới nhất. Nó giữ nguyên toàn bộ object và toàn bộ version của chúng.

Nhưng từ thời điểm đó về sau, khi upload một object mới, nó được gán version ID null. Về bản chất nó hoạt động như thể versioning đã bị tắt với mọi object mới.

Diễn biến cụ thể: upload một file mới tên file1.txt thì nó được gán version ID null, giống như mọi file mới. Rồi upload một version mới hơn của file1.txt thì nó cũng có version ID null và nó thay thế cái trước. Nên từ thời điểm đó nó hoạt động đúng như khi versioning bị tắt.

Nó chỉ không quay lại quá khứ để xóa toàn bộ các version cũ. Muốn dọn các version cũ đó thì phải tự tay xóa.

MFA delete​

Feature cuối cùng của versioning là MFA delete. Nó liên quan tới versioning, và cái knob của nó nằm trong mục cấu hình versioning.

Tác dụng: để thực hiện bất kỳ thay đổi nào lên trạng thái versioning của một bucket thì phải làm multi-factor authentication. Đây là một lớp an toàn bổ sung, để trạng thái versioning không bị đổi do vô tình. Ngoài ra còn cần multi-factor authentication để xóa các version.

Và feature này chỉ bật được bằng CLI.

Tóm tắt mục này​

  • Versioning là feature cho phép preserve, retrieve và restore mọi version của một object được lưu trong bucket.
  • Versioning mặc định bị tắt trên bucket, phải bật tường minh nếu muốn có chức năng đó.
  • Versioning phải được bật ở mức bucket. Không bật versioning cho từng object riêng lẻ trong một bucket, nó được bật toàn cục trên bucket và áp cho mọi object trong bucket.
  • Bucket có ba trạng thái versioning: unversioned, versioning enabled, versioning suspended.
  • Một khi versioning đã bật trên một bucket thì không trở về trạng thái unversioned được. Chỉ đưa về trạng thái suspended được.
  • Ở trạng thái suspended, các version cũ của một object vẫn còn, nhưng không version mới nào được tạo.
  • Bị tính tiền cho từng version của một object. Ví dụ có một object nặng 5 gigabyte, và nó có năm version khác nữa mỗi version 5 gigabyte, thì phải trả cho 5 gigabyte cộng 5 gigabyte cho từng version còn lại, tổng cộng là 30 gigabyte.
  • Multi-factor authentication cấu hình được để bảo vệ trạng thái versioning của một bucket.

14. Thực hành: versioning​

Phần này bắt đầu với versioning bị tắt để thấy hành vi, sau đó bật versioning lên để thấy hành vi đổi như thế nào.

Bước 1: tạo bucket với versioning tắt​

Vào S3, bấm Create bucket, đặt tên versioning demo. Mọi setting khác để mặc định, và riêng Bucket Versioning thì bảo đảm đang đặt là Disabled.

Bước 2: upload file khi versioning tắt​

Chuẩn bị một file text giả tên file1.txt có nội dung this is version one. Cách đánh dấu này giúp theo dõi các version của file dễ hơn: mỗi lần sửa thì ghi this is version two, và tiếp tục như vậy, nên nhìn là thấy rõ.

Upload file này lên S3 bucket, mọi thứ để mặc định, bấm Upload rồi Close. Bấm vào file để mở nó ra thì thấy nội dung this is version one.

Bước 3: xóa file khi versioning tắt​

Chọn file rồi bấm delete. Console hỏi có chắc muốn permanently delete file này không. Chọn có.

Với versioning bị tắt, permanently delete một file là mất vĩnh viễn. File này không bao giờ lấy lại được, mất một trăm phần trăm. Nên phải rất cẩn thận khi versioning bị tắt: xóa một file là không bao giờ lấy lại được.

Bước 4: ghi đè file khi versioning tắt​

Upload lại file đó để nó về bucket, và xác nhận vẫn đang ở version một bằng cách mở ra: this is version one.

Giờ về file text, sửa nội dung thành this is version two, lưu lại. Về bucket và upload file này lên.

Diễn biến: trong S3 bucket đã có một file tên file1.txt, đó là key. Và đang upload một file khác với đúng cùng key đó. Sau khi upload xong thì đóng thông báo, mở file1.txt ra, nội dung là this is version two.

Nên khi trong S3 bucket có một file với một key nào đó, và upload một file mới cùng key, thì nó ghi đè file đó. File cũ mất. Version một ban đầu đã mất và không lấy lại được khi versioning bị tắt.

Bước 5: bật versioning​

Xóa file đó đi nếu muốn, vì hành vi khi xóa và khi ghi đè với versioning tắt đã rõ.

Vào Properties, tới mục Bucket Versioning, bấm Edit rồi bật versioning lên. Bấm Save changes. Trạng thái bucket versioning giờ là Enabled.

Bước 6: upload file khi versioning bật​

Về bucket, đổi tên nội dung file trở lại thành version một, copy file đó vào rồi upload.

Sau khi upload thì mọi thứ trông y như cũ. Nhưng giờ xuất hiện một nút Show versions. Theo mặc định console không hiện các version, nhưng khi tick ô đó thì toàn bộ thông tin versioning hiện ra.

Nó đã thêm một version ID. Đó là version đó của file. Và khi file được sửa thì các version mới sẽ được thêm vào kèm một ID unique mới.

Bước 7: tạo thêm các version​

Trước khi sửa, mở file để xác nhận đang là version một, nội dung this is version one. Đúng.

Sửa file thành version hai rồi upload lên S3 với cùng tên. Về bucket thì thoạt trông không thấy gì, vì phải tick Show versions. Tick vào thì thấy hai version:

  • Cái dưới là version một, cái cũ, hiển thị lồng vào trong.
  • Cái trên là version gần nhất, tức version hai.

Kiểm chứng: mở cái trên, nội dung là this is version two. Mở cái dưới, có thể đọc cả timestamp: cái dưới là timestamp cũ hơn, 18:19, còn version hai là 18:20. Mở cái cũ ra thì nội dung là this is version one.

Sửa file lần nữa thành version ba rồi upload lên bucket. Giờ có ba version, và latest version là cái trên cùng. Mở nó ra thì nội dung là version three. Mọi thứ hoạt động đúng như mong đợi.

Nên mỗi khi có một file với một key cụ thể trong S3 bucket, và upload một file mới với đúng cùng key đó, thì nó không ghi đè, nó lưu thành một version mới.

Bước 8: xóa file khi versioning bật​

Chọn file rồi bấm Delete. Để ý là lần này nó không yêu cầu nhập permanently delete, nó chỉ ghi delete. Lý do là hành vi khác đi khi versioning đang bật.

Xóa xong, về bucket, trông như file đã bị xóa thật. Nhưng file chưa bị xóa. Chuyện xảy ra là console không hiện các version vì chưa tick nút Show versions. Tick vào thì thấy đủ cả ba version của file.

Việc duy nhất xảy ra khi xóa file là nó thêm một delete marker. Đó như một version đặc biệt của object, nói với S3 rằng người dùng đã xóa nó, thực ra không muốn xóa, chỉ muốn bảo đảm người dùng không thấy nó nữa. Nên S3 không trình file đó ra.

Bước 9: undelete bằng cách xóa delete marker​

Muốn lấy lại file thì chỉ cần xóa delete marker. Delete marker hoạt động như mọi object S3 khác, nên chọn delete marker rồi bấm Delete, và permanently delete chính delete marker đó.

Sau khi nó bị xóa, về lại bucket thì file hiện ra cùng ba version, và latest version vẫn là version ba.

Bước 10: xóa một version cụ thể​

Xóa được cả một version cụ thể. Tick Show versions, chọn version hai, bấm Delete.

Điểm quan trọng cần nhớ: khi xóa một version cụ thể, tức khi nói với S3 rằng muốn xóa file1.txt ở đúng version hai, khi chỉ định một version cụ thể, thì nó xóa vĩnh viễn. Không có delete marker hay bất cứ thứ gì tương tự. Mỗi khi yêu cầu xóa một version cụ thể là mất version đó vĩnh viễn.

Nhập Permanently delete rồi xóa. Về lại thì chỉ còn hai version: cái gần nhất là version ba, và cái còn lại là version một, vì version hai đã bị xóa. Mở cái đó ra thì đúng là version một.

Bước 11: suspend versioning​

Như đã nêu ở mục lý thuyết, một khi versioning đã bật thì không tắt được, chỉ suspend được.

Về bucket, vào Properties, sửa mục Versioning. Trạng thái hiện tại là Enabled. Không có lựa chọn disable, chỉ có Suspend. Việc này nghĩa là từ thời điểm đó về sau sẽ không lưu thêm version nào trong bucket.

Chọn Suspend, tick ô xác nhận các cảnh báo, bấm Save changes.

Về lại object để xem đã xảy ra gì. Sau khi suspend versioning, toàn bộ version cũ của toàn bộ object đã có trước lúc suspend vẫn còn nguyên. Chúng vẫn còn version và version ID của chúng, đúng như mong đợi. Nhắc lại là không phải disable versioning, chỉ là suspend. Nên chỉ từ thời điểm này về sau thì mới ngừng theo dõi version.

Bước 12: hành vi của object mới sau khi suspend​

Tạo một version bốn của file rồi upload lên. Sau khi suspend versioning thì upload file này ra kết quả gì?

Upload, đóng thông báo. Dù versioning đang suspend thì vẫn thấy được các version cũ. Và điểm đáng chú ý: nó thêm một version mới với version ID là null.

Nên nó giữ toàn bộ version cũ, đúng như mong đợi, nhưng thêm một version mới tên là version ID null.

Ý nghĩa của việc này: mỗi lần thêm một object mới với đúng cùng key thì nó được thêm với version ID null. Và nếu sửa thêm một lần nữa rồi upload, nó sẽ xóa cái gần nhất và thay bằng cái mới nhất.

Mở cái gần nhất ra thì đúng là version bốn. Giờ sửa thành version năm rồi upload lên. Kết quả: vẫn chỉ có ba version, bởi vì đã có một object file1.txt với version là null. Vì versioning đang tắt, khi upload một file mới cùng tên thì nó cũng được gán version ID null. Nên nó cứ thay chỗ cho nhau.

Hiệu quả thực tế: nó giữ toàn bộ version cũ, nhưng từ đây không lưu version mới nào. Mở ra thì nội dung đúng là version năm.

Muốn dọn sạch các version cũ thì tự tay xóa chúng.

Bước 13: object mới với key mới sau khi suspend​

Tạo thêm một file nữa để thấy hành vi với object mới có key mới. Đặt tên file2.txt, nội dung this is version one, rồi upload.

Tick Show versions thì thấy file2 với version ID null.

Sửa nội dung thành version hai rồi upload lên. Vì versioning đang tắt hay suspend, nên chỉ có một file2.txt. Từ đây không lưu version mới nào, nó luôn lưu object mới với version ID null, và upload một object mới cùng key thì nó chỉ thay chỗ.

Bước 14: MFA delete​

Việc cuối cùng về versioning là MFA delete. Vào trang cấu hình versioning thì thấy có thể bật MFA delete. Khi bật, mỗi lần muốn thay đổi trạng thái versioning thì luôn phải làm multi-factor authentication delete.

Đặc điểm của feature này: nó chỉ bật được bằng AWS CLI hoặc SDK, không bật được qua console. Lý do thì không rõ, nhưng AWS đã thiết kế như vậy. Muốn dùng thì xem tài liệu để cấu hình. Sau đó, muốn bật lại versioning thì phải làm multi-factor authentication.

Bước 15: dọn dẹp​

Tick Show versions, xóa hết mọi thứ, rồi xóa bucket.

Nguồn tham khảo​

Nguồn gốc: Khóa "AWS Solutions Architect Associate Certification", chương "3. Services - Storage", nền tảng KodeKloud. Giảng viên: Sanjeev Thiagarajan. Nội dung bài viết được diễn giải lại bằng tiếng Việt và tổ chức theo cấu trúc riêng, không sao chép nguyên văn bài giảng.

Fact-check:

  • AMI Amazon Linux 2023 mặc định dùng EBS gp3, AMI Amazon Linux 2 mặc định dùng gp2, loại volume đổi được lúc launch — 2026-10-29, Amazon Linux 2023 User Guide
  • Free Tier mới từ 15/07/2025: free plan cấp 100 USD credit lúc sign-up, tối đa 100 USD nữa khi dùng service, hết hạn sau 6 tháng hoặc khi hết credit; account mở trước 15/07/2025 giữ chương trình cũ — 2026-10-29, AWS Free Tier now offers 200 USD in credits
  • Free Tier cũ: 750 giờ mỗi tháng cho t2.micro hoặc t3.micro tùy region, trong 12 tháng — 2026-10-29, Legacy AWS Free Tier FAQs
  • Từ 01/02/2024 AWS tính phí mọi public IPv4 address ở mức 0,005 USD mỗi giờ, kể cả address đang gắn vào resource đang chạy — 2026-10-29, New AWS public IPv4 address charge

Tên resource trong các phần thực hành (server one, demo volume, EBS-demo, my-demo-bucket-2026...) là tên ví dụ chung, đặt lại thế nào cũng được. Riêng tên bucket của S3 phải unique trên toàn cầu, nên tên trong bài chỉ dùng được sau khi đổi thành một tên chưa có người lấy.