Amazon S3
Bài giảng gọi S3 là "hạ tầng của Internet" — và trong đề SAA, nó xuất hiện dày đặc hơn bất kỳ dịch vụ nào khác. Chương này lo phần nền: bucket, object, bảo mật, versioning, replication và bảy storage class.
S3 Overview · Bucket & Object
S3 là object storage — lưu file dưới dạng đối tượng trong các "thùng chứa" gọi là bucket. Rất nhiều website và cả các dịch vụ AWS khác đều chạy trên nền S3.
Các trường hợp sử dụng
Sao lưu và lưu trữ · disaster recovery · lưu trữ dài hạn · hybrid cloud · lưu media · data lake và phân tích dữ liệu lớn · phân phối phần mềm · hosting website tĩnh.
Bucket — ba quy tắc
Tên bucket phải duy nhất trên TOÀN CẦU — trên mọi region và mọi tài khoản AWS của mọi khách hàng. Đây là lý do bạn không thể tạo bucket tên dev hay test: ai đó trên thế giới đã lấy rồi. Đây là câu hỏi đầu tiên trong quiz gốc.
- Bucket được tạo trong một region cụ thể — S3 trông có vẻ global nhưng dữ liệu nằm ở region bạn chọn.
- Quy tắc đặt tên: không chữ hoa, không dấu gạch dưới, dài 3–63 ký tự, không được là địa chỉ IP, phải bắt đầu bằng chữ thường hoặc số, không bắt đầu bằng
xn--, không kết thúc bằng-s3alias.
Object — và cái bẫy "thư mục"
Mỗi object có một key, và key chính là toàn bộ đường dẫn:
s3://my-bucket/my_file.txt
└─ key = "my_file.txt"
s3://my-bucket/anh/2026/thang-08/bien.jpg
└─ key = "anh/2026/thang-08/bien.jpg"
prefix = "anh/2026/thang-08/" · tên object = "bien.jpg"S3 KHÔNG có khái niệm thư mục. Giao diện web hiển thị như có thư mục, nhưng thực chất chỉ là các key dài chứa dấu gạch chéo. Điều này giải thích vì sao "đổi tên thư mục" trong S3 thực ra là copy toàn bộ object sang key mới rồi xóa cái cũ.
Các con số của object
| Thuộc tính | Chi tiết |
|---|---|
| Kích thước tối đa | 5 TB |
| Upload trên 5 GB | Bắt buộc dùng multi-part upload |
| Metadata | Cặp key/value dạng text — của hệ thống hoặc do bạn đặt |
| Tags | Cặp key/value Unicode, tối đa 10 — hữu ích cho bảo mật và lifecycle |
| Version ID | Có khi bật versioning |
S3 Security & Bucket Policy
Bốn cơ chế phân quyền
| Loại | Cơ chế | Ghi chú |
|---|---|---|
| User-Based | IAM Policies | API nào user được gọi — gắn vào user/group/role |
| Resource-Based | Bucket Policy | Quy tắc cho cả bucket, hỗ trợ truy cập xuyên tài khoản |
| Object ACL | Phân quyền chi tiết tới từng object (tắt được) | |
| Bucket ACL | Ít dùng (tắt được) |
Một IAM principal truy cập được object khi: quyền IAM của user CHO PHÉP HOẶC resource policy CHO PHÉP — VÀ không có explicit DENY nào.
Hệ quả: bucket policy đã cho phép mà user vẫn không PutObject được → nguyên nhân là explicit DENY trong IAM policy gắn vào user đó. Nhớ lại quy tắc vàng từ Section 4: Deny tường minh thắng tất cả.
Bucket Policy
Là JSON, cấu trúc giống policy IAM đã học: Resource (bucket và object), Effect, Action, Principal.
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "PublicRead",
"Effect": "Allow",
"Principal": "*", ← ai cũng được
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::my-bucket/*"] ← nhớ dấu /* cho object
}]
}Ba trường hợp dùng phổ biến: cho phép truy cập công khai · bắt buộc mã hóa khi upload · cấp quyền cho tài khoản AWS khác.
arn:aws:s3:::my-bucket là bản thân bucket (dùng cho ListBucket), còn arn:aws:s3:::my-bucket/* là các object bên trong (dùng cho GetObject). Quên dấu /* là nguyên nhân số một của lỗi Access Denied.
Block Public Access
Lớp chặn đứng trên mọi policy, sinh ra để ngăn rò rỉ dữ liệu công ty. Kể cả bucket policy có cho phép public, nếu Block Public Access đang bật thì vẫn bị chặn. Cấu hình được ở mức tài khoản cho toàn bộ bucket.
Rất nhiều vụ lộ dữ liệu lớn trên thế giới bắt nguồn từ một bucket S3 bị để public do nhầm lẫn. AWS tạo ra Block Public Access chính vì lý do đó, và bật sẵn theo mặc định cho bucket mới. Khi bạn thật sự cần một bucket public (ví dụ hosting website tĩnh), phải chủ động tắt nó — bước cố ý này giúp không ai để lộ dữ liệu do vô tình.
Static Website Hosting
S3 host được website tĩnh (HTML, CSS, JS, ảnh) và cho truy cập từ Internet — không cần máy chủ nào.
http://ten-bucket.s3-website-.amazonaws.com
hoặc
http://ten-bucket.s3-website..amazonaws.com Gặp 403 Forbidden khi mở website → bucket policy chưa cho phép đọc công khai. Nhớ kiểm tra cả hai thứ: tắt Block Public Access và thêm bucket policy cho s3:GetObject với Principal: "*".
Một trang landing page hoặc tài liệu kỹ thuật dạng tĩnh đặt trên S3 tốn vài đô mỗi tháng, không cần vá lỗi máy chủ, và tự chịu được lượng truy cập tăng vọt. Thực tế người ta thường ghép thêm CloudFront phía trước để có HTTPS, tên miền riêng và cache toàn cầu — mô hình bạn sẽ gặp lại ở Section 15.
Versioning
Bật ở mức bucket. Sau khi bật, ghi đè lên cùng một key sẽ tạo phiên bản mới (1, 2, 3…) thay vì mất bản cũ.
Vì sao nên bật: chống xóa nhầm (khôi phục lại được) và quay lui về phiên bản trước dễ dàng.
1. File đã có TRƯỚC khi bật versioning sẽ mang version null — không phải 0, không phải 1.
2. Tạm dừng (suspend) versioning KHÔNG xóa các phiên bản cũ — chúng vẫn nằm đó, chỉ là từ giờ không tạo phiên bản mới nữa.
Cơ chế xóa
| Thao tác | Điều gì xảy ra |
|---|---|
| Xóa object thông thường | S3 thêm một delete marker — file không thật sự mất, chỉ bị ẩn |
| Khôi phục | Xóa delete marker đi là file hiện lại |
| Xóa vĩnh viễn | Phải xóa đúng version ID cụ thể |
Một script dọn dẹp chạy sai và xóa nhầm 4.000 file ảnh sản phẩm lúc 2h sáng. Vì bucket đã bật versioning, thao tác đó chỉ tạo ra 4.000 delete marker — đội vận hành xóa các marker và toàn bộ ảnh trở lại nguyên vẹn. Nếu không bật versioning thì đó là mất dữ liệu thật, và phải khôi phục từ backup nếu có.
Replication — CRR & SRR
| Loại | Nghĩa | Dùng khi |
|---|---|---|
| CRR — Cross-Region Replication | Sao chép sang region khác | Tuân thủ pháp lý, giảm độ trễ cho người dùng ở xa, sao chép giữa các tài khoản |
| SRR — Same-Region Replication | Sao chép trong cùng region | Gom log, đồng bộ dữ liệu giữa tài khoản production và test |
Phải bật Versioning ở CẢ bucket nguồn VÀ bucket đích. Không có versioning thì không replicate được.
Các đặc điểm cần nhớ
- Hai bucket có thể thuộc hai tài khoản AWS khác nhau.
- Sao chép là bất đồng bộ.
- Phải cấp quyền IAM phù hợp cho S3 để nó thực hiện việc sao chép.
- Sau khi bật, chỉ object MỚI được replicate. Muốn chép cả dữ liệu cũ thì dùng S3 Batch Replication (chép cả object cũ và những object từng replicate thất bại).
1. Không có chuỗi dây chuyền (no chaining). Nếu bucket A replicate sang B, và B replicate sang C, thì object tạo ở A không tới được C. Muốn A tới cả B và C thì phải cấu hình hai luồng riêng: A→B và A→C.
2. Về thao tác xóa: có tùy chọn replicate delete marker sang bucket đích, nhưng xóa theo version ID cụ thể thì KHÔNG được replicate — đây là cơ chế cố ý để chống xóa phá hoại.
Đội phân tích ở châu Âu phải truy vấn tập dữ liệu nằm ở bucket tại Singapore. Mỗi truy vấn kéo dữ liệu xuyên châu lục nên vừa chậm vừa tốn phí truyền dữ liệu. Bật CRR sang một bucket ở Frankfurt: đội châu Âu đọc dữ liệu ngay tại chỗ, độ trễ và chi phí đều giảm — đây chính là tình huống trong quiz gốc.
Storage Classes
Bảy lớp lưu trữ. Chuyển giữa các lớp thủ công hoặc tự động bằng S3 Lifecycle configuration (học kỹ ở Section 13).
Độ bền và tính sẵn sàng — phân biệt hai khái niệm
| Durability (độ bền) | Availability (tính sẵn sàng) | |
|---|---|---|
| Nghĩa | Xác suất dữ liệu không bị mất | Dịch vụ truy cập được bao nhiêu phần trăm thời gian |
| Con số | 99,999999999% (11 số 9) | Thay đổi theo từng storage class |
| Khác nhau giữa các class? | KHÔNG — mọi class đều như nhau | CÓ |
Ý nghĩa của 11 số 9: lưu 10 triệu object thì trung bình 10.000 năm mới mất một object. S3 Standard có availability 99,99% — tức khoảng 53 phút không truy cập được mỗi năm.
Bảng bảy storage class
| Class | Availability | Đặc điểm | Dùng cho |
|---|---|---|---|
| S3 Standard | 99,99% | Độ trễ thấp, thông lượng cao, chịu được 2 sự cố cơ sở đồng thời | Dữ liệu truy cập thường xuyên: big data, ứng dụng di động, phân phối nội dung |
| Standard-IA | 99,9% | Rẻ hơn Standard nhưng có phí truy xuất | Backup, disaster recovery |
| One Zone-IA | 99,5% | Độ bền 11 số 9 nhưng chỉ trong MỘT AZ — AZ chết là mất dữ liệu | Bản sao thứ cấp của dữ liệu on-premise, hoặc dữ liệu tạo lại được |
| Glacier Instant Retrieval | — | Lấy ra trong mili giây, tối thiểu 90 ngày | Dữ liệu truy cập khoảng một lần mỗi quý |
| Glacier Flexible Retrieval | — | Ba chế độ lấy, tối thiểu 90 ngày | Lưu trữ dài hạn, chấp nhận chờ |
| Glacier Deep Archive | — | Rẻ nhất, tối thiểu 180 ngày | Lưu trữ rất dài hạn, gần như không đụng tới |
| Intelligent-Tiering | — | Tự chuyển tầng theo thói quen truy cập, không có phí truy xuất, nhưng có phí giám sát hàng tháng | Không đoán được mẫu truy cập |
Chế độ truy xuất Glacier — hai câu trong quiz gốc
| Glacier Flexible Retrieval | Glacier Deep Archive | |
|---|---|---|
| Các chế độ | Expedited: 1–5 phút | Standard: 12 giờ |
| Standard: 3–5 giờ | Bulk: 48 giờ | |
| Bulk: 5–12 giờ (miễn phí) | — | |
| Tối thiểu lưu trữ | 90 ngày | 180 ngày |
Deep Archive KHÔNG có chế độ Expedited — nhanh nhất cũng phải 12 giờ.
Flexible Retrieval KHÔNG có chế độ Instant — muốn lấy trong mili giây thì đó là Glacier Instant Retrieval, một class riêng.
Các tầng của Intelligent-Tiering
| Tầng | Điều kiện chuyển vào |
|---|---|
| Frequent Access | Mặc định |
| Infrequent Access | Không truy cập 30 ngày |
| Archive Instant Access | Không truy cập 90 ngày |
| Archive Access (tùy chọn) | Cấu hình từ 90 ngày trở lên |
| Deep Archive Access (tùy chọn) | Cấu hình từ 180 ngày trở lên |
Một bệnh viện lưu ảnh chụp X-quang: 30 ngày đầu bác sĩ xem thường xuyên → S3 Standard. Sau 30 ngày thỉnh thoảng mới tra lại nhưng cần có ngay khi cần → Standard-IA. Sau một năm chỉ giữ để tuân thủ quy định 10 năm, gần như không ai mở → Glacier Deep Archive, rẻ hơn Standard khoảng 20 lần. Chuyển tự động bằng Lifecycle Rule, không ai phải làm thủ công.
Ngược lại, nếu dữ liệu không đoán được khi nào cần — ví dụ log của một sản phẩm mới ra mắt — thì Intelligent-Tiering hợp hơn: nó tự chuyển tầng và không tính phí truy xuất, đổi lại chịu phí giám sát nhỏ hàng tháng.
Map từ khóa & cheat sheet
| Đề nhắc đến… | Nghĩ ngay tới |
|---|---|
| "không tạo được bucket dù có quyền IAM" | Tên bucket đã bị người khác lấy — duy nhất toàn cầu |
| "bucket policy cho phép nhưng vẫn Access Denied" | Explicit DENY trong IAM policy |
| "403 Forbidden khi mở website S3" | Bucket policy chưa cho đọc công khai |
| "file có trước khi bật versioning" | Version null |
| "chống xóa nhầm file" | Bật Versioning |
| "dữ liệu sẵn có ở region khác, độ trễ và chi phí thấp nhất" | S3 Replication (CRR) |
| "replicate từ A sang cả B và C" | Hai luồng A→B và A→C — không có chaining |
| "replicate cả dữ liệu cũ" | S3 Batch Replication |
| "truy cập một lần mỗi quý, cần lấy trong mili giây" | Glacier Instant Retrieval |
| "lưu trữ rẻ nhất, chờ 12–48 giờ cũng được" | Glacier Deep Archive |
| "dữ liệu tạo lại được, muốn rẻ, chấp nhận rủi ro một AZ" | One Zone-IA |
| "không đoán được mẫu truy cập" | Intelligent-Tiering |
| "bắt buộc mã hóa khi upload" | Bucket Policy với điều kiện |
| "cấp quyền cho tài khoản AWS khác" | Bucket Policy (resource-based) |
Cheat sheet 90 giây
- Tên bucket duy nhất toàn cầu, không hoa, không gạch dưới, 3–63 ký tự; bucket thuộc một region.
- Không có thư mục — chỉ có key dài chứa dấu gạch chéo (prefix + tên).
- Object tối đa 5 TB; trên 5 GB phải multi-part upload; tối đa 10 tag.
- Quyền = IAM HOẶC bucket policy cho phép, VÀ không có explicit DENY.
- Block Public Access chặn đè lên mọi policy, bật sẵn cho bucket mới.
- Versioning ở mức bucket; file cũ mang version null; suspend không xóa phiên bản cũ; xóa thường chỉ tạo delete marker.
- Replication cần versioning ở cả hai bucket, chạy bất đồng bộ, chỉ áp dụng cho object mới, và không có chaining.
- Xóa theo version ID cụ thể không được replicate.
- Độ bền 11 số 9 cho mọi class; chỉ availability mới khác nhau.
- Glacier: Instant (mili giây) · Flexible (1–5 phút / 3–5 giờ / 5–12 giờ) · Deep Archive (12 giờ / 48 giờ).
- Tối thiểu lưu trữ: Glacier Instant và Flexible 90 ngày, Deep Archive 180 ngày.
- Intelligent-Tiering không có phí truy xuất, nhưng có phí giám sát hàng tháng.
Sáu câu tự kiểm tra trước khi qua file quiz
1. Bạn có quyền IAM đầy đủ nhưng không tạo được bucket tên data. Vì sao?
2. Bật versioning trên bucket đã có 500 file. Các file đó mang version gì?
3. Muốn replicate từ bucket A sang cả B và C. Cấu hình thế nào?
4. Glacier Deep Archive có chế độ Expedited không?
5. Bucket policy đã Allow nhưng user vẫn bị Access Denied. Nguyên nhân?
6. Dữ liệu có thể tạo lại được, muốn rẻ nhất trong nhóm truy cập nhanh. Chọn class nào?
Đáp án: (1) Tên bucket phải duy nhất toàn cầu — ai đó đã lấy tên đó. (2) Version null. (3) Cấu hình hai luồng riêng A→B và A→C; replication không hoạt động theo dây chuyền. (4) Không — Deep Archive chỉ có Standard 12 giờ và Bulk 48 giờ. (5) Có explicit DENY trong IAM policy của user. (6) One Zone-IA — rẻ hơn Standard-IA, đổi lại mất dữ liệu nếu AZ đó hỏng.