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

Đáp án

D — Khởi chạy AWS Transit Gateway và thêm VPC attachment để kết nối các bộ phận; thiết lập AWS Network Firewall để bảo vệ lưu lượng ứng dụng giữa các VPC.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi thành phần giải một yêu cầu: | Yêu cầu | Giải pháp | |---|---| | Hai VPC ở hai Region truy cập lẫn nhau | Transit Gateway với inter-region peering | | Hệ thống ngăn xâm nhập (IPS) kiểm tra và chặn khai thác lỗ hổng | AWS Network Firewall |

Transit Gateway kết nối được cả hai chiều:

Region A: TGW ◀──peering──▶ Region B: TGW
    │                            │
VPC Nhân sự                 VPC Tài chính
    → cả hai bên truy cập được nhau
    → lưu lượng đi trên mạng xương sống AWS, được mã hoá

Và AWS Network Firewall là dịch vụ IPS của AWS:

Network Firewall cung cấp:
    ✓ kiểm tra sâu gói tin (deep packet inspection)
    ✓ chữ ký kiểu Suricata — phát hiện và CHẶN khai thác lỗ hổng
    ✓ lọc theo tên miền
    ✓ kiểm tra TLS

Vế "block any vulnerability exploits" chính là chức năng IPS — và chỉ Network Firewall trong bốn phương án làm được.

Rule group với chữ ký Suricata:

alert tcp any any -> $HOME_NET 445 (msg:"Khai thac SMB";
  flow:to_server,established; content:"|FF|SMB"; sid:1000001;)

Và AWS cung cấp bộ rule được quản lý sẵn: | Bộ rule | Chống | |---|---| | MalwareDomainsActionOrder | tên miền phát tán mã độc | | BotNetCommandAndControlDomainsActionOrder | máy chủ điều khiển botnet | | AbusedLegitDomainsActionOrder | tên miền hợp pháp bị lạm dụng |

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

• **C. Tạo Direct Connect Gateway và thêm VPC attachment; dùng Security Hub để bảo vệ lưu lượng — đây là phương án gần nhất vì cũng nói tới kết nối và bảo mật, nhưng nó sai ở hai chỗ: Direct Connect Gateway dùng để nối VPC với MẠNG TẠI CHỖ qua kết nối DX, không phải để nối hai VPC với nhau. Và Security Hub TỔNG HỢP finding từ các dịch vụ bảo mật — nó không kiểm tra hay chặn lưu lượng nào.
• **A. Tạo Traffic Policy trong Route 53 để nối hai VPC; dùng Route 53 Resolver DNS Firewall — sai cả hai: Route 53 traffic policy là công cụ định tuyến DNS, nó không tạo kết nối mạng. Và DNS Firewall chỉ lọc truy vấn DNS theo tên miền — nó không kiểm tra nội dung lưu lượng hay chặn khai thác lỗ hổng.
• **B. Kết nối hai VPC bằng NAT Gateway; quản lý phiên qua Session Manager — sai chức năng: NAT Gateway cho instance ra Internet, nó không nối hai VPC. Và Session Manager là công cụ truy cập quản trị, không phải cơ chế bảo vệ lưu lượng.

Ghi nhớ

Ba cách kết nối các VPC — bảng cần thuộc: | Cách | Bắc cầu | Xuyên Region | Chèn kiểm tra lưu lượng | |---|---|---|---| | VPC Peering | ❌ | ✅ | khó | | Transit Gateway | ✅ | ✅ (qua TGW peering) | ✅ dễ — định tuyến qua firewall | | PrivateLink | — | ✅ | — |

Transit Gateway thắng ở chỗ nó là điểm tập trung — mọi lưu lượng đi qua nó, nên chèn firewall vào đường đi rất tự nhiên.

Kiến trúc kiểm tra lưu lượng tập trung:

VPC Nhân sự ──▶ TGW ──▶ VPC KIỂM TRA (Network Firewall) ──▶ TGW ──▶ VPC Tài chính

Mô hình này gọi là "inspection VPC" — một VPC riêng chứa firewall, mọi lưu lượng giữa các VPC đi vòng qua đó.

Các lớp kiểm soát mạng — chọn đúng công cụ: | Lớp | Khả năng | Chặn khai thác lỗ hổng | |---|---|---| | Security group | stateful, chỉ Allow, theo IP và cổng | ❌ | | Network ACL | stateless, có Deny, theo CIDR | ❌ | | AWS Network Firewall | kiểm tra sâu gói tin, IPS, theo tên miền | ✅ | | AWS WAF | tầng 7, chỉ HTTP/HTTPS | ✅ (cho web) | | Route 53 DNS Firewall | chỉ truy vấn DNS | ❌ |

Từ khoá nhận diện trong đề thi:

"IPS", "intrusion prevention", "deep packet inspection", "block exploits" → AWS Network Firewall "web application attacks", "SQL injection", "HTTP" → AWS WAF "block malicious domain queries" → Route 53 DNS Firewall

Hai loại rule group của Network Firewall: | Loại | Lọc theo | |---|---| | Stateless | IP, cổng, giao thức — nhanh, từng gói tin | | Stateful | theo LUỒNG: tên miền, chữ ký Suricata, giao thức ứng dụng |

Chữ ký Suricata là thứ cho khả năng IPS thật sự — nó nhận diện mẫu tấn công đã biết trong nội dung gói tin.

Ba khả năng chính của Network Firewall: | Khả năng | Chi tiết | |---|---| | Ngăn xâm nhập (IPS) | chặn khai thác lỗ hổng theo chữ ký ← câu này | | Lọc tên miền cho lưu lượng RA | danh sách cho phép hoặc cấm | | Kiểm tra TLS | giải mã và kiểm tra nội dung mã hoá |

Lọc lưu lượng ra là giá trị lớn trong thực tế:

Máy chủ bị xâm nhập
    → cố gửi dữ liệu ra máy chủ điều khiển
    → Network Firewall chặn vì tên miền không nằm trong danh sách
    → ngăn được bước rò rỉ dữ liệu

Bốn loại attachment của Transit Gateway: | Loại | Nối tới | |---|---| | VPC | VPC trong cùng Region | | VPN | kết nối site-to-site | | Direct Connect Gateway | kết nối DX tới mạng tại chỗ | | TGW Peering | TGW ở Region KHÁC ← cần cho đề này |

Và TGW peering có một hạn chế cần biết:

KHÔNG bắc cầu qua peering
    → TGW-A peering TGW-B, TGW-B peering TGW-C
    → A KHÔNG tới được C
    → và route phải khai TĨNH, không tự lan truyền

Ba lựa chọn kiểm tra lưu lượng — theo mức phức tạp: | Lựa chọn | Đặc điểm | |---|---| | AWS Network Firewall | được quản lý, ít công vận hành ← câu này | | Gateway Load Balancer + thiết bị bên thứ ba | Palo Alto, Fortinet, Check Point | | Thiết bị ảo tự quản lý trên EC2 | kiểm soát cao nhất, công lớn nhất |

Gateway Load Balancer đáng biết: nó chèn thiết bị bảo mật của bên thứ ba vào đường đi một cách trong suốt, với khả năng mở rộng và chịu lỗi tự động.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | TGW: phí attachment + phí mỗi GB | tích luỹ theo số VPC | | Network Firewall: phí endpoint mỗi giờ mỗi AZ + phí mỗi GB | cần endpoint ở mỗi AZ | | Phí truyền dữ liệu xuyên Region | ~0,02 USD/GB |

Với kiến trúc kiểm tra tập trung, lưu lượng đi qua nhiều chặng tính phí — hãy tính toán trước khi triển khai ở quy mô lớn.

Và một lời khuyên khi triển khai: bắt đầu ở chế độ chỉ cảnh báo (alert) thay vì chặn, chạy vài tuần và xem log để biết rule sẽ chặn những gì. Một bộ rule quá chặt sẽ làm hỏng kết nối hợp lệ giữa hai bộ phận, và triệu chứng là timeout không rõ nguyên nhân — rất khó chẩn đoán.

Đáp án

A — Tạo Amazon Aurora Replica.

Vì sao đúng

Đề nêu vấn đề rõ: cụm Aurora chỉ có MỘT instance — đó là điểm hỏng đơn ở tầng dữ liệu.

Và Aurora Replica giải quyết trực tiếp:

Chỉ có một instance:
    → instance hỏng → Aurora phải TẠO MỚI một instance
    → mất VÀI PHÚT
    → cổng học trực tuyến ngừng hoạt động trong khoảng đó

Có Aurora Replica:
    → instance chính hỏng → Aurora đổi CNAME sang replica
    → replica được THĂNG CẤP thành primary
    → hoàn tất DƯỚI 30 GIÂY

