1. Amazon S3: Dịch vụ Lưu trữ Đối tượng Đơn giản

1.1. S3 là Gì?

• Định nghĩa: Amazon Simple Storage Service (S3) là dịch vụ Lưu trữ Đối tượng (Object Storage) của AWS, cung cấp khả năng lưu trữ và truy xuất dữ liệu gần như vô hạn từ bất kỳ đâu trên Internet.
• Mô hình Lưu trữ: Khác với hệ thống tệp truyền thống (File System) hoặc lưu trữ khối (Block Storage) dùng cho ổ đĩa, S3 quản lý dữ liệu dưới dạng Đối tượng (Object). Mỗi đối tượng bao gồm:
  • Tệp tin (File): Nội dung dữ liệu thực tế.
  • Metadata (Siêu dữ liệu): Thông tin bổ sung về đối tượng (ví dụ: loại nội dung, ngày tạo, quyền truy cập).
  • Khóa định danh (Key): Tên duy nhất để truy cập đối tượng.
• Điểm mạnh Cốt lõi:
  • Tính bền vững (Durability): Cực kỳ cao (99.999999999%).
  • Tính khả dụng (Availability): Cao (99.95% – 99.99%).
  • Khả năng mở rộng (Scalability): Gần như không giới hạn.
  • Bảo mật (Security): Toàn diện với nhiều lớp.

Các Trường hợp Sử dụng Phổ biến (Use Cases)

• Lưu trữ Nền tảng: Lưu trữ ảnh, video, tài liệu, mã nguồn (code) cho các ứng dụng web và di động.
• Lưu trữ Nội dung Tĩnh: Lưu trữ nội dung cho các trang web tĩnh (static website hosting).
• Sao lưu và Phục hồi (Backup & Recovery): Lưu trữ dữ liệu sao lưu, nhật ký (logs) và kho lưu trữ (archive).
• Dữ liệu Phân tích: Lưu trữ dữ liệu lớn (Big Data) và dữ liệu cho các mô hình Machine Learning.

Lưu ý Quan trọng: S3 không thể được sử dụng để chạy hệ điều hành (Operating System) hoặc cơ sở dữ liệu (Database) trực tiếp. Nó là kho lưu trữ đối tượng, không phải ổ đĩa cho máy chủ.

1.2. Khái niệm Cơ bản về S3

a) Buckets (Thùng chứa)

• Chức năng: Là “container” (giống thư mục cấp cao nhất) để chứa các đối tượng (objects).
• Phạm vi: Dữ liệu trong Bucket chỉ tồn tại ở cấp độ Region (Khu vực) mà bạn đã chọn khi tạo Bucket.
• Tên duy nhất toàn cầu (Global Namespace): Tên của một Bucket phải duy nhất trên toàn bộ AWS (ví dụ: my-bucket-abc-123). Điều này là cần thiết vì tên Bucket được ánh xạ ra DNS để tạo URL truy cập.

b) Lưu trữ và Truy cập

• Giới hạn:
  • Lưu trữ: Không giới hạn số lượng Objects.
  • Kích thước Object: Tối đa 5 TB mỗi Object (tệp tin).
• Truy cập qua URL: Bạn có thể truy cập các tệp tin (Objects) qua một URL công khai (nếu được phép truy cập):

https://bucket-name.s3.Region.amazonaws.com/key-name

• • Ví dụ: https://unica.s3.us-east-1.amazonaws.com/book.jpg
• Mã phản hồi API: Khi tải tệp lên (Upload), nếu thành công, API S3 sẽ trả về mã HTTP 200 OK.

1.3. Mô hình Key-Value Store

Mỗi Object trong S3 được lưu trữ theo mô hình Key-Value Store:

Thành phần	Mô tả
Key	Tên đầy đủ của đối tượng (bao gồm cả “đường dẫn” ảo, ví dụ: photos/2025/nhatrang.jpg). Đây là khóa duy nhất.
Value	Dữ liệu/nội dung byte thực tế của tệp tin.
Version ID	Một ID duy nhất cho phép lưu nhiều phiên bản khác nhau của cùng một Key.
Metadata	Thông tin bổ sung (ví dụ: kiểu tệp Content-Type, quyền truy cập, ngày sửa đổi).

1.4. Các Đặc tính Hữu ích của S3

Đặc tính	Mô tả
Tiered Storage (Lớp lưu trữ)	Nhiều lớp lưu trữ được tối ưu hóa cho chi phí và tần suất truy cập khác nhau (ví dụ: S3 Standard cho truy cập thường xuyên, S3 Infrequent Access cho truy cập ít thường xuyên hơn, S3 Glacier cho lưu trữ lâu dài).
Lifecycle Management	Tự động hóa việc quản lý dữ liệu bằng cách chuyển đổi hoặc xóa dữ liệu sau một khoảng thời gian nhất định (ví dụ: Tự động chuyển Object từ Standard sang Glacier sau 30 ngày để tiết kiệm chi phí).
Versioning (Phiên bản)	Cho phép lưu giữ nhiều phiên bản của cùng một Object. Điều này bảo vệ dữ liệu khỏi việc bị ghi đè hoặc xóa nhầm, giúp khôi phục về trạng thái trước đó.

1.5. Bảo mật Dữ liệu trên S3

Bảo mật là ưu tiên hàng đầu của S3, được kiểm soát chặt chẽ thông qua nhiều cơ chế:

• Mã hóa Dữ liệu (Encryption):
  • Có thể bật mã hóa mặc định cho toàn bộ Bucket (tại phía máy chủ Server-Side Encryption hoặc phía máy khách Client-Side Encryption).
  • S3 tích hợp với AWS KMS (Key Management Service) để quản lý khóa mã hóa.
• Kiểm soát Truy cập (Access Control):
  • Block Public Access: Thiết lập mặc định chặn mọi truy cập công cộng vào Bucket, đây là biện pháp bảo mật đầu tiên và quan trọng nhất.
  • Bucket Policies: Các quy tắc dựa trên JSON được áp dụng cho toàn bộ Bucket, cho phép hoặc từ chối hành động từ các tài khoản/người dùng cụ thể.
  • IAM Policies: Các chính sách quản lý quyền (IAM) gắn vào người dùng hoặc vai trò, kiểm soát hành động S3 của họ.
  • Access Control Lists (ACLs): Cơ chế cũ hơn, cấp quyền cho người dùng hoặc nhóm cụ thể trên từng Object (hoặc Bucket).

2. Quản Lý Quyền Truy Cập trong Amazon S3

Trong Amazon Simple Storage Service (S3), có hai cơ chế chính để kiểm soát quyền truy cập vào các bucket và object của bạn: Object Access Control Lists (ACLs) và Bucket Policies. Việc hiểu rõ sự khác biệt giữa hai cơ chế này là rất quan trọng để triển khai bảo mật tối ưu.

