GĐ31 — AWS SAA: Storage, Databases, Cache và Analytics

Mục tiêu: bắt đầu từ access pattern, durability, latency và recovery; sau đó chọn data store. Kiến thức SQL/transaction ở GĐ05 và backup ở GĐ14 vẫn áp dụng trên AWS.

Kiểm chứng ngày 2026-10-05 (đọc tài liệu AWS; lệnh CLI chỉ kiểm cờ bằng aws ... help và --generate-cli-skeleton, chưa chạy trên AWS; phép tính RCU/WCU và EBS chạy bằng script Node, kết quả khớp các số trong bài): loại EBS, gp2 và gp3, RCU/WCU, chế độ provisioned, Aurora cluster, Aurora endpoint, mã hóa RDS, Block Public Access, Object Ownership, mã hóa mặc định S3, lifecycle. Các mục viết từ trước giữ nguồn riêng ở cuối mỗi mục.

1. Object, block, file và ephemeral storage#

Ví dụ tự xây: nhiều app đọc PDF → S3; nhiều Linux process cần mount shared directory → EFS; Windows app cần SMB → FSx for Windows File Server; scratch có thể mất khi instance bị thay → instance store.

Nguồn: EC2 storage, EBS, EFS, FSx, storage overview.

2. S3: quyền, consistency, versioning và replication#

S3 dùng bucket/key và object metadata. Với general purpose buckets, đọc sau PUT/overwrite và LIST có strong consistency; cache CDN/client và replication xuyên Region vẫn có hành vi riêng. Không giải thích mọi stale read bằng “S3 eventual consistency”.

Giữ Block Public Access và chọn quyền qua policy/role. Presigned URL là quyền tạm theo signer cho operation cụ thể; không thay auth tenant ở API. SSE-S3 và SSE-KMS có mô hình quản key/quyền khác nhau.

Versioning giữ version cũ; delete thường tạo delete marker thay xóa hết versions. Lifecycle cần xét current/noncurrent versions. Replication sao chép theo cấu hình, thường bất đồng bộ; kiểm tra versioning, permissions, object cũ và delete behavior. Object Lock dùng retention/legal hold cho WORM khi có yêu cầu, không bật chỉ để “cho an toàn” trong lab cần xóa.

Nguồn: S3 overview, versioning, replication, Object Lock.

Mặc định của bucket mới và cách kiểm#

Bốn thiết lập Block Public Access là BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets; áp dụng được ở cấp bucket, access point, account và organization, và S3 lấy tổ hợp chặt nhất giữa các cấp (Block Public Access). Block Public Access không sửa policy hay ACL có sẵn; gỡ nó ra thì policy công khai có hiệu lực trở lại. Đừng giả định mặc định cho bucket tạo bằng CLI hay IaC: kiểm trực tiếp (đã kiểm cờ bằng CLI help; chưa chạy trên AWS; tên bucket là ví dụ):

aws s3api get-public-access-block --bucket my-bucketaws s3api get-bucket-ownership-controls --bucket my-bucketaws s3api get-bucket-encryption --bucket my-bucket

Kết quả get-public-access-block đúng mong đợi cho bucket riêng tư là cả bốn khóa BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets đều true. Lệnh này chỉ phản ánh cấp bucket; cấp account kiểm bằng aws s3control get-public-access-block --account-id 111122223333 (đã kiểm cờ bằng CLI help).

3. S3 storage classes: chọn theo tần suất và thời gian lấy lại#

Lifecycle transition không phải xóa dữ liệu. Archive có thể giảm tiền GB-tháng nhưng tăng retrieval/restore và early deletion cost. Không viết “Glacier luôn phải chờ hàng giờ”: Instant Retrieval khác Flexible/Deep Archive.

Nguồn: S3 classes, lifecycle, pricing. Đọc minimum duration/size và giá theo Region trước khi tính.

Lifecycle bằng JSON cho bucket có versioning#

