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

Đáp án

B, D — hai việc cần làm:

• B — Cấu hình AWS VPN giữa trung tâm dữ liệu tại chỗ và AWS.
• D — Dùng AWS KMS để quản lý khoá mã hoá dữ liệu.

Vì sao đúng

Đề nêu hai yêu cầu tách bạch, và mỗi giải pháp lo một yêu cầu:

⚠ Điều B — vì sao VPN chứ không phải thứ khác:

Môi trường lai: dữ liệu đi qua "shared networks"
        ↓
    Nghĩa là qua internet công cộng
        ↓
    Site-to-Site VPN dựng đường hầm IPsec
        ↓
    → MÃ HOÁ TOÀN BỘ lưu lượng giữa hai bên
    → dựng trong vài phút, chỉ bằng cấu hình
        ↓
    (Direct Connect thì riêng tư nhưng KHÔNG MÃ HOÁ —
     muốn cả hai thì phải chạy VPN đè lên nó)

⚠ Điều D — KMS là dịch vụ quản lý khoá của AWS:

KMS quản lý khoá cho:
        S3 (SSE-KMS), EBS, RDS, DynamoDB, EFS,
        Secrets Manager, Lambda env vars, và nhiều hơn nữa
        ↓
    → xoay khoá tự động
    → key policy kiểm soát ai dùng được
    → CloudTrail ghi lại MỌI lần dùng khoá
        ↓
    → đúng nghĩa "quản lý khoá mã hoá dữ liệu"

⚠ Và điểm phân biệt quan trọng nhất của câu này:

KMS làm gì:
        ↓
    Tạo và quản lý KHOÁ MÃ HOÁ ĐỐI XỨNG (và bất đối xứng)
    dùng để mã hoá DỮ LIỆU

KMS KHÔNG làm gì:
        ↓
    KHÔNG cấp CHỨNG CHỈ TLS/SSL
        ↓
    → chứng chỉ TLS là việc của ACM
    → đây là chỗ phương án C sai

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

• A (dùng ACM để tạo chứng chỉ TLS/SSL) — đây là phương án gần nhất và ACM đúng là nơi cấp chứng chỉ TLS. Nhưng chứng chỉ ACM không cài lên EC2 hay lên thiết bị tại chỗ được (không xuất được private key), nên nó không giải quyết được mã hoá cho kết nối lai giữa hai môi trường. VPN mới là câu trả lời cho vế đó.

• C (dùng KMS để tạo chứng chỉ TLS/SSL) — KMS KHÔNG cấp chứng chỉ TLS. Nó quản lý khoá mã hoá dữ liệu. Đây là bẫy trung tâm của câu hỏi.

• E (dùng CloudHSM để mã hoá dữ liệu bằng CMK) — thuật ngữ "CMK" thuộc về KMS, không phải CloudHSM. Ngoài ra CloudHSM là lựa chọn đắt và phức tạp hơn nhiều, chỉ cần khi yêu cầu tuân thủ đòi module phần cứng tự quản — đề không nêu yêu cầu đó.

Ghi nhớ

⚠ Mã hoá khi truyền và khi lưu — bảng phải thuộc: | | In transit (khi truyền) | At rest (khi lưu) | |---|---|---| | Công cụ | TLS/SSL, IPsec VPN, MACsec | KMS, CloudHSM | | Cho kết nối lai | Site-to-Site VPN | — | | Cho web | ACM cấp chứng chỉ cho ALB/CloudFront | — | | Cho dữ liệu | — | SSE-KMS, SSE-S3, EBS/RDS encryption |

Từ khoá nhận diện:

"mã hoá giữa tại chỗ và AWS" → Site-to-Site VPN "quản lý khoá mã hoá dữ liệu" → KMS "chứng chỉ TLS cho tên miền" → ACM "KMS cấp chứng chỉ TLS" → LUÔN SAI "module mã hoá phần cứng tự quản" → CloudHSM "riêng tư VÀ mã hoá" → Direct Connect + VPN

⚠ ACM, KMS, CloudHSM — ba dịch vụ dễ lẫn: | Dịch vụ | Việc | |---|---| | ACM | cấp và quản lý CHỨNG CHỈ TLS/SSL cho ALB, CloudFront, API Gateway | | KMS | quản lý KHOÁ MÃ HOÁ DỮ LIỆU — tích hợp sâu với mọi dịch vụ AWS | | CloudHSM | HSM phần cứng RIÊNG — bạn tự quản, AWS không truy cập được | | AWS Private CA | cấp chứng chỉ nội bộ, xuất được private key |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VPN có lên không | describe-vpn-connections, xem cả hai tunnel | | Dữ liệu đã mã hoá chưa | describe-volumes / get-bucket-encryption | | Ai dùng khoá | CloudTrail, lọc eventSource = kms.amazonaws.com |

Và một điểm cần làm rõ khi bàn về "mã hoá đầu-cuối" trong môi trường lai: VPN mã hoá đường truyền GIỮA hai mạng, còn bên trong VPC thì lưu lượng không tự động được mã hoá. Nếu yêu cầu tuân thủ nói "mã hoá mọi kênh truyền", hãy làm rõ xem chặng trong VPC có nằm trong phạm vi không — nếu có, bạn còn phải bật TLS cho từng kết nối giữa các dịch vụ, và với RDS thì đó là tham số rds.force_ssl.

Đáp án

A — Thêm bucket policy cấp quyền đọc cho tất cả mọi người trên các ĐỐI TƯỢNG trong bucket.

Vì sao đúng

Bẫy của câu này nằm ở khác biệt giữa "bucket" và "objects trong bucket" — đúng bẫy mà nhiều câu hỏi về chính sách S3 hay dùng.

⚠ Điểm mấu chốt — hai hành động cần hai Resource khác nhau:

Người dùng truy cập website
        ↓
    Trình duyệt gọi s3:GetObject cho từng tệp
        ↓
    Quyền phải khai trên ĐỐI TƯỢNG:
        "Resource": "arn:aws:s3:::ten-bucket/*"
        ↓
    Nếu chỉ khai trên bucket:
        "Resource": "arn:aws:s3:::ten-bucket"
        ↓
    → đó là quyền cho hành động cấp BUCKET (ListBucket)
    → GetObject KHÔNG khớp → 403 Forbidden

Bucket policy đúng:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PublicReadGetObject",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::ten-bucket/*"
  }]
}

