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

Đáp án

A — Tạo S3 GATEWAY ENDPOINT dùng chính sách endpoint mặc định, và gắn private subnet vào endpoint đó.

Vì sao đúng

Đề có ba ràng buộc, và gateway endpoint thoả cả ba cùng lúc.

⚠ Điểm mấu chốt — ba ràng buộc và cách gateway endpoint đáp ứng:

1. "Truy cập S3 CÙNG REGION"
        ↓
    Gateway endpoint phục vụ S3 trong CÙNG Region
    → đúng phạm vi

2. "KHÔNG đổi cấu hình EC2 hay ứng dụng"
        ↓
    Endpoint hoạt động ở tầng ĐỊNH TUYẾN
    → ứng dụng vẫn gọi s3.<region>.amazonaws.com
    → SDK không phải sửa gì
    → không phải cài gì lên máy

3. "KHÔNG được ra internet"
        ↓
    Gateway endpoint KHÔNG dùng IGW, KHÔNG dùng NAT
    → lưu lượng đi trong mạng AWS
    → subnet vẫn hoàn toàn private

⚠ Cơ chế — nó chỉ thêm một tuyến:

Route table của private subnet, sau khi gắn endpoint:

    10.0.0.0/16          →  local
    pl-xxxxxxxx (S3)     →  vpce-0123abcd   ← tự thêm
        ↓
    "pl-" là PREFIX LIST của S3
    → chứa toàn bộ dải IP của S3 trong Region đó
    → AWS tự cập nhật khi dải thay đổi
        ↓
    → mọi gói tin tới S3 đi qua endpoint
    → KHÔNG có tuyến 0.0.0.0/0 nào cả

⚠ Và nó MIỄN PHÍ — điểm rất đáng nhớ:

Gateway endpoint (S3, DynamoDB)
        ↓
    Không phí theo giờ
    Không phí theo dữ liệu
        ↓
    So với NAT Gateway:
      phí giờ + phí xử lý MỖI GB
        ↓
    → chuyển lưu lượng S3 từ NAT sang endpoint
      là cách giảm hoá đơn NAT hiệu quả nhất

Xem thêm câu #11852 (lô 128): cùng dùng gateway endpoint, nhưng ở đó còn thêm yêu cầu khoá bucket chỉ nhận request từ endpoint bằng bucket policy với aws:sourceVpce.

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

• B (NAT gateway ở public subnet, thêm tuyến 0.0.0.0/0 trong route table) — đây là phương án gần nhất và về kỹ thuật thì máy sẽ truy cập được S3, nhưng nó vi phạm thẳng ràng buộc "không được ra internet": NAT mở đường ra toàn bộ internet. Lại còn tốn phí trong khi endpoint miễn phí.

• C (dựng Direct Connect rồi định tuyến request S3 qua đó) — Direct Connect là đường riêng từ trung tâm dữ liệu CỦA CÔNG TY tới AWS. Ở đây nguồn là EC2 đã nằm trong AWS, không có trung tâm dữ liệu nào tham gia.

• D (dựng đường hầm VPN từ private subnet tới các bucket S3) — không có cơ chế nào như vậy. VPN của AWS nối VPC với mạng tại chỗ hoặc VPC khác, không nối tới một dịch vụ.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Chi phí | MIỄN PHÍ | phí giờ + phí GB | | Cơ chế | tuyến trong route table (prefix list) | ENI có IP riêng trong subnet | | Từ mạng tại chỗ | KHÔNG dùng được | dùng được qua VPN/DX | | Cần đổi ứng dụng | không | không (nếu bật private DNS) | | Bảo mật thêm | endpoint policy | endpoint policy + security group |

Từ khoá nhận diện:

"private subnet cần gọi S3, không ra internet" → gateway endpoint "không được đổi cấu hình ứng dụng" → endpoint hoạt động ở tầng định tuyến "mạng tại chỗ cũng cần truy cập riêng tư tới S3" → interface endpoint "phí NAT tăng vì lưu lượng S3" → gateway endpoint, miễn phí "chỉ cho phép truy cập bucket từ VPC" → bucket policy + aws:sourceVpce

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint đã vào route table chưa | describe-route-tables, tìm vpce- | | Lưu lượng có đi qua endpoint không | VPC Flow Logs | | Máy có gọi được S3 không | aws s3 ls từ chính máy đó |

Và một cách kiểm chứng gọn cho ràng buộc "không được ra internet": đọc route table bằng CLI thay vì nhìn console. Chỉ cần đúng một dòng 0.0.0.0/0 trỏ tới IGW hoặc NAT là cam kết cô lập bị phá vỡ hoàn toàn — và trên giao diện, một route table có mười dòng trông chẳng khác gì một route table có chín dòng.

Đáp án

B — Thêm SHARD vào cụm Redis đang có.

Vì sao đúng

Cụm đang chạy ở chế độ cluster mode enabled, và đó là chế độ duy nhất cho phép mở rộng ngang bằng cách thêm shard.

⚠ Điểm mấu chốt — cluster mode chia dữ liệu theo shard:

Redis cluster mode enabled
        ↓
    Dữ liệu được chia thành 16.384 HASH SLOT
        ↓
    Các slot phân bổ cho các SHARD
        ↓
    Mỗi shard = 1 node chính + tối đa 5 replica
        ↓
Thêm shard
        ↓
    - Slot được PHÂN BỔ LẠI qua nhiều shard hơn
    - Tổng BỘ NHỚ tăng → cache được nhiều dữ liệu hơn
    - Tổng THÔNG LƯỢNG tăng → phục vụ nhiều request hơn
        ↓
    → tỉ lệ cache hit cao hơn
    → thời gian đọc tốt hơn, đúng yêu cầu đề

⚠ Và việc này làm được TRỰC TUYẾN:

