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

Đáp án

D và E.

• D — Dùng Systems Manager Maintenance Windows để lập lịch vá lỗi và tự động gỡ instance khỏi ALB trong lúc cập nhật
• E — Dùng tài liệu Automation AWSEC2-PatchLoadBalancerInstance để quản lý quy trình vá lỗi cho EC2 sau ALB

Vì sao đúng

Đề mô tả một sự cố cụ thể, và nguyên nhân rất rõ: | Dữ kiện | Vấn đề | |---|---| | Vá lỗi bằng Systems Manager | | | Yêu cầu: gỡ instance khỏi vòng phục vụ trong lúc vá | chưa làm được | | Kết quả: lỗi ứng dụng và gián đoạn lưu lượng | ALB vẫn gửi request tới máy đang vá |

Chuyện gì đang xảy ra:

Vá lỗi bắt đầu → dịch vụ khởi động lại → máy tạm thời không trả lời
    → nhưng ALB CHƯA biết
    → vẫn gửi request tới → người dùng nhận lỗi 5xx
        ↓
    Health check của ALB sẽ phát hiện, nhưng SAU vài chu kỳ
    → trong khoảng đó, lưu lượng đã bị mất

AWSEC2-PatchLoadBalancerInstance làm gì:

Đây là tài liệu Automation do AWS cung cấp sẵn:
    1. Gỡ instance khỏi target group (deregister)
    2. Chờ hết deregistration delay (kết nối đang mở được xử lý xong)
    3. Chạy vá lỗi bằng AWS-RunPatchBaseline
    4. Khởi động lại nếu cần
    5. Đăng ký lại vào target group
    6. Chờ health check chuyển sang healthy
        ↓
    Toàn bộ vòng đời, không viết mã nào

Và Maintenance Window là nơi lập lịch nó:

aws ssm create-maintenance-window --name cua-so-va-loi   --schedule "cron(0 2 ? * SUN *)" --duration 4 --cutoff 1   --allow-unassociated-targets

aws ssm register-task-with-maintenance-window   --window-id mw-abc123 --task-type AUTOMATION   --task-arn AWSEC2-PatchLoadBalancerInstance   --max-concurrency 1 --max-errors 0   --targets "Key=WindowTargetIds,Values=<id-target>"

⚠ --max-concurrency 1 là tham số quan trọng nhất:

Vá một máy tại một thời điểm
    → luôn còn máy khác phục vụ
        ↓
    Đặt max-concurrency cao là vá nhiều máy cùng lúc
    → có thể gỡ hết máy khỏi ALB cùng lúc
    → chính là sự cố đề đang mô tả

Ba lợi ích của cặp D + E: | Lợi ích | Chi tiết | |---|---| | Không mất request nào | gỡ trước, vá sau | | Lập lịch vào giờ thấp điểm | | | Không viết mã tự động hoá | AWS cung cấp sẵn |

Và deregistration delay là chi tiết đảm bảo không đứt kết nối:

aws elbv2 modify-target-group-attributes --target-group-arn <arn>   --attributes Key=deregistration_delay.timeout_seconds,Value=60

Gỡ target → ALB ngừng gửi request MỚI
    → nhưng vẫn cho request ĐANG XỬ LÝ hoàn tất
        ↓
    Đây là "connection draining"

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

• **A. Dùng State Manager lập lịch vá và đảm bảo instance được gỡ rồi đăng ký lại — đây là phương án gần nhất vì mô tả đúng luồng công việc mong muốn, nhưng State Manager không làm được điều đó: nó dùng để duy trì một trạng thái cấu hình mong muốn (cài agent, áp cấu hình), không phải để điều phối quy trình nhiều bước có gỡ và đăng ký load balancer. Automation document mới là công cụ đúng.
• **C. Cấu hình ALB health check tự gỡ instance không khoẻ trong lúc vá, dùng Run Command vá thủ công — đây chính là hành vi hiện tại đang gây sự cố: health check là cơ chế phản ứng, nó chỉ gỡ máy SAU KHI máy đã trả lời lỗi. Những request trong khoảng đó đã thất bại.
• **B. Đổi target group từ kiểu IP sang kiểu instance — không liên quan tới vấn đề. Kiểu target ảnh hưởng cách đăng ký target, không ảnh hưởng tới việc có gỡ máy trước khi vá hay không.

Ghi nhớ

Bốn khả năng của Systems Manager hay bị lẫn — bảng phải thuộc: | Khả năng | Việc | |---|---| | Run Command | chạy MỘT lệnh trên nhiều máy, ngay lập tức | | State Manager | DUY TRÌ trạng thái cấu hình mong muốn | | Automation | QUY TRÌNH nhiều bước có logic ← câu này | | Maintenance Windows | LẬP LỊCH cho các việc trên |

Từ khoá nhận diện:

"deregister from LB, patch, re-register" → Automation document "run a script on many instances now" → Run Command "ensure agent is always installed" → State Manager "schedule during off-hours" → Maintenance Window

Ba thành phần của Patch Manager: | Thành phần | Việc | |---|---| | Patch baseline | quy tắc bản vá nào được duyệt | | Patch group | nhóm máy theo tag | | AWS-RunPatchBaseline | tài liệu thực thi việc vá |

Ba tham số của Maintenance Window: | Tham số | Ý nghĩa | |---|---| | duration | cửa sổ dài bao nhiêu giờ | | cutoff | ngừng bắt đầu việc mới trước khi hết bao nhiêu giờ | | schedule | biểu thức cron hoặc rate |

cutoff là tham số hay bị bỏ qua:

duration 4 giờ, cutoff 1 giờ
    → sau 3 giờ, không bắt đầu vá máy mới nữa
    → 1 giờ cuối để việc đang chạy hoàn tất
        ↓
    Không có cutoff: việc bắt đầu lúc 3 giờ 55 phút
    có thể bị cắt giữa chừng

Ba tham số kiểm soát mức độ ảnh hưởng: | Tham số | Việc | |---|---| | max-concurrency | bao nhiêu máy cùng lúc | | max-errors | dừng sau bao nhiêu lỗi | | Deregistration delay | thời gian rút kết nối |

Đặt max-errors 0 là thực hành tốt:

Máy đầu tiên vá lỗi thất bại → dừng ngay
    → không lan ra cả nhóm
        ↓
    Đặt max-errors cao là để một bản vá hỏng
    lan qua toàn bộ đội máy chủ

Ba tài liệu Automation dựng sẵn hữu ích: | Tài liệu | Việc | |---|---| | AWSEC2-PatchLoadBalancerInstance | vá máy sau LB ← câu này | | AWS-RestartEC2Instance | khởi động lại | | AWS-CreateSnapshot | chụp snapshot trước khi thay đổi |

Ba yêu cầu để Systems Manager hoạt động: | Yêu cầu | Chi tiết | |---|---| | SSM Agent cài trên máy | có sẵn trên AMI của Amazon | | Instance profile với AmazonSSMManagedInstanceCore | | | Đường ra tới endpoint SSM | NAT hoặc VPC endpoint |

Ba VPC endpoint cần cho subnet riêng tư: | Endpoint | Vì sao | |---|---| | ssm | API chính | | ssmmessages | Session Manager | | ec2messages | Run Command |

Ba lưu ý về ALB trong lúc bảo trì: | Lưu ý | Chi tiết | |---|---| | Deregistration delay đủ dài cho request dài nhất | | | Health check grace period sau khi đăng ký lại | | | Giữ đủ máy khoẻ để chịu tải | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem lịch sử Automation execution | | | Theo dõi HTTPCode_ELB_5XX_Count trong cửa sổ vá | | | Kiểm tra target group luôn còn máy khoẻ | |

aws ssm describe-automation-executions   --filters Key=DocumentNamePrefix,Values=AWSEC2-PatchLoadBalancerInstance

Và một lời khuyên: hãy theo dõi metric 5xx của ALB trong đúng cửa sổ bảo trì đầu tiên. Một quy trình vá lỗi được cấu hình đúng sẽ để lại đồ thị lỗi hoàn toàn phẳng — và nếu bạn thấy một gợn sóng nhỏ, đó là dấu hiệu deregistration delay chưa đủ dài cho những request lâu nhất của ứng dụng.

Đáp án

A — Thêm một quy tắc Deny vào bảng INBOUND của Network ACL, với số thứ tự nhỏ hơn các quy tắc khác.

Vì sao đúng

Đề nêu ba dữ kiện, và mỗi cái loại bớt một phương án: | Dữ kiện | Ý nghĩa | |---|---| | Lưu lượng độc hại ĐI VÀO | quy tắc phải ở bảng INBOUND | | Từ nhiều IP trong CÙNG một dải CIDR | chặn cả dải | | Cần CHẶN (deny) | chỉ NACL có Deny; security group thì không |

Vế thứ ba là điểm quyết định:

Security Group: CHỈ CÓ quy tắc Allow
    → không có cách nào viết "từ chối dải này"
        ↓
    Muốn chặn phải dùng Network ACL

Đây là lý do loại cả B và D.

Và số thứ tự nhỏ là chi tiết bắt buộc:

NACL đánh giá quy tắc theo THỨ TỰ TĂNG DẦN
    → gặp quy tắc khớp đầu tiên là DỪNG
        ↓
    Nếu quy tắc Deny có số 200
    mà quy tắc Allow 0.0.0.0/0 có số 100
    → Allow khớp trước → Deny KHÔNG BAO GIỜ được xét

Thêm quy tắc:

aws ec2 create-network-acl-entry --network-acl-id acl-abc123   --rule-number 50 --protocol -1   --cidr-block 203.0.113.0/24 --rule-action deny --ingress

Kiểm tra thứ tự hiện có trước khi thêm:

aws ec2 describe-network-acls --network-acl-ids acl-abc123   --query "NetworkAcls[0].Entries[?Egress==\`false\`].[RuleNumber,CidrBlock,RuleAction,Protocol]"   --output table

Ba lợi ích của NACL cho việc này: | Lợi ích | Chi tiết | |---|---| | Chặn ở tầng SUBNET | mọi instance trong subnet được bảo vệ | | Có Deny tường minh | | | Chặn trước khi gói tới instance | |

