Ngân hàng đề — AWS Certified SysOps Administrator Associate

Đáp án

B và E — Tạo và gắn TAG lên tài nguyên, VÀ kích hoạt COST ALLOCATION TAG.

Vì sao đúng

Muốn Cost Explorer chia chi phí theo dự án thì phải làm đủ hai bước, thiếu một bước là không có gì hiện ra.

⚠ Điểm mấu chốt — hai bước bắt buộc, không thay thế nhau:

BƯỚC 1 — GẮN TAG  (phương án B)
        ↓
    Gắn Project=Alpha, Project=Beta… lên
    EC2, RDS, S3, Lambda, EBS…
        ↓
    Công cụ: Tag Editor, CloudFormation,
             Terraform, hoặc gắn lúc tạo
        ↓
    Chưa gắn tag → không có gì để phân loại

BƯỚC 2 — KÍCH HOẠT  (phương án E)
        ↓
    Billing and Cost Management →
    Cost Allocation Tags → chọn "Project" → Activate
        ↓
    Chưa kích hoạt → tag CÓ trên tài nguyên
    nhưng KHÔNG hiện trong Cost Explorer

⚠ Và một chi tiết thời gian phải nói rõ với người quản lý:

Sau khi kích hoạt
        ↓
    Mất TỚI 24 GIỜ dữ liệu mới xuất hiện
        ↓
    Và KHÔNG áp ngược cho chi phí trong quá khứ
        ↓
    → chi phí của tháng trước sẽ KHÔNG BAO GIỜ
      được chia theo tag này
        ↓
    → kích hoạt càng sớm càng tốt

⚠ Xem kết quả ở đâu:

Cost Explorer
        ↓
    Group by → Tag → Project
        ↓
    → biểu đồ chi phí theo từng dự án
        ↓
    Muốn cảnh báo: AWS Budgets đặt theo tag
    Muốn chi tiết theo giờ: Cost and Usage Report

Xem thêm câu #11831, #11590, #11636 và #11663: cùng chùm cost allocation tag. #11831 (cùng lô này) bổ sung một chi tiết quan trọng — trong tổ chức, bước kích hoạt chỉ làm được ở tài khoản quản lý.

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

• A (bật consolidated billing) — đây là phương án gần nhất vì cũng thuộc về chuyện hoá đơn, nhưng nó gộp hoá đơn giữa nhiều TÀI KHOẢN. Đề nói rõ là chia chi phí trong MỘT tài khoản, theo dự án. (Và consolidated billing đã bật sẵn khi dùng Organizations.)

• D (bật AWS Budgets) — Budgets cảnh báo khi chi phí vượt ngưỡng, không phân tích và chia nhỏ chi phí. Nó là bước sau, không thay được Cost Explorer.

• C (bật server access logging) — ghi log request tới bucket S3, hoàn toàn không liên quan tới chi phí.

Ghi nhớ

⚠ Bốn công cụ chi phí — bảng phải thuộc: | Công cụ | Việc | |---|---| | Cost Explorer | xem, lọc, nhóm chi phí — 13 tháng lịch sử, có dự báo | | Cost and Usage Report | chi tiết nhất: theo GIỜ, theo từng tài nguyên — đổ ra S3 | | Budgets | cảnh báo khi vượt ngưỡng (chi phí, mức dùng, RI/SP) | | Cost Anomaly Detection | phát hiện chi phí bất thường bằng học máy | | Trusted Advisor | gợi ý tiết kiệm cụ thể (máy nhàn rỗi, EIP không dùng) |

Từ khoá nhận diện:

"chia chi phí theo dự án / phòng ban" → gắn tag + KÍCH HOẠT tag "cảnh báo khi vượt ngân sách" → Budgets "chi phí tăng bất thường" → Cost Anomaly Detection "dữ liệu chi phí chi tiết nhất" → CUR "gộp hoá đơn nhiều tài khoản" → Organizations, bật sẵn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tag đã kích hoạt chưa | Billing → Cost Allocation Tags — cột Status | | Tài nguyên nào chưa gắn tag | Tag Editor, lọc theo "tag không tồn tại" | | Dữ liệu đã về chưa | Cost Explorer → Group by → Tag → chọn tag đó |

Và một cách làm giúp tránh hẳn phần lớn rắc rối này về sau: khi tách bạch chi phí là yêu cầu quan trọng, hãy cân nhắc mỗi dự án một tài khoản AWS riêng thay vì dựa hoàn toàn vào tag. Tag phụ thuộc vào kỷ luật của mọi người trong đội, và luôn có một phần chi phí không gắn tag được — còn ranh giới tài khoản thì chính xác tuyệt đối và không cần ai nhớ phải làm gì.

Đáp án

A và E — Dùng CloudWatch alarm theo dõi sức khoẻ của ALB ở từng Region rồi cấu hình Route 53 DNS failover với health check gắn vào các alarm đó, VÀ cấu hình Route 53 dùng ĐỊNH TUYẾN THEO VỊ TRÍ ĐỊA LÝ (geolocation) khai các Region tương ứng.

Vì sao đúng

Đề đòi hai thứ: hướng người dùng tới Region gần họ, và tự động chuyển hướng khi hỏng. Mỗi phương án đúng lo một vế.

⚠ Vế thứ nhất — hướng người dùng theo vị trí:

Geolocation routing
        ↓
    Route 53 xem vị trí của người truy vấn DNS
      (theo châu lục / quốc gia / bang)
        ↓
    Trả về bản ghi của Region tương ứng
        ↓
    → người ở châu Âu về Region châu Âu
    → người ở châu Á về Region châu Á
        ↓
    Nhớ khai một bản ghi mặc định (Default)
    cho vị trí không khớp quy tắc nào

⚠ Vế thứ hai — failover phải theo dõi ĐÚNG thứ:

Theo dõi ALB, không theo dõi từng EC2
        ↓
    ALB là điểm vào của cả Region đó
        ↓
    Một máy EC2 hỏng → ASG tự thay,
      ALB tự rút khỏi target group
      → KHÔNG cần failover cả Region
        ↓
    ALB không còn target khoẻ mạnh nào
      → CHÍNH LÚC ĐÓ mới cần chuyển Region
        ↓
    Cách làm: CloudWatch alarm trên
      HealthyHostCount của ALB
      → health check kiểu CloudWatch alarm
      → gắn vào bản ghi Route 53

⚠ Vì sao dùng health check kiểu alarm thay vì health check gọi HTTP thẳng:

Health check gọi HTTP từ ngoài
        ↓
    → phải để endpoint truy cập được từ internet
    → chỉ biết "gọi được hay không"

Health check kiểu CLOUDWATCH ALARM
        ↓
    → dùng được với endpoint riêng tư
    → dựa trên chỉ số THẬT của ALB
      (HealthyHostCount, TargetResponseTime, 5xx)
    → tinh vi hơn nhiều

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

• B (alarm theo dõi trạng thái các INSTANCE EC2 ở từng Region rồi failover theo đó) — đây là phương án gần nhất và chỉ sai ở đối tượng theo dõi: một máy EC2 hỏng là chuyện bình thường mà ASG và ALB xử lý được tại chỗ. Failover cả Region vì một máy hỏng là phản ứng thái quá và gây bất ổn.

• C (định tuyến theo TRỌNG SỐ, khai châu lục, quốc gia, bang) — mâu thuẫn ngay trong chính nó: định tuyến theo trọng số chia lưu lượng theo tỉ lệ phần trăm, không hề xét vị trí. Các trường châu lục/quốc gia/bang là của geolocation.

• D (health check theo dõi ĐỊA CHỈ IP RIÊNG của một EC2 ở mỗi Region) — health check của Route 53 gọi từ internet công cộng, không tới được IP riêng. Và theo dõi một máy đơn lẻ cũng sai như phương án B.

Ghi nhớ

⚠ Bảy kiểu định tuyến của Route 53 — bảng phải thuộc: | Kiểu | Dùng khi | |---|---| | Simple | một bản ghi, không điều kiện | | Weighted | chia theo TỈ LỆ — canary, A/B testing | | Latency-based | Region có ĐỘ TRỄ THẤP NHẤT với người dùng | | Geolocation | theo VỊ TRÍ người dùng — tuân thủ dữ liệu, nội dung theo vùng | | Geoproximity | theo khoảng cách địa lý, có bias kéo giãn vùng phục vụ | | Failover | chính / dự phòng (active-passive) | | Multivalue answer | trả nhiều IP khoẻ mạnh, cân bằng thô |

Từ khoá nhận diện:

"gần người dùng nhất" → latency-based (nếu có), hoặc geolocation "dữ liệu phải ở lại trong nước" → geolocation, BẮT BUỘC "chia 10% sang phiên bản mới" → weighted "dự phòng khi Region chính hỏng" → failover "kết hợp nhiều kiểu" → bản ghi alias lồng nhau

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

Với yêu cầu "hướng người dùng tới Region gần nhất", câu trả lời chuẩn mực của AWS thường là latency-based routing — nó chọn theo độ trễ mạng đo được thật, chứ không theo khoảng cách trên bản đồ, và độ trễ mới là thứ người dùng cảm nhận. Geolocation chọn theo vị trí địa lý của người truy vấn, nên về nguyên tắc có thể gửi người dùng tới một Region gần về khoảng cách nhưng chậm hơn về đường mạng.

Tuy vậy, latency-based không có trong bốn phương án, và trong số các lựa chọn được đưa ra thì geolocation là phương án đúng duy nhất — weighted không xét vị trí, còn hai phương án còn lại sai ở đối tượng theo dõi. Khoá đáp án vẫn là A và E. Khi gặp đề tương tự có đủ lựa chọn, hãy phân biệt: "độ trễ thấp nhất / hiệu năng tốt nhất" → latency-based; "theo quốc gia, tuân thủ dữ liệu, nội dung theo vùng" → geolocation.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng ở vùng X nhận gì | dig từ resolver ở vùng đó, hoặc test-dns-answer | | Health check đang báo gì | Route 53 → Health checks → tab Monitoring | | Failover có chạy không | tắt tạm target ở một Region, xem DNS đổi trong bao lâu |

Và một cấu hình rất dễ quên khi dùng geolocation: luôn tạo một bản ghi Default. Route 53 chỉ trả lời cho những vị trí khớp một quy tắc — người dùng ở một quốc gia bạn chưa khai, hoặc một resolver mà Route 53 không xác định được vị trí, sẽ nhận về NXDOMAIN thay vì được đưa tới Region gần nhất. Đây là loại lỗi chỉ lộ ra khi có người dùng thật ở đúng vùng bạn chưa nghĩ tới.

Đáp án

A — AWS Cost Explorer.

Vì sao đúng

Câu hỏi là "cái gì đang làm chi phí tăng", và Cost Explorer là công cụ toàn diện nhất để trả lời — nhất là khi có nhiều tài khoản gộp hoá đơn.

⚠ Điểm mấu chốt — Cost Explorer cắt lát chi phí theo mọi chiều:

Ở TÀI KHOẢN QUẢN LÝ, Cost Explorer thấy
chi phí của MỌI tài khoản thành viên
        ↓
    Group by:
      Linked Account  → tài khoản nào tăng
      Service         → dịch vụ nào tăng
      Region          → Region nào tăng
      Instance Type   → loại máy nào
      Usage Type      → chi tiết loại sử dụng
      Tag             → dự án / phòng ban nào
        ↓
    Kèm theo:
      13 tháng lịch sử
      dự báo 12 tháng tới
      chi tiết theo NGÀY, và theo GIỜ (bật thêm)