Ví dụ cho prefix logs/ (số ngày là ví dụ, chọn theo yêu cầu lưu trữ). Ràng buộc từ trang transitions: một rule không được chuyển object sang class khác trước khi hết minimum storage duration của class hiện tại; ví dụ Glacier Instant Retrieval có minimum 90 ngày, nên nếu chuyển sang GIR ở ngày 4 thì chuyển tiếp sang Deep Archive phải từ ngày 94 trở đi. Rule thứ nhất chuyển version hiện tại sang Glacier Instant Retrieval, hết hạn version hiện tại, xóa version cũ sau 30 ngày noncurrent, và dọn upload dở. Ví dụ cố ý không dùng NewerNoncurrentVersions (xem câu hỏi lifecycle cuối stage để biết lý do). Rule thứ hai dọn delete marker không còn version nào đứng sau. Cấu trúc đã kiểm bằng --generate-cli-skeleton; chưa chạy trên AWS:

{  "Rules": [    {      "ID": "logs-tiering",      "Status": "Enabled",      "Filter": { "Prefix": "logs/" },      "Transitions": [{ "Days": 90, "StorageClass": "GLACIER_IR" }],      "Expiration": { "Days": 365 },      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }    },    {      "ID": "clean-delete-markers",      "Status": "Enabled",      "Filter": { "Prefix": "logs/" },      "Expiration": { "ExpiredObjectDeleteMarker": true }    }  ]}

aws s3api put-bucket-lifecycle-configuration \  --bucket my-logs-bucket --lifecycle-configuration file://lifecycle.json

Điểm cần nhớ theo lifecycle elements: ở bucket bật versioning, Expiration của version hiện tại chỉ thêm delete marker và không xóa dữ liệu; NoncurrentVersionExpiration mới xóa vĩnh viễn version cũ (không khôi phục được); NewerNoncurrentVersions (1 đến 100) bắt buộc đi kèm Filter; AbortIncompleteMultipartUpload và ExpiredObjectDeleteMarker không dùng được trong rule có filter theo tag. Object nhỏ hơn 128 KB mặc định không chuyển class nào; thêm ObjectSizeGreaterThan nếu muốn. Lifecycle chạy bất đồng bộ, nên ngày chuyển thực tế có thể trễ.

4. Hiệu năng storage và đường truyền file#

EBS: phân biệt IOPS với throughput và latency; workload nhiều I/O nhỏ khác scan file lớn. General purpose SSD và provisioned IOPS SSD phục vụ nhu cầu khác nhau. Giới hạn volume và EC2 instance cùng ảnh hưởng kết quả; tăng IOPS khi app thiếu CPU không chữa được bottleneck.

EFS: xem throughput mode, số client và pattern metadata/small files. Shared filesystem giảm nhu cầu đồng bộ file bằng tay nhưng không loại lock/contention.

S3: multipart upload cho file lớn, parallel transfer có kiểm soát, lifecycle dọn incomplete multipart uploads. Transfer Acceleration có thể giúp đường upload xa bằng edge path; CloudFront chủ yếu dùng phân phối/cache nội dung. Benchmark đường truyền thật trước khi thêm dịch vụ tăng phí.

Nguồn: EBS volume types, EFS performance, multipart upload, Transfer Acceleration.

Loại EBS: chọn theo IOPS, throughput và boot#

Số liệu đọc ngày 2026-10-05 từ EBS volume types:

Tín hiệu chọn: IOPS cao cho giao dịch nhỏ thì SSD; throughput lớn tuần tự và rẻ thì st1/sc1 (không dùng làm boot volume); cần trên 80.000 IOPS hoặc 2.000 MiB/s, độ trễ dưới mili giây ổn định thì io2 Block Express (mốc "hơn 16.000 IOPS" là use case của io1; loại EBS). Dung lượng gp2 gắn IOPS: 6.000 IOPS cần 2.000 GiB, còn gp3 chỉ cần cấp IOPS (general purpose). Tạo volume gp3 và đổi gp2 sang gp3 không cần dừng instance (đã kiểm cờ bằng CLI help; chưa chạy trên AWS; ID và AZ là ví dụ):

aws ec2 create-volume --availability-zone us-east-1a \  --volume-type gp3 --size 500 --iops 6000 --throughput 250 --encryptedaws ec2 modify-volume --volume-id vol-0123456789abcdef0 \  --volume-type gp3 --iops 6000 --throughput 250

5. RDS và Aurora: quan hệ, HA và scale đọc#

Không học quy tắc “mọi Multi-AZ đều không đọc được standby”: cần phân biệt DB instance với DB cluster. Replica không chữa truy vấn thiếu index và cũng không thay backup. App cần reconnect sau failover; DNS endpoint không giữ nguyên TCP connection cũ.

