Amazon S3 – Lưu trữ đối tượng
1. Amazon S3 & use case
Phần tiêu đề “1. Amazon S3 & use case”Amazon S3 (Simple Storage Service) là một trong những “viên gạch” xây dựng nền tảng quan trọng nhất của AWS. S3 được quảng bá là dịch vụ lưu trữ có khả năng mở rộng “vô hạn” (infinitely scaling storage) — bạn không cần lo lắng về việc hết dung lượng như khi dùng một ổ cứng vật lý. Rất nhiều website lớn dùng S3 làm “bộ xương sống” (backbone) lưu trữ dữ liệu của mình, và rất nhiều dịch vụ khác của AWS cũng tích hợp trực tiếp với S3 (ví dụ CloudFront, Lambda, Athena, SageMaker…).
Các use case phổ biến nhất của S3 bao gồm:
- Backup và lưu trữ (Backup and storage): sao lưu dữ liệu quan trọng.
- Disaster Recovery: phục hồi sau thảm họa — lưu bản sao dữ liệu ở nơi an toàn để khôi phục khi cần.
- Archive: lưu trữ dữ liệu ít dùng nhưng cần giữ lại lâu dài (ví dụ vì lý do pháp lý).
- Hybrid Cloud storage: làm cầu nối lưu trữ giữa hạ tầng on-premise và cloud.
- Application hosting: lưu trữ mã nguồn, file tĩnh phục vụ ứng dụng.
- Media hosting: lưu video, ảnh, âm thanh.
- Data lakes & big data analytics: làm “hồ dữ liệu” trung tâm cho các công cụ phân tích.
- Software delivery: phân phối phần mềm, bản cập nhật.
- Static website: lưu trữ và phục vụ website tĩnh trực tiếp từ S3.
2. S3 Buckets
Phần tiêu đề “2. S3 Buckets”S3 cho phép bạn lưu các đối tượng (object, tức là file) vào trong các bucket — có thể hình dung bucket giống như một “thư mục gốc” hoặc một “container” chứa file. Mỗi bucket phải có tên duy nhất trên toàn cầu (globally unique) — không chỉ duy nhất trong region hay account của bạn, mà duy nhất trên toàn bộ AWS, ở mọi region, mọi account của mọi khách hàng khác.
Một điểm hay gây nhầm lẫn: S3 trông có vẻ là một dịch vụ “toàn cầu” (bạn không chọn region khi nhìn vào danh sách bucket), nhưng thực chất mỗi bucket được tạo và tồn tại tại một region cụ thể. Dữ liệu trong bucket đó thực sự nằm vật lý ở region bạn đã chọn khi tạo bucket.
Quy tắc đặt tên bucket khá chặt chẽ, đề thi hay hỏi chi tiết:
- Không được chứa chữ hoa (uppercase).
- Không được chứa dấu gạch dưới (underscore).
- Độ dài từ 3 đến 63 ký tự.
- Không được là một địa chỉ IP (ví dụ không được đặt tên dạng
192.168.1.1). - Phải bắt đầu bằng chữ thường hoặc số.
- Không được bắt đầu bằng tiền tố
xn--. - Không được kết thúc bằng hậu tố
-s3alias.
3. S3 Objects
Phần tiêu đề “3. S3 Objects”Mỗi file lưu trong S3 được gọi là một Object. Mỗi Object có một Key — chính là đường dẫn đầy đủ của file đó trong bucket. Ví dụ: s3://my-bucket/my_file.txt, hoặc với các “thư mục lồng nhau” như s3://my-bucket/folder1/folder2/my_file.txt. Key được cấu tạo từ Prefix (phần đường dẫn phía trước, ví dụ folder1/folder2/) cộng với tên object.
Đây là điểm rất dễ gây hiểu lầm: S3 KHÔNG có khái niệm “thư mục” (directory) thực sự bên trong bucket. Giao diện AWS Console “đánh lừa” bạn bằng cách hiển thị các folder trông giống hệ thống file thông thường, nhưng bản chất, S3 chỉ lưu các Key là những chuỗi ký tự dài, có chứa dấu gạch chéo / — không có cấu trúc cây thư mục thật sự ở tầng lưu trữ.
Mỗi Object còn có các thành phần khác:
- Value: nội dung thực tế (body) của file. Kích thước tối đa của một object là 5TB (5000GB). Nếu bạn upload một file lớn hơn 5GB, bạn phải sử dụng cơ chế multi-part upload (chia file thành nhiều phần nhỏ để upload song song, sau đó AWS ghép lại).
- Metadata: danh sách các cặp key/value dạng văn bản, mô tả về file (có thể là metadata hệ thống hoặc do người dùng tự định nghĩa).
- Tags: các cặp key/value dạng Unicode, tối đa 10 tag cho mỗi object — rất hữu ích để phục vụ mục đích bảo mật (ví dụ gắn tag để áp policy) hoặc lifecycle (tự động chuyển storage class/xóa theo tag).
- Version ID: nếu bucket đã bật Versioning, mỗi lần ghi đè lên cùng một Key sẽ tạo ra một Version ID mới, giữ lại lịch sử các phiên bản.
4. Bảo mật S3 – Tổng quan
Phần tiêu đề “4. Bảo mật S3 – Tổng quan”Bảo mật cho S3 được kiểm soát theo hai hướng chính, và bạn cần hiểu rõ sự khác biệt giữa chúng:
- User-Based (dựa trên người dùng): thông qua IAM Policies — quy định API nào mà một user IAM cụ thể được phép gọi, được gắn trực tiếp vào user/group/role trong IAM.
- Resource-Based (dựa trên tài nguyên): gồm ba loại:
- Bucket Policies: các quy tắc áp dụng cho toàn bộ bucket, cấu hình từ S3 Console, cho phép cấp quyền cross-account (cho account khác truy cập).
- Object Access Control List (ACL): kiểm soát chi tiết hơn ở từng object, hiện có thể bị tắt (disabled) hoàn toàn.
- Bucket ACL: ít phổ biến hơn, cũng có thể bị tắt.
Nguyên tắc đánh giá quyền truy cập rất quan trọng: một IAM principal (user/role) có thể truy cập một object S3 NẾU quyền IAM của user đó CHO PHÉP (ALLOW) HOẶC resource policy (bucket policy) CHO PHÉP — VÀ không có bất kỳ DENY rõ ràng (explicit) nào áp dụng. Nói cách khác, chỉ cần một trong hai phía (IAM hoặc bucket policy) cho phép là đủ, nhưng một DENY tường minh ở bất kỳ đâu sẽ luôn thắng và chặn truy cập.
Ngoài ra, S3 còn hỗ trợ Encryption (mã hóa) — mã hóa các object bằng khóa mã hóa, sẽ được trình bày chi tiết ở phần sau của chương.
5. S3 Bucket Policies
Phần tiêu đề “5. S3 Bucket Policies”Bucket Policy là các chính sách dạng JSON, được gắn trực tiếp vào bucket. Cấu trúc chính của một Bucket Policy gồm:
- Resources: bucket và/hoặc object nào bị áp dụng chính sách.
- Effect: Allow (cho phép) hoặc Deny (từ chối).
- Actions: tập hợp các API nào được cho phép/từ chối (ví dụ
s3:GetObject,s3:PutObject). - Principal: account/user nào mà chính sách này áp dụng cho.
Bucket Policy thường được dùng để:
- Cấp quyền public (công khai) cho bucket — ví dụ để phục vụ website tĩnh.
- Buộc các object phải được mã hóa khi upload (từ chối các request không kèm tham số mã hóa).
- Cấp quyền truy cập cho một account AWS khác (cross-account access).
Để hiểu rõ cách các cơ chế bảo mật kết hợp với nhau, hãy xem 4 tình huống điển hình sau:
- Truy cập công khai qua Bucket Policy: một khách truy cập ẩn danh (anonymous) trên Internet được cho phép đọc dữ liệu, nhờ Bucket Policy cho phép Principal là
*(mọi người) thực hiện hành động đọc. - Truy cập của người dùng qua quyền IAM: một IAM User trong chính account của bạn được gắn một IAM Policy cho phép truy cập bucket — không cần Bucket Policy nào cả, quyền IAM là đủ.
- Truy cập từ EC2 Instance qua IAM Role: một EC2 Instance được gắn một IAM Role có quyền truy cập S3 — ứng dụng chạy trên EC2 dùng credential tạm thời từ Role đó để gọi API S3, đây là cách làm được khuyến nghị (không hard-code access key).
- Truy cập cross-account qua Bucket Policy: một IAM User thuộc một AWS account KHÁC được Bucket Policy của bạn cho phép truy cập — Bucket Policy đóng vai trò “mời” account khác vào, dù account đó không có quyền IAM gì trong account của bạn.
6. Block Public Access
Phần tiêu đề “6. Block Public Access”Block Public Access là một nhóm cài đặt được AWS tạo ra để ngăn chặn rò rỉ dữ liệu công ty do vô tình cấu hình bucket ở chế độ public. Đây là một trong những sự cố bảo mật phổ biến nhất trên cloud — rất nhiều vụ rò rỉ dữ liệu nổi tiếng trong thực tế xuất phát từ một bucket S3 bị để public “nhầm”.
Nếu bạn biết chắc bucket của mình không bao giờ cần công khai, hãy giữ nguyên các cài đặt Block Public Access ở trạng thái BẬT (mặc định của AWS hiện nay). Các cài đặt này có thể được thiết lập ở cấp độ từng bucket, hoặc ở cấp độ toàn bộ account (account level) — áp dụng cho tất cả bucket hiện có và sẽ tạo trong tương lai.
7. Website tĩnh trên S3
Phần tiêu đề “7. Website tĩnh trên S3”S3 có thể được dùng để lưu trữ (host) một website tĩnh (static website — chỉ gồm HTML/CSS/JS, không cần server xử lý backend) và cho phép truy cập trực tiếp qua Internet. URL của website sẽ phụ thuộc vào region bạn chọn, theo một trong hai định dạng:
http://bucket-name.s3-website-aws-region.amazonaws.comhttp://bucket-name.s3-website.aws-region.amazonaws.com
Nếu bạn truy cập website và gặp lỗi 403 Forbidden, nguyên nhân gần như chắc chắn là Bucket Policy chưa cho phép đọc công khai (public read) — cần kiểm tra lại Bucket Policy và cài đặt Block Public Access để đảm bảo khách truy cập ẩn danh có quyền s3:GetObject.
8. S3 Versioning
Phần tiêu đề “8. S3 Versioning”S3 cho phép bật Versioning (đánh phiên bản) cho các file trong bucket. Versioning được bật ở cấp độ bucket (toggle on/off cho toàn bộ bucket). Khi bật, mỗi lần bạn ghi đè (overwrite) lên cùng một Key, S3 không xóa dữ liệu cũ mà tạo ra một “version” mới: version 1, version 2, version 3… và giữ lại tất cả các version trước đó.
Đây là một best practice rất được khuyến nghị vì hai lý do chính:
- Bảo vệ khỏi xóa/ghi đè ngoài ý muốn: nếu ai đó vô tình xóa hoặc ghi đè một file quan trọng, bạn có thể khôi phục lại phiên bản trước đó.
- Dễ dàng rollback: quay lại một phiên bản cũ của file bất cứ lúc nào.
Một số điểm cần nhớ:
- Các file được upload trước khi bạn bật Versioning sẽ có version là
null— chúng không “tự động” có version 1, mà version của chúng là giá trị null cho tới khi bị ghi đè lần đầu sau khi Versioning đã bật. - Việc tạm ngưng (suspend) Versioning không xóa các phiên bản đã được lưu trước đó — các version cũ vẫn còn nguyên, chỉ là từ giờ sẽ không tạo thêm version mới nữa.
9. S3 Replication (CRR & SRR)
Phần tiêu đề “9. S3 Replication (CRR & SRR)”S3 Replication cho phép tự động sao chép object từ một bucket nguồn sang một bucket đích. Điều kiện bắt buộc: Versioning phải được bật ở cả bucket nguồn và bucket đích. Có hai loại replication:
- Cross-Region Replication (CRR): sao chép sang bucket ở một region KHÁC.
- Same-Region Replication (SRR): sao chép sang bucket trong CÙNG một region.
Hai bucket nguồn và đích có thể thuộc về các AWS account khác nhau. Việc sao chép diễn ra bất đồng bộ (asynchronous) — có một khoảng thời gian trễ nhỏ (thường vài giây tới vài phút) giữa lúc object được tạo ở nguồn và lúc nó xuất hiện ở đích, không phải tức thời. Để replication hoạt động, bạn cần cấp đúng quyền IAM cho dịch vụ S3 thực hiện việc sao chép.
Ứng dụng thực tế của từng loại:
- CRR thường dùng cho: đáp ứng yêu cầu tuân thủ (compliance) đòi hỏi lưu dữ liệu ở nhiều địa lý; giảm độ trễ (latency) khi truy cập dữ liệu từ khu vực xa; hoặc nhân bản dữ liệu sang một account khác.
- SRR thường dùng cho: gộp log (log aggregation) từ nhiều bucket vào một nơi; hoặc nhân bản dữ liệu “sống” (live replication) giữa môi trường production và môi trường test để test luôn có dữ liệu mới nhất.
10. Tổng quan Storage Class
Phần tiêu đề “10. Tổng quan Storage Class”AWS cung cấp nhiều Storage Class (hạng lưu trữ) khác nhau cho S3, mỗi loại được tối ưu cho một kiểu truy cập dữ liệu và mức chi phí khác nhau. Danh sách các storage class gồm:
- S3 Standard (General Purpose)
- S3 Standard-Infrequent Access (Standard-IA)
- S3 One Zone-Infrequent Access
- S3 Glacier Instant Retrieval
- S3 Glacier Flexible Retrieval
- S3 Glacier Deep Archive
- S3 Intelligent-Tiering
Bạn có thể chuyển đổi giữa các storage class này một cách thủ công, hoặc tự động hóa việc chuyển đổi thông qua S3 Lifecycle Configuration (quy tắc tự động, ví dụ “sau 30 ngày, chuyển sang Standard-IA; sau 90 ngày, chuyển sang Glacier”). Các phần tiếp theo sẽ đi sâu vào từng storage class.
11. Durability và Availability
Phần tiêu đề “11. Durability và Availability”Đây là hai khái niệm cực kỳ dễ nhầm lẫn khi học về S3 — đề thi khai thác rất nhiều:
- Durability (độ bền/độ tin cậy dữ liệu): đo khả năng dữ liệu KHÔNG bị mất. S3 cam kết độ bền 99.999999999% (11 số 9) cho object, được duy trì nhờ tự động sao chép dữ liệu qua nhiều Availability Zone. Nói dễ hiểu: nếu bạn lưu 10.000.000 object trong S3, về mặt thống kê bạn chỉ có thể mất trung bình 1 object mỗi 10.000 năm. Mức độ bền 11 số 9 này là giống nhau cho TẤT CẢ storage class của S3 — dù bạn chọn Standard hay Glacier Deep Archive, độ bền dữ liệu đều như nhau.
- Availability (tính sẵn sàng): đo mức độ dịch vụ luôn “sẵn sàng để dùng ngay khi cần” — nói cách khác là tỷ lệ thời gian bạn có thể truy cập/đọc được dữ liệu thành công. Khác với Durability, Availability thay đổi tùy theo từng storage class. Ví dụ, S3 Standard có Availability 99.99% — nghĩa là dịch vụ có thể “không sẵn sàng” tối đa khoảng 53 phút mỗi năm.
12. S3 Standard – General Purpose
Phần tiêu đề “12. S3 Standard – General Purpose”S3 Standard (General Purpose) là storage class “mặc định”, phù hợp cho phần lớn trường hợp sử dụng thông thường. Đặc điểm chính:
- Availability 99.99%.
- Dùng cho dữ liệu được truy cập thường xuyên (frequently accessed data).
- Độ trễ thấp (low latency) và throughput cao.
- Có thể chịu được việc mất đồng thời 2 cơ sở lưu trữ (facility) mà vẫn không mất dữ liệu.
Use case điển hình: phân tích Big Data, ứng dụng di động và game (mobile & gaming apps), phân phối nội dung (content distribution) — tất cả đều cần truy cập dữ liệu nhanh và liên tục.
13. Standard-IA & One Zone-IA
Phần tiêu đề “13. Standard-IA & One Zone-IA”Nhóm Infrequent Access (IA) được thiết kế cho dữ liệu ít được truy cập, nhưng vẫn cần có thể truy cập nhanh khi cần thiết. Đổi lại việc ít truy cập, chi phí lưu trữ thấp hơn S3 Standard đáng kể.
- S3 Standard-IA: Availability 99.9%, dữ liệu vẫn được sao chép qua nhiều AZ (giữ độ bền cao). Use case: Disaster Recovery, các bản backup ít khi cần đọc lại nhưng phải sẵn sàng khi có sự cố.
- S3 One Zone-IA: vẫn giữ độ bền cao (11 số 9) nhưng chỉ lưu trong MỘT Availability Zone duy nhất — nghĩa là nếu AZ đó bị phá hủy hoàn toàn, dữ liệu sẽ MẤT. Availability thấp hơn, ở mức 99.5%. Đổi lại rủi ro này, chi phí rẻ hơn Standard-IA. Use case: lưu các bản sao lưu phụ (secondary backup) của dữ liệu vốn đã có trên on-premise, hoặc dữ liệu có thể tái tạo lại được (recreatable data) nếu chẳng may mất.
14. Các Storage Class Glacier
Phần tiêu đề “14. Các Storage Class Glacier”Nhóm Glacier là các storage class chi phí thấp nhất, dành cho việc lưu trữ dài hạn (archiving) và backup. Chi phí Glacier gồm hai phần: chi phí lưu trữ (storage) và chi phí truy xuất (retrieval) — khi bạn muốn lấy dữ liệu ra, bạn phải trả thêm phí và chờ một khoảng thời gian nhất định tùy loại truy xuất.
- S3 Glacier Instant Retrieval: truy xuất trong tính bằng millisecond — phù hợp cho dữ liệu chỉ được truy cập khoảng một lần mỗi quý (once a quarter). Thời gian lưu trữ tối thiểu (min storage duration) là 90 ngày.
- S3 Glacier Flexible Retrieval (tên cũ: S3 Glacier): có 3 tùy chọn tốc độ truy xuất — Expedited (1-5 phút), Standard (3-5 giờ), Bulk (5-12 giờ, miễn phí). Thời gian lưu trữ tối thiểu là 90 ngày.
- S3 Glacier Deep Archive (lưu trữ dài hạn nhất): có 2 tùy chọn — Standard (12 giờ), Bulk (48 giờ). Thời gian lưu trữ tối thiểu là 180 ngày. Đây là storage class rẻ nhất trong tất cả, phù hợp cho dữ liệu gần như không bao giờ cần đọc lại.
| Storage Class | Tốc độ truy xuất | Min Storage Duration |
|---|---|---|
| Glacier Instant Retrieval | Vài millisecond | 90 ngày |
| Glacier Flexible Retrieval | Expedited 1-5 phút / Standard 3-5 giờ / Bulk 5-12 giờ | 90 ngày |
| Glacier Deep Archive | Standard 12 giờ / Bulk 48 giờ | 180 ngày |
15. S3 Intelligent-Tiering
Phần tiêu đề “15. S3 Intelligent-Tiering”S3 Intelligent-Tiering giải quyết một vấn đề thực tế: nhiều khi bạn không biết chắc dữ liệu của mình sẽ được truy cập thường xuyên hay không, và không muốn tự tay quản lý việc chuyển storage class. Với Intelligent-Tiering, bạn chỉ trả thêm một khoản phí giám sát và tự động phân hạng (monitoring/auto-tiering fee) nhỏ mỗi tháng, và AWS sẽ tự động di chuyển object giữa các tier truy cập dựa trên hành vi sử dụng thực tế — hoàn toàn không tính phí truy xuất (no retrieval charges).
Các tier trong Intelligent-Tiering:
- Frequent Access tier: tier mặc định, tự động (automatic).
- Infrequent Access tier: tự động chuyển vào nếu object không được truy cập trong 30 ngày.
- Archive Instant Access tier: tự động, nếu không truy cập trong 90 ngày.
- Archive Access tier: tùy chọn (optional, phải tự bật), từ 90 ngày đến 700+ ngày không truy cập.
- Deep Archive Access tier: tùy chọn, từ 180 ngày đến 700+ ngày không truy cập.
16. So sánh & giá Storage Class
Phần tiêu đề “16. So sánh & giá Storage Class”Bảng dưới đây tổng hợp các thông số quan trọng để so sánh giữa các storage class (Durability giống nhau ở mọi loại, 11 số 9):
| Storage Class | Availability | Availability SLA | Số AZ | Min Storage Duration | Min Billable Object Size | Phí truy xuất (Retrieval Fee) |
|---|---|---|---|---|---|---|
| S3 Standard | 99.99% | 99.9% | ≥ 3 | Không có | Không có | Không có |
| S3 Intelligent-Tiering | 99.9% | 99% | ≥ 3 | Không có | Không có | Không có |
| S3 Standard-IA | 99.9% | 99% | ≥ 3 | 30 ngày | 128KB | Có, theo GB |
| S3 One Zone-IA | 99.5% | 99% | 1 | 30 ngày | 128KB | Có, theo GB |
| S3 Glacier Instant Retrieval | 99.9% | 99% | ≥ 3 | 90 ngày | 128KB | Có, theo GB |
| S3 Glacier Flexible Retrieval | 99.99% | 99.9% | ≥ 3 | 90 ngày | 40KB | Có, theo GB |
| S3 Glacier Deep Archive | 99.99% | 99.9% | ≥ 3 | 180 ngày | 40KB | Có, theo GB |
Hai cột dễ bị bỏ qua: Availability SLA là mức cam kết hợp đồng (thấp hơn con số availability thiết kế), còn số AZ là điểm phân biệt quan trọng nhất của One Zone-IA — dữ liệu chỉ nằm trong một AZ duy nhất, nên nếu AZ đó bị phá hủy thì dữ liệu mất, trong khi mọi storage class còn lại trải trên ít nhất 3 AZ.
Về mặt giá thành lưu trữ (ví dụ tại region us-east-1, mang tính minh họa tương đối, giá thực tế nên tham khảo AWS Pricing Calculator), thứ tự từ đắt tới rẻ nhất trên mỗi GB/tháng gần đúng là: Standard đắt nhất, tiếp theo Intelligent-Tiering (dao động theo tier), rồi Standard-IA, One Zone-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval, và rẻ nhất là Glacier Deep Archive. Xu hướng chung: storage class nào truy xuất chậm hơn/lâu hơn thì giá lưu trữ càng rẻ, nhưng phí truy xuất khi cần lấy dữ liệu ra lại càng cao hơn — đây là sự đánh đổi (trade-off) căn bản giữa các storage class.
17. S3 Express One Zone
Phần tiêu đề “17. S3 Express One Zone”S3 Express One Zone là storage class hiệu năng cao, chỉ lưu trong một Availability Zone (single AZ). Object được lưu trong một loại bucket đặc biệt gọi là Directory Bucket. Đây là lựa chọn dành cho các workload cần độ trễ (latency) cực thấp:
- Xử lý hàng trăm nghìn request mỗi giây (100,000s requests/sec) với độ trễ chỉ vài millisecond.
- Hiệu năng cao hơn tới 10 lần so với S3 Standard, đồng thời chi phí request thấp hơn tới 50%.
- Vẫn giữ độ bền cao (11 số 9) và Availability 99.95%.
- Cho phép “đặt gần nhau” (co-locate) tầng lưu trữ và tầng tính toán (compute) trong cùng một AZ, giúp giảm tối đa độ trễ mạng.
Use case: các ứng dụng nhạy cảm với độ trễ (latency-sensitive apps), ứng dụng xử lý dữ liệu chuyên sâu, huấn luyện AI & Machine Learning, mô hình hóa tài chính (financial modeling), xử lý media, và các workload tính toán hiệu năng cao (HPC). S3 Express One Zone được tích hợp tốt với các dịch vụ như SageMaker Model Training, Athena, EMR, và Glue.
18. Mã hóa & Access Analyzer
Phần tiêu đề “18. Mã hóa & Access Analyzer”S3 hỗ trợ hai cách mã hóa dữ liệu chính:
- Server-Side Encryption (mặc định): S3 nhận file của bạn (dưới dạng chưa mã hóa) rồi tự mã hóa nó SAU KHI nhận, trước khi lưu xuống đĩa vật lý.
- Client-Side Encryption: bạn tự mã hóa file TRƯỚC KHI upload lên S3 — S3 chỉ nhận và lưu dữ liệu đã được mã hóa từ trước, không biết nội dung gốc.
Bên cạnh mã hóa, AWS còn cung cấp IAM Access Analyzer for S3 — một công cụ giúp đảm bảo rằng chỉ những người/thực thể được chủ định (intended) mới có quyền truy cập bucket S3 của bạn. Công cụ này giúp phát hiện các tình huống như: bucket đang bị public ngoài ý muốn, hoặc bucket đang được chia sẻ với một AWS account khác mà bạn không lường trước. IAM Access Analyzer for S3 hoạt động bằng cách đánh giá toàn diện S3 Bucket Policies, S3 ACLs, và S3 Access Point Policies — được vận hành dựa trên nền tảng dịch vụ IAM Access Analyzer.
19. Trách nhiệm chung với S3
Phần tiêu đề “19. Trách nhiệm chung với S3”Giống như mọi dịch vụ AWS khác, S3 tuân theo Shared Responsibility Model — trách nhiệm bảo mật được chia sẻ giữa AWS và khách hàng:
| Trách nhiệm của AWS | Trách nhiệm của bạn (khách hàng) |
|---|---|
| Hạ tầng: bảo mật toàn cầu, đảm bảo Durability, Availability, chịu được mất đồng thời dữ liệu ở 2 facility | Cấu hình S3 Versioning |
| Cấu hình mặc định và phân tích lỗ hổng (vulnerability analysis) | Cấu hình S3 Bucket Policies |
| Xác thực tuân thủ (compliance validation) | Thiết lập S3 Replication |
| Logging và Monitoring | |
| Lựa chọn S3 Storage Class phù hợp | |
| Mã hóa dữ liệu khi lưu trữ (at rest) và khi truyền tải (in transit) |
Nói ngắn gọn: AWS chịu trách nhiệm cho hạ tầng vật lý và độ tin cậy nền tảng của S3, còn bạn chịu trách nhiệm cấu hình đúng cách dùng nó — bật versioning, viết đúng bucket policy, chọn đúng storage class, mã hóa dữ liệu phù hợp.
20. AWS Snowball
Phần tiêu đề “20. AWS Snowball”AWS Snowball là các thiết bị vật lý, di động (portable), có độ bảo mật cao, dùng để thu thập/xử lý dữ liệu ngay tại “biên” (edge) và di chuyển dữ liệu vào hoặc ra khỏi AWS. Snowball giúp di chuyển dữ liệu với khối lượng lên tới hàng Petabyte — điều mà việc truyền qua Internet thông thường sẽ mất rất nhiều thời gian hoặc thậm chí không khả thi.
| Loại thiết bị Snowball Edge | vCPU | RAM | Dung lượng lưu trữ |
|---|---|---|---|
| Storage Optimized | 104 | 416GB | 210TB SSD |
| Compute Optimized | 104 | 416GB | 28TB SSD |
Vì sao không truyền dữ liệu qua Internet luôn cho tiện? Hãy xem thời gian truyền dữ liệu ước tính theo băng thông:
| Băng thông | 10TB | 100TB | 1PB |
|---|---|---|---|
| 100 Mbps | 12 ngày | 124 ngày | ~3 năm |
| 1 Gbps | 30 giờ | 12 ngày | 124 ngày |
| 10 Gbps | 3 giờ | 30 giờ | 12 ngày |
Trong thực tế, việc truyền dữ liệu qua mạng gặp nhiều thử thách: kết nối hạn chế (limited connectivity), băng thông hạn chế, chi phí mạng cao (high network cost), băng thông bị chia sẻ với các ứng dụng khác (shared bandwidth), và kết nối không ổn định (connection stability). Quy tắc chung (rule of thumb): nếu việc truyền dữ liệu qua mạng mất hơn một tuần, hãy chuyển sang dùng thiết bị Snowball.
Có hai cách đưa dữ liệu vào S3: Direct upload — client gửi dữ liệu trực tiếp tới S3 bucket qua Internet (www); hoặc với Snowball — client copy dữ liệu vào thiết bị Snowball Edge tại chỗ, sau đó gửi (ship) thiết bị vật lý này về AWS, AWS sẽ nhập (import) dữ liệu vào S3 bucket của bạn.
21. Snowball Edge
Phần tiêu đề “21. Snowball Edge”Edge Computing là việc xử lý dữ liệu ngay tại thời điểm và nơi dữ liệu được tạo ra — ví dụ trên một xe tải đang chạy trên đường, một con tàu đang ở giữa biển, hoặc một trạm khai thác mỏ dưới lòng đất. Những nơi này thường có kết nối Internet rất hạn chế hoặc hoàn toàn không có, và cũng không có sẵn hạ tầng tính toán mạnh.
Giải pháp là triển khai một thiết bị Snowball Edge (Compute Optimized hoặc Storage Optimized) ngay tại địa điểm đó để thực hiện edge computing — thiết bị này có thể chạy trực tiếp EC2 Instance hoặc Lambda function ngay tại “biên”, xử lý dữ liệu cục bộ mà không cần gửi toàn bộ dữ liệu thô về AWS trước.
Use case điển hình: xử lý dữ liệu sơ bộ (preprocess data) trước khi truyền về cloud, chạy các mô hình machine learning ngay tại chỗ (ví dụ phát hiện lỗi trên dây chuyền sản xuất theo thời gian thực), hoặc chuyển đổi định dạng media (transcoding) ngay tại nơi quay/thu.
Về giá cả (Snowball Edge Pricing): bạn trả tiền cho việc sử dụng thiết bị và phí truyền dữ liệu ra khỏi AWS. Lưu ý: truyền dữ liệu VÀO S3 luôn miễn phí ($0.00/GB). Có hai mô hình giá:
- On-Demand: bao gồm một khoản phí dịch vụ (service fee) tính một lần cho mỗi job, kèm theo số ngày sử dụng miễn phí (ví dụ 10 ngày cho thiết bị Storage Optimized 80TB, 15 ngày cho thiết bị 210TB) — thời gian vận chuyển (shipping) không bị tính vào số ngày sử dụng. Nếu dùng lâu hơn, bạn trả thêm phí theo từng ngày phát sinh.
- Committed Upfront: trả trước theo tháng, 1 năm, hoặc 3 năm cho việc dùng Edge Computing, đổi lại được chiết khấu tới 62% so với giá thông thường.
22. AWS Storage Gateway
Phần tiêu đề “22. AWS Storage Gateway”AWS ngày càng khuyến khích mô hình Hybrid Cloud — một phần hạ tầng vẫn nằm on-premise, một phần chuyển lên cloud. Có nhiều lý do khiến các tổ chức chọn hybrid thay vì chuyển 100% lên cloud ngay: quá trình di trú (migration) kéo dài nhiều năm chứ không thể xong trong một sớm một chiều; yêu cầu bảo mật đặc thù; yêu cầu tuân thủ pháp lý (compliance) buộc một số dữ liệu phải nằm on-premise; hoặc đơn giản là chiến lược IT của tổ chức.
Một vấn đề kỹ thuật đặt ra: S3 là một công nghệ lưu trữ độc quyền (proprietary) của AWS — khác với các giao thức file chuẩn như NFS mà EFS sử dụng. Vậy làm sao để các hệ thống on-premise (vốn quen làm việc với ổ đĩa, file share truyền thống) có thể sử dụng được dữ liệu lưu trong S3 một cách “vô hình”, như thể nó chỉ là một ổ đĩa mạng thông thường? Câu trả lời là AWS Storage Gateway.
Trước khi đi vào Storage Gateway, hãy nhìn lại các lựa chọn lưu trữ “cloud-native” của AWS, phân theo loại:
- BLOCK (khối): Amazon EBS, EC2 Instance Store.
- FILE (file/hệ thống file): Amazon EFS.
- OBJECT (đối tượng): Amazon S3, S3 Glacier.
AWS Storage Gateway chính là “cây cầu” nối giữa dữ liệu on-premise và dữ liệu trên cloud (trong S3). Đây là một dịch vụ hybrid storage cho phép hạ tầng on-premise sử dụng AWS Cloud một cách liền mạch (seamlessly), như thể S3 chỉ là một phần mở rộng tự nhiên của hệ thống lưu trữ hiện có.
Use case của Storage Gateway: disaster recovery, backup & restore, và tiered storage (lưu trữ theo tầng — dữ liệu nóng ở on-premise, dữ liệu lạnh tự động đẩy lên cloud). Storage Gateway có 3 loại chính: File Gateway, Volume Gateway, và Tape Gateway — với kỳ thi Cloud Practitioner, bạn chỉ cần biết Storage Gateway TỒN TẠI và mục đích của nó là gì, không cần nắm chi tiết kỹ thuật của từng loại.
Tổng kết chương
Phần tiêu đề “Tổng kết chương”- Bucket vs Object: Bucket cần tên duy nhất toàn cầu, được tạo tại một region cụ thể; Object có Key (đường dẫn), Value, Metadata, Tags, và Version ID.
- Bảo mật S3: kết hợp IAM Policy (user-based) và Bucket Policy/ACL (resource-based); dùng Bucket Policy để public bucket, ép mã hóa, hoặc cấp quyền cross-account; luôn cân nhắc Block Public Access.
- S3 Website: lưu trữ website tĩnh trực tiếp trên S3, lỗi 403 thường do thiếu quyền đọc công khai.
- Versioning: giữ nhiều phiên bản của file, chống xóa/ghi đè nhầm, cho phép rollback; là điều kiện bắt buộc để dùng Replication.
- Replication (CRR/SRR): sao chép bất đồng bộ giữa bucket khác region (CRR) hoặc cùng region (SRR), có thể xuyên account.
- Storage Classes: Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, và 3 loại Glacier (Instant Retrieval, Flexible Retrieval, Deep Archive) — đánh đổi giữa chi phí lưu trữ và tốc độ/chi phí truy xuất; Durability giống nhau (11 số 9), Availability khác nhau.
- Snowball: thiết bị vật lý di chuyển dữ liệu khối lượng lớn vào/ra AWS, và hỗ trợ Edge Computing (chạy EC2/Lambda ngay tại biên) khi không có kết nối Internet tốt.
- Storage Gateway: giải pháp hybrid cloud, mở rộng lưu trữ on-premise lên S3 một cách liền mạch, phục vụ disaster recovery, backup, và tiered storage.