⚠ Quy trình truy tìm nguyên nhân — đi từ rộng tới hẹp:

1. Group by LINKED ACCOUNT
        ↓
    → tài khoản nào tăng
2. Lọc tài khoản đó, group by SERVICE
        ↓
    → dịch vụ nào tăng
3. Lọc dịch vụ đó, group by USAGE TYPE
        ↓
    → tăng ở phần nào: giờ máy? dữ liệu ra? lưu trữ?
4. Group by REGION và INSTANCE TYPE
        ↓
    → khoanh vùng chính xác
5. Cần tới từng tài nguyên → CUR + Athena

⚠ Và một công cụ nên bật kèm:

Cost Anomaly Detection
        ↓
    Học mẫu hình chi tiêu bằng học máy
        ↓
    → báo NGAY khi có mức tăng bất thường
    → thay vì đợi CEO hỏi vào cuối tháng
        ↓
    Miễn phí, và cấu hình trong vài phút

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

• D (cost allocation tag) — đây là phương án gần nhất và là một phần rất quan trọng của việc phân tích chi phí, nhưng bản thân tag không phải là công cụ phân tích — nó là cách phân loại dữ liệu để công cụ như Cost Explorer dùng. Và tag chỉ hữu ích khi tài nguyên đã được gắn tag từ trước.

• B (Trusted Advisor) — có mục kiểm tra tối ưu chi phí (máy nhàn rỗi, Elastic IP không dùng, RI chưa tận dụng), nhưng đó là một danh sách gợi ý cố định, không phân tích được xu hướng theo thời gian và không cho biết chi phí đã tăng ở đâu.

• C (resource groups) — chỉ là cách nhóm tài nguyên lại để quản lý, hoàn toàn không có chức năng chi phí.

Ghi nhớ

⚠ Năm công cụ chi phí — bảng phải thuộc: | Công cụ | Việc | Dùng khi | |---|---|---| | Cost Explorer | phân tích, lọc, nhóm, dự báo | "vì sao chi phí tăng" | | Cost and Usage Report | chi tiết nhất: giờ, từng tài nguyên | phân tích sâu bằng SQL | | Budgets | cảnh báo vượt ngưỡng | chủ động, ngăn trước | | Cost Anomaly Detection | phát hiện bất thường bằng ML | báo sớm, tự động | | Trusted Advisor | gợi ý tiết kiệm cụ thể | tìm việc tối ưu ngay |

Từ khoá nhận diện:

"vì sao chi phí tăng" → Cost Explorer "cảnh báo trước khi vượt" → Budgets "tăng đột biến bất thường" → Cost Anomaly Detection "chi tiết từng tài nguyên, từng giờ" → CUR + Athena "lãng phí gì có thể cắt ngay" → Trusted Advisor, Compute Optimizer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài khoản nào tăng | Cost Explorer → Group by Linked Account, so hai tháng | | Dịch vụ nào tăng | lọc tài khoản đó → Group by Service | | Tài nguyên cụ thể nào | CUR + Athena, hoặc bật dữ liệu mức tài nguyên |

Và một việc nên làm ngay sau khi tìm ra nguyên nhân lần này: bật Cost Anomaly Detection và một vài Budget theo tài khoản. Cả hai đều miễn phí hoặc gần như miễn phí, và chúng biến việc kiểm soát chi phí từ một cuộc điều tra bị động sau khi có người phàn nàn, thành một cảnh báo tự động tới đúng đội chịu trách nhiệm trong vòng một ngày kể từ khi chi tiêu đi lệch khỏi mẫu hình bình thường.

Đáp án

D — Dùng PARAMETERS để cung cấp giá trị khác nhau cho từng lần triển khai.

Vì sao đúng

Đề muốn MỘT template dùng lại được cho nhiều môi trường và nhiều Region. Parameters chính là cơ chế sinh ra cho việc đó.

⚠ Điểm mấu chốt — parameter tách CẤU TRÚC khỏi GIÁ TRỊ:

Template mô tả CẤU TRÚC (giống nhau mọi nơi)
        ↓
    Parameter giữ GIÁ TRỊ (khác nhau mỗi nơi)
        ↓
    Triển khai dev:   InstanceType=t3.micro,  Size=1
    Triển khai prod:  InstanceType=m5.large,  Size=6
        ↓
    → CÙNG một tệp template
    → khác nhau ở giá trị truyền vào lúc tạo stack

⚠ Ví dụ thực tế:

Parameters:
  MoiTruong:
    Type: String
    AllowedValues: [dev, staging, prod]
    Default: dev
  LoaiMay:
    Type: String
    Default: t3.micro
  AmiId:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64

Kiểu AWS::SSM::Parameter::Value<...>
        ↓
    → tự lấy AMI ĐÚNG CỦA TỪNG REGION
    → giải quyết luôn vấn đề "AMI khác nhau mỗi Region"

⚠ Ba công cụ đi kèm parameter, rất hay ra thi:

MAPPINGS
        ↓
    Bảng tra cứu theo Region hoặc theo môi trường
      → !FindInMap [CauHinh, !Ref MoiTruong, LoaiMay]

CONDITIONS
        ↓
    Tạo hay không tạo một tài nguyên tuỳ môi trường
      → chỉ prod mới dựng Multi-AZ RDS

PSEUDO PARAMETERS
        ↓
    AWS::Region, AWS::AccountId, AWS::StackName
      → template tự biết mình đang ở đâu

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

• B (dùng nested stack) — đây là phương án gần nhất về mức độ hữu ích, nhưng nested stack giải bài toán CHIA NHỎ một template lớn thành các thành phần dùng lại được, chứ không phải bài toán truyền giá trị khác nhau cho mỗi môi trường. (Rất hay dùng kèm parameter, nhưng không thay thế được.)