Vế đầu đáng nhấn mạnh:

Security group áp cho từng ENI
    → thêm instance mới phải nhớ gắn
NACL áp cho cả subnet
    → mọi thứ trong subnet tự động được bảo vệ

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

• **C. Thêm quy tắc Deny vào bảng OUTBOUND của NACL — đây là phương án gần nhất và chỉ sai chiều, nhưng đó là sai điểm cốt lõi: lưu lượng độc hại đi vào hệ thống, nên phải chặn ở chiều inbound. Chặn outbound chỉ ngăn máy của bạn gửi ra dải đó.
• **D. Thêm quy tắc vào bảng inbound của Security Group để từ chối dải CIDR — security group KHÔNG có quy tắc Deny. Nó chỉ có Allow, và mọi thứ không được Allow thì mặc định bị chặn. Không có cú pháp nào để viết điều này.
• **B. Thêm quy tắc vào bảng outbound của Security Group để từ chối — sai cả hai vế: sai chiều và security group không có Deny.

Ghi nhớ

⚠ Security Group và NACL — bảng phải thuộc: | | Security Group | Network ACL | |---|---|---| | Cấp | ENI (instance) | SUBNET | | Trạng thái | STATEFUL | STATELESS | | Quy tắc | CHỈ Allow | Allow VÀ Deny | | Đánh giá | mọi quy tắc (OR) | theo SỐ THỨ TỰ, dừng ở cái khớp đầu | | Nguồn | CIDR hoặc security group | chỉ CIDR | | Áp dụng | phải gắn tường minh | tự động cho cả subnet |

Từ khoá nhận diện:

"DENY a specific IP or CIDR" → Network ACL (security group không làm được) "allow traffic from another security group" → security group "block at subnet level" → NACL "block malicious HTTP requests, SQLi" → AWS WAF

Ba đặc điểm của số thứ tự NACL: | Đặc điểm | Chi tiết | |---|---| | Từ 1 tới 32766 | | | Đánh giá TĂNG DẦN, dừng ở cái khớp đầu tiên | | | Nên để khoảng cách (10, 20, 30...) | dễ chèn sau này |

⚠ NACL là STATELESS — bẫy kinh điển:

Cho phép inbound cổng 443
    → phản hồi đi ra dùng cổng EPHEMERAL (1024-65535)
    → nếu outbound không mở dải đó → kết nối treo
        ↓
    Phải mở CẢ HAI chiều

Dải cổng ephemeral theo hệ điều hành: | Hệ | Dải | |---|---| | Linux hiện đại | 32768-60999 | | Windows | 49152-65535 | | NAT Gateway | 1024-65535 | | An toàn: mở 1024-65535 | |

Quy tắc mặc định của NACL: | NACL | Inbound | Outbound | |---|---|---| | NACL mặc định của VPC | cho phép TẤT CẢ | cho phép tất cả | | NACL tự tạo | TỪ CHỐI tất cả | từ chối tất cả |

Vế thứ hai là bẫy khi tạo NACL mới:

Tạo NACL mới rồi gắn vào subnet
    → mọi lưu lượng bị chặn ngay lập tức
        ↓
    Phải thêm quy tắc Allow TRƯỚC khi gắn

Quy tắc * không xoá được:

Mọi NACL có một quy tắc cuối, số thứ tự là `*`
    → DENY tất cả
    → không sửa, không xoá được
        ↓
    Đây là lưới an toàn cuối cùng

Ba hạn chế của NACL: | Hạn chế | Chi tiết | |---|---| | Chỉ lọc theo IP/CIDR và cổng | không theo tên miền | | Giới hạn 20 quy tắc mỗi NACL (tăng được tới 40) | | | Không phù hợp cho danh sách chặn dài | |

Vế thứ ba quan trọng:

Có hàng trăm IP xấu cần chặn?
    → NACL không đủ chỗ
        ↓
    Dùng AWS WAF với IP set (tới 10.000 địa chỉ)
    → hoặc AWS Network Firewall

Bốn công cụ chặn lưu lượng — bảng chọn nhanh: | Công cụ | Lọc theo | Khi nào | |---|---|---| | Security Group | IP, cổng, SG | cho phép có chọn lọc | | NACL | IP, cổng — có Deny | chặn vài dải CIDR ← câu này | | AWS WAF | HTTP: IP set, địa lý, tần suất, SQLi | web app | | Network Firewall | tên miền, nội dung gói | lọc sâu |

Ba lưu ý khi chặn theo CIDR: | Lưu ý | Chi tiết | |---|---| | Kiểm tra dải có chứa người dùng thật không | | | Ghi lại lý do chặn và ngày | | | Rà soát định kỳ, gỡ quy tắc cũ | |

Vế đầu là rủi ro thật:

Chặn cả một /16 vì vài IP xấu
    → có thể nuốt luôn cả một nhà mạng
    → khách hàng thật bị chặn mà không ai biết
        ↓
    Chặn dải hẹp nhất có thể

Ba công cụ điều tra: | Công cụ | Việc | |---|---| | VPC Flow Logs | xem gói bị REJECT | | GuardDuty | phát hiện IP có tiếng xấu | | Reachability Analyzer | tìm chỗ chặn nhầm |

# Tìm gói bị chặn trong Flow Logs
fields @timestamp, srcAddr, dstPort, action
| filter action = "REJECT"
| stats count() by srcAddr
| sort by count desc

Và một lời khuyên: hãy ghi ngày và lý do vào tên hoặc tài liệu cho mỗi quy tắc Deny bạn thêm. Danh sách NACL rất dễ tích tụ những dải CIDR mà không ai còn nhớ vì sao bị chặn — và khi giới hạn 20 quy tắc đầy lên, bạn sẽ phải đoán xem cái nào còn cần thiết.

Đáp án

D — Chuyển object sang lớp lưu trữ phù hợp bằng cấu hình S3 Lifecycle.

Vì sao đúng

Đề nêu bốn dữ kiện, và lifecycle là công cụ đúng: | Dữ kiện | Cách đáp ứng | |---|---| | Mỗi bucket có object với MẪU TRUY CẬP KHÁC NHAU | lifecycle lọc theo tiền tố hoặc tag | | Hoá đơn S3 tăng vọt | chuyển sang lớp rẻ hơn | | NHANH NHẤT | cấu hình, không viết mã | | Ít công vận hành nhất | AWS tự chạy hằng ngày |

Lifecycle làm gì:

Khai quy tắc theo TUỔI của object
    → AWS tự chuyển lớp lưu trữ mỗi ngày
        ↓
    Không viết mã, không chạy máy nào
    → áp cho cả object hiện có lẫn object mới

Cấu hình:

{"Rules": [
  {"ID": "log-truy-cap-it",
   "Status": "Enabled",
   "Filter": {"Prefix": "log/"},
   "Transitions": [
     {"Days": 30, "StorageClass": "STANDARD_IA"},
     {"Days": 90, "StorageClass": "GLACIER_IR"},
     {"Days": 365, "StorageClass": "DEEP_ARCHIVE"}]},
  {"ID": "bao-cao-giu-lau",
   "Status": "Enabled",
   "Filter": {"Tag": {"Key": "loai", "Value": "bao-cao"}},
   "Transitions": [{"Days": 60, "StorageClass": "STANDARD_IA"}]}]}

aws s3api put-bucket-lifecycle-configuration --bucket kho-tai-chinh   --lifecycle-configuration file://vong-doi.json

Và nếu chưa biết mẫu truy cập — dùng Intelligent-Tiering:

{"Rules": [{"ID":"tu-dong-phan-tang","Status":"Enabled","Filter":{},
  "Transitions":[{"Days":0,"StorageClass":"INTELLIGENT_TIERING"}]}]}

Đề nói "mỗi bucket có object với mẫu truy cập KHÁC NHAU"
    → Intelligent-Tiering tự theo dõi từng object
    → tự chuyển tầng theo thực tế truy cập
        ↓
    Không có phí lấy dữ liệu
    → chỉ có phí giám sát nhỏ mỗi object

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Áp dụng ngay, không cần triển khai gì | | | AWS chạy tự động mỗi ngày | | | Áp cho object hiện có | |

Và một quy tắc nên có ở MỌI bucket:

{"ID":"don-multipart-do","Status":"Enabled","Filter":{},
 "AbortIncompleteMultipartUpload":{"DaysAfterInitiation":7}}

Multipart upload thất bại giữa chừng
    → các phần đã tải lên VẪN TÍNH PHÍ
    → KHÔNG hiện trong danh sách object
        ↓
    Đây là nguồn chi phí ẩn phổ biến nhất của S3
    → và rất có thể là một phần của "sharp increase" trong đề

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

• **B. Dùng Trusted Advisor tự động chuyển object sang lớp tốt nhất — đây là phương án gần nhất vì Trusted Advisor đúng là công cụ tối ưu chi phí, nhưng nó chỉ KHUYẾN NGHỊ, không tự thực hiện thay đổi nào. Nó không di chuyển object.
• **C. Viết Lambda quét bucket và di chuyển object — làm được nhưng viết lại thứ AWS đã có: phải viết mã, xử lý phân trang, xử lý lỗi, chạy định kỳ, và trả phí Lambda. Chậm hơn và nhiều việc hơn hẳn.
• **A. Đưa TẤT CẢ object vào Glacier Instant Retrieval — sai vì bỏ qua chính điều đề nêu: các object có mẫu truy cập khác nhau. Object hay đọc mà nằm ở Glacier IR sẽ phát sinh phí lấy dữ liệu lớn, có thể còn đắt hơn ban đầu. Và Glacier IR có thời gian lưu tối thiểu 90 ngày.

Ghi nhớ

Bảng lớp lưu trữ S3 — phải thuộc: | Lớp | Truy cập | Lưu tối thiểu | Phí lấy dữ liệu | |---|---|---|---| | Standard | tức thì | — | không | | Intelligent-Tiering | tức thì | — | không | | Standard-IA | tức thì | 30 ngày | có | | One Zone-IA | tức thì | 30 ngày | có | | Glacier Instant Retrieval | tức thì | 90 ngày | có (cao hơn) | | Glacier Flexible Retrieval | phút - giờ | 90 ngày | có | | Deep Archive | 12-48 giờ | 180 ngày | có |

