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

Đáp án

B — Dùng multipart upload cho các job sao lưu; tạo lifecycle policy dọn các multipart upload dở dang trên bucket để phần tải hỏng không tích luỹ nữa.

Vì sao đúng

Đề nêu hai triệu chứng đi cùng nhau, và chúng có chung một nguyên nhân: một số lần tải lên thất bại, và chi phí lưu trữ tăng mạnh.

⚠ Điểm mấu chốt: multipart upload dở dang KHÔNG hiện ra khi liệt kê object, nhưng VẪN tính tiền:

Tải lên bị đứt giữa chừng
        ↓
    Các phần đã tải nằm lại trong bucket dưới dạng "incomplete multipart upload"
        ↓
    KHÔNG xuất hiện trong `aws s3 ls`
    KHÔNG tính vào dung lượng bucket bạn nhìn thấy trong console
        ↓
    → nhưng vẫn tính tiền lưu trữ đầy đủ, mãi mãi
        ↓
    → đây chính là lý do chi phí tăng mà không ai giải thích được

Đề nói đội vận hành đã xoá các phần hỏng bằng tay — nghĩa là họ đã tìm ra chúng, nhưng chưa ngăn được việc chúng tiếp tục tích luỹ. Lifecycle rule làm việc đó tự động.

aws s3api list-multipart-uploads --bucket sao-luu-du-lieu

aws s3api put-bucket-lifecycle-configuration --bucket sao-luu-du-lieu \
  --lifecycle-configuration '{"Rules":[{
    "ID":"don-multipart-do-dang","Status":"Enabled","Filter":{},
    "AbortIncompleteMultipartUpload":{"DaysAfterInitiation":7}}]}'

Vì sao multipart cũng chữa được vế thất bại. Nó chia tệp thành nhiều phần tải song song, và khi một phần lỗi thì chỉ phải tải lại phần đó thay vì cả tệp — điều rất đáng giá với sao lưu xuyên Region qua đường truyền không hoàn hảo.

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

• A (dùng S3 Transfer Acceleration cho job sao lưu; lifecycle rule dọn multipart dở dang) — đây là phương án gần nhất và vế lifecycle của nó chính xác bằng đáp án đúng. Nó chỉ chọn sai công cụ cho vế đầu. Transfer Acceleration tối ưu đường đi tới S3 cho người dùng ở xa Region của bucket, và nó tính thêm phí mỗi GB — đi ngược yêu cầu giảm chi phí. Quan trọng hơn, nó không giải quyết nguyên nhân thất bại: một lần tải lên một luồng vẫn là một luồng, đứt vẫn mất hết. Multipart mới là thứ làm cho việc tải lên chịu được lỗi.

• C (multipart upload — đúng; nhưng lifecycle policy chuyển dữ liệu sang Glacier hằng ngày) — vế đầu đúng, vế sau nhắm sai vấn đề. Chuyển sang Glacier giảm chi phí lưu trữ dữ liệu hợp lệ, nhưng không đụng gì tới các phần tải dở dang — chúng vẫn nằm lại và vẫn tính tiền. Đề nói chi phí tăng do các lần tải hỏng, nên đây là chữa nhầm chỗ. Ngoài ra chuyển sang Glacier ngay hằng ngày làm dữ liệu sao lưu mất khả năng lấy ra tức thì.

• D (Transfer Acceleration; dùng Multi-Object Delete để xoá các phần cũ hằng ngày) — sai cả hai vế. Transfer Acceleration như trên, và Multi-Object Delete xoá OBJECT, không xoá multipart upload dở dang — chúng là hai loại thực thể khác nhau, và thao tác để huỷ chúng là AbortMultipartUpload. Ngoài ra dọn bằng job hằng ngày là làm thủ công thứ lifecycle rule làm miễn phí.

Ghi nhớ

⚠ Bốn nguồn chi phí ẩn trong S3 — bảng phải thuộc: | Nguồn | Đặc điểm | |---|---| | Multipart upload dở dang | không hiện khi liệt kê object, vẫn tính tiền | | Phiên bản cũ khi bật versioning | mỗi lần ghi đè giữ lại bản cũ | | Delete marker | tích luỹ khi xoá object có versioning | | Object nhỏ trong lớp IA | tính phí tối thiểu 128 KB mỗi object |

Từ khoá nhận diện:

"failed uploads" + "storage costs increased" → multipart dở dang tích luỹ "prevent new failed uploads from accumulating" → AbortIncompleteMultipartUpload "Transfer Acceleration" để chữa lỗi tải hỏng → SAI, nó tối ưu đường đi và tính thêm phí "Multi-Object Delete" để xoá multipart dở dang → SAI, đó là hai thực thể khác nhau "chuyển sang Glacier" để chữa chi phí do phần tải dở → chữa nhầm chỗ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có phần dở dang nào không | aws s3api list-multipart-uploads --bucket <ten> | | Lifecycle rule đã áp chưa | get-bucket-lifecycle-configuration | | Chi phí có giảm không | so dòng chi phí lưu trữ S3 sau một chu kỳ hoá đơn |

Và một lời khuyên: hãy chạy list-multipart-uploads trên mọi bucket quan trọng ngay hôm nay, kể cả những bucket bạn nghĩ là không có vấn đề. Đây là khoản chi phí ẩn phổ biến nhất trong S3 và cũng là khoản khó phát hiện nhất: dung lượng bạn nhìn thấy trong console không bao gồm các phần tải dở dang, nên một bucket hiện 500 GB có thể đang tính tiền cho 2 TB. Không có cảnh báo, không có cột nào trong giao diện mặc định, và Cost Explorer chỉ cho bạn một con số tổng cho S3. Cách duy nhất để biết là chủ động gọi API đó — và với các đường ống sao lưu chạy hằng đêm nhiều năm, con số trả về thường gây bất ngờ.

Đáp án

D — Tạo Auto Scaling group cho tầng front end kết hợp Reserved Instance và Spot Instance để giảm chi phí; chuyển các bảng trong cơ sở dữ liệu Oracle thành bảng DynamoDB.

Vì sao đúng

Đề nêu ba mục tiêu, và một chi tiết về dữ liệu quyết định lựa chọn cơ sở dữ liệu: dữ liệu là phi cấu trúc.

⚠ Điểm mấu chốt: "eliminate licensing costs" nghĩa là phải RỜI KHỎI Oracle, không phải chuyển Oracle sang RDS:

Oracle trên EC2 hoặc trên RDS
        ↓
    Vẫn phải trả phí bản quyền Oracle
    (RDS có mô hình License Included cho một số phiên bản, nhưng phí vẫn nằm trong giá)
        ↓
DynamoDB
        ↓
    Không có khái niệm bản quyền — trả theo dung lượng và request
        ↓
    → đây là cách duy nhất "eliminate" chứ không phải "giảm"