2.1. Object Access Control Lists (ACLs)

ACLs là cơ chế kiểm soát truy cập cũ hơn và chi tiết nhất, được áp dụng trực tiếp lên từng object (tệp) cụ thể bên trong một bucket.

• Phạm vi áp dụng: Áp dụng ở cấp độ Object (tệp tin).
• Hoạt động: Cho phép bạn xác định một cách chi tiết Ai (người dùng, tài khoản AWS, hoặc công khai) được phép thực hiện Hành động gì (ví dụ: READ, WRITE, FULL_CONTROL) đối với object đó.
• Trường hợp sử dụng: Thích hợp cho các tình huống cần cấp quyền rất chi tiết cho từng object riêng lẻ, đặc biệt nếu quyền truy cập cho object đó khác với phần còn lại của bucket.
• Lưu ý quan trọng:
  • Mặc dù còn tồn tại, AWS hiện khuyến nghị nên ưu tiên sử dụng Bucket Policies hoặc IAM Policies hơn là ACLs, vì chúng cung cấp khả năng kiểm soát tập trung và linh hoạt hơn.
  • Bạn có thể bật tính năng Bucket Owner Enforced cho S3 Object Ownership để vô hiệu hóa ACLs trên bucket của mình, giúp đơn giản hóa việc quản lý quyền truy cập.

Ví dụ:

• Một tệp hình ảnh được đặt công khai bằng ACL để có thể hiển thị trực tiếp trên một trang web.
• Chỉ định rằng một Tài khoản AWS hoặc Người dùng IAM cụ thể mới có quyền READ (đọc) một tài liệu nhạy cảm trong bucket.

2.2. Bucket Policies

Bucket Policies là cơ chế kiểm soát truy cập mạnh mẽ và linh hoạt nhất, được áp dụng ở cấp độ Bucket (thùng chứa dữ liệu).

• Phạm vi áp dụng: Áp dụng ở cấp độ Bucket (ảnh hưởng đến tất cả các object bên trong nó, trừ khi được chỉ định khác).
• Hoạt động: Được viết dưới định dạng JSON (Policy Document), cho phép bạn định nghĩa các quy tắc phức tạp, có điều kiện về quyền truy cập.
• Các thành phần chính của Policy:
  • Effect (Allow/Deny): Kết quả của policy.
  • Principal (Ai): Người, dịch vụ, hoặc tài khoản được cấp/từ chối quyền.
  • Action (Làm gì): Các thao tác S3 cụ thể (ví dụ: s3:GetObject, s3:PutObject).
  • Resource (Đối tượng nào): Bucket và/hoặc Object mà policy áp dụng.
• Trường hợp sử dụng: Lý tưởng để định nghĩa quyền truy cập thống nhất cho toàn bộ bucket hoặc cho một nhóm lớn các object. Nó giúp dễ quản lý hơn nhiều so với việc cấu hình ACLs cho hàng nghìn object.

Ví dụ:

• Giới hạn tất cả các hành động truy cập vào bucket chỉ từ một Amazon VPC Endpoint hoặc một dải địa chỉ IP cụ thể (sử dụng khối Condition).
• Cho phép một Nhóm người dùng IAM (IAM Group) hoặc một IAM Role cụ thể có quyền s3:PutObject (tải lên tệp) vào bucket.

2.3. Tóm tắt và Điểm mấu chốt

Đặc điểm	Object ACLs	Bucket Policies
Phạm vi	Từng Object riêng lẻ	Toàn bộ Bucket
Định dạng	Giao diện cơ bản (được xác định trước)	Tài liệu JSON linh hoạt
Tính linh hoạt	Hạn chế, chỉ cấp quyền cơ bản	Rất cao, hỗ trợ điều kiện (IP, thời gian, nguồn)
Khuyến nghị AWS	Nên tránh, ưu tiên cơ chế khác	Cơ chế được khuyến nghị hàng đầu
Hiểu nôm na	Ổ khóa trên từng cánh cửa (file)	Nội quy của cả tòa nhà (bucket)

Mẹo quan trọng:

• Quyền truy cập vào một object là sự kết hợp của nhiều chính sách (Bucket Policies, IAM Policies, và Object ACLs). Khi có sự xung đột về quyền, quy tắc Từ chối (Deny) luôn được ưu tiên hơn Cho phép (Allow).
• Đối với hầu hết các trường hợp sử dụng hiện đại, hãy cố gắng quản lý quyền truy cập thông qua IAM Policies (áp dụng cho người dùng/role) và Bucket Policies (áp dụng cho bucket), và vô hiệu hóa ACLs nếu có thể.

Tại sao khi tôi disable “Block all public access” nhưng tôi vẫn không thể truy cập được vào file từ trình duyệt?

Khi bạn disable “Block all public access”, điều đó chỉ cho phép bucket và object có thể được public nếu bạn cấu hình thêm. Nó không tự động biến bucket hay object thành public.

Để file trong S3 thực sự public và có thể truy cập bằng link, bạn có thể dùng một trong số những cách sau đây:

• Bạn cần thêm Bucket Policy cho phép s3:GetObject với Principal: *.
• Hoặc bật Object ACL và cấp quyền Read cho Everyone (nhưng ACL hiện nay ít dùng, AWS khuyến nghị Bucket Policy).

3. Triển Khai Website Tĩnh với Amazon S3

AWS Simple Storage Service (S3) là một dịch vụ lưu trữ đối tượng (Object Storage) cung cấp giải pháp mạnh mẽ và hiệu quả về chi phí để triển khai các website tĩnh (Static Websites).

3.1. Khái Niệm Cơ Bản

• Website Tĩnh: Là các trang web mà nội dung của chúng là cố định và được xây dựng bằng các ngôn ngữ phía client như HTML, CSS, và JavaScript. Không có xử lý backend phức tạp trên máy chủ.
• Cách thức hoạt động của S3: S3 có thể được cấu hình để hoạt động như một máy chủ web tĩnh bằng cách lưu trữ các tệp (objects) của bạn (HTML, hình ảnh, video, v.v.) và cho phép truy cập chúng thông qua HTTP tại một URL công cộng.

3.2. Lưu Ý Quan Trọng: S3 KHÔNG Phù Hợp cho Website Động

Loại Website	Đặc điểm	Dịch vụ AWS Thay thế
Website Tĩnh	Nội dung cố định, chỉ cần HTML/CSS/JS.	S3 Static Website Hosting
Website Động	Cần xử lý logic phía máy chủ (backend), kết nối cơ sở dữ liệu (Database), xử lý biểu mẫu (form processing), hoặc chạy các ngôn ngữ như PHP, Python, Node.js, Java.	Amazon EC2, AWS Lambda kết hợp API Gateway, Amazon ECS/EKS (Containerization).