Từ khoá nhận diện:

"reduce S3 cost quickly, least overhead" → S3 Lifecycle "unknown or changing access patterns" → Intelligent-Tiering "recommendations only" → Trusted Advisor, Storage Class Analysis

⚠ Ba giới hạn lifecycle phải nhớ: | Giới hạn | Con số | |---|---| | Standard → Standard-IA / One Zone-IA | tối thiểu 30 ngày | | Object < 128 KB | không chuyển sang IA | | Đã ở IA → Glacier | không còn ràng buộc 30 ngày |

Ba tầng của Intelligent-Tiering: | Tầng | Chuyển sau | |---|---| | Frequent Access | mặc định | | Infrequent Access | 30 ngày không truy cập | | Archive Instant Access | 90 ngày | | Archive / Deep Archive (tuỳ chọn) | 90 / 180 ngày |

Ba đặc điểm của Intelligent-Tiering: | Đặc điểm | Chi tiết | |---|---| | KHÔNG có phí lấy dữ liệu | | | Có phí giám sát mỗi object | | | Object < 128 KB luôn ở tầng Frequent | không tính phí giám sát |

Phí giám sát là lý do cân nhắc:

Hàng chục triệu object rất nhỏ
    → phí giám sát cộng lại đáng kể
        ↓
    Với object lớn và ít, Intelligent-Tiering gần như luôn có lợi

Ba công cụ phân tích trước khi quyết định: | Công cụ | Việc | |---|---| | S3 Storage Lens | phân bố tuổi, kích thước, lớp | | S3 Storage Class Analysis | gợi ý thời điểm chuyển tầng | | Cost Explorer | chi phí theo lớp |

Storage Lens là bước đầu tiên nên làm:

aws s3control put-storage-lens-configuration --account-id 123456789012   --config-id cau-hinh-mac-dinh   --storage-lens-configuration file://storage-lens.json

Nó cho biết ngay:
    → bao nhiêu % object là nhỏ hơn 128 KB
    → bao nhiêu dữ liệu chưa từng được đọc lại
    → bao nhiêu phần tải lên dở chưa dọn

Bốn nguyên nhân hoá đơn S3 tăng vọt: | Nguyên nhân | Cách kiểm tra | |---|---| | Phần tải lên dở dang | Storage Lens | | Phiên bản cũ khi bật versioning | | | Phí REQUEST (nhiều object nhỏ) | Cost Explorer theo loại phí | | Phí truyền dữ liệu ra | |

⚠ Ba khoản dễ bị bỏ sót:

Nhiều người chỉ nhìn "dung lượng lưu trữ"
    → nhưng hoá đơn S3 gồm cả:
    → phí request (PUT, GET, LIST)
    → phí truyền dữ liệu ra Internet
    → phí lấy dữ liệu từ lớp lạnh
        ↓
    Đọc Cost Explorer tách theo "usage type" mới thấy đúng

Ba lưu ý với bucket bật versioning: | Lưu ý | Chi tiết | |---|---| | Phiên bản cũ VẪN tính phí | | | NoncurrentVersionTransitions cho bản cũ | | | NoncurrentVersionExpiration để dọn | |

{"NoncurrentVersionTransitions":[{"NoncurrentDays":30,"StorageClass":"STANDARD_IA"}],
 "NoncurrentVersionExpiration":{"NoncurrentDays":90}}

Ba lưu ý về phí chuyển tầng: | Lưu ý | Chi tiết | |---|---| | Tính theo SỐ đối tượng chuyển | | | Hàng triệu object nhỏ = phí đáng kể | | | Tính trước khi áp cho bucket rất lớn | |

Ba cách giảm phí truyền dữ liệu: | Cách | Chi tiết | |---|---| | Đặt CloudFront trước S3 | S3 → CloudFront miễn phí | | VPC endpoint cho truy cập nội bộ | không qua NAT | | Requester Pays cho bên thứ ba tải về | |

Và một lời khuyên: hãy đọc Cost Explorer tách theo "usage type" trước khi đặt quy tắc lifecycle. Rất nhiều hoá đơn S3 tăng vọt không phải vì lưu trữ mà vì phí request hoặc phần tải lên dở dang — và trong hai trường hợp đó, chuyển lớp lưu trữ sẽ không làm hoá đơn giảm được đồng nào.

Đáp án

D — Triển khai DataSync agent tại chỗ, cấu hình task sao chép dữ liệu và nối nó tới một VPC endpoint.

Vì sao đúng

Đề nêu bốn yêu cầu, và DataSync qua VPC endpoint khớp cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Di chuyển LƯỢNG LỚN dữ liệu lên S3 | DataSync là công cụ di chuyển chuyên dụng | | Đã có Direct Connect | VPC endpoint cho lưu lượng đi qua DX | | Dữ liệu phải RIÊNG TƯ | VPC endpoint — không qua Internet | | Được quản lý hoàn toàn, TỰ ĐỘNG và TĂNG TỐC | DataSync lập lịch, song song hoá, kiểm tra toàn vẹn |

Vế thứ ba là điểm phân biệt D và B:

DataSync endpoint kiểu PUBLIC:
    → agent gọi tới địa chỉ công khai của dịch vụ
    → lưu lượng đi qua Internet (hoặc qua public VIF của DX)
        ↓
DataSync endpoint kiểu VPC (interface endpoint):
    → agent gọi tới ENI có IP RIÊNG trong VPC
    → đi qua private VIF của Direct Connect
    → KHÔNG chạm Internet

Tạo interface endpoint cho DataSync:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --vpc-endpoint-type Interface   --service-name com.amazonaws.ap-southeast-1.datasync   --subnet-ids subnet-a --security-group-ids sg-datasync

Kích hoạt agent trỏ vào endpoint đó:

aws datasync create-agent   --activation-key <khoa-kich-hoat>   --agent-name agent-tai-cho   --vpc-endpoint-id vpce-0abc123   --subnet-arns arn:aws:ec2:ap-southeast-1:...:subnet/subnet-a   --security-group-arns arn:aws:ec2:...:security-group/sg-datasync

Tạo task sao chép:

aws datasync create-task   --source-location-arn <arn-nfs-tai-cho>   --destination-location-arn <arn-s3>   --schedule ScheduleExpression="cron(0 2 * * ? *)"   --options '{"VerifyMode":"POINT_IN_TIME_CONSISTENT",
              "PreserveDeletedFiles":"PRESERVE",
              "BytesPerSecond":-1}'

Ba lý do DataSync là "fully managed" và "accelerate": | Lý do | Chi tiết | |---|---| | Giao thức truyền tối ưu riêng của AWS | nhanh hơn rsync nhiều lần | | Song song hoá nhiều luồng tự động | | | Kiểm tra toàn vẹn dữ liệu sau khi chép | |

Và ba việc nó tự lo: | Việc | Chi tiết | |---|---| | Lập lịch chạy định kỳ | | | Chỉ chép phần THAY ĐỔI ở lần sau | | | Báo cáo tệp lỗi | |

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

• **B. Triển khai DataSync agent, cấu hình task và nối nó tới public endpoint — đây là phương án gần nhất và chỉ khác một chữ, nhưng đó là chữ quyết định: public endpoint nghĩa là lưu lượng đi qua địa chỉ công khai, vi phạm yêu cầu "keep the data private". Đề đã có Direct Connect chính là để tránh điều này.
• **A. Dùng Storage Gateway file gateway với cache cục bộ, giữ dữ liệu chính ở S3 — File Gateway dành cho truy cập liên tục có cache, không phải công cụ di chuyển một lượng lớn dữ liệu. Nó không có lập lịch, không có kiểm tra toàn vẹn, và chậm hơn DataSync đáng kể cho việc chép hàng loạt.
• **C. Dùng volume gateway ở chế độ stored và chụp snapshot bằng AWS Backup — sai mục tiêu: dữ liệu sẽ nằm ở dạng snapshot EBS, không phải object S3 dùng được. Và stored mode giữ toàn bộ dữ liệu tại chỗ, không giải quyết việc di chuyển.

Ghi nhớ

⚠ DataSync và Storage Gateway — bảng phải thuộc: | | AWS DataSync | Storage Gateway | |---|---|---| | Mục đích | DI CHUYỂN / đồng bộ dữ liệu | truy cập LIÊN TỤC có cache | | Chạy | theo lịch hoặc một lần | liên tục | | Cache cục bộ | ❌ | ✅ | | Kiểm tra toàn vẹn | ✅ | — | | Tốc độ | nhanh hơn nhiều | |

Từ khoá nhận diện:

"migrate/replicate large data" + "fully managed" + "accelerate" → DataSync "low latency access to recent files" → Storage Gateway File Gateway "petabytes, poor network" → Snowball "keep private" + có DX → VPC endpoint

Ba cách agent kết nối tới AWS: | Cách | Đặc điểm | |---|---| | Public service endpoint | qua Internet | | VPC endpoint (PrivateLink) | riêng tư, qua DX hoặc VPN ← câu này | | FIPS endpoint | tuân thủ FIPS 140-2 |

Ba nguồn và đích DataSync hỗ trợ: | Nguồn | Đích | |---|---| | NFS, SMB tại chỗ | S3, EFS, FSx | | HDFS | | | Object storage tự quản (S3-compatible) | | | S3 sang S3 (giữa vùng, giữa tài khoản) | |

Ba tham số quan trọng của task: | Tham số | Việc | |---|---| | VerifyMode | kiểm tra toàn vẹn | | PreserveDeletedFiles | giữ hay xoá tệp đã bị xoá ở nguồn | | BytesPerSecond | giới hạn băng thông |

Giới hạn băng thông là việc nên làm:

aws datasync update-task --task-arn <arn>   --options '{"BytesPerSecond":104857600}'

100 MB/s
    → không nuốt hết băng thông Direct Connect
    → tải nghiệp vụ khác vẫn chạy được