Aurora reader endpoint phân phối kết nối tới readers, không phải route từng SQL statement. Aurora Serverless v2 tự điều chỉnh capacity trong phạm vi cấu hình; không được suy ra mọi version/config đều scale về zero.

Nguồn: RDS Multi-AZ, read replicas, Aurora HA, Aurora endpoints, Serverless v2.

Aurora: storage dùng chung, endpoint và I/O#

Cluster volume của Aurora là một volume ảo có bản sao dữ liệu ở ba AZ trong Region; mức sao chép độc lập với số DB instance. Mỗi cluster có một writer và tối đa 15 Aurora Replica đọc cùng volume, nên thêm replica không phải copy dữ liệu. Khi writer hỏng, Aurora failover sang một replica (bạn đặt được thứ tự ưu tiên). Ngay cả cluster chỉ có một instance vẫn có storage ở nhiều AZ (Aurora DB clusters, Aurora storage). Endpoint (Aurora endpoints):

Về chi phí I/O: Aurora Standard tính thêm phí theo số request I/O; Aurora I/O-Optimized không tính phí I/O đọc/ghi và hợp khi chi phí I/O từ 25% tổng chi phí Aurora trở lên (theo tài liệu Aurora storage). Đây là quy tắc chọn, giá cụ thể xem trang pricing.

Mã hóa RDS: chỉ chọn được lúc tạo#

Mã hóa dùng KMS key và áp dụng cho storage, log, automated backup, read replica và snapshot. Chỉ bật được khi tạo instance (--storage-encrypted, thêm --kms-key-id nếu dùng customer managed key); không tắt được sau đó. Muốn mã hóa instance đang chạy: snapshot, copy snapshot có --kms-key-id, restore từ bản đã mã hóa, rồi chuyển ứng dụng sang endpoint mới. Không có replica mã hóa của instance không mã hóa (và ngược lại). Đã kiểm cờ bằng CLI help; chưa chạy trên AWS (tên và key là ví dụ):

aws rds create-db-snapshot \  --db-instance-identifier mydb --db-snapshot-identifier mydb-plainaws rds copy-db-snapshot \  --source-db-snapshot-identifier mydb-plain \  --target-db-snapshot-identifier mydb-enc \  --kms-key-id alias/rds-prodaws rds restore-db-instance-from-db-snapshot \  --db-instance-identifier mydb-new --db-snapshot-identifier mydb-encaws rds describe-db-instances --db-instance-identifier mydb-new \  --query "DBInstances[].StorageEncrypted"

Nguồn: mã hóa RDS. Disable KMS key thì instance chuyển sang trạng thái không truy cập được, nên quản lý vòng đời key cẩn thận (xem GĐ29 mục 3).

6. Connection pool, RDS Proxy và backup#

Ví dụ tự xây: 100 container × pool tối đa 20 = tới 2.000 kết nối, chưa tính workers/admin. Scale app có thể làm DB hết connection trước khi CPU app cao. Giới hạn pool theo tổng capacity, đặt timeout và đo connections thực.

RDS Proxy hỗ trợ pooling và khả năng kết nối/failover cho database hỗ trợ; không tăng tốc mọi query hoặc loại bỏ connection pinning. Cần kiểm tra engine, transaction/session behavior và phí proxy.

Automated backup/PITR phục hồi đến thời điểm trong retention hỗ trợ; snapshot giữ một bản tại thời điểm chụp. Restore tạo tài nguyên cần kiểm tra network, secret, endpoint và dữ liệu. AWS Backup tập trung policy/vault/restore cho tài nguyên được hỗ trợ, không tự chứng minh RTO.

Nguồn: RDS Proxy, RDS backups, AWS Backup.

7. DynamoDB: thiết kế từ access pattern#

DynamoDB phù hợp key-value/document access với partition key và optional sort key. Viết trước các truy vấn: “lấy job theo ID”, “liệt kê job của user theo thời gian”; thiết kế key/index đáp ứng chúng. Scan toàn bảng không phải mặc định để tìm dữ liệu ở scale lớn.

Table/LSI hỗ trợ strongly consistent reads; GSI/streams không hỗ trợ strong reads. Global Tables có MREC và MRSC với khả năng/Region/giới hạn khác nhau; không học “global tables luôn eventual” như quy tắc bất biến. Chọn mode theo yêu cầu và kiểm tra docs hiện tại.

