StorageStorage

Part of the Cloud knowledge base — AWS deep dive. Complements DevOps Roadmap.

Tổng quan

Storage trên AWS chia thành ba hình dạng vật lý, và chọn sai hình dạng là một sai lầm bạn cảm nhận mỗi ngày. Object storage (S3) giữ các blob phi cấu trúc được định địa chỉ bằng key qua HTTP — có thể scale vô hạn, rẻ, và là nơi mặc định cho gần như mọi thứ không phải là một đĩa đang sống hay một database. Block storage (EBS) trình bày các đĩa thô cho một EC2 instance duy nhất — volume mà OS và database của bạn nằm trên đó. File storage (EFS, FSx) cung cấp một hệ thống file POSIX hoặc SMB dùng chung mà nhiều máy mount cùng lúc. Quanh những thứ này là backup (AWS Backup), các cầu nối hybrid (Storage Gateway), và câu hỏi luôn hiện diện về chi phí truyền dữ liệu, thứ âm thầm chi phối nhiều hóa đơn.

Trang này đi sâu vào S3 — viên ngọc quý — bao gồm bucket, storage class, lifecycle, versioning, mã hóa, sự phân biệt giữa bucket-policy và IAM, static hosting, và event notification. Sau đó nó bao gồm các loại volume EBS và snapshot, EFS và FSx cho hệ thống file dùng chung, AWS Backup cho bảo vệ dữ liệu tập trung, Storage Gateway cho hybrid, và các bẫy chi phí egress bắt gặp mọi người. Nó kết thúc bằng một bucket policy S3 và cấu hình lifecycle thực hành.

Một cách nhìn hữu ích: chọn storage theo mẫu truy cập, không theo kích thước. Một máy cần một đĩa? EBS. Nhiều máy cần cùng các file? EFS/FSx. Thứ gì đó đọc và ghi blob theo tên qua mạng và không bao giờ cần một hệ thống file? S3 — và gần như luôn là S3. Làm đúng điều này ngay từ đầu tránh được những lần tái kiến trúc đau đớn đến từ việc gắn một hệ thống file lên thứ lẽ ra phải là object storage.

Tại sao các quyết định về storage tích lũy dồn

Storage là nơi trọng lực dữ liệu tích tụ. Một petabyte ở sai storage class tốn gấp 10 lần mức đáng lẽ; một bucket không có lifecycle rule phình mãi mãi; dữ liệu không được mã hóa mặc định trở thành một phát hiện khi audit; và egress mà bạn chưa từng đo biến một data pipeline thành một bất ngờ năm-con-số. Không như compute, bạn không thể chỉ đơn giản chấm dứt storage — dữ liệu chính là mục đích. Các quyết định về class, lifecycle, mã hóa và đường truyền được đưa ra sớm sẽ tiết kiệm tiền thật và các sự cố thật về sau, bởi vì di chuyển dữ liệu ở quy mô lớn thì chậm và đắt.

Kiến thức nền tảng

S3 — Simple Storage Service

S3 là object storage: bạn đặt các object (dữ liệu + metadata, tới 5 TB mỗi cái) vào các bucket (container có tên duy nhất toàn cầu, sống trong một Region), được định địa chỉ bằng một key (tên đầy đủ giống đường dẫn). Không có thư mục — dấu / trong một key chỉ là một ký tự, và khung nhìn “thư mục” là một tiện lợi của console. S3 cung cấp độ bền mười một số chín (99,999999999%) bằng cách lưu dư thừa trên nhiều AZ, và nó scale tới dung lượng gần như không giới hạn mà không cần provisioning.

Storage class đánh đổi chi phí/độ trễ truy xuất với giá lưu trữ. Chọn đúng class cho mỗi object là đòn bẩy chi phí lớn nhất của S3.

Class	Dùng cho	Truy xuất	Chi phí tương đối
S3 Standard	Dữ liệu nóng, truy cập thường xuyên	Tức thì	Mốc cơ sở (giá lưu trữ cao nhất)
S3 Intelligent-Tiering	Mẫu truy cập chưa biết/thay đổi	Tức thì	Tự chuyển giữa các tier; phí giám sát nhỏ
S3 Standard-IA (Infrequent Access)	Dữ liệu ấm truy cập tầm hằng tháng	Tức thì	Lưu trữ rẻ hơn ~40%; phí truy xuất theo GB
S3 One Zone-IA	Dữ liệu ấm có thể tạo lại	Tức thì	Rẻ hơn nữa; một AZ (không chịu lỗi AZ)
S3 Glacier Instant Retrieval	Lưu trữ cần truy cập tức thì	Tức thì (ms)	Lưu trữ rẻ; phí truy xuất cao hơn
S3 Glacier Flexible Retrieval	Lưu trữ, chấp nhận phút-đến-giờ	Phút–12h	Rất rẻ
S3 Glacier Deep Archive	Tuân thủ/lạnh, hiếm khi đọc	12–48h	Lưu trữ rẻ nhất trên AWS