⚠ Ba chế độ VerifyMode: | Chế độ | Đặc điểm | |---|---| | POINT_IN_TIME_CONSISTENT | kiểm tra TOÀN BỘ sau khi chép — chậm nhất, chắc nhất | | ONLY_FILES_TRANSFERRED | chỉ kiểm tra tệp vừa chép | | NONE | nhanh nhất, không kiểm tra |

Ba tuỳ chọn giữ metadata: | Tuỳ chọn | Việc | |---|---| | SecurityDescriptorCopyFlags | giữ ACL của Windows | | PosixPermissions | giữ quyền POSIX | | Uid / Gid | giữ chủ sở hữu |

Với nguồn SMB, tuỳ chọn đầu là bắt buộc:

Không đặt SecurityDescriptorCopyFlags
    → tệp sang được nhưng MẤT quyền NTFS
        ↓
    Một file share mà ai cũng đọc được — sự cố im lặng

Ba yêu cầu tài nguyên cho agent: | Yêu cầu | Con số tối thiểu | |---|---| | vCPU | 4 | | RAM | 32 GB (cho > 20 triệu tệp) | | Đĩa | 80 GB |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Nhiều tệp nhỏ chậm hơn ít tệp lớn | | | Một agent có giới hạn thông lượng | | | Dùng nhiều task song song trên nhiều thư mục | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí theo GB dữ liệu chuyển | | | Phí VPC endpoint theo giờ và GB | | | Không tính phí data transfer IN vào AWS | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy thử một thư mục nhỏ trước | | | Đọc task report tìm tệp lỗi | | | So số tệp và dung lượng hai bên | |

aws datasync describe-task-execution --task-execution-arn <arn>   --query "[Status,FilesTransferred,BytesTransferred,Result]"

Ba lưu ý về lần chạy tiếp theo: | Lưu ý | Chi tiết | |---|---| | DataSync chỉ chép phần THAY ĐỔI | so sánh metadata | | Lần đầu lâu nhất | | | Lập lịch chạy hằng đêm để giữ đồng bộ | |

Và một lời khuyên: hãy đặt giới hạn băng thông cho task DataSync ngay từ đầu. Nó được thiết kế để chạy nhanh nhất có thể, và với một đường Direct Connect dùng chung, "nhanh nhất có thể" nghĩa là mọi tải nghiệp vụ khác đều chậm lại trong suốt thời gian đồng bộ.

Đáp án

B — Thêm nhiều EBS volume io1 nữa, và dùng lệnh của hệ điều hành tạo một LVM stripe.

Vì sao đúng

Đề nêu ba dữ kiện, và chỉ một phương án vượt qua được rào cản kỹ thuật: | Dữ kiện | Ý nghĩa | |---|---| | Một volume io1 1 TB với 64.000 IOPS | đã ở mức TỐI ĐA của một volume io1 | | Hiệu năng chậm hơn tại chỗ | cần nhiều IOPS hơn nữa | | CSDL Oracle trên EC2 tối ưu bộ nhớ | |

Vế đầu là chìa khoá:

Giới hạn cứng của MỘT volume io1: 64.000 IOPS
    → volume đang chạy đã chạm trần
        ↓
    Không có cách nào tăng IOPS của volume đó nữa
    → phải dùng NHIỀU volume và gộp lại

Đây là lý do loại phương án C.

RAID 0 (striping) hoạt động thế nào:

4 volume io1, mỗi cái 64.000 IOPS
    → LVM stripe gộp thành một volume logic
    → I/O được chia đều cho 4 volume
        ↓
    Tổng IOPS lý thuyết: tới 256.000
    → (giới hạn thực tế phụ thuộc băng thông EBS của instance)

Tạo LVM stripe:

sudo pvcreate /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1
sudo vgcreate vg_oracle /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1
sudo lvcreate -i 4 -I 256 -l 100%FREE -n lv_du_lieu vg_oracle
sudo mkfs.xfs /dev/vg_oracle/lv_du_lieu
sudo mount /dev/vg_oracle/lv_du_lieu /u01

⚠ -i 4 là số stripe, -I 256 là kích thước sọc (KB) — thiếu -i thì LVM chỉ nối tiếp các volume chứ không chia song song, và IOPS không tăng.

⚠ Nhưng phải kiểm tra trần của INSTANCE trước:

Mỗi loại instance có giới hạn băng thông EBS riêng
    → ví dụ một số loại chỉ hỗ trợ 80.000 IOPS tổng
        ↓
    Thêm volume mà instance đã chạm trần
    → không tăng được gì
    → phải chọn loại instance có băng thông EBS cao hơn

Kiểm tra:

aws ec2 describe-instance-types --instance-types r6i.8xlarge   --query "InstanceTypes[0].EbsInfo.EbsOptimizedInfo" --output table

Ba lưu ý khi dùng RAID 0: | Lưu ý | Chi tiết | |---|---| | KHÔNG có dự phòng — mất một volume là mất hết | | | Phải dựa vào sao lưu và Multi-AZ của ứng dụng | | | Snapshot nhiều volume phải nhất quán | |

Vế thứ ba có công cụ giải quyết:

aws ec2 create-snapshots --instance-specification InstanceId=i-abc   --description "Snapshot nhat quan nhieu volume"

`create-snapshots` (số nhiều) chụp MỌI volume của instance
    tại cùng một thời điểm
        ↓
    Chụp từng volume riêng lẻ sẽ cho ra bộ dữ liệu không nhất quán

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

• **C. Tăng volume io1 lên hơn 64.000 IOPS — đây là phương án gần nhất và nghe hợp lý nhất, nhưng nó vượt giới hạn cứng: 64.000 IOPS là mức tối đa của một volume io1. Không có cách nào cấu hình cao hơn. (io2 Block Express đạt tới 256.000, nhưng phương án nói io1.)
• **A. Tăng kích thước volume io1 lên 2 TB — dung lượng không phải nút thắt: io1 cho phép khai IOPS độc lập với dung lượng (tỷ lệ tối đa 50:1). Volume 1 TB đã đủ để khai 64.000 IOPS.
• **D. Đổi sang instance tối ưu lưu trữ mà không đổi volume — instance tối ưu lưu trữ có ổ NVMe cục bộ, nhưng nếu không đổi volume thì dữ liệu vẫn nằm trên chính EBS đó. Băng thông EBS có thể tăng, nhưng volume vẫn bị giới hạn 64.000 IOPS.

Ghi nhớ

⚠ Giới hạn IOPS của EBS — bảng phải thuộc: | Loại | IOPS tối đa mỗi volume | Thông lượng tối đa | |---|---|---| | gp3 | 16.000 | 1.000 MB/s | | gp2 | 16.000 | 250 MB/s | | io1 | 64.000 | 1.000 MB/s | | io2 | 64.000 | 1.000 MB/s | | io2 Block Express | 256.000 | 4.000 MB/s |

Ba cách vượt giới hạn một volume: | Cách | Chi tiết | |---|---| | RAID 0 / LVM stripe nhiều volume | ← câu này | | io2 Block Express | tới 256.000 IOPS một volume | | Instance store NVMe | hàng triệu IOPS nhưng mất dữ liệu khi stop |

io2 Block Express đáng biết:

Cùng giá io2 nhưng hiệu năng cao hơn nhiều
    → và io2 có độ bền gấp 100 LẦN io1 (99,999% vs 99,9%)
        ↓
    Với dự án mới, io2 gần như luôn tốt hơn io1
    → cùng giá, hơn mọi mặt

Từ khoá nhận diện:

"already at 64,000 IOPS on io1" → stripe nhiều volume "millions of IOPS", "data replicated by app" → instance store "single volume, up to 256,000 IOPS" → io2 Block Express

Hai kiểu RAID hay được hỏi: | RAID | Đặc điểm | |---|---| | RAID 0 (striping) | hiệu năng cao nhất, KHÔNG dự phòng | | RAID 1 (mirroring) | dự phòng, KHÔNG tăng hiệu năng ghi |

⚠ AWS KHÔNG khuyến nghị RAID 5 và RAID 6 trên EBS:

RAID 5/6 tốn IOPS cho việc tính parity
    → giảm 20-30% IOPS khả dụng
        ↓
    Và EBS đã có dự phòng ở tầng dưới (trong một AZ)
    → parity là chi phí không mang lại lợi ích tương ứng

Ba lưu ý về EBS-optimized: | Lưu ý | Chi tiết | |---|---| | Hầu hết instance đời mới bật MẶC ĐỊNH | | | Băng thông EBS tách khỏi băng thông mạng | | | Kiểm tra trần của loại instance | |

Ba lưu ý khi chọn instance cho CSDL: | Lưu ý | Chi tiết | |---|---| | Băng thông EBS đủ cho tổng IOPS mong muốn | | | RAM đủ cho buffer cache | | | Cân nhắc họ tối ưu bộ nhớ (r6i, x2idn) | |

Ba metric cần đo trước khi kết luận: | Metric | Ý nghĩa | |---|---| | VolumeReadOps / VolumeWriteOps | IOPS thật đang dùng | | VolumeQueueLength | hàng đợi dài = đang nghẽn I/O | | VolumeTotalReadTime | độ trễ |

VolumeQueueLength là chỉ báo quan trọng nhất:

Queue length liên tục cao
    → I/O đang xếp hàng chờ
    → đây mới là bằng chứng nghẽn ở tầng đĩa
        ↓
    Nếu queue length thấp mà vẫn chậm
    → nút thắt nằm ở chỗ khác (CPU, RAM, truy vấn)

Ba việc nên làm trước khi thêm volume: | Việc | Chi tiết | |---|---| | Đo IOPS thật đang dùng | có thật sự chạm 64.000 không | | Kiểm tra trần EBS của instance | | | Xem lại cấu hình Oracle (SGA, buffer cache) | |

Ba lựa chọn thay thế cho CSDL Oracle: | Lựa chọn | Đặc điểm | |---|---| | RDS for Oracle | được quản lý, bớt việc vận hành | | io2 Block Express | một volume đủ IOPS | | Instance có NVMe cục bộ | nhanh nhất nhưng phải tự lo bền vững |