Đây là lý do phương án A và B — vốn giữ RDS — không đạt mục tiêu.

Vì sao DynamoDB hợp với dữ liệu phi cấu trúc. Đề nói rõ "the data is unstructured". Một cơ sở dữ liệu quan hệ đòi lược đồ cố định; DynamoDB chỉ đòi khoá chính, các thuộc tính còn lại tự do theo từng item — đúng hình dạng dữ liệu mà đề mô tả.

Về mô hình chi phí cho front end:

Auto Scaling group
├── Phần nền luôn chạy      → Reserved Instance (giảm tới 72%)
└── Phần đỉnh hằng tuần     → Spot Instance (giảm tới 90%)

Đề nói đợt tải dồn mỗi tuần và front end là tầng web stateless sau ELB — đúng hình thái chịu được việc Spot bị thu hồi.

⚠ Chuyển từ quan hệ sang DynamoDB đòi thiết kế lại mô hình truy cập, không phải dịch bảng sang bảng:

Trong quan hệ: chuẩn hoá, join khi cần
        ↓
Trong DynamoDB: KHÔNG có join
        ↓
    Phải liệt kê trước mọi mô hình truy cập
    Rồi thiết kế khoá chính và GSI phục vụ đúng chúng
        ↓
    → đây là phần tốn công nhất của việc chuyển đổi, và đề không nhắc tới

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

• B (Auto Scaling group với Reserved và Spot — đúng; nhưng chuyển Oracle sang RDS Multi-AZ) — đây là phương án gần nhất và phần front end của nó chính xác bằng đáp án đúng, thậm chí Multi-AZ còn cải thiện độ tin cậy của tầng dữ liệu. Nhưng nó không loại bỏ được chi phí bản quyền: chạy Oracle trên RDS vẫn phải trả phí Oracle, dù theo mô hình BYOL hay License Included. Đề dùng chữ "eliminate", không phải "giảm", nên phương án giữ nguyên engine không đáp ứng được. Đây là bẫy hay vì nó đúng ba phần tư và chỉ sai ở đúng từ khoá quyết định.

• A (Auto Scaling group với On-Demand và Spot; Oracle sang một RDS reserved instance duy nhất) — cùng lỗi bản quyền như B, và còn hai điểm yếu nữa: một instance RDS duy nhất không có tính sẵn sàng cao, và dùng On-Demand cho phần nền là bỏ lỡ khoản giảm giá lớn nhất.

• C (dùng Spot Instance cho toàn bộ front end; chuyển Oracle sang DynamoDB) — vế cơ sở dữ liệu đúng, nhưng dùng Spot cho toàn bộ tầng front end là rủi ro: khi dung lượng Spot khan hiếm — thường xảy ra đúng lúc nhiều người cùng cần, tức là lúc cao điểm — bạn có thể mất phần lớn đội máy cùng lúc. Mẫu đúng là trộn: phần nền chạy On-Demand hoặc Reserved để đảm bảo, phần co giãn dùng Spot.

Ghi nhớ

⚠ Bốn cách xử lý cơ sở dữ liệu thương mại khi lên cloud — bảng phải thuộc: | Cách | Bỏ được phí bản quyền | |---|---| | Oracle trên EC2 (BYOL) | không | | Oracle trên RDS | không | | Chuyển sang engine mã nguồn mở (PostgreSQL, MySQL) | có | | Chuyển sang dịch vụ AWS (DynamoDB, Aurora) | có |

Từ khoá nhận diện:

"eliminate licensing costs" → phải đổi engine, không chỉ đổi chỗ chạy "data is unstructured" → DynamoDB, không phải cơ sở dữ liệu quan hệ "bursts of traffic each week" → Auto Scaling với Spot cho phần đỉnh "lift and shift Oracle to RDS" khi đòi bỏ bản quyền → SAI, phí vẫn còn "toàn bộ đội máy dùng Spot" → rủi ro, nên trộn |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình truy cập có được phục vụ không | mọi truy vấn phải dùng Query, không dùng Scan | | Spot có bị thu hồi nhiều không | Spot Instance Advisor cho từng lớp máy | | RI có được dùng hết không | báo cáo RI utilization |

Và một lời khuyên: hãy liệt kê đầy đủ mọi mô hình truy cập trước khi thiết kế bảng DynamoDB, và coi đó là bước không được rút gọn. Đây là chỗ các dự án chuyển từ quan hệ sang NoSQL thất bại: trong cơ sở dữ liệu quan hệ, một truy vấn mới chỉ là một câu SQL mới — bạn thêm nó bất cứ lúc nào. Trong DynamoDB, một mô hình truy cập không được tính tới từ đầu có thể đòi một GSI mới, hoặc tệ hơn, một cách phi chuẩn hoá khác cho toàn bộ dữ liệu. Chi phí của việc phát hiện muộn không phải là viết thêm một câu truy vấn, mà là chuyển đổi lại toàn bộ bảng khi nó đã có hàng trăm triệu item.

Đáp án

D — Dùng Application Auto Scaling để mở rộng write capacity của bảng DynamoDB theo LỊCH.

Vì sao đúng

Đề có một chi tiết quyết định mà nếu bỏ qua thì cả bốn phương án đều nghe hợp lý: đợt tải lớn là "short predictable periods" — ngắn và đoán trước được.

⚠ Điểm mấu chốt: target tracking phản ứng SAU khi tải đã tăng — với đỉnh ngắn thì luôn muộn:

Tải tăng vọt 300%
        ↓
    CloudWatch cần vài chu kỳ để phát hiện (thường vài phút)
        ↓
    Application Auto Scaling gọi UpdateTable
        ↓
    Dung lượng mới có hiệu lực
        ↓
    → tổng cộng vài phút — mà đợt tải chỉ kéo dài "short period"
        ↓
    → đỉnh đã qua trước khi dung lượng kịp lên

Scheduled scaling đảo ngược thứ tự: tăng dung lượng trước khi đợt tải tới, nên không có khoảng nào bị throttle.

aws application-autoscaling put-scheduled-action \
  --service-namespace dynamodb \
  --resource-id table/du-lieu \
  --scalable-dimension dynamodb:table:WriteCapacityUnits \
  --scheduled-action-name tang-truoc-dot-tai \
  --schedule "cron(50 7 * * ? *)" \
  --scalable-target-action MinCapacity=3000,MaxCapacity=5000

# hạ lại sau khi đợt tải qua
aws application-autoscaling put-scheduled-action \
  --scheduled-action-name ha-sau-dot-tai \
  --schedule "cron(30 9 * * ? *)" \
  --scalable-target-action MinCapacity=500,MaxCapacity=5000

