Amazon S3 – Tính năng nâng cao

1. Chuyển object giữa các Storage Class

Ở chương S3 cơ bản bạn đã biết S3 có nhiều storage class (hạng lưu trữ) với mức giá và độ sẵn sàng khác nhau. Điều quan trọng tiếp theo là: một object không cần nằm mãi ở một hạng. Bạn có thể transition (chuyển) object từ hạng này sang hạng khác theo thời gian, vì dữ liệu thường “nguội dần” — file log của tháng này được đọc liên tục, còn file log của hai năm trước thì gần như không ai mở nữa.

Nguyên tắc chọn đích khi chuyển:

• Object ít được truy cập (infrequently accessed) → chuyển sang Standard IA.
• Object dạng archive (lưu trữ lâu dài) mà bạn không cần lấy ra nhanh → chuyển sang Glacier hoặc Glacier Deep Archive.

Các hạng có thể tham gia vào luồng chuyển đổi này gồm: Standard, Standard IA, Intelligent Tiering, One-Zone IA, Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive.

Bạn hoàn toàn có thể gọi API để chuyển từng object bằng tay, nhưng cách làm thực tế là tự động hóa bằng Lifecycle Rules — để S3 tự làm theo tuổi của object.

2. S3 Lifecycle Rules

Lifecycle Rules (quy tắc vòng đời) là cách bạn khai báo cho S3 biết: object trong bucket này, sau bao nhiêu ngày thì làm gì. Thay vì viết một cron job đi quét bucket rồi gọi API, bạn chỉ khai báo luật một lần và S3 thi hành.

Một Lifecycle Rule có hai loại hành động:

• Transition Actions – cấu hình để object chuyển sang một storage class khác.
  • Ví dụ: chuyển object sang Standard IA 60 ngày sau khi tạo.
  • Ví dụ: chuyển sang Glacier để archive sau 6 tháng.
• Expiration Actions – cấu hình để object hết hạn (bị xóa) sau một khoảng thời gian.
  • Ví dụ: file access log có thể đặt xóa sau 365 ngày.
  • Dùng để xóa các version cũ của file (nếu đã bật versioning).
  • Dùng để xóa các incomplete Multi-Part upload (phần upload dở dang không hoàn tất).

Rule không nhất thiết phải áp cho cả bucket. Bạn có thể giới hạn phạm vi:

• Theo prefix, ví dụ s3://mybucket/mp3/*.
• Theo tag của object, ví dụ Department: Finance.

Ví dụ thực tế — Scenario 1

Ứng dụng trên EC2 tạo thumbnail cho ảnh profile ngay sau khi ảnh được upload lên S3. Thumbnail có thể tạo lại dễ dàng và chỉ cần giữ 60 ngày. Ảnh gốc phải lấy được ngay lập tức trong 60 ngày đầu, sau đó người dùng có thể chờ tới 6 giờ. Thiết kế:

• Ảnh gốc để ở Standard, cấu hình lifecycle chuyển sang Glacier sau 60 ngày (vì chờ 6 giờ là chấp nhận được).
• Thumbnail để ở One-Zone IA (tạo lại được nên không cần nhiều AZ), cấu hình lifecycle expire (xóa) sau 60 ngày.

Ví dụ thực tế — Scenario 2

Quy định của công ty: object S3 đã xóa phải phục hồi được ngay trong 30 ngày (tình huống này rất ít xảy ra), sau đó và cho tới 365 ngày thì object đã xóa phải phục hồi được trong vòng 48 giờ. Thiết kế:

• Bật S3 Versioning để có các version của object — khi đó “object bị xóa” thực ra chỉ bị che bởi một delete marker và vẫn phục hồi được.
• Chuyển các noncurrent version (version không còn là bản hiện tại) sang Standard IA.
• Sau đó chuyển tiếp các noncurrent version sang Glacier Deep Archive.

3. S3 Analytics – Storage Class Analysis

Câu hỏi khó nhất khi viết Lifecycle Rule là: nên chuyển sau bao nhiêu ngày? Đặt 30 ngày thì có khi vẫn còn người đọc, đặt 180 ngày thì trả tiền Standard quá lâu. S3 Analytics – Storage Class Analysis trả lời câu hỏi đó bằng số liệu truy cập thật của bucket.