Ba lưu ý về sao lưu khi dùng RAID: | Lưu ý | Chi tiết | |---|---| | Dùng create-snapshots cho nhiều volume | nhất quán | | Hoặc dừng I/O ngắn khi chụp | | | Kiểm thử khôi phục thật | |

Và một lời khuyên: hãy đo VolumeQueueLength trước khi thêm volume. Nếu hàng đợi I/O không dài, thì nút thắt không nằm ở đĩa — và bạn sẽ trả tiền cho ba volume io1 nữa để phát hiện ra rằng vấn đề thật là một truy vấn thiếu chỉ mục.

Đáp án

A — Dựng một CloudFront distribution với ALB hiện có làm origin, dùng cấu hình cache cho nội dung động để giảm độ trễ cho người dùng toàn cầu.

Vì sao đúng

Đề nêu bốn dữ kiện, và CloudFront khớp cả bốn: | Dữ kiện | Cách đáp ứng | |---|---| | ASG + ALB trong MỘT vùng | giữ nguyên, chỉ thêm CloudFront phía trước | | Nội dung ĐỘNG cho hàng triệu người dùng toàn cầu | CloudFront tăng tốc cả nội dung động | | Cần tối ưu CHI PHÍ | rẻ hơn nhiều so với nhân bản hạ tầng ra nhiều vùng | | Độ trễ thấp toàn cầu | kết nối qua mạng xương sống AWS |

⚠ Hiểu nhầm phổ biến: "CloudFront chỉ dành cho nội dung tĩnh".

CloudFront tăng tốc nội dung ĐỘNG bằng ba cơ chế,
kể cả khi TTL = 0 và không cache gì:

1. Kết nối TCP và TLS kết thúc ở EDGE gần người dùng
   → bắt tay nhanh hơn nhiều (3 vòng thay vì 3 vòng đường dài)

2. Chặng từ edge về origin đi trên MẠNG XƯƠNG SỐNG AWS
   → ổn định hơn Internet công cộng

3. Kết nối edge ↔ origin được TÁI SỬ DỤNG
   → không phải bắt tay lại cho mỗi request
        ↓
    Với người dùng ở xa, riêng ba điều này đã giảm
    độ trễ đáng kể — chưa cần cache gì

Cấu hình cho nội dung động:

aws cloudfront create-distribution --distribution-config '{
  "Origins":{"Quantity":1,"Items":[{"Id":"alb-goc",
    "DomainName":"alb-abc.ap-southeast-1.elb.amazonaws.com",
    "CustomOriginConfig":{"HTTPPort":80,"HTTPSPort":443,
      "OriginProtocolPolicy":"https-only",
      "OriginKeepaliveTimeout":60}}]},
  "DefaultCacheBehavior":{"TargetOriginId":"alb-goc",
    "ViewerProtocolPolicy":"redirect-to-https",
    "CachePolicyId":"4135ea2d-6df8-44a3-9df3-4b5a84be39ad",
    "OriginRequestPolicyId":"216adef6-5c7f-47e4-b989-5492eafa07d3",
    "AllowedMethods":{"Quantity":7,
      "Items":["GET","HEAD","OPTIONS","PUT","POST","PATCH","DELETE"]}},
  "Enabled":true, "Comment":"Tang toc noi dung dong"}'

⚠ Hai policy ID trên là managed policy của AWS: | ID | Tên | |---|---| | 4135ea2d-... | CachingDisabled — không cache | | 216adef6-... | AllViewer — chuyển tiếp mọi header, cookie, query string |

Và vẫn cache được phần cache được:

Ứng dụng gợi ý video có cả nội dung tĩnh:
    → ảnh thumbnail, CSS, JS  → cache TTL dài
    → API gợi ý cá nhân hoá   → không cache
        ↓
    Tạo cache behavior riêng theo đường dẫn

{"CacheBehaviors":{"Quantity":1,"Items":[{
  "PathPattern":"/static/*","TargetOriginId":"alb-goc",
  "CachePolicyId":"658327ea-f89d-4fab-a63d-7e88639e58f6"}]}}

Ba lợi ích về chi phí: | Lợi ích | Chi tiết | |---|---| | Không nhân bản hạ tầng ra nhiều vùng | | | Data transfer ra qua CloudFront rẻ hơn qua ALB | | | Cache phần tĩnh giảm tải cho ASG | |

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

• **B. Dùng AWS Global Accelerator định tuyến tới ALB và EC2 ở vùng gần nhất — đây là phương án gần nhất và thực sự cải thiện độ trễ, nhưng nó không khớp hiện trạng: hệ thống chỉ có một vùng, nên không có gì để "định tuyến tới vùng gần nhất". Và Global Accelerator không cache, nên không giảm được tải hay chi phí như CloudFront.
• **C. Triển khai thêm EC2 và ALB ở nhiều vùng với Route 53 latency-based — cải thiện độ trễ tốt nhất, nhưng đắt nhất và nhiều việc nhất: nhân bản toàn bộ hạ tầng, đồng bộ dữ liệu giữa các vùng, quản lý triển khai ở nhiều nơi. Đề yêu cầu "cost-optimized".
• **D. Chuyển engine gợi ý sang S3 static website hosting — bất khả thi: đây là hệ thống sinh gợi ý cá nhân hoá theo hoạt động người dùng, tức là nội dung động cần mã chạy phía máy chủ. S3 chỉ phục vụ tệp tĩnh.

Ghi nhớ

⚠ CloudFront và Global Accelerator — bảng phải thuộc: | | CloudFront | Global Accelerator | |---|---|---| | Có cache | ✅ | ❌ | | Giao thức | HTTP/HTTPS | TCP và UDP | | IP | thay đổi | 2 IP tĩnh anycast | | Tối ưu cho | web, API, nội dung | non-HTTP, cần IP tĩnh, đa vùng | | Failover đa vùng | origin group | rất nhanh |

Từ khoá nhận diện:

"single Region" + "global users" + "cost-optimized" → CloudFront "multiple Regions" + "deterministic routing" + "static IP" → Global Accelerator "UDP, gaming, VoIP" → Global Accelerator "static website" → S3 + CloudFront

Ba cơ chế CloudFront tăng tốc nội dung động: | Cơ chế | Chi tiết | |---|---| | Kết thúc TLS ở edge | bắt tay ngắn hơn nhiều | | Chặng edge → origin trên mạng AWS | ổn định hơn | | Tái sử dụng kết nối tới origin | keep-alive |

Ba managed cache policy của AWS: | Policy | Dùng cho | |---|---| | CachingOptimized | nội dung tĩnh | | CachingDisabled | nội dung động ← câu này | | CachingOptimizedForUncompressedObjects | tệp đã nén sẵn |

Ba managed origin request policy: | Policy | Chuyển tiếp | |---|---| | AllViewer | mọi header, cookie, query string | | CORS-S3Origin | header CORS | | UserAgentRefererHeaders | chỉ vài header |

⚠ Ba lỗi làm hỏng tỷ lệ cache hit: | Lỗi | Hậu quả | |---|---| | Forward mọi cookie cho đường dẫn tĩnh | mỗi khách một bản cache | | Forward mọi query string | ?utm_source= tách cache | | TTL quá ngắn | |

Với nội dung động thì forward hết là ĐÚNG — nhưng phải tách cache behavior để đường dẫn tĩnh không bị ảnh hưởng.

Ba tính năng nâng cao cho nội dung động: | Tính năng | Việc | |---|---| | Origin Shield | thêm một tầng cache, giảm tải origin | | CloudFront Functions | biến đổi request/response ở edge (rất nhanh) | | Lambda@Edge | logic phức tạp hơn ở edge |

CloudFront Functions rất hợp cho cá nhân hoá nhẹ:

function handler(event) {
    var req = event.request;
    var quocGia = req.headers['cloudfront-viewer-country'];
    req.uri = '/' + (quocGia ? quocGia.value : 'default') + req.uri;
    return req;
}

Chạy ở edge, thời gian dưới 1 ms
    → rẻ hơn Lambda@Edge nhiều lần

Ba header CloudFront thêm vào cho origin: | Header | Nội dung | |---|---| | CloudFront-Viewer-Country | mã quốc gia | | CloudFront-Is-Mobile-Viewer | loại thiết bị | | CloudFront-Viewer-Latitude/Longitude | vị trí gần đúng |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Gắn AWS WAF vào distribution | | | Thêm custom header bí mật để ALB chỉ nhận từ CloudFront | | | ViewerProtocolPolicy: redirect-to-https | |

Vế thứ hai nên làm:

ALB vẫn có tên miền công khai
    → ai biết tên đó có thể bỏ qua CloudFront và WAF
        ↓
    CloudFront thêm header X-Origin-Secret
    → ALB listener rule chỉ chấp nhận request có header đó

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Chọn price class hợp phân bố khách | | | Bật nén Brotli và gzip | | | Data transfer ALB → CloudFront vẫn tính phí | khác S3 |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | phần tĩnh có cache không | | OriginLatency | origin có chậm không | | TotalErrorRate | |

Và một lời khuyên: hãy tách cache behavior cho đường dẫn tĩnh ngay khi dựng distribution. Đặt CachingDisabled cho toàn bộ site là cách nhanh nhất để nội dung động chạy đúng, nhưng nó cũng vứt bỏ luôn cơ hội cache ảnh và JavaScript — phần thường chiếm phần lớn số byte mà người dùng thực sự tải về.

Đáp án

D — Dùng AWS App Runner để container hoá ứng dụng, và để App Runner tự động triển khai và quản lý ứng dụng mà không dùng ECS hay EC2.

Vì sao đúng theo đáp án nguồn

Đề nêu bốn yêu cầu, và lập luận của đáp án là: | Yêu cầu | Cách đáp ứng | |---|---| | Ứng dụng web phục vụ khách hàng | App Runner sinh ra cho ứng dụng web và API | | Tự co giãn theo metric CloudWatch | App Runner tự co giãn theo số request đồng thời | | ÍT công vận hành NHẤT | không cụm, không task definition, không load balancer | | Container hoá | App Runner nhận mã nguồn hoặc ảnh container |