• C (dùng cross-stack reference) — dùng để một stack đọc đầu ra của stack khác (Export/ImportValue), ví dụ stack ứng dụng lấy VPC id từ stack mạng. Không liên quan tới việc tái sử dụng template.

• A (dùng change set để tạo thêm môi trường) — change set chỉ xem trước thay đổi trên một stack ĐANG TỒN TẠI, nó không tạo môi trường mới.

Ghi nhớ

⚠ Các phần của một template CloudFormation — bảng phải thuộc: | Phần | Việc | |---|---| | Parameters | giá trị truyền vào lúc tạo/cập nhật stack | | Mappings | bảng tra cứu tĩnh — thường theo Region | | Conditions | tạo tài nguyên có điều kiện | | Resources | phần DUY NHẤT bắt buộc | | Outputs | giá trị trả ra, Export được cho stack khác | | Metadata | nhóm và mô tả tham số cho giao diện | | Transform | dùng macro, hoặc AWS::Serverless (SAM) |

Từ khoá nhận diện:

"một template, nhiều môi trường" → Parameters (+ Mappings, Conditions) "chia nhỏ template lớn" → nested stacks "stack này cần giá trị của stack kia" → Export / ImportValue "triển khai ra nhiều tài khoản và Region cùng lúc" → StackSets "xem trước thay đổi" → change set

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Template có hợp lệ không | validate-template, và cfn-lint để kiểm sâu hơn | | Stack đang dùng giá trị gì | describe-stacks --query 'Stacks[0].Parameters' | | Thay đổi sẽ ảnh hưởng gì | tạo change set rồi đọc trước khi execute |

Và một mẫu tổ chức mã rất đáng theo cho hạ tầng nhiều môi trường: một template duy nhất trong git, kèm một tệp parameter cho mỗi môi trường. Khi ấy mọi khác biệt giữa dev và prod đều nằm gọn trong một tệp JSON nhỏ mà bạn đọc hết trong nửa phút — thay vì nằm rải rác trong hai template gần giống nhau, nơi những khác biệt vô tình và những khác biệt có chủ đích trông y hệt nhau.

Đáp án

C — STICKY SESSIONS (session affinity).

Vì sao đúng

Yêu cầu rất rõ: sau khi đăng nhập, mọi request của người dùng đó phải về ĐÚNG một máy EC2. Đó là định nghĩa của sticky session.

⚠ Điểm mấu chốt — vì sao cần dính phiên ở đây:

Xác thực diễn ra TRÊN TỪNG MÁY EC2
        ↓
    Phiên đăng nhập lưu trong bộ nhớ của máy đó
        ↓
    Request tiếp theo rơi vào máy KHÁC
        ↓
    → máy đó không biết người này là ai
    → bắt đăng nhập lại
        ↓
STICKY SESSIONS
        ↓
    ALB gắn một cookie, và mọi request kèm cookie đó
    được gửi về ĐÚNG target cũ

⚠ Hai loại cookie của ALB:

DURATION-BASED (do ALB tự quản)
        ↓
    Cookie tên AWSALB
    Thời hạn do bạn đặt: 1 giây đến 7 NGÀY
    → không cần sửa ứng dụng

APPLICATION-BASED (do ứng dụng quản)
        ↓
    Ứng dụng tự sinh cookie, ALB bọc thêm AWSALBAPP
    → thời hạn theo phiên của chính ứng dụng
    → linh hoạt hơn

⚠ Nhưng phải nói rõ — sticky session là giải pháp TẠM:

Nhược điểm:
    - Tải phân bố KHÔNG ĐỀU
      (máy giữ nhiều phiên sẽ nặng hơn)
    - Máy hỏng → NGƯỜI DÙNG MẤT PHIÊN
    - Auto Scaling thu nhỏ → cũng mất phiên
    - Triển khai phiên bản mới khó êm
        ↓
CÁCH ĐÚNG VỀ LÂU DÀI: ứng dụng KHÔNG GIỮ TRẠNG THÁI
        ↓
    Lưu phiên ra ngoài:
      ElastiCache for Redis  (phổ biến nhất)
      DynamoDB
      hoặc JWT ký sẵn, không cần lưu phiên
        ↓
    → mọi máy phục vụ được mọi người dùng

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

• B (deregistration delay) — đây là phương án gần nhất vì cũng liên quan tới việc giữ kết nối với một target, nhưng nó chỉ quy định ALB chờ bao lâu cho các request ĐANG DỞ hoàn tất trước khi rút một target ra. Nó không định tuyến request mới của một người dùng cụ thể.

• A (cross-zone load balancing) — quyết định ALB có phân phối lưu lượng đều sang target ở MỌI AZ hay không. Liên quan tới cân bằng tải, không liên quan tới phiên. (Với ALB thì tính năng này luôn bật.)

• D (TCP listener) — ALB chỉ làm việc ở tầng 7 (HTTP/HTTPS), không có TCP listener. Đó là của Network Load Balancer.

Ghi nhớ

⚠ Ba loại load balancer — bảng phải thuộc: | | ALB | NLB | GWLB | |---|---|---|---| | Tầng | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | 3 (GENEVE) | | Sticky session | cookie (duration hoặc app-based) | theo IP nguồn | — | | Định tuyến | theo path, host, header, query | theo cổng | — | | Hiệu năng | rất cao | cực cao, độ trễ cực thấp | — | | IP tĩnh | không (dùng tên miền) | CÓ, mỗi AZ một IP | — | | Dùng khi | web, API, microservice | game, IoT, cần IP tĩnh | thiết bị bảo mật |

Từ khoá nhận diện:

"mọi request về cùng một máy" → sticky sessions "người dùng bị đăng xuất khi máy bị thay" → lưu phiên RA NGOÀI (Redis) "chờ request đang dở xong rồi mới rút máy" → deregistration delay "cần IP tĩnh cho load balancer" → NLB "định tuyến theo đường dẫn URL" → ALB với rule

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sticky đã bật chưa | describe-target-group-attributes | | Cookie có được gắn không | mở DevTools, tìm cookie AWSALB | | Tải có lệch không | chỉ số RequestCount theo từng target |

Và một lời khuyên nên nói thẳng với đội phát triển khi bật tính năng này: sticky session chữa triệu chứng, không chữa nguyên nhân. Nguyên nhân là ứng dụng giữ trạng thái trong bộ nhớ của một máy — và chừng nào còn như vậy thì mỗi lần Auto Scaling thu nhỏ, mỗi lần triển khai phiên bản mới, mỗi lần một máy hỏng đều là một lần một nhóm người dùng bị đăng xuất giữa chừng.

Đáp án

B — Tạo quy tắc Amazon EventBridge dùng SCHEDULE (mẫu theo lịch), đặt hàm Lambda làm target.

Vì sao đúng

Đề cần chạy hàm Lambda vào cuối mỗi ngày. Đó là một lịch cố định, và EventBridge có sẵn cơ chế đó — không cần hạ tầng nào cả.

⚠ Điểm mấu chốt — EventBridge Scheduler / rule theo lịch:

Tạo quy tắc với biểu thức cron
        ↓
      cron(0 23 * * ? *)   → 23:00 mỗi ngày UTC
      hoặc rate(1 day)
        ↓
    Target: hàm Lambda
        ↓
    → không máy chủ nào phải chạy
    → không phải vá, không phải theo dõi
    → chỉ trả tiền cho lần chạy Lambda
        ↓
    Đây đúng nghĩa "hiệu quả vận hành nhất"

⚠ Cú pháp cron của EventBridge có SÁU trường — khác cron của Linux:

cron(phút giờ ngày-trong-tháng tháng thứ năm)
        ↓
    cron(0 23 * * ? *)
        ↓
    Lưu ý:
      - có thêm trường NĂM
      - KHÔNG được đặt cả "ngày-trong-tháng" và "thứ"
        → một trong hai phải là dấu ?
      - mặc định chạy theo GIỜ UTC
        (EventBridge Scheduler hỗ trợ múi giờ)

⚠ Vì sao KHÔNG dùng sự kiện của S3 ở đây:

Đề nói: chạy VÀO CUỐI MỖI NGÀY
        ↓
    Đây là kích hoạt THEO THỜI GIAN
        ↓
    Không phải theo sự kiện dữ liệu
        ↓
    Nếu dùng sự kiện S3:
      - tệp đổi 1000 lần → chạy 1000 lần
      - cả ngày không có tệp nào đổi → KHÔNG chạy
        ↓
    → sai hoàn toàn mô hình kích hoạt

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

• D (S3 event notification kích hoạt Lambda mỗi khi đối tượng thay đổi) — đây là phương án gần nhất vì cùng liên quan tới bucket trong đề, nhưng nó kích hoạt theo sự kiện dữ liệu, không phải theo lịch: báo cáo sẽ chạy nhiều lần mỗi ngày, hoặc không chạy lần nào.

• C (EventBridge rule với event pattern cho S3) — cùng vấn đề như D: event pattern là phản ứng với sự kiện, còn đề cần schedule pattern. Sự khác biệt nằm đúng ở một chữ.

• A (dựng một EC2 chạy cron để gọi Lambda) — chạy được nhưng lãng phí: phải trả tiền máy chạy 24/7, phải vá hệ điều hành, và chính máy đó trở thành điểm hỏng đơn lẻ cho một việc mà AWS làm sẵn miễn phí.

Ghi nhớ

⚠ Ba cách kích hoạt Lambda — bảng phải thuộc: | Cách | Dùng khi | |---|---| | EventBridge SCHEDULE | theo thời gian: hằng ngày, hằng giờ, cron | | EventBridge EVENT PATTERN | phản ứng với sự kiện AWS: EC2 đổi trạng thái, Config vi phạm | | Nguồn sự kiện trực tiếp | S3 notification, SQS, DynamoDB Streams, Kinesis, API Gateway | | Bẫy hay gặp | lẫn schedule với event pattern |

Từ khoá nhận diện:

"chạy vào cuối ngày / mỗi giờ / mỗi thứ Hai" → EventBridge schedule "khi có tệp mới tải lên" → S3 event notification "khi tài nguyên vi phạm tuân thủ" → EventBridge event pattern (Config) "cần múi giờ địa phương" → EventBridge SCHEDULER (không phải rule thường) "chạy đúng một lần trong tương lai" → EventBridge Scheduler one-time

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lịch có kích hoạt không | CloudWatch chỉ số Invocations của quy tắc | | Hàm có lỗi không | CloudWatch Logs của Lambda, và chỉ số Errors | | Biểu thức cron có đúng ý không | tạo thử một quy tắc rate(1 minute) ở môi trường dev |

Và một lỗi rất hay gặp với loại tác vụ này: quên rằng biểu thức cron của EventBridge rule chạy theo UTC. Một báo cáo "cuối ngày" đặt ở cron(0 23 * * ? *) sẽ chạy lúc 6 giờ sáng hôm sau theo giờ Việt Nam — tức là báo cáo của ngày hôm trước ra đời sau khi ngày mới đã bắt đầu. Với lịch mới, hãy dùng EventBridge Scheduler và khai thẳng múi giờ để tránh cả lớp lỗi này.

Đáp án

D — Tạo hành động co giãn THEO LỊCH (scheduled scaling) để tăng số máy trước khi lưu lượng tới.

Vì sao đúng

Manh mối nằm gọn trong một cụm từ: "chậm vào ĐẦU MỖI NGÀY LÀM VIỆC" — tức là thời điểm đã biết trước và lặp lại đều đặn.