Intelligent-Tiering là mặc định an toàn khi bạn không biết mẫu truy cập — nó tự động chuyển object giữa các tier thường xuyên, không thường xuyên, và lưu trữ dựa trên mức sử dụng thực tế, không có phí truy xuất cho các tier tức thì. Hãy dùng nó và ngừng đoán.

Lifecycle policy tự động hóa việc chuyển class và hết hạn theo rule (prefix, tag, tuổi). Một policy điển hình: giữ log ở Standard trong 30 ngày, chuyển sang Standard-IA ở mốc 30, sang Glacier ở mốc 90, và xóa ở mốc 365. Lifecycle rule là cách bạn giữ chi phí lưu trữ không phình vô hạn — thiếu chúng, dữ liệu lạnh nằm mãi trong Standard đắt đỏ.

Versioning giữ mọi phiên bản của một object (bao gồm cả delete marker) để việc ghi đè và xóa có thể phục hồi. Đây là nền tảng để bảo vệ chống xóa nhầm và ransomware. Kết hợp với MFA Delete (yêu cầu MFA để xóa vĩnh viễn các phiên bản) và Object Lock (WORM — write-once-read-many, cho lưu giữ tuân thủ). Lưu ý: versioning nhân bội storage, nên hãy ghép nó với lifecycle rule cho hết hạn các phiên bản noncurrent cũ.

Mã hóa — S3 mã hóa mọi object mới lúc nghỉ theo mặc định (SSE-S3) kể từ 2023. Các tùy chọn:

• SSE-S3 — key do AWS quản lý, không cần cấu hình, mặc định.
• SSE-KMS — key do KMS quản lý với audit trail, key policy, và xoay vòng; dùng cho dữ liệu nhạy cảm cần kiểm soát truy cập và CloudTrail cho việc dùng key.
• SSE-C — bạn cung cấp key trên mỗi request (hiếm).
• DSSE-KMS — hai lớp cho tuân thủ nghiêm ngặt. Ép buộc mã hóa khi truyền bằng cách từ chối các request không TLS trong bucket policy (aws:SecureTransport = false).

Bucket policy vs IAM policy

Sự phân biệt này làm mọi người bối rối, nên hãy ghim chặt nó: cả hai đều là tài liệu IAM policy, nhưng chúng gắn vào những thứ khác nhau và trả lời những câu hỏi khác nhau.

	IAM policy	Bucket policy
Gắn vào	Một user, group hoặc role (danh tính)	Bucket (tài nguyên)
Trả lời	”Danh tính này có thể làm gì?"	"Ai được truy cập bucket này, và như thế nào?”
Cross-account	Chỉ cấp trong tài khoản của bạn	Có thể cấp quyền cho tài khoản khác / công khai
Tốt nhất cho	Chuẩn “principal nào của tôi chạm được bucket nào”	Chia sẻ cross-account, truy cập công khai/ẩn danh, ép buộc TLS/mã hóa không phụ thuộc tổ chức

Quyền được cấp nếu hoặc một identity policy áp dụng hoặc resource policy cho phép (và không có Deny tường minh hoặc SCP nào chặn). Dùng IAM policy cho trường hợp thông thường (các principal của chính bạn), và bucket policy khi rule là về bản thân bucket — truy cập cross-account, ép buộc TLS toàn diện, hoặc (cẩn thận) đọc công khai cho một static site. Trên cả hai là Block Public Access, một lớp ghi đè ở mức tài khoản/bucket ngăn các cấp quyền công khai bất kể policy — hãy để nó bật ở mọi nơi trừ một số ít bucket công khai có chủ đích.

