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

Đáp án

A — Dùng Availability Zone ID (AZ ID) để xác định duy nhất các Availability Zone giữa hai tài khoản AWS.

Vì sao đúng

Đây là một trong những chi tiết hay gây bối rối nhất của AWS: tên AZ được ÁNH XẠ NGẪU NHIÊN theo từng tài khoản.

Tài khoản A: us-west-2a → trung tâm dữ liệu vật lý X
Tài khoản B: us-west-2a → trung tâm dữ liệu vật lý Y
        ↓
    CÙNG TÊN nhưng KHÁC vị trí vật lý

Vì sao AWS làm vậy:

Nếu mọi tài khoản đều ánh xạ us-west-2a về cùng một nơi:
    → mọi người mặc định chọn "a"
    → AZ đó quá tải, các AZ khác nhàn rỗi
        ↓
    Ánh xạ ngẫu nhiên theo tài khoản
    → phân bố tải đều giữa các AZ vật lý

Và AZ ID là định danh THẬT, không đổi giữa các tài khoản:

AZ ID có dạng: usw2-az1, usw2-az2, usw2-az3
    → usw2-az1 ở tài khoản A và tài khoản B
      là CÙNG MỘT trung tâm dữ liệu vật lý

Xem ánh xạ của tài khoản mình:

aws ec2 describe-availability-zones --region us-west-2   --query 'AvailabilityZones[].{Ten:ZoneName,Id:ZoneId}' --output table

Tài khoản A:              Tài khoản B:
us-west-2a → usw2-az2     us-west-2a → usw2-az1
us-west-2b → usw2-az1     us-west-2b → usw2-az3
us-west-2c → usw2-az3     us-west-2c → usw2-az2

Nên để đặt instance vào CÙNG AZ vật lý:

Chọn AZ ID = usw2-az1
    → tài khoản A dùng us-west-2b
    → tài khoản B dùng us-west-2a

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

• **C. Dùng default subnet để xác định AZ giữa hai tài khoản — đây là phương án gần nhất vì subnet có gắn với AZ, nhưng nó không giải quyết vấn đề: default subnet của mỗi tài khoản gắn với tên AZ, mà tên AZ chính là thứ được ánh xạ khác nhau. Nó chỉ lặp lại vấn đề gốc.
• **D. Dùng default VPC — cùng lỗi: VPC là tài nguyên cấp Region, nó không giúp phân biệt AZ vật lý.
• **B. Liên hệ AWS Support để tạo instance cùng AZ — không cần thiết: AZ ID đã có sẵn trong API và console, đây là thông tin công khai.

Ghi nhớ

Tên AZ và AZ ID — bảng phải thuộc: | | Tên AZ (us-west-2a) | AZ ID (usw2-az1) | |---|---|---| | Nhất quán giữa các tài khoản | ❌ ánh xạ NGẪU NHIÊN | ✅ luôn cùng vị trí vật lý | | Dùng khi | trong một tài khoản | phối hợp giữa nhiều tài khoản |

Ba trường hợp phải dùng AZ ID: | Trường hợp | Chi tiết | |---|---| | Đặt tài nguyên cùng AZ vật lý giữa các tài khoản | ← câu này | | VPC sharing qua AWS RAM | RAM hiển thị AZ ID | | Giảm phí truyền chéo AZ | biết chắc tài nguyên cùng AZ |

Điểm thứ ba đáng chú ý về chi phí:

Hai tài khoản, tưởng cùng AZ (đều "us-west-2a"):
    → thực ra ở HAI AZ vật lý khác nhau
    → mọi lưu lượng giữa chúng bị tính phí CHÉO AZ
    → và độ trễ cao hơn dự kiến

Ba nơi AZ ID xuất hiện: | Nơi | Chi tiết | |---|---| | describe-availability-zones | trường ZoneId | | AWS RAM khi chia sẻ subnet | hiển thị AZ ID | | Console EC2 và VPC | có cột AZ ID |

Ba khái niệm về hạ tầng AWS: | Khái niệm | Chi tiết | |---|---| | Availability Zone | một hoặc nhiều trung tâm dữ liệu, cách ly điện và mạng | | Region | nhóm AZ, thường 3–6 | | Local Zone | mở rộng Region tới thành phố lớn |

Và các AZ trong một Region cách nhau đủ xa để không cùng hỏng, nhưng đủ gần để độ trễ dưới 2ms.

Ba lưu ý về phí truyền dữ liệu chéo AZ: | Lưu ý | Chi tiết | |---|---| | EC2 chéo AZ | ~0,01 USD/GB MỖI CHIỀU | | RDS sao chép trong Region | miễn phí | | EFS chéo AZ | miễn phí |

Ba mẫu kiến trúc quan tâm tới AZ: | Mẫu | Chi tiết | |---|---| | Cluster placement group | PHẢI cùng một AZ | | EBS volume | gắn với MỘT AZ, không chuyển được | | Multi-AZ cho sẵn sàng cao | trải nhiều AZ có chủ đích |

Và EBS gắn với AZ là ràng buộc quan trọng:

Volume ở us-west-2a KHÔNG gắn được vào instance ở us-west-2b
    → muốn chuyển: chụp snapshot rồi tạo volume mới ở AZ đích

Ba lưu ý khi chia sẻ VPC qua RAM: | Lưu ý | Chi tiết | |---|---| | RAM hiển thị AZ ID cho subnet chia sẻ | tránh nhầm lẫn | | Tài khoản tham gia tạo tài nguyên trong subnet đó | AZ vật lý là của chủ VPC | | Không cần lo ánh xạ tên | AZ ID đã rõ ràng |

Ba cách kiểm tra tài nguyên có cùng AZ vật lý không:

# Tài khoản A
aws ec2 describe-instances --instance-ids i-0abc   --query 'Reservations[].Instances[].Placement.AvailabilityZone'

# Đối chiếu tên AZ với AZ ID
aws ec2 describe-availability-zones   --query 'AvailabilityZones[?ZoneName==`us-west-2a`].ZoneId'

Ba lưu ý khi tự động hoá hạ tầng nhiều tài khoản: | Lưu ý | Chi tiết | |---|---| | Dùng AZ ID trong template CloudFormation dùng chung | không dùng tên AZ cứng | | Tra AZ ID lúc chạy | không giả định ánh xạ | | Ghi tài liệu ánh xạ của từng tài khoản | tiết kiệm thời gian gỡ lỗi |

Và AWS Organizations không đồng nhất hoá ánh xạ AZ — mỗi tài khoản vẫn có ánh xạ riêng, kể cả trong cùng một tổ chức.

Và một lời khuyên: hãy luôn dùng AZ ID khi tài liệu hoá kiến trúc nhiều tài khoản. Viết "đặt ở us-west-2a" trong tài liệu là vô nghĩa với người đọc ở tài khoản khác — và đó là loại hiểu nhầm dẫn tới hoá đơn truyền dữ liệu chéo AZ mà không ai giải thích được.

Đáp án

*B — Dùng một bucket S3 duy nhất và mã hoá bằng SSE-S3

Vì sao đúng

Đây là điểm ít người biết nhưng rất đáng nhớ về SSE-S3:

SSE-S3 mã hoá MỖI ĐỐI TƯỢNG bằng một khoá riêng biệt, rồi mã hoá chính khoá đó bằng một khoá gốc mà AWS thường xuyên xoay vòng.

Nghĩa là yêu cầu "mỗi tệp một khoá khác nhau" đã được đáp ứng tự động, không cần bạn làm gì — và đó chính là phần "không thêm gánh nặng chia dữ liệu thành nhóm logic" mà đề nhấn mạnh.

Bạn đổ tất cả vào một bucket, bật SSE-S3, và mỗi tệp có khoá riêng.

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

• C. Dùng SSE-KMS kèm encryption context để sinh khoá khác nhau cho mỗi tệp — hiểu sai vai trò của encryption context: nó là dữ liệu bổ sung để xác thực, gắn vào bản mã và bắt buộc phải khớp khi giải mã. Nó không sinh ra khoá mới. Đây là phương án nhiễu chính, và nghe rất thuyết phục nếu chưa nắm rõ khái niệm.
• A. Chia dữ liệu ra nhiều bucket — chính là việc chia nhóm logic mà đề nói muốn tránh; và SSE-S3 vốn đã cho khoá riêng mỗi đối tượng nên chia bucket chẳng thêm gì.
• D. Dùng Multi-Region key cho mã hoá phía client — Multi-Region key dựng để dùng CÙNG một khoá ở nhiều Region, tức là ngược hẳn mục tiêu "mỗi tệp một khoá".

Đáp án