⚠ Điểm mấu chốt — co giãn theo CPU luôn đi SAU lưu lượng:

8:00 người dùng bắt đầu vào
        ↓
    CPU tăng dần
        ↓
    CloudWatch thu thập chỉ số        ~1-5 phút
    Alarm cần đủ số chu kỳ liên tiếp  ~2-3 phút
    Máy mới khởi chạy                 ~1-2 phút
    Khởi động ứng dụng + health check ~2-5 phút
        ↓
    → máy mới sẵn sàng lúc 8:10-8:15
    → 10-15 phút đầu tiên NGƯỜI DÙNG CHỊU CHẬM
        ↓
    Đúng triệu chứng đề mô tả

⚠ Co giãn theo lịch xoá bỏ hẳn khoảng trũng đó:

Đặt hành động lúc 7:40 (trước 20 phút):
      MinSize = 10,  DesiredCapacity = 10
        ↓
    8:00 lưu lượng tới → máy ĐÃ SẴN SÀNG
        ↓
Đặt hành động lúc 18:30:
      MinSize = 2,   DesiredCapacity = 2
        ↓
    → không trả tiền thừa cả đêm

⚠ Và giữ NGUYÊN chính sách động làm lưới an toàn:

Lịch      → lo phần tải ĐOÁN ĐƯỢC
Động      → lo phần BẤT NGỜ vượt dự kiến
        ↓
    Hai cơ chế chạy song song, bổ sung nhau
        ↓
    Lưu ý: đặt cả MinSize, không chỉ DesiredCapacity
    → nếu không, chính sách động có thể kéo tụt lại

Xem thêm câu #11827 (lô 127): gần như cùng một câu hỏi, cùng khoá scheduled scaling. Và #11764 (lô 126): cũng hỏi chọn kiểu co giãn nhưng khoá là dynamic, vì ở đó trigger là một ngưỡng CPU chứ không phải khung giờ định sẵn — hai khoá khác nhau vì ràng buộc trong đề khác nhau, không mâu thuẫn.

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

• B (sửa chính sách để thêm NHIỀU máy hơn mỗi lần mở rộng) — đây là phương án gần nhất và giảm bớt vấn đề, nhưng vẫn phải chờ CPU tăng trước. Khoảng trũng ban đầu vẫn còn nguyên, chỉ ngắn hơn một chút.

• A (đổi launch configuration sang loại máy lớn hơn) — trả tiền cho máy lớn suốt 24 giờ để phục vụ một khoảng cao điểm ngắn, và vẫn không có thêm máy nào sẵn sàng vào lúc 8 giờ — chỉ là mỗi máy khoẻ hơn.

• C (đổi sang co giãn theo mức dùng BỘ NHỚ) — đổi chỉ số không đổi được bản chất phản ứng chậm. Hơn nữa chỉ số bộ nhớ cần CloudWatch agent mới có, và đề không hề nói vấn đề là bộ nhớ.

Ghi nhớ

⚠ Bốn kiểu co giãn — bảng phải thuộc: | Kiểu | Dùng khi | Ví dụ | |---|---|---| | Theo lịch | biết TRƯỚC thời điểm | đầu giờ làm việc, khuyến mãi đã lên lịch | | Động | bất ngờ, chỉ biết ngưỡng | CPU > 70% | | Dự đoán | mẫu hình lặp lại, để ML học | tải theo mùa | | Thủ công | thay đổi một lần | sự kiện đặc biệt |

Từ khoá nhận diện:

"chậm vào đầu mỗi ngày làm việc" → scheduled scaling "tải tăng bất ngờ" → dynamic scaling "có mẫu hình nhưng giờ không cố định" → predictive scaling "máy mới lên quá chậm" → warm pool, golden AMI, detailed monitoring "trả tiền cả đêm cho máy nhàn rỗi" → scheduled scale-in

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lịch có chạy không | describe-scheduled-actions, và tab Activity của ASG | | Máy sẵn sàng lúc mấy giờ | so thời điểm InService với giờ bắt đầu cao điểm | | Người dùng còn thấy chậm không | TargetResponseTime của ALB trong khung 8:00-8:30 |

Và một cách kiểm chứng rất trực quan cho loại sự cố này: vẽ chồng đồ thị TargetResponseTime của ALB và GroupInServiceInstances của ASG trên cùng một khung giờ. Bạn sẽ thấy rất rõ một khoảng thời gian đầu giờ nơi đường phản hồi vọt lên trong khi số máy vẫn nằm yên — và sau khi bật scheduled scaling, chính khoảng vọt đó sẽ biến mất khỏi đồ thị.

Đáp án

C — Dùng chiến lược phân bổ capacity-optimized cho Spot, và MỞ RỘNG DANH SÁCH LOẠI INSTANCE trong Auto Scaling group.

Vì sao đúng

Đề nêu hai triệu chứng, và cả hai đều bắt nguồn từ danh sách loại instance quá hẹp.

⚠ Điểm mấu chốt — Spot có sẵn theo từng "capacity pool":

Một capacity pool = một tổ hợp:
    loại instance × Availability Zone
        ↓
    ASG chỉ khai 1-2 loại instance
        ↓
    → chỉ có vài pool để chọn
    → pool cạn → KHÔNG khởi chạy được đúng giờ
    → pool bị thu hồi → hàng loạt máy bị dừng
        ↓
    Đúng hai triệu chứng của đề
        ↓
Khai 10-15 loại instance tương đương
        ↓
    → hàng chục pool trải trên nhiều AZ
    → gần như luôn có pool còn chỗ

⚠ Và capacity-optimized chọn pool SÂU nhất:

lowest-price
        ↓
    Chọn pool RẺ NHẤT
    → nhưng thường cũng là pool đông người dùng nhất
    → BỊ THU HỒI NHIỀU NHẤT

