GĐ32 — AWS SAA: Cost Optimization, Operations, Migration và Reference

Mục tiêu: so tổng chi phí theo workload, chọn đường migration và có bản đồ tra cứu dịch vụ. Đọc sau GĐ31; áp dụng cho project thực hành ở GĐ33.

Kiểm chứng ngày 2026-10-05 (đọc tài liệu AWS; cờ CLI chỉ kiểm bằng aws ... help, chưa chạy trên AWS; phép tính chạy bằng Node với đơn giá giả định, không phải giá AWS): Free Plan, NAT gateway so với NAT instance, tạo NAT instance, change set, xem change set, Requester Pays, danh sách in-scope, danh sách out-of-scope, Amazon Quick, Elastic Transcoder, Snow Family. Các mục viết từ trước giữ nguồn riêng ở cuối mỗi mục.

1. Tính tổng chi phí thay vì chỉ giá máy#

Mô hình tự xây để học, không phải bảng giá AWS (ví dụ có số nằm ở mục con "Ví dụ có số: ba phương án cùng yêu cầu" bên dưới):

Monthly total ≈ compute + storage + database + load balancer              + requests + data transfer + network gateways/endpoints              + logs/metrics/traces + backups + các dịch vụ phụ trợ

Ví dụ giả định: một app có 200 GB file nhưng mỗi tháng tải ra 5 TB; tiền lưu không nói lên tổng chi phí. App nhỏ chạy private có ALB, NAT và nhiều interface endpoints có thể chịu fixed cost cao hơn compute.

Lập hai phương án cùng yêu cầu và cùng lượng tải. Tính bình thường/peak, một tháng và một năm; ghi Region, ngày lấy giá, giả định và phần chưa tính. Dùng AWS Pricing Calculator và pricing page từng dịch vụ. Không suy ra “mọi lab miễn phí” từ nhãn Free Tier.

Ví dụ có số: ba phương án cùng yêu cầu#

Yêu cầu chung: API chạy 24/7, chịu mất một AZ, log giữ ngắn hạn, mỗi request gọi một lần đọc dữ liệu. Ba phương án:

• A: API Gateway + Lambda + DynamoDB on-demand (không có chi phí cố định đáng kể).
• B: ALB + 2 task Fargate (2 AZ) + RDS Multi-AZ, giá On-Demand.
• C: ALB + 2 EC2 (2 AZ) + RDS Multi-AZ, compute có cam kết 1 năm.

Giả định (đã tính bằng Node; chỉ đơn giá Lambda lấy từ trang giá Lambda cho x86 us-east-1: 0,0000166667 USD/GB-giây và 0,20 USD/triệu request; mọi đơn giá còn lại là số giả định để tập tính, không phải giá AWS):

Kết quả (USD/tháng; R là triệu request/tháng):

Chi phí cố định (chưa tính log) là 135,84 cho B và 121,09 cho C; A tốn 2,28 USD mỗi triệu request ngoài log. Hòa vốn A với C là 121,09 / 2,28 ≈ 53 triệu request/tháng, A với B là 135,84 / 2,28 ≈ 59,5. Nhạy cảm với giả định: nếu mỗi request dùng 1024 MB và 200 ms (0,2 GB-giây), A tốn 4,78 USD mỗi triệu request và hòa vốn với C giảm còn khoảng 25 triệu. Phần chưa tính: egress Internet, storage DynamoDB, NAT/endpoint, backup, public IPv4, công vá lỗi của C, công vận hành. Đọc kết quả như một cách suy nghĩ về hình dạng đường chi phí, không phải kết luận "serverless rẻ hơn" hay "container rẻ hơn".

Free Plan của tài khoản mới#