⚠ Và một điều BẮT BUỘC phải làm cùng lúc trong môi trường hiện nay:

Từ tháng 4/2023, bucket mới BẬT SẴN Block Public Access
        ↓
    Nó GHI ĐÈ mọi bucket policy cho phép công khai
        ↓
    → viết policy đúng mà vẫn nhận 403
        ↓
    → phải TẮT Block Public Access cho bucket đó
      (hoặc dùng CloudFront + OAC và giữ bucket riêng tư)

Xem thêm câu #11761: cùng chủ đề website tĩnh trên S3 nhưng nguyên nhân khác — ở đó tên bucket phải TRÙNG tên miền thì DNS mới phân giải được. Hai câu là hai lỗi phổ biến nhất khi dựng website tĩnh trên S3.

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

• C (thêm bucket policy cấp quyền đọc cho mọi người trên BUCKET) — đây là phương án gần nhất và chỉ khác đáp án đúng ở một chữ. Quyền trên bucket (arn:aws:s3:::ten-bucket) áp cho các hành động cấp bucket như s3:ListBucket; nó không cho phép đọc TỆP, nên website vẫn trả 403.

• D (gỡ bucket policy mặc định đang từ chối quyền đọc) — không có "bucket policy mặc định" nào. Bucket mới không có policy nào cả; quyền truy cập bị từ chối theo implicit deny, chứ không phải do một chính sách Deny nào tồn tại.

• B (cấu hình cross-region replication) — sao chép dữ liệu sang Region khác. Không liên quan gì tới quyền truy cập.

Ghi nhớ