DAX là cache dành cho DynamoDB, khác Redis cache tổng quát; xét read consistency và pattern trước khi dùng. TTL không thay kiểm tra expiresAt khi trả dữ liệu nhạy thời hạn.

Nguồn: DynamoDB core components, read consistency, Global Tables, TTL, DAX.

RCU và WCU tính bằng tay#

Chế độ provisioned tính tiền theo capacity bạn cấp mỗi giờ, không theo phần đã dùng. Quy tắc (read/write operations, provisioned mode):

Query cộng kích thước mọi item trả về rồi mới làm tròn lên 4 KB; BatchGetItem làm tròn từng item rồi mới cộng. Scan tính theo item được quét, không theo item trả về. Chọn danh sách thuộc tính (projection) không giảm RCU. Ví dụ (tính bằng script Node calc-31.mjs, chạy ngày 2026-10-05; output khớp từng số dưới đây):

• Ghi 50 item mỗi giây, mỗi item 3,2 KB: làm tròn lên 4 KB nên 4 WCU mỗi lần, tổng 200 WCU.
• Đọc GetItem 80 lần mỗi giây, item 3 KB, eventually consistent: 3 KB làm tròn lên 4 KB nên 1 đơn vị đầy đủ, một nửa là 0,5, tổng 40 RCU. Cùng tải đó strongly consistent là 80 RCU.
• Query trả 25 item, mỗi item 1,2 KB: tổng 30 KB làm tròn lên 32 KB, tức 8 RCU strongly consistent hoặc 4 RCU eventually consistent. Nếu tính từng item riêng như BatchGetItem sẽ là 25 RCU, nên nhóm item cùng partition key vào một Query rẻ hơn.

DynamoDB auto scaling đặt giới hạn dưới, giới hạn trên và target utilization; tài liệu khuyến nghị 70%. Tạo bảng provisioned (đã kiểm cờ bằng CLI help; chưa chạy trên AWS):

aws dynamodb create-table --table-name Jobs \  --attribute-definitions AttributeName=jobId,AttributeType=S \  --key-schema AttributeName=jobId,KeyType=HASH \  --billing-mode PROVISIONED \  --provisioned-throughput ReadCapacityUnits=400,WriteCapacityUnits=360

8. ElastiCache và cache correctness#

ElastiCache cung cấp cache managed với engine được hỗ trợ như Valkey/Redis OSS/Memcached. Chọn theo cấu trúc dữ liệu, persistence/replication, HA và cách vận hành; không coi mọi engine đều có cùng khả năng.

Ví dụ cache-aside tự xây: đọc cache → miss thì đọc DB → ghi cache có TTL. Update DB cần chiến lược invalidate/update; thêm jitter cho TTL và giới hạn request đồng thời để tránh stampede. Cache key phải chứa tenant/user context nếu dữ liệu phụ thuộc quyền.

Cache có thể stale hoặc bị eviction. Không dùng cache làm bản duy nhất của billing; cache hit không bỏ qua authorization. Multi-AZ cache vẫn cần app xử lý reconnect và cache miss khi failover.

Nguồn: ElastiCache, caching strategies.

9. Analytics, search và ingestion: phân biệt OLTP/OLAP#

OLTP phục vụ transaction nhỏ cho app; OLAP phục vụ phân tích/tổng hợp. Không chuyển billing transaction sang Redshift chỉ vì dữ liệu lớn. Với Athena, partition theo truy vấn và format cột như Parquet giúp giảm dữ liệu scan. Index search thường là derived data; nguồn dữ liệu chính phải có quy trình rebuild index.

Pipeline tự xây: events → stream/delivery → S3 → Glue catalog/ETL → Athena hoặc Redshift → BI. Theo dõi lag, failed delivery, schema change, duplicate và replay; “có pipeline” chưa chứng minh dữ liệu đúng.

Nguồn: Analytics overview, Athena, Glue, Redshift.

10. Tự kiểm tra#