• Trường hợp sử dụng TỐT NHẤT cho S3:
  • Landing Pages, Trang Giới Thiệu Công ty.
  • Blog cá nhân (với các nền tảng tạo site tĩnh như Jekyll, Hugo).
  • Ứng dụng Web Đơn trang (Single Page Applications – SPAs) được xây dựng bằng các framework như React, Vue, Angular – nơi tệp build cuối cùng chỉ là HTML/CSS/JS và gọi API từ một dịch vụ backend riêng biệt.
  • Trang tài liệu hoặc các trang hỗ trợ.

3.3. Khả Năng Tự Động Mở Rộng (Automatic Scaling)

Một lợi thế cạnh tranh lớn nhất của S3 là khả năng tự động mở rộng (auto-scaling) vô hạn, giúp nó trở thành một lựa chọn lý tưởng cho các ứng dụng web cần độ sẵn sàng cao và khả năng chịu tải lớn.

• Khả năng chịu tải (Elasticity): S3 được thiết kế để xử lý mọi lượng truy cập một cách tự động, từ 10 người dùng đến hàng triệu người dùng cùng lúc.
• Bạn KHÔNG CẦN: Quản lý máy chủ web, cân bằng tải (Load Balancer), hoặc lo lắng về việc cấu hình tài nguyên khi lưu lượng truy cập tăng đột biến (Viral Traffic).
• Trường hợp ứng dụng:
  • Phân phối nội dung số: Lưu trữ video khóa học, hình ảnh chất lượng cao, tài liệu, hoặc tệp lớn cho hàng trăm nghìn người dùng.
  • Sử dụng với Amazon CloudFront: Để tăng tốc độ truy cập toàn cầu và giảm độ trễ, các bucket S3 hosting website tĩnh thường được đặt sau Amazon CloudFront (một dịch vụ Mạng Phân phối Nội dung – CDN của AWS). CloudFront sẽ cache nội dung S3 tại các điểm hiện diện (Edge Locations) gần người dùng nhất.

3.4. Mẹo Quan Trọng & Cảnh Báo Chi phí

• Bảo mật: Đảm bảo rằng bạn cấu hình Quyền truy cập công cộng (Public Access) một cách chính xác để cho phép người dùng xem trang web của bạn. Tuy nhiên, hãy luôn tuân theo nguyên tắc Ít đặc quyền nhất (Least Privilege).
• Chi phí: Chi phí S3 chủ yếu dựa trên:
  • Lưu trữ (Storage): Dung lượng dữ liệu bạn lưu trữ.
  • Yêu cầu (Requests): Số lượng yêu cầu GET (đọc) và PUT (ghi) vào bucket của bạn.
  • Truyền dữ liệu (Data Transfer Out): Lưu lượng dữ liệu truyền ra khỏi AWS (dữ liệu truyền vào/trong cùng khu vực thường miễn phí).
• Tên Miền Tùy chỉnh (Custom Domain): Bạn có thể dễ dàng liên kết website tĩnh trên S3 với tên miền riêng của mình (ví dụ: www.mydomain.com) bằng cách sử dụng Amazon Route 53 (Dịch vụ DNS của AWS).

4. Amazon S3 Versioning: Bảo Vệ Dữ Liệu và Lịch Sử Thay Đổi

4.1. Versioning trong S3 là gì?

Versioning là một tính năng mạnh mẽ của Amazon S3 cho phép bạn lưu trữ nhiều phiên bản (version) của cùng một object (tức là tệp tin) trong một bucket S3.

• Mục đích cốt lõi: Ngăn chặn việc mất dữ liệu do xóa nhầm hoặc ghi đè ngoài ý muốn.
• Cơ chế hoạt động: Khi Versioning được bật:
  • Mỗi lần bạn ghi đè (overwrite) một object, S3 sẽ tạo ra một phiên bản mới và giữ lại phiên bản cũ.
  • Mỗi lần bạn xóa một object, S3 sẽ không xóa vật lý object đó mà thay vào đó sẽ thêm một Delete Marker (Dấu xóa) như một phiên bản mới nhất.

Ví dụ: Bạn có file report.docx. Lần đầu tải lên là Version 1. Khi bạn cập nhật file và tải lên lại, S3 sẽ lưu file mới là Version 2 và vẫn giữ nguyên Version 1 để bạn có thể khôi phục bất cứ lúc nào.

4.2. Lợi ích Chính của S3 Versioning

Lợi ích	Mô tả
Bảo vệ Dữ liệu (Backup)	Dễ dàng khôi phục dữ liệu đã bị xóa nhầm hoặc ghi đè. Hoạt động như một cơ chế undo cho mọi hành động.
Lịch sử Thay đổi Hoàn chỉnh	Lưu trữ toàn bộ lịch sử thay đổi của object, giúp theo dõi và quay lại các trạng thái trước đó.
Quản lý Vòng đời (Lifecycle Management)	Có thể kết hợp với S3 Lifecycle Rules để tự động chuyển các phiên bản không phải mới nhất (Noncurrent Versions) sang các Storage Class rẻ hơn (như S3 Glacier Flexible Retrieval) hoặc tự động xóa chúng sau một khoảng thời gian.
Bảo mật Tăng cường với MFA Delete	Cung cấp tùy chọn MFA Delete, yêu cầu xác thực Multi-Factor Authentication từ thiết bị AWS MFA để xóa vĩnh viễn object hoặc thay đổi trạng thái Versioning, tăng cường bảo mật chống lại việc xóa trái phép.

Lưu ý Quan trọng: Khi đã bật Versioning cho một bucket, bạn không thể tắt hoàn toàn nó được, chỉ có thể đặt nó ở trạng thái Suspended (Tạm dừng). Khi ở trạng thái Suspended, các object mới sẽ không có ID phiên bản (hoặc có ID phiên bản là null), nhưng các phiên bản cũ đã tồn tại vẫn được giữ lại.

4.3. Truy cập và Quản lý Quyền đối với Object Versions

Để cho phép người dùng hoặc công chúng truy cập vào các phiên bản cụ thể của object, bạn cần hiểu rõ về các quyền truy cập S3.

Vấn đề Thường gặp (AccessDenied)

• Policy chỉ cấp quyền s3:GetObject (cho phiên bản mới nhất – latest version).
• Khi người dùng cố gắng truy cập một phiên bản cũ bằng cách chỉ định versionId trong yêu cầu, IAM/Bucket Policy sẽ kiểm tra quyền cụ thể để truy cập phiên bản đó.
• Nếu không có quyền s3:GetObjectVersion, yêu cầu sẽ bị từ chối (Access Denied).

Giải pháp: Điều chỉnh Policy

• Để cho phép truy cập vào tất cả các phiên bản của object (kể cả phiên bản mới nhất và phiên bản cũ), bạn cần đảm bảo rằng Bucket Policy hoặc IAM Policy của người dùng bao gồm quyền s3:GetObjectVersion.