Vì sao App Runner là mức "ít việc nhất":

ECS trên Fargate: phải khai task definition, service,
                  cluster, ALB, target group, security group,
                  chính sách co giãn
        ↓
App Runner:       trỏ vào repo mã nguồn hoặc ảnh ECR
                  → nó tự lo build, triển khai, TLS,
                    load balancing, co giãn, tên miền

Triển khai:

aws apprunner create-service --service-name ung-dung-ho-tro   --source-configuration '{
    "ImageRepository":{
      "ImageIdentifier":"123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/ung-dung:latest",
      "ImageRepositoryType":"ECR",
      "ImageConfiguration":{"Port":"8080"}},
    "AutoDeploymentsEnabled":true}'   --instance-configuration '{"Cpu":"2 vCPU","Memory":"4 GB"}'   --auto-scaling-configuration-arn <arn-cau-hinh-co-gian>

Cấu hình co giãn:

aws apprunner create-auto-scaling-configuration   --auto-scaling-configuration-name cau-hinh-web   --max-concurrency 100 --min-size 2 --max-size 25

⚠ max-concurrency là tham số điều khiển chính:

App Runner co giãn theo SỐ REQUEST ĐỒNG THỜI mỗi instance
    → vượt ngưỡng → thêm instance
    → dưới ngưỡng → bớt instance
        ↓
    Khác với ECS vốn co giãn theo CPU hoặc bộ nhớ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | HTTPS và tên miền tự động | có sẵn chứng chỉ | | Tự build từ mã nguồn nếu muốn | không cần Dockerfile | | Triển khai tự động khi ảnh mới lên ECR | |

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

• **A. Dùng App2Container container hoá rồi triển khai lên ECS trên Fargate bằng CloudFormation — đây là phương án gần nhất và về mặt kỹ thuật là con đường di chuyển chuẩn nhất, nhưng nó nhiều việc hơn: phải quản lý cluster, task definition, service, ALB và template CloudFormation. Đề đòi "LEAST operational overhead".
• **B. App2Container rồi triển khai lên ECS trên EC2 — nhiều việc hơn nữa: cộng thêm việc quản lý cụm EC2, vá lỗi hệ điều hành, và co giãn tầng máy chủ.
• **C. Dùng App Runner để container hoá rồi triển khai lên EKS trên EC2 — mô tả mâu thuẫn: App Runner là dịch vụ chạy ứng dụng, không phải công cụ container hoá để đưa sang EKS. Và EKS trên EC2 là mức công vận hành cao nhất.

Ghi nhớ về chất lượng câu hỏi

Đáp án chọn D và đúng theo tiêu chí "ít công vận hành nhất", nhưng có hai điểm cần nói rõ:

Thứ nhất: App Runner không phải công cụ container hoá.

Đề bài (và phương án C, D) dùng cụm từ
"Use AWS App Runner to CONTAINERIZE the application"
        ↓
    App Runner KHÔNG container hoá ứng dụng
    → nó CHẠY container, hoặc build từ mã nguồn
      với runtime dựng sẵn (Java, Python, Node...)
        ↓
    Công cụ container hoá ứng dụng cũ là AWS App2Container

Thứ hai: ứng dụng chạy trên Windows là chi tiết đáng lưu ý.

Đề nói: "Java Spring Boot trên máy chủ WINDOWS"
    → App Runner CHỈ chạy container Linux
        ↓
    Nhưng Spring Boot là ứng dụng Java — chạy trên JVM
    → đóng gói lại thành container Linux hoàn toàn được
    → chỉ cần lưu ý nếu ứng dụng gọi API riêng của Windows

Nếu ứng dụng thực sự cần Windows container: | Lựa chọn | Hỗ trợ Windows container | |---|---| | App Runner | ❌ | | ECS trên EC2 | ✅ | | EKS trên EC2 | ✅ | | Fargate | ❌ |

Đây là điều đáng nhớ cho thực tế: với ứng dụng Windows không thể chuyển sang Linux, phương án B mới là câu trả lời khả thi.

Ghi nhớ

Bốn mức "được quản lý" cho container — bảng phải thuộc: | Mức | Dịch vụ | Bạn quản lý | |---|---|---| | Cao nhất | AWS App Runner | chỉ ảnh container hoặc mã | | Cao | ECS trên Fargate | task definition, service | | Trung bình | ECS/EKS trên EC2 | cụm + máy chủ | | Thấp | EC2 tự cài Docker | mọi thứ |

Từ khoá nhận diện:

"web app/API" + "least operational overhead" + container → App Runner "need fine control, sidecars, service mesh" → ECS/EKS "containerize a legacy app" → AWS App2Container "Windows containers" → ECS/EKS trên EC2 (App Runner và Fargate không hỗ trợ)

Ba đặc điểm của App Runner: | Đặc điểm | Chi tiết | |---|---| | Chỉ phục vụ HTTP/HTTPS | không phải job hay worker | | Chỉ container Linux | | | Co giãn theo số request đồng thời | |

Ba nguồn triển khai: | Nguồn | Chi tiết | |---|---| | Ảnh trong Amazon ECR | ← câu này | | Repo mã nguồn (GitHub, Bitbucket) | App Runner tự build | | ECR Public | |

Ba tính năng có sẵn: | Tính năng | Chi tiết | |---|---| | HTTPS với chứng chỉ tự động | | | Load balancing tích hợp | | | Triển khai tự động khi có ảnh mới | |

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | VPC connector để gọi tài nguyên trong VPC | RDS, ElastiCache | | Có thể đặt service ở chế độ private | chỉ truy cập trong VPC | | Không có security group cho inbound công khai | |

aws apprunner create-vpc-connector --vpc-connector-name ket-noi-vpc   --subnets subnet-a subnet-b --security-groups sg-app-runner

⚠ Không có VPC connector thì App Runner không gọi được RDS trong subnet riêng tư — đây là bước hay bị quên.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính phí compute theo thời gian XỬ LÝ request | | | Cộng phí bộ nhớ được cấp phát liên tục | | | Có thể tạm dừng service khi không dùng | |

Vế thứ ba hữu ích cho môi trường thử nghiệm:

aws apprunner pause-service --service-arn <arn>

Ba đặc điểm của App2Container: | Đặc điểm | Chi tiết | |---|---| | Phân tích ứng dụng .NET và Java đang chạy | | | Sinh Dockerfile và artifact triển khai | | | Hỗ trợ cả Windows và Linux | |

Ba lưu ý khi di chuyển Spring Boot: | Lưu ý | Chi tiết | |---|---| | Kiểm tra phụ thuộc vào hệ tệp Windows | đường dẫn, dấu \ | | Chuyển cấu hình sang biến môi trường | | | Đưa bí mật vào Secrets Manager | |

Ba việc kiểm chứng sau khi triển khai: | Việc | Cách | |---|---| | Thử tải để xem có co giãn không | | | Kiểm tra gọi được CSDL qua VPC connector | | | Xem log trong CloudWatch | |

Và một lời khuyên: hãy kiểm tra ứng dụng có phụ thuộc gì vào Windows trước khi chọn App Runner. Một ứng dụng Java thuần thì chuyển sang container Linux rất êm, nhưng chỉ cần một chỗ ghi đường dẫn kiểu C:\du-lieu hoặc một lệnh gọi ra PowerShell là cả kế hoạch phải quay về phương án ECS trên EC2.

Đáp án

A — Amazon ElastiCache for Redis.

Vì sao đúng

Đề nêu ba yêu cầu, và chỉ một lựa chọn thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Dữ liệu thời gian thực, cần hiệu năng cao hơn | dữ liệu trong RAM — độ trễ dưới mili giây | | CSDL TRONG BỘ NHỚ (in-memory) | loại RDS (đĩa) | | Hỗ trợ NHÂN BẢN (replication) | loại Memcached |

Vế thứ ba là điểm phân biệt duy nhất giữa A và B:

Memcached: KHÔNG có nhân bản, không có failover
    → mất node là mất dữ liệu trên node đó

Redis: có replica, có Multi-AZ, có tự động failover
    → và có snapshot để khôi phục
        ↓
    Đề nói rõ "supports data replication"
    → câu trả lời chỉ có thể là Redis

Tạo cụm Redis có nhân bản:

aws elasticache create-replication-group   --replication-group-id cum-game   --replication-group-description "Du lieu thoi gian thuc game"   --engine redis --cache-node-type cache.r7g.large   --num-cache-clusters 3 --automatic-failover-enabled   --multi-az-enabled   --transit-encryption-enabled --at-rest-encryption-enabled   --cache-subnet-group-name nhom-subnet-rieng-tu

Và Redis còn có cấu trúc dữ liệu hợp với game: | Cấu trúc | Dùng cho | |---|---| | Sorted set | bảng xếp hạng — thứ hạng tự động | | Hash | hồ sơ người chơi | | List | hàng đợi sự kiện | | Pub/Sub | thông báo thời gian thực |

import redis
r = redis.Redis(host='cum-game.abc.cache.amazonaws.com', port=6379, ssl=True)

r.zadd('bangxephang:mua1', {'nguoichoi_a': 5200, 'nguoichoi_b': 4800})
top10 = r.zrevrange('bangxephang:mua1', 0, 9, withscores=True)
thu_hang = r.zrevrank('bangxephang:mua1', 'nguoichoi_a')

Lấy top 10 và tra thứ hạng đều là O(log N)
    → nhanh hơn nhiều so với ORDER BY trên CSDL quan hệ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Độ trễ dưới mili giây | | | Nhân bản và tự động failover | | | Snapshot để khôi phục | |

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

• **B. ElastiCache for Memcached — đây là phương án gần nhất vì cũng là CSDL trong bộ nhớ, nhưng nó thiếu đúng tính năng đề yêu cầu: Memcached không có nhân bản, không có Multi-AZ, không có snapshot. Mất một node là mất dữ liệu trên node đó vĩnh viễn.
• **C. RDS for MySQL — không phải CSDL trong bộ nhớ: dữ liệu lưu trên đĩa (EBS), độ trễ tính bằng mili giây chứ không phải micro giây. Nó có nhân bản nhưng không đáp ứng vế "in-memory".
• **D. RDS for PostgreSQL — cùng lý do: CSDL quan hệ trên đĩa, không phải in-memory.

