Ngân hàng đề — AWS Certified Solutions Architect Associate

Đáp án

B — Cold HDD (sc1).

Vì sao đúng

Đề cho ba dữ kiện, và cả ba đều chỉ vào sc1: | Dữ kiện | Ý nghĩa | |---|---| | Dữ liệu HIẾM KHI truy cập | sc1 dành cho tải ít truy cập nhất | | Đọc TUẦN TỰ | HDD tốt cho tuần tự, kém cho ngẫu nhiên | | RẺ NHẤT | sc1 là loại rẻ nhất trong mọi loại EBS |

⚠ HDD hợp với đọc tuần tự, không hợp với đọc ngẫu nhiên:

HDD có đầu đọc cơ học phải di chuyển
    → đọc liên tiếp: rất nhanh
    → nhảy lung tung: rất chậm
        ↓
    Đề nói "retrieved sequentially" → HDD hợp

Bảng giá tham khảo: | Loại | Giá/GB-tháng | Đặc điểm | |---|---|---| | sc1 (Cold HDD) | ~0,015 USD | rẻ nhất | | st1 (Throughput Optimized HDD) | ~0,045 USD | tuần tự, hay truy cập | | gp3 (General Purpose SSD) | ~0,08 USD | mặc định | | io2 (Provisioned IOPS SSD) | ~0,125 USD + phí IOPS | đắt nhất |

sc1 rẻ hơn gp3 khoảng 5 lần
    → với vài chục TB dữ liệu ít dùng
    → khoản chênh rất lớn

Tạo volume:

aws ec2 create-volume --availability-zone ap-southeast-1a \
  --size 2000 --volume-type sc1 --encrypted

⚠ sc1 và st1 có kích thước TỐI THIỂU: | Loại | Tối thiểu | Tối đa | |---|---|---| | sc1 | 125 GiB | 16 TiB | | st1 | 125 GiB | 16 TiB |

Cần volume 50 GB rẻ tiền
    → sc1 KHÔNG tạo được dưới 125 GiB
        ↓
    Trả tiền 125 GiB dù chỉ dùng 50
    → gp3 có thể rẻ hơn ở dung lượng nhỏ

Ba giới hạn của sc1 phải biết: | Giới hạn | Giá trị | |---|---| | Thông lượng cơ sở | 12 MB/s mỗi TiB | | Thông lượng bùng nổ | 80 MB/s mỗi TiB | | Thông lượng tối đa mỗi volume | 250 MB/s | | IOPS tối đa | ~250 |

⚠ sc1 KHÔNG dùng làm volume khởi động:

sc1 và st1 không boot được
    → volume gốc phải là gp3, gp2, io1 hoặc io2
        ↓
    sc1 chỉ dùng làm volume dữ liệu phụ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Rẻ nhất trong các loại EBS | | | Vẫn bền vững như mọi volume EBS | | | Snapshot được như bình thường | |

Vì sao các phương án khác sai

• **C. Throughput Optimized HDD (st1) — đây là phương án gần nhất và cũng là HDD tối ưu cho tuần tự, nhưng st1 dành cho tải truy cập THƯỜNG XUYÊN (log xử lý, dữ liệu lớn, ETL) và đắt gấp ba lần sc1. Đề nói "rarely accessed" và "least expensive".
• **A. General Purpose SSD (gp2) — SSD, đắt hơn sc1 khoảng 5 lần; thừa hiệu năng cho dữ liệu ít dùng đọc tuần tự.
• **D. Provisioned IOPS SSD (io1) — đắt nhất, dành cho CSDL đòi IOPS cao và ổn định; hoàn toàn không hợp.

Ghi nhớ

⚠ Bốn nhóm volume EBS — bảng phải thuộc: | Loại | Nhóm | Dùng cho | |---|---|---| | gp3 / gp2 | SSD | mặc định, boot, hầu hết tải | | io2 / io1 | SSD | CSDL đòi IOPS cao, ổn định | | st1 | HDD | tuần tự, thường xuyên — log, big data | | sc1 | HDD | tuần tự, HIẾM khi dùng — rẻ nhất |

Từ khoá nhận diện:

"rarely accessed, sequential, cheapest" → sc1 "frequently accessed, sequential, big data" → st1 "boot volume, general workload" → gp3 "database, consistent high IOPS" → io2 "sub-millisecond latency, highest IOPS" → io2 Block Express

⚠ HDD không dùng cho tải NGẪU NHIÊN:

CSDL đọc ngẫu nhiên trên st1 hoặc sc1
    → hiệu năng thảm hại
        ↓
    HDD chỉ hợp khi đọc/ghi theo khối lớn, liên tiếp

Ba lưu ý về gp3 (mặc định hiện nay): | Lưu ý | Chi tiết | |---|---| | Rẻ hơn gp2 ~20% | | | 3.000 IOPS và 125 MB/s cơ bản MIỄN PHÍ | | | Tăng IOPS và thông lượng độc lập với dung lượng | |

⚠ Đây là khác biệt lớn giữa gp2 và gp3:

gp2: IOPS gắn với dung lượng (3 IOPS mỗi GB)
    → cần 6.000 IOPS phải cấp 2 TB
        ↓
gp3: cấp 100 GB vẫn có 3.000 IOPS
    → tăng lên 16.000 IOPS mà không cần thêm dung lượng

Ba lưu ý về mô hình burst: | Lưu ý | Chi tiết | |---|---| | st1 và sc1 dùng credit thông lượng | | | Volume lớn hơn có thông lượng cơ sở cao hơn | | | Cạn credit thì tụt về mức cơ sở | |

Ba lưu ý về giới hạn của instance: | Lưu ý | Chi tiết | |---|---| | Instance có trần băng thông EBS riêng | | | Volume nhanh mà máy nhỏ vẫn nghẽn | | | Bật EBS-optimized | mặc định trên máy đời mới |

Ba lựa chọn rẻ hơn nữa cho dữ liệu ít dùng: | Lựa chọn | Khi nào | |---|---| | S3 Glacier Deep Archive | ~0,00099 USD/GB — rẻ hơn sc1 15 lần | | S3 Standard-IA | ~0,0125 USD/GB | | EFS Archive | hệ thống tệp dùng chung |

⚠ Nếu ứng dụng đọc được qua API thì S3 rẻ hơn nhiều:

sc1 2 TB: ~30 USD/tháng
S3 Glacier Deep Archive 2 TB: ~2 USD/tháng
        ↓
    Đề buộc dùng EBS ("migrated onto an EC2 instance")
    → nhưng ngoài đời hãy cân nhắc S3 trước

Ba lưu ý về snapshot: | Lưu ý | Chi tiết | |---|---| | Snapshot của sc1 vẫn lưu ở S3 | | | Chỉ tính tiền dữ liệu thật thay đổi | | | DLM tự động hoá lịch snapshot | |

Ba lưu ý về đổi loại volume: | Lưu ý | Chi tiết | |---|---| | Đổi loại được khi volume đang chạy | | | Không cần dừng máy | | | Phải chờ tối thiểu 6 giờ giữa hai lần đổi | |

aws ec2 modify-volume --volume-id vol-abc --volume-type sc1

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thông lượng đọc tuần tự thật | | | Kiểm tra BurstBalance không cạn | | | So chi phí với gp3 | |

Và một lời khuyên: hãy tính lại xem dữ liệu này có thật sự cần nằm trên EBS không. sc1 là loại EBS rẻ nhất, nhưng nó vẫn đắt hơn S3 Glacier Deep Archive khoảng mười lăm lần — và với dữ liệu hiếm khi đọc thì khoản chênh đó thường lớn hơn công sức sửa ứng dụng để đọc qua API.

Đáp án

A — AWS Lambda.

Vì sao đúng

Đề cho ba dữ kiện, và cả ba đều nằm gọn trong vùng hoạt động của Lambda: | Dữ kiện | Lambda có phù hợp | |---|---| | Xử lý mất VÀI GIÂY | ✅ giới hạn 15 phút | | Dưới 256 MB bộ nhớ | ✅ khoảng 128 MB – 10 GB | | Kích hoạt bởi tệp trên S3 | ✅ S3 event notification |

⚠ "Vài giây mỗi lần chạy" là chỗ Lambda rẻ hơn hẳn:

Fargate: tính phí từ lúc kéo image tới lúc task dừng
    → task chạy 3 giây vẫn tốn thời gian khởi động
        ↓
Lambda: tính theo mili giây thực thi
    → 3 giây = trả tiền 3 giây

Tính thử chi phí:

Lambda 256 MB, 3 giây, 100.000 lần/tháng
    → 0,25 GB × 3 s × 100.000 = 75.000 GB-giây
    → ~1,25 USD + phí request ~0,02 USD
        ↓
    Fargate 0,25 vCPU + 0,5 GB, cùng số lần
    → cộng thêm thời gian khởi động mỗi task
    → đắt hơn nhiều lần

Cấu hình:

aws lambda create-function --function-name xu-ly-du-lieu \
  --runtime python3.12 --handler app.handler \
  --memory-size 256 --timeout 30 \
  --role <arn-role> --zip-file fileb://ma.zip

aws s3api put-bucket-notification-configuration \
  --bucket du-lieu-vao \
  --notification-configuration '{
    "LambdaFunctionConfigurations": [{
      "LambdaFunctionArn": "<arn-ham>",
      "Events": ["s3:ObjectCreated:*"],
      "Filter": {"Key": {"FilterRules": [
        {"Name": "prefix", "Value": "vao/"}]}}}]}'

⚠ Ghi kết quả sang bucket KHÁC hoặc lọc tiền tố chặt:

Ghi kết quả vào cùng bucket, cùng tiền tố
    → hàm tự kích hoạt chính nó
        ↓
    VÒNG LẶP VÔ HẠN — hoá đơn không giới hạn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có gì chạy khi không có tệp | | | Tự mở rộng khi nhiều tệp tới cùng lúc | | | Một triệu request đầu mỗi tháng miễn phí | |

