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

Đáp án

D — Nạp dữ liệu thời gian thực bằng Amazon Kinesis Data Stream. Dùng AWS Lambda ẩn danh hoá PII, rồi lưu vào Amazon DynamoDB.

Vì sao đúng

Đề nêu ba yêu cầu, và mấu chốt nằm ở thứ tự: | Yêu cầu | Cơ chế | |---|---| | Thu thập dữ liệu thời gian thực từ nhiều nguồn | Kinesis Data Streams | | Ẩn danh hoá PII TRƯỚC KHI vào CSDL NoSQL | Lambda xử lý giữa luồng | | Đích là NoSQL | DynamoDB |

Cụm "prior to landing in a NoSQL database" là điều kiện quyết định:

Đáp án D (đúng):
  Nguồn → Kinesis → Lambda ẩn danh hoá → DynamoDB
                     ^^^^^^^^^^^^^^^^^
                     PII bị loại BỎ TRƯỚC khi chạm CSDL
  → DynamoDB KHÔNG BAO GIỜ chứa PII

Phương án B (sai):
  Nguồn → DynamoDB (CÓ PII) → Streams → Lambda ẩn danh hoá
                ^^^^^^^^^^^
                PII ĐÃ NẰM TRONG CSDL rồi

Vì sao khác biệt đó quan trọng với dữ liệu y tế: ngay cả khi Lambda ghi đè bản ghi sau vài mili giây, PII đã tồn tại trong CSDL — nó nằm trong bản sao lưu, trong point-in-time recovery, trong log, và trong phạm vi kiểm toán tuân thủ. Với HIPAA hay quy định tương đương, đó là vi phạm.

Và Kinesis Data Streams là lựa chọn đúng cho "real-time từ nhiều nguồn": | Đặc điểm | Chi tiết | |---|---| | Độ trễ mili giây | thật sự thời gian thực | | Nhiều producer ghi vào cùng một stream | đúng "multiple sources" | | Giữ dữ liệu 1–365 ngày | phát lại được nếu xử lý lỗi | | Lambda là consumer tự nhiên | tích hợp sẵn, xử lý theo lô |

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

• B. Đưa dữ liệu vào bảng DynamoDB; bật DynamoDB Streams và cấu hình một hàm ẩn danh hoá các item mới ghi — đây là phương án gần nhất và cơ chế hoạt động, nhưng nó vi phạm yêu cầu cốt lõi: PII đã được ghi vào CSDL trước khi ẩn danh hoá. Đề nói rõ "prior to landing in a NoSQL database".
• A. Tạo data lake trên S3 làm nơi lưu chính cho dữ liệu bệnh nhân; dùng S3 trigger gọi Lambda ẩn danh hoá; gửi dữ liệu đã ẩn danh sang DynamoDB — cùng lỗi, ở một nơi khác: PII được lưu dạng rõ trên S3 trước khi xử lý. Và đề nói dữ liệu là luồng thời gian thực, không phải tệp đổ vào S3.
• C. Triển khai Amazon Data Firehose thu thập và biến đổi dữ liệu luồng; đưa dữ liệu đã ẩn danh vào Amazon Redshift để phân tích — sai đích: đề yêu cầu NoSQL database, còn Redshift là kho dữ liệu quan hệ (OLAP). (Firehose với biến đổi bằng Lambda là cơ chế hợp lệ — chỉ đích là sai.)

Ghi nhớ

Nguyên tắc thiết kế quan trọng nhất từ câu này:

Ẩn danh hoá dữ liệu nhạy cảm ở điểm SỚM NHẤT có thể trong đường ống. Mỗi hệ thống mà PII đi qua đều mở rộng phạm vi tuân thủ.

Vì sao "xử lý rồi ghi đè" không đủ: | Nơi PII còn sót lại | Chi tiết | |---|---| | Bản sao lưu và point-in-time recovery | giữ trạng thái trước khi ghi đè | | DynamoDB Streams | bản ghi cũ nằm trong stream 24 giờ | | CloudTrail data event | có thể ghi lại tham số request | | Log ứng dụng | nếu vô tình ghi ra |

Ba dịch vụ luồng của AWS — phân biệt: | Dịch vụ | Đặc điểm | |---|---| | Kinesis Data Streams | mili giây, phát lại được, nhiều consumer, tự quản shard | | Data Firehose | được quản lý hoàn toàn, gom lô ~60 giây, giao thẳng vào đích | | MSK (Kafka) | tương thích Kafka, tự quản nhiều hơn |

Chọn Streams khi cần độ trễ thấp và khả năng phát lại; chọn Firehose khi chỉ cần "đưa dữ liệu vào S3/Redshift/OpenSearch" mà không viết mã.

Ba kỹ thuật ẩn danh hoá — nên biết khác biệt: | Kỹ thuật | Cách làm | Đảo ngược | |---|---|---| | Che (masking) | 1234-5678-9012-3456 → ****-****-****-3456 | ❌ | | Băm (hashing) | băm một chiều, thường kèm salt | ❌ | | Tokenization | thay bằng token, ánh xạ lưu ở kho riêng | ✅ nếu có quyền | | Mã hoá | mã hoá trường nhạy cảm | ✅ nếu có khoá |

Tokenization đáng cân nhắc cho y tế: nó cho phép liên kết các bản ghi của cùng một bệnh nhân (cùng token) mà không lộ danh tính — điều mà băm ngẫu nhiên không làm được và che thì làm mất.

Ba lưu ý khi Lambda xử lý luồng Kinesis: | Lưu ý | Chi tiết | |---|---| | Xử lý theo lô | BatchSize quyết định số bản ghi mỗi lần gọi | | Xử lý lỗi cẩn thận | một bản ghi lỗi có thể chặn cả shard — dùng BisectBatchOnFunctionError và DLQ | | Song song theo shard | mở rộng bằng cách tăng số shard |

Dòng giữa là bẫy vận hành nghiêm trọng: mặc định Lambda thử lại cả lô cho tới khi thành công hoặc dữ liệu hết hạn — một bản ghi hỏng có thể làm nghẽn luồng nhiều giờ. Cấu hình MaximumRetryAttempts và OnFailure destination.

Và một dịch vụ đáng biết cho bài toán này: Amazon Comprehend Medical phát hiện và trích xuất PHI (thông tin y tế được bảo vệ) từ văn bản y khoa tự do — hữu ích khi PII không nằm ở các trường có cấu trúc mà lẫn trong ghi chú của bác sĩ, nơi mà quy tắc regex đơn giản sẽ bỏ sót.

Đáp án

A và E.

• A — Bật Versioning
• E — Bật MFA Delete

Vì sao đúng

Đề nêu hai mối nguy: xoá nhầm và ghi đè. Cặp Versioning + MFA Delete phủ cả hai với hai lớp khác nhau.