capacity-optimized     ← khuyến nghị
        ↓
    Chọn pool có DUNG LƯỢNG DƯ NHIỀU NHẤT
    → ít bị thu hồi hơn hẳn
    → đúng yêu cầu "ít gián đoạn hơn"

price-capacity-optimized  (mới hơn)
        ↓
    Cân bằng cả giá lẫn dung lượng dư
    → AWS khuyến nghị cho phần lớn trường hợp

⚠ Vì sao TĂNG MaxSize không giải quyết được:

Vấn đề KHÔNG phải là trần số lượng
        ↓
    Là KHÔNG CÓ chỗ trong các pool đang khai
        ↓
    Nâng MaxSize từ 20 lên 40
        ↓
    → vẫn không khởi chạy nổi máy thứ 15
    → vì pool đã cạn

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

• A (capacity-optimized + TĂNG kích thước tối đa của ASG) — đây là phương án gần nhất, vế đầu hoàn toàn đúng, nhưng vế sau sai: tăng MaxSize không tạo ra dung lượng Spot. Đây chính là điểm phân biệt giữa A và C.

• B (chiến lược phân bổ on-demand + mở rộng danh sách loại instance) — mở rộng danh sách thì đúng, nhưng "on-demand allocation strategy" không phải là thứ giải quyết vấn đề Spot bị thu hồi. (Nếu chuyển hẳn sang On-Demand thì hết bị thu hồi thật — nhưng cũng mất luôn khoản tiết kiệm, và đề không nói muốn bỏ Spot.)

• D (on-demand + tăng MaxSize) — kết hợp hai vế đều không nhắm đúng nguyên nhân.

Ghi nhớ

⚠ Ba chiến lược phân bổ Spot — bảng phải thuộc: | Chiến lược | Chọn pool theo | Kết quả | |---|---|---| | lowest-price | giá rẻ nhất | bị thu hồi NHIỀU nhất | | capacity-optimized | dung lượng dư nhiều nhất | ít bị thu hồi | | price-capacity-optimized | cân bằng cả hai | AWS khuyến nghị hiện nay | | capacity-optimized-prioritized | ưu tiên loại bạn xếp trước, trong giới hạn dung lượng | khi có ràng buộc phần cứng |

Từ khoá nhận diện:

"Spot bị thu hồi nhiều" → capacity-optimized + NHIỀU loại instance "không khởi chạy được đủ máy" → mở rộng loại instance và AZ "cần một phần dung lượng bảo đảm" → mix On-Demand + Spot "tải không chịu được gián đoạn" → đừng dùng Spot hoặc dùng On-Demand base "tiết kiệm cho tải ổn định" → Savings Plans, không phải Spot

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bị thu hồi bao nhiêu lần | EC2 → Spot Requests, và sự kiện EventBridge | | Pool nào đang sâu | Spot placement score | | ASG đang khai bao nhiêu loại | describe-auto-scaling-groups → Overrides |

Và một con số đáng nhớ khi thiết kế: AWS khuyến nghị khai ít nhất 10 loại instance cho một Auto Scaling group dùng Spot. Nghe có vẻ nhiều, nhưng với một ứng dụng web thông thường thì m5, m5a, m5n, m6i, m6a, c5, c5a, c6i ở vài cỡ khác nhau đã đủ số đó — và chính sự đa dạng ấy là thứ quyết định bạn có đủ máy vào đúng lúc cần hay không, nhiều hơn bất kỳ tham số nào khác.

Đáp án

B và C — Tạo INTERNET GATEWAY rồi gắn vào VPC, VÀ thêm một tuyến trong route table của subnet trỏ tới internet gateway đó.

Vì sao đúng

Đề cần kết nối cả hai chiều — vào và ra internet. Đó là định nghĩa của một public subnet, và public subnet cần đúng hai thứ này.

⚠ Điểm mấu chốt — ba điều kiện của một máy ra vào internet được:

1. Internet Gateway gắn vào VPC        ← phương án B
        ↓
2. Route table của subnet có tuyến:
       0.0.0.0/0  →  igw-xxxxx          ← phương án C
        ↓
3. Instance có ĐỊA CHỈ IP CÔNG CỘNG
   (public IP hoặc Elastic IP)
        ↓
    Thiếu BẤT KỲ điều nào → không ra vào được

⚠ Và hai lớp lọc phải cho phép:

4. Security group: mở cổng cần thiết chiều vào
5. Network ACL: mở CẢ HAI chiều
       (nhớ dải cổng tạm 1024-65535 chiều ra)

⚠ Vì sao NAT Gateway không phải câu trả lời ở đây:

NAT Gateway
        ↓
    Cho máy ở PRIVATE subnet đi RA internet
        ↓
    NHƯNG chặn hoàn toàn chiều VÀO
        ↓
    Đề cần "cả incoming và outgoing"
        ↓
    → NAT không thoả được vế incoming

⚠ Và Internet Gateway không có địa chỉ IP:

IGW là thành phần định tuyến ảo
        ↓
    - Mở rộng theo chiều ngang, dự phòng sẵn
    - KHÔNG có băng thông giới hạn
    - KHÔNG gắn Elastic IP được
    - Miễn phí (chỉ trả tiền dữ liệu truyền)
        ↓
    Nó thực hiện NAT 1-1 giữa IP riêng
    và IP công cộng của chính instance

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

• A và E (thêm NAT Gateway vào private subnet) — hai phương án gần như trùng nhau, và NAT Gateway chỉ cho chiều RA. Đề đòi cả chiều vào. (Và về nguyên tắc, NAT Gateway phải đặt ở PUBLIC subnet, không phải private — nó cần một tuyến ra IGW để hoạt động.)