• Chọn object/block/file storage cho bốn workload.

  Đáp án

  (a) Nhiều app đọc PDF qua API, cần bền và rẻ: S3 (object, truy cập bằng API, không mount như disk). (b) Ổ đĩa cho database tự cài trên EC2: EBS (block, gắn một AZ). (c) Nhiều instance Linux cùng mount một thư mục: EFS (NFS dùng chung). (d) Ứng dụng Windows cần SMB: FSx for Windows File Server. Scratch có thể tái tạo: instance store, mất khi instance bị thay. Sai thường gặp: dùng S3 làm disk POSIX; dùng EBS làm "shared folder" (volume thuộc AZ, multi-attach chỉ ở vài cấu hình). Xem mục 1.

• Giải thích versioning, replication và backup khác nhau.

  Đáp án

  Versioning: giữ nhiều phiên bản của cùng một object trong cùng bucket; delete thường chỉ thêm delete marker. Replication: sao chép bất đồng bộ sang bucket khác (cùng hoặc khác Region), live replication chỉ áp dụng cho object mới, object có sẵn cần Batch Replication; S3 RTC mới có cam kết 15 phút cho 99,99% object mới. Backup: bản độc lập, có chính sách giữ và quy trình restore. Replication cần bật versioning ở cả bucket nguồn và đích. Ghi đè nhầm được replicate sang bản sao. Delete marker mặc định không replicate với cấu hình dùng Filter (chỉ replicate khi bật delete marker replication; cấu hình V1 không có Filter thì có), còn xóa vĩnh viễn theo version ID không bao giờ replicate; dù vậy replication vẫn không thay backup (lỗi ghi đè và dữ liệu hỏng đều sang bản sao); versioning không bảo vệ khi xóa cả bucket hay lộ credential. Xem mục 2.

• Chọn archive class theo retrieval time và chi phí đọc.

  Đáp án

  Cần	Chọn	Điểm phân biệt (theo AWS)
  Ít đọc, cần mili giây	Glacier Instant Retrieval	Tối thiểu 90 ngày, có phí retrieval theo GB
  Chấp nhận chờ phút đến giờ	Glacier Flexible Retrieval	Tối thiểu 90 ngày; Expedited 1-5 phút, Standard 3-5 giờ, Bulk 5-12 giờ
  Lưu rất lâu, chấp nhận chờ nhiều giờ	Deep Archive	Tối thiểu 180 ngày; Standard trong 12 giờ, Bulk trong 48 giờ, không có Expedited
  Ít đọc, cần mili giây, có thể ở một AZ	One Zone-IA	Một AZ, tối thiểu 30 ngày, 128 KB tính phí tối thiểu

  Xóa sớm vẫn bị tính phần thời lượng còn thiếu. Sai thường gặp: "mọi Glacier đều chờ hàng giờ" (Instant Retrieval thì không). Xem mục 3.

• Phân biệt RDS Multi-AZ instance, cluster và read replica.

  Đáp án

  textReady

  Multi-AZ DB instance      Multi-AZ DB cluster        Read replicaAZ-a: Primary             AZ-a: Writer               AZ-a: Primary  | sync (engine/storage)   | semi-sync x2             | asyncAZ-b: Standby (no read)   AZ-b: Reader (đọc được)    AZ-b/Region: Replica                          AZ-c: Reader (đọc được)      (đọc được, có lag)Mục tiêu: failover        Mục tiêu: failover + đọc   Mục tiêu: scale đọc

  Multi-AZ instance: một standby, chỉ failover. Multi-AZ cluster: writer và hai reader ở ba AZ, replication semi-synchronous (cần ít nhất một reader xác nhận), reader nhận read traffic và là đích failover; khác với Aurora cluster. Read replica: bất đồng bộ, có replica lag, không thay HA tự động và không thay backup. Xem mục 5.

• Thiết kế hai DynamoDB access patterns, nêu consistency của GSI.

  Đáp án

  Ví dụ bảng Jobs: pattern 1 "lấy job theo ID" = base table, partition key jobId. Pattern 2 "liệt kê job của user theo thời gian" = GSI có partition key userId, sort key createdAt, dùng Query (không Scan). Read từ GSI luôn eventually consistent; ConsistentRead=true chỉ hỗ trợ trên base table và LSI. Cần đọc đúng ngay sau ghi: đọc base table theo jobId, hoặc chấp nhận độ trễ của GSI. Eventually consistent read rẻ bằng nửa strongly consistent read. Sai thường gặp: đặt userId làm partition key duy nhất khi một user quá nóng (hot partition). Xem mục 7.