Online resharding
        ↓
    Thêm hoặc bớt shard mà KHÔNG dừng cụm
        ↓
    Redis tự chuyển slot sang shard mới
        ↓
    → ứng dụng vẫn phục vụ trong lúc chuyển
    → chỉ cần client hỗ trợ cluster mode
      (đọc được lệnh MOVED/ASK)

⚠ Hai hướng mở rộng — chọn theo thứ đang cạn:

Thiếu BỘ NHỚ / thiếu thông lượng GHI
        ↓
    → THÊM SHARD  (mở rộng ngang)   ← đề này

Thiếu thông lượng ĐỌC
        ↓
    → THÊM REPLICA trong mỗi shard
    → hoặc bật đọc từ replica ở phía client

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

• C (đưa dữ liệu tĩnh sang S3) — đây là phương án gần nhất và là một cải tiến kiến trúc tốt thật, nhưng đề nói rõ vấn đề là thời gian ĐỌC dữ liệu qua tầng cache, không phải phục vụ tệp tĩnh. (Và với nội dung tĩnh thì câu trả lời đầy đủ hơn sẽ là S3 + CloudFront.)

• A (dùng RDS Multi-AZ) — Multi-AZ là khả năng chịu lỗi, KHÔNG tăng năng lực: node dự phòng ở chế độ standby, không phục vụ truy vấn nào.

• D (dùng hàng đợi tin nhắn để cache dữ liệu) — hàng đợi không phải cache. SQS phục vụ việc tách rời các thành phần và xử lý bất đồng bộ, không có khái niệm đọc lại một khoá.

Ghi nhớ

⚠ Hai chế độ của ElastiCache for Redis — bảng phải thuộc: | | Cluster mode DISABLED | Cluster mode ENABLED | |---|---|---| | Số shard | 1 | tối đa 500 | | Mở rộng | chỉ đổi cỡ node (dọc) | THÊM SHARD (ngang) | | Dữ liệu | toàn bộ trong một node | chia theo hash slot | | Replica | tối đa 5 | tối đa 5 MỖI shard | | Client | Redis client thường | phải hỗ trợ cluster mode |

Từ khoá nhận diện:

"cluster mode enabled, cần thêm năng lực" → THÊM SHARD "cần thêm thông lượng ĐỌC" → thêm replica "cache không đủ chỗ, hay bị đẩy khoá ra" → thêm shard, hoặc node lớn hơn "tải đọc CSDL cao" → read replica của RDS, hoặc ElastiCache "nội dung tĩnh" → S3 + CloudFront

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cache có đủ chỗ không | Evictions và DatabaseMemoryUsagePercentage | | Cache có hiệu quả không | CacheHitRate — dưới 80% là nên xem lại | | Resharding xong chưa | trạng thái cụm và describe-replication-groups |

Và một chỉ số nên nhìn trước khi quyết định thêm shard: Evictions. Nếu nó bằng 0 mà thời gian đọc vẫn chậm thì vấn đề không nằm ở dung lượng cache — nhiều khả năng là CacheHitRate thấp do TTL quá ngắn hoặc do ứng dụng không cache đúng những truy vấn tốn kém nhất, và thêm shard khi ấy chỉ làm hoá đơn tăng chứ không làm trang web nhanh hơn.

Đáp án

A — ID của AMI được tham chiếu trong template KHÔNG TỒN TẠI ở Region eu-west-1.

Vì sao đúng

Đây là nguyên nhân số một khiến một template CloudFormation chạy tốt ở Region này lại hỏng ở Region khác.

⚠ Điểm mấu chốt — AMI ID là tài nguyên THEO TỪNG REGION:

AMI của Amazon Linux 2023 ở us-east-1
        ↓
    ami-0abcdef1234567890
        ↓
Cùng phiên bản đó ở eu-west-1
        ↓
    ami-0fedcba0987654321   ← ID HOÀN TOÀN KHÁC
        ↓
    Ghi cứng một AMI ID vào template
        ↓
    → chạy ở Region khác:
      "The image id does not exist"
    → CREATE_FAILED → ROLLBACK_COMPLETE

⚠ Ba cách viết template không phụ thuộc Region:

1. SSM PUBLIC PARAMETER  ← tốt nhất
        ↓
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ami-amazon-linux-latest/
             al2023-ami-kernel-default-x86_64
        ↓
    → tự lấy AMI MỚI NHẤT và ĐÚNG REGION
    → không phải bảo trì gì

2. MAPPINGS
        ↓
    Bảng tra cứu AMI theo Region
    → !FindInMap [AmiTheoRegion, !Ref AWS::Region, Id]
    → phải tự cập nhật khi có AMI mới

3. PARAMETER truyền vào lúc tạo stack
        ↓
    → linh hoạt, nhưng người chạy phải biết ID

⚠ Các thứ KHÁC cũng phụ thuộc Region — kiểm luôn khi viết template:

Tên Availability Zone   → dùng !GetAZs, đừng ghi "us-east-1a"
ARN của dịch vụ         → dùng !Sub với ${AWS::Region}
Chứng chỉ ACM           → CloudFront BẮT BUỘC us-east-1
Loại instance           → không phải Region nào cũng có mọi loại
Dịch vụ                 → có dịch vụ chưa mở ở mọi Region
S3 bucket               → tên là DUY NHẤT TOÀN CẦU → sẽ trùng

Xem thêm câu #11857 (lô 128): cùng chủ đề template dùng lại được — ở đó là Parameters, Mappings và Conditions. Và #11822 (lô 127): một nguyên nhân khác khiến stack thất bại — chạm hạn mức dịch vụ.

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

• B (tài khoản không có quyền khởi chạy instance ở eu-west-1) — đây là phương án gần nhất vì thiếu quyền đúng là một nguyên nhân có thật, nhưng quyền IAM là TOÀN CỤC, không theo Region (trừ khi có điều kiện aws:RequestedRegion hoặc SCP chặn Region — đề không nhắc gì tới). AMI theo Region là nguyên nhân khả dĩ nhất.