Đọc đúng điều khoản của gói đang áp dụng cho tài khoản bạn, đừng suy từ nhãn "Free Tier" trên từng dịch vụ. Theo trang AWS Free (đọc ngày 2026-10-05): khách mới nhận 100 USD credit ngay và có thể kiếm thêm tối đa 100 USD, tổng tối đa 200 USD trong 6 tháng; gói Free chỉ dùng được một số dịch vụ, còn gói Paid dùng được mọi dịch vụ; tài khoản ở gói Free tự đóng sau 6 tháng hoặc khi hết credit, tùy cái nào đến trước, và chỉ bị tính tiền nếu bạn chuyển sang Paid. Điều kiện chi tiết, ngày bắt đầu áp dụng và dịch vụ nào bị loại: đọc lại trang trước khi lập tài khoản (chưa xác minh trong tài liệu này). Với bài học này: lab nào cần dịch vụ ngoài danh sách của gói Free thì phải chuyển Paid và chịu phí thật, nên đặt Budget trước (mục 5) và dọn tài nguyên sau mỗi lab.

2. Compute purchasing: giảm giá khác giữ capacity#

Spot phù hợp worker có queue/checkpoint, không phù hợp làm bản duy nhất của một database không chịu gián đoạn. Savings Plans không đồng nghĩa AWS dành sẵn capacity cho bạn. Right-size trước khi cam kết dài hạn; mua discount cho tài nguyên đang lãng phí vẫn là lãng phí.

Nguồn: EC2 purchasing options, Savings Plans, Capacity Reservations.

3. Storage và database cost#

Với S3, tính storage + request + retrieval + transfer + lifecycle transition và các phí áp dụng. Xóa object sớm có thể vẫn chịu minimum storage duration. File nhỏ rất nhiều cần xét minimum billable size và request count. Versioning/replication có thể tăng bản dữ liệu được tính phí.

Với SQL, đo CPU/RAM/IOPS/query plan trước khi tăng instance. Read replica chỉ có lợi khi thật sự chuyển read workload sang nó. Chọn Multi-AZ vì yêu cầu availability, không xem standby như tài nguyên “thừa” rồi bỏ để giảm phí mà không đánh giá downtime.

DynamoDB on-demand thuận tiện cho tải khó dự báo; provisioned với auto scaling có thể phù hợp tải ổn định. Thiết kế key/index, item size và reads/writes ảnh hưởng chi phí; scan rộng hoặc GSI không cần thiết vẫn tốn dù code ngắn.

Nguồn để tính theo Region: S3 pricing, RDS pricing, DynamoDB pricing.

4. Network cost và data locality#

Vẽ đường dữ liệu trước khi tính: user → edge → origin; app → DB; app → S3; worker → LLM API. Xác định traffic qua AZ, Region, Internet và gateway nào.

Các phương án đánh giá:

• Cache static content bằng CloudFront để giảm origin traffic khi cache hit cao.
• S3 gateway endpoint để traffic S3 phù hợp không đi NAT; xác nhận route/policy.
• Đặt compute gần dữ liệu khi có thể, vẫn giữ redundancy cần thiết.
• So sánh NAT và interface endpoint theo fixed cost lẫn GB traffic.
• Giảm payload/duplicate transfer; upload trực tiếp S3 bằng presigned URL khi phù hợp.

Không tối ưu bằng cách ép tất cả app/DB vào một AZ nếu requirement là chịu mất AZ. Không học quy tắc “mọi traffic cùng Region đều miễn phí”: cách tính phụ thuộc dịch vụ và đường truyền.

Nguồn: VPC pricing, EC2 data transfer, CloudFront pricing.

NAT gateway và NAT instance#

Cả hai cho tài nguyên ở private subnet đi ra Internet. Theo bảng so sánh của AWS, AWS khuyến nghị NAT gateway vì sẵn sàng cao hơn, băng thông lớn hơn và ít việc quản trị hơn:

NAT instance cần thêm hai bước bắt buộc: tắt source/destination check (instance phải nhận và gửi traffic không phải của chính nó) và thêm route 0.0.0.0/0 trỏ về instance trong route table của private subnet (hướng dẫn tạo NAT instance). NAT instance cũng phải nằm ở public subnet có đường ra Internet gateway.

# Đã kiểm cờ bằng CLI help; chưa chạy trên AWS.# Tắt source/destination check cho NAT instance:aws ec2 modify-instance-attribute \  --instance-id i-0123456789abcdef0 \  --no-source-dest-check