⚠ Nếu đợt tải KHÔNG đoán trước được thì lời giải là on-demand, không phải scheduled:

On-demand hấp thụ tức thì tới gấp đôi đỉnh cao nhất trong 30 ngày qua
        ↓
    Không cần dự báo, không cần lịch
        ↓
    → đắt hơn theo đơn vị request, nhưng đúng cho tải không đoán được

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

• A (dùng Application Auto Scaling đặt step scaling policy để tăng write capacity khi tải chạm ngưỡng) — đây là phương án gần nhất và step scaling thật sự phản ứng nhanh và mạnh hơn target tracking: nó cho phép nhảy nhiều bậc một lúc khi vượt ngưỡng xa. Nhưng nó vẫn là co giãn phản ứng — vẫn phải chờ CloudWatch phát hiện rồi mới hành động, và với một đợt tải "ngắn" thì độ trễ đó vẫn đủ để gây throttle. Khi đề đã nói rõ đợt tải đoán trước được, việc chuẩn bị trước luôn tốt hơn phản ứng nhanh.

• C (giảm target utilization của auto scaling xuống 50% để có nhiều tài nguyên hơn cho lúc cao điểm) — làm giảm mức độ chứ không giải quyết vấn đề, và tăng chi phí liên tục: bạn giữ dung lượng dư 50% suốt 24/7 để phòng một đợt tải ngắn. Với mức vượt tải lên tới 300%, biên 20% thêm vào cũng không đủ.

• B (dùng CloudWatch Events giám sát dead-letter queue và gọi Lambda thử lại các bản ghi lỗi) — chữa triệu chứng chứ không chữa nguyên nhân. Bản ghi vẫn bị throttle, vẫn rơi vào DLQ, chỉ là được thử lại sau. Nó thêm độ trễ, thêm phức tạp, và nếu đợt tải vẫn đang diễn ra thì lần thử lại cũng bị throttle tiếp.

Ghi nhớ

⚠ Bốn cách co giãn DynamoDB — bảng phải thuộc, chú ý cột thời điểm: | Cách | Thời điểm | Hợp với | |---|---|---| | Target tracking | sau khi tải tăng | tải đổi dần | | Step scaling | sau khi tải tăng, phản ứng mạnh hơn | tải đổi nhanh nhưng kéo dài | | Scheduled scaling | TRƯỚC khi tải tăng | đỉnh đoán trước được | | On-demand | tức thì | đỉnh không đoán được |

Từ khoá nhận diện:

"predictable periods" + đỉnh ngắn → scheduled scaling "unpredictable spikes" → on-demand capacity mode ProvisionedThroughputExceededException → đang bị throttle vì thiếu capacity "giảm target utilization" → tăng chi phí liên tục, không giải quyết đỉnh lớn "thử lại từ DLQ" → chữa triệu chứng |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn bị throttle không | WriteThrottleEvents trong khung giờ cao điểm | | Scheduled action có chạy không | describe-scheduled-actions và lịch sử scaling | | GSI có bị nghẽn riêng không | chỉ số throttle theo từng index |

Và một lời khuyên: hãy đặt lịch tăng dung lượng sớm hơn thời điểm đỉnh ít nhất mười phút, và hạ xuống muộn hơn khi đợt tải kết thúc. Đây là chỗ scheduled scaling vẫn thất bại dù đã được cấu hình: UpdateTable không có hiệu lực tức thì — với mức nhảy lớn, DynamoDB cần thời gian tái phân vùng ở hậu trường, và nếu lịch của bạn đặt đúng vào giờ đỉnh thì dung lượng mới vẫn chưa sẵn sàng khi dữ liệu đổ tới. Biên an toàn ở cả hai đầu tốn rất ít tiền so với chi phí của những bản ghi rơi vào dead-letter queue trong đúng khoảnh khắc quan trọng nhất.

Đáp án

D — Đặt authorization của method API Gateway thành AWS_IAM; tạo permissions policy cấp quyền execute-api:Invoke trên tài nguyên REST API và gắn vào một group chứa các IAM user.

Vì sao đúng

Đề đòi chỉ IAM user có quyền phù hợp mới gọi được API. AWS có một cơ chế dựng riêng cho việc đó, và nó đòi hai nửa khớp nhau.

⚠ Điểm mấu chốt: hành động IAM để gọi một API Gateway endpoint là execute-api:Invoke — không phải lambda:InvokeFunction:

Client ký request bằng SigV4 với thông tin đăng nhập IAM của họ
        ↓
    API Gateway xác minh chữ ký, xác định principal
        ↓
    Kiểm tra principal đó có execute-api:Invoke trên ARN của method không
        ↓
    Đạt → API Gateway gọi backend (Lambda) bằng QUYỀN CỦA CHÍNH NÓ
        ↓
    → người gọi KHÔNG cần quyền gì với Lambda

Đây là điểm phân biệt duy nhất giữa phương án C và D, và nó phản ánh một sự thật về kiến trúc: người gọi nói chuyện với API Gateway, không nói chuyện với Lambda.

{
  "Effect": "Allow",
  "Action": "execute-api:Invoke",
  "Resource": "arn:aws:execute-api:ap-southeast-1:111122223333:abc123/prod/GET/du-lieu"
}

⚠ Client phải ký request bằng SigV4 — không phải chỉ gửi kèm khoá:

Với AWS_IAM authorization
        ↓
    Request phải mang chữ ký SigV4 trong header Authorization
        ↓
    SDK của AWS làm tự động; curl thì phải dùng --aws-sigv4
        ↓
    → thiếu chữ ký thì nhận 403, dù người dùng có đủ quyền

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

• C (đặt authorization AWS_IAM — đúng; nhưng cấp quyền lambda:InvokeFunction trên REST API resource) — đây là phương án gần nhất và nó chỉ sai đúng một tên hành động. Nhưng sai này là sai dứt khoát: lambda:InvokeFunction là quyền gọi thẳng một hàm Lambda, còn quyền gọi một method của API Gateway là execute-api:Invoke. Ngoài ra câu "cấp lambda:InvokeFunction trên REST API resource" tự mâu thuẫn — ARN của một REST API method không phải ARN của một Lambda function, nên policy đó sẽ không bao giờ khớp. Việc API Gateway gọi Lambda được cấp phép bằng resource policy trên chính hàm, không phải bằng quyền của người dùng cuối.

• A (viết Lambda custom authorizer, client gửi kèm key và secret, Lambda tự xác thực với hệ thống IAM) — tự dựng lại thứ AWS đã có, và làm theo cách nguy hiểm: yêu cầu client gửi access key và secret trong request là phơi thông tin đăng nhập dài hạn ra đường truyền và ra log. Cơ chế đúng là ký SigV4, trong đó secret không bao giờ được truyền đi.