Ghi nhớ

⚠ Redis và Memcached — bảng phải thuộc: | | Redis | Memcached | |---|---|---| | Cấu trúc dữ liệu | string, list, set, sorted set, hash, stream | chỉ string | | Nhân bản | ✅ | ❌ | | Multi-AZ, tự động failover | ✅ | ❌ | | Bền vững (snapshot, AOF) | ✅ | ❌ | | Pub/Sub | ✅ | ❌ | | Giao dịch | ✅ | ❌ | | Đa luồng | (Redis 6+ có I/O threads) | ✅ đa luồng gốc | | Phân mảnh (sharding) | cluster mode | ✅ đơn giản |

Từ khoá nhận diện:

"in-memory" + "replication" → Redis "in-memory" + "simplest, multi-threaded, horizontal scale" → Memcached "in-memory" + "durable as a database" → MemoryDB for Redis "cache for DynamoDB" → DAX

⚠ MemoryDB for Redis là dịch vụ thứ ba cần biết: | | ElastiCache for Redis | MemoryDB for Redis | |---|---|---| | Vai trò | CACHE (dữ liệu có thể mất) | CSDL CHÍNH (bền vững) | | Ghi | vào bộ nhớ | ghi vào transaction log đa AZ | | Độ bền | snapshot định kỳ | không mất dữ liệu | | Giá | thấp hơn | cao hơn |

Đề nói "in-memory database that supports data replication"
    → ElastiCache for Redis là đáp án chuẩn của kỳ thi
    → MemoryDB là lựa chọn khi dữ liệu KHÔNG ĐƯỢC PHÉP MẤT

Hai chế độ cluster của Redis: | Chế độ | Đặc điểm | |---|---| | Cluster mode disabled | một shard, tới 5 replica — đơn giản | | Cluster mode enabled | nhiều shard, dữ liệu phân mảnh — dữ liệu lớn |

Ba đặc điểm của Multi-AZ: | Đặc điểm | Chi tiết | |---|---| | Replica ở AZ khác | | | Tự động failover khi primary hỏng | | | Thời gian chuyển thường dưới 1 phút | |

Ba lưu ý về bền vững của Redis: | Cơ chế | Chi tiết | |---|---| | Snapshot (RDB) | chụp định kỳ, có thể mất dữ liệu giữa hai lần | | AOF (append-only file) | ghi từng lệnh, bền hơn | | Backup thủ công | giữ lâu dài |

aws elasticache create-snapshot --replication-group-id cum-game   --snapshot-name snapshot-truoc-cap-nhat

Ba chính sách khi hết bộ nhớ (maxmemory-policy): | Chính sách | Hành vi | |---|---| | volatile-lru | đẩy khoá có TTL, ít dùng nhất | | allkeys-lru | đẩy khoá bất kỳ, ít dùng nhất | | noeviction | từ chối ghi mới |

Chọn sai chính sách gây sự cố khó hiểu:

`noeviction` + bộ nhớ đầy
    → mọi lệnh ghi trả về lỗi OOM
    → ứng dụng đọc vẫn chạy → khó chẩn đoán
        ↓
    Với cache thì dùng allkeys-lru
    Với dữ liệu quan trọng thì tăng cỡ node

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | hiệu quả cache | | Evictions | bộ nhớ đầy, đang đẩy dữ liệu ra | | DatabaseMemoryUsagePercentage | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Đặt trong subnet riêng tư | | | Bật mã hoá at rest và in transit | | | Dùng Redis AUTH hoặc IAM authentication | |

⚠ Mã hoá phải bật KHI TẠO — không bật sau được, phải tạo cụm mới.

Ba lựa chọn khác cho dữ liệu thời gian thực: | Lựa chọn | Khi nào | |---|---| | ElastiCache Serverless | không muốn chọn cỡ node | | DynamoDB + DAX | cần bền vững + cache | | Amazon Timestream | dữ liệu chuỗi thời gian |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo giờ mỗi node | replica cũng tính | | Reserved node giảm tới 55% | | | Graviton (r7g) rẻ hơn x86 | |

Và một lời khuyên: hãy đặt alarm trên metric Evictions ngay khi dựng cụm. Với Redis, bộ nhớ đầy không gây lỗi ồn ào — nó chỉ lặng lẽ đẩy dữ liệu cũ ra, và triệu chứng bạn thấy là tỷ lệ trúng cache giảm dần cùng với hiệu năng ứng dụng, không phải một thông báo lỗi nào.

Đáp án

D — Triển khai NAT Gateway trong subnet công khai, và sửa bảng định tuyến của subnet riêng tư để đẩy mọi lưu lượng Internet qua NAT Gateway.

Vì sao đúng

Đề nêu ba yêu cầu, và NAT Gateway khớp cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Máy MySQL ở subnet riêng tư cần GỌI RA Internet | NAT cho lưu lượng đi ra | | BẢO MẬT TỐI ĐA | không ai từ Internet vào được | | Ít công vận hành nhất | NAT Gateway được quản lý hoàn toàn |

NAT Gateway hoạt động thế nào:

Máy ở subnet riêng tư gửi request ra Internet
    → route table trỏ 0.0.0.0/0 tới NAT Gateway
    → NAT dịch địa chỉ nguồn thành IP công khai của nó
    → phản hồi quay về đúng máy
        ↓
    Chiều RA: được
    Chiều VÀO từ Internet: KHÔNG được
    → đây chính là "tối đa bảo mật"

Triển khai:

aws ec2 allocate-address --domain vpc
aws ec2 create-nat-gateway --subnet-id subnet-cong-khai-a   --allocation-id eipalloc-abc123

aws ec2 create-route --route-table-id rtb-rieng-tu   --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-abc123

⚠ NAT Gateway phải nằm trong subnet CÔNG KHAI:

NAT cần đường ra Internet cho chính nó
    → subnet của NAT phải có route 0.0.0.0/0 → Internet Gateway
        ↓
    Đặt NAT trong subnet riêng tư là lỗi kinh điển
    → nó không ra được Internet, và không ai dùng được nó

Bảng định tuyến đúng: | Subnet | Đích | Next hop | |---|---|---| | Công khai | 0.0.0.0/0 | Internet Gateway | | Riêng tư | 0.0.0.0/0 | NAT Gateway |

Ba lợi ích so với NAT instance: | Lợi ích | Chi tiết | |---|---| | AWS quản lý — không vá lỗi, không giám sát | | | Tự co giãn tới 100 Gbps | | | Sẵn sàng cao trong AZ | |

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

• **A. Triển khai NAT instance trong subnet riêng tư — đây là phương án gần nhất vì NAT instance cũng làm được việc NAT, nhưng sai hai chỗ: nó phải nằm trong subnet công khai để ra được Internet, và NAT instance là một EC2 bạn phải tự vá lỗi, tự co giãn, tự lo dự phòng. Đề yêu cầu "minimum operational overhead".
• **B. Tạo Internet Gateway và trỏ route của subnet riêng tư tới nó — phá vỡ tính riêng tư: subnet có route tới IGW thì theo định nghĩa nó là subnet công khai. Và máy CSDL sẽ cần IP công khai để hoạt động, mở đường cho kết nối từ ngoài vào.
• **C. Tạo Virtual Private Gateway và trỏ route Internet tới nó — sai công cụ: VGW là điểm cuối phía AWS cho VPN hoặc Direct Connect, dùng để nối với mạng tại chỗ. Nó không cung cấp đường ra Internet.

Ghi nhớ

⚠ NAT Gateway và NAT Instance — bảng phải thuộc: | | NAT Gateway | NAT Instance | |---|---|---| | Quản lý | AWS | bạn | | Băng thông | tự co giãn tới 100 Gbps | theo loại instance | | Sẵn sàng | cao trong AZ | phải tự dựng | | Security group | không có | có | | Port forwarding | ❌ | ✅ | | Dùng làm bastion | ❌ | ✅ |

Từ khoá nhận diện:

"private subnet needs outbound internet" + "least overhead" → NAT Gateway "connect to on-premises" → Virtual Private Gateway hoặc Transit Gateway "access S3 privately" → VPC gateway endpoint "expose service to internet" → Internet Gateway + ALB

Ba thành phần định tuyến ra Internet: | Thành phần | Việc | |---|---| | Internet Gateway (IGW) | cổng ra Internet của VPC — hai chiều | | NAT Gateway | chỉ chiều RA cho subnet riêng tư | | Egress-only IGW | NAT cho IPv6 |

⚠ Egress-only IGW là câu trả lời cho IPv6:

NAT Gateway chỉ làm việc với IPv4
    → với IPv6, dùng egress-only internet gateway
        ↓
    Vì IPv6 không cần dịch địa chỉ,
    chỉ cần chặn chiều vào

Định nghĩa subnet công khai và riêng tư:

Subnet CÔNG KHAI  = có route 0.0.0.0/0 → Internet Gateway
Subnet RIÊNG TƯ   = KHÔNG có route đó
        ↓
    Không có cờ nào đánh dấu; chỉ là bảng định tuyến

⚠ Ba lưu ý về tính sẵn sàng: | Lưu ý | Chi tiết | |---|---| | NAT Gateway nằm trong MỘT AZ | | | AZ đó hỏng → máy ở AZ khác mất đường ra | | | Đặt một NAT Gateway ở MỖI AZ | |

Kiến trúc đa AZ đúng:

AZ-a: subnet công khai (NAT-a) + subnet riêng tư → route tới NAT-a
AZ-b: subnet công khai (NAT-b) + subnet riêng tư → route tới NAT-b
        ↓
    Mỗi AZ có bảng định tuyến RIÊNG
    → dùng chung một bảng trỏ tới NAT-a là điểm hỏng đơn lẻ

