Advanced Amazon S3
Chương này gom một loạt tính năng tên na ná nhau: Lifecycle, Analytics, Inventory, Batch Operations, Storage Lens, S3 Select, Byte-Range Fetch. Cái khó không phải là hiểu từng cái, mà là chọn đúng cái nào cho tình huống nào.
Lifecycle Rules & S3 Analytics
Lifecycle Rule là cách tự động hóa toàn bộ vòng đời dữ liệu — chuyển tầng và xóa — mà không cần ai can thiệp.
Hai loại hành động
| Loại | Làm gì | Ví dụ |
|---|---|---|
| Transition Actions | Chuyển object sang storage class khác | Standard → Standard-IA sau 60 ngày; → Glacier sau 6 tháng |
| Expiration Actions | Xóa object sau một khoảng thời gian | Xóa log sau 365 ngày · xóa phiên bản cũ · xóa phần multi-part upload dang dở |
1. "Xóa các phiên bản cũ để giảm chi phí" → Expiration Actions, không phải Transition.
2. "Tự động chuyển tầng object" → Lifecycle Rules, không phải Lambda hay CloudWatch Events.
3. "Dọn các phần multi-part upload dang dở do mạng lỗi" → cũng là Lifecycle Rule, không cần viết Lambda hay nhờ AWS Support.
Rule áp dụng được cho một prefix cụ thể (ví dụ s3://mybucket/mp3/*) hoặc cho object mang tag nhất định (ví dụ Department: Finance).
Hai kịch bản trong bài giảng
Yêu cầu: EC2 tạo thumbnail từ ảnh người dùng upload. Thumbnail tạo lại được dễ dàng và chỉ cần giữ 60 ngày. Ảnh gốc phải lấy được ngay trong 60 ngày đầu, sau đó chờ tới 6 giờ cũng chấp nhận.
Thiết kế: ảnh gốc để Standard, lifecycle chuyển sang Glacier sau 60 ngày. Thumbnail để One Zone-IA (vì tạo lại được), lifecycle expire sau 60 ngày.
Yêu cầu: object đã xóa phải khôi phục ngay lập tức trong 30 ngày, và trong vòng 48 giờ cho tới 365 ngày.
Thiết kế: bật Versioning (xóa chỉ tạo delete marker) → chuyển noncurrent version sang Standard-IA → sau đó chuyển tiếp sang Glacier Deep Archive (chế độ Bulk đúng 48 giờ).
S3 Analytics — Storage Class Analysis
Công cụ gợi ý nên chuyển object sang tầng khác sau bao nhiêu ngày. Đây là bước đầu tiên nên làm trước khi viết lifecycle rule.
| Đặc điểm | Chi tiết |
|---|---|
| Phạm vi phân tích | Chỉ cho Standard và Standard-IA — không áp dụng cho One Zone-IA hay Glacier |
| Tần suất | Báo cáo cập nhật hàng ngày |
| Thời gian có dữ liệu | 24–48 giờ mới bắt đầu thấy kết quả |
S3 Analytics gợi ý nên chuyển khi nào — nó không tự làm gì cả. Lifecycle Rule mới là thứ thực thi. Đề hỏi "làm sao biết số ngày tối ưu để chuyển tầng" → Analytics; "làm sao tự động chuyển" → Lifecycle.
S3 Event Notifications
Cho phép S3 báo cho hệ thống khác biết khi có chuyện xảy ra với object.
- Các sự kiện:
S3:ObjectCreated,S3:ObjectRemoved,S3:ObjectRestore,S3:Replication… - Lọc được theo tên object (ví dụ chỉ
*.jpg). - Tạo bao nhiêu sự kiện cũng được.
- Thường giao trong vài giây, đôi khi mất một phút hoặc lâu hơn.
Ba đích đến cổ điển
| Đích | Dùng khi |
|---|---|
| SNS | Phát tán thông báo cho nhiều bên nhận |
| SQS | Xếp hàng để xử lý dần, chịu tải cao |
| Lambda | Chạy code xử lý ngay lập tức |
Phải cấp quyền bằng resource-based policy ở phía đích — SNS Access Policy, SQS Access Policy, Lambda Resource Policy — để cho phép S3 gửi sự kiện tới. Không phải gắn IAM role cho S3.
Kết hợp với Amazon EventBridge
Mọi sự kiện S3 đều đẩy được sang EventBridge, và từ đó mở ra nhiều khả năng hơn hẳn:
- Gửi tới hơn 18 dịch vụ AWS làm đích (Step Functions, Kinesis Data Streams, Firehose…)
- Lọc nâng cao bằng quy tắc JSON — theo metadata, kích thước object, tên file…
- Gửi tới nhiều đích cùng lúc
- Có Archive, Replay Events và cơ chế giao tin tin cậy
Người dùng upload ảnh đại diện lên bucket. Event Notification lọc *.jpg và gọi Lambda tạo thumbnail ba kích cỡ rồi ghi lại vào bucket khác. Toàn bộ chuỗi này không có máy chủ nào chạy thường trực — chỉ tốn tiền khi thật sự có ảnh mới. Đây là ứng dụng kinh điển nhất của S3 Event Notifications và sẽ gặp lại ở phần serverless.
Biến thể chịu tải cao hơn: S3 → SQS → nhóm worker xử lý dần. Nếu có 10.000 ảnh upload cùng lúc, hàng đợi giữ lại và worker xử lý theo tốc độ của mình thay vì bị quá tải.
S3 Performance
Hiệu năng nền
S3 tự động co giãn theo lượng request, độ trễ khoảng 100–200 ms. Giới hạn quan trọng nhất tính theo prefix:
| Loại request | Số lượng mỗi giây, mỗi prefix |
|---|---|
| PUT / COPY / POST / DELETE | 3.500 |
| GET / HEAD | 5.500 |
Không giới hạn số prefix trong một bucket. Đây là mấu chốt: chia dữ liệu ra nhiều prefix là nhân được hiệu năng lên.
bucket/folder1/sub1/file → prefix = /folder1/sub1/
Trải đều request qua 4 prefix → 4 × 5.500 = 22.000 GET mỗi giâyBa kỹ thuật tăng tốc
| Kỹ thuật | Cơ chế | Dùng khi |
|---|---|---|
| Multi-Part Upload | Chia file thành nhiều phần, tải song song, ghép lại ở S3 | Khuyến nghị trên 100 MB, bắt buộc trên 5 GB |
| Transfer Acceleration | Tải lên edge location gần nhất, AWS chuyển tiếp qua mạng nội bộ tới bucket | Upload/download xuyên châu lục |
| Byte-Range Fetch | Yêu cầu một khoảng byte cụ thể của object | Tải song song nhiều phần, hoặc chỉ lấy phần đầu file |
Đề mô tả "file 10 GB, băng thông tốt nhưng kết nối không ổn định" → dùng cả hai: multi-part để phần nào lỗi thì chỉ tải lại phần đó (không phải cả file), transfer acceleration để đi qua mạng xương sống của AWS cho nhanh.
Cần đọc 250 byte đầu của 100.000 file để dựng index → Byte-Range Fetch, vì bạn muốn một khoảng byte theo vị trí.
S3 Select lọc theo hàng và cột của dữ liệu có cấu trúc (CSV, JSON) bằng câu SQL — không lấy được "250 byte đầu" của file bất kỳ. Đọc cả file rồi cắt 250 byte thì lãng phí 50 TB băng thông.
Một công ty truyền thông ở Việt Nam upload video 4K lên bucket đặt tại Mỹ. Upload trực tiếp mất hàng giờ và hay đứt giữa chừng. Bật Transfer Acceleration: dữ liệu đi vào edge location tại Hà Nội rồi chạy trên mạng riêng của AWS sang Mỹ — nhanh hơn đáng kể. Kết hợp multi-part upload: mạng rớt thì chỉ tải lại phần dở, không mất công cả file.
S3 Select & Glacier Select
Cho phép lọc dữ liệu ngay tại phía server bằng câu SQL đơn giản, thay vì tải cả file về rồi mới lọc.
- Lọc được theo hàng và cột của dữ liệu có cấu trúc (CSV, JSON, Parquet)
- Giảm lượng dữ liệu truyền qua mạng và giảm tải CPU phía client
- Nhanh hơn tới 400% và rẻ hơn tới 80%
File CSV 5 GB chứa log giao dịch, bạn chỉ cần các dòng có status = 'FAILED' và hai cột. Không có S3 Select thì phải tải cả 5 GB về máy rồi lọc. Với S3 Select, S3 lọc sẵn và chỉ trả về vài MB — nhanh hơn và rẻ hơn hẳn.
S3 Batch Operations
Thực hiện thao tác hàng loạt trên các object ĐÃ tồn tại chỉ bằng một yêu cầu duy nhất.
Làm được những gì
- Sửa metadata và thuộc tính của object
- Copy object giữa các bucket
- Mã hóa các object chưa được mã hóa
- Sửa ACL và tag
- Khôi phục object từ Glacier
- Gọi Lambda để chạy hành động tùy ý trên từng object
Một job gồm: danh sách object + hành động cần làm + tham số tùy chọn. S3 Batch Operations tự thử lại khi lỗi, theo dõi tiến độ, gửi thông báo khi xong và xuất báo cáo.
"Cần mã hóa lại toàn bộ file đang có trong bucket bằng KMS để đáp ứng yêu cầu tuân thủ, cách hiệu quả và tiết kiệm nhất" → S3 Batch Operations. Lifecycle Rules chỉ chuyển tầng và xóa chứ không mã hóa; Replication tạo bản sao chứ không sửa dữ liệu tại chỗ.
S3 Inventory tạo danh sách object → S3 Select lọc ra đúng những object cần xử lý → S3 Batch Operations thực thi hành động trên danh sách đó. Đề có thể mô tả cả chuỗi này.
S3 Storage Lens
Công cụ nhìn toàn cảnh: phân tích và tối ưu lưu trữ S3 trên toàn bộ AWS Organization — phát hiện bất thường, tìm chỗ lãng phí, kiểm tra việc tuân thủ thực hành bảo vệ dữ liệu.
- Gom dữ liệu theo tổ chức, tài khoản, region, bucket hoặc prefix.
- Có dashboard mặc định do AWS dựng sẵn — không xóa được nhưng tắt được; bạn cũng tự tạo dashboard riêng.
- Xuất metrics hàng ngày ra một bucket S3 dưới dạng CSV hoặc Parquet.
Các nhóm metrics
| Nhóm | Trả lời câu hỏi |
|---|---|
| Summary | Bucket nào đang phình nhanh nhất? |
| Cost-Optimization | Còn bao nhiêu phiên bản cũ và multi-part upload dang dở quá 7 ngày? |
| Data-Protection | Bucket nào chưa bật versioning, MFA Delete, mã hóa KMS, replication? |
| Access-Management | Cấu hình Object Ownership ra sao? |
| Event | Bucket nào đã bật Event Notifications? |
| Performance | Bucket nào đã bật Transfer Acceleration? |
| Activity | Lượng request, byte tải xuống ra sao? |
| Detailed Status Code | Bao nhiêu lỗi 403 Forbidden, bao nhiêu 200 OK? |
| Free Metrics | Advanced Metrics (trả phí) | |
|---|---|---|
| Phạm vi | Khoảng 28 usage metrics, có sẵn cho mọi khách hàng | Thêm Activity, Advanced Cost Optimization, Advanced Data Protection, Status Code |
| Lưu dữ liệu truy vấn | 14 ngày | 15 tháng |
| Khác | — | Đẩy metrics sang CloudWatch không tính thêm phí, gom metrics theo prefix |
Một tập đoàn có 40 tài khoản AWS và hàng nghìn bucket. Đội bảo mật cần trả lời câu hỏi "bucket nào chưa bật versioning và chưa mã hóa?" — kiểm tra tay là bất khả thi. Storage Lens với nhóm Data-Protection Metrics liệt kê ngay danh sách đó cho toàn bộ tổ chức trong một dashboard.
S3 Requester Pays
Bình thường chủ bucket trả toàn bộ chi phí lưu trữ và truyền dữ liệu. Với Requester Pays, người gửi yêu cầu là người trả tiền cho request và cho lượng dữ liệu tải xuống.
- Hữu ích khi bạn chia sẻ tập dữ liệu lớn cho các tài khoản khác.
- Chủ bucket vẫn trả tiền lưu trữ; bên yêu cầu trả tiền truyền dữ liệu.
- Người yêu cầu bắt buộc phải đăng nhập AWS — không dùng được với truy cập ẩn danh.
Một viện nghiên cứu công bố tập dữ liệu vệ tinh 200 TB cho cộng đồng. Nếu để chế độ thường, mỗi lần ai đó tải về là viện trả tiền băng thông — có thể lên tới hàng chục nghìn đô. Bật Requester Pays: ai muốn dùng thì tự trả phí tải, viện chỉ chịu chi phí lưu trữ.
Map từ khóa & cheat sheet
| Đề nhắc đến… | Nghĩ ngay tới |
|---|---|
| "được thông báo khi có object upload" | S3 Event Notifications |
| "tự động chuyển object giữa các tầng" | Lifecycle Rules — Transition |
| "xóa phiên bản cũ để giảm chi phí" | Lifecycle Rules — Expiration |
| "dọn phần multi-part upload dang dở" | Lifecycle Rules |
| "biết nên chuyển tầng sau bao nhiêu ngày" | S3 Analytics (chỉ Standard và Standard-IA) |
| "đọc 250 byte đầu của mỗi file" | Byte-Range Fetch |
| "lọc hàng và cột của CSV bằng SQL" | S3 Select |
| "file lớn, mạng không ổn định" | Multi-Part Upload + Transfer Acceleration |
| "lỗi khi upload file 25 GB" | Multi-Part Upload |
| "mã hóa lại toàn bộ file đang có" | S3 Batch Operations |
| "chạy Lambda trên từng object trong danh sách" | S3 Batch Operations |
| "nhìn toàn cảnh lưu trữ cả tổ chức" | S3 Storage Lens |
| "bucket nào chưa bật versioning/mã hóa" | Storage Lens — Data-Protection Metrics |
| "chia sẻ dataset lớn, người tải tự trả phí" | Requester Pays |
| "cần lọc và định tuyến sự kiện nâng cao" | EventBridge |
Cheat sheet 90 giây
- Lifecycle có hai loại hành động: Transition (chuyển tầng) và Expiration (xóa — kể cả phiên bản cũ và multi-part dang dở).
- S3 Analytics chỉ gợi ý, không tự làm; chỉ hỗ trợ Standard và Standard-IA; cần 24–48 giờ mới có dữ liệu.
- Event Notifications gửi tới SNS · SQS · Lambda, cần resource-based policy ở phía đích.
- EventBridge cho lọc JSON nâng cao, hơn 18 đích, có archive và replay.
- Hiệu năng: 3.500 PUT · 5.500 GET mỗi giây mỗi prefix, không giới hạn số prefix.
- Multi-part: khuyến nghị trên 100 MB, bắt buộc trên 5 GB.
- Transfer Acceleration đi qua edge location; kết hợp được với multi-part.
- Byte-Range Fetch = lấy khoảng byte theo vị trí. S3 Select = lọc hàng/cột bằng SQL.
- Batch Operations tác động lên object đã tồn tại: mã hóa lại, copy, sửa tag, gọi Lambda.
- Storage Lens: toàn tổ chức, free giữ 14 ngày, advanced giữ 15 tháng.
- Requester Pays: bên tải trả phí truyền dữ liệu, bắt buộc đăng nhập AWS.
Sáu câu tự kiểm tra trước khi qua file quiz
1. Muốn xóa tự động các phiên bản cũ trong bucket đã bật versioning. Dùng gì?
2. Muốn biết nên chuyển object sang Standard-IA sau bao nhiêu ngày. Dùng gì?
3. Cần đọc 250 byte đầu của 100.000 file. Dùng gì?
4. Cần mã hóa lại toàn bộ file đang có bằng KMS. Dùng gì?
5. Bucket có một prefix, cần 12.000 GET mỗi giây. Làm sao?
6. Upload file 10 GB qua kết nối chập chờn. Làm sao?
Đáp án: (1) Lifecycle Rules — Expiration Actions. (2) S3 Analytics (Storage Class Analysis). (3) Byte-Range Fetch — S3 Select chỉ lọc hàng/cột của dữ liệu có cấu trúc. (4) S3 Batch Operations. (5) Chia dữ liệu ra nhiều prefix — mỗi prefix cho 5.500 GET/giây nên cần ít nhất 3 prefix. (6) Multi-Part Upload kết hợp Transfer Acceleration.