• Giúp bạn quyết định khi nào nên chuyển object sang storage class phù hợp.
• Đưa ra khuyến nghị cho Standard và Standard IA.
• KHÔNG hoạt động cho One-Zone IA hay Glacier.
• Báo cáo được cập nhật hằng ngày, dưới dạng file .csv với các cột kiểu Date, StorageClass, ObjectAge.
• Cần 24 đến 48 giờ mới bắt đầu thấy dữ liệu phân tích.

Đây là bước đầu tiên rất tốt để dựng Lifecycle Rules (hoặc để cải thiện các rule đang có) — bạn xem báo cáo rồi mới chọn mốc ngày, thay vì đoán.

4. S3 Requester Pays

Mặc định, chủ bucket (bucket owner) trả toàn bộ chi phí lưu trữ và chi phí truyền dữ liệu của bucket đó. Điều này rất bất lợi khi bạn muốn chia sẻ một tập dữ liệu lớn cho các AWS account khác tải về — họ tải càng nhiều, bạn càng trả nhiều tiền network.

Requester Pays đảo ngược phần chi phí đó:

• Với bucket bật Requester Pays, người gửi request (requester) — chứ không phải chủ bucket — trả chi phí request và chi phí download dữ liệu từ bucket.
• Chủ bucket vẫn trả chi phí storage.
• Rất hữu ích khi bạn muốn chia sẻ dataset lớn với các account khác.
• Requester phải được xác thực trong AWS — không thể là request ẩn danh (anonymous).

5. S3 Event Notifications

Nhiều kiến trúc cần phản ứng ngay khi có gì đó xảy ra trong bucket: ảnh vừa upload thì phải tạo thumbnail, file vừa xóa thì phải cập nhật database. S3 Event Notifications cho phép S3 tự đẩy sự kiện tới nơi xử lý mà bạn không phải đi hỏi (“poll”) bucket liên tục.

• Các loại event: S3:ObjectCreated, S3:ObjectRemoved, S3:ObjectRestore, S3:Replication…
• Có thể lọc theo tên object, ví dụ chỉ bắt các file *.jpg.
• Use case kinh điển: tạo thumbnail cho ảnh được upload lên S3.
• Có thể tạo bao nhiêu “S3 event” cũng được.
• Event thường được gửi trong vài giây, nhưng đôi khi có thể mất một phút hoặc lâu hơn.

Ba đích nhận trực tiếp là Lambda Function, SQS và SNS. Điểm cần chú ý về quyền: bạn không cấp quyền bằng IAM Role gắn cho S3, mà bằng resource policy của chính đích đến — Lambda Resource Policy, SNS Resource (Access) Policy, SQS Resource (Access) Policy — cho phép S3 được ghi vào đó.

S3 Event Notifications với Amazon EventBridge

Ngoài ba đích trên, bucket có thể gửi toàn bộ event sang Amazon EventBridge, rồi EventBridge dùng rules để phân phối tiếp. Cách này mở ra nhiều khả năng hơn:

• Lọc nâng cao bằng JSON rules (theo metadata, kích thước object, tên…).
• Nhiều đích đến — ví dụ Step Functions, Kinesis Data Streams / Firehose… tổng cộng hơn 18 dịch vụ AWS có thể làm destination.
• Các năng lực riêng của EventBridge: Archive, Replay Events, Reliable delivery (gửi tin cậy).

Lưu ý khi thi

Nhớ hai tầng: S3 gửi trực tiếp thì chỉ có Lambda / SQS / SNS; muốn lọc phức tạp, gửi nhiều đích, hoặc muốn archive/replay event thì đi qua EventBridge.

6. Hiệu năng cơ bản của S3

S3 tự động scale để chịu được tốc độ request cao, với độ trễ khoảng 100–200 ms. Giới hạn thông lượng của S3 được tính theo prefix, không phải theo bucket — đây là chi tiết rất hay bị hiểu sai.

• Ứng dụng của bạn đạt được ít nhất 3.500 request PUT/COPY/POST/DELETE mỗi giây, hoặc 5.500 request GET/HEAD mỗi giây, trên mỗi prefix trong một bucket.
• Không có giới hạn về số lượng prefix trong một bucket.

Prefix chính là phần đường dẫn nằm giữa tên bucket và tên file:

bucket/folder1/sub1/file  => prefix /folder1/sub1/
bucket/folder1/sub2/file  => prefix /folder1/sub2/
bucket/1/file             => prefix /1/
bucket/2/file             => prefix /2/

Nếu bạn chia đều lượng đọc ra cả bốn prefix trên, tổng thông lượng đạt được là 22.000 request/giây cho GET và HEAD (4 × 5.500).