Và replica còn mang lại lợi ích thứ hai: mở rộng khả năng đọc.

Cổng học trực tuyến có tải chủ yếu là ĐỌC:
    → xem bài giảng, xem tiến độ, xem điểm
        ↓
Reader endpoint tự phân phối truy vấn đọc giữa các replica
    → giảm tải cho instance chính

aws rds create-db-instance   --db-instance-identifier aurora-replica-1   --db-cluster-identifier cum-hoc-truc-tuyen   --db-instance-class db.r6g.large --engine aurora-mysql   --availability-zone ap-southeast-1b   --promotion-tier 0

Và đặt replica ở AZ KHÁC để chịu được sự cố AZ — dữ liệu vốn đã có 6 bản qua 3 AZ, nhưng tầng compute cần trải ra mới thật sự chịu lỗi.

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

• **B. Triển khai Aurora lên hai Auto Scaling group EC2 qua hai AZ với load balancer — hiểu sai bản chất Aurora: Aurora là dịch vụ được quản lý, bạn không cài nó lên EC2. Và không đặt load balancer trước database theo cách này.
• **C. Bật Hash Joins để cải thiện hiệu năng truy vấn — giải quyết vấn đề khác: hash join là kỹ thuật tối ưu cho truy vấn phép nối lớn. Nó không liên quan tới tính sẵn sàng.
• **D. Dùng Asynchronous Key Prefetch để tăng tốc truy vấn nối qua chỉ mục — cũng là tối ưu HIỆU NĂNG, không phải SẴN SÀNG.

Ghi nhớ

Hành vi failover của Aurora phụ thuộc vào việc có replica: | Cấu hình | Cơ chế | Thời gian | |---|---|---| | CÓ Aurora Replica | đổi CNAME sang replica, thăng cấp | dưới 30 giây | | KHÔNG có replica | tạo mới DB instance, best-effort | vài phút |

Kiến trúc lưu trữ của Aurora:

Tầng COMPUTE (DB instance)  ←→ tách rời ←→ Tầng LƯU TRỮ
                                              ↓
                                6 bản sao qua 3 AZ
                                tự sửa lỗi, tự mở rộng tới 128 TB

Mất instance KHÔNG mất dữ liệu — nhưng vẫn mất dịch vụ nếu không có instance nào thay thế ngay.

Khả năng chịu lỗi của tầng lưu trữ Aurora: | Mất | Hậu quả | |---|---| | 2 trong 6 bản | vẫn GHI được | | 3 trong 6 bản | vẫn ĐỌC được |

Ba loại endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster endpoint (writer) | instance chính — dùng cho GHI | | Reader endpoint | tự cân bằng tải giữa các replica — dùng cho ĐỌC | | Custom endpoint | nhóm instance do bạn định nghĩa |

Reader endpoint là tiện ích đáng giá — ứng dụng chỉ cần một địa chỉ, Aurora tự phân phối.

Và promotion tier quyết định replica nào được chọn khi failover:

Tier 0 (cao nhất) → ưu tiên thăng cấp trước
Tier 15 (thấp nhất) → chọn sau cùng
    → cùng tier thì chọn replica có kích thước GẦN NHẤT với primary

Aurora Replica và RDS Read Replica — bảng phân biệt: | | Aurora Replica | RDS Read Replica | |---|---|---| | Cơ chế | CHIA SẺ chung tầng lưu trữ | sao chép qua log của engine | | Độ trễ | mili giây | giây | | Số lượng | tới 15 | tối đa 5 | | Làm mục tiêu failover tự động | ✅ | ❌ (phải promote thủ công) | | Reader endpoint | ✅ | ❌ |

Ba tính năng khác của Aurora cho sẵn sàng cao: | Tính năng | Việc | |---|---| | Aurora Global Database | sao chép sang Region khác, độ trễ dưới 1 giây | | Backtrack | quay ngược cluster tới 72 giờ — chữa lỗi do người | | Aurora Serverless v2 | tự co giãn compute, thêm được vào cluster provisioned |

Backtrack rất hữu ích cho cổng học trực tuyến: lỡ chạy lệnh xoá nhầm dữ liệu học viên thì quay ngược trong vài phút, thay vì khôi phục snapshot mất hàng giờ.

Ba cấu hình ứng dụng cần có để failover mượt: | Cấu hình | Lý do | |---|---| | Dùng ENDPOINT, không hard-code IP | IP đổi sau failover | | Đặt TTL cache DNS ngắn | Java mặc định cache DNS VĨNH VIỄN | | Có cơ chế thử lại kết nối | failover mất vài giây |

java.security.Security.setProperty("networkaddress.cache.ttl", "5");

Và RDS Proxy giảm thời gian failover cảm nhận được tới 66%:

RDS Proxy giữ kết nối của client trong lúc database chuyển đổi
    → ứng dụng không thấy kết nối bị ngắt
    → và nó gộp kết nối, giảm tải cho database

Ba lưu ý về chi phí Aurora: | Khoản | Chi tiết | |---|---| | Mỗi replica là một instance tính phí riêng | thêm replica là gấp đôi chi phí compute | | Lưu trữ tính chung cho cả cluster | không nhân theo số replica | | I/O tính theo request | cân nhắc Aurora I/O-Optimized nếu I/O cao |

Aurora I/O-Optimized đáng cân nhắc:

Không tính phí I/O, đổi lại giá compute và lưu trữ cao hơn ~25%
    → có lợi khi chi phí I/O vượt 25% tổng hoá đơn
    → và làm hoá đơn dự đoán được

Và cách diễn tập failover:

aws rds failover-db-cluster --db-cluster-identifier cum-hoc-truc-tuyen

Hãy chạy thử vào giờ thấp điểm — nó cho biết thời gian ngừng thật và kiểm chứng ứng dụng kết nối lại đúng.

Và một lưu ý về kiến trúc trong đề: ứng dụng chạy trên một EC2 instance lớn — đó cũng là điểm hỏng đơn. Thêm Aurora Replica giải quyết tầng dữ liệu, nhưng tầng ứng dụng vẫn cần Auto Scaling group qua nhiều AZ sau một load balancer để thật sự sẵn sàng cao.

Đáp án

B — Khởi chạy Auto Scaling group EC2 instance cùng một SQS queue; thêm trigger co giãn theo độ sâu hàng đợi SQS.

Vì sao đúng

Đề nêu hai yêu cầu, và mô hình này đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | MỞ RỘNG được (highly scalable) | ASG tự thêm bớt máy; SQS là vùng đệm không giới hạn | | TIẾT KIỆM chi phí | chỉ chạy đúng số máy cần, tự co lại khi vắng |

Vì sao co giãn theo ĐỘ SÂU HÀNG ĐỢI là mẫu đúng:

Hàng đợi tích tụ → nghĩa là consumer không theo kịp
    → ASG thêm máy
Hàng đợi cạn    → consumer đang rảnh
    → ASG bớt máy
        ↓
Đây là chỉ báo TRỰC TIẾP của nhu cầu xử lý,
chính xác hơn nhiều so với CPU

Và SQS đóng vai trò vùng đệm bảo vệ hệ thống:

Đỉnh tải đột ngột:
    → thông điệp dồn vào hàng đợi
    → consumer xử lý theo tốc độ của mình
    → KHÔNG bị quá tải và sập
    → ASG dần thêm máy để bắt kịp

Cấu hình co giãn theo backlog mỗi instance:

# Metric tuỳ chỉnh: số thông điệp chờ / số instance
aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-xu-ly   --policy-name giu-backlog --policy-type TargetTrackingScaling   --target-tracking-configuration '{
    "TargetValue": 100.0,
    "CustomizedMetricSpecification": {
      "MetricName": "BacklogMoiInstance",
      "Namespace": "UngDungNganHang", "Statistic": "Average"}}'

AWS khuyến nghị dùng "backlog mỗi instance" thay vì độ sâu hàng đợi thuần:

Độ sâu thuần: 1.000 thông điệp → nhiều hay ít?
    → phụ thuộc số máy đang chạy
Backlog mỗi instance = 1.000 / số instance
    → nếu mỗi máy xử lý được 100 → đặt mục tiêu 100

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