Ví dụ số (giả định, tính bằng Node): NAT gateway 0,045 USD/giờ + 0,045 USD/GB xử lý, 730 giờ, nên 32,85 USD cố định + 0,045 USD/GB; NAT instance 0,017 USD/giờ, 12,41 USD cố định và không có phí xử lý theo GB. Ở 1 TB/tháng qua NAT, gateway tốn khoảng 77,85 USD và instance khoảng 12,41 USD (chưa tính data transfer ra Internet, giống nhau ở cả hai). Chênh lệch tiền là có thật, nhưng bạn đổi nó lấy việc tự vá, tự dự phòng và băng thông bị chặn bởi loại instance; với workload cần HA, AWS khuyến nghị NAT gateway mỗi AZ. Đơn giá thật theo Region ở VPC pricing.

5. Công cụ quản chi phí và governance#

Budgets gửi cảnh báo theo cấu hình và có độ trễ dữ liệu; không phải hard spending cap. Budget actions chỉ làm những action đã cấu hình, không đảm bảo mọi phí dừng ở ngưỡng. Đặt tags ngay lúc tạo tài nguyên, kích hoạt cost allocation theo nhu cầu và kiểm tra report.

Nguồn: Budgets, Cost Explorer, Data Exports, Compute Optimizer, Control Tower.

6. Operations và infrastructure as code#

CloudWatch quan sát metric/log/alarm; CloudTrail ghi hoạt động API; Config theo dõi cấu hình/compliance. X-Ray/distributed tracing giúp theo request qua dependency; log có correlation ID vẫn cần thiết. AWS Health Dashboard cho sự kiện sức khỏe AWS liên quan tài khoản/dịch vụ.

Systems Manager hỗ trợ quản fleet, Session Manager và các thao tác vận hành theo cấu hình. Session Manager có thể giảm nhu cầu mở SSH Internet, nhưng cần agent, IAM và network connectivity tới endpoints cần thiết.

CloudFormation mô tả tài nguyên thành stack. Change set giúp xem thay đổi dự kiến; drift detection hỗ trợ tìm thay đổi ngoài template ở tài nguyên được hỗ trợ. IaC làm triển khai lặp lại và phục hồi dễ kiểm tra hơn; không tự ngăn replacement/delete có tác dụng phụ.

Trong nhánh SAA chỉ học khái niệm stack, parameters, outputs, dependency, rollback và change set; chưa cần học sâu Terraform/CDK. Trước update, xem tài nguyên nào sẽ bị thay và dữ liệu được giữ bằng cơ chế nào.

Nguồn: CloudWatch, X-Ray, Systems Manager, CloudFormation, Health.

Change set trước khi update stack#

Change set cho bạn xem CloudFormation sẽ thêm, sửa hay xóa tài nguyên nào trước khi áp dụng; stack chỉ đổi khi bạn chạy (execute) change set. Mỗi dòng thay đổi có Action (Add, Modify, Remove) và, với Modify, trường Replacement: True nghĩa là tài nguyên bị tạo mới rồi xóa cái cũ, Conditional là còn phụ thuộc giá trị chỉ biết lúc chạy, False là sửa tại chỗ (theo aws cloudformation describe-change-set help). Tạo lại một database hay bucket đang chứa dữ liệu là chỗ nguy hiểm nhất. Hai giới hạn từ tài liệu change set: change set không bảo đảm update thành công (lỗi lúc chạy vẫn có thể xảy ra), và sau khi bạn chạy một change set, CloudFormation xóa các change set khác của stack vì chúng không còn khớp.