• C (tag trong template chỉ dùng được ở eu-west-1) — tag chỉ là cặp khoá-giá trị, hoàn toàn không phụ thuộc Region và không gây lỗi tạo stack.

• D (AZ ở eu-west-1 không đủ năng lực) — có thể xảy ra, nhưng rất hiếm và thường chỉ với các loại instance đặc biệt. Nó cũng cho thông báo lỗi khác hẳn (InsufficientInstanceCapacity).

Ghi nhớ

⚠ Những gì phụ thuộc Region — bảng phải thuộc: | Phụ thuộc Region | Toàn cục | |---|---| | AMI ID | IAM (user, role, policy) | | Tên và ID của Availability Zone | Route 53 (hosted zone) | | Chứng chỉ ACM (trừ khi dùng cho CloudFront) | CloudFront | | Key pair của EC2 | tên bucket S3 (duy nhất toàn cầu) | | Security group, VPC, subnet | WAF cho CloudFront (ở us-east-1) | | Hạn mức dịch vụ | Organizations |

Từ khoá nhận diện:

"template chạy ở Region này, hỏng ở Region kia" → AMI ID ghi cứng "lấy AMI mới nhất tự động" → SSM public parameter "chứng chỉ cho CloudFront" → BẮT BUỘC us-east-1 "tên bucket đã tồn tại" → tên S3 là duy nhất TOÀN CẦU "triển khai ra nhiều tài khoản và Region" → StackSets

Ba việc kiểm chứng: | Việc | Cách | |---|---| | AMI có tồn tại ở Region không | aws ec2 describe-images --image-ids ami-xxx --region eu-west-1 | | AMI mới nhất ở Region đó là gì | aws ssm get-parameter --name /aws/service/ami-amazon-linux-latest/... | | Vì sao stack hỏng | describe-stack-events — đọc từ dưới lên |

Và một quy tắc nên đưa thẳng vào review code hạ tầng: bất kỳ chuỗi nào bắt đầu bằng ami- xuất hiện trong template đều là một lỗi chờ xảy ra. cfn-lint bắt được mẫu này, và cách sửa — thay bằng một SSM public parameter — vừa giải quyết vấn đề đa Region, vừa khiến template luôn dùng bản vá mới nhất mà không ai phải nhớ cập nhật.

Đáp án

C và E — CloudFront ACCESS LOG và ALB ACCESS LOG.

Vì sao đúng

Đề cần mã trạng thái HTTP ở tầng 7, và chỉ hai dịch vụ trong kiến trúc này ghi lại chúng.

⚠ Điểm mấu chốt — đường đi của một request và nơi có log tầng 7:

Người dùng
    │
    ▼
CLOUDFRONT  ──► access log: sc-status (200/403/502…)
    │           thấy được cả lỗi ở tầng edge
    ▼
ALB         ──► access log: elb_status_code
    │           VÀ target_status_code
    ▼
EC2         ──► log của ứng dụng (nếu có đẩy đi)
    │
    ▼
EFS         ──► KHÔNG có khái niệm HTTP

⚠ Vì sao ALB access log đặc biệt hữu ích:

Nó có HAI mã trạng thái riêng biệt:
        ↓
    elb_status_code     → ALB trả về cho client
    target_status_code  → EC2 trả về cho ALB
        ↓
    So hai cột này biết ngay lỗi ở đâu:
        ↓
    elb 502, target rỗng   → EC2 không phản hồi
                             hoặc phản hồi sai định dạng
    elb 503, target rỗng   → KHÔNG CÓ target khoẻ mạnh
    elb 504, target rỗng   → EC2 quá chậm (timeout)
    elb 500, target 500    → lỗi trong ỨNG DỤNG

⚠ Và CloudFront access log phân biệt lỗi của ai:

x-edge-result-type
        ↓
    Hit / Miss / RefreshHit  → cache
    Error                    → lỗi
    LimitExceeded            → chạm giới hạn
        ↓
x-edge-response-result-type
        ↓
    → so với sc-status để biết
      lỗi phát sinh ở EDGE hay ở ORIGIN

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

• A (VPC Flow Logs) — đây là phương án gần nhất vì nó cũng là log mạng, nhưng flow log ghi ở tầng 3/4: địa chỉ IP, cổng, giao thức, số byte, ACCEPT/REJECT. Không có mã trạng thái HTTP nào trong đó.

• D (log của Amazon EFS) — EFS là hệ thống tệp NFS, hoàn toàn không có khái niệm HTTP.

• B (Amazon CloudWatch Logs) — đây là một nơi CHỨA log, không phải một nguồn log. Nó có thể chứa log ứng dụng, và ALB/CloudFront thì mặc định ghi ra S3 chứ không ghi vào CloudWatch Logs.

Ghi nhớ

⚠ Log ở tầng nào — bảng phải thuộc: | Nguồn log | Tầng | Có mã HTTP | |---|---|---| | CloudFront access log | 7 | CÓ — sc-status | | ALB access log | 7 | CÓ — elb_status_code và target_status_code | | API Gateway access log | 7 | có | | NLB access log | 4 | KHÔNG (chỉ TLS listener mới có log) | | VPC Flow Logs | 3/4 | KHÔNG — chỉ ACCEPT/REJECT | | S3 server access log | 7 | có (mã của S3) | | CloudTrail | API | mã lỗi API, không phải HTTP |

Từ khoá nhận diện:

"mã trạng thái HTTP, lỗi 5xx" → ALB và CloudFront access log "gói tin bị chặn" → VPC Flow Logs "ai gọi API nào" → CloudTrail "ứng dụng in ra gì" → CloudWatch Logs (phải tự đẩy lên) "truy vấn khối lượng log lớn" → Athena trên S3

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lỗi ở ALB hay ở ứng dụng | so HTTPCode_ELB_5XX với HTTPCode_Target_5XX | | Lỗi ở edge hay ở origin | CloudFront log, cột x-edge-result-type | | Request cụ thể nào lỗi | Athena trên log ALB, lọc elb_status_code >= 500 |

Và một cách khoanh vùng rất nhanh trước khi mở bất kỳ tệp log nào: so hai chỉ số HTTPCode_ELB_5XX_Count và HTTPCode_Target_5XX_Count của ALB. Nếu chỉ cột ELB tăng còn cột Target đứng yên, vấn đề nằm giữa ALB và máy — thường là health check hoặc timeout; nếu cả hai cùng tăng thì lỗi đến từ chính ứng dụng, và bạn nên bắt đầu từ log của nó chứ không phải từ hạ tầng.

Đáp án

B — AWS CloudTrail.

Vì sao đúng

Câu hỏi là "ai đang gọi tới hàng đợi", và chỉ có một dịch vụ ghi lại danh tính của người gọi API.

⚠ Điểm mấu chốt — CloudTrail ghi AI đã gọi, TỪ ĐÂU, LÚC NÀO:

Mỗi bản ghi CloudTrail có:
        ↓
    userIdentity      → IAM user, role, hay tài khoản nào
    sourceIPAddress   → gọi từ địa chỉ nào
    eventTime         → lúc mấy giờ
    eventName         → SendMessage, ReceiveMessage…
    userAgent         → SDK nào, ứng dụng nào
    requestParameters → hàng đợi nào
        ↓
    → đủ để chỉ ra chính xác nguồn của lượng gọi tăng vọt

⚠ Nhưng có một điều KHÁC BIỆT rất quan trọng với SQS:

Management event (bật sẵn, miễn phí)
        ↓
    CreateQueue, DeleteQueue,
    SetQueueAttributes, AddPermission
        ↓
    → thao tác QUẢN LÝ hàng đợi

Data event (phải bật riêng, có phí)
        ↓
    SendMessage, ReceiveMessage, DeleteMessage
        ↓
    → thao tác trên TIN NHẮN
        ↓
    Đây mới là loại sinh ra lượng gọi lớn
    → phải bật data event cho SQS
      mới thấy được nguồn thật

⚠ Ghép với CloudWatch để có bức tranh đầy đủ:

CloudWatch  → biết CÓ vấn đề
        ↓
    NumberOfMessagesSent
    NumberOfEmptyReceives   ← rất quan trọng
    ApproximateNumberOfMessagesVisible
        ↓
CloudTrail  → biết vấn đề ĐẾN TỪ ĐÂU
        ↓
    danh tính, IP, ứng dụng cụ thể

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

• C (Amazon CloudWatch) — đây là phương án gần nhất và rất hữu ích để thấy quy mô vấn đề, nhưng chỉ số CloudWatch là con số tổng hợp: bao nhiêu tin nhắn được gửi, bao nhiêu lần nhận rỗng. Nó không cho biết danh tính người gọi — đúng thứ đề cần.

• A (Amazon SQS Access Logs) — không tồn tại. SQS không có access log kiểu S3 hay ALB; việc ghi lại lời gọi API do CloudTrail đảm nhiệm.

• D (AWS Cost Explorer) — cho biết tốn bao nhiêu tiền, nhóm được theo dịch vụ và tag, nhưng không cho biết lời gọi đến từ đâu.

Ghi nhớ

⚠ Ba nguồn dữ liệu — bảng phải thuộc: | Nguồn | Trả lời câu hỏi | |---|---| | CloudTrail | AI gọi, TỪ ĐÂU, LÚC NÀO, làm gì | | CloudWatch | BAO NHIÊU, xu hướng ra sao | | Cost Explorer | TỐN bao nhiêu tiền, theo chiều nào | | VPC Flow Logs | gói tin đi đâu, có bị chặn không |

Từ khoá nhận diện:

"ai đang gọi API này" → CloudTrail "lời gọi tới SQS/S3/DynamoDB từng bản ghi" → CloudTrail DATA EVENT "số lượng, xu hướng" → CloudWatch "chi phí tăng ở đâu" → Cost Explorer "chi phí SQS cao bất thường" → kiểm tra NumberOfEmptyReceives trước tiên

⚠ Chi phí SQS — nguyên nhân số một là NHẬN RỖNG: | Vấn đề | Nội dung | |---|---| | Short polling (mặc định) | trả lời ngay kể cả khi không có tin nhắn | | Hậu quả | ứng dụng gọi ReceiveMessage liên tục → hàng triệu lời gọi rỗng, đều tính tiền | | Long polling | ReceiveMessageWaitTimeSeconds = 1-20 giây | | Kết quả | giảm số lời gọi tới hàng chục lần, và giảm cả độ trễ | | Chỉ số theo dõi | NumberOfEmptyReceives |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang gọi | CloudTrail (data event) — nhóm theo userIdentity | | Có nhận rỗng nhiều không | NumberOfEmptyReceives | | Long polling đã bật chưa | get-queue-attributes → ReceiveMessageWaitTimeSeconds |

Và một điều nên kiểm tra trước cả khi mở CloudTrail trong tình huống chi phí SQS tăng: ReceiveMessageWaitTimeSeconds có đang bằng 0 không. Phần lớn các trường hợp "số lời gọi SQS tăng vọt" hoá ra không phải do ai đó gọi sai, mà do một consumer dùng short polling quay vòng hàng nghìn lần mỗi phút trên một hàng đợi gần như luôn rỗng — và sửa nó chỉ là đổi một thuộc tính.

Đáp án

C — Xem PERSONAL HEALTH DASHBOARD để biết các đợt bảo trì theo lịch.