• B (tạo client certificate cho API Gateway và phân phối cho người dùng) — hiểu ngược chiều của tính năng. Client certificate của API Gateway dùng để BACKEND xác minh rằng request đến từ API Gateway, không phải để người dùng chứng minh danh tính với API Gateway. Nó cũng không liên kết gì với IAM user.

Ghi nhớ

⚠ Bốn cơ chế uỷ quyền của API Gateway — bảng phải thuộc: | Cơ chế | Dành cho | Hành động IAM | |---|---|---| | AWS_IAM | IAM user/role, dịch vụ AWS | execute-api:Invoke | | Cognito user pool | người dùng ứng dụng | — | | Lambda authorizer | logic tuỳ chỉnh, JWT, hệ thống ngoài | — | | Không xác thực + API key | đo đếm và giới hạn, không phải bảo mật | — |

Từ khoá nhận diện:

"only IAM users with permissions" → AWS_IAM + execute-api:Invoke lambda:InvokeFunction để gọi API Gateway → LUÔN SAI "client certificate" để xác thực người gọi → SAI, nó dùng cho chiều backend gửi key và secret trong request → SAI, phải ký SigV4 người dùng ứng dụng (không phải IAM) → Cognito user pool |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quyền có đủ không | aws iam simulate-principal-policy với execute-api:Invoke | | Chữ ký có đúng không | thử gọi bằng SDK trước khi thử bằng curl | | Ai đã gọi | CloudTrail nếu bật, hoặc access log của API Gateway |