A — Versioning bảo vệ cả hai kịch bản:

XOÁ với versioning bật:
    S3 KHÔNG xoá object
    → tạo một "delete marker" đè lên trên
    → mọi phiên bản cũ VẪN CÒN
    → xoá delete marker là khôi phục được ngay

GHI ĐÈ với versioning bật:
    S3 KHÔNG thay thế object
    → tạo một PHIÊN BẢN MỚI
    → phiên bản cũ vẫn truy cập được bằng versionId

Đây là lý do Versioning là nền tảng: nó biến mọi thao tác phá huỷ thành thao tác cộng thêm, nên không có gì thực sự mất.

E — MFA Delete thêm rào cản cho thao tác nguy hiểm nhất: | Thao tác | Yêu cầu MFA | |---|---| | Xoá vĩnh viễn một PHIÊN BẢN cụ thể | ✅ | | TẮT versioning trên bucket | ✅ | | Xoá thông thường (tạo delete marker) | ❌ không cần |

Vế thứ hai quan trọng hơn vẻ ngoài: không có MFA Delete, ai đó tắt versioning rồi xoá — và mọi bảo vệ của A biến mất. MFA Delete khoá chính cái công tắc đó.

Và MFA Delete có một ràng buộc đặc biệt cần biết:

CHỈ ROOT USER của tài khoản bật/tắt được
Và PHẢI dùng CLI hoặc API — Console KHÔNG làm được

aws s3api put-bucket-versioning --bucket du-lieu-nguoi-dung   --versioning-configuration Status=Enabled,MFADelete=Enabled   --mfa "arn:aws:iam::111122223333:mfa/root-account-mfa-device 123456"

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

• **C. Cấm xoá trên S3 bằng IAM bucket policy — đây là phương án gần nhất và là lớp bảo vệ hợp lệ, nhưng nó quá cứng và có thể bị gỡ: cấm hoàn toàn s3:DeleteObject chặn cả việc dọn dẹp hợp lệ; và quản trị viên sửa được bucket policy để bỏ hạn chế đó. Versioning bảo vệ dữ liệu, không phụ thuộc vào việc ai còn quyền gì.
• **B. Chỉ cho truy cập dữ liệu S3 qua pre-signed URL — giải quyết vấn đề khác: pre-signed URL kiểm soát ai truy cập được và trong bao lâu. Nó không ngăn người có quyền xoá thực hiện việc xoá.
• **D. Bật S3 Intelligent-Tiering — tính năng tối ưu CHI PHÍ: nó tự chuyển object giữa các lớp lưu trữ theo mẫu truy cập. Không liên quan gì tới bảo vệ dữ liệu.

Ghi nhớ

Bốn lớp bảo vệ dữ liệu trên S3 — theo độ mạnh: | Lớp | Chống lại | |---|---| | Versioning | xoá nhầm và ghi đè — NỀN TẢNG | | MFA Delete | xoá phiên bản, tắt versioning | | Object Lock (COMPLIANCE) | xoá bởi BẤT KỲ AI, kể cả root | | Cross-Region Replication | mất mát do sự cố Region | | Bucket policy Deny | thao tác nhầm (nhưng gỡ được) |