Access Points và S3 Access Grants là các công cụ mới hơn để quản lý truy cập ở quy mô lớn (các endpoint mạng/policy được đặt tên cho mỗi ứng dụng, và ánh xạ các prefix S3tới các principal IAM/identity-center) — hãy dùng chúng khi một bucket policy duy nhất trở nên cồng kềnh trên nhiều app.

S3 static website hosting

S3 có thể phục vụ một static site (HTML/CSS/JS) trực tiếp: bật static-website hosting, đặt một tài liệu index và error, và các object trở thành trang web. Trong thực tế, hãy đặt CloudFront (CDN) ở phía trước để có HTTPS (endpoint website của S3 chỉ hỗ trợ HTTP), tên miền tùy chỉnh, caching, và chi phí egress thấp hơn, dùng Origin Access Control (OAC) để bucket vẫn riêng tư và chỉ CloudFront đọc được. Mẫu hiện đại là: bucket S3 riêng tư + CloudFront + OAC + chứng chỉ ACM — không bao giờ dùng một bucket công khai phục vụ trực tiếp.

S3 event notifications

S3 có thể phát ra event khi có hành động trên object (s3:ObjectCreated:*, s3:ObjectRemoved:*, và nhiều hơn) để kích hoạt xử lý phía sau:

• Lambda — chạy code khi upload (tạo thumbnail, quét virus, trích xuất metadata).
• SQS — xếp hàng event để xử lý batch đáng tin cậy, tách rời.
• SNS — phát tỏa ra nhiều subscriber.
• EventBridge — lọc, định tuyến và tích hợp phong phú hơn (bật nó và bạn nhận mọi event S3 với rule chi tiết).

Điều này biến S3 thành cửa trước của các pipeline hướng sự kiện — “ai đó vừa upload một file” trở thành một trigger, không phải một lần poll.

Khái niệm chính

EBS — Elastic Block Store

EBS cung cấp các block volume gắn qua mạng cho EC2 — các đĩa mà OS của bạn boot từ đó và database của bạn ghi vào. Một volume sống trong một AZ, gắn vào một instance tại một thời điểm (trừ io2 Multi-Attach), và tồn tại độc lập với vòng đời của instance.

Loại	Class	Tốt nhất cho	Ghi chú
gp3	SSD tổng quát	Mặc định cho hầu hết workload	Cơ sở 3.000 IOPS / 125 MB/s, provision thêm độc lập; rẻ hơn gp2
gp2	SSD tổng quát (cũ hơn)	Legacy	IOPS scale theo kích thước; ưu tiên gp3
io2 / io2 Block Express	SSD IOPS provisioned	Database nhạy độ trễ	Tới 256.000 IOPS, độ bền 99,999%, Multi-Attach
st1	HDD thông lượng	Tuần tự lớn (log, big data)	Rẻ, hướng thông lượng, không dành cho I/O ngẫu nhiên
sc1	HDD lạnh	Hiếm truy cập, ưu tiên chi phí	Block rẻ nhất; thông lượng thấp

gp3 là mặc định — nó tách IOPS/thông lượng khỏi dung lượng (với gp2 bạn phải over-provision kích thước để mua IOPS) và rẻ hơn. Chuyển gp2 → gp3 để có một lợi ích chi phí dễ dàng.

Snapshot là bản backup gia tăng, tại-một-thời-điểm của một volume được lưu trong S3 (đằng sau hậu trường). Chỉ các block thay đổi được lưu sau snapshot đầu tiên, nên chúng tiết kiệm không gian. Dùng chúng để backup, để nhân bản volume, để di chuyển dữ liệu qua AZ/Region (sao chép một snapshot), và để build AMI. Tự động hóa chúng với Data Lifecycle Manager hoặc AWS Backup. Snapshot (và volume) nên được mã hóa — bật mã hóa EBS mặc định trên toàn tài khoản.

EFS và FSx — file storage dùng chung

Khi nhiều instance (hoặc Lambda/container) cần cùng các file cùng lúc, block storage không đáp ứng được — bạn cần một hệ thống file dùng chung.

EFS (Elastic File System) là một hệ thống file NFS co giãn, được quản lý hoàn toàn cho Linux: mount nó từ hàng nghìn instance trên nhiều AZ đồng thời, và nó tự phình ra và co lại mà không cần provisioning. Nó có storage class (Standard, Infrequent Access, Archive) với quản lý lifecycle. Dùng nó cho nội dung dùng chung, thư mục home, persistent volume của container, và các app lift-and-shift mong đợi một hệ thống file POSIX. Đánh đổi: chi phí theo GB và độ trễ cao hơn EBS; không dành cho database IOPS cao chạy một instance.