Và một lời khuyên: hãy chỉ định đúng stage và method trong ARN của policy, đừng dùng */*/* cho tiện. Đây là chỗ một quyền tưởng là hẹp hoá ra rất rộng: execute-api:Invoke với ARN đầy đủ ký tự đại diện cho phép người dùng gọi mọi method, trên mọi stage, của API đó — bao gồm cả stage dev đang trỏ vào cơ sở dữ liệu thử nghiệm, và cả những method quản trị mà bạn thêm vào sáu tháng sau. Policy không thay đổi, không có gì được cấp thêm một cách tường minh, nhưng phạm vi của nó lớn dần theo chính API của bạn — và không ai nhận ra vì dòng policy vẫn y hệt như ngày nó được viết.

Đáp án

C — Đổi mã hoá mặc định của bucket sang SSE-KMS; đặt bucket policy từ chối các request PutObject không mã hoá; dùng AWS CLI tải lại toàn bộ object đang có.

Vì sao đúng

Đề đòi mọi object hiện tại và tương lai đều được mã hoá bằng khoá do đội bảo mật quản lý. Ba mảnh của phương án C tương ứng với ba phần của yêu cầu đó.

⚠ Điểm mấu chốt: đổi default encryption KHÔNG mã hoá lại object đã có:

Đổi default encryption sang SSE-KMS
        ↓
    Áp dụng cho object GHI TỪ ĐÓ TRỞ ĐI
        ↓
    Object cũ vẫn giữ nguyên SSE-S3 như trước
        ↓
    → phải chủ động ghi lại chúng để đổi khoá
        ↓
    → và bucket chưa bật versioning nên không có bản cũ nào tồn đọng

Cách ghi lại object bằng CLI:

aws s3 cp s3://du-lieu-pii/ s3://du-lieu-pii/ --recursive \
  --sse aws:kms --sse-kms-key-id arn:aws:kms:...:key/abc --metadata-directive REPLACE

Với bucket lớn, S3 Batch Operations làm việc này ở quy mô hàng triệu object và có báo cáo hoàn chỉnh.

Vì sao cần bucket policy bên cạnh default encryption. Default encryption áp khi request không nêu cách mã hoá; nhưng một client vẫn có thể chủ động yêu cầu SSE-S3. Bucket policy đóng cửa đó lại:

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

⚠ SSE-KMS làm tăng số lời gọi KMS — bật S3 Bucket Keys để giảm:

Không có Bucket Keys: mỗi object PUT và GET là một lời gọi KMS
        ↓
    Với bucket nhiều triệu object → chi phí KMS đáng kể, và có thể chạm giới hạn tần suất
        ↓
Bật S3 Bucket Keys
        ↓
    S3 tạo một khoá cấp bucket, dùng lại cho nhiều object
        ↓
    → giảm tới 99% lời gọi KMS

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

• D (đổi default encryption sang SSE-KMS trong bucket properties; đặt bucket policy "tự động mã hoá object khi GetObject và PutObject") — đây là phương án gần nhất và vế đầu của nó chính xác. Nhưng vế sau mô tả một thứ không tồn tại: bucket policy không mã hoá gì cả — nó chỉ cho phép hoặc từ chối request. Không có cơ chế nào để policy "tự động mã hoá khi GetObject" (mã hoá vốn không xảy ra lúc đọc). Và quan trọng hơn, phương án này bỏ hẳn bước tải lại object cũ, nên yêu cầu "all current objects" không được đáp ứng.

• A (đổi default encryption sang "SSE-S3 với customer managed key") — tự mâu thuẫn về khái niệm. SSE-S3 dùng khoá do AWS quản lý hoàn toàn; không có biến thể SSE-S3 với khoá của khách hàng. Muốn khoá do bạn quản lý thì đó là SSE-KMS (hoặc SSE-C). Đề nói rõ đội bảo mật phải quản lý khoá, nên SSE-S3 loại từ đầu.

• B (đổi default encryption sang "AES-256 với customer managed key") — cùng lỗi. Trong ngữ cảnh S3, AES256 là mã định danh của SSE-S3; giá trị cho SSE-KMS là aws:kms. Ghép "AES-256" với "customer managed key" là mô tả một chế độ không tồn tại.

Ghi nhớ

⚠ Bốn kiểu mã hoá của S3 — bảng phải thuộc, chú ý cột ai giữ khoá: | Kiểu | Giá trị header | Ai quản lý khoá | |---|---|---| | SSE-S3 | AES256 | AWS hoàn toàn | | SSE-KMS | aws:kms | bạn, qua KMS — có audit và phân quyền | | SSE-C | khách gửi khoá theo request | bạn giữ hoàn toàn, S3 không lưu | | DSSE-KMS | aws:kms:dsse | mã hoá hai lớp, cho tuân thủ đặc biệt |

Từ khoá nhận diện:

"keys the security team manages" → SSE-KMS với customer managed key "all current AND future objects" → default encryption + policy + TẢI LẠI object cũ "SSE-S3 với customer managed key" → LUÔN SAI, không tồn tại "AES-256 với customer managed key" → SAI, AES256 chính là SSE-S3 "bucket policy tự động mã hoá" → SAI, policy chỉ cho phép hoặc từ chối

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Object đang mã hoá bằng gì | head-object, xem ServerSideEncryption và SSEKMSKeyId | | Còn object nào chưa đổi không | S3 Inventory có cột encryption status | | Policy có chặn đúng không | thử put-object với --sse AES256 — phải bị từ chối |

Và một lời khuyên: hãy dùng S3 Inventory để xác nhận không còn object nào ở kiểu mã hoá cũ, thay vì tin rằng lệnh copy đã chạy hết. Với một bucket lớn, lệnh aws s3 cp --recursive có thể dừng giữa chừng vì lỗi mạng, vì một object đang bị khoá, vì thiếu quyền trên một tiền tố cụ thể — và nó thường báo lỗi cho từng object rồi vẫn tiếp tục, nên trạng thái kết thúc trông giống như đã hoàn thành. Không có gì đánh dấu những object bị bỏ sót. S3 Inventory sinh ra một bản kê đầy đủ kèm trạng thái mã hoá của từng object, và đó là bằng chứng duy nhất đủ sức trả lời một câu hỏi kiểm toán về dữ liệu cá nhân.

Đáp án

C — Tạo IAM role gắn policy AmazonSSMManagedInstanceCore và gán cho mọi EC2 instance; gỡ hết security group rule cho phép TCP 22 vào; kỹ sư cài Session Manager plugin và truy cập bằng lời gọi start-session của Systems Manager.

Vì sao đúng

Đề đòi tăng kiểm soát bảo mật và đáp ứng yêu cầu kiểm toán về truy cập máy. Session Manager đạt cả hai bằng cách xoá bỏ hẳn lớp bề mặt tấn công.

⚠ Điểm mấu chốt: Session Manager đảo chiều kết nối — agent gọi RA, không ai gọi VÀO:

SSM Agent trên máy chủ động mở kết nối HTTPS ra endpoint Systems Manager
        ↓
    Kỹ sư gọi StartSession qua API của AWS
        ↓
    Phiên đi qua kênh mà agent đã mở sẵn
        ↓
    → security group KHÔNG cần rule vào nào
    → không có cổng nào để quét, không có gì để tấn công vét cạn

Lợi ích đi kèm cũng đáng kể: không còn khoá SSH để quản lý — không phát khoá, không xoay khoá, không lo khoá của người đã nghỉ việc.

aws ssm start-session --target i-0abc123

# giới hạn ai vào được máy nào bằng tag

{
  "Effect": "Allow",
  "Action": "ssm:StartSession",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {"StringEquals": {"ssm:resourceTag/Doi": "vanhanh"}}
}

⚠ Bật ghi log phiên thì mới đáp ứng được yêu cầu kiểm toán:

Session Manager mặc định ghi metadata phiên vào CloudTrail
        ↓
    Nhưng NỘI DUNG phiên (từng lệnh gõ) phải bật riêng
        ↓
    → cấu hình đẩy sang S3 hoặc CloudWatch Logs
        ↓
    → thiếu bước này thì bạn biết ai đã vào máy nào, nhưng không biết họ đã làm gì

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

• B (cài EC2 Instance Connect, gỡ mọi rule cho phép TCP 22, kỹ sư dùng EC2 Instance Connect CLI) — đây là phương án gần nhất và nó cũng bỏ được việc quản lý khoá SSH dài hạn: Instance Connect đẩy một khoá công khai tạm thời có hạn 60 giây, và quyền được kiểm soát bằng IAM. Nhưng nó vẫn cần cổng 22 mở — chỉ là mở cho dải IP của dịch vụ EC2 Instance Connect thay vì cho mọi nơi. Câu "gỡ hết rule cho phép TCP 22" khiến chính giải pháp đó không hoạt động. Và về kiểm toán, Instance Connect không ghi lại nội dung phiên như Session Manager, nên không đáp ứng được yêu cầu "auditing requirements" của đề.

• A (giới hạn TCP 22 theo IP của thiết bị kỹ sư, cài CloudWatch agent gửi log audit của hệ điều hành) — cải thiện so với hiện trạng nhưng vẫn giữ cổng SSH mở, vẫn phải quản lý khoá, và IP của thiết bị cá nhân thay đổi liên tục. Log audit của hệ điều hành cũng không tương đương với log phiên: nó ghi những gì hệ điều hành thấy, không ghi lại phiên làm việc theo cách xem lại được.

• D (giới hạn TCP 22 theo IP, bật AWS Config theo dõi thay đổi security group, dùng Firewall Manager tự khắc phục) — có giá trị về mặt quản trị nhưng không giải quyết vấn đề gốc: cổng SSH vẫn mở và khoá vẫn phải quản lý. Config và Firewall Manager chỉ đảm bảo rule không bị nới lỏng ngoài ý muốn, tức là bảo vệ một cấu hình vốn đã kém an toàn.

Ghi nhớ

⚠ Bốn cách truy cập EC2, xếp theo mức an toàn — bảng phải thuộc: | Cách | Cổng vào cần mở | Quản khoá | Log phiên | |---|---|---|---| | Session Manager | không có | không cần | có sẵn | | EC2 Instance Connect | 22, từ dải AWS | khoá tạm 60 giây | không | | Bastion host | 22 từ dải hẹp | có | tự dựng | | SSH trực tiếp | 22 | có | không |

Từ khoá nhận diện:

"increase security control and comply with auditing" → Session Manager "no bastion, no open ports, no SSH keys" → Session Manager "EC2 Instance Connect" + gỡ hết rule cổng 22 → mâu thuẫn, nó vẫn cần cổng 22 "giới hạn cổng 22 theo IP" → cải thiện nhưng chưa phải đích đến cần xem lại từng lệnh đã gõ → session logging của Session Manager

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đã sẵn sàng chưa | aws ssm describe-instance-information | | Đã đóng cổng chưa | kiểm security group không còn rule 22 | | Log phiên có ghi không | mở một phiên rồi kiểm S3 hoặc CloudWatch Logs |

Và một lời khuyên: hãy bật session logging và kiểm tra rằng nó thật sự ghi nội dung, đừng dừng ở việc Session Manager chạy được. Đây là chỗ một giải pháp đúng vẫn không đáp ứng được yêu cầu kiểm toán: Session Manager hoạt động ngay sau khi gán IAM role, kỹ sư vào máy được, cổng 22 đã đóng — mọi thứ trông như đã hoàn thành. Nhưng nếu chưa cấu hình đích ghi log, thứ bạn có chỉ là bản ghi CloudTrail nói rằng ai đó đã mở một phiên tới máy nào, lúc mấy giờ. Với một cuộc kiểm toán hỏi "người này đã chạy những lệnh gì trên máy chủ chứa dữ liệu khách hàng", đó không phải câu trả lời.

Đáp án

B, D, F — ba bước để có tầm nhìn về hiệu năng trong các đợt cao điểm:

• F — Cài CloudWatch Logs agent trên EC2 để đẩy log Apache lên CloudWatch Logs.
• D — Cấu hình Aurora MySQL sinh slow query log bằng cách đặt tham số trong parameter group.
• B — Triển khai AWS X-Ray SDK để theo dõi request HTTP trên EC2 và theo dõi truy vấn SQL bằng X-Ray SDK cho PHP.

Vì sao đúng

Đề nêu đúng hai lỗ hổng trong khả năng quan sát, và ba bước đúng lấp cả hai cộng thêm một tầng liên kết chúng lại.

⚠ Điểm mấu chốt: ba bước này trả lời ba câu hỏi khác nhau, và thiếu bất kỳ cái nào cũng để lại điểm mù:

CloudWatch Logs agent (F)
        ↓
    "Máy chủ web đã ghi gì trước khi chết?"

Slow query log (D)
        ↓
    "Truy vấn nào chậm, chậm bao lâu, quét bao nhiêu dòng?"

X-Ray (B)
        ↓
    "Request nào của người dùng đã gọi truy vấn nào, và thời gian đi đâu?"

Vì sao slow query log chứ không phải error log (điểm phân biệt với C). Đề nói "Aurora metrics were not sufficient for query performance analysis" — vấn đề là hiệu năng truy vấn, không phải lỗi. Error log ghi lại sự cố của engine; slow query log ghi lại chính những truy vấn chạy lâu, kèm thời gian và số dòng quét:

slow_query_log = 1
long_query_time = 1
log_output = FILE

Vì sao X-Ray là mảnh ghép quan trọng nhất. Log của web server và log của cơ sở dữ liệu là hai kho tách rời — không có gì nối một request chậm với truy vấn đã gây ra nó. X-Ray gắn một trace ID xuyên suốt:

use Aws\XRay\XRayClient;
// segment cho request HTTP, subsegment cho từng truy vấn SQL

⚠ Log nằm trên máy sẽ mất khi Auto Scaling huỷ instance — đây chính là điều đã xảy ra trong đề:

Web server ghi log ra đĩa cục bộ
        ↓
    ASG huỷ máy vì health check thất bại hoặc vì scale-in
        ↓
    → log biến mất cùng máy, và đó thường là log quan trọng nhất
        ↓
    → phải đẩy ra ngoài theo luồng, không phải thu gom định kỳ

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

• C (cấu hình Aurora sinh ERROR LOG bằng cách đặt tham số trong parameter group) — đây là phương án gần nhất và nó chỉ khác D một từ: cùng cơ chế parameter group, cùng cách bật. Nhưng error log ghi các sự kiện lỗi của engine — khởi động, tắt, lỗi kết nối, lỗi cú pháp — chứ không ghi thời gian thực thi của truy vấn. Đề nói rõ vấn đề là phân tích hiệu năng truy vấn, và công cụ cho việc đó là slow query log. Đây là bẫy đòi đọc kỹ xem đề đang thiếu loại thông tin nào.

• E (EventBridge rule kích hoạt Lambda khi có sự kiện lỗi Aurora, lưu log vào S3 để phân tích bằng Athena) — chỉ bắt được sự kiện lỗi, cùng hạn chế với C. Ngoài ra sự kiện Aurora trong EventBridge là các sự kiện ở mức cụm (failover, thay đổi cấu hình), không phải chi tiết truy vấn.

• A (CloudTrail thu thập hoạt động API từ EC2 và Aurora, phân tích bằng Athena) — sai nguồn dữ liệu. CloudTrail ghi lời gọi API quản lý — ai tạo instance, ai sửa cụm — chứ không ghi truy vấn SQL hay request HTTP tới ứng dụng. Nó không chứa một chút thông tin nào về hiệu năng ứng dụng.

Ghi nhớ

⚠ Bốn tầng quan sát và công cụ tương ứng — bảng phải thuộc: | Tầng | Công cụ | Trả lời | |---|---|---| | Hạ tầng | CloudWatch metric | "CPU, bộ nhớ, kết nối bao nhiêu?" | | Ứng dụng | CloudWatch Logs | "Máy chủ đã ghi gì?" | | Cơ sở dữ liệu | slow query log, Performance Insights | "Truy vấn nào chậm?" | | Xuyên suốt | X-Ray | "Thời gian của một request đi đâu?" |

Từ khoá nhận diện:

"logs lost when instances terminated" → CloudWatch Logs agent, đẩy theo luồng "query performance analysis" → slow query log, không phải error log "trace requests end to end" → X-Ray "CloudTrail để phân tích hiệu năng" → SAI, CloudTrail ghi API quản lý "error log" khi cần phân tích hiệu năng → SAI loại log

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log có tới CloudWatch không | kiểm log stream theo instance_id | | Slow query log có ghi không | kiểm log file của cụm trong console RDS | | X-Ray có thấy truy vấn không | mở service map, xem có node cơ sở dữ liệu không |

Và một lời khuyên: hãy bật Performance Insights cho cụm Aurora ngay bây giờ, đừng chờ tới sự cố tiếp theo. Slow query log rất hữu ích nhưng nó chỉ ghi lại những truy vấn vượt ngưỡng bạn đặt — nghĩa là nếu vấn đề là hàng nghìn truy vấn mỗi cái chỉ mất 200 mili giây, chúng sẽ không xuất hiện ở đâu cả trong khi cộng lại chúng đang làm sập cụm. Performance Insights hiển thị tải cơ sở dữ liệu theo truy vấn, nên nó bắt được cả loại vấn đề đó, và nó giữ lại lịch sử — nghĩa là sau sự cố tiếp theo bạn sẽ có dữ liệu của chính khoảnh khắc đó, thay vì bắt đầu thu thập từ lúc mọi chuyện đã qua.

Đáp án

C — Giới hạn throttle trên REST API được đặt quá thấp; trong giờ cao điểm một số request bị throttle và không tới được hàm Lambda.

Vì sao đúng

Manh mối quyết định nằm ở một câu trong đề: đội vận hành đã kiểm tra lỗi Lambda và không tìm thấy gì. Nếu Lambda không ghi nhận lỗi nào, thì request thất bại chưa bao giờ tới được Lambda.

⚠ Điểm mấu chốt: request bị API Gateway throttle KHÔNG bao giờ tới Lambda, nên không để lại dấu vết nào ở đó:

Request tới API Gateway
        ↓
    Vượt throttle limit của stage hoặc của account
        ↓
    API Gateway trả 429 Too Many Requests NGAY
        ↓
    → Lambda không được gọi
    → không có Invocation, không có Error, không có log
        ↓
    → nhìn từ phía Lambda, mọi thứ hoàn toàn bình thường

Đây là lý do đội vận hành không tìm thấy gì: họ đang tìm ở đúng nơi mà theo định nghĩa sẽ không có gì.

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations \
    op=replace,path=/*/*/throttling/rateLimit,value=5000 \
    op=replace,path=/*/*/throttling/burstLimit,value=10000