Ba lưu ý về chi phí NAT Gateway: | Khoản | Chi tiết | |---|---| | Phí theo GIỜ | ~0,045 USD/giờ mỗi cái | | Phí theo GB xử lý | thường là khoản lớn hơn | | Nhiều AZ = nhân lên | |

⚠ Cách giảm chi phí NAT hiệu quả nhất:

Dùng VPC endpoint cho các dịch vụ AWS
    → S3 và DynamoDB: gateway endpoint MIỄN PHÍ
    → dịch vụ khác: interface endpoint
        ↓
    Lưu lượng tới dịch vụ AWS không đi qua NAT
    → tiết kiệm phí xử lý GB rất đáng kể

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --service-name com.amazonaws.ap-southeast-1.s3   --vpc-endpoint-type Gateway --route-table-ids rtb-rieng-tu

Ba lưu ý về NAT Gateway: | Lưu ý | Chi tiết | |---|---| | Không có security group | kiểm soát bằng NACL của subnet | | Cần một Elastic IP | | | Hỗ trợ tới 55.000 kết nối đồng thời mỗi đích | |

Vế thứ ba là giới hạn thực tế:

Nhiều máy cùng gọi tới CÙNG MỘT IP đích và cổng
    → có thể chạm giới hạn cổng
    → lỗi ErrorPortAllocation
        ↓
    Theo dõi metric này nếu có tải rất lớn

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | BytesOutToDestination | lượng dữ liệu ra — để tính chi phí | | ErrorPortAllocation | chạm giới hạn cổng | | ActiveConnectionCount | |

Ba lựa chọn thay thế cho NAT: | Lựa chọn | Khi nào | |---|---| | VPC endpoint | chỉ cần gọi dịch vụ AWS | | AWS Network Firewall | cần lọc theo tên miền | | Proxy tự dựng | công vận hành cao |

Ba lưu ý về bảo mật cho tầng CSDL: | Lưu ý | Chi tiết | |---|---| | Không gán IP công khai cho instance CSDL | | | Security group chỉ cho tầng web vào cổng 3306 | | | Siết outbound nếu bảo mật cao | |

Và một lời khuyên: hãy thêm gateway endpoint cho S3 và DynamoDB ngay khi dựng NAT Gateway. Chúng miễn phí, giảm cả độ trễ lẫn hoá đơn, và với nhiều hệ thống thì phần lớn lưu lượng "ra Internet" thực ra chỉ là gọi tới chính các dịch vụ AWS.

Đáp án

A và C.

• A — Dùng AWS PrivateLink phơi bày ứng dụng dưới dạng endpoint service
• C — Tạo một Network Load Balancer

Vì sao đúng

Đề nêu ba yêu cầu, và cặp này là cơ chế chuẩn: | Yêu cầu | Cách đáp ứng | |---|---| | Chia sẻ MỘT ứng dụng từ VPC dùng chung | PrivateLink phơi bày đúng một dịch vụ | | Bên tiêu thụ KHÔNG được nối tới instance khác trong VPC | PrivateLink chỉ mở một endpoint | | Ít công quản trị nhất | một endpoint service, nhiều bên đăng ký |

Vế thứ hai là điểm quyết định:

VPC Peering: mở đường giữa HAI VPC
    → bên kia có thể tới MỌI instance
      (chỉ bị chặn bởi route table và security group)
        ↓
PrivateLink: chỉ có ĐÚNG MỘT điểm vào
    → là NLB của dịch vụ được chia sẻ
    → không có đường nào tới instance khác

Vì sao cần NLB:

Endpoint service của PrivateLink CHỈ gắn được với:
    → Network Load Balancer
    → hoặc Gateway Load Balancer
        ↓
    Không gắn thẳng vào EC2 hay ALB được
    → NLB là thành phần bắt buộc, đó là lý do C cũng đúng

Cấu hình phía cung cấp (VPC dùng chung):

aws elbv2 create-load-balancer --name nlb-dich-vu-chung   --type network --scheme internal --subnets subnet-a subnet-b

aws ec2 create-vpc-endpoint-service-configuration   --network-load-balancer-arns <arn-nlb>   --acceptance-required

aws ec2 modify-vpc-endpoint-service-permissions   --service-id vpce-svc-abc123   --add-allowed-principals arn:aws:iam::111122223333:root                            arn:aws:iam::444455556666:root

Phía tiêu thụ (mỗi tài khoản):

aws ec2 create-vpc-endpoint --vpc-id vpc-nguoi-dung   --vpc-endpoint-type Interface   --service-name com.amazonaws.vpce.ap-southeast-1.vpce-svc-abc123   --subnet-ids subnet-x --security-group-ids sg-endpoint

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chỉ phơi bày MỘT dịch vụ | | | CIDR hai bên được phép TRÙNG | | | Kết nối MỘT CHIỀU | bên cung cấp không vào được bên tiêu thụ |

Vế thứ hai là ưu thế thực tế lớn:

Nhiều tài khoản trong một tổ chức thường dùng
cùng dải 10.0.0.0/16
    → VPC Peering KHÔNG nối được
        ↓
    PrivateLink không quan tâm CIDR

Và ít công quản trị vì:

Thêm tài khoản thứ 10 muốn dùng dịch vụ?
    → thêm một principal vào danh sách cho phép
    → bên đó tự tạo endpoint
        ↓
    Peering: phải tạo và chấp nhận từng kết nối,
    rồi sửa route table ở cả hai bên

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

• **E. Thiết lập VPC peering giữa từng VPC — đây là phương án gần nhất vì cũng nối được mạng, nhưng nó vi phạm yêu cầu cô lập: peering mở đường tới toàn bộ VPC, và bạn phải dựa vào security group để chặn — đúng thứ đề nói là không đủ. Cộng thêm việc số kết nối tăng theo cấp số nhân.
• **B. Cấu hình security group để giới hạn truy cập — đây là biện pháp bổ sung, không phải cơ chế chia sẻ. Nó không tạo ra đường kết nối nào giữa các VPC, và dựa vào cấu hình đúng ở nhiều nơi là rủi ro.
• **D. Dùng AWS ClassicLink — dịch vụ đã ngừng: ClassicLink dùng để nối EC2-Classic (nền tảng cũ trước VPC) với VPC. AWS đã ngừng EC2-Classic từ 08/2022.

Ghi nhớ

⚠ Ba cách nối VPC — bảng phải thuộc: | Cách | Phơi bày | CIDR trùng | Bắc cầu | |---|---|---|---| | VPC Peering | cả VPC | ❌ | ❌ không bắc cầu | | Transit Gateway | cả VPC, có phân đoạn | ❌ | ✅ | | PrivateLink | CHỈ một dịch vụ | ✅ | không áp dụng |

Từ khoá nhận diện:

"share ONE application" + "must not reach other instances" → PrivateLink + NLB "connect many VPCs to on-premises" → Transit Gateway "exactly two VPCs, full access" → VPC Peering

Ba thành phần của PrivateLink tự tạo: | Thành phần | Ở đâu | |---|---| | Network Load Balancer | VPC cung cấp | | VPC Endpoint Service | VPC cung cấp | | Interface VPC Endpoint | VPC TIÊU THỤ |

⚠ Endpoint luôn nằm ở phía TIÊU THỤ — đây là điểm gây nhầm lẫn nhiều nhất.

Ba cách kiểm soát ai được kết nối: | Cách | Chi tiết | |---|---| | AllowedPrincipals | danh sách tài khoản hoặc role | | AcceptanceRequired | duyệt từng kết nối bằng tay | | Endpoint policy phía tiêu thụ | giới hạn hành động |

aws ec2 describe-vpc-endpoint-connections   --filters Name=service-id,Values=vpce-svc-abc123

aws ec2 accept-vpc-endpoint-connections --service-id vpce-svc-abc123   --vpc-endpoint-ids vpce-0abc123

Ba lưu ý về NLB cho PrivateLink: | Lưu ý | Chi tiết | |---|---| | Phải là NLB hoặc GWLB, không dùng ALB | | | Nên đặt scheme internal | | | Bật cross-zone nếu target lệch AZ | |

Nếu ứng dụng cần tính năng của ALB:

Đặt ALB phía sau NLB
    → NLB (cho PrivateLink) → ALB (cho routing theo path)
        ↓
    NLB hỗ trợ target kiểu ALB từ 2021

Ba lưu ý về DNS: | Lưu ý | Chi tiết | |---|---| | Endpoint có tên DNS theo AZ | | | Private DNS name cần xác minh tên miền | | | Hoặc dùng Route 53 private hosted zone làm CNAME | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Endpoint tính theo GIỜ mỗi AZ | | | Cộng phí theo GB xử lý | | | NLB tính phí riêng | |

Ba đặc điểm của ClassicLink (để biết vì sao D sai): | Đặc điểm | Chi tiết | |---|---| | Nối EC2-Classic với VPC | | | EC2-Classic đã NGỪNG từ 08/2022 | | | Không liên quan tới chia sẻ dịch vụ giữa VPC | |

Ba mẫu chia sẻ tài nguyên giữa tài khoản: | Mẫu | Dùng cho | |---|---| | PrivateLink | chia sẻ một DỊCH VỤ mạng | | AWS RAM | chia sẻ TÀI NGUYÊN (subnet, TGW, license) | | Cross-account IAM role | chia sẻ quyền gọi API |

AWS RAM cũng là mô hình VPC dùng chung:

Chủ sở hữu VPC chia sẻ SUBNET cho tài khoản khác
    → các tài khoản chạy tài nguyên trong cùng VPC
        ↓
    Khác với PrivateLink: đây là dùng chung mạng,
    không phải phơi bày một dịch vụ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig tên endpoint từ VPC tiêu thụ | ra IP riêng | | curl tới dịch vụ | | | Thử ping một instance khác trong VPC cung cấp | phải KHÔNG tới được |

Và một lời khuyên: hãy thực sự thử kết nối tới một instance khác trong VPC dùng chung sau khi cấu hình xong. Đó là bài kiểm tra duy nhất chứng minh yêu cầu cô lập đã được đáp ứng — và nếu ai đó đã lỡ tạo thêm một peering "để tiện gỡ lỗi", bạn sẽ phát hiện ra ngay.