FSx là một họ các hệ thống file được quản lý cho các hệ sinh thái cụ thể:

• FSx for Windows File Server — SMB, Active Directory, cho workload Windows.
• FSx for Lustre — hệ thống file song song hiệu năng cao cho HPC/ML, tích hợp với S3.
• FSx for NetApp ONTAP — đầy đủ tính năng ONTAP (snapshot, dedup, đa giao thức).
• FSx for OpenZFS — dựa trên ZFS, độ trễ thấp, snapshot.

Chọn EFS cho NFS Linux tổng quát; chọn hương vị FSx phù hợp khi bạn cần Windows/SMB, thông lượng lớp Lustre, hoặc các tính năng của một hệ thống file nhà cung cấp cụ thể.

AWS Backup

AWS Backup tập trung hóa việc backup trên nhiều service — EBS, EFS, RDS, DynamoDB, S3, FSx, EC2, và nhiều hơn — dưới một service dựa trên policy duy nhất. Bạn định nghĩa backup plan (lịch, thời gian giữ, lifecycle sang cold storage), gán tài nguyên theo tag, và có một nơi duy nhất để giám sát, khôi phục và chứng minh tuân thủ. Nó hỗ trợ sao chép cross-Region và cross-account (quan trọng cho DR và để sống sót qua một vụ xâm nhập tài khoản) và Backup Vault Lock (backup bất biến, WORM mà ngay cả admin cũng không thể xóa sớm). Hãy ưu tiên nó hơn các script snapshot tự viết theo từng service — một policy, một audit trail, một console khôi phục.

Storage Gateway

Storage Gateway bắc cầu các ứng dụng on-premises tới storage AWS thông qua một virtual appliance cục bộ:

• S3 File Gateway — trình bày S3 dưới dạng NFS/SMB cho các app on-prem.
• Volume Gateway — các block volume iSCSI được hậu thuẫn bởi snapshot S3.
• Tape Gateway — một thư viện băng ảo thay thế các băng vật lý, được hậu thuẫn bởi Glacier. Dùng nó cho backup hybrid, cloud-bursting, và di chuyển các workload file/backup on-prem lên AWS mà không cần viết lại ứng dụng.

Chi phí truyền dữ liệu và egress

Cái bẫy bắt gặp mọi người: dữ liệu vào AWS thì miễn phí; dữ liệu ra internet thì mất tiền, và nó cộng dồn lên. Các quy tắc chính:

• Vào (ingress) từ internet: miễn phí.
• Ra (egress) ra internet: tính phí theo GB (theo bậc; khoảng $0,05–$0,09/GB, 100 GB/tháng đầu tiên miễn phí trên toàn tài khoản).
• Lưu lượng cross-AZ: tính phí cả hai chiều (~$0,01/GB mỗi chiều) — một chi phí thực cho các app đa AZ nói chuyện nhiều.
• Cross-Region: tính phí, nhiều hơn cross-AZ.
• Cùng AZ, cùng VPC qua private IP: miễn phí.
• S3/DynamoDB qua Gateway VPC Endpoint: miễn phí (tránh phí xử lý dữ liệu của NAT Gateway).
• Egress CloudFront rẻ hơn egress trực tiếp từ S3/EC2, và các lần fetch từ CloudFront về origin trong nội bộ AWS thì miễn phí — thêm một lý do để đặt CDN ở phía trước nội dung.

Hệ quả thực tế: giữ các service nói chuyện nhiều trong một AZ nơi khả năng chịu lỗi cho phép, dùng VPC Gateway Endpoint cho S3/DynamoDB để né chi phí NAT, phục vụ tải xuống qua CloudFront, và theo dõi phí xử lý dữ liệu của NAT Gateway (chúng đo mỗi GB đi qua). Egress là mục chi thầm lặng — hãy mô hình hóa nó trước khi xây các pipeline nặng dữ liệu.

Ví dụ thực hành: S3 bucket policy + lifecycle

Bucket policy — ép buộc TLS và cấp cho một tài khoản khác quyền đọc, trong khi các principal của chính bạn dùng IAM:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-data-bucket",
        "arn:aws:s3:::my-data-bucket/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "AllowPartnerAccountRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::222233334444:root" },
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-data-bucket",
        "arn:aws:s3:::my-data-bucket/shared/*"
      ]
    }
  ]
}