Lưu ý khi thi

Khi đề bài nói “ứng dụng bị nghẽn ở S3, cần tăng số request/giây”, đáp án thường là phân bổ object ra nhiều prefix hơn, chứ không phải tạo thêm bucket.

7. Tối ưu hiệu năng upload và download

Multi-Part Upload

Thay vì đẩy một file khổng lồ trong một request duy nhất, Multi-Part upload chia file thành nhiều part và upload song song.

• Khuyến nghị dùng cho file lớn hơn 100 MB.
• Bắt buộc phải dùng cho file lớn hơn 5 GB.
• Giúp song song hóa việc upload, tức là tăng tốc truyền tải.

S3 Transfer Acceleration

Vấn đề khác: người upload ở Australia mà bucket nằm ở USA thì đường đi qua Internet công cộng rất chậm. S3 Transfer Acceleration giải quyết bằng cách cho file đi vào edge location gần nhất, rồi edge location chuyển tiếp dữ liệu tới bucket ở region đích qua mạng nội bộ của AWS (nhanh và ổn định hơn Internet công cộng).

• Tăng tốc độ truyền bằng cách gửi file tới một AWS edge location, nơi này forward dữ liệu tới S3 bucket ở region đích.
• Tương thích với Multi-Part upload — dùng được cả hai cùng lúc.

S3 Byte-Range Fetches

Với việc tải xuống, bạn có thể song song hóa các lệnh GET bằng cách yêu cầu từng khoảng byte (byte range) cụ thể của file.

• Song song hóa GET bằng cách yêu cầu các byte range khác nhau (Part 1, Part 2, … Part N) cùng lúc → tăng tốc download.
• Chịu lỗi tốt hơn: nếu một range lỗi, chỉ cần tải lại đúng range đó.
• Cũng dùng để lấy một phần dữ liệu thôi — ví dụ chỉ lấy header (XX byte đầu tiên) của file mà không tải toàn bộ.

Lưu ý khi thi

Ba kỹ thuật ba mục đích: Multi-Part upload = upload file lớn song song; Transfer Acceleration = rút ngắn đường mạng cho upload xuyên region; Byte-Range Fetches = tăng tốc (hoặc cắt bớt) download.

8. S3 Batch Operations

Khi cần tác động lên hàng triệu object đã có sẵn — ví dụ mã hóa lại toàn bộ object chưa được mã hóa — viết script tự chạy vòng lặp là việc rất dễ sai và rất khó theo dõi. S3 Batch Operations làm việc đó với một request duy nhất.

Các thao tác hàng loạt có thể thực hiện:

• Sửa metadata & properties của object.
• Copy object giữa các S3 bucket.
• Mã hóa các object chưa được mã hóa.
• Sửa ACL, tag.
• Restore object từ S3 Glacier.
• Gọi một Lambda function để thực hiện hành động tùy ý trên từng object.

Cách hoạt động: một job gồm ba phần — danh sách object, hành động cần làm, và các tham số tùy chọn. S3 Batch Operations lo phần vất vả còn lại: quản lý retry, theo dõi tiến độ, gửi thông báo khi hoàn tất, sinh báo cáo…

Để có danh sách object đầu vào, bạn có thể dùng S3 Inventory (sinh ra Objects List Report), rồi dùng Athena để query và lọc ra đúng tập object cần xử lý trước khi đưa vào job.

Ví dụ thực tế

Công ty kiểm tra và phát hiện một phần object trong bucket chưa được mã hóa. Quy trình: S3 Inventory sinh danh sách object → Athena lọc ra những object không có thuộc tính mã hóa → đưa danh sách đã lọc vào một S3 Batch Operations job với hành động “encrypt” → job tự chạy, tự retry và xuất báo cáo cuối cùng.

9. S3 Storage Lens

Lifecycle Rules và Analytics làm việc ở phạm vi một bucket. Khi bạn có hàng chục account và hàng trăm bucket trong một AWS Organization, bạn cần một góc nhìn tổng thể — đó là S3 Storage Lens.

• Hiểu, phân tích và tối ưu việc lưu trữ trên toàn bộ AWS Organization.
• Phát hiện bất thường (anomaly), chỉ ra chỗ tiết kiệm chi phí, và áp dụng best practice về bảo vệ dữ liệu trên toàn Organization — với 30 ngày metric về usage & activity.
• Tổng hợp (aggregate) dữ liệu theo Organization, theo account cụ thể, theo region, theo bucket, hoặc theo prefix.
• Có dashboard mặc định, hoặc bạn tự tạo dashboard riêng.
• Có thể cấu hình export metric hằng ngày ra một S3 bucket, định dạng CSV hoặc Parquet.