⚠ Bộ nhớ Lambda quyết định cả CPU:

Lambda cấp CPU TỶ LỆ với bộ nhớ
    → 1.769 MB ≈ 1 vCPU đầy đủ
        ↓
    Đề nói "dưới 256 MB là đủ"
    → nhưng nếu tác vụ nặng CPU,
      tăng bộ nhớ có thể vừa nhanh hơn vừa RẺ hơn

Vì sao các phương án khác sai

• **B. AWS Fargate — đây là phương án gần nhất vì cũng không quản lý máy chủ, nhưng Fargate tính phí theo thời gian task tồn tại (gồm cả khởi động), nên với tác vụ chỉ vài giây thì đắt hơn Lambda đáng kể.
• **C. EC2 Spot Instances — rẻ trên mỗi giờ, nhưng phải có máy chạy sẵn để nhận việc; với tải rời rạc thì trả tiền cho phần lớn thời gian rảnh.
• **D. Elastic Beanstalk — nền tảng chạy ứng dụng web thường trực; luôn có EC2 chạy nền, đắt nhất cho tác vụ vài giây.

Ghi nhớ

⚠ Bốn lựa chọn tính toán theo thời lượng tác vụ — bảng phải thuộc: | Thời lượng | Lựa chọn | |---|---| | Vài giây tới 15 phút | Lambda | | Quá 15 phút, container | Fargate / ECS | | Job theo lô có phụ thuộc | AWS Batch | | Chạy liên tục | EC2 / Fargate service |

Từ khoá nhận diện:

"seconds, event-driven, cost-effective" → Lambda "longer than 15 minutes" → Fargate / Batch "steady constant load" → EC2 với Savings Plans "fault-tolerant batch" → Spot

⚠ Bốn giới hạn Lambda phải thuộc: | Giới hạn | Giá trị | |---|---| | Thời gian chạy | 15 phút | | Bộ nhớ | 128 MB – 10 GB | | Dung lượng /tmp | 512 MB – 10 GB | | Payload đồng bộ | 6 MB |

Ba lưu ý về khởi động nguội: | Lưu ý | Chi tiết | |---|---| | Lần gọi đầu sau khi rảnh chậm hơn | | | Runtime biên dịch sẵn khởi động nhanh hơn | | | Provisioned concurrency loại bỏ nhưng tốn tiền | |

⚠ Với tải rời rạc, đừng bật provisioned concurrency:

Nó giữ môi trường sẵn 24/7
    → mất đúng lợi thế "rảnh thì không tốn"
        ↓
    Chỉ bật cho endpoint nhạy cảm với độ trễ

Ba lưu ý về tối ưu bộ nhớ: | Lưu ý | Chi tiết | |---|---| | Bộ nhớ lớn hơn = CPU nhiều hơn | | | Có khi lớn hơn lại RẺ hơn | | | Lambda Power Tuning tìm điểm tối ưu | |

128 MB × 1000 ms = 128 GB-ms
1024 MB × 100 ms = 102 GB-ms
        ↓
    Gấp 8 lần bộ nhớ, rẻ hơn 20%, nhanh hơn 10 lần

Ba lưu ý về S3 event: | Lưu ý | Chi tiết | |---|---| | Giao ít nhất một lần — có thể trùng | | | Không đảm bảo thứ tự | | | Xử lý phải idempotent | |

Ba lưu ý về xử lý lỗi: | Lưu ý | Chi tiết | |---|---| | Cấu hình destination cho lỗi | | | Hoặc đi qua SQS để có DLQ | | | Đặt cảnh báo cho metric Errors | |

aws lambda put-function-event-invoke-config \
  --function-name xu-ly-du-lieu --maximum-retry-attempts 2 \
  --destination-config '{"OnFailure":{"Destination":"<arn-sqs>"}}'

⚠ S3 → SQS → Lambda bền hơn S3 → Lambda:

S3 → Lambda trực tiếp: lỗi thì thử 2 lần rồi bỏ
        ↓
S3 → SQS → Lambda: tin nhắn nằm trong hàng đợi
    → thử lại nhiều lần, hỏng thì vào DLQ
    → không mất tệp nào

Ba lưu ý về đồng thời: | Lưu ý | Chi tiết | |---|---| | Mặc định 1.000 thực thi đồng thời mỗi tài khoản | | | Reserved concurrency bảo vệ hàm khác | | | Cũng để bảo vệ backend hạ nguồn | |

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | Execution role cần đọc bucket nguồn | | | Và ghi bucket đích | | | Cấp quyền cho S3 gọi hàm | |

aws lambda add-permission --function-name xu-ly-du-lieu \
  --principal s3.amazonaws.com --action lambda:InvokeFunction \
  --statement-id s3-goi --source-arn arn:aws:s3:::du-lieu-vao

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | Duration | so với timeout | | Throttles | chạm giới hạn đồng thời | | Errors | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy một tệp, xem hàm chạy | | | Kiểm tra bộ nhớ dùng thật trong log | | | Đẩy nhiều tệp cùng lúc, xem throttle | |

Và một lời khuyên: hãy chạy Lambda Power Tuning trước khi chốt mức bộ nhớ. Đề nói 256 MB là đủ về mặt bộ nhớ, nhưng Lambda cấp CPU theo tỷ lệ với bộ nhớ — nên với tác vụ nặng tính toán, một cấu hình lớn hơn thường vừa nhanh hơn vừa rẻ hơn cùng lúc.

Đáp án

C — Thiết lập bucket policy của S3 cho phép truy cập từ một VPC endpoint.

Vì sao đúng

Đề nêu hai yêu cầu, và chỉ phương án này giải quyết cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Kết nối RIÊNG TƯ giữa EC2 và S3 | Gateway VPC endpoint — lưu lượng không ra Internet | | Dữ liệu tối mật, kết nối AN TOÀN | bucket policy chỉ chấp nhận qua endpoint đó |

⚠ Hai nửa của giải pháp phải đi cùng nhau:

Chỉ tạo VPC endpoint:
    → lưu lượng đi riêng tư
    → nhưng bucket vẫn nhận truy cập từ Internet
        ↓
Thêm bucket policy điều kiện aws:SourceVpce:
    → bucket TỪ CHỐI mọi đường khác

Tạo Gateway endpoint:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --route-table-ids rtb-rieng-tu-a rtb-rieng-tu-b

Bucket policy khoá chặt:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChiQuaVpcEndpoint",
   "Effect": "Deny",
   "Principal": "*",
   "Action": "s3:*",
   "Resource": ["arn:aws:s3:::du-lieu-mat",
                "arn:aws:s3:::du-lieu-mat/*"],
   "Condition": {
     "StringNotEquals": {"aws:SourceVpce": "vpce-abc123"}}}]}

⚠ Đây là điểm mạnh nhất của cách này:

Kể cả kẻ tấn công có credential ĐÚNG
    → gọi từ Internet vẫn bị từ chối
        ↓
    Credential bị lộ không còn đủ để lấy dữ liệu

Gateway endpoint là loại đúng cho S3 từ trong VPC: | Loại | Dịch vụ | Phí | |---|---|---| | Gateway | S3, DynamoDB | MIỄN PHÍ | | Interface | hầu hết dịch vụ khác | có phí |

⚠ Cách Gateway endpoint hoạt động — thêm TUYẾN:

AWS thêm vào route table:
    đích = prefix list của S3
    next hop = vpce-abc123
        ↓
    Gói tin tới S3 đi theo tuyến đó
    → không qua NAT gateway, không qua Internet

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Miễn phí hoàn toàn | | | Bỏ được phí xử lý dữ liệu của NAT | | | Bucket chỉ truy cập được từ VPC đó | |

Vì sao các phương án khác sai

• **B. Đặt IAM policy cấp quyền đọc-ghi bucket — đây là phương án gần nhất và cần thiết (không có nó thì không truy cập được), nhưng IAM policy quyết định AI được phép, không quyết định ĐƯỜNG ĐI. Lưu lượng vẫn có thể ra Internet.
• **D. Bật mã hoá bằng KMS cho bucket — mã hoá bảo vệ dữ liệu khi lưu trữ; nó không tạo ra kết nối riêng tư nào.
• **A. Cấu hình chứng chỉ SSL/TLS tuỳ chỉnh trên bucket — S3 đã dùng HTTPS sẵn, và không có chuyện gắn chứng chỉ tuỳ chỉnh lên bucket theo cách này; mã hoá đường truyền cũng không làm cho kết nối thành riêng tư.

Ghi nhớ

⚠ Bốn cơ chế thường bị gộp làm một — bảng phải thuộc: | Cơ chế | Trả lời câu hỏi | |---|---| | VPC endpoint | lưu lượng đi ĐƯỜNG nào | | IAM policy | AI được phép làm gì | | Bucket policy | tài nguyên chấp nhận ai, từ đâu | | Mã hoá (KMS) | dữ liệu có đọc được nếu bị lấy không |

⚠ Bảo mật tốt cần cả bốn, không thay thế nhau.

Từ khoá nhận diện:

"private connection to S3 from VPC" → Gateway VPC endpoint "only my VPC can access this bucket" → aws:SourceVpce trong bucket policy "access S3 from on-premises privately" → Interface endpoint "encrypt data at rest" → SSE-KMS

Ba khoá điều kiện giới hạn nguồn: | Khoá | Giới hạn theo | |---|---| | aws:SourceVpce | một VPC endpoint cụ thể | | aws:SourceVpc | cả VPC | | aws:SourceIp | dải IP |

⚠ aws:SourceIp KHÔNG hoạt động cho lưu lượng qua VPC endpoint:

Gói tin qua endpoint không mang IP công khai
    → điều kiện SourceIp không khớp
        ↓
    Dùng SourceVpce hoặc SourceVpc thay thế