Statement đầu tiên là một Deny toàn diện trên mọi request không TLS — một deny tường minh luôn thắng, nên nó làm cứng cả bucket bất kể identity policy. Statement thứ hai cấp cho tài khoản 2222... quyền đọc chỉ trên prefix shared/; lưu ý các cấp quyền cross-account như thế này yêu cầu một resource (bucket) policy — một IAM policy trong tài khoản của bạn không thể cấp quyền cho principal của người khác.

Cấu hình lifecycle — chuyển log xuống bậc thấp và cho hết hạn, đồng thời dọn dẹp các phiên bản cũ:

{
  "Rules": [
    {
      "ID": "log-tiering-and-expiry",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30,  "StorageClass": "STANDARD_IA" },
        { "Days": 90,  "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    },
    {
      "ID": "expire-old-versions",
      "Filter": {},
      "Status": "Enabled",
      "NoncurrentVersionTransitions": [
        { "NoncurrentDays": 30, "StorageClass": "GLACIER" }
      ],
      "NoncurrentVersionExpiration": { "NoncurrentDays": 90 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Rule đầu tiên chuyển các object logs/ sang Standard-IA ở mốc 30 ngày, Glacier ở mốc 90, và xóa chúng ở mốc một năm — đường cong chi phí mẫu mực cho dữ liệu observability. Rule thứ hai dọn dẹp sau versioning (các phiên bản cũ sang Glacier ở mốc 30 ngày, biến mất ở mốc 90) và hủy các multipart upload bị đình trệ sau 7 ngày, một nguồn phổ biến của storage vô hình bị tính phí. Áp dụng bằng aws s3api put-bucket-lifecycle-configuration --bucket my-data-bucket --lifecycle-configuration file://lifecycle.json.

Best Practices

1. Bật Block Public Access trên toàn tài khoản, và giữ nó bật — bật nó ở mức tài khoản để không bucket nào vô tình công khai được. Chỉ cấp quyền công khai cho một số ít bucket có chủ đích (và ngay cả khi đó cũng ưu tiên CloudFront + OAC). Bucket S3 công khai là loại vi phạm dữ liệu AWS phổ biến nhất.
2. Mã hóa mọi thứ, và ép buộc TLS khi truyền — dựa vào mã hóa mặc định của S3 (SSE-KMS cho dữ liệu nhạy cảm với audit trail), bật mã hóa EBS mặc định trên toàn tài khoản, và từ chối các request không TLS qua bucket policy. Mã hóa lúc nghỉ gần như miễn phí và đóng lại cả một lớp phát hiện.
3. Áp lifecycle policy cho mọi bucket — thiếu chúng, dữ liệu lạnh nằm mãi trong Standard đắt đỏ và các phiên bản cũ tích lũy âm thầm. Chuyển xuống IA/Glacier và cho hết hạn theo lịch; đồng thời hủy các multipart upload chưa hoàn tất, một chi phí ẩn phổ biến.
4. Dùng Intelligent-Tiering khi mẫu truy cập chưa biết — nó tự tối ưu chi phí lưu trữ không có phí truy xuất cho các tier tức thì và không phải đoán. Với dữ liệu rõ ràng nóng hoặc rõ ràng lạnh, chọn class cụ thể; với mọi thứ còn lại, dùng Intelligent-Tiering.
5. Bật versioning trên các bucket quan trọng, ghép với hết hạn lifecycle — versioning là nút undo của bạn chống lại xóa nhầm và ransomware. Thêm MFA Delete hoặc Object Lock cho dữ liệu tuân thủ, và cho hết hạn các phiên bản noncurrent để nó không nhân bội hóa đơn.
6. Ưu tiên IAM policy cho các principal của chính bạn, bucket policy cho các rule ở mức tài nguyên — giữ “role nào của tôi chạm được bucket nào” trong identity policy; để dành bucket policy cho chia sẻ cross-account và ép buộc toàn diện (TLS, mã hóa). Đừng rải logic truy cập ra cả hai mà không có lý do.
7. Đặt CloudFront ở phía trước nội dung tĩnh và tải xuống — không bao giờ phục vụ một website S3 công khai trực tiếp. CloudFront cho HTTPS, tên miền tùy chỉnh, caching, egress rẻ hơn, và (qua OAC) để bucket vẫn riêng tư. Nó vừa an toàn hơn vừa rẻ hơn ở quy mô lớn.
8. Mặc định EBS volume là gp3 và chuyển khỏi gp2 — gp3 tách IOPS/thông lượng khỏi kích thước và rẻ hơn cho cùng hiệu năng. Việc chuyển đổi diễn ra online và là một trong những lợi ích chi phí dễ nhất hiện có.
9. Tự động hóa và mã hóa snapshot; sao chép các snapshot quan trọng qua Region — dùng Data Lifecycle Manager hoặc AWS Backup cho các snapshot theo lịch, được giữ, được mã hóa, và sao chép các backup quan trọng cho DR sang một Region thứ hai và lý tưởng là một tài khoản riêng.
10. Tập trung hóa backup với AWS Backup và khóa vault — một service dựa trên policy trên EBS/EFS/RDS/DynamoDB/S3 thắng các script theo từng service. Dùng Backup Vault Lock (WORM) và sao chép cross-account để một tài khoản bị xâm nhập không thể phá hủy bản khôi phục cuối cùng của bạn.
11. Right-size hình dạng storage theo mẫu truy cập — đĩa của một instance → EBS; nhiều máy chia sẻ file → EFS/FSx; blob theo key qua HTTP → S3. Đừng ép một hệ thống file dùng chung lên thứ lẽ ra phải là object storage, hoặc ngược lại.
12. Dùng VPC Gateway Endpoint cho S3 và DynamoDB — chúng định tuyến lưu lượng riêng tư và miễn phí, tránh cả internet lẫn phí xử lý dữ liệu của NAT Gateway. Với việc truy cập S3 khối lượng lớn từ các private subnet, đây là một khoản tiết kiệm lớn, dễ dàng.
13. Mô hình hóa egress trước khi xây các pipeline nặng dữ liệu — egress internet và truyền cross-AZ/Region là các mục chi thầm lặng, đáng kể. Giữ lưu lượng nói chuyện nhiều trong-AZ nơi khả năng chịu lỗi cho phép, phục vụ qua CloudFront, và theo dõi phí xử lý theo GB của NAT Gateway.
14. Bật S3 access logging hoặc CloudTrail data event trên các bucket nhạy cảm — bạn không thể điều tra một truy cập bạn chưa từng ghi lại. Ghi log các lần đọc/ghi trên dữ liệu được quy định, và giám sát bằng S3 Storage Lens để phát hiện bất thường về chi phí và sử dụng.
15. Dùng S3 event notification để xây các pipeline hướng sự kiện — để các lần upload kích hoạt Lambda/SQS/EventBridge thay vì polling. Nó rẻ hơn, nhanh hơn, và là cách chuẩn mực để xử lý dữ liệu ngay khi nó đáp xuống.
16. Gắn tag cho storage để phân bổ chi phí và tự động hóa lifecycle — tag trên bucket, volume và snapshot điều khiển các báo cáo chi phí, gán backup, và rule dọn dẹp. Storage không gắn tag là không thể quy trách nhiệm và có xu hướng trở thành rác bị bỏ quên, bị tính phí.

Tài liệu tham khảo

• roadmap.sh — DevOps Roadmap
• Amazon S3 Documentation
• S3 Storage Classes
• S3 Lifecycle Configuration
• S3 Versioning
• S3 Encryption
• S3 Bucket Policies vs IAM Policies
• S3 Block Public Access
• Hosting a Static Website on S3
• S3 Event Notifications
• Amazon EBS Documentation
• EBS Volume Types
• Amazon EFS Documentation
• Amazon FSx
• AWS Backup Documentation
• AWS Storage Gateway
• AWS Data Transfer Pricing

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-data-bucket",
        "arn:aws:s3:::my-data-bucket/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "AllowPartnerAccountRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::222233334444:root" },
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-data-bucket",
        "arn:aws:s3:::my-data-bucket/shared/*"
      ]
    }
  ]
}

{
  "Rules": [
    {
      "ID": "log-tiering-and-expiry",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30,  "StorageClass": "STANDARD_IA" },
        { "Days": 90,  "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    },
    {
      "ID": "expire-old-versions",
      "Filter": {},
      "Status": "Enabled",
      "NoncurrentVersionTransitions": [
        { "NoncurrentDays": 30, "StorageClass": "GLACIER" }
      ],
      "NoncurrentVersionExpiration": { "NoncurrentDays": 90 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}