Default Dashboard

• Trực quan hóa các insight và xu hướng đã tổng hợp, cho cả metric miễn phí và metric nâng cao.
• Hiển thị dữ liệu Multi-Region và Multi-Account.
• Được Amazon S3 cấu hình sẵn.
• Không thể xóa, nhưng có thể disable.

Các nhóm metric

Nhóm metric	Ví dụ metric	Dùng để làm gì
Summary	StorageBytes, ObjectCount…	Tìm bucket/prefix tăng nhanh nhất, hoặc không còn được dùng
Cost-Optimization	NonCurrentVersionStorageBytes, IncompleteMultipartUploadStorageBytes…	Tìm bucket có multipart upload dở dang quá 7 ngày; tìm object nên chuyển xuống storage class rẻ hơn
Data-Protection	VersioningEnabledBucketCount, MFADeleteEnabledBucketCount, SSEKMSEnabledBucketCount, CrossRegionReplicationRuleCount…	Tìm bucket chưa tuân thủ best practice bảo vệ dữ liệu
Access-management	ObjectOwnershipBucketOwnerEnforcedBucketCount…	Xem các bucket đang dùng thiết lập S3 Object Ownership nào
Event	EventNotificationEnabledBucketCount	Xem bucket nào đã cấu hình S3 Event Notifications
Performance	TransferAccelerationEnabledBucketCount	Xem bucket nào đã bật S3 Transfer Acceleration
Activity	AllRequests, GetRequests, PutRequests, ListRequests, BytesDownloaded…	Hiểu storage đang được request như thế nào
Detailed Status Code	200OKStatusCount, 403ForbiddenErrorCount, 404NotFoundErrorCount…	Phân tích các HTTP status code trả về

Free vs. Paid

	Free Metrics	Advanced Metrics and Recommendations
Có sẵn	Tự động cho mọi khách hàng	Metric & tính năng trả phí thêm
Nội dung	Khoảng 28 usage metric	Advanced Metrics – Activity, Advanced Cost Optimization, Advanced Data Protection, Status Code
Tính năng thêm	—	CloudWatch Publishing (xem metric trong CloudWatch, không tính phí thêm); Prefix Aggregation (thu metric ở mức prefix)
Thời gian query được	14 ngày	15 tháng

Lưu ý khi thi

Phân biệt ba công cụ phân tích: S3 Analytics (Storage Class Analysis) = khuyến nghị chuyển hạng cho một bucket, chỉ cho Standard/Standard IA; S3 Inventory = danh sách object để xử lý tiếp; S3 Storage Lens = bức tranh toàn Organization về chi phí và bảo vệ dữ liệu.

Tóm tắt nhanh

Chủ đề	Phải nhớ
Lifecycle Rules	Transition (đổi storage class) + Expiration (xóa); áp theo prefix hoặc tag; xóa được version cũ và multipart upload dở dang
S3 Analytics	Khuyến nghị chuyển hạng, chỉ cho Standard / Standard IA; báo cáo hằng ngày; cần 24–48 giờ mới có dữ liệu
Requester Pays	Requester trả tiền request + download; chủ bucket vẫn trả storage; requester phải đã xác thực
Event Notifications	Đích trực tiếp: Lambda, SQS, SNS (cấp quyền bằng resource policy của đích); qua EventBridge để lọc JSON nâng cao, nhiều đích, archive/replay
Baseline performance	3.500 PUT/COPY/POST/DELETE và 5.500 GET/HEAD mỗi giây mỗi prefix; không giới hạn số prefix
Multi-Part upload	Khuyến nghị > 100 MB, bắt buộc > 5 GB
Transfer Acceleration	Đi qua edge location rồi vào region đích qua mạng AWS; kết hợp được với multi-part
Byte-Range Fetches	Song song hóa GET theo byte range, hoặc chỉ lấy phần đầu file
Batch Operations	Một request cho hàng loạt object; job = danh sách + hành động + tham số; lấy danh sách từ S3 Inventory, lọc bằng Athena
Storage Lens	Phân tích toàn Organization, 30 ngày metric, export CSV/Parquet; free = ~28 metric giữ 14 ngày, advanced giữ 15 tháng