• Tính tổng DB connections khi scale container/Lambda.

  Đáp án

  Công thức: tổng ≈ số instance x pool tối đa mỗi instance, cộng worker/admin/migration. Ví dụ (giả định, từ bài gốc): 100 container x 20 = 2.000. Với Lambda: mỗi môi trường thực thi đồng thời có thể giữ kết nối riêng, nên tổng ≈ concurrency x kết nối mỗi môi trường (ví dụ 500 x 1 = 500; con số concurrency là giả định). So sánh với giới hạn kết nối của engine/instance class bạn dùng (số này phụ thuộc cấu hình, tra tài liệu engine). Giảm bằng: pool nhỏ hơn, giới hạn concurrency, RDS Proxy (pool và multiplexing; proxy phải cùng VPC với database, không public; có hiện tượng pinning làm giảm lợi ích). Xem mục 6.

• Nêu cách cache tránh trả dữ liệu nhầm tenant.

  Đáp án

  Khóa cache chứa ngữ cảnh quyền: app:v1:t:{tenantId}:u:{userId}:invoice:{id}; dữ liệu dùng chung nhiều user thì key theo tenant, dữ liệu theo quyền thì theo user hoặc role. Luôn kiểm quyền ở API trước khi đọc cache; cache hit không bỏ qua authorization. Thêm TTL có jitter, không dùng cache làm bản duy nhất của billing.

  textReady

  GET /invoices/42 (tenant T1, user U7)  1. authz: U7 có quyền xem invoice 42?  -- không --> 404/403  2. cache.get("t:T1:invoice:42")       hit  -> trả về       miss -> DB (WHERE tenant_id = T1) -> cache.set(key, ttl + jitter)

  Sai thường gặp: key chỉ là invoice:42, tenant khác gọi cùng id nhận dữ liệu của người khác. Xem mục 8.

• Phân biệt query OLTP, analytics và search index.

  Đáp án

  	OLTP	Analytics (OLAP)	Search index
  Truy vấn	Transaction nhỏ, theo khóa	Quét/tổng hợp nhiều dòng	Full-text, filter, relevance
  Dịch vụ ví dụ	RDS/Aurora, DynamoDB	Athena trên S3, Redshift	OpenSearch Service
  Nguồn sự thật	Có	Dữ liệu dẫn xuất	Dữ liệu dẫn xuất, phải rebuild được

  Billing transaction ở OLTP, không chuyển sang Redshift chỉ vì dữ liệu lớn. Athena giảm dữ liệu quét bằng partition và Parquet. Dịch vụ BI nằm trong Amazon Quick (phần Quick Sight, xuất phát từ QuickSight; xem GĐ32 mục 9). Xem mục 9.

• Cần volume 500 GiB cho database với 6.000 IOPS và 250 MiB/s. Chọn gp3 hay gp2, cấu hình gp3 thế nào, và gp2 cần bao nhiêu GiB để đạt 6.000 IOPS?

  Đáp án

  gp3: baseline 3.000 IOPS và 125 MiB/s đã gồm trong giá; cấp thêm IOPS lên 6.000 (hợp lệ: trần là 500 IOPS mỗi GiB và tối đa 80.000 mỗi volume) và throughput 250 MiB/s (hợp lệ: trần là 0,25 MiB/s mỗi IOPS, tức 1.500 MiB/s với 6.000 IOPS, và tối đa 2.000 MiB/s mỗi volume), tức --iops 6000 --throughput 250. gp2: IOPS gắn với kích thước, 3 IOPS mỗi GiB, nên 6.000 IOPS cần 2.000 GiB; volume 500 GiB chỉ có baseline 1.500 IOPS và chỉ burst tới 3.000 IOPS bằng I/O credit. Vì vậy cần IOPS cao mà dung lượng vừa thì gp3 hợp lý hơn gp2. Cần trên 80.000 IOPS hoặc 2.000 MiB/s, hoặc độ trễ dưới mili giây ổn định thì xem io2 Block Express (trang loại EBS ghi use case này cho io2 Block Express; mốc hơn 16.000 IOPS là của io1). Xem mục 4 và gp2/gp3.