D — Dùng DynamoDB point-in-time recovery (PITR) để khôi phục bảng về trạng thái ngay trước khi dữ liệu hỏng được ghi vào.

Vì sao đúng

Đề nêu hai yêu cầu, và PITR là cơ chế duy nhất đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Khôi phục về trạng thái NGAY TRƯỚC lúc dữ liệu hỏng | PITR khôi phục về BẤT KỲ GIÂY nào trong 35 ngày | | Loại bỏ dữ liệu hỏng SỚM NHẤT có thể | có sẵn, không cần chuẩn bị trước từng thời điểm |

PITR là gì:

Point-in-time recovery:
    → DynamoDB sao lưu LIÊN TỤC ở nền
    → khôi phục về bất kỳ GIÂY nào trong 35 ngày qua
    → độ chi tiết tới TỪNG GIÂY
        ↓
    Vấn đề xảy ra lúc 14:32:17
    → khôi phục về 14:32:16

Bật PITR:

aws dynamodb update-continuous-backups --table-name bang-nguoi-dung   --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

Khôi phục:

aws dynamodb restore-table-to-point-in-time   --source-table-name bang-nguoi-dung   --target-table-name bang-nguoi-dung-khoi-phuc   --restore-date-time 2026-08-30T14:32:16Z

Lưu ý quan trọng: khôi phục tạo BẢNG MỚI, không ghi đè bảng cũ.

Quy trình đầy đủ:
    ① Khôi phục thành bảng mới
    ② Kiểm chứng dữ liệu đúng
    ③ Chuyển ứng dụng sang bảng mới (hoặc đối chiếu và sửa bảng gốc)
    ④ Xoá bảng cũ nếu không cần

Và vì sao PITR hơn on-demand backup:

On-demand backup:
    → là ẢNH CHỤP tại một thời điểm cụ thể
    → chỉ khôi phục được về CHÍNH thời điểm đó
    → nếu backup gần nhất là 6 giờ trước → mất 6 giờ dữ liệu

PITR:
    → về BẤT KỲ giây nào
    → mất gần như không có dữ liệu nào

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

• **A. Dùng DynamoDB on-demand backup để khôi phục về trạng thái ngay trước lúc dữ liệu hỏng — đây là phương án gần nhất và on-demand backup thực sự khôi phục được, nhưng nó không đạt được "ngay trước lúc hỏng": backup chỉ tồn tại tại các thời điểm bạn đã chụp. Trừ khi tình cờ có backup ngay trước sự cố, bạn sẽ mất toàn bộ dữ liệu giữa lần backup gần nhất và thời điểm hỏng.
• **B. Dùng DynamoDB Streams để khôi phục bảng — sai chức năng: Streams ghi lại luồng thay đổi trong 24 giờ để các dịch vụ khác phản ứng (Lambda, sao chép). Nó không phải cơ chế khôi phục — không có API nào "khôi phục bảng từ Streams".
• **C. Cấu hình bảng thành global table và trỏ ứng dụng sang Region khác — không giúp gì: global table sao chép dữ liệu theo cả hai chiều, nên dữ liệu hỏng sẽ được sao chép sang mọi Region trong vòng vài giây.

Ghi nhớ

Hai cơ chế sao lưu của DynamoDB — bảng phải thuộc: | Cơ chế | Đặc điểm | |---|---| | Point-in-time recovery (PITR) | liên tục, về bất kỳ GIÂY nào trong 35 ngày | | On-demand backup | ảnh chụp tại thời điểm, giữ tới khi xoá |

Bảng so sánh: | | PITR | On-demand backup | |---|---|---| | Độ chi tiết | từng giây | thời điểm chụp | | Thời gian giữ | 35 ngày | không giới hạn | | Ảnh hưởng hiệu năng | không | không | | Phù hợp | lỗi con người, dữ liệu hỏng ← câu này | tuân thủ, lưu trữ dài hạn | | Chi phí | theo dung lượng bảng | theo dung lượng backup |

Hai cơ chế này BỔ SUNG nhau — PITR cho khôi phục gần, backup cho lưu trữ lâu dài.

Ba lưu ý về PITR: | Lưu ý | Chi tiết | |---|---| | Khôi phục tạo BẢNG MỚI | không ghi đè bảng gốc | | Khôi phục mất thời gian | tuỳ dung lượng bảng | | PITR KHÔNG cứu được bảng ĐÃ BỊ XOÁ | nếu không bật deletion protection |

Dòng cuối rất quan trọng:

Xoá bảng:
    → PITR của bảng đó cũng mất theo
        ↓
    → Bật deletion protection cho mọi bảng sản xuất

aws dynamodb update-table --table-name bang-nguoi-dung   --deletion-protection-enabled

Ba cơ chế bảo vệ dữ liệu DynamoDB: | Cơ chế | Chống lại | |---|---| | PITR | lỗi con người, ứng dụng ghi sai | | On-demand backup | lưu trữ dài hạn, tuân thủ | | Deletion protection | xoá bảng nhầm | | AWS Backup | quản lý tập trung nhiều dịch vụ |

Ba việc DynamoDB Streams thực sự dùng để làm: | Việc | Chi tiết | |---|---| | Kích hoạt Lambda khi dữ liệu đổi | xử lý sự kiện | | Sao chép sang hệ thống khác | OpenSearch, kho phân tích | | Nền tảng của Global Tables | sao chép giữa Region |

Bốn chế độ view của Streams: | Chế độ | Trả về | |---|---| | KEYS_ONLY | chỉ khoá | | NEW_IMAGE | item sau khi đổi | | OLD_IMAGE | item TRƯỚC khi đổi | | NEW_AND_OLD_IMAGES | cả hai — hữu ích nhất |

Và Streams CÓ THỂ dùng để xây cơ chế khôi phục thủ công:

NEW_AND_OLD_IMAGES → Lambda → ghi bản cũ vào S3
    ↓
    Có nhật ký mọi thay đổi
    → dựng lại được trạng thái tại bất kỳ thời điểm nào

Nhưng đó là tự xây, tốn công, và PITR làm sẵn tốt hơn.

Ba lưu ý về Global Tables: | Lưu ý | Chi tiết | |---|---| | Đa ghi thật (multi-active) | mọi Region ghi được | | Sao chép trong vòng giây | | | KHÔNG bảo vệ khỏi dữ liệu hỏng | lỗi được sao chép đi khắp nơi ← điểm của phương án C |

Ba biện pháp phòng ngừa dữ liệu hỏng: | Biện pháp | Chi tiết | |---|---| | Kiểm tra dữ liệu ở tầng ứng dụng | trước khi ghi | | Dùng condition expression | chặn ghi không hợp lệ ở tầng database | | Bật PITR | lưới an toàn |

Condition expression rất hữu ích:

bang.put_item(
    Item=du_lieu,
    ConditionExpression='attribute_not_exists(ma) OR phien_ban < :v',
    ExpressionAttributeValues={':v': phien_ban_moi})

Nó ngăn ghi đè bằng dữ liệu cũ hơn — một nguồn "dữ liệu hỏng" phổ biến.

Ba lưu ý về chi phí PITR: | Lưu ý | Chi tiết | |---|---| | Tính theo dung lượng bảng | ~0,20 USD/GB-tháng | | Khôi phục tính riêng | theo dung lượng khôi phục | | Rẻ so với giá trị bảo vệ | nên bật cho mọi bảng sản xuất |

Ba việc nên làm ngay: | Việc | Chi tiết | |---|---| | Bật PITR cho mọi bảng sản xuất | | | Bật deletion protection | | | Tìm nguyên nhân gốc của việc ghi dữ liệu hỏng | khôi phục chỉ chữa triệu chứng |

Và một lời khuyên: hãy thử khôi phục một lần trong môi trường thử nghiệm để biết quy trình mất bao lâu với dung lượng bảng thật. Với bảng lớn, thời gian khôi phục có thể tính bằng giờ — và biết con số đó trước khi cần dùng giúp bạn quyết định đúng giữa việc khôi phục toàn bảng và việc sửa từng bản ghi hỏng.

Đáp án

D — Tạo alias record cho covid19survey.com trỏ tới www.covid19survey.com.

Vì sao đúng

Điểm mấu chốt: covid19survey.com là ĐỈNH TÊN MIỀN (apex/zone apex), và CNAME không dùng được ở đỉnh.

Chuẩn DNS (RFC 1034):
    Một tên có bản ghi CNAME
    → KHÔNG được có bản ghi loại khác
        ↓
    Nhưng đỉnh tên miền BẮT BUỘC có NS và SOA
    → nên KHÔNG THỂ có CNAME ở đỉnh

Và alias record của Route 53 giải quyết đúng hạn chế đó:

Alias record:
    → là tính năng RIÊNG của Route 53
    → hoạt động như CNAME nhưng DÙNG ĐƯỢC ở đỉnh
    → trả về trực tiếp bản ghi A của đích

Và alias trỏ tới bản ghi khác trong CÙNG hosted zone là trường hợp được hỗ trợ:

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"covid19survey.com","Type":"A",
    "AliasTarget":{"HostedZoneId":"Z123",
                   "DNSName":"www.covid19survey.com",
                   "EvaluateTargetHealth":false}}}]}'

HostedZoneId ở đây là chính hosted zone của bạn — vì đích là bản ghi trong cùng zone.

Và vế "TIẾT KIỆM NHẤT" cũng nghiêng về alias: | Loại | Chi phí truy vấn | |---|---| | Alias tới tài nguyên AWS hoặc bản ghi cùng zone | MIỄN PHÍ | | CNAME | tính phí ~0,40 USD/triệu truy vấn |

Nên alias vừa là lựa chọn duy nhất khả thi, vừa rẻ hơn.

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

• **B. Tạo CNAME record cho covid19survey.com trỏ tới www.covid19survey.com — đây là phương án gần nhất và là bẫy chính: CNAME đúng là cách trỏ tên miền sang tên miền khác, nhưng nó KHÔNG dùng được ở đỉnh tên miền. Route 53 sẽ từ chối tạo bản ghi này.
• **A. Tạo bản ghi MX — sai loại hoàn toàn: MX chỉ định máy chủ thư điện tử cho tên miền, không liên quan tới việc định tuyến lưu lượng web.
• **C. Tạo bản ghi NS — sai mục đích: NS khai máy chủ tên có thẩm quyền cho một zone, dùng để uỷ quyền tên miền con sang hệ thống DNS khác.

Ghi nhớ

Quy tắc vàng về đỉnh tên miền:

Đỉnh tên miền (example.com):
    ❌ KHÔNG dùng được CNAME
    ✅ dùng alias record của Route 53

Tên miền phụ (www.example.com):
    ✅ dùng được CẢ CNAME LẪN alias

CNAME và Alias — bảng phân biệt cốt lõi: | | CNAME | Alias | |---|---|---| | Dùng ở ĐỈNH | ❌ | ✅ | | Trỏ tới tên miền BÊN NGOÀI | ✅ | ❌ | | Chi phí truy vấn | tính phí | MIỄN PHÍ (tài nguyên AWS hoặc cùng zone) | | Chuẩn DNS | ✅ | ❌ riêng Route 53 | | Kiểm tra sức khoẻ đích | ❌ | ✅ EvaluateTargetHealth | | Khai TTL | ✅ | ❌ dùng TTL của đích |

Các đích mà alias record hỗ trợ: | Đích | Hỗ trợ | |---|---| | CloudFront distribution | ✅ | | ALB / NLB | ✅ | | S3 static website endpoint | ✅ | | API Gateway | ✅ | | Global Accelerator | ✅ | | Elastic Beanstalk | ✅ | | VPC interface endpoint | ✅ | | Bản ghi khác trong CÙNG hosted zone | ✅ ← câu này | | Tên miền bên ngoài | ❌ |

Ba cách xử lý chuyển hướng đỉnh sang www: | Cách | Chi tiết | |---|---| | Alias tới bản ghi www trong cùng zone | đơn giản nhất ← câu này | | S3 bucket cấu hình redirect + alias tới bucket | chuyển hướng HTTP 301 thật | | CloudFront function | linh hoạt nhất |

Khác biệt quan trọng giữa hai cách đầu:

Alias tới bản ghi www:
    → cả hai tên miền phục vụ CÙNG nội dung
    → thanh địa chỉ VẪN hiện covid19survey.com
    → có thể gây vấn đề SEO (nội dung trùng lặp)

S3 redirect bucket:
    → trả về HTTP 301
    → thanh địa chỉ ĐỔI sang www.covid19survey.com
    → tốt hơn cho SEO

Với yêu cầu "route all traffic to www", cách thứ hai chính xác hơn về mặt ngữ nghĩa — nhưng alias là đáp án phù hợp với các phương án cho sẵn và rẻ hơn.

Ba lưu ý khi cấu hình S3 redirect bucket:

aws s3api put-bucket-website --bucket covid19survey.com   --website-configuration '{"RedirectAllRequestsTo":
    {"HostName":"www.covid19survey.com","Protocol":"https"}}'

Các loại bản ghi DNS — bảng cần thuộc: | Loại | Việc | |---|---| | A / AAAA | tên miền → IPv4 / IPv6 | | CNAME | tên miền → tên miền khác (không ở đỉnh) | | Alias | tên miền → tài nguyên AWS hoặc bản ghi cùng zone | | MX | máy chủ thư | | TXT | văn bản (SPF, DKIM, xác minh) | | NS | máy chủ tên của zone | | SOA | thông tin khởi đầu zone | | PTR | phân giải ngược | | CAA | CA nào được cấp chứng chỉ |

Ba lưu ý về chi phí Route 53: | Khoản | Giá tham khảo | |---|---| | Hosted zone | 0,50 USD/tháng | | Truy vấn tiêu chuẩn | ~0,40 USD/triệu | | Truy vấn alias tới tài nguyên AWS | MIỄN PHÍ |

Ba lưu ý về EvaluateTargetHealth: | Lưu ý | Chi tiết | |---|---| | true | Route 53 kiểm tra sức khoẻ đích, không trả về nếu hỏng | | false | luôn trả về | | Hữu ích với | failover routing, nhiều endpoint |

Ba công cụ kiểm tra:

dig covid19survey.com
dig www.covid19survey.com
curl -sI https://covid19survey.com | head -3

Và một lời khuyên: hãy kiểm chứng cả hai tên miền đều phục vụ được nội dung sau khi cấu hình. Với alias trỏ tới bản ghi www, người dùng vào tên miền đỉnh sẽ nhận nội dung nhưng thanh địa chỉ không đổi — và nếu chứng chỉ TLS chỉ cấp cho www, trình duyệt sẽ báo lỗi bảo mật cho ai gõ tên miền không có www.

Đáp án

B — Đặt nội dung tĩnh trên Amazon S3; dùng AWS Lambda với DynamoDB cho phần động; đặt CloudFront phía trước.

Vì sao đúng

Đề nêu ba yêu cầu, và đáp án là lựa chọn duy nhất thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | KHÔNG MÁY CHỦ (serverless) | S3 + Lambda + DynamoDB + CloudFront — không có EC2 nào | | Nội dung TĨNH | S3 | | Nội dung ĐỘNG | Lambda + DynamoDB |

Vì sao phải tách hai loại nội dung:

Nội dung TĨNH (HTML, CSS, JS, ảnh):
    → không đổi giữa các request
    → S3 phục vụ tối ưu, rẻ nhất

Nội dung ĐỘNG (kết quả truy vấn, dữ liệu người dùng):
    → cần thực thi mã
    → Lambda chạy theo request, trả tiền theo mili giây

Kiến trúc đầy đủ:

Người dùng
    ↓