⚠ Hành động S3 và Resource tương ứng — bảng rất hay dùng: | Hành động | Resource phải là | |---|---| | s3:GetObject | arn:aws:s3:::bucket/* | | s3:PutObject | arn:aws:s3:::bucket/* | | s3:DeleteObject | arn:aws:s3:::bucket/* | | s3:ListBucket | arn:aws:s3:::bucket | | s3:GetBucketLocation | arn:aws:s3:::bucket | | Cách nhớ | thao tác trên ĐỐI TƯỢNG → có /*; thao tác trên BUCKET → không có |

Từ khoá nhận diện:

"403 khi truy cập website S3" → bucket policy thiếu quyền trên ĐỐI TƯỢNG, hoặc Block Public Access "tên miền không phân giải" → tên bucket phải trùng tên miền "cần HTTPS cho website S3" → phải dùng CloudFront "bucket policy mặc định" → KHÔNG TỒN TẠI "giữ bucket riêng tư mà vẫn phục vụ website" → CloudFront + OAC

⚠ Chẩn đoán 403 với website tĩnh trên S3 — thứ tự kiểm tra: | Bước | Kiểm tra | |---|---| | 1 | Block Public Access ở cấp tài khoản và cấp bucket | | 2 | Bucket policy — Resource có /* không | | 3 | Static website hosting đã bật chưa, có khai IndexDocument chưa | | 4 | Object Ownership — nếu là BucketOwnerEnforced thì ACL bị vô hiệu | | 5 | Đối tượng có mã hoá bằng KMS không (khi đó cần thêm quyền KMS) |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Block Public Access | get-public-access-block ở cả hai cấp | | Bucket policy hiện tại | get-bucket-policy --bucket <ten> | | Website endpoint có chạy không | curl http://bucket.s3-website-<region>.amazonaws.com |

Và một lời khuyên về hướng đi trước khi bỏ công gỡ Block Public Access: hãy cân nhắc dùng CloudFront với OAC thay vì mở bucket ra công khai. Bạn được HTTPS miễn phí, cache ở edge, chi phí truyền dữ liệu thấp hơn — và quan trọng nhất là bucket của bạn không bao giờ xuất hiện trong danh sách "S3 bucket mở công khai" mà các công cụ quét bảo mật vẫn rà internet để tìm.

Đáp án

D, C — hai bước cần làm:

• D — Bật S3 Server Access Logging trên mọi bucket bị ảnh hưởng, lưu log vào một bucket RIÊNG.
• C — Dùng Athena truy vấn log đó tìm lỗi HTTP 403, và xác định IAM user hoặc role đã gửi request.

Vì sao đúng

Hai bước này là thu thập dữ liệu rồi phân tích dữ liệu — thứ tự bắt buộc.

⚠ Điểm mấu chốt — access log ghi lại CẢ những lần truy cập BỊ TỪ CHỐI:

Ai đó thử truy cập bucket không có quyền
        ↓
    S3 từ chối → HTTP 403 AccessDenied
        ↓
    Lần thử đó VẪN được ghi vào access log
        ↓
    → biết ai thử, thử bucket nào, tệp nào, lúc nào, từ IP nào

⚠ Và mã 403 chính là dấu hiệu cần tìm:

403 Forbidden  → BỊ TỪ CHỐI vì thiếu quyền   ← đề cần
404 NoSuchKey  → không có tệp đó
200 OK         → thành công
503            → lỗi phía máy chủ (throttle), KHÔNG liên quan quyền

⚠ Truy vấn Athena tìm ra ngay:

SELECT requester, bucket, key, remoteip,
       count(*) AS so_lan_thu
FROM s3_access_logs
WHERE httpstatus = '403'
  AND parse_datetime(requestdatetime, 'dd/MMM/yyyy:HH:mm:ss Z')
      > timestamp '2026-08-01 00:00:00'
GROUP BY requester, bucket, key, remoteip
ORDER BY so_lan_thu DESC;

⚠ Và một quy tắc BẮT BUỘC khi cấu hình:

Bucket chứa log PHẢI KHÁC bucket được ghi log
        ↓
    Nếu ghi log vào chính bucket đó
        ↓
    → mỗi bản ghi log lại sinh ra một bản ghi log mới
    → VÒNG LẶP VÔ TẬN, hoá đơn tăng không giới hạn

Xem thêm câu #11602 và #11585: cùng công cụ này ở hai góc khác — phát hiện nhân viên truy cập trái phép mà họ không biết, và so sánh chi phí với CloudTrail data event.

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

• A (truy vấn access log tìm lỗi HTTP 503) — đây là phương án gần nhất và chỉ sai ở MÃ LỖI. 503 là lỗi phía máy chủ (S3 quá tải hoặc throttle), hoàn toàn không liên quan tới quyền truy cập. Mã cần tìm là 403.

• B (truy vấn S3 Analytics reports tìm lỗi 403) — S3 Analytics phân tích MẪU TRUY CẬP để gợi ý lớp lưu trữ (nên chuyển sang IA hay không). Nó không ghi lại từng request và không có mã lỗi HTTP nào.

• E (bật S3 Analytics và sinh báo cáo về truy cập trái phép) — cùng lý do: S3 Analytics không phải công cụ bảo mật.

Ghi nhớ

⚠ Hai cách ghi nhật ký truy cập S3 — bảng phải thuộc: | | Server Access Logging | CloudTrail Data Events | |---|---|---| | Chi phí | miễn phí (trả tiền lưu log) | có phí theo sự kiện | | Độ trễ | vài giờ, best effort | gần thời gian thực | | Ghi lần bị từ chối | có | có | | Thông tin identity | ít hơn | chi tiết hơn (role, session) | | Cảnh báo tự động | không sẵn | EventBridge, CloudWatch |

Từ khoá nhận diện:

"phát hiện truy cập trái phép vào S3" → access log + Athena, lọc 403 "cần cảnh báo NGAY khi có 403" → CloudTrail data event + EventBridge "gợi ý chuyển lớp lưu trữ" → S3 Analytics hoặc Storage Lens "danh sách mọi đối tượng và siêu dữ liệu" → S3 Inventory "bucket nào đang chia sẻ ra ngoài" → IAM Access Analyzer for S3

⚠ Bốn công cụ phân tích S3 — rất dễ lẫn: | Công cụ | Cho gì | |---|---| | Server Access Logging | từng REQUEST, kể cả bị từ chối | | S3 Inventory | danh sách TỪNG ĐỐI TƯỢNG + siêu dữ liệu, theo lịch | | S3 Storage Lens | số liệu tổng hợp về dung lượng và chi phí | | S3 Analytics | gợi ý lớp lưu trữ dựa trên mẫu truy cập |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log đã bật chưa | get-bucket-logging --bucket <ten> | | Log có tới không | xem bucket đích — chờ vài giờ | | Có bỏ sót không | access log là best effort — vụ nghiêm trọng thì đối chiếu thêm CloudTrail |

Và một lưu ý về kỳ vọng thời gian khi điều tra: S3 Server Access Logging có độ trễ vài giờ và được giao theo kiểu "best effort". Nó rất hợp để dựng bức tranh về những gì đã xảy ra, nhưng nếu đội bảo mật cần phát hiện và phản ứng ngay khi có người dò quét, thì phải bật CloudTrail data event cho những bucket nhạy cảm nhất và nối nó với EventBridge — chấp nhận trả phí để đổi lấy tốc độ.

Đáp án

B — Các chỉ số được đánh giá vẫn liên tục vượt ngưỡng đã định, nên alarm giữ nguyên trạng thái kích hoạt.

Vì sao đúng

CloudWatch Alarm là một máy trạng thái phản ánh tình hình HIỆN TẠI, không phải một sự kiện phát ra rồi thôi.

⚠ Điểm mấu chốt — ALARM nghĩa là "ngay lúc này vẫn đang vượt ngưỡng":

Chỉ số vượt ngưỡng
        ↓
    OK → ALARM, thực hiện action MỘT LẦN
        ↓
Chỉ số VẪN vượt ngưỡng
        ↓
    → giữ nguyên ALARM, KHÔNG lặp lại action
        ↓
Chỉ số trở lại dưới ngưỡng
        ↓
    → ALARM → OK, TỰ ĐỘNG, không cần ai reset

Vậy alarm kẹt mãi ở ALARM chỉ có một nghĩa: chỉ số thật sự vẫn đang vượt ngưỡng.

⚠ Hai hướng xử lý — phải xác định đúng hướng nào:

Vấn đề là THẬT
        ↓
    → CPU đang cao thật, hàng đợi đang dồn thật
    → sửa hệ thống

Ngưỡng đặt SAI
        ↓
    → chỉnh threshold
    → chỉnh EvaluationPeriods
    → đổi thống kê (Average thay vì Maximum)
    → dùng M-out-of-N thay vì N chu kỳ liên tiếp

Xem thêm câu #11567: cùng câu hỏi này ở lô trước, với bộ phương án nhiễu khác — ở đó bẫy là "phải reset alarm bằng mã ứng dụng". Khoá đáp án thống nhất: CloudWatch tự chuyển trạng thái theo dữ liệu, không ai reset thủ công.

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

• D (instance mà alarm theo dõi đang ở trạng thái stopped, buộc alarm ở ALARM) — đây là phương án gần nhất và nghe có lý. Nhưng khi instance dừng, nó ngừng phát chỉ số — alarm sẽ chuyển sang INSUFFICIENT_DATA, không phải ALARM (trừ khi bạn đặt treat missing data as breaching).

• A (thông báo gửi tới SNS topic chưa xác minh, khiến trạng thái bị khoá) — bịa: việc gửi thông báo thất bại không ảnh hưởng gì tới trạng thái của alarm. Trạng thái do dữ liệu chỉ số quyết định.

• C (alarm chưa được cấu hình IAM role cho phép đổi trạng thái) — alarm không cần IAM role nào để đổi trạng thái. CloudWatch tự quản việc đó.

Ghi nhớ

⚠ Ba trạng thái của CloudWatch Alarm — bảng phải thuộc: | Trạng thái | Nghĩa | |---|---| | OK | chỉ số nằm trong ngưỡng | | ALARM | chỉ số vượt ngưỡng — cập nhật liên tục, không phải sự kiện | | INSUFFICIENT_DATA | thiếu dữ liệu để kết luận |

Từ khoá nhận diện:

"kẹt ở ALARM" → chỉ số vẫn đang vượt ngưỡng thật "phải reset alarm bằng tay" → LUÔN SAI với CloudWatch "kẹt ở INSUFFICIENT_DATA" → chỉnh "treat missing data" "báo giả liên tục" → tăng EvaluationPeriods hoặc dùng M-out-of-N "chỉ số bất thường theo mùa" → anomaly detection thay ngưỡng cố định

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lịch sử chuyển trạng thái | describe-alarm-history | | Chỉ số thật ra sao | vẽ đồ thị cùng khoảng thời gian với đường ngưỡng | | Action có chạy không | SNS topic có subscriber đã xác nhận chưa |

Và một quan điểm đáng nhớ về loại tình huống này: một alarm kẹt ở ALARM nhiều ngày là bằng chứng rằng alarm đó đã hỏng, bất kể chỉ số có đúng hay không. Đội vận hành học rất nhanh cách phớt lờ một dòng đỏ luôn đỏ — và khi ấy nó không còn là cảnh báo mà chỉ là đồ trang trí, tệ hơn nữa là nó dạy mọi người bỏ qua đúng cái bảng điều khiển mà một ngày kia sẽ hiện sự cố thật.

Đáp án

B — Nhập key material MỚI vào một CMK MỚI, rồi cập nhật alias trỏ sang CMK mới đó.

Vì sao đúng

Chi tiết quyết định nằm ở một cụm từ trong đề: CMK dùng IMPORTED KEY MATERIAL.

⚠ Điểm mấu chốt — khoá nhập từ ngoài KHÔNG xoay tự động được:

CMK do KMS TỰ SINH key material
        ↓
    → bật enable-key-rotation là xong
    → KMS tự tạo material mới mỗi năm, giữ material cũ
    → ARN và alias KHÔNG ĐỔI

CMK với IMPORTED key material
        ↓
    → KMS KHÔNG tự sinh được material mới
      (nó không có khoá gốc để sinh ra)
        ↓
    → KHÔNG bật automatic rotation được
    → phải xoay THỦ CÔNG

⚠ Và tại sao phải tạo CMK MỚI chứ không nhập đè lên CMK cũ:

Một CMK chỉ chứa ĐÚNG MỘT bộ imported key material
        ↓
    Nhập material mới đè lên material cũ
        ↓
    → MỌI DỮ LIỆU đã mã hoá bằng material cũ
      TRỞ THÀNH KHÔNG GIẢI MÃ ĐƯỢC
        ↓
    → đây chính là lý do phương án A sai và rất nguy hiểm

⚠ Quy trình xoay thủ công đúng cách:

1. Tạo CMK MỚI với origin = EXTERNAL
2. Tải wrapping key và import token của CMK mới
3. Bọc (wrap) key material mới rồi import vào CMK mới
4. Cập nhật ALIAS trỏ từ CMK cũ sang CMK mới
        ↓
    aws kms update-alias --alias-name alias/khoa-ung-dung \
      --target-key-id <cmk-moi>
        ↓
5. GIỮ CMK CŨ — để giải mã dữ liệu cũ
6. (tuỳ chọn) mã hoá lại dữ liệu cũ bằng CMK mới,
   rồi mới lên lịch xoá CMK cũ

⚠ Và đây chính là lý do dùng ALIAS ngay từ đầu:

Ứng dụng tham chiếu alias, không tham chiếu key id
        ↓
    Xoay khoá = đổi alias trỏ sang CMK khác
        ↓
    → KHÔNG phải sửa một dòng mã nào
    → KHÔNG phải triển khai lại ứng dụng

Xem thêm câu #11751: cùng chủ đề xoay khoá KMS nhưng ở đó khoá do KMS tự sinh, nên đáp án là bật automatic rotation. Hai câu bổ sung cho nhau: nguồn gốc key material quyết định cách xoay.

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

• A (xoá key material hiện tại rồi nhập material mới vào CHÍNH CMK đó) — đây là phương án gần nhất và cực kỳ nguy hiểm: xoá key material khiến CMK chuyển sang trạng thái PendingImport, và mọi dữ liệu mã hoá bằng material cũ trở thành không đọc được vĩnh viễn.

• C (bật automatic key rotation và đặt chu kỳ 6 tháng) — imported key material KHÔNG hỗ trợ automatic rotation. (Và trước năm 2024, chu kỳ cũng cố định là 365 ngày; nay chỉnh được nhưng vẫn chỉ cho khoá do KMS sinh.)

• D (dùng AWS managed CMK với xoay tự động 6 tháng, rồi cập nhật alias) — sai hai chỗ: AWS managed key xoay mỗi NĂM, không chỉnh được chu kỳ, và alias của nó cố định (aws/s3, aws/ebs) — bạn không trỏ alias riêng sang nó được.

Ghi nhớ

⚠ Xoay khoá theo từng loại khoá KMS — bảng phải thuộc: | Loại khoá | Xoay tự động | |---|---| | AWS managed key (aws/s3) | CÓ, mỗi năm — bắt buộc, không tắt được | | CMK do KMS sinh material | CÓ, phải BẬT thủ công | | CMK với IMPORTED material | KHÔNG — phải xoay thủ công | | CMK trong CloudHSM key store | không tự động | | External Key Store (XKS) | quản ở hệ thống bên ngoài |

Từ khoá nhận diện:

"xoay khoá nhập từ ngoài" → tạo CMK MỚI + đổi ALIAS "xoay khoá do KMS sinh" → enable-key-rotation "chu kỳ xoay tuỳ chỉnh" → chỉ với khoá do KMS sinh (90–2560 ngày) "nhập material mới đè lên CMK cũ" → MẤT DỮ LIỆU "xoay khoá không sửa mã ứng dụng" → dùng ALIAS

⚠ Hai kiểu "xoay khoá" — khác nhau về bản chất: | | Automatic rotation | Manual rotation | |---|---|---| | Cái gì đổi | key material BÊN TRONG cùng một CMK | CMK MỚI hoàn toàn | | ARN, key id | KHÔNG đổi | ĐỔI | | Alias | không đổi | phải cập nhật | | Dữ liệu cũ | giải mã được bằng material cũ | cần GIỮ CMK cũ | | Mã hoá lại dữ liệu | không cần | nên làm, rồi mới xoá CMK cũ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khoá thuộc loại nào | describe-key, xem Origin (AWS_KMS hay EXTERNAL) | | Xoay tự động có bật được không | get-key-rotation-status | | Alias đang trỏ vào đâu | list-aliases, xem TargetKeyId |

Và một lời nhắc quan trọng khi xoay khoá thủ công: ĐỪNG xoá CMK cũ ngay sau khi đổi alias. Mọi dữ liệu đã mã hoá trước đó vẫn tham chiếu tới key id của CMK cũ, và xoá nó là mất dữ liệu vĩnh viễn. Hãy giữ CMK cũ ở trạng thái Enabled (hoặc ít nhất là còn tồn tại) cho tới khi bạn đã mã hoá lại toàn bộ dữ liệu bằng khoá mới và xác nhận được điều đó bằng head-object.

Đáp án

B — Cấu hình inter-region VPC peering giữa hai VPC, rồi cấu hình route table.

Vì sao đúng

Đề nêu hai ràng buộc, và inter-region VPC peering thoả cả hai mà không cần thêm gì.

⚠ Điểm mấu chốt — lưu lượng peering chéo Region đi trên đường trục riêng của AWS:

Inter-region VPC peering
        ↓
    Lưu lượng đi trên MẠNG TRỤC TOÀN CẦU CỦA AWS
        ↓
    → KHÔNG BAO GIỜ đi qua internet công cộng   ← ràng buộc 2
    → AWS TỰ ĐỘNG MÃ HOÁ ở tầng vật lý           ← ràng buộc 1
        ↓
    → thoả cả hai yêu cầu mà không cần cấu hình gì thêm

Đây là điều AWS ghi rõ trong tài liệu: lưu lượng inter-region peering được mã hoá tự động và không đi qua internet, không qua điểm trao đổi lưu lượng công cộng.

⚠ Và peering còn có ưu thế về vận hành:

Không có thiết bị nào phải quản lý
        ↓
    → không có gateway, không có đường hầm, không có băng thông trần
    → không có điểm chết đơn
        ↓
    Chỉ trả tiền cho DỮ LIỆU TRUYỀN qua nó

⚠ Nhưng đừng quên ba ràng buộc kinh điển của peering:

KHÔNG bắc cầu (non-transitive)
        ↓
    A↔B và B↔C KHÔNG cho A↔C

CIDR KHÔNG được chồng lấn

Route table phải sửa ở CẢ HAI PHÍA
        ↓
    → đây là bước mà đề nhắc tới trong chính đáp án

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

• C (dựng AWS Managed VPN giữa hai VPC) — đây là phương án gần nhất và cũng cho mã hoá thật (IPsec). Nhưng nó chạy qua internet công cộng — trái thẳng ràng buộc "không được đi qua internet". Ngoài ra băng thông chỉ khoảng 1,25 Gbps mỗi đường hầm và phải quản lý thêm hạ tầng VPN.

• A (dựng Internet Gateway ở mỗi VPC và trỏ route table vào đó) — đưa lưu lượng thẳng ra internet công cộng, và không có mã hoá nào. Trái cả hai ràng buộc.

• D (dựng NAT Gateway ở cả hai VPC rồi cấu hình route table) — NAT Gateway để private subnet ra INTERNET, không phải để hai VPC nói chuyện với nhau. Lưu lượng vẫn ra internet công cộng.

Ghi nhớ

⚠ Các cách nối hai VPC chéo Region — bảng phải thuộc: | Cách | Qua internet | Mã hoá | Ghi chú | |---|---|---|---| | Inter-region VPC peering | KHÔNG | CÓ, tự động | đơn giản nhất, không bắc cầu | | Transit Gateway peering | KHÔNG | CÓ, tự động | bắc cầu được, cho nhiều VPC | | Site-to-Site VPN | CÓ | có (IPsec) | qua internet công cộng | | Direct Connect | không | KHÔNG | nối tại chỗ, không nối hai VPC | | PrivateLink | không | có | chỉ lộ MỘT dịch vụ, không nối cả mạng |

Từ khoá nhận diện:

"nối hai VPC chéo Region, không qua internet, có mã hoá" → inter-region VPC peering "nhiều VPC, cần bắc cầu" → Transit Gateway (+ TGW peering chéo Region) "CIDR chồng lấn" → peering KHÔNG được — dùng PrivateLink "chỉ cần lộ một dịch vụ" → PrivateLink "nối trung tâm dữ liệu tại chỗ" → VPN hoặc Direct Connect

⚠ Ba giới hạn của VPC Peering — nhắc lại: | Giới hạn | Nội dung | |---|---| | Không bắc cầu | A↔B, B↔C không cho A↔C | | CIDR không chồng lấn | kể cả một phần | | Không dùng chung gateway | không mượn NAT, IGW, VPC endpoint của nhau |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Peering đã active chưa | describe-vpc-peering-connections | | Route hai phía | describe-route-tables cho cả hai VPC | | Gói bị chặn ở đâu | VPC Flow Logs, tìm bản ghi REJECT |

Và một điểm rất đáng nhớ cho các câu hỏi về tuân thủ: mọi lưu lượng đi trên mạng trục toàn cầu của AWS đều được mã hoá tự động ở tầng vật lý — bao gồm inter-region VPC peering, Transit Gateway peering, và sao chép chéo Region của các dịch vụ có quản lý. Nghĩa là với những trường hợp này, bạn không cần dựng VPN chồng lên để thoả yêu cầu "mã hoá khi truyền", và việc dựng thêm chỉ tốn tiền và tốn công vô ích.

Đáp án

C — Chuyển cơ sở dữ liệu từ EC2 sang Amazon RDS for MySQL Multi-AZ; triển khai ứng dụng trên EC2 trong một Auto Scaling group trải nhiều Availability Zone; đặt load balancer phía trước.

Vì sao đúng

Hệ thống hiện tại có một điểm chết đơn ở cả hai tầng, và đáp án xử lý cả hai bằng dịch vụ có quản lý.

⚠ Điểm mấu chốt — tách hai tầng rồi làm mỗi tầng sẵn sàng cao theo cách riêng của nó:

Tầng CƠ SỞ DỮ LIỆU
        ↓
    RDS Multi-AZ
        ↓
    → sao chép ĐỒNG BỘ sang standby ở AZ khác
    → FAILOVER TỰ ĐỘNG trong 60–120 giây
    → KHÔNG mất giao dịch đã commit
    → endpoint không đổi, ứng dụng chỉ cần nối lại

Tầng ỨNG DỤNG
        ↓
    Auto Scaling group trải nhiều AZ + load balancer
        ↓
    → máy hỏng → ASG tự thay
    → mất một AZ → AZ còn lại vẫn phục vụ
    → co giãn theo tải luôn thể

⚠ Và vì sao đây là cách ÍT CÔNG SỨC nhất:

Mọi cơ chế sẵn sàng cao đều do AWS lo:
        RDS: failover, vá, sao lưu, sao chép
        ASG: phát hiện máy hỏng, thay máy, co giãn
        ALB: health check, phân phối tải
        ↓
    → không viết một dòng mã nào
    → không có Lambda tự chế nào phải bảo trì

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

• D (chuyển DB sang một EC2 khác, ứng dụng vào ASG nhiều AZ, tạo AMI của DB rồi khởi chạy một DB thứ hai ở AZ khác làm dự phòng) — đây là phương án gần nhất vì tầng ứng dụng làm đúng. Nhưng tầng cơ sở dữ liệu thì tự chế: AMI là ảnh chụp tại một thời điểm, máy dự phòng dựng từ nó sẽ thiếu toàn bộ dữ liệu phát sinh sau đó. Đây không phải sẵn sàng cao, mà là một bản sao lỗi thời.

• A (nhân bản DB sang EC2 ở AZ khác, dùng AWS Backup tạo AMI, viết Lambda health check mỗi phút để chuyển đổi) — tự dựng lại toàn bộ cơ chế failover: rất khó làm đúng (split-brain, mất dữ liệu, thời điểm chuyển đổi), và phải bảo trì mãi mãi.

• B (chuyển DB sang RDS Multi-AZ, rồi dùng Application Migration Service để tái cấu trúc ứng dụng thành Lambda, triển khai với tuỳ chọn Multi-AZ) — vế đầu đúng, hai vế sau sai: MGN dùng để DI CHUYỂN máy chủ lên AWS, không phải để "tái cấu trúc ứng dụng thành Lambda"; và Lambda không có tuỳ chọn Multi-AZ — nó vốn đã chạy trên nhiều AZ một cách tự động.

Ghi nhớ

⚠ Sẵn sàng cao theo từng tầng — bảng phải thuộc: | Tầng | Cách làm | |---|---| | DNS | Route 53 với health check + failover routing | | Load balancer | ALB/NLB trải nhiều AZ (bắt buộc ≥ 2 AZ) | | Ứng dụng | ASG nhiều AZ, không giữ trạng thái trên máy | | Cơ sở dữ liệu | RDS Multi-AZ, hoặc Aurora | | Phiên làm việc | ElastiCache hoặc DynamoDB | | Tệp dùng chung | EFS (nhiều AZ) hoặc S3 |

Từ khoá nhận diện:

"sẵn sàng cao cho cơ sở dữ liệu" → RDS Multi-AZ "sẵn sàng cao cho ứng dụng" → ASG nhiều AZ + load balancer "chia tải đọc" → Read Replica (khác Multi-AZ) "chịu được mất cả một Region" → cross-Region replica hoặc Aurora Global Database "tự viết Lambda để failover" → thường SAI khi đã có dịch vụ quản lý

⚠ Multi-AZ và Read Replica — nhắc lại chỗ hay nhầm nhất: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | sẵn sàng cao | chia tải đọc | | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | Phục vụ đọc | KHÔNG | CÓ | | Failover | tự động | promote thủ công | | Mất dữ liệu khi chuyển | KHÔNG | có thể |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Multi-AZ đã bật chưa | describe-db-instances, xem MultiAZ: true | | ASG có trải nhiều AZ không | describe-auto-scaling-groups, xem AvailabilityZones | | Failover mất bao lâu thật | reboot-db-instance --force-failover rồi bấm giờ |

Và một lời khuyên sau khi triển khai xong kiến trúc này: hãy chủ động kích hoạt một lần failover trong giờ bảo trì để đo thời gian phục hồi THẬT của ứng dụng. RDS hứa chuyển đổi trong một tới hai phút, nhưng đó chỉ là phía cơ sở dữ liệu — thời gian ứng dụng của bạn thật sự hồi phục còn phụ thuộc vào DNS cache, connection pool và logic thử lại, và cả ba thứ đó chỉ lộ ra khi bạn thử thật.

Đáp án

D — Tạo một Service Control Policy (SCP) trong tài khoản quản lý để từ chối mọi hành động của Redshift, rồi gắn SCP đó vào ROOT của tổ chức.

Vì sao đúng

Đề nêu một ràng buộc rất khó: chặn CẢ những người có quyền root của tài khoản thành viên. Chỉ SCP làm được điều đó.

⚠ Điểm mấu chốt — SCP là thứ duy nhất áp được lên root của tài khoản thành viên:

Chính sách IAM
        ↓
    → KHÔNG áp cho tài khoản root
        ↓
Permissions boundary
        ↓
    → cũng không áp cho root
        ↓
SCP (Service Control Policy)
        ↓
    → áp cho MỌI principal trong tài khoản THÀNH VIÊN,
      KỂ CẢ ROOT
        ↓
    → đây là câu trả lời duy nhất

⚠ SCP là TRẦN QUYỀN, không phải quyền cấp thêm:

SCP không cấp quyền cho ai cả
        ↓
    Nó chỉ giới hạn TỐI ĐA những gì có thể làm
        ↓
    Quyền hiệu lực = GIAO của (SCP) và (chính sách IAM)
        ↓
    → Deny trong SCP là tuyệt đối

SCP cần thiết:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ChanRedshift",
    "Effect": "Deny",
    "Action": "redshift:*",
    "Resource": "*"
  }]
}

⚠ Và vì sao gắn vào ROOT của tổ chức:

Gắn vào ROOT
        ↓
    → áp cho MỌI OU và MỌI tài khoản thành viên
    → tài khoản MỚI thêm vào cũng tự động bị áp
        ↓
    Nhưng nhớ: SCP KHÔNG áp cho
    root của TÀI KHOẢN QUẢN LÝ
        ↓
    → đây là lý do KHÔNG NÊN chạy workload
      ở tài khoản quản lý

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

• A (xoá SCP mặc định ở tài khoản quản lý, thay bằng một SCP chỉ có câu Deny cho Redshift) — đây là phương án gần nhất và hướng đi đúng, nhưng cách làm sai nghiêm trọng: SCP mặc định là FullAWSAccess (Allow tất cả). Xoá nó đi mà chỉ để lại một câu Deny nghĩa là không còn Allow nào — và vì SCP hoạt động như trần quyền, kết quả là chặn TOÀN BỘ mọi dịch vụ, không riêng Redshift. Trái thẳng yêu cầu "không ảnh hưởng các dịch vụ khác".

• C (tạo IAM policy ở từng tài khoản thành viên cấm truy cập Redshift cho mọi người, kể cả root) — IAM policy KHÔNG áp cho root. Và phải làm lặp lại ở từng tài khoản, tài khoản mới lại phải nhớ làm.

• B (dùng chính sách AmazonRedshiftFullAccess để từ chối truy cập) — tự mâu thuẫn: đó là managed policy CẤP QUYỀN đầy đủ cho Redshift, không phải để chặn.

Ghi nhớ

⚠ SCP áp cho ai — bảng phải thuộc: | Principal | SCP có áp không | |---|---| | IAM user và role ở tài khoản THÀNH VIÊN | CÓ | | Root của tài khoản THÀNH VIÊN | CÓ | | Root của tài khoản QUẢN LÝ | KHÔNG | | IAM user/role ở tài khoản quản lý | KHÔNG | | Service-linked role | KHÔNG |

Từ khoá nhận diện:

"chặn cả root của tài khoản thành viên" → SCP "trần quyền cho một user cụ thể" → permissions boundary "chặn hẳn không cho ai làm gì" → Deny trong SCP "SCP cấp quyền" → LUÔN SAI — SCP chỉ giới hạn "chạy workload ở tài khoản quản lý" → KHÔNG NÊN — SCP không áp được

⚠ Hai chiến lược viết SCP — hiểu rõ trước khi làm: | Chiến lược | Nội dung | |---|---| | Deny list (phổ biến) | giữ FullAWSAccess, thêm SCP có câu Deny cho thứ cần cấm | | Allow list | gỡ FullAWSAccess, chỉ Allow những dịch vụ được phép | | Rủi ro của Allow list | rất dễ chặn nhầm — quên một dịch vụ là hệ thống hỏng | | Khuyến nghị | dùng Deny list cho hầu hết trường hợp |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SCP đang gắn vào đâu | list-policies-for-target | | Trần quyền hiệu lực | describe-effective-policy ở cấp tài khoản | | Có chặn nhầm không | CloudTrail — tìm lỗi AccessDenied kèm lý do SCP |

Và một nguyên tắc quản trị rất đáng nhớ rút ra từ câu này: đừng bao giờ chạy workload ở tài khoản quản lý của Organizations. SCP — công cụ kiểm soát mạnh nhất mà bạn có — không áp được cho chính tài khoản đó, nghĩa là mọi rào chắn bạn dựng lên cho cả tổ chức đều có một ngoại lệ, và ngoại lệ ấy chính là tài khoản có nhiều quyền nhất.

Đáp án

A, E — hai cách xác định nguyên nhân:

• A — Dùng AWS Trusted Advisor để kiểm tra xem đã chạm hạn mức dịch vụ chưa.
• E — Dùng AWS CloudTrail để xem kết quả của các lời gọi RunInstances.

Vì sao đúng

Đề đã loại trừ nghi phạm phổ biến nhất: "MaxSize CHƯA bị chạm". Vậy nguyên nhân nằm ở chỗ khác.

⚠ Điều A — hạn mức dịch vụ là nghi phạm số một khi MaxSize vẫn còn chỗ:

ASG muốn khởi chạy thêm máy
        ↓
    Nhưng tài khoản đã chạm hạn mức vCPU của họ instance đó
        ↓
    → lời gọi RunInstances bị TỪ CHỐI
      với VcpuLimitExceeded
        ↓
    → ASG không thêm được máy nào
    → và KHÔNG có lỗi nào nổi lên ở đâu dễ thấy
        ↓
    Trusted Advisor có nhóm check "Service Limits"
        ↓
    → cảnh báo khi đã dùng tới ~80% hạn mức

⚠ Điều E — CloudTrail cho biết lời gọi thất bại vì lý do gì:

Mỗi lần ASG gọi RunInstances đều để lại bản ghi CloudTrail
        ↓
    Nếu thất bại, bản ghi chứa:
        errorCode     : VcpuLimitExceeded / InsufficientInstanceCapacity
        errorMessage  : mô tả chi tiết
        ↓
    → biết CHÍNH XÁC vì sao không khởi chạy được

⚠ Và cách nhanh nhất trong thực tế — nơi nên xem đầu tiên:

Activity history của Auto Scaling group
        ↓
    aws autoscaling describe-scaling-activities \
      --auto-scaling-group-name ten-asg
        ↓
    → đọc trường StatusMessage
    → nó nêu thẳng lý do thất bại

Xem thêm câu #11618: cùng triệu chứng ASG không scale out, nhưng ở đó đề không loại trừ MaxSize, nên đáp án là đã chạm MaxSize và tiến trình Launch bị tạm ngừng. Hai câu bổ sung cho nhau thành một danh sách chẩn đoán đầy đủ.

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

• C (xem AWS Personal Health Dashboard để tìm sự kiện sự cố) — đây là phương án gần nhất và đáng xem trong một số tình huống. Nhưng nếu AWS đang có sự cố ở AZ đó thì lỗi sẽ là InsufficientInstanceCapacity, và CloudTrail đã cho biết điều đó rồi. Personal Health Dashboard không giải thích được vấn đề hạn mức của tài khoản.

• B (theo dõi limits trong AWS Systems Manager) — Systems Manager không quản lý hạn mức dịch vụ. Dịch vụ đúng là Service Quotas (hoặc Trusted Advisor).

• D (dùng Amazon Inspector để xem thông tin hiệu năng) — Inspector quét lỗ hổng bảo mật, hoàn toàn không liên quan tới hiệu năng hay hạn mức.

Ghi nhớ

⚠ Bốn nguyên nhân ASG không scale out — kiểm tra theo thứ tự này: | Thứ tự | Kiểm tra | Dấu hiệu | |---|---|---| | 1 | MaxSize đã chạm trần chưa | DesiredCapacity == MaxSize | | 2 | SuspendedProcesses có gì không | tiến trình Launch bị tạm ngừng | | 3 | Hạn mức vCPU của tài khoản | VcpuLimitExceeded trong Activity history | | 4 | AWS hết dung lượng ở AZ đó | InsufficientInstanceCapacity | | Thêm | Subnet hết địa chỉ IP | AvailableIpAddressCount bằng 0 | | Thêm | Alarm chưa kích hoạt | chỉ số chưa vượt ngưỡng thật |

Từ khoá nhận diện:

"ASG không thêm máy, MaxSize còn chỗ" → hạn mức dịch vụ "ASG không thêm máy, không rõ vì sao" → Activity history trước tiên "sắp chạm hạn mức" → Trusted Advisor hoặc Service Quotas "AWS có sự cố không" → Personal Health Dashboard "máy mới lên rồi bị giết ngay" → health check grace period quá ngắn

⚠ Hạn mức hay chạm phải — bảng đáng thuộc: | Hạn mức | Nội dung | |---|---| | vCPU theo họ instance | tính bằng vCPU, KHÔNG phải số instance | | Elastic IP | mặc định 5 mỗi Region | | Địa chỉ IP trong subnet | trừ 5 địa chỉ AWS giữ | | Số ASG, launch template | có trần | | Xin tăng ở đâu | Service Quotas — một số tự động duyệt |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vì sao khởi chạy thất bại | describe-scaling-activities — đọc StatusMessage | | Hạn mức hiện tại | Service Quotas console | | Có tiến trình nào bị ngừng | describe-auto-scaling-groups, trường SuspendedProcesses |

Và một thói quen đáng xây dựng cho mọi Auto Scaling group quan trọng: đặt cảnh báo cho sự kiện EC2 Instance Launch Unsuccessful qua EventBridge. Thất bại khi khởi chạy là loại sự cố hoàn toàn im lặng — hệ thống vẫn "hoạt động" với số máy hiện có, không có lỗi nào ở đâu, chỉ là mỗi người dùng mới đến đều được phục vụ chậm hơn một chút, cho tới lúc mọi thứ đổ sập cùng lúc.

Đáp án

B — Bảo đảm rằng mọi EC2 instance đều được gắn instance profile có quyền truy cập Systems Manager.

Vì sao đúng

Chi tiết quyết định nằm ở cách đề diễn đạt: "không quản được TẤT CẢ instance trong CÙNG MỘT subnet".

⚠ Điểm mấu chốt — cùng subnet nghĩa là đường mạng đã ổn:

Một số instance trong subnet đó ĐÃ được quản lý
        ↓
    → đường mạng tới endpoint SSM hoạt động tốt
    → NAT Gateway hoặc VPC endpoint đều ổn
        ↓
    Vậy khác biệt nằm ở ĐÂU?
        ↓
    → ở CẤP INSTANCE, không phải cấp mạng
        ↓
    → thiếu IAM instance profile

⚠ Ba điều kiện để SSM quản lý được một máy — nhắc lại:

1. SSM Agent đã cài và đang chạy
        ↓
    Đề nói rõ: "phiên bản mới nhất, đang hoạt động" ✓

2. IAM instance profile với quyền SSM
        ↓
    → chính sách AmazonSSMManagedInstanceCore
    → ĐÂY là thứ còn thiếu

3. Đường mạng tới endpoint SSM
        ↓
    Cùng subnet với máy đã hoạt động ✓

⚠ Cách sửa — gắn instance profile mà KHÔNG cần dừng máy:

aws ec2 associate-iam-instance-profile \
  --instance-id i-xxxxxxxx \
  --iam-instance-profile Name=SSMInstanceProfile

    → gắn được khi máy đang chạy
    → agent nhận chứng chỉ mới trong vài phút
    → máy xuất hiện trong Fleet Manager

Xem thêm câu #11814: cùng bộ điều kiện này ở tình huống AMI tuỳ chỉnh — ở đó agent có thể chưa được cài, nên đáp án gồm cả hai vế. Và #11741, #11653: cùng bộ ba điều kiện, nhấn mạnh khả năng quản lý máy tại chỗ qua hybrid activation.

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

• A (cấu hình SSM dùng interface VPC endpoint cho VPC và subnet đó) — đây là phương án gần nhất và là một điều kiện THẬT của Systems Manager. Nhưng đề nói rõ vấn đề nằm ở một số máy trong CÙNG subnet — nếu thiếu VPC endpoint thì không máy nào trong subnet đó hoạt động được, chứ không phải chỉ một số.

• C (kiểm tra instance có tag phù hợp để SSM truy cập) — tag KHÔNG quyết định máy có được SSM quản lý hay không. Tag chỉ dùng để chọn máy khi chạy lệnh hoặc phân nhóm vá.

• D (dùng IAM Access Analyzer để phát hiện và tự sửa) — Access Analyzer tìm tài nguyên bị chia sẻ ra ngoài tài khoản và sinh chính sách từ lịch sử CloudTrail. Nó không tự sửa gì và không liên quan tới instance profile.

Ghi nhớ

⚠ Ba điều kiện để một EC2 thành managed instance — bảng phải thuộc: | Điều kiện | Chi tiết | |---|---| | SSM Agent | đã cài và đang chạy — có sẵn trên hầu hết AMI của AWS | | IAM instance profile | chính sách AmazonSSMManagedInstanceCore | | Đường mạng tới endpoint SSM | NAT Gateway hoặc 3 interface VPC endpoint |

Từ khoá nhận diện:

"MỘT SỐ máy trong cùng subnet không được quản" → thiếu instance profile "KHÔNG máy nào trong subnet được quản" → thiếu đường mạng / VPC endpoint "máy tại chỗ" → hybrid activation, id bắt đầu bằng mi- "tag để chọn máy chạy lệnh" → đúng, nhưng không quyết định máy có được quản lý hay không

⚠ Ba VPC endpoint cần cho SSM ở private subnet không có NAT:

com.amazonaws.<region>.ssm            → mặt phẳng điều khiển
com.amazonaws.<region>.ssmmessages    → Session Manager
com.amazonaws.<region>.ec2messages    → Run Command
        ↓
    Thiếu ssmmessages → Session Manager không vào được
    Thiếu ec2messages → Run Command không chạy
        ↓
    (thêm com.amazonaws.<region>.s3 gateway endpoint
     nếu cần Patch Manager tải bản vá — MIỄN PHÍ)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy nào đang được quản lý | describe-instance-information | | Instance profile hiện tại | describe-instances, xem IamInstanceProfile | | Vì sao agent không kết nối | đọc log của chính agent |

Và một tính năng mới rất đáng biết nếu bạn thường xuyên gặp vấn đề này: Default Host Management Configuration của Systems Manager. Bật nó lên ở cấp tài khoản và Region, SSM sẽ tự quản lý mọi EC2 instance trong đó mà không cần gắn instance profile cho từng máy — xoá sổ vĩnh viễn đúng loại sự cố mà câu hỏi này mô tả.