Vì sao đúng

Đề cần biết những máy CỦA MÌNH nào sẽ bị ảnh hưởng, và chỉ Personal Health Dashboard trả lời câu hỏi đó.

⚠ Điểm mấu chốt — hai bảng điều khiển hoàn toàn khác nhau:

SERVICE HEALTH DASHBOARD (công khai)
        ↓
    Tình trạng CHUNG của dịch vụ AWS
    → "EC2 đang có sự cố ở us-east-1"
        ↓
    Ai cũng xem được, KHÔNG nói gì
    về tài nguyên cụ thể của bạn

PERSONAL HEALTH DASHBOARD  ← đề này
        ↓
    Sự kiện ảnh hưởng tới CHÍNH TÀI NGUYÊN của bạn
        ↓
    Liệt kê ĐÍCH DANH:
      instance i-0abc... sẽ bảo trì lúc ...
      instance i-0def... sẽ retire ngày ...
        ↓
    → đúng thứ đề cần, và KHÔNG PHẢI CÀI GÌ

⚠ Vì sao "ít công quản trị nhất":

Có sẵn ở mọi tài khoản, miễn phí
Không phải cài agent
Không phải viết script
Không phải theo dõi thủ công
        ↓
    Và tự động hoá được bằng EventBridge
    → không cần ai vào xem hằng ngày

⚠ Ghép EventBridge để không bao giờ lỡ một thông báo:

AWS Health phát sự kiện vào EventBridge
        ↓
    Mẫu sự kiện:
      source: aws.health
      detail-type: AWS Health Event
      detail.eventTypeCode:
        AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED
        AWS_EC2_SYSTEM_MAINTENANCE_SCHEDULED
        ↓
    Target: SNS báo đội trực,
            hoặc SSM Automation tự stop/start
        ↓
    → nhiều tài khoản: bật ORGANIZATIONAL VIEW

Xem thêm câu #11853 (lô 128): gom Health của nhiều tài khoản bằng organizational view. Và #11871 (lô 128): xử lý một sự kiện bảo trì bằng stop/start.

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

• A (xem AWS Service Health Dashboard) — đây là phương án gần nhất và cùng họ dịch vụ, nhưng nó chỉ hiển thị tình trạng chung của dịch vụ AWS, không liệt kê tài nguyên nào của bạn bị ảnh hưởng.

• B (cài CloudWatch agent lên mọi máy và theo dõi tính sẵn sàng) — rất nhiều công, và nó chỉ cho biết máy đang khoẻ hay không, chứ không dự báo được lịch bảo trì sắp tới.

• D (theo dõi CloudTrail để tìm lời gọi StopInstances) — phản ứng SAU khi việc đã xảy ra, và bảo trì theo lịch cũng không nhất thiết đi kèm một lời gọi API nào để mà bắt.

Ghi nhớ

⚠ Hai bảng điều khiển Health — bảng phải thuộc: | | Service Health Dashboard | Personal Health Dashboard | |---|---|---| | Nội dung | tình trạng chung của dịch vụ | ảnh hưởng tới TÀI NGUYÊN CỦA BẠN | | Ai xem được | công khai | chỉ tài khoản của bạn | | Liệt kê tài nguyên | không | CÓ, đích danh | | Nhiều tài khoản | — | organizational view | | API | không | Health API — cần gói Business/Enterprise |

Từ khoá nhận diện:

"máy NÀO CỦA TÔI bị ảnh hưởng" → Personal Health Dashboard "AWS có đang gặp sự cố không" → Service Health Dashboard "gom nhiều tài khoản" → organizational view "tự động phản ứng" → EventBridge + Lambda/SSM "máy sắp retire" → stop/start ngoài giờ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy nào bị lên lịch | EC2 → Events, hoặc describe-instance-status --include-all-instances | | Sự kiện Health đang mở | describe-events (hoặc describe-events-for-organization) | | Cảnh báo có tới không | gửi thử một sự kiện qua EventBridge |

Và một cấu hình rất đáng dựng một lần rồi dùng mãi: một EventBridge rule bắt mọi sự kiện aws.health và đẩy vào một kênh của đội trực. Personal Health Dashboard trả lời được câu hỏi của đề, nhưng nó chỉ hữu ích khi có người mở ra xem — còn một quy tắc EventBridge thì báo cho bạn ngay cả trong tuần không ai nghĩ tới việc kiểm tra.

Đáp án

A — Không truy cập được KHOÁ KMS dùng để mã hoá hoặc giải mã instance CSDL.

Vì sao đúng

Chính tên trạng thái đã nói ra vấn đề: inaccessible-encryption-credentials — thông tin xác thực để mã hoá không truy cập được.

⚠ Điểm mấu chốt — RDS cần khoá KMS ở MỌI THỜI ĐIỂM:

Instance CSDL được mã hoá bằng một CMK
        ↓
    RDS cần khoá đó để:
      - giải mã dữ liệu khi đọc
      - mã hoá dữ liệu khi ghi
        ↓
    Mất quyền truy cập khoá
        ↓
    → RDS KHÔNG THỂ phục vụ
    → trạng thái inaccessible-encryption-credentials
    → CSDL không truy cập được

⚠ Bốn nguyên nhân, theo thứ tự hay gặp:

1. KHOÁ BỊ VÔ HIỆU HOÁ (disabled)
        ↓
    → bật lại: enable-key  → sửa được

2. KHOÁ BỊ LÊN LỊCH XOÁ
        ↓
    → HUỶ LỆNH XOÁ NGAY: cancel-key-deletion
    → còn 7-30 ngày để cứu
    → quá hạn: DỮ LIỆU MẤT VĨNH VIỄN

3. KEY POLICY bị sửa
        ↓
    → RDS không còn quyền kms:Decrypt,
      kms:GenerateDataKey, kms:CreateGrant
    → khôi phục lại key policy