• D (gắn Elastic IP vào internet gateway) — IGW không nhận Elastic IP. Elastic IP gắn vào instance, ENI, NAT Gateway hoặc NLB, không bao giờ gắn vào IGW.

Ghi nhớ

⚠ Public subnet ↔ Private subnet — bảng phải thuộc: | | Public subnet | Private subnet | |---|---|---| | Định nghĩa | route table có 0.0.0.0/0 → IGW | không có tuyến tới IGW | | Ra internet | có (nếu máy có IP công cộng) | chỉ qua NAT Gateway | | Vào từ internet | CÓ | không bao giờ | | Đặt gì ở đây | ALB, NAT Gateway, bastion | máy ứng dụng, CSDL |

Từ khoá nhận diện:

"cần cả vào và ra internet" → IGW + tuyến trong route table + IP công cộng "ra được nhưng không ai vào được" → NAT Gateway "IPv6, chỉ ra không vào" → Egress-only Internet Gateway "không được ra internet chút nào" → private subnet, không NAT "gọi dịch vụ AWS mà không qua internet" → VPC endpoint

Ba việc kiểm chứng: | Việc | Cách | |---|---| | IGW đã gắn chưa | describe-internet-gateways --filters Name=attachment.vpc-id,... | | Subnet có phải public không | đọc route table, tìm 0.0.0.0/0 → igw- | | Máy ra được chưa | trên máy: curl https://checkip.amazonaws.com |

Và một sai lầm rất hay gặp khi tự dựng VPC lần đầu: tạo Internet Gateway rồi quên thêm tuyến vào route table. Console không báo lỗi gì, mọi thứ trông như đã xong, và triệu chứng duy nhất là mọi kết nối ra ngoài đều timeout — thứ dễ bị đổ nhầm cho security group hơn là cho một dòng còn thiếu trong bảng định tuyến.

Đáp án

D — Tạo IAM ROLE cho các instance EC2 và cấp cho role đó quyền đọc tham số trong Systems Manager.

Vì sao đúng

Nguyên tắc bất di bất dịch: tải công việc chạy trên EC2 luôn dùng role, không bao giờ dùng IAM user.

⚠ Điểm mấu chốt — chỉ role mới gắn được vào instance:

IAM ROLE + instance profile
        ↓
    Gắn thẳng vào instance EC2
        ↓
    IMDS cấp thông tin xác thực TẠM THỜI,
    tự làm mới, không nằm trên đĩa
        ↓
    → SDK/CLI tự tìm thấy
    → không có khoá nào để lộ
        ↓
IAM USER / GROUP / POLICY
        ↓
    KHÔNG gắn được vào instance
        ↓
    User → phải có access key trên máy
    Group → chỉ là tập hợp user
    Policy → chỉ là tài liệu, phải gắn vào ai đó

⚠ Chính sách nên viết chặt tới đâu:

{
  "Effect": "Allow",
  "Action": ["ssm:GetParameter", "ssm:GetParameters"],
  "Resource": "arn:aws:ssm:ap-southeast-1:123456789012:parameter/ung-dung/csdl/*"
}

Và với SecureString còn cần thêm quyền giải mã:

{
  "Effect": "Allow",
  "Action": "kms:Decrypt",
  "Resource": "arn:aws:kms:...:key/<id-cua-CMK>"
}

Thiếu kms:Decrypt
        ↓
    → GetParameter với WithDecryption=true
      trả về AccessDenied
    → lỗi rất hay gặp, và thông báo không nói rõ

Xem thêm câu #11842 (cùng lô) và #11813, #11814 (lô 127): cùng nguyên tắc — EC2 dùng IAM role, không dùng khoá dài hạn.

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

• C (tạo IAM policy cho ứng dụng và cấp quyền đọc tham số) — đây là phương án gần nhất và chính sách đúng là thứ cần viết, nhưng policy phải được GẮN vào một thực thể (user, group hay role). Bản thân nó không cấp quyền cho ai cả — câu trả lời phải nói rõ là gắn vào role.

• A (tạo IAM user cho ứng dụng) — kéo theo access key dài hạn phải nằm trên máy, đúng thứ role sinh ra để loại bỏ.

• B (tạo IAM group cho ứng dụng) — group chỉ chứa user, không gắn vào instance được, và cũng không phải là một danh tính có thể đảm nhận.

Ghi nhớ

⚠ Bốn thực thể IAM — bảng phải thuộc: | Thực thể | Gắn vào EC2 được | Dùng khi | |---|---|---| | Role | CÓ (qua instance profile) | tải công việc: EC2, Lambda, ECS, EKS | | User | không | người thật, hoặc hệ thống NGOÀI AWS | | Group | không | gom user để quản lý quyền | | Policy | không (phải gắn vào thực thể) | mô tả quyền |

Từ khoá nhận diện:

"EC2 cần truy cập dịch vụ AWS" → IAM role "cách AN TOÀN NHẤT" → role + quyền tối thiểu "đọc SecureString" → nhớ thêm kms:Decrypt "bí mật cần XOAY tự động" → Secrets Manager "máy tại chỗ cần gọi AWS" → IAM Roles Anywhere hoặc SSM Hybrid Activation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đang dùng role nào | trên máy: aws sts get-caller-identity | | Đọc được tham số không | aws ssm get-parameter --name ... --with-decryption | | Thiếu quyền ở đâu | CloudTrail — bản ghi AccessDenied nói rõ action nào bị chặn |

Và một lỗi rất tốn thời gian nếu chưa từng gặp: quyền ssm:GetParameter không đủ để đọc một SecureString. Lời gọi sẽ trả về AccessDenied, và người gỡ lỗi thường quay lại soi chính sách SSM hết lần này tới lần khác — trong khi thứ còn thiếu là kms:Decrypt trên khoá đã mã hoá tham số đó, một chính sách nằm ở dịch vụ hoàn toàn khác.