CloudFront (đệm nội dung tĩnh, chuyển tiếp request động)
    ├── /* (tĩnh)     → S3 bucket
    └── /api/* (động) → API Gateway → Lambda → DynamoDB

Và về chi phí, mô hình serverless rất phù hợp với doanh nghiệp nhỏ:

Lambda:     1 triệu request miễn phí mỗi tháng
DynamoDB:   25 GB và 25 WCU/RCU miễn phí (chế độ provisioned)
S3:         5 GB miễn phí năm đầu
CloudFront: 1 TB truyền và 10 triệu request miễn phí mỗi tháng
        ↓
    Ứng dụng nhỏ có thể gần như MIỄN PHÍ
    Và KHÔNG có máy chủ nào chạy không mà vẫn tính tiền

Trong khi EC2 chạy 24/7:

Một t3.small chạy liên tục: ~15 USD/tháng
    → dù không ai truy cập
    → cộng chi phí RDS, cộng công vá lỗi

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

• **A. S3 cho nội dung tĩnh, EC2 với RDS cho nội dung động, CloudFront trước EC2 — đây là phương án gần nhất và kiến trúc hoàn toàn hợp lý, nhưng nó vi phạm yêu cầu serverless: EC2 và RDS đều là máy chủ phải quản lý, vá lỗi và trả tiền 24/7. Đề hỏi rõ giải pháp serverless.
• **D. Đặt CẢ hai loại nội dung trên EC2 với RDS — vi phạm nặng nhất: không có gì serverless, và cũng không tách được nội dung tĩnh ra khỏi máy chủ ứng dụng.
• **C. Đặt CẢ nội dung tĩnh LẪN ĐỘNG trên S3 — không làm được: S3 chỉ phục vụ tệp tĩnh, nó không thực thi mã nên không sinh được nội dung động.

Ghi nhớ

Kiến trúc web serverless chuẩn trên AWS:

Route 53 (DNS)
    ↓
CloudFront (CDN, TLS, WAF)
    ├── nội dung TĨNH  → S3 (với Origin Access Control)
    └── nội dung ĐỘNG  → API Gateway → Lambda → DynamoDB
                                              → RDS/Aurora Serverless (nếu cần SQL)

Bốn thành phần serverless cốt lõi: | Thành phần | Vai trò | |---|---| | Amazon S3 | lưu và phục vụ tệp tĩnh | | AWS Lambda | thực thi logic nghiệp vụ | | Amazon DynamoDB | lưu dữ liệu, không quản lý máy | | API Gateway | endpoint HTTP, xác thực, throttling | | CloudFront | đệm và phân phối toàn cầu |

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

"serverless", "no servers to manage", "cost-effective for small business" → S3 + Lambda + DynamoDB "static content" → S3 "dynamic content, serverless" → Lambda "relational schema required" → Aurora Serverless v2

Ba lợi ích của kiến trúc serverless: | Lợi ích | Chi tiết | |---|---| | Không trả tiền khi không dùng | quan trọng nhất với doanh nghiệp nhỏ | | Tự co giãn | không phải cấu hình ASG | | Không vá lỗi hệ điều hành | AWS lo hết |

Ba giới hạn của Lambda cần biết: | Giới hạn | Giá trị | |---|---| | Thời gian chạy | 15 phút | | Bộ nhớ | 128 MB – 10 GB | | Payload đồng bộ | 6 MB | | Đồng thời mặc định | 1.000 mỗi tài khoản mỗi Region |

Ba cách phơi Lambda ra HTTP: | Cách | Đặc điểm | |---|---| | API Gateway HTTP API | rẻ hơn ~70%, JWT authorizer | | API Gateway REST API | đầy đủ: usage plan, caching, WAF, private | | Lambda Function URL | đơn giản nhất, MIỄN PHÍ, không có tính năng gateway |

Lambda Function URL rất phù hợp với doanh nghiệp nhỏ:

aws lambda create-function-url-config --function-name ham-cua-toi   --auth-type NONE --cors '{"AllowOrigins":["*"]}'

Không có phí API Gateway — chỉ trả tiền Lambda.

Ba cách cấu hình CloudFront cho ứng dụng lai: | Cấu hình | Chi tiết | |---|---| | Nhiều origin | S3 cho tĩnh, API Gateway cho động | | Cache behavior theo đường dẫn | /api/* không đệm, còn lại đệm | | Origin Access Control | khoá bucket S3 lại |

Behavior /api/*:  origin = API Gateway, cache policy = CachingDisabled
Behavior /* :     origin = S3,          cache policy = CachingOptimized

Ba lưu ý về DynamoDB cho ứng dụng nhỏ: | Lưu ý | Chi tiết | |---|---| | Chế độ on-demand | không phải đoán trước dung lượng | | Thiết kế bảng theo mẫu truy vấn | khác hẳn thiết kế quan hệ | | Bật PITR | bảo vệ khỏi lỗi con người |

Và nếu ứng dụng cần lược đồ quan hệ: | Lựa chọn | Đặc điểm | |---|---| | Aurora Serverless v2 | SQL, tự co giãn, tối thiểu 0,5 ACU | | RDS Proxy | gom kết nối cho Lambda | | DynamoDB | NoSQL, rẻ hơn cho tải nhỏ |

Lưu ý: Lambda + database quan hệ cần RDS Proxy — hàng nghìn lượt Lambda đồng thời sẽ cạn kết nối database nếu không có nó.

Ba lưu ý về chi phí serverless: | Lưu ý | Chi tiết | |---|---| | Trả theo lượng dùng | rất rẻ khi tải thấp | | Có thể ĐẮT HƠN EC2 khi tải rất cao và ổn định | tính điểm hoà vốn | | Đặt alarm chi phí | tránh bất ngờ |

Ba công cụ phát triển serverless: | Công cụ | Việc | |---|---| | AWS SAM | framework của AWS, dựa trên CloudFormation | | AWS CDK | định nghĩa hạ tầng bằng ngôn ngữ lập trình | | AWS Amplify | tích hợp CI/CD, phù hợp cho ứng dụng web nhỏ |

Amplify đáng cân nhắc cho doanh nghiệp nhỏ:

Amplify Hosting:
    ✓ nối repo git, tự build và triển khai
    ✓ CDN, TLS, tên miền tuỳ chỉnh dựng sẵn
    ✓ backend serverless tích hợp
        ↓
    Ít công nhất để bắt đầu

Và một lời khuyên cho doanh nghiệp nhỏ mới lên đám mây: hãy bắt đầu với AWS Free Tier và đặt AWS Budget cảnh báo ở mức thấp (ví dụ 20 USD/tháng). Kiến trúc serverless rất rẻ khi tải thấp, nhưng một vòng lặp trong mã hoặc một cấu hình sai có thể sinh chi phí bất ngờ — và cảnh báo sớm rẻ hơn hoá đơn cuối tháng.

Đáp án

B — Instance khởi động từ CẢ Launch Template LT1 LẪN LT2 đều có dedicated instance tenancy.

Vì sao đúng

Có hai quy tắc, và mỗi Launch Template rơi vào một quy tắc:

LT1: VPC là default, launch template khai dedicated:

VPC tenancy = default
    → cho phép instance chọn tenancy riêng
        ↓
    Launch template khai dedicated → instance là DEDICATED

LT2: VPC là dedicated, launch template khai default:

VPC tenancy = dedicated
    → ÉP MỌI instance trong VPC đó thành dedicated
    → BẤT KỂ launch template khai gì
        ↓
    Instance vẫn là DEDICATED

Quy tắc cốt lõi — bảng đầy đủ: | VPC tenancy | Instance tenancy khai | Kết quả | |---|---|---| | default | default | shared | | default | dedicated | dedicated ← LT1 | | dedicated | default | dedicated ← LT2 | | dedicated | dedicated | dedicated |

Nguyên tắc: VPC tenancy dedicated là ràng buộc CỨNG, không vượt qua được.

VPC dedicated:
    → mọi instance đều dedicated
    → KHÔNG có cách nào chạy shared trong đó
        ↓
    Và tenancy của VPC KHÔNG đổi ngược về default được

Kiểm tra tenancy của VPC:

aws ec2 describe-vpcs --vpc-ids vpc-0abc   --query 'Vpcs[].InstanceTenancy'

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

• **A. LT1 cho dedicated, LT2 cho shared — đây là phương án gần nhất và vế LT1 hoàn toàn đúng, nhưng vế LT2 bỏ qua ràng buộc của VPC: VPC V2 có tenancy dedicated, và điều đó ép mọi instance trong đó thành dedicated bất kể launch template khai gì.
• **C. LT1 cho default, LT2 cho dedicated — sai vế LT1: VPC V1 là default nên nó cho phép launch template chọn dedicated, và launch template đã chọn như vậy.
• **D. Cả hai đều cho default — sai cả hai vế.

Ghi nhớ

Ba mô hình thuê phần cứng của EC2 — bảng phải thuộc: | Mô hình | Phần cứng | Thấy máy chủ vật lý | Chi phí | |---|---|---|---| | Shared (mặc định) | dùng chung với khách hàng khác | ❌ | thấp nhất | | Dedicated Instance | CHỈ của bạn | ❌ | trung bình | | Dedicated Host | CHỈ của bạn | ✅ thấy socket và lõi | cao nhất |

Quy tắc kết hợp tenancy — nội dung cốt lõi:

VPC tenancy quyết định TRẦN:
    default   → instance tự chọn (shared hoặc dedicated)
    dedicated → ÉP tất cả thành dedicated

Ba nơi khai instance tenancy: | Nơi | Chi tiết | |---|---| | Lúc tạo VPC | --instance-tenancy default|dedicated | | Trong launch template hoặc launch configuration | Placement.Tenancy | | Lúc chạy instance | --placement Tenancy=dedicated |

Ba lưu ý về tenancy của VPC: | Lưu ý | Chi tiết | |---|---| | KHÔNG đổi từ dedicated về default được | quyết định vĩnh viễn | | Đổi được từ default sang dedicated | nhưng chỉ áp cho instance MỚI | | Nên tách VPC riêng cho tải cần dedicated | tránh ép nhầm |

Dòng đầu là ràng buộc quan trọng nhất:

Tạo VPC với instance-tenancy = dedicated
    → mọi instance trong đó vĩnh viễn là dedicated
    → chi phí cao hơn shared khoảng 10% + phụ phí Region
        ↓
    → Cân nhắc rất kỹ trước khi đặt

Ba lý do dùng dedicated tenancy: | Lý do | Chi tiết | |---|---| | Yêu cầu tuân thủ về phần cứng đơn thuê | HIPAA, PCI-DSS theo chính sách nội bộ | | Giấy phép phần mềm tính theo lõi vật lý | cần Dedicated HOST, không phải Dedicated Instance | | Cách ly theo yêu cầu của khách hàng | |

Khi nào phải dùng Dedicated Host thay vì Dedicated Instance: | Trường hợp | Lý do | |---|---| | BYOL tính theo LÕI hoặc SOCKET vật lý | cần thấy số lõi | | Cần đặt instance lên đúng một máy chủ | host affinity | | Yêu cầu tuân thủ đòi kiểm soát vị trí vật lý | |

Ba khác biệt kỹ thuật: | | Dedicated Instance | Dedicated Host | |---|---|---| | Sau stop/start | có thể sang máy chủ KHÁC | giữ nguyên được (affinity) | | Thấy socket và lõi | ❌ | ✅ | | Dùng cho BYOL | ❌ | ✅ | | Tính phí | phụ phí theo Region | theo máy chủ, theo giờ |

Ba lưu ý về chi phí dedicated: | Lưu ý | Chi tiết | |---|---| | Phụ phí ~2 USD/giờ mỗi Region | tính MỘT LẦN dù chạy bao nhiêu instance | | Giá instance cao hơn ~10% | | | Có RI và Savings Plans cho Dedicated | giảm giá vẫn áp dụng |

Ba lưu ý khi dùng ASG với dedicated tenancy: | Lưu ý | Chi tiết | |---|---| | Khai tenancy trong launch template | không phải trong ASG | | Kiểm tra tenancy của VPC trước | có thể ghi đè khai báo | | Một số loại instance không hỗ trợ dedicated | kiểm tra tài liệu |

Ba loại tài nguyên KHÔNG chạy trên dedicated tenancy:

Một số dịch vụ được quản lý không hỗ trợ VPC dedicated,
hoặc có hành vi khác — kiểm tra tài liệu trước khi đặt
tenancy dedicated ở cấp VPC.

Ba cách kiểm tra tenancy thực tế của instance:

aws ec2 describe-instances --instance-ids i-0abc   --query 'Reservations[].Instances[].Placement.Tenancy'

aws ec2 describe-vpcs --vpc-ids vpc-0abc   --query 'Vpcs[].InstanceTenancy'

aws ec2 describe-launch-template-versions   --launch-template-name lt1 --versions '$Latest'   --query 'LaunchTemplateVersions[].LaunchTemplateData.Placement.Tenancy'

Ba thực hành tốt: | Thực hành | Chi tiết | |---|---| | Tách VPC riêng cho tải cần dedicated | tránh ép nhầm tài nguyên khác | | Ghi tài liệu rõ vì sao cần dedicated | chi phí cao, người sau sẽ hỏi | | Xác nhận yêu cầu tuân thủ thực sự cần | thường mã hoá và cách ly mạng là đủ |

Và một lời khuyên: hãy kiểm tra tenancy của cả VPC lẫn launch template khi chi phí EC2 cao bất thường. Một VPC được đặt dedicated từ lâu và không ai nhớ lý do là nguồn chi phí âm thầm phổ biến — mọi instance trong đó đều đắt hơn khoảng 10% cộng phụ phí Region, và không có gì trong giao diện EC2 nhắc bạn về điều đó.

Đáp án

D — Lưu lượng được định tuyến tới instance bằng địa chỉ IP RIÊNG chính (primary private IP) trên network interface chính của instance.

Vì sao đúng

Điểm mấu chốt: load balancer luôn nói chuyện với target qua IP RIÊNG trong VPC, bất kể instance có IP công cộng hay không.

NLB nằm TRONG VPC
    → nó định tuyến tới target qua mạng nội bộ của VPC
    → dùng IP riêng, không đi ra Internet
        ↓
    Kể cả instance ở public subnet và có IP công cộng,
    NLB vẫn dùng IP RIÊNG

Vì sao thiết kế như vậy: | Lý do | Chi tiết | |---|---| | Hiệu quả | không đi vòng ra Internet rồi quay lại | | Không tốn phí truyền dữ liệu ra Internet | | | Bảo mật | lưu lượng nội bộ không rời VPC |

Và điều này có hệ quả về security group:

Security group của instance phải cho phép:
    → lưu lượng từ DẢI IP RIÊNG của subnet chứa NLB
    → hoặc từ VPC CIDR
        ↓
    KHÔNG phải từ IP công cộng của NLB

Lưu ý đặc biệt của NLB — khác hẳn ALB:

ALB:  security group của target nhận từ SECURITY GROUP của ALB
NLB:  historically KHÔNG có security group
      → phải cho phép theo CIDR

(Từ 2023 NLB hỗ trợ security group, nhưng phải bật lúc tạo và không đổi được sau.)

Ba loại target của NLB: | Loại target | Định tuyến bằng | |---|---| | instance (instance ID) | IP RIÊNG CHÍNH của ENI chính ← câu này | | ip | địa chỉ IP bạn khai | | alb | ALB làm target |

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

• **A. Định tuyến bằng IP CÔNG CỘNG chính trên network interface chính — đây là phương án gần nhất vì instance thực sự nằm ở public subnet và có IP công cộng, nhưng nó sai về cơ chế: NLB nằm trong VPC và định tuyến nội bộ. Dùng IP công cộng sẽ khiến lưu lượng đi ra Internet rồi quay lại — vừa chậm vừa tốn phí.
• **C. Định tuyến bằng Elastic IP chính — cùng lỗi, và Elastic IP là IP công cộng gán thêm, không thay đổi cách NLB định tuyến.
• **B. Định tuyến bằng instance ID — nhầm giữa CÁCH ĐĂNG KÝ và CÁCH ĐỊNH TUYẾN: instance ID là cách bạn khai báo target, nhưng NLB dịch nó ra IP riêng để định tuyến thật.

Ghi nhớ

Ba loại target type — bảng cần thuộc: | Target type | Đăng ký bằng | Dùng khi | |---|---|---| | instance | instance ID | EC2 trong cùng VPC ← câu này | | ip | địa chỉ IP | container, máy tại chỗ, VPC peering | | lambda | ARN của hàm | chỉ ALB, không có ở NLB | | alb | ARN của ALB | NLB đứng trước ALB |

Target type ip rất linh hoạt:

Dùng được cho:
    ✓ IP trong VPC (kể cả từ VPC peering)
    ✓ IP tại chỗ qua Direct Connect hoặc VPN
    ✓ container ECS ở chế độ awsvpc

Và mẫu alb làm target của NLB đáng biết:

NLB (IP tĩnh) → ALB (định tuyến theo nội dung) → EC2
    ↓
    Có IP tĩnh cho tường lửa
    Vẫn giữ được path-based routing của ALB

ALB, NLB và GWLB — bảng phân biệt: | | ALB | NLB | GWLB | |---|---|---|---| | Tầng | 7 (HTTP) | 4 (TCP/UDP/TLS) | 3 (IP) | | Định tuyến theo nội dung | ✅ | ❌ | ❌ | | IP tĩnh | ❌ | ✅ Elastic IP mỗi AZ | — | | Hiệu năng | rất tốt | hàng triệu request/giây, độ trễ cực thấp | — | | Giữ IP nguồn của client | qua X-Forwarded-For | ✅ NGUYÊN BẢN | ✅ | | WAF | ✅ | ❌ | ❌ | | Lambda target | ✅ | ❌ | ❌ |

Đặc điểm giữ IP nguồn của NLB rất đáng chú ý:

NLB với target type "instance":
    → instance thấy IP THẬT của client
    → không cần đọc X-Forwarded-For
        ↓
    Rất hữu ích cho ứng dụng cần biết IP client
    (chống gian lận, giới hạn tần suất, phân tích địa lý)

Nhưng có ngoại lệ quan trọng: | Target type | Giữ IP nguồn | |---|---| | instance | ✅ giữ nguyên | | ip | ❌ thấy IP của NLB (trừ khi bật Proxy Protocol v2) |

Bật Proxy Protocol v2 để giữ IP nguồn với target type ip:

aws elbv2 modify-target-group-attributes --target-group-arn <arn>   --attributes Key=proxy_protocol_v2.enabled,Value=true

Ứng dụng phải hiểu Proxy Protocol để đọc được thông tin này.

Ba lưu ý về security group với NLB: | Lưu ý | Chi tiết | |---|---| | NLB truyền thống KHÔNG có security group | phải cho phép theo CIDR | | Từ 2023 có hỗ trợ security group | phải bật LÚC TẠO, không đổi sau | | Health check đến từ IP riêng của NLB | nhớ cho phép |

Với NLB không có security group, cấu hình instance:

aws ec2 authorize-security-group-ingress --group-id sg-app   --protocol tcp --port 443 --cidr 10.0.0.0/16

Cho phép từ VPC CIDR — vì không tham chiếu được security group của NLB.

Ba đặc điểm hiệu năng của NLB: | Đặc điểm | Chi tiết | |---|---| | Xử lý hàng triệu request/giây | | | Độ trễ rất thấp | ~100 micro giây | | Hỗ trợ TCP, UDP, TLS | ← lý do dùng cho game |

Ba lưu ý về cross-zone load balancing: | | ALB | NLB | |---|---|---| | Mặc định | BẬT | TẮT | | Phí truyền chéo AZ | miễn phí | tính phí khi bật |

Với NLB tắt cross-zone:

Lưu lượng vào node của AZ nào
    → chỉ phân phối tới target TRONG AZ đó
        ↓
    Số target mỗi AZ nên cân bằng

Ba tính năng của NLB đáng biết: | Tính năng | Chi tiết | |---|---| | TLS termination | giảm tải mã hoá cho backend | | Sticky session theo IP nguồn | giữ client ở cùng target | | PrivateLink endpoint service | NLB là bắt buộc để phơi dịch vụ qua PrivateLink |

Ba lưu ý về health check của NLB: | Lưu ý | Chi tiết | |---|---| | Mặc định là TCP | chỉ kiểm tra cổng có mở không | | Nên đổi sang HTTP/HTTPS | kiểm tra ứng dụng thật sự khoẻ | | Interval tối thiểu 10 giây | ít linh hoạt hơn ALB |

Ba lỗi cấu hình phổ biến với NLB: | Lỗi | Triệu chứng | |---|---| | Security group của instance chỉ cho phép IP của ALB cũ | health check thất bại | | Quên cho phép dải IP của NLB cho health check | target luôn unhealthy | | Dùng target type ip mà quên Proxy Protocol | ứng dụng thấy IP của NLB |

Và một lời khuyên khi chẩn đoán: hãy xem describe-target-health để biết lý do target bị đánh giá là không khoẻ mạnh. Với NLB, nguyên nhân phổ biến nhất là security group của instance chưa cho phép dải IP riêng của subnet chứa NLB — và thông báo lỗi chỉ nói "Health checks failed" mà không nói vì sao.

Đáp án

B — Dùng Amazon API Gateway HTTP API với JWT authorizer nguyên bản để xác thực token từ nhà cung cấp OIDC.

Vì sao đúng

Đề nêu bốn yêu cầu, và HTTP API với JWT authorizer thoả cả bốn: | Yêu cầu | Cơ chế | |---|---| | Kiểm tra JWT từ IdP tương thích OIDC | JWT authorizer dựng sẵn | | Phân quyền theo SCOPE | authorizationScopes trên từng route | | Tiết kiệm chi phí | HTTP API rẻ hơn REST API ~70% | | Độ trễ tối thiểu, KHÔNG viết mã xác thực | API Gateway tự kiểm tra, không gọi Lambda |

JWT authorizer làm gì:

Request đến kèm header Authorization: Bearer <JWT>
    ↓
API Gateway TỰ:
    ✓ tải khoá công khai từ endpoint JWKS của IdP
    ✓ kiểm tra CHỮ KÝ của token
    ✓ kiểm tra `iss` (issuer) và `aud` (audience)
    ✓ kiểm tra `exp` (hết hạn)
    ✓ kiểm tra SCOPE có đủ cho route này không
        ↓
    Không có Lambda nào được gọi
    → độ trễ thấp hơn, chi phí thấp hơn

Cấu hình:

aws apigatewayv2 create-authorizer --api-id abc123   --authorizer-type JWT --name xac-thuc-oidc   --identity-source '$request.header.Authorization'   --jwt-configuration Audience=api-cua-toi,Issuer=https://idp.example.com

aws apigatewayv2 create-route --api-id abc123   --route-key 'GET /don-hang'   --authorization-type JWT --authorizer-id xyz   --authorization-scopes 'don-hang:doc'

Và phân quyền theo scope là tính năng dựng sẵn:

Route GET /don-hang       → yêu cầu scope "don-hang:doc"
Route POST /don-hang      → yêu cầu scope "don-hang:ghi"
Route DELETE /don-hang/*  → yêu cầu scope "don-hang:xoa"
    ↓
    Token thiếu scope → 403, không cần mã nào

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

• **C. Dùng REST API với Lambda function tự kiểm tra JWT — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó vi phạm hai yêu cầu: bạn phải VIẾT mã xác thực (tải JWKS, kiểm tra chữ ký, xử lý xoay vòng khoá), và mỗi request tốn thêm một lời gọi Lambda — tăng cả độ trễ lẫn chi phí.
• **D. Dùng WebSocket API với Lambda authorizer — sai loại API: WebSocket dành cho giao tiếp hai chiều lâu dài (chat, thông báo thời gian thực), không phải cho API request–response của microservice. Và vẫn phải viết Lambda authorizer.
• **A. Dựng gRPC backend trên ECS Fargate qua App Runner, xử lý JWT trong container — nhiều công nhất: phải viết logic xác thực trong mỗi dịch vụ, và App Runner không phải cổng API có tính năng phân quyền.

Ghi nhớ

Ba loại API của API Gateway — bảng phân biệt: | | HTTP API | REST API | WebSocket API | |---|---|---|---| | Chi phí | rẻ hơn ~70% | cao hơn | theo thông điệp + phút kết nối | | Độ trễ | thấp hơn | cao hơn | — | | JWT authorizer nguyên bản | ✅ | ❌ | ❌ | | Lambda authorizer | ✅ | ✅ | ✅ | | IAM authorization | ✅ | ✅ | ✅ | | Cognito authorizer | qua JWT | ✅ | — | | Usage plan, API key | ❌ | ✅ | ✅ | | Caching | ❌ | ✅ | — | | AWS WAF | ❌ | ✅ | — | | Private endpoint | ❌ | ✅ | — | | Request validation | hạn chế | ✅ | — |

Quy tắc chọn:

API đơn giản, JWT từ OIDC, ưu tiên chi phí và độ trễ → HTTP API Cần usage plan, caching, WAF, private endpoint → REST API Giao tiếp hai chiều thời gian thực → WebSocket API

Bốn cơ chế xác thực của API Gateway: | Cơ chế | Đặc điểm | |---|---| | JWT authorizer (HTTP API) | kiểm tra token OIDC, KHÔNG cần mã ← câu này | | Lambda authorizer | logic tuỳ ý — linh hoạt nhất nhưng có độ trễ | | IAM authorization | cho principal của AWS, dùng SigV4 | | Cognito user pool authorizer | chỉ REST API |

Ba thành phần JWT mà authorizer kiểm tra: | Thành phần | Kiểm tra gì | |---|---| | Chữ ký | khớp với khoá công khai từ JWKS của issuer | | iss (issuer) | đúng nhà cung cấp đã khai | | aud (audience) | token dành cho API này | | exp (expiration) | chưa hết hạn | | scope hoặc scp | đủ quyền cho route |

Và API Gateway tự tải JWKS:

https://idp.example.com/.well-known/jwks.json
    → API Gateway tự tải và cache
    → tự cập nhật khi IdP xoay vòng khoá
        ↓
    Không phải viết và bảo trì logic này

Ba lưu ý về JWT authorizer: | Lưu ý | Chi tiết | |---|---| | CHỈ có ở HTTP API | REST API không có | | IdP phải hỗ trợ OIDC discovery | có endpoint .well-known | | Không tuỳ chỉnh được logic | cần logic riêng thì dùng Lambda authorizer |

Ba lợi ích về hiệu năng: | Lợi ích | Chi tiết | |---|---| | Không gọi Lambda | tiết kiệm 20–100ms mỗi request | | Không có cold start của authorizer | | | Không trả phí Lambda cho việc xác thực | |

Ước lượng cho 10 triệu request mỗi tháng:

HTTP API + JWT authorizer:
    10 triệu × 1,00 USD/triệu = ~10 USD

REST API + Lambda authorizer:
    10 triệu × 3,50 USD/triệu = 35 USD (API Gateway)
    + ~10 triệu lời gọi Lambda ≈ 2–10 USD
        ↓
    Chênh lệch đáng kể

Ba tính năng khác của HTTP API: | Tính năng | Chi tiết | |---|---| | CORS cấu hình sẵn | không phải viết | | Tích hợp trực tiếp với dịch vụ AWS | SQS, Step Functions, EventBridge | | Auto-deploy | không phải deploy thủ công như REST API |

Ba cách phân quyền chi tiết hơn: | Cách | Chi tiết | |---|---| | authorizationScopes trên route | thô nhưng đủ cho phần lớn trường hợp | | Kiểm tra claim trong mã dịch vụ | phân quyền theo dữ liệu | | Lambda authorizer trả về IAM policy | linh hoạt nhất |

Và claim của JWT được truyền tới backend:

{"requestContext": {"authorizer": {"jwt": {
   "claims": {"sub": "user-123", "email": "a@b.com"},
   "scopes": ["don-hang:doc"]}}}}

Dịch vụ đọc sub để biết người dùng nào, không cần giải mã token lại.

Ba biện pháp bảo vệ bổ sung: | Biện pháp | Chi tiết | |---|---| | Throttling ở mức stage | HTTP API có throttling cơ bản | | CloudWatch alarm cho 4xx và 5xx | phát hiện bất thường | | CloudFront trước API Gateway | thêm WAF và chống DDoS |

Dòng cuối là cách bù cho việc HTTP API không hỗ trợ WAF trực tiếp — đặt CloudFront ở giữa và gắn WAF vào đó.

Ba lưu ý khi chọn IdP: | Lưu ý | Chi tiết | |---|---| | Phải hỗ trợ OIDC discovery | Auth0, Okta, Cognito, Entra ID, Google | | Thời gian sống của token | ngắn thì an toàn hơn | | Cơ chế xoay vòng khoá | API Gateway tự xử lý nếu theo chuẩn |

Và một lời khuyên: hãy kiểm chứng bằng một token thiếu scope sau khi cấu hình. Gọi route yêu cầu don-hang:ghi bằng token chỉ có don-hang:doc — nó phải trả về 403. Đây là loại cấu hình mà việc "gọi được" không chứng minh gì; chỉ việc "bị chặn đúng lúc" mới xác nhận phân quyền thật sự hoạt động.

Đáp án

A, B và D.

• A — Security group GẮN ĐƯỢC vào NAT instance
• B — NAT instance dùng được làm bastion server
• D — NAT instance hỗ trợ port forwarding

Vì sao đúng

Ba đáp án phản ánh cùng một sự thật căn bản: NAT instance là một EC2 instance thông thường.

NAT instance = EC2 chạy AMI có cấu hình NAT
    → có ENI riêng
    → gắn security group được
    → cài phần mềm được
    → SSH vào được
        ↓
    Mọi thứ làm được với EC2 đều làm được với nó

A — security group gắn được:

NAT instance có ENI như mọi EC2
    → gắn security group để kiểm soát lưu lượng

B — dùng làm bastion server:

NAT instance nằm ở PUBLIC subnet, có IP công cộng
    → SSH vào được từ Internet
    → từ đó SSH tiếp vào instance ở private subnet
        ↓
    Chức năng bastion (jump host)

D — hỗ trợ port forwarding:

Cài và cấu hình iptables trên NAT instance
    → chuyển tiếp cổng từ Internet vào máy ở private subnet

iptables -t nat -A PREROUTING -p tcp --dport 8080   -j DNAT --to-destination 10.0.2.50:80

Và NAT gateway thì ngược lại hoàn toàn:

NAT gateway là dịch vụ ĐƯỢC QUẢN LÝ
    → KHÔNG phải instance
    → KHÔNG gắn security group được
    → KHÔNG SSH vào được
    → KHÔNG cấu hình được gì
        ↓
    Đổi lại: AWS lo sẵn sàng cao, băng thông, vá lỗi

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

• **F. Security group gắn được vào NAT gateway — đây là phương án gần nhất và là bẫy chính: nghe rất hợp lý vì NAT gateway có ENI, nhưng AWS KHÔNG cho gắn security group vào NAT gateway. Kiểm soát lưu lượng qua NAT gateway phải làm bằng network ACL của subnet.
• **C. NAT gateway hỗ trợ port forwarding — không hỗ trợ: NAT gateway chỉ làm NAT một chiều cho lưu lượng đi ra. Không cấu hình được gì.
• **E. NAT gateway dùng được làm bastion server — không làm được: nó không phải máy chủ, không đăng nhập vào được.

Ghi nhớ

NAT gateway và NAT instance — bảng phải thuộc: | | NAT gateway | NAT instance | |---|---|---| | Quản lý | AWS quản lý hoàn toàn | BẠN quản lý | | Sẵn sàng cao | ✅ trong AZ, tự dư thừa | ❌ tự dựng | | Băng thông | 5 – 100 Gbps tự co giãn | theo loại instance | | Security group | ❌ KHÔNG gắn được | ✅ gắn được | | Bastion server | ❌ | ✅ | | Port forwarding | ❌ | ✅ | | Vá lỗi | AWS lo | bạn lo | | Chi phí | ~0,045 USD/giờ + 0,045 USD/GB | giá EC2 |

Quy tắc: dùng NAT gateway trừ khi có lý do cụ thể.

AWS khuyến nghị NAT gateway cho mọi trường hợp sản xuất
    → NAT instance là công nghệ cũ
    → chỉ cân nhắc khi cần port forwarding
      hoặc muốn tiết kiệm cực độ ở môi trường nhỏ

Ba cách kiểm soát lưu lượng qua NAT gateway: | Cách | Chi tiết | |---|---| | Network ACL của subnet | cơ chế duy nhất ở tầng mạng | | Security group của INSTANCE nguồn | kiểm soát outbound từ máy | | AWS Network Firewall | lọc sâu hơn, tập trung |

Ba đặc điểm quan trọng của NAT gateway: | Đặc điểm | Chi tiết | |---|---| | Phải đặt ở PUBLIC subnet | cần đường ra Internet Gateway | | Cần Elastic IP | | | Chỉ phục vụ IPv4 | IPv6 dùng egress-only internet gateway |

Và route table của private subnet trỏ vào nó:

aws ec2 create-route --route-table-id rtb-private   --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-0abc

Ba lưu ý về sẵn sàng cao: | Lưu ý | Chi tiết | |---|---| | NAT gateway dư thừa TRONG một AZ | nhưng KHÔNG trải nhiều AZ | | Mỗi AZ nên có NAT gateway RIÊNG | AZ hỏng không kéo theo AZ khác | | Route table riêng cho mỗi AZ | trỏ vào NAT gateway cùng AZ |

Đây là cấu hình đúng cho sản xuất:

Private subnet AZ-a → NAT gateway ở public subnet AZ-a
Private subnet AZ-c → NAT gateway ở public subnet AZ-c
    ↓
    Vừa chịu lỗi, vừa tránh phí truyền chéo AZ

Ba khoản chi phí của NAT gateway: | Khoản | Giá tham khảo | |---|---| | Theo giờ | ~0,045 USD/giờ (~33 USD/tháng) | | Xử lý dữ liệu | ~0,045 USD/GB | | Truyền chéo AZ nếu đặt sai | thêm phí |

Với nhiều VPC, chi phí NAT gateway tích tụ nhanh:

10 VPC × 2 AZ × 33 USD = 660 USD/tháng
    → chỉ riêng phí giờ, chưa tính phí dữ liệu
        ↓
    → Cân nhắc shared services VPC với NAT tập trung

Ba cách giảm chi phí NAT gateway: | Cách | Tiết kiệm | |---|---| | Gateway VPC endpoint cho S3 và DynamoDB | MIỄN PHÍ, tránh hẳn phí NAT | | Interface endpoint cho dịch vụ AWS hay dùng | ECR, SSM, CloudWatch Logs | | NAT tập trung ở shared services VPC | ít NAT gateway hơn |

Gateway endpoint là khoản tiết kiệm dễ nhất:

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc   --service-name com.amazonaws.ap-northeast-1.s3   --route-table-ids rtb-private

Hoàn toàn miễn phí, và lưu lượng tới S3 thường rất lớn.

Ba lựa chọn cho lưu lượng ra Internet: | Lựa chọn | Chi tiết | |---|---| | NAT gateway | IPv4, được quản lý | | Egress-only internet gateway | IPv6, MIỄN PHÍ | | Internet Gateway | cho public subnet, hai chiều |

Ba lưu ý về bastion server: | Lưu ý | Chi tiết | |---|---| | AWS khuyến nghị SSM Session Manager thay bastion | không cần máy nào, không mở cổng 22 | | Bastion phải được vá lỗi và giám sát | là bề mặt tấn công | | Nếu vẫn dùng | giới hạn IP nguồn, bắt buộc MFA |

SSM Session Manager là lựa chọn hiện đại:

aws ssm start-session --target i-0abc

Lợi ích:
    ✓ KHÔNG cần bastion, không cần mở cổng 22
    ✓ không cần IP công cộng
    ✓ ghi log toàn bộ phiên
    ✓ phân quyền bằng IAM

Ba lưu ý nếu vẫn dùng NAT instance: | Lưu ý | Chi tiết | |---|---| | PHẢI tắt source/destination check | nếu không, NAT không hoạt động | | Là điểm hỏng duy nhất | cần script chuyển đổi tự viết | | Băng thông giới hạn theo loại instance | |

aws ec2 modify-instance-attribute --instance-id i-0nat   --no-source-dest-check

Đây là bước bắt buộc và hay bị quên nhất khi dựng NAT instance.

Và một lời khuyên: hãy chuyển sang SSM Session Manager và bỏ hẳn bastion. Nó loại bỏ một máy phải vá lỗi, một cổng phải mở, và một bộ khoá SSH phải quản lý — đồng thời cho bạn nhật ký đầy đủ mọi phiên truy cập, thứ mà bastion truyền thống không có sẵn.

Đáp án

B và E.

• B — File Gateway của AWS Storage Gateway
• E — Amazon FSx for Windows File Server

Vì sao đúng

Đề hỏi dịch vụ nào phục vụ giao thức SMB — và đó là hai dịch vụ này.

E — FSx for Windows File Server:

Chạy Windows Server thật do AWS quản lý
    ✓ SMB nguyên bản (2.0 đến 3.1.1)
    ✓ tích hợp Active Directory
    ✓ ACL của NTFS, shadow copy, quota, DFS
        ↓
    Tương thích Windows ĐẦY ĐỦ — đúng yêu cầu của đề

B — File Gateway cũng phơi ra SMB:

S3 File Gateway hỗ trợ HAI giao thức:
    ✓ NFS (cho Linux)
    ✓ SMB (cho Windows)
        ↓
    Tệp lưu vào S3, phơi ra dưới dạng file share
    Có cache cục bộ cho dữ liệu nóng

Và hai dịch vụ này phục vụ hai kịch bản khác nhau: | Dịch vụ | Kịch bản | |---|---| | FSx for Windows | thay hẳn file server, dữ liệu trên AWS | | File Gateway | mô hình LAI — truy cập từ tại chỗ với cache |

Với công ty muốn "đưa cụm file server RA KHỎI trung tâm dữ liệu", FSx for Windows là đích đến, còn File Gateway là cầu nối trong quá trình chuyển đổi.

Cấu hình File Gateway với SMB:

aws storagegateway create-smb-file-share   --gateway-arn <arn-gateway>   --location-arn arn:aws:s3:::kho-tep   --role <arn-role>   --authentication ActiveDirectory

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

• **D. Amazon EFS — đây là phương án gần nhất và là dịch vụ hệ thống tệp chia sẻ được quản lý, nhưng nó chỉ phục vụ NFS: EFS dành cho Linux, không hỗ trợ SMB, không tích hợp Active Directory. Máy chủ Windows không mount được EFS một cách tự nhiên.
• **C. Amazon S3 — sai mô hình lưu trữ: S3 là kho object qua HTTP API, không phải hệ thống tệp và không nói SMB.
• **A. Amazon EBS — sai loại lưu trữ: EBS là ổ đĩa khối gắn với một instance, không phải kho tệp chia sẻ qua mạng.

Ghi nhớ

Các dịch vụ AWS theo giao thức — bảng phải thuộc: | Giao thức | Dịch vụ | |---|---| | SMB | FSx for Windows, File Gateway, FSx for ONTAP | | NFS | EFS, File Gateway, FSx for Lustre, FSx for ONTAP, FSx for OpenZFS | | iSCSI (khối) | EBS, Volume Gateway, FSx for ONTAP | | Lustre | FSx for Lustre | | HTTP (object) | S3 |

Từ khoá nhận diện:

"SMB", "Windows", "Active Directory" → FSx for Windows hoặc File Gateway "NFS", "Linux", "auto-scaling" → EFS "hybrid, on-premises access with cache" → Storage Gateway "HPC, parallel" → FSx for Lustre

Ba loại Storage Gateway: | Loại | Giao thức | Đích | |---|---|---| | File Gateway (S3) | NFS và SMB | S3 ← câu này | | File Gateway (FSx) | SMB | FSx for Windows | | Volume Gateway | iSCSI | S3 dạng EBS snapshot | | Tape Gateway | iSCSI VTL | S3 Glacier |

Bốn dịch vụ FSx: | Dịch vụ | Giao thức | Đặc trưng | |---|---|---| | FSx for Windows File Server | SMB | DFS, AD, NTFS ACL | | FSx for Lustre | Lustre | HPC, tích hợp S3 | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | đa giao thức | | FSx for OpenZFS | NFS | di chuyển từ ZFS |

FSx for Windows và File Gateway — bảng so sánh: | | FSx for Windows | File Gateway (SMB) | |---|---|---| | Dữ liệu chính ở | AWS (FSx) | S3, cache tại chỗ | | Hiệu năng | cao, như file server thật | phụ thuộc cache | | Tích hợp AD | ✅ đầy đủ | ✅ | | Tính năng Windows (DFS, shadow copy) | ✅ | ❌ | | Truy cập tệp bằng S3 API | ❌ | ✅ mỗi tệp là một object | | Phù hợp | thay hẳn file server | mô hình lai, chuyển đổi dần |

Điểm cuối là lợi ích riêng của File Gateway:

Tệp vừa dùng được qua SMB
    vừa xử lý được bằng Athena, Glue, học máy qua S3 API
        ↓
    Không cần bước chuyển đổi nào

Ba tính năng riêng của FSx for Windows: | Tính năng | Chi tiết | |---|---| | Data deduplication | tiết kiệm 50–60% | | Shadow Copy | người dùng tự khôi phục phiên bản cũ | | DFS Namespaces và Replication | gộp nhiều file system |

Ba yêu cầu triển khai FSx for Windows: | Yêu cầu | Chi tiết | |---|---| | Active Directory | Managed AD hoặc AD tại chỗ | | Subnet trong VPC | hai subnet nếu Multi-AZ | | Cổng SMB (445) và cổng AD | trong security group |

Ba cách di chuyển dữ liệu lên FSx: | Cách | Đặc điểm | |---|---| | AWS DataSync | nhanh, GIỮ ACL và metadata NTFS | | DFS Replication | đồng bộ liên tục hai chiều | | Robocopy | thủ công, khối lượng nhỏ |

Giữ được ACL là điểm quan trọng — công cụ sao chép thường làm mất toàn bộ phân quyền NTFS.

Ba lưu ý về File Gateway: | Lưu ý | Chi tiết | |---|---| | Kích thước CACHE quyết định trải nghiệm | cache nhỏ hơn dữ liệu nóng thì mọi lần đọc phải lấy từ S3 | | Mỗi tệp là một object S3 | lifecycle rule áp trực tiếp | | Tệp đã chuyển sang Glacier KHÔNG đọc qua SMB được | phải restore trước |

Ba metric của File Gateway cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitPercent | thấp nghĩa là cache quá nhỏ | | CachePercentUsed | gần đầy thì cần mở rộng | | UploadBufferPercentUsed | buffer đầy sẽ chặn ghi |

Ba lựa chọn cho công ty dịch vụ tài chính: | Lựa chọn | Phù hợp | |---|---| | FSx for Windows Multi-AZ | thay hẳn cụm file server | | File Gateway | giai đoạn chuyển tiếp | | FSx File Gateway | truy cập FSx từ tại chỗ với cache |

Ba biện pháp bảo mật cho dữ liệu tài chính: | Biện pháp | Chi tiết | |---|---| | Mã hoá at rest bằng KMS | bật lúc tạo | | Mã hoá in transit (SMB 3.0+) | | | Tích hợp AD cho phân quyền | giữ nguyên mô hình quyền hiện có |

Và một lời khuyên: hãy bắt đầu bằng File Gateway để chuyển dần rồi mới chuyển hẳn sang FSx for Windows. Cách đó cho người dùng thời gian thích nghi và cho đội vận hành thời gian phát hiện những phụ thuộc không ai nhớ tới — script cũ, ứng dụng nội bộ trỏ vào đường dẫn UNC cụ thể, hoặc máy in mạng ánh xạ tới thư mục nào đó.