Bucket Policy Mẫu (Cho phép public đọc mọi phiên bản):

{

  “Version“: “2012-10-17”,

  “Statement“: [

    {

      “Effect“: “Allow”,

      “Principal“: “*”,

      “Action“: [“s3:GetObject”, “s3:GetObjectVersion”],

      “Resource“: [

        “arn:aws:s3:::your-bucket/*”

      ]

    }

  ]

}

Mẹo về ACLs: Việc sử dụng ACLs (Access Control Lists) để cấp quyền public (Make public using ACL) cũng là một cách để khôi phục hoặc cấp quyền cho các phiên bản cũ, đặc biệt nếu Object Ownership của bucket được đặt là ACLs enabled. Tuy nhiên, AWS khuyến khích sử dụng Bucket Policies hoặc IAM Policies cho hầu hết các trường hợp quản lý quyền hiện đại.

4.4. Xóa Object với Versioning

Cơ chế xóa object trong bucket đã bật Versioning khác với xóa thông thường:

4.4.1. Xóa Mềm (Soft Delete) – Xóa qua Console/SDK mà không chỉ định Version ID

• Khi bạn xóa object (ở chế độ không hiển thị phiên bản hoặc xóa thông thường), S3 sẽ tạo một phiên bản mới gọi là Delete Marker.
• Object thực tế (các Version 1, Version 2,…) vẫn còn nguyên.
• Khôi phục: Bạn có thể khôi phục object bằng cách xóa phiên bản Delete Marker này. Khi Delete Marker bị xóa, phiên bản gần nhất (latest non-delete marker version) sẽ tự động trở thành phiên bản hiện tại (latest version).

4.4.2. Xóa Vĩnh viễn (Hard Delete) – Xóa bằng cách chỉ định Version ID

• Khi bạn ở trạng thái hiển thị các phiên bản (Show versions) và xóa một phiên bản cụ thể (kể cả Delete Marker) bằng cách chỉ định Version ID của nó, phiên bản đó sẽ bị xóa vĩnh viễn khỏi S3.
• Chỉ những ai có quyền s3:DeleteObjectVersion mới có thể thực hiện thao tác này.

5. S3 Storage Classes

Amazon S3 cung cấp nhiều lớp lưu trữ khác nhau, được thiết kế để tối ưu hóa chi phí và hiệu suất cho các nhu cầu truy cập dữ liệu khác nhau (thường xuyên, không thường xuyên, lưu trữ dài hạn).

5.1. S3 Standard (S3 Tiêu chuẩn)

Đây là lớp lưu trữ mặc định và được thiết kế cho dữ liệu được truy cập thường xuyên.

• Đặc điểm:
  • Tính khả dụng (Availability): 99.99% (Dịch vụ cam kết khả dụng)
  • Độ bền (Durability): 99.999999999% (11 số 9) – Gần như không thể mất dữ liệu.
  • Vị trí lưu trữ: Dữ liệu được lưu trữ dự phòng trên nhiều thiết bị ở ít nhất 3 Vùng sẵn sàng (Availability Zones – AZs).
  • Hiệu suất: Truy xuất dữ liệu với độ trễ tính bằng mili giây.
• Trường hợp sử dụng tốt nhất:
  • Trang web tĩnh (Static websites) và phân phối nội dung.
  • Dữ liệu ứng dụng di động, chơi game.
  • Big Data Analytics.

5.2. S3 Standard-Infrequent Access (S3 Standard-IA)

Lớp lưu trữ dành cho dữ liệu ít được truy cập (Infrequent Access) nhưng vẫn yêu cầu khả năng truy xuất nhanh chóng (tính bằng mili giây) khi cần.

• Chi phí:
  • Chi phí lưu trữ thấp hơn S3 Standard.
  • Có phí truy xuất dữ liệu (Retrieval Fee) – Lưu ý quan trọng: Điều này làm cho nó không phù hợp với dữ liệu truy cập thường xuyên.
  • Yêu cầu thời gian lưu trữ tối thiểu: 30 ngày.
• Đặc điểm & Tính năng: Giống hệt S3 Standard về độ bền (11 số 9) và khả năng lưu trữ tại ≥ 3 AZs.
• Trường hợp sử dụng tốt nhất:
  • Sao lưu dài hạn (Long-term Backups).
  • Lưu trữ dữ liệu phục hồi sau thảm họa (Disaster Recovery).

5.3. S3 One Zone-Infrequent Access (S3 One Zone-IA)

Lớp lưu trữ dành cho dữ liệu ít truy cập, chi phí thấp nhất trong nhóm truy cập nhanh, nhưng chỉ lưu trữ tại 1 AZ duy nhất.

• Rủi ro: Do chỉ lưu trữ trong một AZ, dữ liệu có thể bị mất trong trường hợp AZ đó gặp sự cố (ví dụ: mất điện trên diện rộng, hỏa hoạn, thiên tai).
• Chi phí: Rẻ hơn S3 Standard-IA. Có phí truy xuất dữ liệu.
  • Yêu cầu thời gian lưu trữ tối thiểu: 30 ngày.
• Trường hợp sử dụng tốt nhất:
  • Dữ liệu ít truy cập mà bạn có thể dễ dàng tạo lại (ví dụ: bản sao thứ cấp của dữ liệu đã được lưu ở nơi khác, dữ liệu được mã hóa từ nguồn).

5.4. S3 Intelligent-Tiering (S3-IT)

Lớp lưu trữ tự động tối ưu hóa chi phí bằng cách di chuyển dữ liệu giữa các tầng truy cập (Tier) dựa trên hành vi truy cập thực tế của từng đối tượng.

• Hoạt động:
  • Tầng Truy cập Thường xuyên (Frequent Access Tier): Tương đương với S3 Standard.
  • Tầng Truy cập Không thường xuyên (Infrequent Access Tier): Tương đương với S3 Standard-IA.
  • Tầng Lưu trữ Lạnh (Archive Instant Access/Glacier tiers): Có thể tự động chuyển xuống các tầng Glacier sau 90/180 ngày không truy cập.
• Tự động hóa: AWS S3 sẽ tự động giám sát và chuyển đối tượng giữa các tầng mà không cần người dùng đặt Lifecycle Rules thủ công.
• Chi phí:
  • Chi phí lưu trữ theo tầng (Standard hoặc Standard-IA/Glacier).
  • Có phí quản lý nhỏ hàng tháng ($0.0025 / 1,000 objects) để chi trả cho việc theo dõi và tự động hóa.
  • Yêu cầu thời gian lưu trữ tối thiểu: 30 ngày.
• Trường hợp sử dụng tốt nhất:
  • Dữ liệu không thể dự đoán tần suất truy cập hoặc tần suất truy cập thay đổi theo thời gian (ví dụ: Logs, dữ liệu ứng dụng mới).

5.5. S3 Glacier Options (Các Lớp Lưu trữ Lạnh)

Các lớp lưu trữ này được thiết kế cho lưu trữ dữ liệu cực kỳ dài hạn (Archive) với chi phí thấp nhất, đổi lại là thời gian truy xuất chậm hơn.

Lớp Lưu trữ	Mục đích sử dụng	Thời gian truy xuất dữ liệu	Thời gian lưu trữ tối thiểu
Glacier Instant Retrieval (Glacier IR)	Lưu trữ dài hạn, cần truy xuất tức thì (mili giây).	Mili giây	90 ngày
Glacier Flexible Retrieval (Glacier FR)	Sao lưu, phục hồi thảm họa. Cần truy xuất linh hoạt (miễn phí hoặc nhanh).	3 phút – 12 giờ	90 ngày
Glacier Deep Archive (Glacier DA)	Lưu trữ rẻ nhất, dùng cho các yêu cầu tuân thủ (7-10 năm+).	12 – 48 giờ	180 ngày

• Đặc điểm chung:
  • Chi phí lưu trữ cực thấp.
  • Luôn có phí truy xuất dữ liệu (Retrieval Fee) và thời gian lưu trữ tối thiểu để tránh bị phạt phí (pro-rated charge) nếu xóa sớm.
  • Độ bền 99.999999999% (11 số 9) và lưu trữ tại ≥ 3 AZs.

5.6. So sánh Hiệu suất và Thuộc tính Chính

Thuộc tính	S3 Standard	Intelligent-Tiering	Standard-IA	One Zone-IA	Glacier IR	Glacier FR	Glacier DA
Độ bền	99.99…% (11 số 9)	99.99…% (11 số 9)	99.99…% (11 số 9)	99.99…% (11 số 9)	99.99…% (11 số 9)	99.99…% (11 số 9)	99.99…% (11 số 9)
Tính khả dụng (AZs)	≥ 3 AZs	≥ 3 AZs	≥ 3 AZs	1 AZ	≥ 3 AZs	≥ 3 AZs	≥ 3 AZs
Thời gian truy xuất	Mili giây	Mili giây	Mili giây	Mili giây	Mili giây	Phút – Giờ	Giờ
Tối thiểu lưu trữ	Không	30 ngày	30 ngày	30 ngày	90 ngày	90 ngày	180 ngày
Phí truy xuất	Không	Không	Có	Có	Có	Có	Có
Tự động chuyển tiếp (Lifecycle)	✅	✅	✅	✅	✅	✅	✅

Lưu ý quan trọng về Chi phí:

• Các mức giá tham khảo theo tầng dung lượng (ví dụ: 0.023/GB cho 50TB đầu tiên của S3 Standard) chỉ mang tính minh họa và có thể thay đổi. Luôn kiểm tra trang giá chính thức của AWS (AWS Pricing Page) để có số liệu chính xác.
• Glacier Instant Retrieval thực tế đắt hơn các lớp Glacier khác vì nó cung cấp tốc độ truy xuất nhanh nhất (mili giây).
• Glacier Deep Archive là lớp rẻ nhất cho lưu trữ dài hạn.

6. Quản lý Vòng Đời Dữ liệu S3 (S3 Lifecycle Management)

Quản lý Vòng đời Dữ liệu Amazon S3 (S3 Lifecycle Management) là tính năng giúp bạn tự động hóa việc quản lý chi phí lưu trữ bằng cách chuyển các đối tượng (Object) sang các lớp lưu trữ (Storage Class) rẻ hơn hoặc xóa chúng đi theo một lịch trình định trước.

Điều này thay thế cho việc quản lý thủ công, đảm bảo bạn chỉ trả chi phí cao cho dữ liệu “nóng” (thường xuyên truy cập) và tối ưu chi phí cho dữ liệu “nguội” (ít truy cập).

6.1. Chu kỳ Chuyển đổi Lớp Lưu trữ (Transition)

Lifecycle Management cho phép bạn thiết lập các quy tắc (Rules) để tự động chuyển đổi đối tượng giữa các lớp lưu trữ theo thời gian.

Giai đoạn Dữ liệu	Lớp Lưu trữ Đề xuất	Ví dụ Về Quy tắc Chuyển đổi (Transition)
Thường xuyên truy cập (Hot)	S3 Standard	Dữ liệu được tạo và sử dụng trong 30 ngày đầu tiên.
Ít truy cập (Cool)	S3 Standard-IA (Infrequent Access)	Sau 30 ngày, dữ liệu ít cần truy cập ngay lập tức hơn.
Lưu trữ dài hạn/Lưu trữ lạnh (Cold)	S3 Glacier hoặc S3 Glacier Deep Archive	Sau 90 ngày, dữ liệu chỉ cần lưu trữ để tuân thủ quy định hoặc dự phòng.

• Lưu ý quan trọng: Việc chuyển đổi sang S3 Standard-IA và các lớp Glacier cần tuân thủ thời gian lưu trữ tối thiểu (ví dụ: 30 ngày cho Standard-IA, 90 ngày cho Glacier). Nếu bạn xóa hoặc chuyển đổi đối tượng trước thời hạn này, bạn sẽ bị tính phí cho thời gian lưu trữ tối thiểu đó.

6.2. Quản lý Vòng đời với S3 Versioning

Khi bạn bật Versioning (Quản lý phiên bản) trên một S3 Bucket, mỗi lần bạn cập nhật, xóa, hoặc ghi đè một tệp, một phiên bản đối tượng mới (Current Version) sẽ được tạo, trong khi phiên bản trước đó trở thành Phiên bản không phải hiện tại (Noncurrent Version).

Nếu không quản lý, việc này có thể dẫn đến tăng chi phí nhanh chóng do có nhiều bản sao lưu trữ.

• S3 Lifecycle giúp quản lý Versioning bằng cách:
  • Tự động chuyển các phiên bản cũ (Noncurrent Versions) sang các lớp lưu trữ rẻ hơn (Standard-IA, Glacier) sau một số ngày nhất định.
  • Tự động xóa vĩnh viễn các phiên bản cũ sau một khoảng thời gian quy định, tránh lãng phí dung lượng.
• Trường hợp sử dụng: Rất hữu ích cho việc lưu trữ logs hoặc file cấu hình thay đổi liên tục, nơi bạn cần duy trì lịch sử các phiên bản trong một thời gian.

6.3. Quy tắc Vòng đời (Lifecycle Rules)

Để áp dụng các hành động quản lý vòng đời, bạn cần thiết lập các Quy tắc (Rules).

6.3.1. Phạm vi Quy tắc (Rule Scope)

Bạn có thể giới hạn Rule áp dụng cho một tập hợp đối tượng cụ thể bằng cách sử dụng Bộ lọc (Filters):

• Toàn bộ Bucket: Áp dụng cho tất cả đối tượng trong Bucket.
• Bộ lọc (Filters): Chỉ áp dụng cho một nhóm đối tượng:
  • Prefix: Áp dụng cho đối tượng có một tiền tố cụ thể (ví dụ: chỉ áp dụng cho các tệp trong thư mục ảo /logs/ hoặc /backup/).
  • Tag: Áp dụng cho đối tượng có một cặp key-value tag cụ thể (ví dụ: chỉ cho object có tag env=dev).

6.3.2. Các Hành động Chính (Actions)

Một Lifecycle Rule bao gồm hai loại hành động chính dựa trên số ngày trôi qua kể từ khi đối tượng được tạo hoặc trở thành phiên bản không phải hiện tại:

Hành động	Mô tả	Ứng dụng
Transition (Chuyển đổi)	Tự động chuyển đối tượng sang một lớp lưu trữ khác (ví dụ: Standard → Standard-IA → Glacier).	Giảm chi phí lưu trữ.
Expiration (Hết hạn)	Tự động xóa đối tượng.	Dọn dẹp dữ liệu không còn cần thiết.

 

Chi tiết Hành động	Đối tượng Áp dụng
Move current versions…	Chuyển phiên bản hiện tại (Current Version) sang lớp lưu trữ khác (Standard-IA, Glacier).
Expire current versions…	Tự động xóa phiên bản hiện tại (Current Version) sau X ngày.
Move noncurrent versions…	Chuyển các phiên bản cũ (Noncurrent Versions) sang lớp lưu trữ rẻ hơn (Standard-IA, Glacier).
Permanently delete noncurrent versions…	Xóa vĩnh viễn các phiên bản cũ (Noncurrent Versions) sau Y ngày.
Delete expired object delete markers…	Loại bỏ Delete Marker hết hạn (chỉ liên quan khi dùng Versioning).
Abort incomplete multipart uploads	Tự động hủy bỏ các lần tải lên tệp lớn (Multipart Upload) bị dừng hoặc dang dở sau Z ngày.

• Cảnh báo Chi phí: Luôn xem xét Chi phí truy cập (retrieval cost) của các lớp lưu trữ như Glacier khi đặt quy tắc Transition.

7. Mã Hóa Dữ Liệu trong Amazon S3 (Amazon S3 Encryption)

7. 1. Các Loại Mã Hóa Dữ Liệu Chính

Trong AWS, việc bảo vệ dữ liệu được thực hiện ở hai trạng thái: Trong Quá trình Truyền tải (In Transit) và Khi Ở Trạng thái Nghỉ (At Rest).

7.1.1. Mã Hóa Trong Quá Trình Truyền Tải (Encryption in Transit)

• Mục đích: Bảo vệ dữ liệu khi nó di chuyển giữa ứng dụng (client) và các dịch vụ AWS (như S3).
• Cơ chế Thường dùng:
  • SSL/TLS (Secure Sockets Layer / Transport Layer Security): Đây là các giao thức mật mã đảm bảo rằng dữ liệu được gửi qua internet không bị can thiệp và chỉ có người nhận dự kiến mới có thể giải mã.
  • HTTPS: Sử dụng HTTP trên nền TLS/SSL.
• Khuyến nghị: Luôn sử dụng HTTPS để giao tiếp với các API của AWS, bao gồm cả S3.

7.1.2. Mã Hóa Khi Ở Trạng Thái Nghỉ (Encryption at Rest)

• Mục đích: Bảo vệ dữ liệu đã được lưu trữ vĩnh viễn trong S3 (trong các ổ đĩa của AWS). Có hai cách tiếp cận chính:

Phương Pháp	Mô Tả	Ai Quản Lý Khóa?	Trường Hợp Sử Dụng
a. Mã Hóa Phía Máy Chủ (Server-Side Encryption – SSE)	Dữ liệu được mã hóa bởi AWS S3 ngay khi nó được nhận và được giải mã khi được truy xuất.	AWS/AWS KMS	Phổ biến nhất, dễ triển khai.
b. Mã Hóa Phía Khách Hàng (Client-Side Encryption)	Dữ liệu được mã hóa bởi người dùng trước khi được gửi đến S3.	Người dùng	Yêu cầu kiểm soát khóa tối đa.

7.2. Chi Tiết về Mã Hóa Phía Máy Chủ (Server-Side Encryption – SSE)

Đây là các tùy chọn mã hóa được thực hiện và quản lý bởi AWS:

• SSE-S3:
  • Cơ chế: AWS S3 quản lý hoàn toàn các khóa mã hóa.
  • Thuật toán: Sử dụng AES-256 (Advanced Encryption Standard, khóa 256-bit).
  • Đặc điểm: S3 tự động tạo, sử dụng và luân chuyển (rotate) các khóa mã hóa cho bạn. Đây là tùy chọn dễ dàng nhất để sử dụng.
• SSE-KMS (Key Management Service):
  • Cơ chế: AWS S3 sử dụng AWS KMS để quản lý các khóa mã hóa.
  • Đặc điểm: Cung cấp khả năng kiểm soát chi tiết hơn so với SSE-S3. Người dùng có thể:
    • Theo dõi (Audit): Xem ai đã sử dụng khóa của bạn và khi nào thông qua AWS CloudTrail.
    • Quản lý (Rotation): Tự động luân chuyển khóa theo yêu cầu.
    • Kiểm soát Truy cập: Quản lý quyền truy cập sử dụng chính sách KMS Key (Key Policy).
• SSE-C (Customer-Provided Keys):
  • Cơ chế: Người dùng tự cung cấp khóa mã hóa cho AWS S3 trong mỗi request.
  • Đặc điểm: AWS thực hiện việc mã hóa/giải mã, nhưng khóa được cung cấp bởi người dùng. AWS không lưu trữ khóa này vĩnh viễn; nó chỉ được sử dụng trong quá trình mã hóa hoặc giải mã và ngay lập tức bị loại bỏ khỏi bộ nhớ.

7.3. Chi Tiết về Mã Hóa Phía Khách Hàng (Client-Side Encryption)

• Cơ chế: Người dùng tự mã hóa object (ví dụ: dùng GPG, hoặc AWS Encryption SDK) trên máy tính/server của mình trước khi upload file lên S3.
• Đặc điểm: AWS S3 nhận file đã mã hóa và không có cách nào giải mã nó.
• Trường hợp sử dụng tốt nhất: Khi bạn có yêu cầu pháp lý hoặc quy định nghiêm ngặt không cho phép bất kỳ ai, kể cả AWS, tiếp cận khóa mã hóa của bạn.

7.4. Bắt Buộc Sử Dụng Server-Side Encryption (Enforcing SSE)

Để đảm bảo tất cả dữ liệu trong một bucket S3 luôn được mã hóa theo một tiêu chuẩn cụ thể, bạn nên thực hiện các biện pháp sau:

Cấu Hình Mặc Định (Default Encryption)

• Khuyến nghị Hiện đại: Ngày nay, bạn có thể bật Mã hóa Mặc định cho S3 Bucket (Default Encryption). Khi bật, S3 sẽ tự động áp dụng phương pháp mã hóa (ví dụ: SSE-S3 hoặc SSE-KMS) cho bất kỳ object mới nào được upload, ngay cả khi client không gửi header mã hóa.

Sử Dụng Bucket Policy (Chính Sách Bucket)

Để đảm bảo tuân thủ nghiêm ngặt hơn (đặc biệt trong các thiết lập cũ hoặc để yêu cầu một loại mã hóa cụ thể như SSE-KMS), bạn có thể sử dụng Chính sách Bucket (Bucket Policy).

• Mục tiêu: Từ chối mọi request s3:PutObject (upload) không bao gồm header mã hóa SSE bắt buộc.
• Cơ chế: Chính sách sẽ kiểm tra sự hiện diện của các header sau:
  • “x-amz-server-side-encryption”: “AES256” (cho SSE-S3)
  • “x-amz-server-side-encryption”: “aws:kms” (cho SSE-KMS)
• Lợi ích: Đảm bảo tính nhất quán về mã hóa cho mọi file trong bucket.

7.5. Lưu Ý Quan Trọng (Kiến thức cho Kỳ thi & Thực tế)

• Trạng thái Mặc định Hiện tại: Kể từ tháng 1 năm 2023, AWS S3 đã tự động bật tính năng Mã hóa Mặc định (SSE-S3) cho tất cả các bucket mới. Điều này có nghĩa là mọi object mới được upload sẽ được mã hóa bằng SSE-S3, trừ khi bạn chỉ định mã hóa khác.
• Trạng thái Mặc định trong Kỳ thi: Trong các bài thi chứng chỉ AWS (ví dụ: AWS Certified Solutions Architect Associate), hãy cẩn thận đọc câu hỏi vì chúng đôi khi vẫn giả định rằng mã hóa mặc định chưa được bật và yêu cầu bạn cấu hình nó hoặc sử dụng Bucket Policy để bắt buộc mã hóa.

8. S3 Performance Optimization

8.1. Prefixes trong S3: Tổ chức và Khả năng Mở rộng

Khái niệm:

• Trong Amazon S3, Prefix đóng vai trò tương tự như “đường dẫn thư mục” trong hệ thống tệp truyền thống.
• AWS sử dụng Prefix để tổ chức dữ liệu bên trong Bucket và quan trọng hơn là để định tuyến (route) các yêu cầu (requests).

Vị trí Tệp (File Location)	Prefix Tương ứng
bucket1/folder1/subfolder1/file1.jpg	folder1/subfolder1/
bucket1/folder1/file1.jpg	folder1/

Tác động đến Hiệu suất:

• Prefix có thể được xem là các “nhóm” logic của các đối tượng (Objects).
• Khả năng mở rộng (Scalability) của S3 được tận dụng tốt nhất khi bạn phân phối tải (load) yêu cầu trên nhiều Prefix. AWS có thể song song hóa các yêu cầu được định tuyến đến các Prefix khác nhau, từ đó tăng thông lượng tổng thể.

8.2. Giới hạn Hiệu suất Mặc định của S3

AWS S3 là một dịch vụ được thiết kế cho độ trễ (latency) thấp và khả năng xử lý yêu cầu (request throughput) cực cao.

• Độ trễ thấp: Thời gian tải xuống byte đầu tiên (Time to First Byte) thường chỉ mất ~100–200 ms.
• Giới hạn Yêu cầu trên mỗi Prefix (Request Limit per Prefix):
  • Yêu cầu Ghi (Write Operations): 3.500 yêu cầu PUT/COPY/POST/DELETE mỗi giây
  • Yêu cầu Đọc (Read Operations): 5.500 yêu cầu GET/HEAD mỗi giây

Tăng Thông lượng (Increasing Throughput):

• Để vượt qua giới hạn này, bạn cần phân tán (distribute) các đối tượng của mình trên nhiều Prefix khác nhau.
• Ví dụ: Sử dụng 4 Prefix khác nhau có thể tăng gấp 4 lần thông lượng tổng thể, lên đến ~22.000 yêu cầu GET/HEAD mỗi giây.

💡 Mẹo Tối ưu: Đối với các ứng dụng có yêu cầu thông lượng cực cao, hãy sử dụng các giá trị băm (hash values) hoặc ID ngẫu nhiên làm phần đầu của tên khóa (Key Name) để đảm bảo các đối tượng mới được phân tán đồng đều trên nhiều Prefix.

8.3. Lưu ý khi sử dụng Mã hóa S3 với KMS (SSE-KMS)

Khi bạn chọn sử dụng Mã hóa phía máy chủ với AWS KMS (SSE-KMS), cần lưu ý đến sự tương tác giữa S3 và dịch vụ KMS (Key Management Service).

Luồng hoạt động KMS:

1. Tải lên (Upload): S3 gọi API KMS: GenerateDataKey để lấy khóa dữ liệu (Data Key) dùng để mã hóa Object.
2. Tải xuống (Download): S3 gọi API KMS: Decrypt để giải mã Khóa Dữ liệu đã được mã hóa, từ đó giải mã Object.

Hạn chế Quan trọng (KMS Throttling):

• Mỗi thao tác Upload và Download đều tạo ra một yêu cầu API KMS.
• Các yêu cầu này bị tính vào Hạn mức Tỷ lệ KMS (KMS Rate Quota), vốn có giới hạn mặc định (ví dụ: 5.500, 10.000, 30.000 yêu cầu/giây tùy khu vực).
• CẢNH BÁO: Hạn mức tỷ lệ KMS thường KHÔNG thể được yêu cầu tăng thêm (Hard Limit).

Giải pháp cho Workload Lớn:

• Nếu ứng dụng của bạn có workload quá lớn (rất nhiều yêu cầu Upload/Download) và bị nghẽn (throttled) do vượt quá hạn mức KMS, bạn nên cân nhắc chuyển sang sử dụng:
  • SSE-S3 (S3-Managed Keys): Mã hóa phía máy chủ với khóa do AWS S3 quản lý. SSE-S3 KHÔNG bị ràng buộc bởi hạn mức KMS, cung cấp hiệu suất cao hơn cho các tác vụ khối lượng lớn.

8.4. Tối ưu Hóa Hiệu suất Tải lên (Upload Performance)

Đối với các tệp lớn (thường là > 100 MB), hãy luôn sử dụng Tải lên Đa phần (Multipart Upload).

• Cách hoạt động: Chia tệp lớn thành nhiều phần nhỏ (parts) và tải từng phần đó lên song song.
• Lợi ích:
  • Tăng tốc độ tải lên tổng thể.
  • Giảm rủi ro: Nếu một phần bị lỗi, bạn chỉ cần tải lại phần đó, không cần phải tải lại toàn bộ tệp từ đầu.

8.5. Tối ưu Hóa Hiệu suất Tải xuống (Download Performance)

Để tối ưu hóa việc tải xuống, bạn có thể sử dụng Yêu cầu theo Phạm vi (Range Request) (hoặc Byte-Range Fetches).

• Cách hoạt động: Chỉ định một phạm vi byte cụ thể (ví dụ: 0–128 KB, 128–256 KB) trong yêu cầu GET thay vì tải toàn bộ đối tượng.
• Lợi ích:
  • Tăng tốc độ download nhờ khả năng tải song song các đoạn khác nhau của tệp.
  • Khả năng phục hồi: Nếu một đoạn bị lỗi trong quá trình tải, chỉ cần yêu cầu tải lại đoạn đó.
  • Tải xuống một phần: Có thể dùng để truy xuất chỉ một phần dữ liệu của đối tượng, ví dụ:
    • Tải về phần đầu (header) của một tệp video để xem metadata.
    • Tải về một đoạn log cụ thể trong một tệp log lớn.

9. S3 Replication

S3 Replication là một tính năng mạnh mẽ cho phép bạn tự động và đồng bộ hóa việc sao chép các đối tượng (object) giữa các Amazon S3 bucket. Nó là một cơ chế thiết yếu để tăng cường tính bền vững (durability), hỗ trợ phục hồi thảm họa (disaster recovery), và đáp ứng các yêu cầu về tuân thủ (compliance).

9.1. Khái niệm và Mục đích

• Định nghĩa: Replication là quá trình sao chép các đối tượng được tạo hoặc cập nhật trong một bucket nguồn (source bucket) sang một bucket đích (destination bucket), có thể nằm trong cùng một Khu vực AWS (Same-Region Replication – SRR) hoặc một Khu vực AWS khác (Cross-Region Replication – CRR).
• Mục tiêu chính: Đảm bảo có bản sao dữ liệu của bạn ở vị trí khác nhau gần như thời gian thực để tăng cường tính sẵn sàng và tính bền vững.

9.2. Các Điều kiện Tiên quyết

Để cấu hình S3 Replication, các điều kiện sau đây là bắt buộc:

• Kích hoạt Versioning (Quản lý phiên bản): Cả bucket nguồn và bucket đích phải được kích hoạt Versioning. Replication hoạt động bằng cách sao chép các phiên bản đối tượng.
• Thiết lập IAM Role: Cần có một IAM Role với các quyền thích hợp cho phép S3 thực hiện hành động s3:GetObject từ bucket nguồn và s3:ReplicateObject, s3:ReplicateDelete… sang bucket đích.

9.3. Hành vi Sao chép Đối tượng

1. Các Đối tượng được Sao chép

• Chỉ các Đối tượng mới: Theo mặc định, S3 Replication chỉ sao chép các đối tượng được tạo mới hoặc cập nhật SAU KHI quy tắc replication được thiết lập và kích hoạt.
• Không tự động sao chép Đối tượng cũ (Backfill): Các đối tượng đã tồn tại trong bucket nguồn trước khi thiết lập quy tắc sẽ không tự động được sao chép.
  • 💡 Cải chính: Khi bạn thiết lập quy tắc replication lần đầu, S3 KHÔNG tự động sao chép dữ liệu cũ. Để sao chép các đối tượng đã tồn tại, bạn cần sử dụng tính năng S3 Batch Replication.
• Khi ta thiết lập replication lần đầu, sẽ có một lần cho phép ta copy các object đã tồn tại từ trước

2. Sao chép Thao tác Xóa (Delete Marker)

Đây là một điểm quan trọng cần lưu ý:

Hành động trên Bucket Nguồn	Có được Replication mặc định không?	Giải thích
Tải lên đối tượng mới	CÓ	Đối tượng được tạo và sao chép.
Xóa một Version cụ thể của đối tượng	KHÔNG	Version đó bị xóa ở nguồn, nhưng không ảnh hưởng đến bucket đích.
Xóa đối tượng bằng Delete Marker (Xóa phiên bản hiện tại)	KHÔNG	Delete Marker được thêm vào ở nguồn, nhưng không mặc định được sao chép sang đích. Bucket đích vẫn giữ lại đối tượng.

• Mẹo quan trọng: Để sao chép cả việc xóa đối tượng (Delete Marker), bạn phải bật thêm tùy chọn “Replica delete markers” trong cấu hình quy tắc replication.

9.4. Các Trường hợp Sử dụng Thực tế (Best Use Cases)

Trường hợp Sử dụng	Loại Replication	Lợi ích
Phục hồi Thảm họa (Disaster Recovery)	Cross-Region Replication (CRR)	Sao chép dữ liệu sang một Khu vực khác. Nếu Khu vực chính gặp sự cố, dữ liệu vẫn sẵn có.
Tuân thủ (Compliance)	CRR hoặc SRR	Yêu cầu lưu trữ bản sao dữ liệu ở khoảng cách địa lý tối thiểu hoặc lưu trữ trong một bucket thuộc một tài khoản (Account) khác.
Giảm độ trễ (Latency)	CRR	Sao chép dữ liệu gần hơn với người dùng ở các vị trí địa lý khác nhau để truy cập nhanh hơn.
Bảo vệ Dữ liệu	Same-Region Replication (SRR)	Sao chép dữ liệu sang một bucket khác tài khoản AWS ( khác Account) để tạo một bản sao “Miễn dịch” trước các lỗi cấu hình hoặc các cuộc tấn công xóa dữ liệu trong tài khoản nguồn.

9.5. Tùy chọn Cấu hình Nâng cao

• Phạm vi sao chép (Scope): Bạn có thể chọn chỉ sao chép:
  • Tất cả các đối tượng (All objects).
  • Các đối tượng khớp với một Prefix (ví dụ: chỉ sao chép các tệp trong thư mục /photos/).
  • Các đối tượng khớp với một hoặc nhiều Tags cụ thể.
• Replication Time Control (RTC): Một tùy chọn đảm bảo 99.99% các đối tượng được replication trong vòng 15 phút, hữu ích cho các trường hợp cần tuân thủ thời gian phục hồi nghiêm ngặt.

Cảnh báo Chi phí: Bạn sẽ phải trả phí GET request trên bucket nguồn và phí PUT request trên bucket đích cho các đối tượng được sao chép. Với CRR, bạn cũng phải trả phí Data Transfer Out (phí truyền dữ liệu ra khỏi Khu vực) từ bucket nguồn.