⚠ Có ba tầng throttle chồng lên nhau — phải biết mình đang chạm cái nào: | Tầng | Mặc định | |---|---| | Account | 10.000 request/giây, burst 5.000 — cho cả Region | | Stage / method | bạn tự đặt, mặc định kế thừa account | | Usage plan | theo từng API key |

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

• A (Lambda cấu hình quá ít bộ nhớ nên hàm thất bại khi tải cao) — đây là phương án gần nhất và thiếu bộ nhớ thật sự là nguyên nhân phổ biến của lỗi Lambda. Nhưng nó mâu thuẫn trực tiếp với dữ kiện của đề: hàm hết bộ nhớ sẽ ghi lỗi — Runtime exited with error: signal: killed, hoặc timeout — và chỉ số Errors sẽ tăng rõ ràng. Đội vận hành đã kiểm và không thấy gì, nên nguyên nhân nằm trước Lambda trong đường đi. Đây là bẫy chính của câu hỏi: nó mời bạn chọn một nguyên nhân hợp lý mà quên đối chiếu với chi tiết loại trừ đã cho sẵn.

• B (Lambda đặt ở chế độ gọi đồng bộ trong khi REST API gọi bất đồng bộ) — mô tả một cấu hình không tồn tại theo cách này. API Gateway gọi Lambda đồng bộ theo mặc định, và kiểu gọi do phía tích hợp quyết định chứ không phải một thiết lập của hàm. Nếu có lệch kiểu gọi thì triệu chứng sẽ là lỗi tích hợp nhất quán, không phải thất bại rải rác chỉ trong giờ cao điểm.