• Bảng DynamoDB nhận 120 lần ghi mỗi giây, item 2,5 KB; và 200 lần đọc mỗi giây, item 6 KB, strongly consistent. Tính WCU và RCU; RCU đổi thế nào nếu đọc eventually consistent hoặc transactional?

  Đáp án

  Ghi: 2,5 KB làm tròn lên 3 KB nên 3 WCU mỗi lần, 120 x 3 = 360 WCU (ghi transactional gấp đôi: 720). Đọc: 6 KB làm tròn lên 8 KB nên 2 RCU mỗi lần strongly consistent, 200 x 2 = 400 RCU. Eventually consistent bằng một nửa: 200 RCU. Transactional gấp đôi strongly consistent: 800 RCU. Sai thường gặp: chia thẳng 2,5 / 1 = 2,5 mà quên làm tròn lên từng item. Xem mục 7 và read/write operations.

• Một RDS instance production chưa mã hóa. Làm sao có bản mã hóa, và read replica của nó thì sao?

  Đáp án

  Không bật mã hóa tại chỗ được: chỉ mã hóa khi tạo instance. Cách làm: tạo snapshot, copy snapshot với --kms-key-id để có bản mã hóa, restore instance mới từ snapshot mã hóa, rồi chuyển ứng dụng sang endpoint mới (có cửa sổ chuyển đổi và dữ liệu ghi sau snapshot phải được xử lý riêng). Read replica phải cùng trạng thái mã hóa với nguồn, và cùng KMS key nếu cùng Region, nên tạo lại replica từ instance mới. Mã hóa không tắt được sau khi bật. Vô hiệu hóa KMS key làm instance không truy cập được. Xem mục 5 và mã hóa RDS.

• Bạn chạy aws s3api put-object --acl public-read vào bucket vừa tạo với cài đặt mặc định. Kết quả thế nào, vì sao, và đưa file ra công khai đúng cách ra sao?

  Đáp án

  Request thất bại với lỗi 400 AccessControlListNotSupported: bucket mới mặc định dùng Object Ownership "Bucket owner enforced" (ACL tắt), chỉ nhận PUT không ACL hoặc ACL bucket-owner-full-control. Ngay cả khi ACL được bật, Block Public Access BlockPublicAcls cũng từ chối ACL công khai. Muốn phân phối công khai thì dùng bucket policy cho đúng đối tượng và đúng cách, ưu tiên để bucket riêng tư rồi phục vụ qua CloudFront; chỉ nới Block Public Access khi thật sự cần (ví dụ static website) và kiểm bằng get-public-access-block. Xem mục 2, Object Ownership, Block Public Access.

• Bucket bật versioning có rule lifecycle Expiration sau 30 ngày cho prefix logs/. Sau 30 ngày dung lượng có giảm không? Sửa thế nào?

  Đáp án

  Không. Ở bucket bật versioning, Expiration chỉ thêm delete marker làm version hiện tại thành noncurrent, dữ liệu cũ vẫn còn và vẫn tính tiền. Thêm NoncurrentVersionExpiration (ví dụ sau 30 ngày noncurrent) để xóa vĩnh viễn version cũ, và dọn delete marker mồ côi bằng ExpiredObjectDeleteMarker; đồng thời AbortIncompleteMultipartUpload để dọn upload dở. Cẩn thận với NewerNoncurrentVersions: giá trị này là số version noncurrent mới hơn phải tồn tại trước khi S3 xóa một version, và cả NoncurrentDays lẫn NewerNoncurrentVersions đều phải bị vượt (lifecycle elements); với object chỉ ghi một lần thì bản dữ liệu duy nhất không có version noncurrent nào mới hơn, nên không bao giờ bị xóa và delete marker cũng không được dọn. Chỉ dùng khi chủ ý giữ N bản. Xem mục 3 và lifecycle elements.

Ghi chú chung: Kiểm chứng ngày 2026-10-05 theo tài liệu AWS. Chưa chạy trên AWS thật; đây là đáp án khái niệm, đối chiếu tài liệu AWS. Số liệu về lớp S3 và DynamoDB ở trên khớp trang chính thức; giá tiền cố ý không nêu. Nguồn: S3 storage classes, S3 restore retrieval options, S3 replication: what is replicated, S3 replication, RDS Multi-AZ, DynamoDB read consistency, RDS Proxy.

Tiếp: GĐ32 — Cost, Migration & Reference.