# Đã kiểm cờ bằng CLI help; chưa chạy trên AWS.# 1. Tạo change set cho stack đã có (UPDATE); template mới ở file local.aws cloudformation create-change-set \  --stack-name app-stack \  --change-set-name add-queue-1 \  --change-set-type UPDATE \  --template-body file://template.yaml# 2. Chờ tạo xong, rồi xem Action và Replacement của từng tài nguyên.aws cloudformation wait change-set-create-complete \  --stack-name app-stack --change-set-name add-queue-1aws cloudformation describe-change-set \  --stack-name app-stack --change-set-name add-queue-1 \  --query 'Changes[].ResourceChange.[LogicalResourceId,Action,Replacement]'# 3a. Chấp nhận: áp dụng.aws cloudformation execute-change-set \  --stack-name app-stack --change-set-name add-queue-1# 3b. Từ chối: xóa change set, stack không đổi.aws cloudformation delete-change-set \  --stack-name app-stack --change-set-name add-queue-1

Nếu template có tài nguyên IAM, create-change-set cần thêm --capabilities CAPABILITY_IAM (hoặc CAPABILITY_NAMED_IAM khi đặt tên role). Tạo stack mới qua change set dùng --change-set-type CREATE; stack ở trạng thái REVIEW_IN_PROGRESS đến khi bạn chạy.

7. Migration: chọn theo thứ đang di chuyển#

Kiểm tra availability và lifecycle sản phẩm trước khi đề xuất, đặc biệt dịch vụ/device có thay đổi khả năng đặt hàng. Danh sách trong exam guide có thể chứa tên legacy; học vai trò rồi đối chiếu trang chính thức hiện tại. Ví dụ đã đối chiếu ngày 2026-10-05: AWS Storage Blog ghi Snowcone ngừng từ 2024-11-12 (cả khách mới lẫn khách cũ không đặt được) và Snowball Edge chỉ còn cho khách hiện hữu từ 2025-11-07; blog nêu DataSync cho phần lớn việc di chuyển dữ liệu, còn thiết bị Snowball Edge thế hệ mới và Outposts cho edge. Elastic Transcoder hết hỗ trợ ngày 2025-11-13, AWS đề xuất AWS Elemental MediaConvert thay thế.

Nguồn: Migration overview, DMS, DataSync, Storage Gateway.

8. Migration cutover: dữ liệu đúng quan trọng hơn “copy xong”#

Ví dụ tự xây: chuyển PostgreSQL từ VPS sang RDS với downtime tối thiểu có thể dùng full load + change replication khi source/target đáp ứng. Trước khi chọn, xác nhận version, permissions, network, schema, sequence, extensions và những objects công cụ không chuyển.

1. Inventory dependencies: DB, file, DNS, secrets, scheduled jobs và external integrations.
2. Chọn mục tiêu: rehost/replatform/refactor theo thời gian, công sức và yêu cầu.
3. Di chuyển thử dữ liệu, validate counts/checksums và transaction quan trọng.
4. Replicate changes; đo lag và xử lý lỗi.
5. Đặt cửa sổ cutover, dừng/giới hạn writes và bảo đảm đồng bộ theo kế hoạch.
6. Chuyển endpoint, chạy smoke test, theo dõi error/latency.
7. Có rollback với cách xử lý writes đã phát sinh ở target, tránh hai bên cùng là nguồn chính.

Đây là khung suy luận, không phải runbook cho mọi database. Backup/restore có thể đơn giản hơn CDC khi chấp nhận downtime. Migration nhiều máy không thay requirement bảo mật, backup và observability.

9. Reference: nhóm dịch vụ cần nhận diện thêm#

Những dịch vụ dưới đây giúp đọc tình huống ngoài project Node nhỏ. Mức học đầu tiên: biết vai trò, một use case và dịch vụ dễ nhầm; chưa cần triển khai hết.

Tra cứu: database overview, ML overview, management overview, security overview.

Checklist phạm vi chính thức: mở In-scope AWS services và Technologies and concepts. Đánh dấu mỗi mục theo ba mức: nhận diện / so sánh / thực hành. Danh sách AWS không exhaustive và có thể thay đổi. Các bảng của guide là nhóm kiến thức để học, không tuyên bố thứ tự tần suất xuất hiện trong đề.

Dịch vụ trong danh sách in-scope chưa có mục riêng#

Đối chiếu danh sách in-scope (đọc 2026-10-05) với GĐ28 đến GĐ32 cho thấy các mục sau chưa có mục riêng; mức học đề xuất là nhận diện, mỗi mục một dòng:

Một tính năng S3 hay bị bỏ sót khi tính tiền: Requester Pays. Với bucket bật tính năng này, người yêu cầu trả phí request và tải dữ liệu, chủ bucket vẫn trả phí lưu trữ. Mọi request phải xác thực (không cho truy cập ẩn danh) và người gọi phải khai báo chấp nhận phí bằng header x-amz-request-payer hoặc --request-payer ở CLI (tài liệu).

# Đã kiểm cờ bằng CLI help; chưa chạy trên AWS.aws s3api put-bucket-request-payment \  --bucket shared-datasets-example \  --request-payment-configuration '{"Payer":"Requester"}'# Người đọc phải khai báo chấp nhận phí:aws s3api get-object --bucket shared-datasets-example \  --key data.csv --request-payer requester data.csv

10. Tự kiểm tra#

• Tính fixed cost, request cost và transfer cost cho hai kiến trúc.

  Đáp án

  Công thức: Tổng = Fixed + R x c_req + GB x c_transfer + dòng phụ (log, NAT, backup). Fixed là thứ tính dù không có tải (ALB theo giờ, task chạy 24/7, DB Multi-AZ, NAT, endpoint, public IPv4). Request tăng theo số lần gọi. Transfer gồm Internet egress, cross-AZ, cross-Region, xử lý qua NAT. Ví dụ bài gốc: 200 GB lưu nhưng 5 TB tải ra mỗi tháng thì transfer, không phải lưu trữ, quyết định hóa đơn. Làm đủ bài ở mục 1 (có điểm hòa vốn). Sai thường gặp: chỉ so giá compute.

• Phân biệt commitment discount và capacity reservation.

  Đáp án

  Savings Plans là cam kết mức tiêu thụ tính theo giờ trong 1 hoặc 3 năm để được giá thấp hơn On-Demand; Compute Savings Plans áp dụng cho EC2 bất kể family, size, OS, tenancy, Region, và cho Fargate và Lambda. Capacity Reservation giữ chỗ capacity ở một AZ; không mặc định có chiết khấu. Muốn vừa giữ chỗ vừa giảm giá thì kết hợp hai thứ. Trả theo All, Partial hoặc No upfront không đổi bản chất cam kết nhưng có đổi mức giá: All upfront cho giá thấp nhất, kế đến Partial upfront, còn No upfront chiết khấu ít nhất (Savings Plans FAQ). Savings Plans không cung cấp capacity reservation; muốn giữ chỗ phải dùng On-Demand Capacity Reservation, và Savings Plans vẫn áp dụng giá cho phần đó (Compute Savings Plans và RI). Sai thường gặp: "mua Savings Plans là chắc chắn có máy lúc cần". Xem mục 2.

• Giải thích khi nào Spot phù hợp và cần checkpoint/idempotency.

  Đáp án

  Spot dùng capacity dư, có thể bị thu hồi vì capacity, giá, hoặc ràng buộc; hành vi khi bị thu hồi là terminate, stop hoặc hibernate tùy cấu hình (AWS gửi cảnh báo gián đoạn trước 2 phút khi stop hoặc terminate; với hibernate có thông báo nhưng không có 2 phút vì hibernate bắt đầu ngay; cảnh báo là best effort, xem Spot interruption notices). Phù hợp: worker lấy việc từ queue, batch chạy lại được, CI, xử lý chia nhỏ. Điều kiện: checkpoint (không mất cả công việc), idempotency (chạy lại không tạo kết quả trùng), nhiều pool instance và phương án dự phòng On-Demand nếu có deadline. Không phù hợp: database duy nhất, job có deadline cứng không chịu gián đoạn.

  textReady

  queue --> worker (Spot) --checkpoint--> S3/DB             |  bị thu hồi             v  message hiện lại sau visibility timeout          worker khác --> đọc checkpoint, làm tiếp (idempotent)