Object Lock mạnh hơn MFA Delete (xem câu #8121... thực ra là #7766) — nhưng nó bất biến và tốn chi phí lưu trữ suốt thời hạn, nên MFA Delete phù hợp hơn cho bảo vệ chung.

Cách versioning xử lý các thao tác: | Thao tác | Kết quả | |---|---| | PutObject lên khoá đã có | tạo phiên bản mới, phiên bản cũ còn nguyên | | DeleteObject | tạo delete marker — KHÔNG xoá gì | | DeleteObject kèm versionId | XOÁ VĨNH VIỄN phiên bản đó ← cần MFA | | GetObject | trả phiên bản mới nhất | | GetObject kèm versionId | trả đúng phiên bản đó |

Khôi phục object bị xoá nhầm:

# Tìm delete marker
aws s3api list-object-versions --bucket du-lieu --prefix tep-quan-trong.pdf

# Xoá delete marker → object trở lại
aws s3api delete-object --bucket du-lieu --key tep-quan-trong.pdf   --version-id <id-cua-delete-marker>

Ba lưu ý về versioning: | Lưu ý | Chi tiết | |---|---| | Bật rồi chỉ TẠM DỪNG được, không tắt hẳn | trạng thái Suspended | | MỌI phiên bản đều tính phí lưu trữ | chi phí tăng theo số lần ghi đè | | Dùng lifecycle rule để dọn phiên bản cũ | bắt buộc cho bucket ghi nhiều |

Dòng thứ hai là bẫy chi phí thật: một tệp 1 GB được ghi đè hằng ngày trong một năm sẽ chiếm 365 GB. Lifecycle rule là bắt buộc, không phải tuỳ chọn:

{
  "Rules": [{
    "Status": "Enabled",
    "NoncurrentVersionExpiration": {"NoncurrentDays": 90},
    "NoncurrentVersionTransitions": [
      {"NoncurrentDays": 30, "StorageClass": "GLACIER_IR"}],
    "Expiration": {"ExpiredObjectDeleteMarker": true}
  }]
}

ExpiredObjectDeleteMarker dọn các delete marker mồ côi — chúng không tốn dung lượng nhưng làm chậm thao tác liệt kê khi tích tụ nhiều.

Ba hạn chế của MFA Delete cần biết trước khi bật: | Hạn chế | Chi tiết | |---|---| | Chỉ root user bật/tắt được | trái với thực hành "không dùng root" | | Không dùng được từ Console | chỉ CLI hoặc API | | Không hoạt động với lifecycle rule | lifecycle không xoá được phiên bản khi MFA Delete bật |

Dòng cuối là xung đột thực tế: bật MFA Delete nghĩa là mất khả năng tự động dọn dẹp bằng lifecycle, và chi phí lưu trữ sẽ tăng mãi. Với nhiều tổ chức, Object Lock chế độ GOVERNANCE là lựa chọn cân bằng hơn — nó ngăn xoá nhưng vẫn cho phép ngoại lệ có kiểm soát và tương thích với lifecycle.

Và một biện pháp đáng làm sau sự cố như đề mô tả: tách quyền xoá khỏi quyền ghi thông thường. Kỹ sư DevOps cần PutObject hằng ngày, nhưng DeleteObject nên thuộc về một role riêng cần assume có chủ đích — nó biến việc xoá thành một hành động có ý thức thay vì một cú nhấp nhầm.

Đáp án

D — Tạo một Amazon SNS topic và cấu hình hai SQS queue ĐĂNG KÝ (subscribe) vào topic đó. Cấp quyền cho S3 gửi thông báo tới SNS, và cập nhật bucket để dùng SNS topic mới.

Vì sao đúng

Đề nêu vấn đề rất rõ: hiện tại S3 gửi thông báo tới một SQS queue, và cần thông báo cho hai đội.

Nguyên nhân cần thay đổi kiến trúc: S3 event notification không gửi cùng một sự kiện tới nhiều đích cùng loại một cách gọn gàng.

Trước:  S3 → SQS (một queue, một đội)

Sau:    S3 → SNS topic (fan-out)
                ├→ SQS queue của đội phát triển
                └→ SQS queue của đội vận hành

Đây là mẫu "fan-out" kinh điển của SNS: | Đặc điểm | Chi tiết | |---|---| | Một thông điệp, nhiều người nhận | mỗi subscriber nhận một bản sao độc lập | | Thêm đội mới = thêm một subscription | không sửa cấu hình S3 | | Mỗi queue xử lý theo nhịp riêng | một đội chậm không ảnh hưởng đội kia |

Dòng cuối là lý do dùng SQS ở giữa thay vì để SNS gửi thẳng: SQS đệm thông điệp, nên nếu ứng dụng của một đội ngừng hoạt động, thông điệp vẫn nằm trong queue chờ — không mất.

Và cấu hình cần đúng hai lớp quyền:

// ① SNS topic policy — cho phép S3 publish
{
  "Effect": "Allow",
  "Principal": {"Service": "s3.amazonaws.com"},
  "Action": "SNS:Publish",
  "Resource": "arn:aws:sns:ap-northeast-1:111122223333:thong-bao-s3",
  "Condition": {"ArnLike": {"aws:SourceArn": "arn:aws:s3:::kho-du-lieu"}}
}

// ② SQS queue policy — cho phép SNS gửi vào queue
{
  "Effect": "Allow",
  "Principal": {"Service": "sns.amazonaws.com"},
  "Action": "SQS:SendMessage",
  "Resource": "arn:aws:sqs:...:queue-doi-phat-trien",
  "Condition": {"ArnEquals": {"aws:SourceArn": "arn:aws:sns:...:thong-bao-s3"}}
}

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

• C. Thiết lập SNS topic và cấu hình hai SQS queue POLL (thăm dò) SNS topic; cấp quyền cho S3 gửi thông báo tới SNS — đây là phương án gần nhất và mô tả sai cơ chế: SQS KHÔNG poll SNS. SNS là mô hình đẩy (push) — queue đăng ký vào topic và SNS đẩy thông điệp vào chúng. (Việc "poll" là do consumer thực hiện trên SQS, không phải SQS trên SNS.)
• A. Thiết lập thêm một SQS queue cho đội kia; cấp quyền cho S3 gửi thông báo tới queue thứ hai — hoạt động nhưng không mở rộng được: mỗi lần thêm một đội, bạn phải sửa cấu hình notification của bucket. Và S3 event notification có giới hạn về việc trùng lặp cấu hình cho cùng loại sự kiện và prefix.
• B. Tạo một SNS FIFO topic mới cho đội kia; cấp quyền cho S3 gửi thông báo tới topic thứ hai — hai vấn đề: vẫn là mô hình "mỗi đội một đích" không mở rộng được; và S3 event notification không hỗ trợ SNS FIFO topic. (FIFO topic đảm bảo thứ tự và chỉ gửi một lần, nhưng chỉ nhận từ một số nguồn nhất định.)

Ghi nhớ

Mẫu fan-out SNS + SQS — kiến trúc nên thuộc:

Nguồn sự kiện → SNS topic → nhiều SQS queue → nhiều consumer độc lập

SNS và SQS — phân biệt cốt lõi: | | SNS | SQS | |---|---|---| | Mô hình | push (đẩy) | poll (kéo) | | Số người nhận | nhiều — pub/sub | một consumer mỗi thông điệp | | Lưu giữ | không — gửi ngay hoặc thử lại rồi bỏ | 1–14 ngày | | Dùng khi | phát tán tới nhiều đích | đệm và xử lý bất đồng bộ |

Kết hợp cả hai lấy được ưu điểm của cả hai — đó chính là lý do mẫu fan-out phổ biến đến vậy.

Các đích của S3 event notification: | Đích | Ghi chú | |---|---| | SNS topic | fan-out tới nhiều nơi ← câu này | | SQS queue | đệm, một consumer | | Lambda function | xử lý ngay | | EventBridge | lọc theo mẫu phức tạp, nhiều target hơn |

EventBridge đáng cân nhắc như một lựa chọn thay thế hiện đại hơn:

{
  "source": ["aws.s3"],
  "detail-type": ["Object Created", "Object Deleted"],
  "detail": {"bucket": {"name": ["kho-du-lieu"]}}
}

Với đề này, EventBridge cũng giải quyết được và thậm chí gọn hơn — nhưng SNS fan-out là mẫu kinh điển và là đáp án trong các phương án đã cho.

Ba lưu ý về SNS subscription filter: | Lưu ý | Chi tiết | |---|---| | FilterPolicy lọc theo thuộc tính thông điệp | mỗi subscriber nhận đúng thứ cần | | RawMessageDelivery | bỏ lớp bọc JSON của SNS — consumer đọc trực tiếp payload gốc | | Redrive policy | DLQ cho subscription thất bại |

RawMessageDelivery đáng bật khi đích là SQS: không có nó, thông điệp S3 bị bọc trong một lớp JSON của SNS và consumer phải bóc hai lớp:

aws sns set-subscription-attributes --subscription-arn <arn>   --attribute-name RawMessageDelivery --attribute-value true

Và một lưu ý về thứ tự và trùng lặp: SNS standard topic có thể gửi trùng và không đảm bảo thứ tự. Với thông báo về object S3, điều đó thường chấp nhận được — nhưng consumer nên được viết theo hướng idempotent (xử lý cùng một thông điệp hai lần cho cùng kết quả), vì đó là giả định an toàn cho mọi hệ thống thông điệp phân tán.

Đáp án

B và C.

• B — Cấu hình một Amazon S3 Access Point cho bucket để giới hạn truy cập dữ liệu chỉ từ một VPC nhất định
• C — Tạo bucket S3 mới với S3 Object Lock bật, lưu tài liệu vào đó và đặt tuỳ chọn Legal Hold

Vì sao đúng

Đề nêu hai yêu cầu tách bạch, và mỗi đáp án giải quyết một cái: | Yêu cầu | Cơ chế | |---|---| | Chỉ cho phép truy cập từ một VPC cụ thể | B — VPC access point | | Không xoá, không ghi đè được (WORM) | C — Object Lock + Legal Hold |

B — VPC access point gắn cứng vào một VPC ngay lúc tạo:

aws s3control create-access-point --account-id 111122223333   --name diem-truy-cap-thue   --bucket kho-ho-so-thue   --vpc-configuration VpcId=vpc-0abc123

C — Object Lock thực thi mô hình WORM ở mức object:

aws s3api put-object-legal-hold --bucket kho-ho-so-thue   --key ho-so-2026.pdf --legal-hold Status=ON

Legal Hold khác retention period ở chỗ nó không có thời hạn: | Cơ chế | Đặc điểm | |---|---| | Retention period | khoá tới một ngày cụ thể | | Legal Hold | khoá VÔ THỜI HẠN cho tới khi gỡ tường minh |

Với hồ sơ thuế mật mà chưa biết thời hạn lưu trữ cụ thể, Legal Hold là lựa chọn phù hợp.

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

• E. Bật Object Lock nhưng TẮT Object Versioning trên bucket mới để đáp ứng mô hình WORM — đây là phương án gần nhất và mâu thuẫn nội tại: Object Lock BẮT BUỘC phải có versioning. AWS không cho bật Object Lock khi versioning tắt, và một khi Object Lock đang dùng thì không tắt versioning được nữa.
• D. Lưu tài liệu ở lớp S3 Glacier Instant Retrieval và dùng PutBucketPolicy áp bucket policy giới hạn theo VPC — giải quyết được vế VPC nhưng KHÔNG có WORM: lớp lưu trữ không liên quan gì tới việc chống xoá. Bucket policy cũng bị chính quản trị viên sửa được.
• A. Tạo bucket S3 và tích hợp với AWS Network Firewall; cấu hình Network Firewall chỉ chấp nhận request từ một VPC — sai kiến trúc: Network Firewall lọc lưu lượng trong VPC của bạn, nó không đứng trước S3 — S3 là dịch vụ khu vực nằm ngoài VPC.

Ghi nhớ

Ba cách giới hạn truy cập S3 theo VPC: | Cách | Đặc điểm | |---|---| | VPC access point | network origin cố định, có policy riêng ← câu này | | Bucket policy với aws:SourceVpce | linh hoạt, sửa được | | VPC endpoint policy | giới hạn những gì đi qua endpoint |

Kết hợp cả ba là chặt nhất, nhưng access point đủ cho yêu cầu của đề và ràng buộc mạnh nhất vì cấu hình VPC không đổi được.

Hai chế độ của Object Lock: | Chế độ | Ai gỡ được trước hạn | |---|---| | GOVERNANCE | người có s3:BypassGovernanceRetention | | COMPLIANCE | KHÔNG AI — kể cả root user, kể cả AWS |

Với yêu cầu quy định nghiêm ngặt, COMPLIANCE là chế độ đúng (xem câu #8157).

Ba điều kiện để dùng Object Lock:

① Versioning phải BẬT — và không tắt được sau đó
② Object Lock bật lúc TẠO bucket
   (bật cho bucket có sẵn cần qua AWS Support)
③ Đặt retention hoặc legal hold cho từng object, hoặc mặc định cho bucket

Cảnh báo về COMPLIANCE mode: đặt nhầm thời hạn 10 năm nghĩa là trả tiền lưu trữ suốt 10 năm — không xoá được, AWS cũng không gỡ hộ. Kiểm thử ở GOVERNANCE trước.

Ba ứng dụng thực tế của Object Lock: | Ứng dụng | Chi tiết | |---|---| | Tuân thủ quy định | SEC 17a-4, FINRA — lưu trữ bất biến ← câu này | | Bảo vệ log kiểm toán | CloudTrail log không bị xoá | | Chống ransomware | bản sao lưu không bị mã hoá hay xoá |

Và một lưu ý về chi phí: object bị khoá vẫn tính phí lưu trữ bình thường. Kết hợp với lifecycle rule chuyển sang lớp rẻ hơn (Glacier Instant Retrieval, Deep Archive) — Object Lock hoạt động ở mọi lớp, nên giữ được tính bất biến mà vẫn giảm chi phí cho dữ liệu ít truy cập.

Đáp án

B — Thiết lập SAML 2.0-Based Federation bằng Microsoft Active Directory Federation Service (AD FS).

Vì sao đúng

Đề nêu yêu cầu rõ: kiến trúc sư phải truy cập cả tại chỗ lẫn AWS bằng thông tin đăng nhập tại chỗ lưu trong Active Directory.

AD FS là cầu nối chuẩn giữa Active Directory và AWS:

Người dùng đăng nhập bằng tài khoản AD
    ↓ AD FS xác thực, phát hành SAML assertion
    ↓ trình duyệt gửi assertion tới AWS
AWS STS (AssumeRoleWithSAML)
    ↓ cấp thông tin đăng nhập TẠM THỜI
Truy cập AWS Console hoặc API

Ba lợi ích của mô hình này: | Lợi ích | Chi tiết | |---|---| | Không tạo IAM user cho từng người | quản lý người dùng ở một chỗ duy nhất — AD | | Thông tin đăng nhập TẠM THỜI | tự hết hạn, không có bí mật dài hạn | | Nhân viên nghỉ việc là mất quyền ngay | vô hiệu hoá tài khoản AD là xong |

Dòng cuối là giá trị vận hành lớn nhất: với IAM user riêng, bạn phải nhớ xoá thủ công ở AWS mỗi khi có người rời công ty — và đó là chỗ hay bị bỏ sót.

Ánh xạ nhóm AD sang IAM role qua claim trong SAML assertion:

https://aws.amazon.com/SAML/Attributes/Role
    → arn:aws:iam::111122223333:role/KienTrucSu,
      arn:aws:iam::111122223333:saml-provider/ADFS

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

• A. Thiết lập SAML 2.0-Based Federation bằng Web Identity Federation — đây là phương án gần nhất và nhầm hai cơ chế federation khác nhau: Web Identity Federation dùng cho nhà cung cấp danh tính mạng xã hội (Google, Facebook, Amazon, Apple) qua OIDC — không phải Active Directory. Và nó dùng AssumeRoleWithWebIdentity, không phải SAML.
• C. Dùng IAM user — trái yêu cầu: đề nói dùng thông tin đăng nhập tại chỗ trong AD. Tạo IAM user nghĩa là hai bộ thông tin đăng nhập riêng biệt phải quản lý song song.
• D. Dùng Amazon VPC — nhầm hoàn toàn phạm vi: VPC là mạng ảo, không liên quan gì tới xác thực danh tính.

Ghi nhớ

Ba loại federation trên AWS — bảng phân biệt: | Loại | Nguồn danh tính | API STS | |---|---|---| | SAML 2.0 federation | AD FS, Okta, Ping, Shibboleth | AssumeRoleWithSAML | | Web Identity Federation | Google, Facebook, Amazon, OIDC bất kỳ | AssumeRoleWithWebIdentity | | Custom identity broker | hệ thống tự viết | AssumeRole hoặc GetFederationToken |

Câu hỏi phân biệt:

"Active Directory doanh nghiệp" → SAML federation (AD FS) "Đăng nhập bằng Google/Facebook" → Web Identity Federation "Ứng dụng di động" → Cognito Identity Pool

Bốn cách kết nối Active Directory với AWS: | Cách | Đặc điểm | |---|---| | AD FS + SAML | truy cập AWS Console và API bằng tài khoản AD ← câu này | | AWS IAM Identity Center | cách hiện đại — SSO tập trung, nhiều tài khoản | | AD Connector | proxy tới AD tại chỗ, không lưu bản sao | | AWS Managed Microsoft AD | AD do AWS vận hành trên cloud |

IAM Identity Center (trước là AWS SSO) là lựa chọn được khuyến nghị hiện nay: nó tích hợp sẵn với AD, quản lý quyền cho nhiều tài khoản AWS ở một chỗ, và không cần tự dựng AD FS.

Ba thành phần cần thiết lập cho SAML federation: | Thành phần | Ở đâu | |---|---| | IAM Identity Provider (SAML) | tải metadata XML của AD FS lên IAM | | IAM Role với trust policy cho SAML provider | | | Claim rule trong AD FS | ánh xạ nhóm AD → IAM role ARN |

Trust policy của role:

{
  "Effect": "Allow",
  "Principal": {"Federated": "arn:aws:iam::111122223333:saml-provider/ADFS"},
  "Action": "sts:AssumeRoleWithSAML",
  "Condition": {"StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}}
}

Và một khả năng đáng biết cho phân quyền chi tiết: session tag từ SAML attribute. AD FS gửi thuộc tính (phòng ban, chức danh) thành session tag, và IAM policy dùng aws:PrincipalTag để cấp quyền theo đó — đây là cách ABAC được triển khai ở quy mô doanh nghiệp mà không phải tạo một role cho mỗi nhóm.

Đáp án

A và D.

• A — AWS Directory Service AD Connector
• D — IAM Roles

Vì sao đúng

Đề nêu ba điều kiện, và cặp A+D đáp ứng cả ba: | Điều kiện | Cơ chế | |---|---| | Dùng identity federation | AD Connector — chuyển tiếp xác thực về AD tại chỗ | | Kiểm soát truy cập theo vai trò (RBAC) | IAM Role | | Vai trò đã gán qua nhóm trong AD hiện có | AD Connector ánh xạ nhóm AD sang IAM role |

AD Connector là cầu nối, không phải thư mục:

Lập trình viên đăng nhập AWS Console
    ↓ qua URL của AD Connector
AD Connector CHUYỂN TIẾP yêu cầu xác thực
    ↓ về Active Directory TẠI CHỖ
AD xác thực và trả kết quả
    ↓ AD Connector ánh xạ nhóm AD → IAM role
    ↓ AssumeRole
Truy cập Console với quyền của role đó

Điểm cốt lõi: AD Connector KHÔNG lưu bản sao thư mục nào. | Đặc điểm | Chi tiết | |---|---| | Không sao chép dữ liệu thư mục | mọi truy vấn chuyển tiếp về AD tại chỗ | | Không lưu mật khẩu | quan trọng cho tuân thủ | | Người dùng vẫn ở AD | nghỉ việc là mất quyền ngay |

Và D là vế "role-based access control": IAM Role chứa quyền thật, còn nhóm AD quyết định ai được assume role nào:

Nhóm AD "Developers"      → IAM Role "role-lap-trinh-vien"
Nhóm AD "DBAs"            → IAM Role "role-quan-tri-csdl"

Người dùng liên kết (federated) KHÔNG dùng IAM Group được — chỉ IAM Role. Đó là lý do C sai.

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

• C. IAM Groups — đây là phương án gần nhất và là cơ chế nhóm quyền hợp lệ, nhưng nó chỉ áp cho IAM USER. Người dùng liên kết từ AD không phải IAM user — họ nhận quyền qua role được assume. Không gán được group cho một danh tính liên kết.
• **B. AWS Directory Service Simple AD — sai loại thư mục: Simple AD là một thư mục ĐỘC LẬP tương thích Samba do AWS vận hành. Nó không kết nối được với Active Directory hiện có của công ty — nghĩa là không dùng lại được các nhóm đã gán.
• **E. AWS Lambda — không liên quan: Lambda là dịch vụ tính toán không máy chủ, không phải công cụ quản lý danh tính.

Ghi nhớ

Ba lựa chọn của AWS Directory Service — bảng cần thuộc: | Dịch vụ | Là gì | Dùng khi | |---|---|---| | AD Connector | PROXY tới AD tại chỗ — không lưu gì | đã có AD, muốn dùng lại ← câu này | | AWS Managed Microsoft AD | AD THẬT do AWS vận hành | cần AD trên cloud, hoặc trust với AD tại chỗ | | Simple AD | thư mục độc lập tương thích Samba | nhu cầu đơn giản, KHÔNG nối AD hiện có |

Câu hỏi phân biệt:

"Đã có AD tại chỗ, muốn dùng lại" → AD Connector "Cần AD đầy đủ trên AWS, hoặc ứng dụng cần LDAP/Kerberos" → Managed Microsoft AD "Nhu cầu nhỏ, không có AD" → Simple AD

IAM Group và IAM Role — khác biệt quyết định: | | IAM Group | IAM Role | |---|---|---| | Áp cho | CHỈ IAM user | user, dịch vụ AWS, danh tính LIÊN KẾT | | Thông tin đăng nhập | dài hạn | tạm thời, tự hết hạn | | Federation dùng được | ❌ | ✅ |

Đây là lý do mọi kịch bản federation đều dùng role — không có ngoại lệ.

Ba cách cho người dùng AD truy cập AWS Console: | Cách | Đặc điểm | |---|---| | AD Connector | đơn giản, không lưu dữ liệu thư mục ← câu này | | AD FS + SAML | linh hoạt hơn, tự vận hành AD FS | | IAM Identity Center | hiện đại nhất — SSO cho NHIỀU tài khoản AWS |

IAM Identity Center là lựa chọn nên cân nhắc cho triển khai mới: nó dùng được AD Connector hoặc Managed AD làm nguồn danh tính, và quản lý quyền cho cả tổ chức qua permission set thay vì cấu hình role ở từng tài khoản.

Ba yêu cầu để AD Connector hoạt động:

① Kết nối mạng tới AD tại chỗ (Direct Connect hoặc VPN)
② Hai subnet ở hai AZ khác nhau
③ Tài khoản dịch vụ trong AD có quyền đọc và tham gia domain

Và một hạn chế cần biết: AD Connector không hỗ trợ trust relationship và không mở rộng lược đồ AD. Nếu ứng dụng của bạn cần những thứ đó (ví dụ Amazon RDS for SQL Server với xác thực Windows, hoặc FSx for Windows File Server), thì AWS Managed Microsoft AD mới là lựa chọn đúng.

Đáp án

A — RDS DB instance chạy ở cấu hình Multi-AZ deployment.

Vì sao đúng

Đề hỏi cơ chế nào của RDS thực hiện sao chép dữ liệu ĐỒNG BỘ (synchronous) — và đó là khác biệt căn bản giữa Multi-AZ và Read Replica.

Multi-AZ dùng sao chép đồng bộ:

Ứng dụng ghi dữ liệu
    ↓
Primary (AZ-a)  ──ĐỒNG BỘ──>  Standby (AZ-b)
    ↓                              ↓
    └─ CHỜ standby xác nhận ghi xong
    ↓
Trả về "ghi thành công" cho ứng dụng

Hệ quả của việc chờ xác nhận: KHÔNG MẤT DỮ LIỆU khi chuyển đổi dự phòng. | Đặc điểm | Chi tiết | |---|---| | RPO = 0 | standby luôn khớp chính xác với primary | | Chuyển đổi tự động | 60–120 giây, DNS endpoint không đổi | | Standby KHÔNG phục vụ đọc | nó chỉ chờ sẵn | | Đánh đổi | độ trễ ghi cao hơn một chút |

Dòng thứ ba là điểm hay bị hiểu nhầm: Multi-AZ là cơ chế SẴN SÀNG CAO, không phải cơ chế mở rộng hiệu năng. Bản standby không nhận truy vấn nào cho tới khi chuyển đổi xảy ra.

Và đề mô tả đúng nhu cầu này: ứng dụng ghi dữ liệu thời tiết mỗi phút, chạy trên Spot instance (có thể bị thu hồi bất cứ lúc nào) — nên cơ sở dữ liệu phải tự chịu được sự cố AZ mà không mất bản ghi nào.

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

• **B. RDS Read Replica — đây là phương án gần nhất và là cơ chế sao chép thật, nhưng nó dùng sao chép BẤT ĐỒNG BỘ (asynchronous): primary ghi xong là trả về ngay, không chờ replica. Nên replica luôn trễ một chút (replica lag), và chuyển đổi sang nó có thể mất dữ liệu.
• **C. Amazon DynamoDB Read Replica — không tồn tại khái niệm này: DynamoDB không có "read replica". Cơ chế đa Region của nó là Global Tables. Và đề nói về MySQL RDS, không phải DynamoDB.
• **D. Amazon CloudFront chạy ở Multi-AZ deployment — nhầm hoàn toàn: CloudFront là CDN, không phải cơ sở dữ liệu. Và nó vốn đã là dịch vụ biên toàn cầu — không có khái niệm "Multi-AZ" cho nó.

Ghi nhớ

Multi-AZ và Read Replica — bảng phân biệt quan trọng nhất về RDS: | | Multi-AZ | Read Replica | |---|---|---| | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Phục vụ truy vấn đọc | ❌ KHÔNG | ✅ CÓ | | Chuyển đổi | tự động | thủ công (promote) | | Mất dữ liệu khi chuyển | ❌ không (RPO = 0) | ✅ có thể | | Khác Region được | ❌ (trong một Region) | ✅ cross-Region |

Cả hai dùng chung được và thường nên dùng chung: Multi-AZ cho tính sẵn sàng, Read Replica cho mở rộng đọc.

Câu hỏi phân biệt:

"Tính sẵn sàng cao, chịu được sự cố AZ, không mất dữ liệu" → Multi-AZ "Giảm tải đọc cho primary" → Read Replica "Khôi phục thảm hoạ đa Region" → Cross-Region Read Replica hoặc Aurora Global Database

Hai chế độ Multi-AZ của RDS: | Chế độ | Đặc điểm | |---|---| | Multi-AZ instance deployment | một standby, KHÔNG phục vụ đọc | | Multi-AZ DB cluster | HAI replica CÓ phục vụ đọc, chuyển đổi nhanh hơn (dưới 35 giây) |

Chế độ thứ hai là bản mới hơn (cho MySQL và PostgreSQL) — nó khắc phục đúng nhược điểm "standby nằm không" của chế độ cũ.

Bốn sự kiện kích hoạt chuyển đổi tự động: | Sự kiện | |---| | Mất khả dụng cả một AZ | | Hỏng primary instance | | Hỏng ổ đĩa của primary | | Vá lỗi hệ điều hành hoặc thay đổi loại instance |

Dòng cuối đáng nhớ: Multi-AZ khiến việc bảo trì gần như không gián đoạn — AWS vá standby trước, chuyển đổi, rồi vá bản còn lại.

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Chi phí gần gấp đôi | trả tiền cho cả standby | | Độ trễ ghi tăng nhẹ | phải chờ xác nhận từ AZ khác | | Không thay thế cho sao lưu | xoá nhầm dữ liệu thì standby cũng xoá theo |

Dòng cuối quan trọng: Multi-AZ chống sự cố hạ tầng, không chống lỗi con người. Cho vế đó cần automated backup và point-in-time recovery.

Và với Aurora thì mô hình khác hẳn: dữ liệu được sao chép sáu bản trên ba AZ ở tầng lưu trữ, nên tính sẵn sàng là mặc định — và các "replica" của Aurora vừa phục vụ đọc vừa làm bản dự phòng chuyển đổi.

Đáp án

C — Tạo API bằng Amazon API Gateway và dùng AWS Lambda để xử lý các đợt tăng tải đột ngột trong vài giây.

Vì sao đúng

Đề mô tả một mẫu tải rất đặc trưng: hoạt động thấp phần lớn thời gian, nhưng bùng nổ TRONG VÀI GIÂY khi có thông báo sản phẩm mới.

Cụm "bursts of traffic within seconds" loại bỏ mọi lựa chọn dựa trên máy chủ: | Giải pháp | Thời gian mở rộng | |---|---| | Lambda | gần như tức thì — hàng nghìn lời gọi đồng thời trong vài giây | | ECS/Fargate | 1–2 phút để khởi chạy task mới | | EC2 Auto Scaling | 2–5 phút (khởi chạy + boot + health check) | | Elastic Beanstalk | tương tự EC2 |

Lambda mở rộng theo cơ chế hoàn toàn khác:

Không có "máy chủ" nào phải khởi động
    → mỗi request được cấp một execution environment
    → AWS quản lý nhóm môi trường sẵn sàng
    → tăng từ 0 lên hàng nghìn đồng thời trong vài giây

Và mô hình chi phí khớp hoàn hảo với mẫu tải của đề:

Tải thấp phần lớn thời gian:
    Lambda      → trả tiền theo số lời gọi và thời gian chạy → gần như 0
    EC2/ECS     → trả tiền cho máy chạy 24/7 dù không ai dùng

Vế "người dùng khắp toàn cầu" cũng được API Gateway đáp ứng: dùng edge-optimized endpoint, request đi qua mạng biên của CloudFront tới điểm gần người dùng nhất trước khi về Region.

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

• A. API Gateway + Amazon ECS cluster với Service Auto Scaling — đây là phương án gần nhất và mở rộng được, nhưng không đủ nhanh: khởi chạy task mới mất 1–2 phút. Với đợt bùng nổ "trong vài giây", người dùng đã gặp lỗi trước khi task mới sẵn sàng. Và cụm phải chạy liên tục dù tải thấp.
• D. API Gateway + Auto Scaling group của EC2 — chậm nhất trong các lựa chọn: khởi chạy instance, boot hệ điều hành, khởi động ứng dụng, qua health check — thường 2–5 phút.
• B. API Gateway + Elastic Beanstalk với Auto Scaling — Elastic Beanstalk chạy trên EC2 phía dưới, nên nó thừa hưởng đúng độ trễ mở rộng đó.

Ghi nhớ

Thời gian mở rộng của các dịch vụ tính toán — bảng cần thuộc: | Dịch vụ | Thời gian sẵn sàng | |---|---| | Lambda | mili giây tới vài giây | | Fargate | ~1 phút | | ECS trên EC2 | 1–2 phút (nếu còn chỗ trong cụm) | | EC2 Auto Scaling | 2–5 phút |

Từ khoá trong đề thi:

"within seconds", "unpredictable", "spiky", "intermittent" → Lambda "steady traffic", "long-running", "cost-optimize at scale" → EC2 hoặc Fargate

Ba giới hạn của Lambda cần cân nhắc: | Giới hạn | Giá trị | |---|---| | Thời gian chạy tối đa | 15 phút | | Bộ nhớ | 128 MB – 10.240 MB | | Kích thước payload | 6 MB (đồng bộ), 256 KB (bất đồng bộ) | | Concurrency mặc định | 1.000 mỗi Region (tăng được) |

Concurrency là con số đáng chú ý cho tình huống của đề: 1.000 lời gọi đồng thời là mặc định, và với đợt bùng nổ lớn bạn nên yêu cầu tăng hạn mức trước thay vì gặp lỗi throttling đúng lúc cao điểm.

Hai cơ chế giảm độ trễ khởi động nguội (cold start): | Cơ chế | Đặc điểm | |---|---| | Provisioned Concurrency | giữ sẵn N môi trường đã khởi tạo — KHÔNG có cold start | | SnapStart (Java) | khôi phục từ ảnh chụp, giảm mạnh thời gian khởi động |

Provisioned Concurrency đáng dùng cho tình huống biết trước thời điểm bùng nổ — như thông báo sản phẩm trong đề: đặt lịch tăng trước giờ công bố.

Ba cách kết nối Lambda với RDS — vấn đề thực tế của kiến trúc này: | Cách | Đặc điểm | |---|---| | RDS Proxy | gộp kết nối — BẮT BUỘC khi Lambda mở rộng mạnh | | Kết nối trực tiếp | hàng nghìn Lambda đồng thời sẽ làm cạn kết nối của RDS | | Aurora Serverless Data API | gọi qua HTTP, không cần quản lý kết nối |

Dòng đầu là mảnh ghép quan trọng mà đề không nhắc tới: RDS có giới hạn số kết nối đồng thời, và Lambda mở rộng lên hàng nghìn sẽ vượt qua nó ngay lập tức. RDS Proxy gộp và tái sử dụng kết nối, biến hàng nghìn Lambda thành vài chục kết nối thật tới cơ sở dữ liệu.

Và một tối ưu cho API Gateway: bật caching cho các endpoint đọc dữ liệu ít thay đổi. Với đợt bùng nổ do một thông báo sản phẩm, phần lớn người dùng hỏi cùng một thứ — cache ở tầng API Gateway cắt được phần lớn tải xuống Lambda và cơ sở dữ liệu.

Đáp án

C — Bật Enhanced Monitoring trong RDS.

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: giám sát từng tiến trình hoặc luồng trên DB instance sử dụng CPU thế nào, gồm phần trăm băng thông CPU và tổng bộ nhớ mà MỖI tiến trình tiêu thụ.

Cụm "each process" là điểm quyết định — và đó chính là ranh giới giữa CloudWatch và Enhanced Monitoring:

CloudWatch thường:
    Lấy metric từ HYPERVISOR
    → thấy: CPU tổng của instance là 80%
    → KHÔNG thấy: tiến trình nào đang chiếm CPU đó

Enhanced Monitoring:
    AGENT chạy TRÊN chính DB instance
    → thấy từng tiến trình, từng luồng
    → thấy bộ nhớ, hệ thống tệp, thiết bị đĩa

Enhanced Monitoring cung cấp những gì CloudWatch không có: | Metric | Chi tiết | |---|---| | processList | danh sách tiến trình kèm CPU và bộ nhớ của từng cái | | memory | free, cached, buffers, active, inactive | | fileSys | dung lượng đã dùng và inode của từng hệ thống tệp | | diskIO | I/O chi tiết theo thiết bị | | loadAverage | tải trung bình 1, 5, 15 phút |

Và tần suất lấy mẫu cao hơn hẳn:

CloudWatch thường:     60 giây
Enhanced Monitoring:   1, 5, 10, 15, 30 hoặc 60 giây

Chu kỳ 1 giây rất hữu ích để bắt các đợt tăng đột biến ngắn mà CloudWatch bỏ sót hoàn toàn.

aws rds modify-db-instance --db-instance-identifier csdl-giao-dich   --monitoring-interval 5   --monitoring-role-arn arn:aws:iam::111122223333:role/rds-monitoring-role   --apply-immediately

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

• A. Dùng Amazon CloudWatch giám sát CPU Utilization của cơ sở dữ liệu — đây là phương án gần nhất và là metric có sẵn hữu ích, nhưng nó chỉ cho CPU TỔNG ở mức instance. Nó không trả lời được câu hỏi "tiến trình nào đang chiếm CPU" mà đề đặt ra.
• B. Viết script tự thu thập và publish custom metric lên CloudWatch để theo dõi CPU thời gian thực của RDS — không thực hiện được: RDS là dịch vụ được quản lý, bạn không có quyền SSH vào máy chủ cơ sở dữ liệu để chạy script. Enhanced Monitoring tồn tại chính vì lý do đó.
• D. Kiểm tra metric CPU% và MEM% có sẵn trong Console Amazon RDS hiển thị phần trăm băng thông CPU và bộ nhớ mà mỗi tiến trình tiêu thụ — mô tả đúng dữ liệu nhưng bỏ qua điều kiện: các cột đó chỉ xuất hiện sau khi BẬT Enhanced Monitoring. Chúng không "có sẵn" mặc định.

Ghi nhớ

Quy tắc phân biệt — áp cho cả EC2 lẫn RDS:

Hypervisor nhìn thấy được → CloudWatch có sẵn Chỉ hệ điều hành bên trong biết → cần agent

Ba công cụ giám sát RDS — vai trò khác nhau: | Công cụ | Trả lời | |---|---| | CloudWatch metric | "Instance có đang quá tải không?" | | Enhanced Monitoring | "TIẾN TRÌNH nào đang chiếm tài nguyên?" | | Performance Insights | "TRUY VẤN SQL nào đang gây tải?" |

Ba câu hỏi khác nhau, và thường cần cả ba khi chẩn đoán:

CloudWatch          → phát hiện có vấn đề
Enhanced Monitoring → khoanh vùng ở tầng hệ điều hành
Performance Insights→ tìm ra truy vấn thủ phạm

Performance Insights đáng nhắc riêng cho tình huống của đề: đề nói ứng dụng "heavily using the RDS instance to process complex read and write operations". Performance Insights hiển thị DB load theo từng câu SQL, từng người dùng, từng loại chờ đợi — nó thường là công cụ đưa ra câu trả lời cuối cùng, trong khi Enhanced Monitoring cho biết tài nguyên hệ điều hành bị tiêu thụ ở đâu.

Ba lưu ý về Enhanced Monitoring: | Lưu ý | Chi tiết | |---|---| | Cần IAM role riêng | AmazonRDSEnhancedMonitoringRole | | Metric đi vào CloudWatch LOGS, không phải CloudWatch Metrics | log group RDSOSMetrics | | Chu kỳ càng ngắn, chi phí càng cao | 1 giây tạo rất nhiều dữ liệu |

Dòng giữa hay gây bối rối: dữ liệu Enhanced Monitoring nằm dưới dạng bản ghi JSON trong CloudWatch Logs, nên bạn xem nó trong Console RDS hoặc truy vấn bằng Logs Insights — không tìm thấy trong danh sách metric thông thường.

Và một lưu ý về chi phí: bật chu kỳ 1 giây trên nhiều instance tạo ra khối lượng log đáng kể. Với giám sát thường xuyên, 5 hoặc 10 giây là mức cân bằng tốt; chỉ hạ xuống 1 giây khi đang chủ động chẩn đoán một sự cố cụ thể.

Đáp án

A — Security Group Inbound Rule: Protocol TCP, Port Range 22, Source 110.238.98.71/32.

Vì sao đúng

Đề yêu cầu: EC2 instance chỉ truy cập được từ một địa chỉ IP qua kết nối SSH. Ba yếu tố phải đúng cùng lúc.

① Chiều INBOUND — vì kết nối đi VÀO instance:

Người quản trị (110.238.98.71)  ──SSH──>  EC2 instance
                                            ^
                                    kết nối ĐẾN instance
                                    → rule INBOUND

Security group có trạng thái, nên phản hồi tự động được phép đi ra — không cần rule outbound nào.

② Giao thức TCP — vì SSH chạy trên TCP: | Giao thức | Dùng cho | |---|---| | TCP | SSH, HTTP, HTTPS, RDP, hầu hết cơ sở dữ liệu | | UDP | DNS, NTP, một số giao thức streaming | | ICMP | ping, traceroute |

③ /32 — vì cần đúng MỘT địa chỉ:

110.238.98.71/32   → CHÍNH XÁC một địa chỉ IP     ✓
110.238.98.71/24   → cả dải 110.238.98.0–255      ✗ quá rộng
0.0.0.0/0          → toàn bộ Internet             ✗ nguy hiểm

Ký hiệu CIDR: số sau dấu / là số bit MẠNG bị cố định. /32 cố định cả 32 bit của IPv4, nên chỉ còn đúng một địa chỉ.

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

• B. Inbound Rule: Protocol UDP, Port 22, Source 110.238.98.71/32 — đây là phương án gần nhất và chỉ sai giao thức: SSH dùng TCP, không phải UDP. Rule này sẽ không cho phép kết nối SSH nào cả.
• C. Outbound Rule: Protocol TCP, Port 22, Destination 110.238.98.71/32 — sai chiều: rule này cho phép instance kết nối RA tới địa chỉ đó trên cổng 22 — ngược với điều đề cần.
• D. Outbound Rule: Protocol UDP, Port 22, Destination 0.0.0.0/0 — sai cả ba: sai chiều, sai giao thức, và sai nguồn (mở ra toàn bộ Internet).

Ghi nhớ

Các cổng cần thuộc lòng: | Cổng | Dịch vụ | Giao thức | |---|---|---| | 22 | SSH (Linux) | TCP | | 3389 | RDP (Windows) | TCP | | 80 / 443 | HTTP / HTTPS | TCP | | 3306 | MySQL, MariaDB, Aurora MySQL | TCP | | 5432 | PostgreSQL | TCP | | 1433 | SQL Server | TCP | | 1521 | Oracle | TCP | | 5439 | Redshift | TCP | | 6379 | Redis | TCP | | 2049 | NFS (EFS) | TCP | | 445 | SMB (FSx for Windows) | TCP | | 53 | DNS | UDP và TCP |

Ký hiệu CIDR thường gặp: | Ký hiệu | Số địa chỉ | |---|---| | /32 | 1 — đúng một địa chỉ | | /24 | 256 | | /16 | 65.536 | | /0 | toàn bộ Internet |

Bốn đặc điểm của security group: | Đặc điểm | Hệ quả | |---|---| | Có trạng thái (stateful) | chỉ cần rule một chiều | | CHỈ có rule Allow | muốn chặn một IP cụ thể phải dùng NACL | | Mặc định: chặn inbound, cho phép mọi outbound | | | Nguồn nhận: IP, CIDR, security group ID, prefix list | không nhận IGW ID |

Và giải pháp tốt hơn hẳn cho tình huống của đề: đừng mở cổng 22 chút nào. | Cách | Ưu điểm | |---|---| | AWS Systems Manager Session Manager | KHÔNG cần cổng inbound, KHÔNG cần SSH key, ghi log toàn bộ phiên | | EC2 Instance Connect Endpoint | không cần cổng inbound, vẫn dùng giao thức SSH | | Bastion host | cách truyền thống, vẫn phải mở 22 ở bastion |

Session Manager loại bỏ toàn bộ nhóm rủi ro này: instance khởi tạo kết nối ra ngoài tới dịch vụ SSM, nên security group không cần rule inbound nào. Cộng thêm kiểm soát bằng IAM và ghi lại mọi lệnh gõ trong phiên.

Và nếu vẫn phải mở cổng 22: địa chỉ IP tĩnh của văn phòng là điều kiện tiên quyết. Với người làm việc từ xa có IP động, ràng buộc theo IP sẽ thành gánh nặng bảo trì liên tục — khi đó Session Manager hoặc VPN có IP cố định là lựa chọn bền hơn.