4. GRANT bị thu hồi
        ↓
    → RDS dùng grant để truy cập khoá
    → tạo lại instance từ snapshot nếu cần

⚠ Và một chi tiết quyết định khả năng cứu vãn:

Trạng thái này KHÔNG tự phục hồi
        ↓
    Sau khi sửa quyền khoá
        ↓
    → phải KHỞI ĐỘNG LẠI instance
      (start-db-instance hoặc reboot)
        ↓
    Nếu khoá đã BỊ XOÁ HẲN
        ↓
    → không có cách nào cứu
    → snapshot mã hoá bằng khoá đó cũng vô dụng

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

• C (đang bật hoặc tắt xác thực IAM cho CSDL) — đây là phương án gần nhất vì cũng là một thao tác liên quan tới xác thực, nhưng thao tác đó cho trạng thái modifying, và không làm CSDL không truy cập được.

• B (đang bật hoặc tắt Enhanced Monitoring) — cũng cho trạng thái modifying, hoàn toàn không liên quan tới mã hoá.

• D (đã dùng hết dung lượng lưu trữ) — cho trạng thái riêng là storage-full, một thông báo rất khác.

Ghi nhớ

⚠ Các trạng thái RDS đáng nhớ — bảng phải thuộc: | Trạng thái | Nghĩa | Xử lý | |---|---|---| | inaccessible-encryption-credentials | không truy cập được khoá KMS | bật lại khoá / huỷ lệnh xoá / sửa key policy | | storage-full | hết dung lượng | tăng dung lượng, bật storage autoscaling | | incompatible-parameters | parameter group sai | sửa tham số rồi reboot | | incompatible-network | vấn đề VPC/subnet | kiểm tra subnet group | | modifying | đang áp dụng thay đổi | chờ | | storage-optimization | đang tối ưu sau khi đổi cỡ | vẫn dùng được |

Từ khoá nhận diện:

"inaccessible-encryption-credentials" → khoá KMS: vô hiệu, bị xoá, hoặc mất quyền "storage-full" → tăng dung lượng, bật autoscaling "khoá đã bị xoá hẳn" → dữ liệu MẤT VĨNH VIỄN "snapshot không copy được sang tài khoản khác" → phải dùng CMK và chia sẻ khoá "muốn kiểm soát khoá" → customer managed key, không dùng aws/rds

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khoá đang ở trạng thái nào | aws kms describe-key --key-id ... | | Ai đã đụng vào khoá | CloudTrail, lọc eventSource = kms.amazonaws.com | | Instance dùng khoá nào | describe-db-instances --query '...KmsKeyId' |

Và một cảnh báo nên tồn tại ở mọi tài khoản production: alarm khi có bất kỳ lời gọi ScheduleKeyDeletion hay DisableKey nào. Thời gian chờ bảy tới ba mươi ngày của KMS là một cơ hội cứu vãn rất rộng rãi — nhưng nó chỉ có giá trị nếu ai đó biết rằng đồng hồ đã bắt đầu đếm, và một CSDL bị khoá vào ngày thứ hai mươi chín thì đã quá muộn để phát hiện.

Đáp án

C — Thêm một sản phẩm từ portfolio được chia sẻ vào một portfolio CỤC BỘ của mình.

Vì sao đúng

Nguyên tắc của Service Catalog rất rõ: portfolio được chia sẻ vẫn thuộc quyền sở hữu của tài khoản gốc; bên nhận chỉ dùng, không sửa.

⚠ Điểm mấu chốt — chia sẻ là chỉ đọc, nhưng dùng lại được:

Tài khoản A (chủ sở hữu)
        ↓
    Chia sẻ portfolio với tài khoản B
        ↓
Tài khoản B (bên nhận) LÀM ĐƯỢC:
        ↓
    - Nhập (import) portfolio
    - XEM các sản phẩm trong đó
    - THÊM một sản phẩm vào PORTFOLIO CỤC BỘ
      của chính mình
    - Cấp quyền cho người dùng của mình
      khởi chạy sản phẩm
    - Đặt LAUNCH CONSTRAINT trong portfolio cục bộ

Tài khoản B KHÔNG làm được:
        ↓
    - Thêm/xoá sản phẩm khỏi portfolio ĐƯỢC CHIA SẺ
    - Đổi launch role của sản phẩm trong đó
    - Sửa template của sản phẩm

⚠ Vì sao thiết kế như vậy:

Mục đích của Service Catalog
        ↓
    Đội trung tâm CHUẨN HOÁ hạ tầng
        ↓
    Nếu bên nhận sửa được
      → mỗi tài khoản một biến thể khác nhau
      → mất luôn ý nghĩa chuẩn hoá
        ↓
    Chủ sở hữu cập nhật phiên bản sản phẩm
        ↓
    → thay đổi TỰ ĐỘNG lan tới mọi bên nhận

⚠ Hai cách chia sẻ:

Chia sẻ theo TÀI KHOẢN (account-to-account)
        ↓
    Khai từng account id
    → bên nhận phải TỰ NHẬP portfolio

Chia sẻ qua ORGANIZATIONS  ← khuyến nghị
        ↓
    Chia sẻ với cả một OU
    → tài khoản mới vào OU tự có
    → không phải nhập tay

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

• A (thêm sản phẩm mới vào portfolio đã nhập) — đây là phương án gần nhất và dễ nhầm nhất, nhưng chỉ CHỦ SỞ HỮU mới thêm sản phẩm vào portfolio của mình. Bên nhận thêm được vào portfolio cục bộ, không phải vào portfolio đã nhập.

• B (đổi launch role của sản phẩm trong portfolio đã nhập) — launch constraint thuộc về portfolio gốc. Bên nhận chỉ đặt được launch constraint cho portfolio cục bộ của mình.