• D (API dùng non-proxy integration trong khi lẽ ra phải dùng proxy integration) — đây là lựa chọn về cách ánh xạ request và response. Chọn sai gây lỗi định dạng hoặc lỗi ánh xạ một cách nhất quán, ở mọi mức tải — không phải chỉ khi bận. Đề nói vấn đề chỉ xuất hiện trong giờ cao điểm, nên nguyên nhân phải liên quan tới tải.

Ghi nhớ

⚠ Bốn tầng có thể throttle trong kiến trúc API Gateway + Lambda — bảng phải thuộc: | Tầng | Mã lỗi | Dấu hiệu | |---|---|---| | API Gateway (account/stage) | 429 | Lambda không có invocation nào | | Usage plan theo API key | 429 | chỉ ảnh hưởng một khách hàng | | Lambda concurrency | 429 | chỉ số Throttles của Lambda tăng | | Backend của Lambda (CSDL) | tuỳ | Lambda có lỗi, Duration tăng |

Từ khoá nhận diện:

"requests fail but no Lambda errors" → bị chặn TRƯỚC khi tới Lambda "only during busy periods" → liên quan tới tải, không phải cấu hình sai cố định 429 Too Many Requests → throttle, tìm xem ở tầng nào lỗi nhất quán ở mọi mức tải → cấu hình sai, không phải throttle Throttles của Lambda tăng → hết concurrency, khác với throttle của API Gateway

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Request có tới Lambda không | so Count của API Gateway với Invocations của Lambda | | Bị chặn ở tầng nào | 4XXError của API Gateway so với Throttles của Lambda | | Client nhận mã gì | bật access log của API Gateway, xem mã trạng thái |

Và một lời khuyên: hãy so số request mà API Gateway nhận với số lời gọi mà Lambda ghi nhận, và coi khoảng chênh lệch là chỉ số hạng nhất. Đây là phép đo duy nhất phơi bày loại sự cố này ngay lập tức, và gần như không ai theo dõi nó: hai con số nằm ở hai bảng điều khiển khác nhau, mỗi cái đều trông bình thường khi nhìn riêng lẻ. Lambda báo 100% thành công vì nó chỉ đếm những gì nó chạy; API Gateway báo tổng số request vì nó đếm cả những cái nó từ chối. Chỉ khi đặt hai đường cong cạnh nhau thì khoảng trống giữa chúng mới hiện ra — và khoảng trống ấy chính là những người dùng không được phục vụ.

Đáp án

C — Tạo Auto Scaling group cho các EC2 instance và dùng Application Load Balancer để phân phối request; lưu thông tin phiên đã xác thực trong Amazon DynamoDB.

Vì sao đúng

Đề đòi hai thứ, và thứ hai là điểm phân biệt: sẵn sàng cao, và người dùng vẫn giữ được phiên đăng nhập ngay cả khi một instance hỏng.

⚠ Điểm mấu chốt: phiên lưu trên máy là thứ khiến "sẵn sàng cao" chỉ đúng trên giấy:

Phiên nằm trong bộ nhớ hoặc trên đĩa của từng instance
        ↓
    Instance hỏng, Auto Scaling thay bằng máy mới
        ↓
    Người dùng bị đăng xuất giữa chừng
        ↓
    → hạ tầng vẫn "khoẻ" theo mọi chỉ số, nhưng người dùng vẫn mất việc đang làm

DynamoDB là lựa chọn tự nhiên cho dữ liệu phiên: truy cập theo khoá, độ trễ một chữ số mili giây, và có TTL để tự dọn phiên hết hạn mà không tốn dung lượng ghi.

bang.put_item(Item={
    'phien_id': ma_phien,
    'nguoi_dung': ten,
    'het_han': int(time.time()) + 3600})   # thuộc tính TTL

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

• D (Auto Scaling group + ALB, lưu phiên trên EBS volume) — đây là phương án gần nhất và hai phần ba của nó đúng. Nhưng EBS volume gắn với một instance: máy hỏng thì volume đi theo, và một máy mới ở AZ khác không gắn được volume đó. Đây đúng là kiểu lưu trữ mà yêu cầu "remain connected even if an underlying instance fails" muốn loại bỏ.

• B (Auto Scaling group + ALB, lưu phiên trong AWS Secrets Manager) — sai vai trò dịch vụ. Secrets Manager dùng cho bí mật ít thay đổi — mật khẩu cơ sở dữ liệu, khoá API — với chi phí tính theo từng secret mỗi tháng và giới hạn tần suất gọi. Dùng nó làm kho phiên cho hàng nghìn người dùng là vừa đắt vừa sai mục đích.

• A (Global Accelerator chuyển tiếp request tới EC2, DynamoDB lưu phiên) — vế phiên đúng nhưng vế hạ tầng thiếu. Global Accelerator không thay thế được Auto Scaling group: nó tối ưu đường mạng và cho IP tĩnh, nhưng không thay máy hỏng và không co giãn. Không có Auto Scaling group thì yêu cầu sẵn sàng cao không đạt.