• **D. Khởi chạy nhiều On-Demand EC2 instance CỐ ĐỊNH cùng SQS queue — đây là phương án gần nhất vì cũng dùng SQS làm vùng đệm, nhưng nó thiếu tính co giãn: số máy cố định nghĩa là hoặc thiếu năng lực lúc cao điểm, hoặc lãng phí lúc vắng. Đề yêu cầu cả "scalable" lẫn "cost-effective".
• **A. Nhiều EC2 sau ALB với SNS làm vùng đệm lưu thông điệp — hiểu sai SNS: SNS là dịch vụ phát tán (pub/sub) — nó ĐẨY thông điệp đi ngay và KHÔNG LƯU GIỮ. Nếu người nhận không sẵn sàng, thông điệp mất. Nó không phải vùng đệm.
• **C. Nhiều EC2 sau ALB với SWF làm vùng đệm — sai chức năng: Simple Workflow Service điều phối các bước trong một quy trình nghiệp vụ, nó không phải hàng đợi thông điệp. (Và SWF là dịch vụ thế hệ cũ — AWS khuyến nghị Step Functions cho nhu cầu mới.)

Ghi nhớ

Ba dịch vụ nhắn tin của AWS — đừng nhầm: | Dịch vụ | Mô hình | Lưu giữ | |---|---|---| | SQS | hàng đợi — consumer KÉO về | ✅ tới 14 ngày | | SNS | phát tán — ĐẨY tới người nhận | ❌ không lưu | | Kinesis Data Streams | luồng — nhiều consumer đọc cùng dữ liệu | ✅ 1–365 ngày | | EventBridge | định tuyến sự kiện theo mẫu | ❌ |

Quy tắc: chỉ SQS và Kinesis làm được VÙNG ĐỆM.

Mẫu kiến trúc "queue-based load levelling":

Producer (không giới hạn tốc độ)
    ↓
SQS (vùng đệm hấp thụ đỉnh tải)
    ↓
Consumer trong ASG (co giãn theo độ sâu hàng đợi)

Đây là một trong những mẫu quan trọng nhất của kiến trúc phân tán — nó tách rời tốc độ sinh dữ liệu khỏi tốc độ xử lý.

Ba metric SQS dùng cho Auto Scaling: | Metric | Đo gì | Dùng khi | |---|---|---| | ApproximateNumberOfMessagesVisible | số thông điệp chờ | cơ bản | | Backlog mỗi instance (tuỳ chỉnh) | số thông điệp / số máy | AWS khuyến nghị | | ApproximateAgeOfOldestMessage | thông điệp cũ nhất chờ bao lâu | có SLA về THỜI GIAN |

Ba cấu hình SQS quan trọng: | Cấu hình | Chi tiết | |---|---| | VisibilityTimeout | PHẢI ≥ thời gian xử lý dài nhất | | ReceiveMessageWaitTimeSeconds = 20 | bật long polling — rẻ hơn và ít độ trễ hơn | | Dead-letter queue | tách thông điệp hỏng ra |

Và consumer nên IDEMPOTENT:

def xu_ly(giao_dich):
    if da_xu_ly(giao_dich['ma']):
        return
    thuc_hien(giao_dich)
    danh_dau_da_xu_ly(giao_dich['ma'])

SQS standard giao ít nhất một lần — thông điệp có thể trùng, và với hệ thống ngân hàng thì xử lý trùng là hậu quả nghiêm trọng.

Và với giao dịch ngân hàng, cân nhắc SQS FIFO: | | Standard | FIFO | |---|---|---| | Thứ tự | không đảm bảo | ✅ trong message group | | Trùng lặp | có thể | ❌ không (cửa sổ 5 phút) | | Thông lượng | gần như không giới hạn | 300–3.000 TPS (cao hơn với high throughput mode) |

Với nghiệp vụ cần đúng thứ tự và không trùng, FIFO là lựa chọn đúng dù thông lượng thấp hơn.

Ba cách giảm chi phí cho đội consumer: | Cách | Mức tiết kiệm | |---|---| | Spot Instance cho phần vượt mức nền | tới 90% | | Savings Plan cho mức nền | tới 72% | | Lambda thay EC2 nếu tác vụ dưới 15 phút | 0 đồng khi rảnh |

Và SQS an toàn với Spot một cách tự nhiên:

Spot bị thu hồi giữa chừng
    → thông điệp KHÔNG được xoá
    → hết visibility timeout → quay lại hàng đợi
    → máy khác xử lý lại
    → không mất công việc nào

Xử lý cảnh báo thu hồi để trả thông điệp về ngay:

r = requests.get('http://169.254.169.254/latest/meta-data/spot/instance-action')
if r.status_code == 200:
    sqs.change_message_visibility(QueueUrl=q, ReceiptHandle=rh,
                                  VisibilityTimeout=0)

Và Lambda là lựa chọn đáng cân nhắc thay ASG: | | EC2 + ASG | Lambda event source mapping | |---|---|---| | Co giãn | theo metric, có độ trễ | gần như tức thì | | Chi phí khi rảnh | vẫn trả tiền instance | 0 đồng | | Thời gian xử lý tối đa | không giới hạn | 15 phút | | Công vận hành | quản lý AMI, vá lỗi | không có |

Với giao dịch ngân hàng xử lý nhanh, Lambda thường rẻ hơn và ít công hơn nhiều.

Ba metric cần đặt alarm: | Metric | Cảnh báo khi | |---|---| | ApproximateAgeOfOldestMessage | tiến gần SLA hoặc gần hết retention | | ApproximateNumberOfMessagesVisible | tích tụ bất thường | | Số thông điệp vào DLQ | có lỗi xử lý |

Và một lời khuyên: đặt MessageRetentionPeriod dài hơn mức bạn nghĩ cần (ví dụ 7 ngày thay vì mặc định 4). Với hệ thống ngân hàng, mất một giao dịch vì hàng đợi hết hạn trong lúc sự cố kéo dài là hậu quả khó khắc phục — và chi phí lưu trữ thêm gần như bằng không.

Đáp án

B — Tạo một IAM role, sau đó gán role đó cho EC2 instance mới.

Vì sao đúng

Đề hỏi cách cung cấp thông tin đăng nhập để gọi API của S3 — và IAM role là cách duy nhất an toàn.

Cách IAM role hoạt động trên EC2:

Gán instance profile chứa IAM role
    ↓
SDK và CLI tự lấy thông tin đăng nhập TẠM THỜI qua IMDS:
    http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>
    ↓
    → tự làm mới trước khi hết hạn
    → KHÔNG có khoá nào lưu trên đĩa

Bốn lợi ích so với việc lưu access key: | Lợi ích | Chi tiết | |---|---| | Thông tin đăng nhập TẠM THỜI | tự hết hạn sau vài giờ | | Không có gì để rò rỉ | không nằm trên đĩa, không nằm trong mã | | Đổi quyền có hiệu lực NGAY | sửa policy, không cần triển khai lại | | Không phải xoay vòng thủ công | AWS lo hoàn toàn |

Policy theo quyền tối thiểu cho tình huống này:

{"Effect": "Allow",
 "Action": ["s3:PutObject"],
 "Resource": "arn:aws:s3:::kho-anh-da-xu-ly/*"}

Và bắt buộc dùng IMDSv2 để chống tấn công SSRF:

aws ec2 modify-instance-metadata-options --instance-id i-0abc123   --http-tokens required --http-put-response-hop-limit 1

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

• **A. Mã hoá access key rồi lưu trong một thư mục của EC2 instance — đây là phương án gần nhất vì có ý thức bảo vệ khoá, nhưng nó chỉ đẩy vấn đề đi một bước: ứng dụng phải giải mã được khoá, nghĩa là khoá giải mã cũng phải nằm trên máy. Và access key vẫn là thông tin đăng nhập dài hạn, không hết hạn.
• **D. Lưu access key trong thư mục gốc của ứng dụng web — rủi ro nghiêm trọng nhất: thư mục web thường được máy chủ phục vụ ra ngoài, và một cấu hình sai là ai cũng tải được tệp chứa khoá.
• **C. Lưu access key trong Amazon Glacier — không dùng được về mặt vận hành: Glacier mất vài phút tới vài giờ để lấy dữ liệu. Và vẫn quay lại câu hỏi: ứng dụng dùng khoá nào để đọc Glacier?

Ghi nhớ

Nguyên tắc cốt lõi: KHÔNG BAO GIỜ lưu thông tin đăng nhập dài hạn trên máy, trong mã, hay trong AMI.

Cách cấp quyền đúng cho từng loại tài nguyên: | Tài nguyên | Cơ chế | |---|---| | EC2 instance | IAM role qua instance profile | | Lambda function | execution role | | ECS task | task role (không phải instance role) | | EKS pod | IRSA — IAM Roles for Service Accounts | | CI/CD ngoài AWS | OIDC federation (GitHub Actions, GitLab) | | Người dùng | IAM Identity Center với SSO |

Không trường hợp nào cần access key dài hạn.

