Cùng điểm qua các tính năng khác trong S3, hay dùng trong thực tế cũng như thường xuất hiện trong các kỳ thi chứng chỉ AWS.
Trong bài này:
1. Object Lock
Trong thực tế, một số ngành như tài chính, y tế cần tuân thủ quy định dữ liệu phải một lần ghi, nhiều lần đọc (write once, read many - WORM), tức không thể bị xoá hay thay đổi sau khi được tạo. Object Lock là cơ chế phục vụ yêu cầu này.
Trước đây, Object Lock chỉ có thể được bật khi tạo bucket mới. Từ cuối năm 2023, AWS đã hỗ trợ tính năng này trên các bucket có sẵn, miễn là Versioning đã được bật trong cấu hình của bucket.
Object Lock cung cấp hai phương thức “khoá” object: tự động theo thời hạn (Retention Period) hoặc thủ công (Legal Hold). Lưu ý, hai phương thức này có thể dùng đồng thời, chỉ cần một trong hai còn tác dụng là object vẫn bị “khoá”.
1.1. Retention Period
Theo cách này, người dùng đặt ra thời hạn khoá object, gọi là retention period, theo ngày hoặc năm, áp dụng cho từng phiên bản của object, tức các phiên bản khác nhau của cùng object có thể bị “khoá” trong thời hạn khác nhau.
Có 2 mode:
- Governance: vẫn cho phép một vài người dùng nhất định (có quyền
s3:BypassGovernanceRetentionvà gửi yêu cầu với headerx-amz-bypass-governance-retention:true) thay đổi, xoá object, hoặc thậm chí bỏ cấu hình retention period. - Compliance: chặt chẽ nhất, không ai có thể thay đổi hoặc xoá object trong thời gian khoá, kể cả Root User. Và cũng không thể sửa đổi cấu hình retention period (chẳng hạn như giảm thời gian khoá).
1.2. Legal Hold
Đây là cách thủ công để “khoá” object. Người dùng (với quyền s3:PutObjectLegalHold) đặt Legal Hold lên một phiên bản object, và phiên bản này sẽ bị “khoá” (không ai có thể thay đổi, xoá object) cho đến khi Legal Hold được gỡ bỏ.
Như đã đề cập, Legal Hold hoạt động độc lập với Retention Period.
Ví dụ, giả sử bạn đặt Legal Hold lên một phiên bản object và phiên bản đó cũng được bảo vệ bởi Retention Period. Nếu Retention Period hết hạn, phiên bản object vẫn bị “khoá” bởi Legal Hold cho đến khi một người dùng có quyền s3:PutObjectLegalHold gỡ bỏ nó. Tương tự, nếu gỡ bỏ Legal Hold trong khi Retention Period vẫn còn hiệu lực, phiên bản object vẫn bị “khoá” cho đến khi Retention Period hết hạn.
2. Pre-signed URL
Object được lưu trong S3 mặc định không công khai, muốn truy cập cần có tài khoản AWS và quyền truy cập tương ứng. Có những trường hợp, ta muốn cấp quyền truy cập object trong thời gian ngắn cho một (hoặc nhiều) danh tính không có tài khoản AWS, hoặc tích hợp trong các ứng dụng cho phép người dùng tải về object. Khi đó, việc yêu cầu tạo tài khoản AWS và cấp quyền qua bucket policy sẽ là trở ngại lớn, ảnh hưởng đến trải nghiệm người dùng. Pre-signed URL là giải pháp cho vấn đề này.
Quá trình thường gặp như sau:
- Người dùng (ẩn danh) tương tác với ứng dụng, gửi yêu cầu truy cập object hoặc bucket.
- Ứng dụng có access key của một IAM User có quyền tạo pre-signed URL sẽ gửi yêu cầu đến S3.
- S3 kiểm tra thông tin và quyền của IAM User, trả về pre-signed URL.
- Ứng dụng gửi pre-signed URL cho người dùng.
- Người dùng sử dụng pre-signed URL để tải xuống object hoặc tải dữ liệu lên bucket. Lưu ý, quyền thao tác của người dùng ẩn danh sẽ giống IAM User đã tạo pre-signed URL. Ví dụ, nếu IAM User không có quyền
s3:GetObjectthì sử dụng pre-signed URL sẽ gặp lỗi403 Forbidden error.
Ta không dùng IAM Role để tạo pre-signed URL. Vì IAM Role chỉ cấp thông tin đăng nhập tạm thời (cỡ vài phút), khi hết hạn thì pre-signed URL cũng không thể truy cập được, dù expiration time của pre-signed URL vẫn còn. Thay vào đó, hãy dùng IAM User cho cả người hoặc ứng dụng cần tạo pre-signed URL.
3. Sao chép Dữ liệu S3
AWS hỗ trợ sao chép dữ liệu từ bucket nguồn tới bucket đích ở cùng Region, khác Region, thậm chí khác tài khoản AWS.
Same-Region Replication (SRR) sao chép object sang một S3 bucket cùng Region, hữu ích khi:
- Có nhiều ứng dụng, mỗi ứng dụng lưu log ở một bucket, và cần tổng hợp log vào một bucket duy nhất.
- Cần sao chép dữ liệu trực tiếp giữa môi trường (tài khoản) development và production.
Cross-Region Replication (CRR) sao chép object giữa các bucket S3 ở các Region khác nhau. Thường dùng khi:
-
Cần đáp ứng yêu cầu bảo vệ dữ liệu chặt chẽ: dù S3 mặc định lưu trữ dữ liệu trên tất cả AZ, có khả năng phục hồi Region Resilience, với các doanh nghiệp lớn có yêu cầu bảo vệ dữ liệu cao hơn, có thể dùng CRR để sao chép dữ liệu sang một hoặc nhiều Region khác, tăng khả năng phục hồi lên Global Resilience.
-
Giảm độ trễ: khi phục vụ khách hàng ở các vị trí địa lý khác nhau, có thể giảm độ trễ truy cập object bằng cách đồng bộ dữ liệu ở nhiều Region với CRR hai chiều.
Bất kể là loại sao chép nào, nguyên lý cũng rất đơn giản. Ta chỉ cần tạo replication rule trong S3, trong đó xác định bucket nguồn, bucket đích (cả hai đều cần bật Versioning), và cấu hình một IAM Role có các quyền cần thiết để sao chép object thông qua Permission Policy sau:
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetReplicationConfiguration",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::awscoban-bucket-nguon"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObjectVersionForReplication",
"s3:GetObjectVersionAcl",
"s3:GetObjectVersionTagging"
],
"Resource": [
"arn:aws:s3:::awscoban-bucket-nguon/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ReplicateObject",
"s3:ReplicateDelete",
"s3:ReplicateTags"
],
"Resource": "arn:aws:s3:::awscoban-bucket-dich/*"
}
]
}
IAM Role này cho phép S3 sử dụng để sao chép object, thông qua Trust Policy sau:
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service": [
"s3.amazonaws.com",
"batchoperations.s3.amazonaws.com"
]
},
"Action":"sts:AssumeRole"
}
]
}
Nếu bucket đích ở tài khoản AWS khác, chủ nhân của bucket đích cần tạo một bucket policy cho phép IAM Role trên (của tài khoản nguồn, ví dụ 111122223333) được sao chép object qua. Ví dụ:
{
"Version":"2012-10-17",
"Id": "PolicyForDestinationBucket",
"Statement": [
{
"Sid": "Permissions on objects",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/service-role/IAM-Role-nguon"
},
"Action": [
"s3:ReplicateDelete",
"s3:ReplicateObject"
],
"Resource": "arn:aws:s3:::arn:aws:s3:::awscoban-bucket-dich/*"
},
{
"Sid": "Permissions on bucket",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/service-role/IAM-Role-nguon"
},
"Action": [
"s3:List*",
"s3:GetBucketVersioning",
"s3:PutBucketVersioning"
],
"Resource": "arn:aws:s3:::awscoban-bucket-dich"
}
]
}
Một vài lưu ý:
- Mặc định, khi tạo replication rule, các object tồn tại trước đó sẽ không được sao chép. Tuy nhiên, AWS cho phép dễ dàng thực hiện việc này, chỉ cần đơn giản lựa chọn khi tạo rule trên giao diện S3.
- Việc sao chép có thể là một chiều hoặc hai chiều, hai chiều cần tạo một replication rule ngược.
- Trường hợp sao chép khác tài khoản, dữ liệu sao chép tới bucket đích thuộc sở hữu của tài khoản nguồn. Có thể cấu hình replication rule để chuyển quyền sở hữu cho tài khoản đích. Đọc thêm tại đây.
- Dữ liệu sao chép tới bucket đích sẽ không được mã hoá. Nếu muốn mã hoá cần cấu hình thêm.
- Ở bucket đích, có thể trực tiếp sao chép dữ liệu đến lớp lưu trữ khác (như S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive). Cũng có thể cấu hình Lifecycle nếu muốn.