Ba lưu ý về endpoint policy: | Lưu ý | Chi tiết | |---|---| | Mặc định cho phép tất cả | | | Giới hạn được bucket cụ thể | | | Lớp phòng thủ thứ hai bên cạnh bucket policy | |

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": ["arn:aws:s3:::du-lieu-mat/*"]}]}

⚠ Endpoint policy chặn cả việc lấy dữ liệu ra bucket lạ:

Máy bị chiếm muốn chép dữ liệu sang bucket
của kẻ tấn công
    → endpoint policy chỉ cho phép bucket của bạn
        ↓
    Đường thoát dữ liệu bị bịt

Ba lớp bảo vệ bucket: | Lớp | Việc | |---|---| | Block Public Access (cấp tài khoản) | | | Bucket policy | | | Object Ownership = BucketOwnerEnforced | |

aws s3control put-public-access-block --account-id 123456789012 \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

Ba lưu ý về mã hoá cho dữ liệu tối mật: | Lưu ý | Chi tiết | |---|---| | SSE-KMS với customer managed key | | | Key policy giới hạn ai giải mã được | | | CloudTrail ghi mọi lần dùng khoá | |

⚠ Yêu cầu mã hoá bắt buộc trong bucket policy:

{"Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::du-lieu-mat/*",
 "Condition": {"StringNotEquals":
   {"s3:x-amz-server-side-encryption": "aws:kms"}}}

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | Bật CloudTrail data event cho bucket | | | VPC Flow Logs xem lưu lượng qua endpoint | | | Access Analyzer tìm truy cập ngoài dự kiến | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Gateway endpoint miễn phí | | | Bỏ được phí NAT ~0,045 USD/GB | | | Tiết kiệm lớn với dữ liệu nhiều TB | |

Ba lưu ý về gỡ lỗi: | Triệu chứng | Nguyên nhân | |---|---| | Vẫn đi qua NAT | quên gắn route table | | AccessDenied | endpoint policy hoặc bucket policy quá chặt | | Từ tại chỗ không vào được | Gateway endpoint không hỗ trợ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải object từ EC2 riêng tư | phải được | | Thử từ máy ngoài với cùng credential | phải bị từ chối | | Kiểm tra tuyến trong route table | |

aws ec2 describe-route-tables --route-table-ids rtb-rieng-tu-a \
  --query "RouteTables[0].Routes[?DestinationPrefixListId!=null]"

Và một lời khuyên: hãy thêm điều kiện aws:SourceVpce vào bucket policy chứ đừng dừng ở việc tạo endpoint. Endpoint làm cho lưu lượng đi riêng tư, nhưng chỉ có bucket policy mới biến "có thể đi riêng tư" thành "bắt buộc phải đi riêng tư" — và với dữ liệu tối mật thì khác biệt đó là toàn bộ vấn đề.

Đáp án

A, B và E — Tạo vai trò IAM cho phép AWS Budgets thực thi budget action; dùng AWS Budgets đặt ngân sách riêng cho từng tài khoản; cấu hình cảnh báo cùng budget action liên kết với vai trò đó để chặn cấp phát thêm tài nguyên.

Vì sao đúng

Đề nêu hai mục tiêu, và ba lựa chọn này ghép thành một cơ chế hoàn chỉnh: | Mục tiêu | Bước | |---|---| | Ngân sách riêng mỗi tài khoản | B — tạo budget cho từng tài khoản | | NGĂN cấp phát thêm khi vượt | E — budget action | | Budget action cần quyền để hành động | A — vai trò IAM |

⚠ Điểm cốt lõi: cảnh báo KHÔNG ngăn được gì:

Budget alert: gửi thư "bạn đã dùng 80% ngân sách"
    → ai đó phải đọc và hành động
        ↓
Budget ACTION: tự áp một IAM policy chặn,
               hoặc dừng EC2/RDS
    → ngăn thật, không cần người

Ba loại budget action: | Loại | Việc | |---|---| | Áp IAM policy | chặn quyền tạo tài nguyên | | Áp SCP | chặn ở cấp tổ chức | | Dừng EC2 hoặc RDS | tắt máy đang chạy |

Vai trò IAM cho Budgets:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": {"Service": "budgets.amazonaws.com"},
   "Action": "sts:AssumeRole",
   "Condition": {"StringEquals": {"aws:SourceAccount": "123456789012"}}}]}

⚠ aws:SourceAccount chống tấn công "confused deputy" — thiếu nó thì tài khoản khác có thể lừa dịch vụ Budgets dùng vai trò của bạn.

Policy để áp khi vượt ngân sách:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Deny",
   "Action": ["ec2:RunInstances", "rds:CreateDBInstance",
              "eks:CreateCluster", "sagemaker:CreateNotebookInstance"],
   "Resource": "*"}]}

Tạo budget kèm action:

aws budgets create-budget --account-id 123456789012 \
  --budget '{"BudgetName":"ngan-sach-phat-trien",
    "BudgetLimit":{"Amount":"5000","Unit":"USD"},
    "TimeUnit":"MONTHLY","BudgetType":"COST"}'

aws budgets create-budget-action --account-id 123456789012 \
  --budget-name ngan-sach-phat-trien \
  --notification-type ACTUAL \
  --action-type APPLY_IAM_POLICY \
  --action-threshold 'ActionThresholdValue=100,
                      ActionThresholdType=PERCENTAGE' \
  --definition 'IamActionDefinition={
    PolicyArn=<arn-policy-chan>,Roles=[VaiTroPhatTrien]}' \
  --execution-role-arn <arn-vai-tro-budgets> \
  --approval-model AUTOMATIC \
  --subscribers 'SubscriptionType=EMAIL,Address=quantri@vidu.com'

⚠ --approval-model có hai giá trị, chọn kỹ: | Giá trị | Hành vi | |---|---| | AUTOMATIC | áp ngay khi chạm ngưỡng | | MANUAL | chờ người phê duyệt |

AUTOMATIC ở tài khoản sản xuất là rủi ro
    → có thể chặn đúng lúc cần mở rộng khẩn
        ↓
    Dùng AUTOMATIC cho dev/test,
    MANUAL cho sản xuất

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chặn thật, không chỉ cảnh báo | | | Tự động, không cần người trực | | | Gỡ được sau khi xem xét | |

Ghi nhớ về chất lượng câu hỏi

⚠ Phương án B và C mô tả cùng một việc.

Billing and Cost Management console
    LÀ một phần của AWS Management Console
        ↓
    Hai câu này không phân biệt được bằng cách đọc nào

Đây là lỗi soạn đề. Cặp phương án đúng thật sự phân biệt được là A và F (vai trò IAM đúng, người dùng IAM sai), còn B và C thì không.

Gặp hai phương án không phân biệt được
    → nhận ra đề có vấn đề, đừng tự nghi ngờ

Vì sao các phương án khác sai

• **C. Dùng AWS Budgets trong Management Console đặt ngưỡng — xem phần trên: không phân biệt được với B.
• **F. Tạo IAM user để Budgets thực thi hành động — dịch vụ AWS đảm nhận VAI TRÒ, không đăng nhập bằng người dùng. Budget action cần một role có trust policy cho budgets.amazonaws.com.
• **D. Đặt cảnh báo và bật "giám sát thời gian thực" — AWS Budgets không có giám sát thời gian thực; dữ liệu chi phí cập nhật khoảng ba lần mỗi ngày. Và cảnh báo thì không ngăn được gì.

Ghi nhớ

⚠ Bốn công cụ chi phí — bảng phải thuộc: | Công cụ | Việc | |---|---| | AWS Budgets | đặt ngưỡng, cảnh báo, và HÀNH ĐỘNG | | Cost Explorer | phân tích và trực quan hoá | | Cost and Usage Report | dữ liệu thô chi tiết nhất | | Compute Optimizer | khuyến nghị đổi cỡ máy |

Từ khoá nhận diện:

"prevent provisioning when budget exceeded" → Budget actions "notify when spending exceeds" → Budget alert "analyze past costs" → Cost Explorer "block specific actions permanently" → SCP

⚠ Dữ liệu chi phí KHÔNG thời gian thực:

Budgets đánh giá khoảng 3 lần mỗi ngày
    → chi phí xuất hiện sau vài giờ
        ↓
    Không dùng Budgets để chặn tức thì
    → dùng SCP nếu cần chặn cứng

Ba loại ngân sách: | Loại | Theo dõi | |---|---| | Cost budget | số tiền | | Usage budget | giờ máy, GB | | RI/SP utilization budget | hiệu quả cam kết |

Ba lưu ý về ngưỡng: | Lưu ý | Chi tiết | |---|---| | ACTUAL — chi phí đã phát sinh | | | FORECASTED — dự báo sẽ vượt | | | Đặt nhiều ngưỡng: 50%, 80%, 100% | |

⚠ Ngưỡng FORECASTED cảnh báo SỚM hơn nhiều:

ACTUAL 100%: đã tiêu hết tiền rồi mới biết
        ↓
FORECASTED 100%: "với đà này bạn sẽ vượt"
    → còn thời gian để xử lý

Ba lưu ý về phạm vi ngân sách: | Lưu ý | Chi tiết | |---|---| | Lọc theo tài khoản, dịch vụ, tag | | | Tag phải được kích hoạt làm cost allocation tag | | | Ngân sách của management account thấy cả tổ chức | |

aws budgets create-budget --account-id 123456789012 \
  --budget '{"BudgetName":"theo-du-an",
    "BudgetLimit":{"Amount":"2000","Unit":"USD"},
    "TimeUnit":"MONTHLY","BudgetType":"COST",
    "CostFilters":{"TagKeyValue":["user:DuAn$alpha"]}}'

Ba lưu ý về SCP như biện pháp mạnh hơn: | Lưu ý | Chi tiết | |---|---| | Chặn ngay từ đầu, không chờ vượt ngân sách | | | Giới hạn loại instance được phép | | | Giới hạn Region được dùng | |

{"Effect": "Deny", "Action": "ec2:RunInstances",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"StringNotEquals":
   {"ec2:InstanceType": ["t3.micro","t3.small","m5.large"]}}}

⚠ Kết hợp cả hai là cách tốt nhất:

SCP: chặn cứng thứ không bao giờ được dùng
Budget action: phản ứng khi chi tiêu vượt dự kiến
        ↓
    Một cái phòng ngừa, một cái ứng phó

Ba lưu ý về gỡ hành động: | Lưu ý | Chi tiết | |---|---| | Có thể gỡ policy thủ công | | | Chu kỳ ngân sách mới không tự gỡ | | | Ghi tài liệu quy trình gỡ | |

⚠ Đây là bẫy vận hành thật:

Sang tháng mới, ngân sách reset
    → nhưng IAM policy chặn VẪN CÒN
        ↓
    Phải gỡ thủ công, hoặc dựng tự động hoá riêng

Ba lưu ý về thông báo: | Lưu ý | Chi tiết | |---|---| | Tới 10 người nhận mỗi thông báo | | | Gửi được qua SNS | | | SNS rồi Lambda cho logic phức tạp | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đặt ngân sách thử rất thấp | | | Xác nhận action được áp | | | Thử tạo EC2 — phải bị từ chối | |

aws budgets describe-budget-actions-for-budget \
  --account-id 123456789012 --budget-name ngan-sach-phat-trien

Và một lời khuyên: hãy dùng approval-model MANUAL cho tài khoản sản xuất. Budget action tự động là công cụ tốt cho môi trường phát triển, nhưng ở sản xuất nó có thể chặn đúng lúc bạn cần mở rộng khẩn cấp — và lúc đó việc tiết kiệm vài trăm đô sẽ trở nên rất đắt.

Đáp án

D — Server-Side Encryption with AWS KMS-Managed Keys (SSE-KMS).

Vì sao đúng

Đề nêu ba yêu cầu, và chỉ SSE-KMS đáp ứng đủ: | Yêu cầu | Cách đáp ứng | |---|---| | Mã hoá at rest | cả bốn phương án đều làm được | | KHÔNG muốn tự quản lý và xoay khoá | KMS xoay tự động | | NHƯNG muốn KIỂM SOÁT ai dùng được khoá | key policy — chỉ SSE-KMS có |

⚠ Vế thứ ba là chỗ phân biệt SSE-KMS với SSE-S3:

SSE-S3: AWS quản lý khoá hoàn toàn
    → không có key policy
    → không kiểm soát được ai giải mã
    → không biết ai đã dùng khoá
        ↓
SSE-KMS: khoá của bạn trong KMS
    → key policy quyết định ai dùng được
    → CloudTrail ghi mọi lần dùng

Bật mã hoá mặc định:

aws kms create-key --description "Khoa ma hoa tai lieu khach hang"

aws s3api put-bucket-encryption --bucket tai-lieu-khach-hang \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "<arn-khoa>"},
      "BucketKeyEnabled": true}]}'

⚠ Luôn bật BucketKeyEnabled:

Không bật: mỗi object gọi KMS một lần khi ghi
           và một lần khi đọc
    → triệu object = triệu lời gọi, tính phí từng lời
        ↓
Bật S3 Bucket Key: giảm tới 99% số lần gọi KMS
    → giảm chi phí và tránh chạm hạn ngạch tần suất

Bật xoay khoá tự động:

aws kms enable-key-rotation --key-id <id-khoa>

KMS tự tạo tài liệu khoá mới mỗi năm
    → giữ tài liệu cũ để giải mã dữ liệu cũ
        ↓
    Đúng "không muốn mất thời gian xoay khoá"

Key policy kiểm soát ai dùng được:

{"Sid": "ChoPhepUngDungDung",
 "Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::123456789012:role/VaiTroUngDung"},
 "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
 "Resource": "*"}

⚠ Đây là lớp kiểm soát THỨ HAI, độc lập với IAM:

Ai đó có s3:GetObject nhưng không có kms:Decrypt
    → tải object về được nhưng KHÔNG giải mã được
        ↓
    Hai chìa khoá cho một cánh cửa

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | AWS lo việc xoay khoá | | | Bạn kiểm soát ai giải mã | | | CloudTrail ghi mọi lần dùng khoá | |

Vì sao các phương án khác sai

• **A. SSE-S3 — đây là phương án gần nhất và cũng không phải quản lý khoá, nhưng không có key policy: bạn không kiểm soát được ai giải mã và không có nhật ký dùng khoá. Đề nói rõ "does want to control who can access those keys".
• **C. SSE-C (khách hàng tự cung cấp khoá) — bạn phải tự tạo, tự lưu, tự xoay, và gửi khoá theo MỖI request; ngược hẳn "không muốn mất thời gian quản lý khoá".
• **B. "Mã hoá phía máy chủ với khoá lưu trong một bucket S3" — không tồn tại; đây không phải một chế độ mã hoá của S3, và lưu khoá cạnh dữ liệu là thực hành tệ.

Ghi nhớ

⚠ Bốn chế độ mã hoá S3 — bảng phải thuộc: | Chế độ | Ai giữ khoá | Kiểm soát truy cập khoá | Xoay | |---|---|---|---| | SSE-S3 | AWS hoàn toàn | không có | AWS lo | | SSE-KMS | KMS, của bạn | key policy | tự động | | SSE-C | BẠN, gửi mỗi request | bạn tự lo | bạn tự lo | | DSSE-KMS | KMS, mã hoá hai lớp | key policy | tự động |

Từ khoá nhận diện:

"don't manage keys BUT control access to them" → SSE-KMS "simplest, no key management at all" → SSE-S3 "must supply my own keys per request" → SSE-C "two layers of encryption for compliance" → DSSE-KMS "encrypt before uploading" → client-side encryption

⚠ Ba loại khoá KMS: | Loại | Chi phí | Kiểm soát | |---|---|---| | AWS managed key (aws/s3) | miễn phí | không sửa key policy được | | Customer managed key | ~1 USD/tháng | đầy đủ | | AWS owned key | miễn phí | không thấy được |

Đề nói "control who can access those keys"
    → phải là CUSTOMER MANAGED KEY
        ↓
    AWS managed key aws/s3 không cho sửa key policy

Ba lưu ý về xoay khoá: | Lưu ý | Chi tiết | |---|---| | Xoay tự động mỗi năm (chỉnh được 90-2560 ngày) | | | Object cũ KHÔNG mã hoá lại | | | KMS giữ tài liệu khoá cũ để giải mã | |

⚠ Xoay khoá không mã hoá lại dữ liệu cũ:

Xoay khoá → object mới dùng tài liệu khoá mới
    → object cũ vẫn dùng tài liệu cũ
        ↓
    Muốn mã hoá lại tất cả: dùng S3 Batch Operations
      copy object lên chính nó

Ba lưu ý về hạn ngạch KMS: | Hạn ngạch | Giá trị tham khảo | |---|---| | Decrypt mỗi giây | tuỳ Region, vài nghìn | | Vượt thì ThrottlingException | | | Bucket Key giảm mạnh số lời gọi | |

Ba lưu ý về truy cập xuyên tài khoản: | Lưu ý | Chi tiết | |---|---| | Cần cả bucket policy VÀ key policy | | | Thiếu key policy = AccessDenied khó hiểu | | | Thông báo lỗi không nhắc gì tới KMS | |

⚠ Đây là lỗi gỡ mất nhiều thời gian nhất:

Bucket policy cho phép tài khoản B
    → nhưng key policy không
        ↓
    Tài khoản B nhận AccessDenied
    → đi soi bucket policy vốn đã đúng

Ba lưu ý về ép mã hoá: | Lưu ý | Chi tiết | |---|---| | Bucket policy từ chối PUT không mã hoá | | | Config rule kiểm tra bucket | | | SCP chặn tạo bucket không mã hoá | |

{"Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::tai-lieu-khach-hang/*",
 "Condition": {"StringNotEquals":
   {"s3:x-amz-server-side-encryption": "aws:kms"}}}

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Customer managed key | ~1 USD/tháng | | 10.000 request KMS | ~0,03 USD | | Bucket Key | giảm tới 99% số request |

Ba lưu ý về bảo vệ khoá: | Lưu ý | Chi tiết | |---|---| | Chặn kms:ScheduleKeyDeletion bằng key policy | | | Thời gian chờ xoá 7-30 ngày | | | Xoá khoá = dữ liệu không đọc được vĩnh viễn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra object có ServerSideEncryption: aws:kms | | | Xem CloudTrail ghi lần dùng khoá | | | Thử với vai trò không có kms:Decrypt | |

aws s3api head-object --bucket tai-lieu-khach-hang --key tai-lieu.pdf \
  --query "[ServerSideEncryption,SSEKMSKeyId]"

Và một lời khuyên: hãy bật S3 Bucket Key ngay khi bật SSE-KMS. Không có nó, mỗi object là một lời gọi KMS khi ghi và một lời gọi nữa khi đọc — với vài triệu tài liệu, đó vừa là một khoản phí đáng kể vừa là con đường ngắn nhất tới lỗi ThrottlingException vào giờ cao điểm.

Đáp án

B — Dựng tầng ứng dụng ở vùng mới, dùng Amazon Aurora Global Database cho CSDL ở cả vùng chính lẫn vùng mới, và dùng Route 53 health check với failover routing để chuyển sang vùng mới; thăng cấp secondary lên primary khi cần.

Vì sao đúng

Đề nêu hai yêu cầu, và Aurora Global Database là công cụ đúng cho cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Tính sẵn sàng tối đa | hai vùng, dữ liệu nhân bản liên tục | | Gián đoạn dịch vụ tối thiểu | RPO ~1 giây, RTO dưới 1 phút |

⚠ Aurora Global Database nhân bản ở TẦNG LƯU TRỮ, không qua truy vấn:

Read replica thường: phát lại giao dịch ở vùng đích
    → tốn CPU của cụm nguồn
    → độ trễ theo tải
        ↓
Global Database: hạ tầng lưu trữ tự nhân bản
    → KHÔNG tốn CPU của cụm chính
    → độ trễ thường dưới 1 giây dù ở châu lục khác

Dựng cụm toàn cầu:

aws rds create-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --source-db-cluster-identifier <arn-cum-chinh>

aws rds create-db-cluster \
  --db-cluster-identifier cum-vung-moi \
  --engine aurora-mysql \
  --global-cluster-identifier cum-toan-cau \
  --region ap-northeast-1

Chuyển đổi khi có sự cố:

# Chuyển đổi có kế hoạch — KHÔNG mất dữ liệu
aws rds failover-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --target-db-cluster-identifier <arn-cum-vung-moi>

# Tách khẩn cấp khi vùng chính không phản hồi
aws rds remove-from-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --db-cluster-identifier <arn-cum-vung-moi>

⚠ Hai lệnh này khác nhau hoàn toàn: | Lệnh | Khi nào | Mất dữ liệu | |---|---|---| | failover-global-cluster | vùng chính còn sống | không | | remove-from-global-cluster | vùng chính đã chết | có thể mất phần chưa nhân bản |

Route 53 failover routing:

aws route53 change-resource-record-sets --hosted-zone-id <id> \
  --change-batch '{"Changes":[{
    "Action":"UPSERT",
    "ResourceRecordSet":{
      "Name":"ung-dung.vidu.com","Type":"A",
      "SetIdentifier":"vung-chinh",
      "Failover":"PRIMARY",
      "HealthCheckId":"<id-health-check>",
      "AliasTarget":{"HostedZoneId":"<id-alb>",
        "DNSName":"alb-chinh.ap-southeast-1.elb.amazonaws.com",
        "EvaluateTargetHealth":true}}}]}'

⚠ TTL của bản ghi quyết định RTO thực tế:

Health check phát hiện trong ~90 giây
    → nhưng client cache DNS theo TTL
        ↓
    TTL 300 giây = thêm 5 phút mới chuyển
    → đặt TTL 60 giây cho bản ghi failover

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | RPO ~1 giây, RTO dưới 1 phút | | | Cụm phụ phục vụ ĐỌC ở vùng mới | giảm độ trễ cho người dùng địa phương | | Không tốn CPU của cụm chính | |

⚠ Cụm phụ dùng được ngay cho tải đọc:

Người dùng ở vùng mới đọc từ cụm phụ
    → độ trễ thấp
    → ghi vẫn đi về vùng chính
        ↓
    Vừa là DR vừa là mở rộng đọc toàn cầu

Vì sao các phương án khác sai

• **A. Aurora read replica xuyên vùng rồi promote khi hỏng — đây là phương án gần nhất và cũng chạy được, nhưng cross-region read replica dùng nhân bản logic: độ trễ cao hơn, tốn tài nguyên cụm nguồn, và thăng cấp chậm hơn Global Database.
• **C. Dựng cụm Aurora mới và dùng DMS nhân bản liên tục — DMS là công cụ di chuyển, không phải cơ chế DR; nó thêm một hệ thống phải vận hành và giám sát, trong khi Aurora đã có tính năng gốc.
• **D. Mở rộng Auto Scaling group hiện có sang vùng mới — ASG không hoạt động xuyên Region; một Auto Scaling group chỉ thuộc về một Region duy nhất.

Ghi nhớ

⚠ Ba cơ chế nhân bản CSDL xuyên vùng — bảng phải thuộc: | Cơ chế | RPO | Tác động lên nguồn | |---|---|---| | Aurora Global Database | ~1 giây | không tốn CPU nguồn | | RDS cross-region read replica | giây - phút | tốn CPU nguồn | | DynamoDB Global Tables | dưới 1 giây, active-active | — | | DMS CDC | giây | tốn tài nguyên nguồn |

Từ khoá nhận diện:

"Aurora, multi-Region DR, RPO 1 second" → Aurora Global Database "active-active writes in multiple Regions" → DynamoDB Global Tables "migrate database between engines" → DMS "failover DNS between Regions" → Route 53 failover routing

⚠ ASG, launch template, AMI đều theo REGION: | Tài nguyên | Phạm vi | |---|---| | Auto Scaling group | một Region | | AMI | một Region — phải copy | | Chứng chỉ ACM | một Region | | Security group | một VPC | | IAM role, S3 bucket name | toàn cầu |

Nhân bản kiến trúc sang vùng mới
    → phải dựng LẠI mọi thứ theo Region
    → dùng CloudFormation StackSets

Ba giới hạn của Aurora Global Database: | Giới hạn | Chi tiết | |---|---| | Chỉ MỘT cụm ghi tại một thời điểm | không phải active-active | | Tới 5 vùng phụ | | | Vùng phụ chỉ đọc cho tới khi thăng cấp | |

⚠ Cần ghi ở nhiều vùng cùng lúc thì Aurora không đáp ứng:

Aurora Global: một writer, nhiều reader vùng
        ↓
DynamoDB Global Tables: GHI ở mọi vùng
    → nhưng phải chấp nhận eventual consistency
      và giải quyết xung đột kiểu "last writer wins"

Ba lưu ý về Route 53 health check: | Lưu ý | Chi tiết | |---|---| | Kiểm tra từ nhiều nơi trên thế giới | | | Cần endpoint công khai hoặc CloudWatch alarm | | | Calculated health check gộp nhiều điều kiện | |

⚠ Health check chỉ kiểm được endpoint CÔNG KHAI:

ALB nội bộ không kiểm trực tiếp được
    → dùng CloudWatch alarm làm nguồn
    → hoặc tạo endpoint kiểm tra riêng

Ba lưu ý về Route 53 ARC: | Tính năng | Việc | |---|---| | Readiness check | vùng DR có SẴN SÀNG không | | Routing control | công tắc chuyển vùng thủ công | | Zonal shift | rút một AZ khỏi lưu lượng |

⚠ Readiness check kiểm cả hạn ngạch và năng lực:

Vùng DR trông sẵn sàng
    → nhưng quota EC2 chỉ đủ 8 máy trong khi cần 20
        ↓
    Readiness check phát hiện trước khi cần dùng

Ba thứ phải chuẩn bị ở vùng mới: | Thứ | Hậu quả nếu quên | |---|---| | AMI đã copy | ASG không khởi động nổi máy | | Chứng chỉ ACM | HTTPS không hoạt động | | Hạn ngạch tài khoản | không mở rộng đủ |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Cụm phụ tính phí instance đầy đủ | | | Phí nhân bản theo triệu I/O | | | Phí truyền dữ liệu xuyên vùng | |

Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | failover-global-cluster không mất dữ liệu | | | Diễn tập ít nhất 2 lần/năm | | | Đo RTO thật, đừng ước lượng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ nhân bản | AuroraGlobalDBReplicationLag | | Chạy failover có kế hoạch | | | Kiểm tra Route 53 chuyển đúng | |

aws cloudwatch get-metric-statistics --namespace AWS/RDS \
  --metric-name AuroraGlobalDBReplicationLag \
  --dimensions Name=DBClusterIdentifier,Value=cum-vung-moi \
  --start-time 2026-08-30T00:00:00Z --end-time 2026-08-30T01:00:00Z \
  --period 300 --statistics Average

Và một lời khuyên: hãy đặt TTL 60 giây cho bản ghi failover trước khi thử đo RTO. Aurora chuyển vùng trong chưa tới một phút, nhưng nếu bản ghi DNS vẫn dùng TTL mặc định thì con số RTO bạn đo được sẽ do trình phân giải DNS quyết định chứ không phải do CSDL.

Đáp án

D — Lưu dữ liệu ở S3 Standard trong 90 ngày rồi chuyển sang S3 Glacier Deep Archive.

Vì sao đúng

Đề mô tả hai giai đoạn rất rõ, và mỗi giai đoạn có một lớp lưu trữ đúng: | Giai đoạn | Đặc điểm | Lớp | |---|---|---| | 90 ngày đầu | truy cập THƯỜNG XUYÊN | S3 Standard | | Bảy năm sau đó | giữ để tuân thủ, HIẾM khi đọc | Glacier Deep Archive |

⚠ Deep Archive là lớp rẻ nhất, và bảy năm là quãng đủ dài để khoản chênh rất lớn: | Lớp | Giá/GB-tháng | 1 TB × 7 năm | |---|---|---| | S3 Standard | ~0,023 USD | ~1.930 USD | | Standard-IA | ~0,0125 USD | ~1.050 USD | | Glacier Deep Archive | ~0,00099 USD | ~83 USD |

Rẻ hơn Standard khoảng 23 lần
    → với dữ liệu tuân thủ giữ nhiều năm,
      đây là khoản tiết kiệm lớn nhất trong S3

Lifecycle policy:

aws s3api put-bucket-lifecycle-configuration \
  --bucket du-lieu-suc-khoe \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "tuan-thu-7-nam",
      "Filter": {"Prefix": ""},
      "Status": "Enabled",
      "Transitions": [{
        "Days": 90,
        "StorageClass": "DEEP_ARCHIVE"}],
      "Expiration": {"Days": 2645}}]}'

⚠ Expiration 2645 ngày ≈ 7 năm 90 ngày — tự xoá sau khi hết hạn tuân thủ, tránh trả tiền vô thời hạn.

Ba điều kiện phải thoả để Deep Archive hợp: | Điều kiện | Đề có thoả | |---|---| | Lưu tối thiểu 180 ngày | ✅ giữ 7 năm | | Chấp nhận chờ 12-48 giờ khi lấy | ✅ "rarely accessed" | | Object không quá nhỏ | cần kiểm tra |

⚠ Thời gian lấy dữ liệu là đánh đổi phải chấp nhận: | Chế độ | Thời gian | |---|---| | Standard | ~12 giờ | | Bulk | ~48 giờ, rẻ nhất |

Kiểm toán viên yêu cầu hồ sơ
    → phải chờ tới nửa ngày
        ↓
    Chấp nhận được cho tuân thủ,
    KHÔNG chấp nhận được cho vận hành hằng ngày

Khôi phục object:

aws s3api restore-object --bucket du-lieu-suc-khoe \
  --key ho-so/2026/benh-nhan-123.pdf \
  --restore-request '{"Days":7,"GlacierJobParameters":{"Tier":"Bulk"}}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chi phí lưu trữ thấp nhất của AWS | | | Vẫn 11 số 9 độ bền | | | Chuyển lớp tự động, không cần mã | |

Vì sao các phương án khác sai

• **A. Intelligent-Tiering 90 ngày rồi chuyển sang Standard-IA — đây là phương án gần nhất và cũng giảm chi phí, nhưng sai hướng: Standard-IA đắt hơn Deep Archive khoảng 12 lần, quá tốn cho dữ liệu giữ bảy năm mà hiếm khi đọc. (Và dùng Intelligent-Tiering cho giai đoạn "truy cập thường xuyên" là thừa phí giám sát.)
• **B. Standard 90 ngày rồi REDUCED_REDUNDANCY — RRS đã lỗi thời, AWS không khuyến nghị; nó có độ bền THẤP HƠN và thực tế còn đắt hơn Standard ở nhiều Region.
• **C. Standard 90 ngày rồi xoá dữ liệu — vi phạm thẳng yêu cầu giữ bảy năm để tuân thủ.

Ghi nhớ

⚠ Các lớp lưu trữ S3 — bảng phải thuộc: | Lớp | Lưu tối thiểu | Thời gian lấy | Giá tương đối | |---|---|---|---| | Standard | không | tức thì | 100% | | Intelligent-Tiering | không | tức thì | ~100% + phí giám sát | | Standard-IA | 30 ngày | tức thì | ~54% | | One Zone-IA | 30 ngày | tức thì | ~43% | | Glacier Instant Retrieval | 90 ngày | mili giây | ~17% | | Glacier Flexible Retrieval | 90 ngày | phút - giờ | ~16% | | Glacier Deep Archive | 180 ngày | 12-48 giờ | ~4% |

Từ khoá nhận diện:

"compliance retention for years, rarely accessed" → Deep Archive "archive but need millisecond access" → Glacier Instant Retrieval "unknown access pattern" → Intelligent-Tiering "infrequent but immediate access" → Standard-IA

⚠ Ba lớp Glacier khác nhau ở THỜI GIAN LẤY, không phải độ bền:

Cả ba đều 11 số 9 độ bền
    → khác nhau ở chờ bao lâu và giá bao nhiêu
        ↓
    Instant: mili giây, đắt nhất trong ba
    Flexible: phút tới giờ
    Deep Archive: 12-48 giờ, rẻ nhất

Ba lưu ý về phí xoá sớm: | Lớp | Xoá trước hạn | |---|---| | Standard-IA | tính đủ 30 ngày | | Glacier Flexible | tính đủ 90 ngày | | Deep Archive | tính đủ 180 ngày |

⚠ Object nhỏ có thể ĐẮT HƠN ở lớp lưu trữ:

Mỗi object Glacier tốn thêm ~40 KB siêu dữ liệu
    + kích thước tính phí tối thiểu 128 KB (IA)
        ↓
    Tệp 10 KB ở Deep Archive
    → tính tiền như 50 KB
    → chuyển hàng triệu tệp nhỏ có thể lỗ

{"Filter": {"And": {"Prefix": "", "ObjectSizeGreaterThan": 131072}}}

Ba lưu ý về phí chuyển lớp: | Lưu ý | Chi tiết | |---|---| | Tính theo SỐ OBJECT, không theo GB | | | ~0,05 USD mỗi 1000 object sang Deep Archive | | | Triệu object = ~50 USD phí chuyển | |

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | Object Lock chế độ Compliance chống xoá | | | Versioning bảo vệ khỏi ghi đè | | | Ghi tài liệu chính sách lưu giữ | |

⚠ Với dữ liệu y tế bảy năm, Object Lock đáng cân nhắc:

aws s3api put-object-retention --bucket du-lieu-suc-khoe \
  --key ho-so/benh-nhan-123.pdf \
  --retention 'Mode=COMPLIANCE,RetainUntilDate=2033-08-30T00:00:00Z'

Chế độ COMPLIANCE: KHÔNG AI xoá được, kể cả root
    → đúng yêu cầu tuân thủ
    → nhưng không đảo ngược được, phải chắc chắn

Ba lưu ý về HIPAA (dữ liệu y tế): | Lưu ý | Chi tiết | |---|---| | Ký BAA với AWS | | | Mã hoá at rest và in transit | | | Bật CloudTrail data event cho bucket | |

Ba lưu ý về khôi phục: | Lưu ý | Chi tiết | |---|---| | Object khôi phục là BẢN SAO TẠM | | | Đặt Days là số ngày giữ bản tạm | | | Bản gốc vẫn ở Deep Archive | |

Ba lưu ý về theo dõi: | Công cụ | Việc | |---|---| | S3 Storage Lens | phân bố theo lớp | | S3 Inventory | danh sách object và lớp | | Cost Explorer lọc theo usage type | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra object cũ đã chuyển lớp | | | Thử khôi phục một object | | | So hoá đơn trước và sau | |

aws s3api list-objects-v2 --bucket du-lieu-suc-khoe --max-items 5 \
  --query "Contents[].[Key,StorageClass,Size]" --output table

Và một lời khuyên: hãy thêm quy tắc Expiration cùng lúc với quy tắc chuyển lớp. Yêu cầu tuân thủ nói giữ bảy năm chứ không nói giữ mãi mãi, và không có quy tắc xoá thì dữ liệu năm thứ tám vẫn nằm đó tính tiền — cùng với rủi ro pháp lý của việc giữ hồ sơ y tế lâu hơn mức được phép.

Đáp án

A — Tạo một NAT gateway trong subnet công khai của MỖI AZ, và cập nhật route table của từng subnet riêng tư trỏ lưu lượng ra Internet tới NAT gateway đó.

Vì sao đúng

Đề nêu hai yêu cầu, và chi tiết "mỗi AZ" là chỗ quyết định: | Yêu cầu | Cách đáp ứng | |---|---| | Máy riêng tư gọi API ra Internet | NAT gateway cho phép kết nối ĐI RA | | Kết nối SẴN SÀNG CAO | một NAT gateway mỗi AZ |

⚠ NAT gateway nằm TRONG MỘT AZ — đây là điều phải nhớ:

Một NAT gateway dùng chung cho cả ba AZ
    → AZ chứa nó hỏng
        ↓
    CẢ BA AZ mất kết nối Internet
    → kiến trúc "sẵn sàng cao" sụp vì một điểm hỏng

Kiến trúc đúng:

AZ-a: subnet công khai → NAT gateway A
      subnet riêng tư  → route table A → NAT gateway A
AZ-b: subnet công khai → NAT gateway B
      subnet riêng tư  → route table B → NAT gateway B
AZ-c: subnet công khai → NAT gateway C
      subnet riêng tư  → route table C → NAT gateway C

Dựng:

for az in a b c; do
  eip=$(aws ec2 allocate-address --domain vpc \
        --query AllocationId --output text)
  nat=$(aws ec2 create-nat-gateway \
        --subnet-id subnet-cong-khai-$az \
        --allocation-id $eip \
        --query NatGateway.NatGatewayId --output text)
  aws ec2 create-route --route-table-id rtb-rieng-tu-$az \
    --destination-cidr-block 0.0.0.0/0 --nat-gateway-id $nat
done

⚠ Mỗi subnet riêng tư phải có route table RIÊNG:

Ba subnet riêng tư dùng CHUNG một route table
    → cả ba trỏ vào cùng một NAT gateway
        ↓
    Vẫn là một điểm hỏng, dù đã tạo ba NAT gateway

Lợi ích thứ hai — tránh phí liên AZ:

Máy ở AZ-a đi qua NAT gateway ở AZ-b
    → tính phí truyền dữ liệu liên AZ (~0,01 USD/GB mỗi chiều)
        ↓
    Trỏ về NAT cùng AZ: không có khoản đó

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | AZ hỏng chỉ ảnh hưởng AZ đó | | | Không có phí truyền liên AZ | | | AWS quản lý, tự mở rộng tới 100 Gbps | |

Vì sao các phương án khác sai

• **D. Tạo một NAT gateway gắn vào VPC và trỏ mọi route table riêng tư vào nó — đây là phương án gần nhất và cũng cho kết nối ra Internet, nhưng NAT gateway thuộc về một SUBNET chứ không phải gắn vào VPC, và dùng chung một cái là một điểm hỏng duy nhất — vi phạm "highly available".
• **C. Tạo NAT instance trong subnet RIÊNG TƯ của mỗi AZ — sai hai chỗ: NAT phải nằm ở subnet công khai mới ra được Internet, và NAT instance là cách cũ phải tự vá, tự lo HA.
• **B. Cấu hình internet gateway và thêm route vào route table riêng tư — máy trong subnet riêng tư không có IP công khai, nên riêng internet gateway không giúp chúng ra ngoài; và thêm route đó biến subnet thành công khai về mặt định tuyến.

Ghi nhớ

⚠ Ba cấu phần định tuyến ra Internet — bảng phải thuộc: | Cấu phần | Việc | |---|---| | Internet gateway | cho phép VPC nói chuyện với Internet | | NAT gateway | máy riêng tư ĐI RA, không ai vào được | | Egress-only internet gateway | như NAT nhưng cho IPv6, MIỄN PHÍ |

⚠ Định nghĩa subnet công khai và riêng tư:

Subnet CÔNG KHAI:  route table có 0.0.0.0/0 → internet gateway
Subnet RIÊNG TƯ:   route table KHÔNG có tuyến đó
        ↓
    Không có cờ "public/private" nào cả
    → chỉ là route table khác nhau

Từ khoá nhận diện:

"private instances need outbound internet, highly available" → NAT gateway mỗi AZ "IPv6 outbound only" → egress-only internet gateway "reach AWS services without internet" → VPC endpoint "instance needs inbound from internet" → public subnet + IGW

⚠ NAT gateway vs NAT instance: | Tiêu chí | NAT gateway | NAT instance | |---|---|---| | Quản lý | AWS | bạn | | Băng thông | 5 → 100 Gbps tự động | theo cỡ máy | | Security group | KHÔNG gắn được | gắn được | | Bastion / port forwarding | ❌ | ✅ |

Ba khoản chi phí NAT gateway: | Khoản | Giá tham khảo | |---|---| | Phí giờ | ~0,045 USD/giờ (~32 USD/tháng) | | Phí xử lý dữ liệu | ~0,045 USD/GB | | Nhân số AZ | 3 AZ ≈ 100 USD/tháng tiền giờ |

⚠ Phí xử lý dữ liệu là chỗ hoá đơn nổ:

Ứng dụng tải 10 TB từ S3 qua NAT gateway
    → 10.000 GB × 0,045 = 450 USD mỗi tháng
        ↓
    S3 Gateway Endpoint: MIỄN PHÍ hoàn toàn

Ba VPC endpoint nên có để giảm phí NAT: | Endpoint | Loại | Phí | |---|---|---| | S3 | Gateway | miễn phí | | DynamoDB | Gateway | miễn phí | | ECR, SSM, Secrets Manager | Interface | có phí |

⚠ Nếu chỉ cần Systems Manager thì có thể bỏ hẳn NAT:

Ba endpoint: ssm, ssmmessages, ec2messages
    → vá được, chạy lệnh được, Session Manager được
        ↓
    Không cần NAT gateway

Ba giới hạn của NAT gateway: | Giới hạn | Giá trị | |---|---| | Kết nối đồng thời mỗi đích | ~55.000 | | Vượt thì lỗi ErrorPortAllocation | | | Chia tải ra nhiều NAT gateway | |

Ba lưu ý về Elastic IP: | Lưu ý | Chi tiết | |---|---| | Mỗi NAT gateway cần một EIP | | | EIP là IP đi ra — dùng để đưa vào allowlist | | | Nhiều NAT = nhiều IP phải khai báo | |

⚠ Đối tác thường yêu cầu allowlist IP:

Ba NAT gateway = ba IP khác nhau
    → phải khai cả ba cho đối tác
        ↓
    Quên một cái = lỗi ngẫu nhiên tuỳ AZ
      máy nào đang chạy

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | ErrorPortAllocation | cạn cổng | | BytesOutToDestination | lưu lượng ra | | PacketsDropCount | |

Ba lưu ý về IPv6: | Lưu ý | Chi tiết | |---|---| | NAT gateway chỉ cho IPv4 | | | IPv6 dùng egress-only internet gateway | | | Egress-only MIỄN PHÍ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl ra Internet từ máy riêng tư mỗi AZ | | | Kiểm tra mỗi route table trỏ NAT cùng AZ | | | Thử kết nối từ ngoài vào | phải bị chặn |

aws ec2 describe-route-tables \
  --filters Name=tag:Loai,Values=rieng-tu \
  --query "RouteTables[].[Tags[?Key=='Name']|[0].Value,
    Routes[?DestinationCidrBlock=='0.0.0.0/0'].NatGatewayId|[0]]" \
  --output table

Và một lời khuyên: hãy tạo S3 Gateway Endpoint cùng lúc với NAT gateway. Nó miễn phí và mất một lệnh, nhưng ở phần lớn kiến trúc thì lưu lượng S3 chính là phần lớn nhất của hoá đơn xử lý dữ liệu NAT — và với ba NAT gateway thì khoản đó được nhân lên ba lần cơ hội để lãng phí.

Đáp án

B — Tạo một service control policy (SCP) ở root organizational unit để từ chối truy cập các dịch vụ hoặc hành động đó.

Vì sao đúng

Đề nêu ba yêu cầu, và SCP là công cụ duy nhất đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Giới hạn API cụ thể trên MỌI tài khoản | SCP áp cho toàn tổ chức | | Kiểm soát TẬP TRUNG | viết một lần ở root OU | | ĐƠN GIẢN nhất | không phải đụng vào từng tài khoản |

⚠ SCP đặt ở root OU áp cho MỌI tài khoản, kể cả tài khoản tạo sau:

IAM policy: phải gắn vào từng user, group, role
    → tài khoản mới = phải nhớ gắn lại
        ↓
SCP ở root: tự động áp cho tài khoản mới gia nhập
    → không ai phải nhớ gì

SCP mẫu:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChanHanhDongNhayCam",
   "Effect": "Deny",
   "Action": ["ec2:DeleteVpc",
              "cloudtrail:StopLogging",
              "cloudtrail:DeleteTrail",
              "config:DeleteConfigurationRecorder",
              "guardduty:DeleteDetector"],
   "Resource": "*"}]}

aws organizations create-policy --name chan-hanh-dong-nhay-cam \
  --type SERVICE_CONTROL_POLICY \
  --content file://scp.json

aws organizations attach-policy --policy-id p-abc \
  --target-id r-root-id

⚠ SCP là HÀNG RÀO, không phải cấp quyền:

SCP KHÔNG cấp quyền cho ai cả
    → nó chỉ giới hạn quyền TỐI ĐA
        ↓
    Quyền hiệu lực = IAM policy ∩ SCP
    → SCP Deny thì không IAM policy nào vượt qua được

⚠ SCP chặn được cả người dùng root của tài khoản thành viên:

Đây là điều IAM policy KHÔNG làm được
    → root của tài khoản thành viên bỏ qua mọi IAM policy
    → nhưng KHÔNG bỏ qua được SCP
        ↓
    Đây là lý do SCP là cơ chế kiểm soát thật sự

Ba ngoại lệ SCP không áp: | Ngoại lệ | Chi tiết | |---|---| | Management account | SCP KHÔNG áp cho nó | | Service-linked role | | | Hành động ngoài phạm vi Organizations | |

⚠ Management account không bị SCP kiểm soát:

Đừng chạy tải sản xuất trong management account
    → nó nằm ngoài mọi hàng rào SCP
        ↓
    Giữ nó sạch, chỉ dùng để quản trị tổ chức

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một chỗ định nghĩa, áp cho tất cả | | | Không ai gỡ được từ tài khoản thành viên | | | Tài khoản mới tự động được áp | |

Vì sao các phương án khác sai

• **A. Tạo IAM policy ở tài khoản root rồi gắn cho user và group ở mỗi tài khoản — đây là phương án gần nhất và cũng hạn chế được, nhưng IAM policy không chia sẻ giữa các tài khoản: phải tạo lại và gắn thủ công ở từng nơi, và người có quyền quản trị ở tài khoản đó có thể gỡ ra.
• **D. Tạo cross-account role ở mỗi tài khoản — vai trò xuyên tài khoản là cơ chế cấp quyền truy cập, không phải cơ chế giới hạn; và vẫn phải dựng ở từng tài khoản.
• **C. Tạo Network ACL giới hạn dịch vụ — NACL lọc lưu lượng mạng theo IP và cổng ở tầng subnet; nó không biết gì về API AWS.

Ghi nhớ

⚠ Bốn cơ chế kiểm soát quyền — bảng phải thuộc: | Cơ chế | Phạm vi | Cấp quyền | |---|---|---| | SCP | tài khoản trong tổ chức | KHÔNG — chỉ giới hạn | | IAM policy | user, group, role | có | | Resource policy | tài nguyên cụ thể | có | | Permissions boundary | một identity | KHÔNG — chỉ giới hạn |

Từ khoá nhận diện:

"restrict actions across all accounts centrally" → SCP "grant permissions to a user" → IAM policy "limit max permissions a role can have" → permissions boundary "who can access this bucket" → resource policy

⚠ Hai chiến lược viết SCP: | Chiến lược | Cách làm | |---|---| | Deny list | giữ FullAWSAccess, thêm statement Deny | | Allow list | gỡ FullAWSAccess, chỉ Allow thứ cần |

Deny list: đơn giản, ít rủi ro khoá nhầm
Allow list: chặt hơn nhưng dễ chặn nhầm dịch vụ
        ↓
    Phần lớn tổ chức bắt đầu bằng deny list

Ba SCP nên có sớm: | SCP | Chặn gì | |---|---| | Chặn tắt CloudTrail, Config, GuardDuty | | | Giới hạn Region được dùng | | | Chặn xoá tài nguyên bảo mật | |

Giới hạn Region:

{"Effect": "Deny",
 "NotAction": ["iam:*", "organizations:*", "route53:*",
               "cloudfront:*", "support:*", "s3:GetAccountPublicAccessBlock"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:RequestedRegion": ["ap-southeast-1", "ap-northeast-1"]}}}

⚠ NotAction liệt kê dịch vụ TOÀN CẦU — thiếu là hỏng nghiêm trọng:

IAM, Organizations, Route 53, CloudFront là dịch vụ toàn cầu
    → endpoint của chúng ở us-east-1
        ↓
    Chặn us-east-1 mà quên loại trừ chúng
    → không tạo được IAM role nào nữa

Ba lưu ý về kế thừa SCP: | Lưu ý | Chi tiết | |---|---| | SCP kế thừa từ root xuống OU con | | | Quyền hiệu lực là GIAO của mọi cấp | | | Một Deny ở bất kỳ cấp nào là chặn | |

⚠ Cấu trúc OU quyết định độ linh hoạt:

Root
 ├── OU Sản xuất    → SCP chặt
 ├── OU Phát triển  → SCP lỏng hơn
 └── OU Sandbox     → SCP rất lỏng, có budget action
        ↓
    Thiết kế OU theo MỨC KIỂM SOÁT,
    không theo phòng ban

Ba lưu ý về giới hạn: | Giới hạn | Giá trị | |---|---| | Kích thước SCP | 5.120 byte | | SCP gắn mỗi thực thể | 5 | | Độ sâu OU | 5 cấp |

Ba lưu ý về kiểm thử: | Lưu ý | Chi tiết | |---|---| | Thử ở OU sandbox trước | | | Dùng CloudTrail xem hành động bị chặn | | | errorCode là AccessDenied với ghi chú implicit deny | |

⚠ Lỗi do SCP rất khó chẩn đoán:

Thông báo chỉ nói AccessDenied
    → không nói "bị SCP chặn"
        ↓
    Người gỡ lỗi soi IAM policy vốn đã đúng
    → luôn kiểm tra SCP khi IAM có vẻ đúng mà vẫn bị từ chối

Ba lưu ý về Organizations: | Lưu ý | Chi tiết | |---|---| | Phải bật ALL features, không phải chỉ consolidated billing | | | SCP chỉ dùng được khi bật all features | | | Control Tower dựng sẵn nhiều guardrail | |

aws organizations describe-organization \
  --query "Organization.FeatureSet"

Ba lưu ý về công cụ bổ trợ: | Công cụ | Việc | |---|---| | Control Tower | guardrail dựng sẵn | | Config conformance pack | phát hiện vi phạm | | Access Analyzer | quyền thừa |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử hành động bị chặn từ tài khoản thành viên | | | Kiểm tra management account KHÔNG bị áp | | | Xem CloudTrail ghi từ chối | |

Và một lời khuyên: hãy liệt kê đầy đủ dịch vụ toàn cầu trong NotAction trước khi gắn bất kỳ SCP giới hạn Region nào. Thiếu iam:* trong danh sách đó là cách nhanh nhất để khoá chính mình ra khỏi khả năng sửa chữa — và cách chữa duy nhất là dùng management account, thứ mà nhiều tổ chức cố tình hạn chế truy cập.

Đáp án

D — Amazon EBS General Purpose SSD (gp2).

Vì sao đúng

Đề cho ba dữ kiện, và cả ba đều nằm gọn trong vùng hoạt động của General Purpose SSD: | Dữ kiện | Ý nghĩa | |---|---| | Dùng THƯA THỚT, chỉ cao điểm sáng và tối | tải bùng nổ — hợp mô hình credit của gp2 | | I/O biến động, đỉnh tới 3.000 IOPS | gp2 đạt tới 16.000 IOPS | | RẺ NHẤT có thể | SSD rẻ nhất, không phải trả phí IOPS riêng |

⚠ Mô hình credit của gp2 hợp chính xác với tải bùng nổ:

Lúc rảnh: tích luỹ I/O credit
    ↓ cao điểm sáng
Tiêu credit để đạt tới 3.000 IOPS
    ↓ rảnh cả ngày
Tích lại credit
    ↓ cao điểm tối
Tiêu tiếp

Công thức IOPS của gp2:

IOPS cơ sở = 3 × dung lượng (GiB), tối thiểu 100
Burst = 3.000 IOPS cho volume dưới 1 TiB
        ↓
    Volume 100 GiB: cơ sở 300 IOPS, burst 3.000
    → đủ cho đỉnh của đề

⚠ Volume từ 1.000 GiB trở lên có 3.000 IOPS LIÊN TỤC:

1000 GiB × 3 = 3.000 IOPS cơ sở
    → không còn phụ thuộc credit nữa
        ↓
    Đây là ngưỡng đáng nhớ khi thiết kế

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không trả phí IOPS riêng như io1/io2 | | | Đủ hiệu năng cho đỉnh 3.000 IOPS | | | Dùng làm volume khởi động được | |

Ghi nhớ về chất lượng câu hỏi

⚠ Câu trả lời đúng ngày nay là gp3, không phải gp2.

gp3 ra mắt cuối 2020 và thay thế gp2 ở mọi phương diện cho tình huống này:

Đề nói: đỉnh tới 3.000 IOPS, cần rẻ nhất
        ↓
    gp3 cho ĐÚNG 3.000 IOPS làm mức cơ bản,
    không phụ thuộc credit, và rẻ hơn gp2 20%
        ↓
    gp2 chỉ đạt 3.000 IOPS bằng cách TIÊU CREDIT
    → cạn credit là tụt xuống mức cơ sở

⚠ Rủi ro thật của gp2 trong đề này — cạn credit:

aws cloudwatch get-metric-statistics --namespace AWS/EBS \
  --metric-name BurstBalance --dimensions Name=VolumeId,Value=vol-abc \
  --start-time 2026-08-30T00:00:00Z --end-time 2026-08-30T12:00:00Z \
  --period 300 --statistics Minimum

Cao điểm sáng kéo dài hơn dự kiến
    → BurstBalance về 0
    → IOPS tụt về 3 × GiB
        ↓
    Ứng dụng chậm đột ngột mà cấu hình không đổi gì

Nói rõ điều này vì gặp tình huống tương tự ngoài đời, hãy chọn gp3 — nó không có khái niệm credit nên không có kiểu sự cố đó.

Vì sao các phương án khác sai

• **A. Provisioned IOPS SSD (io1) — đây là phương án gần nhất về mặt chắc chắn đạt 3.000 IOPS, nhưng đắt hơn nhiều: vừa trả tiền dung lượng cao hơn vừa trả phí riêng cho mỗi IOPS cấp phát. Thừa cho tải chỉ bùng nổ vài giờ mỗi ngày.
• **B. Throughput Optimized HDD (st1) — HDD chỉ đạt ~500 IOPS, không đủ cho đỉnh 3.000; và HDD kém với I/O ngẫu nhiên.
• **C. Cold HDD (sc1) — chỉ ~250 IOPS, còn kém hơn st1; dành cho dữ liệu hiếm khi truy cập.

Ghi nhớ

⚠ Bốn loại EBS và giới hạn IOPS — bảng phải thuộc: | Loại | IOPS tối đa | Giá tương đối | |---|---|---| | gp3 | 16.000 | thấp nhất trong SSD | | gp2 | 16.000 (qua credit) | +20% so với gp3 | | io2 Block Express | 256.000 | cao nhất | | st1 | ~500 | thấp | | sc1 | ~250 | thấp nhất |

Từ khoá nhận diện:

"variable I/O, bursty, cost-effective" → gp3 (đề cũ: gp2) "consistent high IOPS, database" → io2 "sequential, frequently accessed, big data" → st1 "sequential, rarely accessed, cheapest" → sc1

⚠ Ba mức IOPS đáng nhớ: | Mức | Loại phù hợp | |---|---| | Dưới 3.000 | gp3 (miễn phí ở mức cơ bản) | | 3.000 – 16.000 | gp3 với IOPS bổ sung | | Trên 16.000 | io2 |

Ba lưu ý về chuyển từ gp2 sang gp3: | Lưu ý | Chi tiết | |---|---| | Đổi được khi volume đang chạy | | | Không cần dừng máy | | | Giữ nguyên dữ liệu | |

aws ec2 modify-volume --volume-id vol-abc \
  --volume-type gp3 --iops 3000 --throughput 125

⚠ Đây là một trong những cách tiết kiệm dễ nhất trên AWS:

Chuyển toàn bộ gp2 sang gp3
    → giảm ~20% chi phí lưu trữ khối
    → không gián đoạn, không rủi ro
        ↓
    Tìm mọi volume gp2 còn lại:

aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 \
  --query "Volumes[].[VolumeId,Size,State]" --output table

Ba lưu ý về credit của gp2: | Lưu ý | Chi tiết | |---|---| | Volume mới bắt đầu với 5,4 triệu credit | | | Theo dõi BurstBalance | | | Volume ≥ 1.000 GiB không cần credit | |

Ba lưu ý về giới hạn của instance: | Lưu ý | Chi tiết | |---|---| | Instance có trần băng thông EBS riêng | | | Máy nhỏ nghẽn trước volume | | | Bật EBS-optimized | mặc định trên máy đời mới |

⚠ Nút thắt có thể ở máy chứ không ở đĩa:

Volume gp3 16.000 IOPS gắn vào t3.small
    → t3.small chỉ đạt vài nghìn IOPS
        ↓
    Kiểm tra thông số EBS của loại instance
    trước khi đổ lỗi cho volume

Ba lưu ý về đo hiệu năng: | Metric | Ý nghĩa | |---|---| | VolumeReadOps / VolumeWriteOps | IOPS thật | | BurstBalance | credit còn lại (gp2) | | VolumeQueueLength | hàng đợi — cao là nghẽn |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo GB CẤP PHÁT, không phải GB dùng | | | io1/io2 tính thêm phí mỗi IOPS | | | Volume không gắn vào máy nào vẫn tính tiền | |

Ba lưu ý về mở rộng: | Lưu ý | Chi tiết | |---|---| | Tăng dung lượng được, KHÔNG giảm được | | | Phải mở rộng hệ thống tệp sau khi tăng | | | Chờ tối thiểu 6 giờ giữa hai lần đổi | |

sudo growpart /dev/nvme0n1 1
sudo xfs_growfs /

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo IOPS thật trong giờ cao điểm | | | Theo dõi BurstBalance nếu dùng gp2 | | | So chi phí gp2 và gp3 | |

Và một lời khuyên: hãy chuyển mọi volume gp2 sang gp3 khi có dịp. Với đúng tình huống của đề này — tải bùng nổ tới 3.000 IOPS — gp3 cho mức đó làm hiệu năng cơ bản thay vì phải tiêu credit, đồng thời rẻ hơn 20%; đây là trường hợp hiếm hoi vừa nhanh hơn vừa rẻ hơn.