IMDSv1 và IMDSv2 — khác biệt quan trọng về bảo mật: | | IMDSv1 | IMDSv2 | |---|---|---| | Cách gọi | GET đơn giản | PUT lấy token trước, rồi GET kèm token | | Chống SSRF | ❌ dễ bị khai thác | ✅ | | Giới hạn hop mạng | không | mặc định 1 — chặn container truy cập |

Lỗ hổng SSRF trong ứng dụng web
    → kẻ tấn công ép máy chủ gọi 169.254.169.254
    → với IMDSv1: LẤY ĐƯỢC thông tin đăng nhập của role
    → đây là nguyên nhân của nhiều vụ rò rỉ dữ liệu lớn

Ba việc phải làm nếu access key đã bị lộ: | Việc | Thứ tự | |---|---| | ① Vô hiệu hoá khoá NGAY | aws iam update-access-key --status Inactive | | ② Kiểm tra CloudTrail | xem khoá đã được dùng làm gì, từ IP nào | | ③ Xoá khoá | và chuyển sang IAM role |

Ba công cụ phát hiện thông tin đăng nhập rủi ro: | Công cụ | Việc | |---|---| | IAM Credential Report | liệt kê mọi khoá và tuổi của chúng | | AWS Config rule access-keys-rotated | phát hiện khoá quá hạn | | GuardDuty | phát hiện khoá bị dùng từ nơi bất thường |

Và biện pháp phòng ngừa mạnh nhất: SCP chặn tạo access key.

{"Effect": "Deny", "Action": "iam:CreateAccessKey", "Resource": "*"}

Ba lưu ý khi dùng IAM role trên EC2: | Lưu ý | Chi tiết | |---|---| | Gán INSTANCE PROFILE, không gán role trực tiếp | instance profile là vỏ bọc của role | | Một instance chỉ gắn được MỘT role | cần nhiều quyền thì gộp vào một policy | | Đổi policy có hiệu lực gần như ngay | không cần khởi động lại |

Và với ứng dụng chạy trên nhiều instance dùng chung AMI, hãy dùng ABAC:

{"Effect": "Allow", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-anh/*",
 "Condition": {"StringEquals":
   {"aws:PrincipalTag/MoiTruong": "${aws:ResourceTag/MoiTruong}"}}}

Một role, một policy, áp đúng phạm vi cho từng môi trường nhờ thẻ.

Và với kiến trúc trong đề, có một cải tiến đáng cân nhắc:

Hiện tại: người dùng → EC2 xử lý ảnh → S3
    → EC2 phải nhận toàn bộ tệp rồi mới đẩy tiếp

Tốt hơn: người dùng tải THẲNG lên S3 bằng pre-signed URL
    → S3 event → Lambda xử lý ảnh → ghi kết quả về S3
    → không có máy chủ nào phải chạy chờ

Và một lời khuyên: hãy chạy IAM Access Analyzer để sinh policy từ hoạt động thực tế trong CloudTrail — cấp rộng trong môi trường thử, đo xem ứng dụng thật sự dùng gì, rồi sinh policy khớp chính xác. Quyền tối thiểu dựa trên dữ liệu chứ không phải phỏng đoán.

Đáp án

B và C.

• C — Chụp snapshot của EBS volume rồi chấm dứt (terminate) EC2 instance
• B — Bán các Reserved Instance trên AWS Reserved Instance Marketplace

Vì sao đúng

Đề nêu hai nhu cầu đối lập nhau, và hai đáp án giải quyết lần lượt: | Nhu cầu | Giải pháp | |---|---| | Đội kiểm toán vẫn cần DỮ LIỆU | C — snapshot giữ lại dữ liệu, chi phí rất thấp | | Ngừng tốn tiền cho Reserved Instance | B — bán lại là cách duy nhất thoát khỏi cam kết |

C — snapshot giữ dữ liệu với chi phí tối thiểu:

Chấm dứt instance → ngừng trả phí compute
    ↓
Snapshot của EBS volume vẫn còn
    → chỉ tính phí theo dữ liệu THẬT (tính tăng dần)
    → khôi phục thành volume mới bất cứ lúc nào khi cần kiểm toán

B — và bán lại là cách duy nhất thu hồi giá trị của RI:

Reserved Instance = cam kết TRẢ TIỀN 1 hoặc 3 năm
    → dừng hay chấm dứt instance KHÔNG huỷ được cam kết
    → cách duy nhất: BÁN trên Marketplace
    → người mua tiếp nhận phần thời hạn còn lại

Hai việc này bổ sung nhau: snapshot giữ dữ liệu, bán RI thu hồi tiền.

aws ec2 create-snapshot --volume-id vol-0abc123   --description "Luu tru cho kiem toan - 2026-08"
aws ec2 terminate-instances --instance-ids i-0abc123

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

• **E. Dừng (stop) tất cả EC2 instance đang chạy — đây là phương án gần nhất và là phản xạ tự nhiên, nhưng nó không tiết kiệm được gì với RI: Reserved Instance tính phí theo cam kết, không theo việc máy có chạy hay không. Dừng máy vẫn trả đủ tiền reservation, mà còn tốn thêm phí EBS.
• **A. Chuyển EC2 instance sang On-Demand — không có thao tác như vậy: RI là một khoản thanh toán riêng biệt, không phải thuộc tính của instance. Và On-Demand còn đắt hơn.
• **D. Chuyển sang Spot Instance với persistent request — sai mục đích hoàn toàn: đề nói máy không còn được dùng nữa. Chuyển sang Spot để tiếp tục chạy là ngược với yêu cầu.

Ghi nhớ

Reserved Instance tính phí theo CAM KẾT, không theo mức sử dụng: | Thao tác | Ngừng tính phí RI | |---|---| | Dừng instance | ❌ vẫn trả đủ | | Chấm dứt instance | ❌ vẫn trả tới hết kỳ hạn | | BÁN trên Marketplace | ✅ cách duy nhất | | Đổi cấu hình (Convertible RI) | ✅ chuyển giá trị sang cấu hình khác |

Điều kiện để bán Reserved Instance: | Điều kiện | Chi tiết | |---|---| | Chỉ Standard RI | Convertible RI KHÔNG bán được | | Đã sở hữu ít nhất 30 ngày | tính từ ngày mua | | Cần tài khoản ngân hàng Mỹ | rào cản thực tế lớn với tổ chức ngoài Mỹ | | Còn ít nhất 1 tháng kỳ hạn | RI sắp hết hạn không bán được |

Standard RI và Convertible RI: | | Standard | Convertible | |---|---|---| | Giảm giá tối đa | 72% | 66% | | Bán trên Marketplace | ✅ | ❌ | | Đổi loại instance, hệ điều hành | ❌ | ✅ |

Bài học: nếu không chắc workload chạy đủ kỳ hạn, hãy mua Convertible RI hoặc Savings Plan thay vì Standard RI.

Ba đặc điểm của EBS snapshot khiến nó phù hợp cho lưu trữ kiểm toán: | Đặc điểm | Chi tiết | |---|---| | TĂNG DẦN (incremental) | chỉ lưu khối dữ liệu thay đổi so với snapshot trước | | Lưu trong S3 do AWS quản lý | độ bền rất cao | | Khôi phục thành volume mới bất cứ lúc nào | và ở AZ hoặc Region khác |

Và có một lớp lưu trữ rẻ hơn nữa cho snapshot ít dùng:

aws ec2 modify-snapshot-tier --snapshot-id snap-0abc123   --storage-tier archive

Với dữ liệu kiểm toán hiếm khi truy cập, archive tier là lựa chọn đúng.

Ba việc nên làm khi ngừng một workload trên AWS: | Việc | Lý do | |---|---| | Chấm dứt instance, xoá EBS volume không cần | volume available vẫn tính tiền | | Giải phóng Elastic IP | EIP không gắn vào máy đang chạy bị tính phí | | Xoá NAT gateway, load balancer, snapshot cũ | NAT gateway là khoản tốn kém âm thầm phổ biến nhất |

Và AWS Cost Explorer có báo cáo đúng cho tình huống này:

Cost Explorer → Reservations → Utilization report
    → RI dưới 100% utilization = đang trả tiền cho phần không dùng

Savings Plan — lựa chọn linh hoạt hơn RI cho lần sau: | | Reserved Instance | Savings Plan | |---|---|---| | Cam kết theo | cấu hình instance cụ thể | số USD/giờ | | Áp cho Fargate và Lambda | ❌ | ✅ (Compute Savings Plan) | | Tự áp cho tài nguyên phù hợp | cần khớp cấu hình | ✅ tự động | | Bán lại | ✅ (Standard) | ❌ |

Và một lời khuyên: hãy đặt AWS Budgets với cảnh báo trước ngày RI hết hạn 30 ngày. Nó cho thời gian quyết định gia hạn, bán lại, hay tắt hẳn — thay vì phát hiện qua hoá đơn tăng đột ngột khi RI hết hạn mà instance vẫn chạy ở giá On-Demand.

Đáp án

A — Dừng rồi khởi động lại (stop và start) các instance trong placement group, sau đó thử khởi chạy lại.

Vì sao đúng

Đề mô tả lỗi insufficient capacity khi thêm instance vào một cluster placement group đã có máy đang chạy — và đây là khuyến nghị chính thức của AWS cho tình huống này.

Vì sao lỗi xảy ra:

Cluster placement group đặt mọi instance GẦN NHAU
    → cùng một mạng con vật lý, thường cùng một giá máy chủ
        ↓
Khi bạn thêm instance sau:
    → AWS phải tìm chỗ trống Ở ĐÚNG khu vực vật lý đó
    → nếu khu vực đó đã đầy → insufficient capacity

Và vì sao dừng rồi khởi động lại giúp được:

Dừng TẤT CẢ instance trong placement group
    → chúng nhả hết phần cứng đang chiếm
        ↓
Khởi động lại:
    → AWS tìm một khu vực vật lý mới, đủ rộng cho TOÀN BỘ nhóm
    → bao gồm cả số instance mới bạn muốn thêm

Đây là cách "sắp xếp lại chỗ ngồi cho cả nhóm" thay vì cố nhét thêm vào chỗ đã chật.

Và có một thực hành phòng ngừa quan trọng:

Khởi chạy TOÀN BỘ số instance cần thiết trong MỘT lời gọi duy nhất
    → AWS tìm chỗ cho tất cả cùng lúc
    → giảm hẳn khả năng gặp insufficient capacity

aws ec2 run-instances --image-id ami-0abc123   --instance-type c5n.9xlarge --count 20   --placement GroupName=cum-thoi-tiet

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

• **C. Kiểm tra mọi instance đang chạy có cùng kích thước và loại rồi thử lại — đây là phương án gần nhất và dùng CÙNG LOẠI instance thực sự là khuyến nghị của AWS, nhưng nó không phải cách KHẮC PHỤC: dùng cùng loại giúp giảm khả năng gặp lỗi, nhưng khi lỗi đã xảy ra thì việc "kiểm tra" không giải phóng dung lượng nào.
• **B. Tạo placement group KHÁC và khởi chạy instance mới ở đó — phá vỡ mục đích của placement group: các instance ở hai nhóm khác nhau không còn gần nhau về mặt vật lý, nên mất hết lợi ích về độ trễ thấp mà hệ thống giám sát thời tiết cần.
• **D. Gửi yêu cầu tăng hạn mức vì giới hạn 12 instance mỗi placement group — con số này không tồn tại: AWS không có hạn mức cứng 12 instance cho cluster placement group. Giới hạn thực tế là dung lượng vật lý sẵn có.

Ghi nhớ

Ba loại placement group — bảng cần thuộc: | Loại | Bố trí | Dùng cho | |---|---|---| | Cluster | GẦN NHAU trong MỘT AZ | HPC, độ trễ thấp nhất, băng thông cao nhất | | Spread | mỗi instance trên một GIÁ MÁY CHỦ khác | tối đa hoá khả năng chịu lỗi | | Partition | nhóm instance trên các phân vùng phần cứng tách biệt | HDFS, Cassandra, Kafka |

Đặc điểm và giới hạn của từng loại: | Loại | Giới hạn | |---|---| | Cluster | một AZ duy nhất; không có giới hạn số instance cứng | | Spread | tối đa 7 instance MỖI AZ | | Partition | tối đa 7 phân vùng mỗi AZ |

Con số 7 của Spread là giới hạn cứng cần nhớ.

Ba thực hành tốt với cluster placement group: | Thực hành | Lý do | |---|---| | Khởi chạy TOÀN BỘ instance trong MỘT lời gọi | AWS tìm chỗ cho tất cả cùng lúc | | Dùng CÙNG loại instance | dễ tìm dung lượng đồng nhất | | Chọn loại instance hỗ trợ Enhanced Networking | để tận dụng được lợi thế gần nhau |

Và đánh đổi của cluster placement group:

Mọi instance ở CÙNG MỘT AZ
    → độ trễ thấp nhất, băng thông cao nhất
    → NHƯNG mất AZ đó là mất toàn bộ cụm
        ↓
Chấp nhận được với HPC (công việc chạy lại được)
Không chấp nhận được với dịch vụ trực tuyến

Ba công nghệ mạng đi kèm để tận dụng cluster placement group: | Công nghệ | Đặc điểm | |---|---| | ENA (Elastic Network Adapter) | Enhanced Networking, tới 100 Gbps, Linux và Windows | | EFA (Elastic Fabric Adapter) | ENA + OS-BYPASS — CHỈ LINUX | | Intel 82599 VF | thế hệ cũ, tối đa 10 Gbps |

Với HPC trên Linux, EFA cho hiệu năng tốt nhất — nó dùng giao thức SRD thay TCP và bỏ qua nhân hệ điều hành.

Và hậu tố n trong tên instance nghĩa là tối ưu mạng:

c5n, m5n, r5n → băng thông cao hơn hẳn loại thường cùng kích thước
                và hỗ trợ EFA

Ba nguyên nhân khác gây insufficient capacity: | Nguyên nhân | Cách xử lý | |---|---| | Loại instance hiếm ở AZ đó | thử AZ khác hoặc loại instance khác | | Nhu cầu tăng đột biến trong Region | thử lại sau, hoặc dùng Capacity Reservation | | Trộn nhiều loại instance trong cluster group | dùng cùng loại |

Và On-Demand Capacity Reservation là biện pháp phòng ngừa:

aws ec2 create-capacity-reservation   --instance-type c5n.9xlarge --instance-platform Linux/UNIX   --availability-zone ap-southeast-1a --instance-count 20   --placement-group-arn <arn-placement-group>

Nó giữ chỗ trước, nên khi cần mở rộng thì chắc chắn có dung lượng.

Ba lưu ý về placement group: | Lưu ý | Chi tiết | |---|---| | Không đổi placement group của instance đang chạy | phải dừng instance trước | | Không gộp hai placement group | | | Instance có thể rời placement group | dừng rồi khởi động lại không có tham số placement |

aws ec2 modify-instance-placement --instance-id i-0abc123   --group-name cum-moi
# instance phải đang ở trạng thái stopped

Và một lời khuyên cho hệ thống giám sát thời tiết như đề mô tả: hãy cân nhắc AWS ParallelCluster — nó tự động hoá việc dựng cụm HPC gồm head node, compute node với Slurm, FSx for Lustre làm hệ thống tệp chung, và tự co giãn theo hàng đợi công việc. Nó cũng xử lý việc đặt instance vào placement group đúng cách, tránh được chính vấn đề trong đề.

Đáp án

A — Tạo Amazon Comprehend analysis job; đưa kết quả cảm xúc kèm bản ghi vào cụm Amazon OpenSearch; trực quan hoá bằng OpenSearch Dashboard.

Vì sao đúng

Đề nêu hai yêu cầu, và đáp án giải quyết lần lượt với ít công vận hành nhất: | Yêu cầu | Giải pháp | |---|---| | Trích xuất CẢM XÚC từ văn bản đã phiên âm | Amazon Comprehend — dịch vụ NLP được quản lý sẵn | | Trực quan hoá kết quả | OpenSearch Dashboard — có sẵn trong cụm OpenSearch |

Amazon Comprehend là dịch vụ AI được quản lý:

Gọi API DetectSentiment
    → không huấn luyện mô hình
    → không triển khai endpoint
    → không bảo trì gì

r = comprehend.detect_sentiment(Text=van_ban, LanguageCode='en')
print(r['Sentiment'], r['SentimentScore'])
# NEGATIVE {'Positive': 0.02, 'Negative': 0.93, 'Neutral': 0.04, 'Mixed': 0.01}

Và với khối lượng lớn, dùng job bất đồng bộ:

aws comprehend start-sentiment-detection-job   --input-data-config S3Uri=s3://kho-ban-ghi/json/,InputFormat=ONE_DOC_PER_FILE   --output-data-config S3Uri=s3://kho-ket-qua/   --data-access-role-arn <arn-role> --language-code en

Và OpenSearch Dashboard là công cụ có SẴN trong cụm OpenSearch:

Đã có cụm OpenSearch → đã có Dashboard
    → không phải dựng thêm dịch vụ nào
    → không phải cấu hình kết nối

Đó chính là điểm phân biệt với Grafana — dùng công cụ đã có sẵn thì ít công hơn.

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

• **C. Comprehend + OpenSearch nhưng trực quan hoá bằng Amazon Managed Grafana — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó thêm một dịch vụ không cần thiết: Managed Grafana là dịch vụ riêng, phải dựng workspace, cấu hình nguồn dữ liệu, quản lý quyền truy cập. OpenSearch Dashboard đã đi kèm cụm.
• **B. Phân tích tệp JSON bằng Amazon Textract — sai loại dịch vụ: Textract trích xuất văn bản từ tài liệu QUÉT hoặc ảnh (PDF scan, biểu mẫu). Tệp JSON đã là văn bản rồi — không có gì để "trích xuất", và Textract không phân tích cảm xúc.
• **D. Huấn luyện mô hình NLP tuỳ chỉnh bằng Amazon SageMaker — nhiều công vận hành nhất: phải chuẩn bị dữ liệu gán nhãn, huấn luyện, đánh giá, triển khai endpoint, và bảo trì mô hình. Đề hỏi cách "minimizing the amount of operational overhead".

Ghi nhớ

Các dịch vụ AI được quản lý sẵn của AWS — bảng cần thuộc: | Dịch vụ | Đầu vào → đầu ra | |---|---| | Comprehend | văn bản → CẢM XÚC, thực thể, chủ đề, ngôn ngữ, PII | | Comprehend Medical | văn bản y tế → PHI, thuốc, chẩn đoán | | Transcribe | giọng nói → văn bản | | Polly | văn bản → giọng nói | | Translate | văn bản ngôn ngữ A → ngôn ngữ B | | Textract | tài liệu QUÉT → văn bản, bảng, biểu mẫu | | Rekognition | ảnh và video → nhãn, khuôn mặt | | Lex | hội thoại → ý định (chatbot) | | Kendra | câu hỏi → tài liệu liên quan |

Quy tắc nhận diện:

"sentiment", "entities", "key phrases" từ VĂN BẢN → Comprehend "extract text from scanned document" → Textract "no ML expertise", "minimal overhead" → dịch vụ AI được quản lý, KHÔNG phải SageMaker

Bốn giá trị cảm xúc của Comprehend: | Giá trị | Ý nghĩa | |---|---| | POSITIVE | tích cực | | NEGATIVE | tiêu cực | | NEUTRAL | trung tính | | MIXED | vừa tích cực vừa tiêu cực trong cùng văn bản |

Nên dùng cả ĐIỂM SỐ chứ không chỉ nhãn — một cuộc gọi NEGATIVE với điểm 0,51 rất khác một cuộc gọi 0,98.

Ba khả năng khác của Comprehend đáng dùng cho phân tích cuộc gọi: | Khả năng | Việc | |---|---| | DetectEntities | tên sản phẩm, địa điểm, ngày tháng | | DetectKeyPhrases | chủ đề chính của cuộc gọi | | DetectPiiEntities | phát hiện và che thông tin cá nhân | | Custom classification | phân loại theo nhãn riêng của bạn |

DetectPiiEntities quan trọng với dữ liệu cuộc gọi — bản ghi thường chứa số thẻ, số điện thoại, địa chỉ.

Ba công cụ trực quan hoá của AWS: | Công cụ | Nguồn dữ liệu chính | |---|---| | OpenSearch Dashboard | OpenSearch — đi kèm cụm | | Amazon QuickSight | Athena, Redshift, RDS, S3 — BI cho doanh nghiệp | | Amazon Managed Grafana | nhiều nguồn — mạnh cho giám sát hạ tầng |

Quy tắc chọn:

Dữ liệu đã ở OpenSearch → OpenSearch Dashboard (không thêm gì) Báo cáo kinh doanh, người dùng nghiệp vụ → QuickSight Giám sát hệ thống, nhiều nguồn metric → Grafana

Kiến trúc đầy đủ cho phân tích cuộc gọi:

Ghi âm cuộc gọi → S3
    ↓ S3 event
Lambda gọi Transcribe (phiên âm, có speaker diarization)
    ↓ kết quả JSON về S3
    ↓ S3 event
Lambda gọi Comprehend (DetectSentiment, DetectKeyPhrases)
    ↓
OpenSearch (index bản ghi + cảm xúc + chủ đề)
    ↓
OpenSearch Dashboard (biểu đồ xu hướng, lọc theo nhân viên)

Và với trung tâm cuộc gọi dùng Amazon Connect, có giải pháp dựng sẵn:

Amazon Connect Contact Lens:
    ✓ phiên âm tự động
    ✓ phân tích cảm xúc theo thời gian trong cuộc gọi
    ✓ phát hiện khoảng lặng và nói chen
    ✓ tìm kiếm theo từ khoá
    → KHÔNG phải tự ghép các dịch vụ

Nếu công ty dùng Amazon Connect, đây là lựa chọn ít công nhất.

Ba lưu ý khi index vào OpenSearch: | Lưu ý | Chi tiết | |---|---| | Thiết kế mapping trước | kiểu dữ liệu của trường ảnh hưởng cách truy vấn | | Dùng index theo thời gian | cuoc-goi-2026.08 — dễ áp lifecycle | | Bật UltraWarm cho dữ liệu cũ | rẻ hơn nhiều cho index ít truy vấn |

Ba cấp lưu trữ của OpenSearch Service: | Cấp | Đặc điểm | |---|---| | Hot | SSD, truy vấn nhanh nhất | | UltraWarm | dùng S3 làm nền — rẻ hơn tới 90% | | Cold | rẻ nhất, phải "hâm nóng" trước khi truy vấn |

Và một lưu ý về chi phí Comprehend: nó tính phí theo đơn vị 100 ký tự. Với hàng nghìn cuộc gọi dài, khoản này tích tụ — hãy cân nhắc chỉ phân tích phần lời của khách hàng (nhờ speaker diarization của Transcribe) thay vì toàn bộ bản ghi, vì cảm xúc của nhân viên hỗ trợ thường không phải thứ cần đo.

Đáp án

A và D.

• A — Khi cần hiệu năng packet per second (PPS) CAO HƠN
• D — Khi cần độ trễ giữa các instance THẤP và NHẤT QUÁN

Vì sao đúng

Enhanced Networking dùng công nghệ SR-IOV (Single Root I/O Virtualization) để cải thiện hiệu năng mạng.

Cách SR-IOV hoạt động:

Mạng ảo hoá thông thường:
    Ứng dụng → nhân hệ điều hành → lớp ảo hoá → phần cứng mạng
        → mỗi lớp thêm độ trễ và tiêu tốn CPU

SR-IOV:
    Instance nói chuyện TRỰC TIẾP với một "hàm ảo" của card mạng
        → bỏ qua lớp ảo hoá
        → độ trễ thấp hơn, CPU rảnh hơn

Ba lợi ích của Enhanced Networking: | Lợi ích | Chi tiết | |---|---| | Băng thông cao hơn | tới 100 Gbps tuỳ loại instance | | PPS cao hơn | quan trọng với lưu lượng nhiều gói tin nhỏ ← A | | Độ trễ thấp và NHẤT QUÁN hơn | ít nhiễu từ instance khác trên cùng máy chủ ← D |

Và PPS quan trọng riêng biệt so với băng thông:

Băng thông cao nhưng PPS thấp
    → tốt cho truyền tệp lớn
    → KÉM cho ứng dụng gửi hàng triệu gói tin nhỏ
        (game, giao dịch tài chính, VoIP, cụm phân tán)

Và Enhanced Networking MIỄN PHÍ — không tính thêm phí gì.

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

• **E. Khi cần kết nối chuyên dụng tới trung tâm dữ liệu tại chỗ — đây là phương án gần nhất vì cũng nói về mạng, nhưng đó là mô tả của AWS Direct Connect. Enhanced Networking tối ưu hiệu năng mạng của instance trong VPC, không tạo kết nối lai nào.
• **B. Khi cần hiệu năng PPS THẤP — ngược với mục đích: không ai cần PPS thấp; Enhanced Networking tồn tại để tăng PPS.
• **C. Khi cần độ trễ CAO — cũng ngược: mục tiêu là giảm độ trễ.

Ghi nhớ

Ba công nghệ mạng của EC2 — bảng cần thuộc: | Công nghệ | Hệ điều hành | Đặc điểm | |---|---|---| | Intel 82599 VF | Linux, Windows | thế hệ CŨ, tối đa 10 Gbps | | ENA (Elastic Network Adapter) | Linux VÀ Windows | tới 100 Gbps, hiện hành | | EFA (Elastic Fabric Adapter) | CHỈ LINUX | ENA + OS-BYPASS cho HPC |

"EFA chỉ hỗ trợ Linux" là chi tiết hay bị hỏi.

Ba yêu cầu để Enhanced Networking hoạt động: | Yêu cầu | Chi tiết | |---|---| | Loại instance hỗ trợ | hầu hết loại thế hệ hiện tại đã có sẵn | | AMI có driver ENA | AMI Amazon Linux, Ubuntu, Windows gần đây đã có | | Thuộc tính enaSupport bật | thường bật sẵn |

aws ec2 describe-instances --instance-ids i-0abc123   --query 'Reservations[].Instances[].EnaSupport'

# Bật cho instance chưa có (phải dừng instance trước)
aws ec2 modify-instance-attribute --instance-id i-0abc123 --ena-support

Và EFA là gì — khi nào cần:

EFA = ENA + khả năng OS-BYPASS
    → ứng dụng giao tiếp THẲNG với phần cứng mạng
    → dùng giao thức SRD thay TCP
    → hỗ trợ MPI và NCCL
        ↓
Cần cho: mô phỏng CFD, huấn luyện học sâu phân tán, tính toán khoa học

Ba đặc điểm của EFA: | Đặc điểm | Chi tiết | |---|---| | OS-bypass | bỏ qua nhân hệ điều hành | | Chỉ hiệu quả TRONG cùng cluster placement group | không tăng tốc lưu lượng Internet | | Yêu cầu security group đặc biệt | cho phép MỌI lưu lượng từ CHÍNH NÓ, hai chiều |

aws ec2 authorize-security-group-ingress --group-id sg-efa   --protocol -1 --source-group sg-efa
aws ec2 authorize-security-group-egress --group-id sg-efa   --protocol -1 --source-group sg-efa

Đây là cấu hình bắt buộc mà nhiều người bỏ sót.

Và cluster placement group là bạn đồng hành của Enhanced Networking: | Loại placement group | Bố trí | Dùng cho | |---|---|---| | Cluster | gần nhau trong MỘT AZ | HPC, độ trễ thấp nhất | | Spread | mỗi instance một giá máy chủ khác | tối đa hoá chịu lỗi | | Partition | nhóm trên phân vùng phần cứng tách biệt | HDFS, Cassandra, Kafka |

Ba loại instance tối ưu mạng:

Hậu tố "n" = network optimized
    c5n, m5n, r5n → băng thông 100 Gbps, hỗ trợ EFA
    hpc6a, hpc7a → thiết kế riêng cho HPC

Ba metric để đo hiệu năng mạng của instance: | Metric | Ý nghĩa | |---|---| | NetworkIn / NetworkOut | băng thông thực tế | | NetworkPacketsIn / NetworkPacketsOut | PPS thực tế | | bw_in_allowance_exceeded (qua ethtool) | chạm trần băng thông của instance |

Kiểm tra trên instance:

ethtool -S eth0 | grep exceeded
# bw_in_allowance_exceeded: 0
# pps_allowance_exceeded: 0     ← khác 0 nghĩa là đang bị giới hạn

Đây là cách chẩn đoán chính xác xem nút thắt nằm ở băng thông hay ở PPS.

Ba lưu ý về giới hạn mạng của instance: | Lưu ý | Chi tiết | |---|---| | Instance nhỏ có băng thông BURST | cạn tín dụng thì tụt xuống mức cơ sở | | Băng thông tới Internet thấp hơn băng thông trong VPC | với một số loại | | Băng thông chia sẻ giữa các ENI | không cộng dồn khi gắn nhiều ENI |

Và một lời khuyên: nếu ứng dụng cần PPS rất cao, hãy chọn instance lớn hơn hoặc loại có hậu tố n thay vì cố tối ưu ở tầng phần mềm. Giới hạn PPS gắn với kích thước instance, và không có cách nào vượt qua bằng cấu hình.

Đáp án

C — Nên cân nhắc AWS CloudHSM thay vì AWS KMS nếu bạn cần khoá được lưu trong module bảo mật phần cứng chuyên dụng, đã qua kiểm định của bên thứ ba, dưới quyền kiểm soát ĐỘC QUYỀN của bạn.

Vì sao đúng

Đây là mô tả chính xác về sự khác biệt giữa hai dịch vụ.

Điểm phân biệt cốt lõi: mô hình thuê và quyền kiểm soát.

AWS KMS:
    → MULTI-TENANT (dùng chung hạ tầng với khách hàng khác)
    → AWS vận hành HSM bên dưới
    → bạn kiểm soát CHÍNH SÁCH khoá

AWS CloudHSM:
    → SINGLE-TENANT — thiết bị HSM RIÊNG cho bạn
    → AWS chỉ quản lý PHẦN CỨNG và mạng
    → BẠN quản lý người dùng, khoá, và mọi thao tác mật mã
    → AWS KHÔNG truy cập được khoá của bạn

Và với xử lý thẻ tín dụng, đây là lý do CloudHSM tồn tại:

Một số quy định (PCI-DSS ở mức cao nhất, PCI PIN, một số luật quốc gia)
    yêu cầu khoá phải nằm trong HSM đạt FIPS 140-2 Level 3
    dưới quyền kiểm soát độc quyền của tổ chức
        ↓
    KMS không đáp ứng được yêu cầu "độc quyền" đó

Nhưng đánh đổi rất rõ ràng: | | KMS | CloudHSM | |---|---|---| | Chi phí | ~1 USD/khoá/tháng | ~1,45 USD/GIỜ mỗi HSM | | Công vận hành | rất thấp | cao — bạn quản lý người dùng và khoá | | Tích hợp dịch vụ AWS | rất rộng | hạn chế | | Khôi phục khi mất khoá | AWS lo | ❌ chỉ từ backup của bạn |

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

• **B. Nếu muốn dịch vụ được quản lý để tạo và kiểm soát khoá nhưng không muốn tự vận hành HSM, hãy dùng CloudHSM — đây là phương án gần nhất và là bẫy chính: mô tả trong câu đúng là của KMS, nhưng nó gán nhầm cho CloudHSM. CloudHSM chính là thứ bạn phải tự vận hành.
• **D. CloudHSM luôn phải dùng cho mọi giao dịch thanh toán — quá tuyệt đối: nhiều hệ thống thanh toán tuân thủ PCI-DSS hoàn toàn với KMS. CloudHSM chỉ cần khi có yêu cầu cụ thể về HSM độc quyền.
• **A. Không có khác biệt đáng kể, cả hai làm cùng một việc — sai: hai dịch vụ có mô hình thuê, mức kiểm soát, chi phí và công vận hành khác hẳn nhau.

Ghi nhớ

CloudHSM và KMS — bảng phân biệt cốt lõi: | | AWS KMS | AWS CloudHSM | |---|---|---| | Mô hình thuê | multi-tenant | SINGLE-TENANT — thiết bị riêng | | Ai kiểm soát khoá | AWS quản lý, bạn kiểm soát policy | CHỈ BẠN — AWS không truy cập được | | Chuẩn FIPS | FIPS 140-3 Level 3 (HSM validated) | FIPS 140-2 Level 3 | | Khôi phục khi mất | ✅ AWS lo | ❌ chỉ từ backup của bạn | | Tích hợp dịch vụ AWS | ✅ rất rộng | hạn chế | | API | AWS API | PKCS#11, JCE, CNG (chuẩn ngành) | | Chi phí | ~1 USD/khoá/tháng | ~1,45 USD/giờ mỗi HSM |

Quy tắc chọn:

Cần HSM độc quyền vì yêu cầu pháp lý, hoặc cần API chuẩn ngành (PKCS#11) → CloudHSM Mọi trường hợp còn lại → KMS

Ba trường hợp thực sự cần CloudHSM: | Trường hợp | Lý do | |---|---| | Quy định buộc khoá phải trong HSM độc quyền | KMS là multi-tenant | | Cần API chuẩn PKCS#11, JCE, CNG | ứng dụng cũ dùng các API này | | Offload SSL/TLS, ký mã, dựng PKI riêng | HSM có hiệu năng mật mã cao |

Và có cách kết hợp cả hai: KMS custom key store.

KMS custom key store backed by CloudHSM:
    ✓ dùng giao diện tiện lợi và tích hợp rộng của KMS
    ✓ nhưng vật liệu khoá nằm trong CloudHSM của bạn
    → kết hợp ưu điểm hai bên

Ba loại người dùng trong CloudHSM: | Vai | Quyền | Ngưỡng zeroize | |---|---|---| | PRECO | người dùng ban đầu, chỉ để kích hoạt | — | | CO (Crypto Officer) | quản lý người dùng và cụm | 3 lần đăng nhập sai | | CU (Crypto User) | tạo và dùng khoá | 5 lần sai |

Zeroize nghĩa là HSM TỰ XOÁ SẠCH khoá khi phát hiện nhiều lần đăng nhập thất bại — đó là tính năng bảo vệ, và cũng là rủi ro vận hành nghiêm trọng.

Bốn thực hành bắt buộc khi vận hành CloudHSM: | Thực hành | Lý do | |---|---| | Sao lưu khoá ra ngoài, cất nơi an toàn | mất khoá là mất vĩnh viễn | | Ghi lại thông tin đăng nhập CO cẩn thận | 3 lần sai là xoá sạch | | Dùng ÍT NHẤT HAI HSM ở HAI AZ | một HSM là điểm hỏng đơn | | Sao chép backup sang Region khác | phục hồi thảm hoạ |

aws cloudhsmv2 copy-backup-to-region   --destination-region us-west-2 --backup-id backup-abc123

Ba loại khoá trong KMS — để so sánh: | Loại | Chi phí | Kiểm soát | |---|---|---| | AWS managed key | miễn phí lưu | không đổi được policy | | Customer managed key | ~1 USD/tháng | đầy đủ: policy, xoay vòng, vô hiệu hoá | | AWS owned key | miễn phí | AWS dùng nội bộ |

Và KMS có nhiều tính năng mà CloudHSM không có sẵn:

✓ Tích hợp một cú nhấp với S3, EBS, RDS, Lambda, Secrets Manager...
✓ Audit trail đầy đủ trong CloudTrail
✓ Xoay khoá tự động hằng năm
✓ Grant và key policy chi tiết
✓ Sao chép khoá đa Region

Ba yêu cầu tuân thủ PCI-DSS mà cả hai đều đáp ứng: | Yêu cầu | Chi tiết | |---|---| | Mã hoá dữ liệu thẻ khi lưu trữ | KMS hoặc CloudHSM | | Quản lý khoá có kiểm soát | key policy hoặc HSM user | | Audit trail | CloudTrail (KMS) hoặc log của HSM |

AWS đã có chứng nhận PCI-DSS cho cả KMS lẫn CloudHSM — nên với phần lớn hệ thống thanh toán, KMS là đủ và rẻ hơn nhiều.

Và một lời khuyên thực tế: hãy bắt đầu với KMS và chỉ chuyển sang CloudHSM khi có yêu cầu cụ thể từ kiểm toán viên hoặc cơ quan quản lý. CloudHSM đắt hơn hàng chục lần, đòi chuyên môn vận hành mật mã, và như tình huống zeroize cho thấy — một sai sót nhỏ có thể mất toàn bộ khoá không cứu được.

Đáp án

D — Tạo một bộ Access Key cho người dùng và gắn các quyền cần thiết.

Vì sao đúng

Đề nêu tình huống rất cụ thể: IAM user vừa tạo bằng AWS CLI với cấu hình mặc định, và cần gọi API tới S3, DynamoDB, Lambda.

Và IAM user mới tạo KHÔNG có gì cả:

aws iam create-user --user-name nguoi-dung-ung-dung
    ↓
Người dùng được tạo với:
    ✗ KHÔNG có access key
    ✗ KHÔNG có mật khẩu console
    ✗ KHÔNG có policy nào gắn vào
    → hoàn toàn không làm được gì

Để gọi API cần HAI thứ, và thiếu một là không được: | Cần | Vì sao | |---|---| | Access key (thông tin đăng nhập) | để KÝ request — không có thì không xác thực được | | Quyền (policy) | để được phép thực hiện hành động |

Và đáp án D bao gồm cả hai — "tạo access key VÀ gắn quyền cần thiết".

aws iam create-access-key --user-name nguoi-dung-ung-dung
aws iam attach-user-policy --user-name nguoi-dung-ung-dung   --policy-arn arn:aws:iam::123456789012:policy/chinh-sach-ung-dung

Vì sao access key là bắt buộc cho lời gọi API:

Mọi request tới AWS API phải được KÝ bằng SigV4
    → cần Access Key ID và Secret Access Key
        ↓
Không có khoá → request không ký được → bị từ chối trước cả bước phân quyền

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

• **C. Gắn IAM Policy cho người dùng để cho phép gửi lời gọi API — đây là phương án gần nhất và là điều kiện CẦN, nhưng nó không đủ: có quyền mà không có access key thì vẫn không ký được request. Đáp án D bao gồm cả hai vế.
• **A. Không cần làm gì, IAM user đã gọi API được — sai: người dùng mới tạo không có thông tin đăng nhập lẫn quyền.
• **B. Bật Multi-Factor Authentication cho người dùng — giải quyết vấn đề khác: MFA thêm một lớp xác thực, nó không cấp thông tin đăng nhập hay quyền nào.

Ghi nhớ

Ba loại thông tin đăng nhập của IAM user: | Loại | Dùng cho | |---|---| | Access key (ID + secret) | AWS CLI, SDK, gọi API | | Mật khẩu console | đăng nhập giao diện web | | Thiết bị MFA | lớp xác thực bổ sung |

Người dùng mới tạo bằng CLI không có cái nào trong ba.

Và AWS khuyến nghị TRÁNH access key dài hạn: | Thay cho | Dùng | |---|---| | Access key trên EC2 | IAM role qua instance profile | | Access key cho Lambda | execution role | | Access key cho ECS task | task role | | Access key cho EKS pod | IRSA | | Access key trong CI/CD | OIDC federation (GitHub Actions, GitLab) | | Access key cho nhân viên | IAM Identity Center với SSO |

Vì sao access key dài hạn rủi ro:

✗ KHÔNG BAO GIỜ hết hạn
✗ Dễ lọt vào Git, log, hoặc image container
✗ Xoay vòng phải làm thủ công
✗ Là nguyên nhân của phần lớn vụ tài khoản AWS bị chiếm dụng

Ba trường hợp access key vẫn cần thiết: | Trường hợp | Ghi chú | |---|---| | Ứng dụng chạy NGOÀI AWS không hỗ trợ OIDC | hệ thống cũ | | Công cụ bên thứ ba chỉ nhận access key | | | Thiết bị IoT không dùng được role | (nên dùng chứng chỉ IoT Core) |

Và nếu buộc phải dùng, hãy áp bốn biện pháp: | Biện pháp | Chi tiết | |---|---| | Quyền tối thiểu | chỉ đúng hành động và tài nguyên cần | | Giới hạn theo IP nguồn | điều kiện aws:SourceIp | | Xoay vòng định kỳ | AWS Config rule access-keys-rotated | | Giám sát bằng GuardDuty | phát hiện dùng từ nơi bất thường |

{"Effect": "Allow",
 "Action": ["s3:GetObject", "dynamodb:GetItem", "lambda:InvokeFunction"],
 "Resource": ["arn:aws:s3:::kho-ung-dung/*",
              "arn:aws:dynamodb:*:*:table/bang-ung-dung",
              "arn:aws:lambda:*:*:function:ham-ung-dung"],
 "Condition": {"IpAddress": {"aws:SourceIp": ["203.0.113.0/24"]}}}

Ba cách gắn quyền cho IAM user: | Cách | Đặc điểm | |---|---| | Gắn policy vào GROUP rồi thêm user vào group | được khuyến nghị — dễ mở rộng | | Gắn policy trực tiếp vào user | khó quản lý khi nhiều người | | Inline policy | gắn chặt với user, khó tái dùng |

Và mỗi IAM user chỉ có tối đa HAI access key:

Giới hạn 2 khoá — có mục đích:
    → cho phép XOAY VÒNG không gián đoạn
    → tạo khoá mới → cập nhật ứng dụng → vô hiệu hoá khoá cũ → xoá

Quy trình xoay vòng an toàn:

# ① Tạo khoá thứ hai
aws iam create-access-key --user-name nguoi-dung-ung-dung
# ② Cập nhật ứng dụng dùng khoá mới
# ③ Vô hiệu hoá khoá cũ (chưa xoá — để quay lui được)
aws iam update-access-key --user-name nguoi-dung-ung-dung   --access-key-id AKIA_CU --status Inactive
# ④ Theo dõi vài ngày, rồi xoá
aws iam delete-access-key --user-name nguoi-dung-ung-dung   --access-key-id AKIA_CU

Ba công cụ theo dõi access key: | Công cụ | Việc | |---|---| | IAM Credential Report | liệt kê mọi khoá, tuổi, lần dùng cuối | | Access Advisor | dịch vụ nào thực sự được dùng gần đây | | AWS Config rule | phát hiện khoá quá hạn xoay vòng |

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d

Và một lời khuyên: nếu người dùng này thực chất là một ứng dụng chạy trên AWS, hãy dùng IAM role thay vì IAM user. Câu hỏi mô tả tình huống dùng access key, nhưng trong thực tế đó gần như luôn là dấu hiệu của một kiến trúc nên được cải thiện.