• Giải thích vì sao budget alert không phải hard cap.

  Đáp án

  Budgets so sánh chi phí/usage thực tế hoặc dự báo với ngưỡng rồi gửi cảnh báo hoặc chạy action đã cấu hình; dữ liệu billing có độ trễ nên tài nguyên có thể tiếp tục phát sinh phí sau khi vượt ngưỡng. Action chỉ làm đúng thứ bạn cấu hình. Cách kiểm: tạo budget, ghi lại ngưỡng/kênh thông báo, và xác nhận rằng tài nguyên lab vẫn chạy sau khi alert; muốn dừng phải có action hoặc quy trình dọn dẹp riêng. Xem mục 5.

• Chọn MGN/DMS/DataSync/Storage Gateway theo dữ liệu cần di chuyển.

  Đáp án

  Thứ cần di chuyển	Chọn	Lý do và giới hạn
  Cả server/workload (rehost)	Application Migration Service	Giữ nguyên cấu trúc server; không tự thành cloud-native
  Database, full load rồi theo dõi thay đổi	DMS	Cần schema assessment; không tự chuyển mọi stored procedure; test SQL ứng dụng
  File/object từ NFS, SMB, S3... sang AWS theo job	DataSync	Transfer dữ liệu, không thay giao thức ứng dụng
  On-premises cần truy cập lâu dài vào lưu trữ AWS với cache	Storage Gateway	Có các loại S3 File, FSx File, Tape, Volume (FSx File Gateway không còn nhận khách mới theo tài liệu AWS; tình trạng các loại còn lại cho khách mới: chưa xác minh)
  Đối tác gửi file bằng SFTP/FTPS/FTP/AS2	Transfer Family	Không phải VPN hay replication database

  Snow Family: học như khái niệm truyền offline và dịch vụ thay thế; thiết bị đời cũ đã ngừng hoặc đóng cho khách mới (xem AWS Storage Blog). Sai thường gặp: dùng DataSync thay CDC database. Xem mục 7.

• Viết kế hoạch cutover có validation và xử lý writes khi rollback.

  Đáp án

  textReady

  T-7d   inventory (DB, file, DNS, secrets, cron, tích hợp)T-3d   full load thử + validate count/checksum, sequence, extensionT-1d   bật replicate thay đổi; theo dõi lag/lỗiT-0    giảm TTL DNS từ trước; dừng/giới hạn ghi ở nguồn       chờ lag = 0; validate; đổi endpoint; smoke testT+1h   quan sát lỗi/latency; GIỮ nguồn chỉ-đọcRollback: nếu đích đã nhận ghi mới -> có đường sao ngược về nguồn          (replication ngược) hoặc đối soát/replay thủ công;          KHÔNG để hai bên cùng nhận ghi.

  Điểm chấm: có bước validate dữ liệu, có tiêu chí rollback (ví dụ tỉ lệ lỗi vượt ngưỡng trong N phút), và quyết định rõ ghi ở đích sau cutover được xử lý ra sao. Khi chấp nhận downtime, dump/restore đơn giản hơn CDC. Xem mục 8.

• Phân biệt CloudWatch, CloudTrail, Config và tracing.

  Đáp án

  Dịch vụ	Trả lời câu hỏi	Ví dụ
  CloudWatch	Hệ thống đang chạy thế nào?	Metric CPU, log, alarm unhealthy
  CloudTrail	Ai gọi API gì, lúc nào?	Ai xóa security group
  Config	Cấu hình hiện tại/lịch sử có tuân thủ không?	Bucket nào đang public
  X-Ray/tracing	Request chậm ở dependency nào?	Trace API tới DB tới LLM

  CloudTrail có Event history 90 ngày cho management events; muốn giữ lâu hơn hoặc ghi data events (như thao tác object S3) thì tạo trail ra S3. Sai thường gặp: dùng CloudWatch để biết ai đổi cấu hình. Xem mục 6.