• D (xoá sản phẩm khỏi portfolio đã nhập) — cũng là thao tác của chủ sở hữu.

Ghi nhớ

⚠ Các thành phần của Service Catalog — bảng phải thuộc: | Thành phần | Nội dung | |---|---| | Product | một template CloudFormation đã được duyệt, có phiên bản | | Portfolio | tập hợp sản phẩm, gán quyền và ràng buộc ở mức này | | Constraint | launch, template, notification, tag update, stack set | | Provisioned product | một stack đã được người dùng khởi chạy | | Chia sẻ | theo tài khoản, hoặc qua Organizations (theo OU) |

Từ khoá nhận diện:

"phát hành hạ tầng chuẩn cho các đội tự dùng" → Service Catalog "người dùng khởi chạy được nhưng không có quyền tạo tài nguyên" → launch constraint "chặn hẳn việc dùng dịch vụ" → SCP, không phải Service Catalog "portfolio được chia sẻ, bên nhận sửa được gì" → chỉ dùng, không sửa "tài khoản mới tự có portfolio" → chia sẻ qua Organizations

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Portfolio đã chia sẻ với ai | describe-portfolio-shares | | Bên nhận thấy gì | ở tài khoản đó: list-accepted-portfolio-shares | | Ai đã khởi chạy gì | search-provisioned-products, và CloudTrail |

Và một cách kết hợp rất hiệu quả trong thực tế: SCP chặn việc tạo tài nguyên trực tiếp, còn Service Catalog mở ra con đường đã được duyệt. Khi đó các đội không bị mất khả năng tự phục vụ — họ vẫn dựng được môi trường trong vài phút — nhưng mọi thứ họ dựng đều đi qua đúng một template đã được review, đã có tag, đã có mã hoá và đã có sao lưu.

Đáp án

C — ON-DEMAND CAPACITY RESERVATIONS.

Vì sao đúng

Đề có một ràng buộc mà chỉ Capacity Reservation đáp ứng: phải CHẮC CHẮN có máy vào đúng lúc cần, và công việc không được gián đoạn giữa chừng.

⚠ Điểm mấu chốt — phân biệt BẢO ĐẢM NĂNG LỰC với GIẢM GIÁ:

Savings Plans / Reserved Instances
        ↓
    CAM KẾT CHI TIÊU để được GIẢM GIÁ
        ↓
    → KHÔNG bảo đảm có máy
    → vẫn có thể gặp InsufficientInstanceCapacity

On-Demand Capacity Reservation   ← đề này
        ↓
    ĐẶT TRƯỚC NĂNG LỰC ở một AZ cụ thể
        ↓
    → năng lực được GIỮ SẴN cho bạn
    → khởi chạy lúc nào cũng có
    → KHÔNG có giảm giá tự thân

⚠ Và hai thứ này GHÉP ĐƯỢC với nhau:

Capacity Reservation  → bảo đảm CÓ máy
        +
Savings Plans         → bảo đảm GIÁ RẺ
        ↓
    Savings Plans TỰ ĐỘNG áp lên
    capacity reservation đang chạy
        ↓
    → vừa chắc chắn có máy, vừa được giảm giá
    → đây là cấu hình đúng cho đề:
      cần tối thiểu 1 năm + chạy đều đặn

⚠ Vì sao Spot bị loại hẳn:

"Không được gián đoạn khi đã bắt đầu"
        ↓
    Spot có thể bị THU HỒI bất cứ lúc nào
    với 2 phút báo trước
        ↓
    → loại ngay, dù rẻ tới đâu

⚠ Chi tiết vận hành:

Capacity Reservation TÍNH TIỀN
kể cả khi KHÔNG CHẠY MÁY NÀO
        ↓
    Chạy vài giờ mỗi đêm, 5 ngày/tuần
        ↓
    → nên TẠO trước khi chạy
      và HUỶ sau khi xong
    → hoặc dùng reservation có
      EndDate tự hết hạn
        ↓
    Ghép với EventBridge Scheduler
    → tự tạo và tự huỷ theo lịch

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

• A (Regional Reserved Instances) — đây là phương án gần nhất vì RI có một biến thể bảo đảm năng lực, nhưng đó là Zonal RI. Regional RI KHÔNG bảo đảm năng lực — nó chỉ cho giảm giá và linh hoạt về AZ.

• D (Savings Plans) — thuần tuý là cơ chế giảm giá theo cam kết chi tiêu, hoàn toàn không giữ chỗ năng lực nào.

• B (On-Demand Instances) — trả giá đầy đủ và vẫn không bảo đảm có máy khi Region bận. Là phương án tệ nhất về cả hai mặt.

Ghi nhớ

⚠ Bảo đảm năng lực ↔ Giảm giá — bảng phải thuộc: | Cơ chế | Bảo đảm năng lực | Giảm giá | |---|---|---| | On-Demand Capacity Reservation | CÓ | không | | Zonal Reserved Instance | CÓ | có (tới 72%) | | Regional Reserved Instance | KHÔNG | có | | Savings Plans | KHÔNG | có (tới 72%) | | On-Demand | không | không | | Spot | không — bị thu hồi | tới 90% |

Từ khoá nhận diện:

"phải CHẮC CHẮN có máy" → Capacity Reservation hoặc Zonal RI "không được gián đoạn" → KHÔNG dùng Spot "tải ổn định, cam kết 1-3 năm" → Savings Plans "chịu được gián đoạn, muốn rẻ nhất" → Spot "chạy theo giờ cố định" → Capacity Reservation tạo/huỷ theo lịch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Reservation có được dùng không | describe-capacity-reservations → AvailableInstanceCount | | Savings Plans dùng hết chưa | Cost Explorer → Utilization report | | Có bị thiếu năng lực không | tìm lỗi InsufficientInstanceCapacity trong log ASG |