Ghi nhớ

⚠ Bốn nơi lưu phiên — bảng phải thuộc: | Nơi | Sống sót khi mất máy | |---|---| | DynamoDB | có — bền, có TTL | | ElastiCache Redis | có — nhanh hơn, dữ liệu trong RAM | | Sticky session ở ALB | không — mất máy vẫn mất phiên | | Bộ nhớ hoặc EBS của instance | không |

Từ khoá nhận diện:

"remain connected even if an instance fails" → đưa phiên ra ngoài máy "highly available" → Auto Scaling group nhiều AZ + ELB "lưu phiên trên EBS" → LUÔN SAI, EBS gắn với một máy "Secrets Manager" làm kho phiên → sai mục đích, đắt Global Accelerator thay cho Auto Scaling → không thay thế được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mất máy có mất phiên không | huỷ thật một instance và xem người dùng có bị đăng xuất không | | Phiên cũ có được dọn không | theo dõi TimeToLiveDeletedItemCount | | Máy có trải nhiều AZ không | kiểm phân bố của Auto Scaling group |

Và một lời khuyên: hãy huỷ thật một instance trong giờ thấp điểm và quan sát xem phiên có sống sót không. Đây là thứ không chỉ số nào cho bạn biết: sau khi thêm ALB và Auto Scaling group, mọi bảng điều khiển đều báo kiến trúc sẵn sàng cao — health check xanh, số instance đủ, tải phân bổ đều. Nếu phiên vẫn nằm trên máy, hệ thống vẫn đạt mọi tiêu chí kỹ thuật trong khi người dùng bị đăng xuất mỗi lần có máy bị thay. Sự cố đó không làm tăng tỷ lệ lỗi HTTP và tới tai bạn dưới dạng những lời phàn nàn mơ hồ.

Đáp án

B — Dùng AWS Compute Optimizer, gọi thao tác ExportLambdaFunctionRecommendations cho các hàm Lambda, xuất tệp CSV ra S3; tạo EventBridge rule chạy theo lịch hai tuần một lần.

Vì sao đúng

Đề đòi ba chỉ số rất cụ thể cho từng hàm Lambda: bộ nhớ đề xuất, chi phí đề xuất, chênh lệch giá so với cấu hình hiện tại. Đó chính xác là những gì Compute Optimizer sinh ra.

⚠ Điểm mấu chốt: Compute Optimizer đã làm sẵn phần khó — phân tích lịch sử và tính chi phí:

Tự viết Lambda phân tích CloudWatch Logs (phương án A)
        ↓
    Phải tự đọc dòng REPORT, tự tính Max Memory Used
    Tự dựng mô hình chi phí cho từng mức bộ nhớ
    Tự đối chiếu với bảng giá
        ↓
Compute Optimizer
        ↓
    Đã phân tích lịch sử, đã tính đề xuất, đã tính chênh lệch giá
        ↓
    → chỉ cần gọi một API xuất ra CSV

aws compute-optimizer export-lambda-function-recommendations \
  --s3-destination-config bucket=bao-cao-toi-uu,keyPrefix=lambda/ \
  --file-format Csv

⚠ Compute Optimizer phải được bật (opt in) và cần đủ dữ liệu lịch sử:

Bật ở cấp tài khoản hoặc cấp tổ chức
        ↓
    Cần ít nhất 14 ngày dữ liệu CloudWatch để đưa ra đề xuất
        ↓
    → hàm mới triển khai sẽ hiện "không đủ dữ liệu", không phải lỗi

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

• D (dùng Compute Optimizer, bật enhanced infrastructure metrics, lên lịch job xuất CSV ngay trong console Compute Optimizer) — đây là phương án gần nhất và nó chọn đúng dịch vụ. Nhưng hai chi tiết sai. Compute Optimizer không có bộ lập lịch xuất báo cáo trong console — việc xuất là một lời gọi API, muốn lặp lại theo lịch thì cần EventBridge. Và enhanced infrastructure metrics là tính năng cho EC2, mở rộng cửa sổ phân tích lên 3 tháng; nó không áp dụng cho Lambda.

• C (mua gói AWS Business Support, opt in Compute Optimizer cho Trusted Advisor, lên lịch xuất kiểm tra tối ưu chi phí từ console Trusted Advisor) — vòng vèo và tốn kém. Không cần gói Business Support để dùng Compute Optimizer — nó là dịch vụ miễn phí ở mức cơ bản. Trusted Advisor cũng không có bộ lập lịch xuất báo cáo, và kiểm tra tối ưu chi phí của nó không cho ba chỉ số cụ thể mà đề đòi.

• A (viết Lambda riêng trích số liệu từ CloudWatch Logs, tự tổng hợp, tự lưu CSV) — chạy được nhưng đây là nhiều công phát triển nhất, đúng thứ đề muốn tránh. Bạn phải tự phân tích log, tự dựng mô hình chi phí theo bảng giá Lambda, và tự bảo trì nó khi giá thay đổi.

Ghi nhớ

⚠ Bốn dịch vụ tối ưu chi phí — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Compute Optimizer | đề xuất right-size cho EC2, Auto Scaling group, EBS, Lambda, ECS trên Fargate | | Trusted Advisor | kiểm tra cố định về chi phí, bảo mật, hiệu năng | | Cost Explorer | phân tích và trực quan hoá chi phí | | AWS Budgets | ngưỡng và cảnh báo |

Từ khoá nhận diện:

"recommended memory / recommended cost / price difference" → Compute Optimizer "export recommendations" → Export*Recommendations API | "chạy theo lịch" → EventBridge scheduled rule "lên lịch xuất trong console Compute Optimizer" → SAI, không có tính năng đó "enhanced infrastructure metrics" cho Lambda → SAI, đó là tính năng của EC2

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã opt in chưa | aws compute-optimizer get-enrollment-status | | Có đủ dữ liệu chưa | đề xuất hiện Unavailable nghĩa là chưa đủ 14 ngày | | Tệp có ra S3 không | kiểm bucket sau khi job xuất chạy |

Và một lời khuyên: hãy đọc cột finding trước khi hành động theo đề xuất. Compute Optimizer phân loại mỗi hàm thành Optimized, NotOptimized hoặc Unavailable — và mục cuối cùng nghĩa là chưa đủ dữ liệu để kết luận, chứ không phải hàm đó ổn. Với những hàm hiếm khi được gọi, trạng thái đó có thể kéo dài mãi, và nếu bạn chỉ nhìn cột chênh lệch giá thì chúng hiện số 0 — trông y như một hàm đã tối ưu hoàn hảo.