• Đối chiếu các dịch vụ còn lạ với danh sách chính thức.

  Đáp án

  Làm theo bài "checklist phạm vi chính thức" ở mục 9: mở trang in-scope và technologies and concepts, chấm ba mức, ghi ngày đối chiếu. Tự kiểm: không còn dịch vụ "lạ" nào trong nhóm trọng số lớn; bảng của bạn có Amazon Quick và SageMaker AI (tên mới); biết Elastic Transcoder và Snow Family nằm trong danh sách dù đã thay đổi vòng đời. Trang chính thức thắng bảng của guide.

• Một NAT instance duy nhất phục vụ private subnet ở hai AZ; AZ chứa nó mất điện. Chuyện gì xảy ra với app ở AZ còn lại, và sửa thế nào?

  Đáp án

  Route 0.0.0.0/0 của cả hai private subnet trỏ vào một instance nên mọi đường ra Internet (cập nhật gói, gọi API ngoài) đứt, kể cả ở AZ còn sống: NAT instance là điểm lỗi đơn và AZ không độc lập. Theo bảng so sánh, failover giữa các NAT instance do bạn tự viết script; NAT gateway được tạo dự phòng trong một AZ và AWS khuyến nghị tạo một gateway mỗi AZ. Cách sửa: (1) NAT gateway zonal ở public subnet của từng AZ, mỗi private subnet có route 0.0.0.0/0 riêng trỏ về gateway cùng AZ; hoặc (2) NAT gateway chế độ regional, một resource tự mở rộng theo AZ có workload và không cần public subnet; AWS ghi nên cân nhắc regional cho mọi trường hợp trừ khi cần private connectivity (tài liệu). Cái giá của cách (1): thêm chi phí cố định mỗi gateway (xem ví dụ số ở mục 4). Sai thường gặp: gắn security group vào NAT gateway (không gắn được).

• Change set báo Modify với Replacement: True cho RDS instance đang có dữ liệu. Bạn làm gì trước khi execute?

  Đáp án

  True nghĩa là CloudFormation tạo instance mới rồi xóa cái cũ, nên dữ liệu không tự chuyển sang. Việc cần làm: (1) xác định thuộc tính nào gây replacement (xem Details của change set, describe-change-set kèm --include-property-values) và thử đổi cách khác để tránh tạo lại; (2) nếu buộc phải thay, chụp snapshot hoặc có bản sao lưu đã kiểm khôi phục trước; (3) lên kế hoạch chuyển dữ liệu và endpoint như bài cutover ở mục 8; (4) chưa chắc chắn thì xóa change set (delete-change-set), stack không đổi. Nhớ change set không bảo đảm update thành công (tài liệu). Xem mục 6.

• Bạn chia sẻ bộ dữ liệu 2 TB cho đối tác nhưng không muốn trả tiền tải về. Dùng tính năng nào, ai trả khoản nào, và đối tác có tải bằng URL công khai được không?

  Đáp án

  Bật Requester Pays trên bucket. Người yêu cầu trả phí request và tải dữ liệu, chủ bucket vẫn trả phí lưu trữ. Truy cập ẩn danh không được phép: mọi request phải xác thực, nên URL công khai không dùng được; đối tác phải có credential (hoặc assume role, khi đó account của role trả tiền) và khai báo chấp nhận phí bằng --request-payer requester hoặc header x-amz-request-payer. Ngoại lệ đáng nhớ: nếu request trả AccessDenied (403) và bắt nguồn từ chính account hoặc organization của chủ bucket thì chủ bucket vẫn bị tính phí request (tài liệu). Lệnh bật: aws s3api put-bucket-request-payment --bucket NAME --request-payment-configuration '{"Payer":"Requester"}' (đã kiểm cờ bằng CLI help; chưa chạy trên AWS). Sai thường gặp: tưởng Requester Pays gom luôn cả phí lưu trữ.

Ghi chú chung: Kiểm chứng ngày 2026-10-05 theo tài liệu AWS (URL nằm trong từng đáp án trên). Chưa chạy trên AWS thật. Ví dụ số dùng đơn giá giả định (riêng đơn giá Lambda lấy từ trang giá của AWS, us-east-1 x86), không dùng làm giá của Region bạn.

Tiếp: GĐ33 — Labs, Case Studies & Ôn tập.