Và một điều rất dễ gây bất ngờ về hoá đơn: Capacity Reservation tính tiền suốt thời gian nó tồn tại, kể cả những giờ không có máy nào chạy. Với một tải chỉ chạy vài giờ mỗi đêm và năm ngày mỗi tuần, giữ reservation thường trực nghĩa là trả tiền cho khoảng bảy mươi phần trăm thời gian không dùng — nên cách làm đúng là tạo trước giờ chạy và huỷ sau khi xong, tự động hoá bằng một lịch EventBridge.

Đáp án

B — Triển khai RDS PROXY để quản lý kết nối, phân phối lưu lượng và gộp kết nối (connection pooling).

Vì sao đúng

Lỗi "too many connections" là lỗi về SỐ KẾT NỐI, không phải về CPU hay bộ nhớ — và RDS Proxy sinh ra đúng cho vấn đề đó.

⚠ Điểm mấu chốt — proxy gộp kết nối lại:

KHÔNG có proxy
        ↓
    Mỗi tiến trình ứng dụng mở kết nối riêng
        ↓
    100 tiến trình × 10 kết nối = 1.000 kết nối
        ↓
    max_connections của db.m6g.xlarge
      ≈ vài trăm
        ↓
    → "too many connections"

CÓ RDS Proxy
        ↓
    Ứng dụng kết nối tới PROXY (không giới hạn chặt)
        ↓
    Proxy giữ một POOL kết nối nhỏ tới CSDL
        ↓
    → nhiều kết nối ứng dụng dùng chung
      ít kết nối thật
    → CSDL không bao giờ chạm trần

⚠ Và vì sao "ít thay đổi mã nhất":

Chỉ đổi ENDPOINT trong chuỗi kết nối
        ↓
    từ  mydb.abc123.ap-southeast-1.rds.amazonaws.com
    sang mydb-proxy.proxy-abc123....rds.amazonaws.com
        ↓
    → cùng giao thức MySQL
    → cùng driver
    → KHÔNG viết lại mã nào
        ↓
    So với phương án C (tự viết pool trong ứng dụng):
      phải sửa mã, kiểm thử, triển khai lại
      và làm ở TỪNG ứng dụng

⚠ RDS Proxy còn cho thêm ba thứ:

1. FAILOVER NHANH HƠN
        ↓
    Proxy tự nhận biết failover
    → giảm thời gian gián đoạn tới 66%
    → ứng dụng không phải chờ DNS TTL

2. XÁC THỰC QUA SECRETS MANAGER
        ↓
    → mật khẩu không nằm trong ứng dụng
    → xoay mật khẩu không làm đứt kết nối

3. ÉP IAM AUTHENTICATION
        ↓
    → bỏ hẳn mật khẩu, dùng token tạm thời

Xem thêm câu #11838 (lô 128): cũng là RDS chậm, nhưng ở đó chỉ số cạn là CPU nên khoá là đổi cỡ instance. Ở đây chỉ số cạn là số kết nối nên khoá là RDS Proxy — hai khoá khác nhau vì tài nguyên bị cạn khác nhau, không mâu thuẫn. Nguyên tắc chung: chữa đúng thứ đang cạn.

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

• C (tự cài cơ chế gộp kết nối trong mã ứng dụng) — đây là phương án gần nhất và giải quyết đúng vấn đề về mặt kỹ thuật, nhưng nó đòi sửa mã ở mọi ứng dụng, trái với yêu cầu "thay đổi mã ít nhất". (Và với ứng dụng serverless như Lambda thì pool trong tiến trình gần như không có tác dụng.)

• A (đổi sang instance lớn hơn) — max_connections tăng theo bộ nhớ, nên cách này có làm nhẹ triệu chứng, nhưng nó tốn tiền suốt ngày đêm cho một vấn đề về quản lý kết nối, và vẫn chạm trần khi ứng dụng mở rộng thêm.

• D (thêm read replica để san tải kết nối) — kết nối GHI vẫn dồn về node chính, và ứng dụng phải sửa mã để tách đường đọc và đường ghi — nhiều thay đổi hơn hẳn.

Ghi nhớ

⚠ Chẩn đoán RDS theo đúng tài nguyên đang cạn — bảng phải thuộc: | Triệu chứng | Tài nguyên cạn | Cách chữa | |---|---|---| | "too many connections" | số kết nối | RDS Proxy | | CPUUtilization ~100% | CPU | đổi cỡ instance, tối ưu truy vấn | | FreeableMemory thấp | RAM | họ máy nhiều RAM (R-family) | | ReadIOPS chạm trần | IOPS | gp3 với IOPS cấp phát, io2 | | ReplicaLag cao | replica yếu | đổi cỡ replica | | storage-full | dung lượng | bật storage autoscaling |

Từ khoá nhận diện:

"too many connections" → RDS Proxy "Lambda gọi CSDL" → RDS Proxy, gần như bắt buộc "tải ĐỌC cao" → read replica "CPU cao" → đổi cỡ, xem Performance Insights "muốn failover nhanh hơn" → RDS Proxy hoặc Aurora

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang có bao nhiêu kết nối | chỉ số DatabaseConnections | | Trần là bao nhiêu | SHOW VARIABLES LIKE 'max_connections' | | Proxy có gộp hiệu quả không | chỉ số DatabaseConnections giảm sau khi chuyển qua proxy |

Và một thứ đáng kiểm tra trước khi kết luận là thiếu năng lực: rò rỉ kết nối trong chính ứng dụng. Một đoạn mã quên đóng kết nối sẽ khiến số kết nối tăng đều theo thời gian và chỉ trở về bình thường sau mỗi lần khởi động lại dịch vụ — RDS Proxy che được triệu chứng đó rất tốt, nhưng đồ thị DatabaseConnections dạng răng cưa đi lên vẫn là dấu hiệu nên đưa cho đội phát triển xem.