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

Đáp án

D — Bật Default Host Management Configuration trong AWS Systems Manager Quick Setup.

Vì sao đúng

Đề nêu ba yêu cầu, và Default Host Management Configuration (DHMC) giải quyết cả ba với ít công nhất: | Yêu cầu | Cơ chế | |---|---| | Quản lý bản vá tập trung | Systems Manager Patch Manager | | KHÔNG làm gián đoạn ứng dụng đang chạy | vá theo maintenance window | | ÍT công quản trị nhất | DHMC tự cấu hình cho MỌI instance, không đụng IAM role hiện có |

Vấn đề mà DHMC giải quyết:

Cách truyền thống:
    → mỗi instance cần IAM role có AmazonSSMManagedInstanceCore
    → instance hiện tại đã có role riêng với policy tuỳ chỉnh
        ↓
    Phải sửa hoặc thay role của TỪNG instance
    → rủi ro làm hỏng quyền truy cập RDS và Secrets Manager

DHMC hoạt động khác hẳn:

Default Host Management Configuration:
    → cấu hình Ở CẤP TÀI KHOẢN VÀ REGION
    → SSM Agent tự lấy thông tin đăng nhập từ Instance Metadata Service
    → KHÔNG cần IAM role trên instance
        ↓
    Mọi EC2 trong tài khoản trở thành managed instance
    mà KHÔNG ĐỤNG gì tới IAM role hiện có

Bật DHMC:

aws ssm update-service-setting   --setting-id arn:aws:ssm:ap-northeast-1:123456789012:servicesetting/ssm/managed-instance/default-ec2-instance-management-role   --setting-value AWSSystemsManagerDefaultEC2InstanceManagementRole

Và ba lợi ích cụ thể: | Lợi ích | Chi tiết | |---|---| | Giữ nguyên IAM role hiện có | không rủi ro mất quyền RDS và Secrets Manager | | Tự áp cho instance MỚI | không phải nhớ cấu hình | | Một thao tác cho cả tài khoản | thay vì từng instance |

Sau đó dùng Patch Manager:

aws ssm create-patch-baseline --name baseline-linux   --operating-system AMAZON_LINUX_2   --approval-rules 'PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=CLASSIFICATION,Values=[Security]}]},ApproveAfterDays=7}]'

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

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

• **B. Gỡ IAM role hiện có khỏi mọi instance và thay bằng role mới có cả quyền cũ lẫn AmazonSSMManagedInstanceCore — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó nhiều công và có rủi ro: phải tạo role mới, sao chép chính xác mọi policy tuỳ chỉnh, rồi thay trên từng instance. Một sai sót là ứng dụng mất quyền truy cập RDS hoặc Secrets Manager.
• **A. Tạo role thứ hai và gắn CẢ HAI role vào mỗi instance qua Hybrid Activation — không làm được: một EC2 instance chỉ gắn được MỘT IAM role. Và Hybrid Activation dành cho máy chủ ngoài AWS, không phải EC2.
• **C. Cài SSM Agent thủ công và lên lịch bằng cron script — nhiều công nhất và không tập trung: mỗi máy một script, không có báo cáo tuân thủ, không có maintenance window, và SSM Agent đã cài sẵn trên hầu hết AMI của AWS.

Ghi nhớ

Ba cách để EC2 trở thành managed instance của SSM: | Cách | Đặc điểm | |---|---| | Default Host Management Configuration | cấp TÀI KHOẢN, không cần role trên instance ← câu này | | IAM role với AmazonSSMManagedInstanceCore | cách truyền thống, từng instance | | Hybrid Activation | cho máy chủ NGOÀI AWS |

Ba yêu cầu để instance được SSM quản lý: | Yêu cầu | Chi tiết | |---|---| | SSM Agent đang chạy | cài sẵn trên hầu hết AMI của AWS | | Quyền (qua role hoặc DHMC) | | | Đường mạng tới endpoint SSM | NAT Gateway hoặc VPC endpoint |

Dòng cuối hay bị bỏ sót:

Instance ở private subnet không có đường ra
    → SSM Agent không kết nối được
    → instance không hiện trong danh sách managed instance
        ↓
    → Tạo interface endpoint cho:
      ssm, ssmmessages, ec2messages
      + gateway endpoint cho S3

Các khả năng của AWS Systems Manager: | Khả năng | Việc | |---|---| | Patch Manager | vá lỗi tự động theo baseline và maintenance window ← câu này | | Session Manager | truy cập shell KHÔNG cần SSH, không cần bastion | | Run Command | chạy lệnh trên nhiều máy | | State Manager | duy trì cấu hình mong muốn | | Parameter Store | lưu cấu hình và bí mật | | Inventory | kiểm kê phần mềm đã cài | | Automation | luồng công việc vận hành |

Ba thành phần của Patch Manager: | Thành phần | Việc | |---|---| | Patch baseline | bản vá nào được duyệt, sau bao nhiêu ngày | | Patch group | nhóm instance theo thẻ | | Maintenance window | khi nào được vá — tránh giờ cao điểm |

Maintenance window là thứ đảm bảo "không gián đoạn ứng dụng":

aws ssm register-target-with-maintenance-window   --window-id mw-0abc --resource-type INSTANCE   --targets "Key=tag:MoiTruong,Values=SanXuat"

aws ssm register-task-with-maintenance-window   --window-id mw-0abc --task-type RUN_COMMAND   --task-arn AWS-RunPatchBaseline   --max-concurrency 25% --max-errors 10%

max-concurrency 25% nghĩa là chỉ vá 25% số máy cùng lúc — phần còn lại vẫn phục vụ.

Ba tuỳ chọn quan trọng: | Tuỳ chọn | Việc | |---|---| | MaxConcurrency | bao nhiêu máy vá cùng lúc | | MaxErrors | dừng nếu quá nhiều lỗi | | Cutoff | ngừng bắt đầu tác vụ mới trước khi hết cửa sổ |

Ba chế độ của AWS-RunPatchBaseline: | Chế độ | Việc | |---|---| | Scan | chỉ quét, báo cáo tuân thủ — không cài gì | | Install | cài bản vá | | — | có thể cấu hình khởi động lại hay không |

Nên chạy Scan trước để biết hiện trạng rồi mới bật Install.

Ba báo cáo tuân thủ:

aws ssm list-compliance-summaries
aws ssm list-resource-compliance-summaries   --filters Key=ComplianceType,Values=Patch

Đây là thứ đội tuân thủ cần — bằng chứng rằng bản vá bảo mật đã được áp.

Ba lợi ích khác của DHMC: | Lợi ích | Chi tiết | |---|---| | Tự áp cho instance MỚI | không phải nhớ cấu hình | | SSM Agent tự cập nhật | luôn có phiên bản mới | | Không cần quản lý IAM role cho SSM | giảm bề mặt quản trị |

Ba lưu ý về DHMC: | Lưu ý | Chi tiết | |---|---| | Cấu hình theo TỪNG Region | phải bật ở mọi Region dùng | | Cần IMDSv2 | instance phải cho phép metadata | | Không ghi đè role hiện có | ← lợi ích chính trong câu này |

Và Session Manager đáng bật cùng lúc:

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

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

Ba việc nên làm sau khi bật: | Việc | Chi tiết | |---|---| | Chạy Inventory | biết phần mềm nào đang cài | | Tạo patch baseline riêng cho prod và dev | prod duyệt chậm hơn | | Đặt alarm cho tuân thủ vá lỗi | phát hiện máy tụt lại |

Và một lời khuyên: hãy chạy chế độ Scan trong hai tuần trước khi bật Install. Nó cho thấy bao nhiêu bản vá đang thiếu và trên những máy nào — và với ứng dụng phân tích nội bộ đang chạy, biết trước quy mô thay đổi an toàn hơn nhiều so với để Patch Manager cài hàng trăm bản vá trong lần chạy đầu tiên.

Đáp án

C — Bật cross-zone load balancing: mỗi instance nhận 20%. Tắt cross-zone load balancing: instance ở AZ A nhận 50%, bốn instance ở AZ B mỗi cái nhận 12,5%.

Vì sao đúng

Đây là bài toán tính toán, và điểm mấu chốt là lưu lượng được chia ở hai cấp khác nhau.

Khi BẬT cross-zone load balancing:

Load balancer coi TẤT CẢ instance như một nhóm duy nhất
    → 5 instance tổng cộng
    → mỗi instance nhận 100% ÷ 5 = 20%
        ↓
    AZ A: 1 instance × 20% = 20%
    AZ B: 4 instance × 20% = 80%

Khi TẮT cross-zone load balancing:

Bước ①: chia đều cho các NODE của load balancer (theo AZ)
    → 2 AZ → mỗi AZ nhận 50%

Bước ②: trong mỗi AZ, chia đều cho instance TRONG AZ đó
    → AZ A: 50% ÷ 1 instance = 50%
    → AZ B: 50% ÷ 4 instance = 12,5% mỗi cái

Bảng tóm tắt: | | Bật cross-zone | Tắt cross-zone | |---|---|---| | Instance ở AZ A (1 máy) | 20% | 50% | | Mỗi instance ở AZ B (4 máy) | 20% | 12,5% | | Tổng AZ A | 20% | 50% | | Tổng AZ B | 80% | 50% |

Và đây là lý do phải cân bằng số instance giữa các AZ khi tắt cross-zone:

Số instance lệch nhau + tắt cross-zone
    → máy ở AZ ít instance bị QUÁ TẢI
    → máy ở AZ nhiều instance NHÀN RỖI
        ↓
    Trong ví dụ này, máy ở AZ A gánh gấp 4 lần máy ở AZ B

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

• **B. Bật: mỗi máy 20%. Tắt: AZ A không nhận gì, AZ B mỗi máy 25% — đây là phương án gần nhất và vế "bật" hoàn toàn đúng, nhưng vế "tắt" sai hoàn toàn: tắt cross-zone không khiến một AZ bị bỏ qua. Mỗi AZ vẫn nhận 50% lưu lượng.
• **A. Bật: AZ A không nhận gì, AZ B mỗi máy 25%. Tắt: AZ A 50%, AZ B 12,5% — đảo ngược và sai vế "bật".
• **D. Bật: AZ A 50%, AZ B 12,5%. Tắt: mỗi máy 20% — đảo ngược hoàn toàn hai trường hợp.

Ghi nhớ

Cross-zone load balancing — nguyên tắc phải thuộc:

BẬT:  chia đều cho MỌI target, bất kể AZ
TẮT:  chia đều cho mỗi AZ trước, rồi chia trong AZ

Mặc định khác nhau giữa các loại load balancer: | Loại | Mặc định | Phí truyền chéo AZ | |---|---|---| | Application Load Balancer | BẬT (không tắt được ở mức LB) | miễn phí | | Network Load Balancer | TẮT | TÍNH PHÍ khi bật | | Gateway Load Balancer | TẮT | tính phí khi bật | | Classic Load Balancer | tuỳ cách tạo | miễn phí |

Đây là bảng hay được hỏi nhất về chủ đề này.

Bật cross-zone cho NLB:

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

Từ 2023, cấu hình được ở mức target group — linh hoạt hơn trước.

Ba đánh đổi khi bật cross-zone cho NLB: | | Bật | Tắt | |---|---|---| | Phân phối | đều cho mọi target | đều theo AZ | | Phí truyền chéo AZ | có | không | | Cách ly lỗi AZ | thấp hơn | cao hơn | | Yêu cầu về số target mỗi AZ | không | phải cân bằng |

Ba lý do vẫn có người tắt cross-zone: | Lý do | Chi tiết | |---|---| | Tiết kiệm phí truyền chéo AZ | với lưu lượng rất lớn thì đáng kể | | Cách ly lỗi theo AZ | sự cố ở một AZ không lan sang AZ khác | | Giữ độ trễ thấp nhất | lưu lượng không rời AZ |

Và điều kiện để tắt cross-zone an toàn:

Số target ở mỗi AZ phải CÂN BẰNG
    → nếu không, phân phối lệch nghiêm trọng
        ↓
    Dùng ASG trải đều qua các AZ để đảm bảo điều này

Ba lưu ý về ASG và phân bố AZ: | Lưu ý | Chi tiết | |---|---| | ASG tự cân bằng số instance giữa các AZ | | | Khi cân bằng lại, ASG KHỞI ĐỘNG trước rồi mới chấm dứt | không giảm năng lực | | Chấm dứt từ AZ có nhiều instance nhất | chính sách mặc định |

ALB, NLB và GWLB — bảng phân biệt: | | ALB | NLB | GWLB | |---|---|---|---| | Tầng | 7 (HTTP) | 4 (TCP/UDP) | 3 (IP) | | Cross-zone mặc định | BẬT | TẮT | TẮT | | Định tuyến theo nội dung | ✅ | ❌ | ❌ | | IP tĩnh | ❌ | ✅ | — | | WAF | ✅ | ❌ | ❌ |

Ba thuật toán phân phối của ALB: | Thuật toán | Chi tiết | |---|---| | Round robin (mặc định) | lần lượt từng target | | Least outstanding requests | target ít request đang xử lý nhất | | Weighted random | với sticky session |

least_outstanding_requests đáng cân nhắc:

aws elbv2 modify-target-group-attributes --target-group-arn <arn>   --attributes Key=load_balancing.algorithm.type,Value=least_outstanding_requests

Phù hợp khi thời gian xử lý request biến động nhiều.

Ba lưu ý về phí truyền dữ liệu: | Chiều | Chi phí | |---|---| | Chéo AZ (EC2) | ~0,01 USD/GB mỗi chiều | | Trong cùng AZ, IP riêng | miễn phí | | ALB cross-zone | miễn phí (AWS không tính) |

Ba cách kiểm chứng phân phối thực tế: | Cách | Việc | |---|---| | CloudWatch metric RequestCount theo target group | | | Access log của ALB | đếm request theo target | | Metric ở tầng ứng dụng | số request mỗi instance |

Ba lưu ý khi thiết kế nhiều AZ: | Lưu ý | Chi tiết | |---|---| | Ba AZ tiết kiệm hơn hai AZ cho cùng mức chịu lỗi | | | Giữ số instance cân bằng giữa các AZ | | | MinSize đủ chịu tải khi mất một AZ | |

Công thức N+1 theo AZ:

Số máy mỗi AZ = (số máy cần phục vụ) ÷ (số AZ − 1)
    ↓
    Cần 4 máy, 3 AZ → 2 máy mỗi AZ (tổng 6)
    Cần 4 máy, 2 AZ → 4 máy mỗi AZ (tổng 8)

Và một lời khuyên: hãy kiểm chứng số instance thực tế ở mỗi AZ khi thấy một số máy bận hơn hẳn máy khác. Với NLB tắt cross-zone mặc định, phân bố lệch là nguyên nhân phổ biến nhất — và nó không hiện ra trong bất kỳ cảnh báo nào, chỉ lộ qua metric CPU chênh lệch giữa các máy.

Đáp án

A — Dùng Amazon GuardDuty giám sát hoạt động độc hại trên dữ liệu S3; dùng Amazon Macie để phát hiện dữ liệu nhạy cảm trên S3.

Vì sao đúng

Đề nêu hai yêu cầu khác nhau, và mỗi yêu cầu có một dịch vụ riêng: | Yêu cầu | Dịch vụ | |---|---| | PHÁT HIỆN dữ liệu NHẠY CẢM | Amazon Macie | | GIÁM SÁT và BẢO VỆ khỏi hoạt động ĐỘC HẠI | Amazon GuardDuty |

Macie phát hiện dữ liệu nhạy cảm:

Amazon Macie dùng học máy và khớp mẫu để tìm:
    ✓ thông tin cá nhân (PII): tên, địa chỉ, email, số điện thoại
    ✓ số thẻ tín dụng, số tài khoản ngân hàng
    ✓ số an sinh xã hội, hộ chiếu
    ✓ khoá API và thông tin đăng nhập
    ✓ dữ liệu tài chính và y tế
        ↓
    Và cho phép định nghĩa mẫu TUỲ CHỈNH bằng regex

GuardDuty phát hiện hoạt động độc hại:

GuardDuty S3 Protection phân tích CloudTrail data event:
    ✓ truy cập từ IP độc hại đã biết hoặc Tor
    ✓ mẫu tải xuống bất thường (rò rỉ dữ liệu)
    ✓ vô hiệu hoá Block Public Access
    ✓ hành vi giống ransomware

Hai dịch vụ trả lời hai câu hỏi khác nhau:

Macie:     "Trong bucket của tôi có gì nhạy cảm?"
GuardDuty: "Có ai đang làm gì đáng ngờ với dữ liệu đó không?"

Bật cả hai:

aws macie2 enable-macie
aws macie2 create-classification-job   --job-type SCHEDULED --name quet-du-lieu-nhay-cam   --s3-job-definition '{"bucketDefinitions":[{"accountId":"123456789012",
                        "buckets":["kho-tai-chinh"]}]}'   --schedule-frequency '{"weeklySchedule":{"dayOfWeek":"SUNDAY"}}'

aws guardduty create-detector --enable   --data-sources '{"S3Logs":{"Enable":true}}'

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

• **C. Dùng GuardDuty cho CẢ HAI việc — đây là phương án gần nhất vì vế giám sát hoạt động độc hại đúng, nhưng nó sai vế phát hiện dữ liệu nhạy cảm: GuardDuty phân tích log hành vi, nó không đọc NỘI DUNG của object trong S3 và không phân loại được dữ liệu.
• **B. Dùng Macie cho cả hai — sai vế giám sát hoạt động: Macie phân tích nội dung dữ liệu, không phải hành vi truy cập. Nó không phát hiện được kẻ tấn công đang tải dữ liệu về.
• **D. Macie giám sát hoạt động độc hại và GuardDuty phát hiện dữ liệu nhạy cảm — đảo ngược hoàn toàn.

Ghi nhớ

Các dịch vụ bảo mật của AWS — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | GuardDuty | PHÁT HIỆN ĐE DOẠ từ log (CloudTrail, VPC Flow, DNS, S3, EKS, RDS) | | Macie | PHÁT HIỆN DỮ LIỆU NHẠY CẢM trong S3 (PII, PHI, thẻ tín dụng) | | Inspector | QUÉT LỖ HỔNG (EC2, ECR, Lambda) | | Security Hub | TỔNG HỢP finding, chấm theo chuẩn | | Detective | ĐIỀU TRA sâu một finding | | Security Lake | tập trung và chuẩn hoá log bảo mật | | AWS Config | tuân thủ cấu hình | | CloudTrail | ghi lời gọi API |

Từ khoá nhận diện — bảng quan trọng nhất:

"sensitive data", "PII", "credit card numbers in S3", "classify data" → Macie "malicious activity", "threat detection", "unusual behavior", "compromised" → GuardDuty "vulnerabilities", "CVE", "unpatched software" → Inspector "aggregate findings", "compliance standard" → Security Hub "root cause investigation" → Detective

Ba khả năng của Amazon Macie: | Khả năng | Chi tiết | |---|---| | Phát hiện dữ liệu nhạy cảm | hơn 100 loại dựng sẵn + mẫu tuỳ chỉnh | | Kiểm kê bucket S3 | bucket nào công khai, chưa mã hoá, chia sẻ ra ngoài | | Chấm điểm rủi ro | ưu tiên bucket cần xử lý |

Kiểm kê bucket là tính năng miễn phí và rất hữu ích:

Macie tự động và LIÊN TỤC:
    ✓ liệt kê mọi bucket S3
    ✓ đánh dấu bucket công khai
    ✓ đánh dấu bucket chưa mã hoá
    ✓ đánh dấu bucket chia sẻ ra ngoài tài khoản
        ↓
    Phần này KHÔNG tính phí quét dữ liệu

Ba loại dữ liệu nhạy cảm Macie phát hiện: | Loại | Ví dụ | |---|---| | Thông tin cá nhân (PII) | tên, địa chỉ, email, số điện thoại | | Thông tin tài chính | số thẻ tín dụng, tài khoản ngân hàng | | Thông tin đăng nhập | khoá API, private key, thông tin AWS | | Tuỳ chỉnh | regex và từ khoá của riêng bạn |

Mẫu tuỳ chỉnh rất hữu ích cho dịch vụ tài chính:

aws macie2 create-custom-data-identifier   --name ma-khach-hang --regex '[A-Z]{3}-[0-9]{8}'   --keywords "ma khach hang" "customer id"

Ba nguồn dữ liệu chính của GuardDuty: | Nguồn | Phát hiện | |---|---| | CloudTrail | lời gọi API bất thường, thông tin đăng nhập bị lộ | | VPC Flow Logs | giao tiếp với IP độc hại, đào tiền mã hoá | | DNS logs | truy vấn tới miền độc hại, DNS tunneling |

Và các tính năng bảo vệ mở rộng (tính phí riêng): | Tính năng | Phát hiện | |---|---| | S3 Protection | ← câu này | | EKS Protection | hành vi bất thường trong cụm | | Malware Protection | quét mã độc trên volume EBS | | RDS Protection | đăng nhập database bất thường | | Lambda Protection | hoạt động mạng đáng ngờ |

Finding của GuardDuty cho S3: | Finding | Ý nghĩa | |---|---| | Exfiltration:S3/AnomalousBehavior | tải xuống bất thường — dấu hiệu rò rỉ | | Impact:S3/MaliciousIPCaller | gọi từ IP độc hại | | Discovery:S3/AnomalousBehavior | dò quét bucket | | Policy:S3/BucketBlockPublicAccessDisabled | tắt Block Public Access |

Ba lưu ý về chi phí: | Dịch vụ | Cách tính | |---|---| | Macie | theo dung lượng dữ liệu QUÉT | | GuardDuty | theo lượng log phân tích | | Cả hai | 30 ngày dùng thử miễn phí |

Chi phí Macie có thể lớn với bucket rất lớn:

Giảm chi phí bằng cách:
    ✓ chỉ quét bucket có khả năng chứa dữ liệu nhạy cảm
    ✓ dùng sampling thay vì quét 100%
    ✓ lên lịch định kỳ thay vì quét liên tục

Ba việc nên làm sau khi bật: | Việc | Chi tiết | |---|---| | Nối vào Security Hub | một chỗ xem mọi finding | | EventBridge rule cho finding nghiêm trọng | tự động cảnh báo hoặc phản ứng | | Bật ở TẤT CẢ Region | kẻ tấn công chọn Region bạn không giám sát |

Và tự động phản ứng:

{"source": ["aws.guardduty", "aws.macie"],
 "detail-type": ["GuardDuty Finding", "Macie Finding"],
 "detail": {"severity": [{"numeric": [">=", 7]}]}}

Ba biện pháp bổ sung cho dữ liệu tài chính: | Biện pháp | Chi tiết | |---|---| | Block Public Access ở mức TÀI KHOẢN | ngăn cấu hình sai | | Bật CloudTrail data event cho S3 | GuardDuty S3 Protection cần nguồn này | | SSE-KMS với customer managed key | audit việc dùng khoá |

Và một lời khuyên: hãy chạy Macie một lần trên toàn bộ bucket trước, xem kết quả, rồi mới quyết định lịch quét định kỳ. Lần quét đầu tiên thường phát hiện dữ liệu nhạy cảm ở những nơi không ai ngờ tới — bản sao lưu cũ, tệp xuất tạm, log chứa thông tin khách hàng — và đó là thông tin định hình toàn bộ chiến lược bảo vệ dữ liệu sau này.

Đáp án

A và C.

• A — Cấu hình origin access identity (OAI) và gắn với CloudFront distribution; đặt bucket policy sao cho chỉ OAI đọc được object
• C — Tạo AWS WAF ACL với IP match condition chỉ cho phép các IP đã có trong security group của EC2; gắn WAF ACL đó với CloudFront distribution

Vì sao đúng

Đề nêu hai yêu cầu, và hai đáp án giải quyết hai vế: | Yêu cầu | Cơ chế | |---|---| | Giới hạn truy cập theo dải IP của nhà cung cấp | WAF với IP match condition trên CloudFront | | Bảo vệ bucket S3 khỏi truy cập trực tiếp | OAI khoá bucket, chỉ CloudFront đọc được |

C — WAF thay thế vai trò của security group:

Trước khi chuyển:
    security group của EC2 giới hạn theo IP

Sau khi chuyển sang CloudFront + S3:
    → S3 và CloudFront KHÔNG có security group
    → cơ chế lọc IP duy nhất là AWS WAF

aws wafv2 create-ip-set --name ip-nha-cung-cap --scope CLOUDFRONT   --region us-east-1 --ip-address-version IPV4   --addresses 203.0.113.0/24 198.51.100.0/24

{"Name": "chi-cho-phep-nha-cung-cap", "Priority": 0,
 "Action": {"Block": {}},
 "Statement": {"NotStatement": {"Statement": {
   "IPSetReferenceStatement": {"ARN": "<arn-ip-set>"}}}}}

Lưu ý: WAF cho CloudFront phải tạo ở us-east-1 với scope CLOUDFRONT.

A — OAI khoá bucket lại:

Không có OAI:
    → nếu bucket công khai, ai biết URL đều tải được
    → vòng qua CloudFront, vòng qua WAF
        ↓
    Toàn bộ lớp lọc IP trở nên vô nghĩa

Có OAI:
    → bucket policy chỉ cho phép OAI đọc
    → mọi truy cập PHẢI đi qua CloudFront
    → và do đó phải qua WAF

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E1ABC"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::kho-noi-dung-tinh/*"}

Hai đáp án phụ thuộc lẫn nhau — thiếu OAI thì WAF vô dụng, thiếu WAF thì không có lọc IP.

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

• **E. Tạo security group mới cho phép cùng dải IP và gắn vào CloudFront distribution — đây là phương án gần nhất và nghe rất tự nhiên vì đó là cách làm với EC2, nhưng CloudFront KHÔNG gắn security group được: nó là dịch vụ biên toàn cầu, không nằm trong VPC.
• **B. Tạo network ACL mới và gắn vào CloudFront distribution — cùng lỗi: NACL gắn với subnet trong VPC, không gắn với CloudFront.
• **D. Tạo WAF ACL và gắn vào bucket policy của S3 — sai đích gắn: WAF gắn được vào CloudFront, ALB, API Gateway, AppSync và Cognito — không gắn được vào bucket S3.

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

Đáp án A dùng OAI, nhưng đó là cơ chế đã bị thay thế.

Từ tháng 8 năm 2022, AWS giới thiệu Origin Access Control (OAC) và khuyến nghị dùng nó thay OAI cho mọi distribution mới: | | OAI (cũ) | OAC (khuyến nghị) | |---|---|---| | Hỗ trợ SSE-KMS | ❌ | ✅ | | Hỗ trợ mọi Region | ❌ (một số Region mới không) | ✅ | | Hỗ trợ mọi phương thức HTTP | chỉ GET, HEAD | ✅ kể cả PUT, POST | | Ký request bằng SigV4 | ❌ | ✅ | | Trạng thái | duy trì nhưng không phát triển thêm | hiện hành |

Cấu hình OAC:

aws cloudfront create-origin-access-control   --origin-access-control-config   'Name=oac-noi-dung,OriginAccessControlOriginType=s3,SigningBehavior=always,SigningProtocol=sigv4'

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::kho-noi-dung-tinh/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1ABC"}}}

(Đáp án A vẫn đúng theo bộ đề, và OAI vẫn hoạt động; nhưng với distribution mới, hãy dùng OAC.)

Ghi nhớ

Các tài nguyên mà AWS WAF gắn được: | Tài nguyên | Scope | Region của Web ACL | |---|---|---| | CloudFront | CLOUDFRONT | BẮT BUỘC us-east-1 | | Application Load Balancer | REGIONAL | cùng Region | | API Gateway REST API | REGIONAL | cùng Region | | AppSync, Cognito user pool | REGIONAL | cùng Region | | Network Load Balancer | ❌ không hỗ trợ | — | | S3 bucket | ❌ không hỗ trợ | — |

Hai dòng cuối là điểm mà phương án B và D hiểu sai.

Ba cơ chế lọc lưu lượng và nơi áp dụng: | Cơ chế | Áp cho | |---|---| | Security group | ENI trong VPC (EC2, ALB, RDS...) | | Network ACL | subnet trong VPC | | AWS WAF | CloudFront, ALB, API Gateway |

CloudFront và S3 đều nằm NGOÀI VPC — nên chỉ WAF dùng được.

Sáu loại statement của WAF: | Statement | Khớp theo | |---|---| | IPSetReferenceStatement | danh sách IP hoặc CIDR ← câu này | | GeoMatchStatement | quốc gia | | RateBasedStatement | số request từ một IP | | ByteMatchStatement | chuỗi trong header, URI, body | | SqliMatchStatement / XssMatchStatement | tấn công phổ biến | | NotStatement, AndStatement, OrStatement | kết hợp logic |

NotStatement là cách viết danh sách trắng:

Block + NotStatement(IPSet)
    → chặn mọi thứ KHÔNG nằm trong IP set
    → tức là chỉ cho phép IP trong set

Ba lợi ích của việc đặt CloudFront trước S3: | Lợi ích | Chi tiết | |---|---| | Hiệu năng | đệm ở hơn 600 điểm biên | | Chi phí | truyền từ CloudFront rẻ hơn từ S3 | | Bảo mật | WAF, HTTPS, và khoá bucket bằng OAC |

Ba lưu ý khi dùng OAC hoặc OAI: | Lưu ý | Chi tiết | |---|---| | Bucket phải TẮT public access | nếu không, vẫn vòng qua được | | Dùng REST API endpoint, không dùng website endpoint | website endpoint không hỗ trợ OAC | | Với SSE-KMS, cần thêm quyền kms:Decrypt | và chỉ OAC hỗ trợ |

Dòng thứ hai đáng lưu ý:

S3 static website endpoint:  HTTP công khai, KHÔNG dùng OAC được
S3 REST API endpoint:        dùng được OAC, bucket riêng tư hoàn toàn
        ↓
    Với OAC, dùng CloudFront Functions để xử lý
    trang mặc định của thư mục con

Ba biện pháp bảo vệ nội dung trên CloudFront: | Biện pháp | Chi tiết | |---|---| | WAF với IP set | ← câu này | | Signed URL hoặc signed cookie | chỉ người có chữ ký hợp lệ xem được | | Geo restriction | chặn theo quốc gia |

Signed URL đáng cân nhắc thêm:

IP có thể thay đổi khi nhà cung cấp đổi nhà mạng
    → signed URL không phụ thuộc IP
    → và có thời hạn
        ↓
    Kết hợp cả hai cho bảo vệ nhiều lớp

Ba lưu ý về chi phí WAF: | Khoản | Giá tham khảo | |---|---| | Web ACL | ~5 USD/tháng | | Mỗi quy tắc | ~1 USD/tháng | | Mỗi triệu request | ~0,60 USD |

Ba việc nên làm khi triển khai: | Việc | Chi tiết | |---|---| | Bật chế độ Count trước | xem sẽ chặn gì trước khi chặn thật | | Bật WAF logging | phục vụ chẩn đoán | | Kiểm chứng bucket không truy cập trực tiếp được | thử URL S3 trực tiếp |

Và một lời khuyên: hãy thử truy cập thẳng URL của bucket S3 sau khi cấu hình xong. Nếu nó vẫn trả về nội dung, nghĩa là OAC hoặc OAI chưa có hiệu lực và toàn bộ lớp lọc IP của WAF đang bị vòng qua — và đó là lỗi chỉ phát hiện được bằng cách thử, không bằng cách đọc cấu hình.

Đáp án

B và E.

• B — AWS Schema Conversion Tool (SCT)
• E — AWS Database Migration Service (DMS)

Vì sao đúng

Đề mô tả một cuộc di chuyển KHÁC ENGINE (thương mại sang mã nguồn mở), và đó là trường hợp cần cả hai công cụ: | Công cụ | Việc | |---|---| | AWS SCT | chuyển LƯỢC ĐỒ và MÃ — bảng, index, khoá ngoại, stored procedure | | AWS DMS | chuyển DỮ LIỆU, có CDC để đồng bộ liên tục |

Vì sao cần SCT — đề nêu rõ lý do:

"complex database configurations such as
 SECONDARY INDEXES, FOREIGN KEYS, and STORED PROCEDURES"
        ↓
    DMS KHÔNG chuyển những thứ này
    → DMS chỉ chuyển DỮ LIỆU và tạo bảng cơ bản
    → index, khoá ngoại, trigger, stored procedure là việc của SCT

SCT làm gì:

① Kết nối tới database nguồn
② Phân tích lược đồ và mã
③ Chuyển sang cú pháp của engine đích
④ TẠO BÁO CÁO ĐÁNH GIÁ:
     ✓ bao nhiêu phần trăm tự chuyển được
     ⚠ cái gì cần xem lại
     ✗ cái gì phải viết lại bằng tay

# Báo cáo đánh giá là bước đầu tiên của mọi dự án di chuyển
# (chạy qua giao diện SCT hoặc DMS Schema Conversion)

Và DMS chuyển dữ liệu với gián đoạn tối thiểu:

aws dms create-replication-task   --replication-task-identifier chuyen-du-lieu   --source-endpoint-arn <arn-nguon>   --target-endpoint-arn <arn-dich>   --replication-instance-arn <arn-instance>   --migration-type full-load-and-cdc   --table-mappings file://anh-xa.json

Quy trình đầy đủ:

① SCT: đánh giá → chuyển lược đồ → áp lên database đích
② DMS: full load → CDC bám theo thay đổi
③ Cắt chuyển: dừng ghi vài phút, chờ CDC đuổi kịp, chuyển ứng dụng
④ SCT: tạo lại index và khoá ngoại (thường làm SAU full load cho nhanh)

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

• **C. Basic Schema Copy — đây là phương án gần nhất và là một tính năng có thật của DMS, nhưng nó không đủ cho yêu cầu của đề: Basic Schema Copy chỉ tạo bảng và cột cơ bản, nó KHÔNG chuyển secondary index, khoá ngoại, stored procedure hay trigger — đúng ba thứ mà đề nêu tên.
• **A. AWS Glue — sai công cụ: Glue là dịch vụ ETL không máy chủ cho chuẩn bị dữ liệu phân tích. Nó không chuyển lược đồ database hay stored procedure.
• **D. AWS Snowball Edge — sai bài toán: Snowball là thiết bị vật lý chuyển khối lượng dữ liệu rất lớn khi băng thông hạn chế. Nó không hiểu gì về lược đồ database.

Ghi nhớ

Bộ công cụ di chuyển database của AWS: | Công cụ | Việc | |---|---| | AWS SCT | chuyển LƯỢC ĐỒ và MÃ ← câu này | | AWS DMS | chuyển DỮ LIỆU, có CDC ← câu này | | DMS Schema Conversion | bản chạy trong đám mây của SCT | | Basic Schema Copy (trong DMS) | chỉ bảng và cột cơ bản |

Hai loại di chuyển database — bảng phải thuộc: | Loại | Công cụ cần | |---|---| | Homogeneous (CÙNG engine) | chỉ DMS | | Heterogeneous (KHÁC engine) | CẢ SCT LẪN DMS ← câu này |

Ví dụ:

Oracle tại chỗ → RDS for Oracle:     chỉ DMS
Oracle tại chỗ → Aurora PostgreSQL:  SCT + DMS
SQL Server → RDS for SQL Server:     chỉ DMS
SQL Server → Aurora MySQL:           SCT + DMS

Ba thứ DMS KHÔNG chuyển: | Không chuyển | Ai chuyển | |---|---| | Secondary index | SCT | | Khoá ngoại | SCT | | Stored procedure, function, trigger | SCT | | Sequence, view phức tạp | SCT |

Đây chính là lý do câu hỏi nêu tên ba thứ đó.

Ba giai đoạn của dự án di chuyển:

① ĐÁNH GIÁ  → SCT tạo báo cáo: bao nhiêu phần trăm tự chuyển được
② CHUYỂN ĐỔI → SCT chuyển lược đồ, con người xử lý phần còn lại
③ DI CHUYỂN  → DMS full load + CDC, rồi cắt chuyển

Báo cáo đánh giá của SCT rất quan trọng:

Nó phân loại từng đối tượng:
    ✓ tự chuyển được hoàn toàn
    ⚠ chuyển được nhưng cần xem lại
    ✗ phải viết lại bằng tay
        ↓
    Đây là căn cứ để ước lượng thời gian và chi phí dự án

Ba chế độ của DMS: | Chế độ | Việc | |---|---| | full-load | chuyển toàn bộ dữ liệu hiện có | | cdc | chỉ chuyển thay đổi | | full-load-and-cdc | chuyển hết rồi bám theo — gián đoạn tối thiểu |

Chế độ thứ ba là cách cắt chuyển ít gián đoạn nhất:

① Full load chạy nhiều ngày (không ảnh hưởng hệ thống cũ)
② CDC bám theo mọi thay đổi mới
③ Đến giờ cắt: dừng ghi vài phút
④ Chờ CDC đuổi kịp → chuyển ứng dụng sang đích

Ba lưu ý khi dùng DMS: | Lưu ý | Chi tiết | |---|---| | Tạo index SAU khi full load | nhanh hơn nhiều | | Bật validation | so sánh dữ liệu nguồn và đích | | Kích cỡ replication instance đủ lớn | ảnh hưởng tốc độ |

Bật validation:

{"ValidationSettings": {"EnableValidation": true,
                        "ValidationMode": "ROW_LEVEL"}}

Nó so từng dòng và báo cáo chênh lệch — bằng chứng cần thiết trước khi cắt chuyển.

Ba lựa chọn engine đích mã nguồn mở: | Engine | Đặc điểm | |---|---| | Aurora PostgreSQL | hiệu năng cao, có Babelfish cho T-SQL | | Aurora MySQL | hiệu năng cao, phổ biến | | RDS PostgreSQL / MySQL | chuẩn, rẻ hơn Aurora |

Babelfish đáng biết nếu nguồn là SQL Server:

Babelfish for Aurora PostgreSQL:
    → hiểu giao thức TDS và cú pháp T-SQL
    → ứng dụng gần như không phải sửa mã
        ↓
    Giảm rất nhiều công so với viết lại truy vấn

Lưu ý: Babelfish chỉ có cho Aurora PostgreSQL, không có cho MySQL.

Ba khoản tiết kiệm khi rời database thương mại: | Khoản | Chi tiết | |---|---| | Giấy phép | Oracle và SQL Server Enterprise rất đắt | | Phí duy trì hằng năm | Software Assurance, support contract | | Vận hành | Aurora tự sao lưu, vá lỗi, mở rộng |

Và DMS MIỄN PHÍ khi di chuyển sang Aurora, RDS, Redshift hoặc DynamoDB — chỉ trả tiền replication instance.

Ba lưu ý về stored procedure: | Lưu ý | Chi tiết | |---|---| | Thường là phần KHÓ NHẤT của dự án | cú pháp khác nhau nhiều | | SCT chuyển được phần lớn, không phải tất cả | | | Cân nhắc chuyển logic lên tầng ứng dụng | dễ bảo trì hơn về lâu dài |

Ba việc kiểm chứng trước khi cắt chuyển: | Việc | Chi tiết | |---|---| | Chạy song song và so kết quả truy vấn | | | Kiểm thử hiệu năng | kế hoạch thực thi khác nhau giữa các engine | | Kiểm thử mọi stored procedure đã chuyển | |

Dòng giữa quan trọng: cùng một truy vấn có thể nhanh trên Oracle và chậm trên PostgreSQL nếu thiếu index phù hợp — đó là loại vấn đề chỉ lộ ra khi chạy với dữ liệu thật.

Và một lời khuyên: hãy chạy báo cáo đánh giá của SCT ngay từ đầu, trước cả khi lập kế hoạch. Nếu nó báo 95% tự chuyển được, dự án khả thi trong vài tháng; nếu nó báo 40% với hàng trăm stored procedure phức tạp, đó là thông tin cần biết trước khi cam kết với ban lãnh đạo.

Đáp án

A — Lên lịch EventBridge rule với biểu thức cron hằng tuần để gọi AWS Lambda function chạy công việc luân chuyển database.

Vì sao đúng

Đề cho một con số quyết định: script chạy khoảng 5 PHÚT.

5 phút < giới hạn 15 phút của Lambda
    ↓
    Lambda hoàn toàn phù hợp

Và ba yêu cầu khác đều được thoả: | Yêu cầu | Cơ chế | |---|---| | Cron job KHÔNG MÁY CHỦ (serverless) | EventBridge + Lambda — không có máy nào | | Script viết bằng Python | Lambda có runtime Python | | Tiết kiệm và ĐÁNG TIN CẬY | trả tiền theo mili giây, tự thử lại |

Ước lượng chi phí:

Chạy 1 lần mỗi tuần × 5 phút × 512 MB
= 52 lần/năm × 300 giây × 0,5 GB = 7.800 GB-giây/năm
        ↓
    Nằm hoàn toàn trong Free Tier (400.000 GB-giây/tháng)
    → gần như MIỄN PHÍ

So với EC2:

EC2 chạy 24/7 chỉ để chạy 5 phút mỗi tuần:
    → t3.micro ~7,5 USD/tháng = 90 USD/năm
    → và phải vá lỗi, giám sát
        ↓
    Lãng phí 99,95% thời gian

Cấu hình:

aws events put-rule --name luan-chuyen-hang-tuan   --schedule-expression "cron(0 3 ? * SUN *)"

aws events put-targets --rule luan-chuyen-hang-tuan   --targets "Id=1,Arn=arn:aws:lambda:ap-northeast-1:123456789012:function:luan-chuyen-db"

aws lambda add-permission --function-name luan-chuyen-db   --statement-id events-invoke --action lambda:InvokeFunction   --principal events.amazonaws.com --source-arn <arn-rule>

Và EventBridge Scheduler là lựa chọn mới hơn, tốt hơn:

aws scheduler create-schedule --name luan-chuyen-hang-tuan   --schedule-expression "cron(0 3 ? * SUN *)"   --schedule-expression-timezone "Asia/Ho_Chi_Minh"   --flexible-time-window '{"Mode":"OFF"}'   --target '{"Arn":"<arn-lambda>","RoleArn":"<arn-role>"}'

Nó hỗ trợ múi giờ và tự xử lý giờ mùa hè.

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

• **B. Dùng tuỳ chọn lịch trong AWS Glue job để tự gọi mỗi tuần và chạy script — đây là phương án gần nhất và Glue thực sự có lịch dựng sẵn, nhưng nó là công cụ quá nặng cho việc này: Glue dành cho ETL trên khối lượng dữ liệu lớn, chạy trên Spark, và tính phí theo DPU-giờ với thời gian khởi động đáng kể. Một script Python 5 phút không cần bộ máy đó.
• **D. Dùng EC2 scheduled reserved instance với cron của hệ điều hành — không phải serverless và tốn kém: Scheduled Reserved Instance đòi cam kết, và bạn vẫn phải quản lý hệ điều hành. (AWS cũng đã ngừng bán loại này cho khách hàng mới.)
• **C. Dùng EC2 Spot instance với cron — không đáng tin cậy: Spot bị thu hồi bất cứ lúc nào. Với công việc chạy đúng một lần mỗi tuần, bị thu hồi giữa chừng nghĩa là bỏ lỡ cả tuần.

Ghi nhớ

Chọn dịch vụ theo thời gian chạy — bảng phải thuộc: | Thời gian chạy | Dịch vụ | |---|---| | Dưới 15 phút | Lambda ← câu này (5 phút) | | Trên 15 phút | Fargate hoặc AWS Batch | | Xử lý dữ liệu lớn với Spark | Glue hoặc EMR | | Cần kiểm soát sâu | EC2 |

Hai dịch vụ lập lịch — bảng phân biệt: | | EventBridge Scheduler | EventBridge Rule (scheduled) | |---|---|---| | Múi giờ | ✅ hỗ trợ | ❌ chỉ UTC | | Lịch một lần | ✅ | ❌ | | Số lịch | hàng triệu | 300 rule mỗi bus | | Số đích hỗ trợ | hơn 270 API | hạn chế hơn | | Retry policy và DLQ | ✅ | qua target |

EventBridge Scheduler là lựa chọn nên dùng cho lịch mới.

Ba loại biểu thức lịch: | Loại | Ví dụ | |---|---| | cron() | cron(0 3 ? * SUN *) — 3 giờ sáng Chủ nhật | | rate() | rate(7 days) | | at() | at(2026-09-01T03:00:00) — chạy một lần |

Cú pháp cron của AWS có SÁU trường:

cron(phút giờ ngày-tháng tháng ngày-tuần năm)
     ↓
cron(0 3 ? * SUN *)

Khác cron của Unix (năm trường) — và một trong hai trường ngày phải là ?.

Ba lưu ý về múi giờ: | Lưu ý | Chi tiết | |---|---| | EventBridge Rule dùng UTC | phải tự quy đổi | | EventBridge Scheduler hỗ trợ múi giờ | và tự xử lý giờ mùa hè | | Ghi rõ múi giờ trong tài liệu | tránh nhầm lẫn |

Ba cấu hình xử lý lỗi của Scheduler: | Cấu hình | Việc | |---|---| | MaximumRetryAttempts | số lần thử lại | | MaximumEventAgeInSeconds | bỏ qua nếu quá cũ | | DeadLetterConfig | gửi sự kiện thất bại vào SQS |

Ba lưu ý khi Lambda truy cập RDS: | Lưu ý | Chi tiết | |---|---| | Lambda phải ở TRONG VPC | nếu RDS ở private subnet | | Cần security group cho phép | từ Lambda tới RDS | | Cân nhắc RDS Proxy | nếu nhiều lượt Lambda đồng thời |

Với công việc chạy một lần mỗi tuần, RDS Proxy không cần thiết — chỉ có một kết nối.

Ba cách lấy thông tin đăng nhập database: | Cách | Đánh giá | |---|---| | Secrets Manager | tốt nhất — tự xoay vòng | | Parameter Store (SecureString) | rẻ hơn, không tự xoay vòng | | Biến môi trường mã hoá bằng KMS | chấp nhận được |

import boto3, json
def lay_thong_tin():
    sm = boto3.client('secretsmanager')
    return json.loads(sm.get_secret_value(SecretId='prod/db/mysql')['SecretString'])

Ba lưu ý về giới hạn của Lambda: | Giới hạn | Giá trị | |---|---| | Thời gian chạy | 15 phút | | Bộ nhớ | 128 MB – 10 GB | | /tmp | 512 MB – 10 GB |

Nếu script sau này chạy quá 15 phút: | Lựa chọn | Chi tiết | |---|---| | EventBridge Scheduler → ECS Fargate task | không giới hạn thời gian | | Step Functions chia nhỏ công việc | mỗi bước dưới 15 phút | | AWS Batch | cho công việc lô lớn |

Ba cách theo dõi: | Cách | Việc | |---|---| | CloudWatch Logs của Lambda | đầu ra của script | | Alarm cho metric Errors | biết khi công việc thất bại | | EventBridge rule bắt Lambda failure | thông báo tự động |

Alarm là thứ bắt buộc với công việc chạy hằng tuần:

aws cloudwatch put-metric-alarm --alarm-name luan-chuyen-that-bai   --metric-name Errors --namespace AWS/Lambda   --dimensions Name=FunctionName,Value=luan-chuyen-db   --statistic Sum --period 300 --threshold 0   --comparison-operator GreaterThanThreshold   --alarm-actions <arn-sns>

Công việc chạy mỗi tuần một lần
    → thất bại mà không có alarm
    → có thể mất HÀNG THÁNG mới phát hiện

Ba lưu ý khi luân chuyển dữ liệu database: | Lưu ý | Chi tiết | |---|---| | Chạy trong giờ thấp điểm | tránh ảnh hưởng ứng dụng | | Xoá theo lô nhỏ | tránh khoá bảng lâu | | Kiểm chứng dữ liệu đã lưu trữ trước khi xoá | |

Và một lời khuyên: hãy đặt alarm cho cả trường hợp công việc KHÔNG CHẠY. Alarm cho Errors bắt được khi script lỗi, nhưng nếu EventBridge rule bị tắt nhầm thì không có lỗi nào cả — chỉ có sự im lặng. Một alarm trên metric Invocations với treat-missing-data breaching sẽ bắt được điều đó.

Đáp án

B — Dùng Amazon API Gateway và cấu hình usage plan kèm API key để áp giới hạn tần suất và hạn ngạch cho từng client.

Vì sao đúng

Đề nêu bốn yêu cầu, và usage plan của API Gateway được thiết kế đúng cho cả bốn: | Yêu cầu | Cơ chế | |---|---| | Giới hạn tần suất THEO TỪNG CLIENT | API key gắn với usage plan riêng | | Hạn ngạch sử dụng (quota) | quota theo ngày, tuần hoặc tháng | | Mức giới hạn KHÁC NHAU cho từng client | nhiều usage plan khác nhau | | Bảo vệ tài nguyên phía sau | throttling chặn ở tầng cổng |

Cấu hình usage plan:

aws apigateway create-usage-plan --name goi-mien-phi   --throttle 'rateLimit=10,burstLimit=20'   --quota 'limit=10000,period=MONTH'   --api-stages 'apiId=abc123,stage=prod'

aws apigateway create-usage-plan --name goi-tra-phi   --throttle 'rateLimit=1000,burstLimit=2000'   --quota 'limit=5000000,period=MONTH'   --api-stages 'apiId=abc123,stage=prod'

Và gắn API key vào usage plan:

aws apigateway create-api-key --name khach-hang-a --enabled
aws apigateway create-usage-plan-key --usage-plan-id up-abc   --key-id key-xyz --key-type API_KEY

Ba mức throttling của API Gateway: | Mức | Phạm vi | |---|---| | Account-level | toàn tài khoản (mặc định 10.000 req/giây) | | Stage-level và method-level | toàn bộ API hoặc một method | | Usage plan | TỪNG CLIENT theo API key ← câu này |

Và hai tham số của throttling: | Tham số | Ý nghĩa | |---|---| | rateLimit | số request TRUNG BÌNH mỗi giây | | burstLimit | số request tối đa trong một đợt bùng phát |

Cơ chế token bucket:

burstLimit = dung tích "xô"
rateLimit  = tốc độ đổ đầy xô
        ↓
    Client bùng phát tới burstLimit
    rồi phải giữ ở mức rateLimit

Vượt giới hạn → API Gateway trả về 429 Too Many Requests trước khi chạm tới backend.

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

• **D. Dùng ALB với path-based routing và cấu hình listener rule để áp giới hạn request — đây là phương án gần nhất vì ALB cũng là điểm vào có thể lọc lưu lượng, nhưng nó không có tính năng giới hạn tần suất theo client: listener rule của ALB chỉ định tuyến, không throttle. Muốn giới hạn tần suất trên ALB thì phải dùng AWS WAF rate-based rule, và nó giới hạn theo IP, không theo API key.
• **A. Dùng NLB kết thúc TLS và áp logic giới hạn trong chính EC2 backend — không bảo vệ được tài nguyên phía sau: request vẫn tới backend rồi mới bị từ chối, nên vẫn tiêu tốn tài nguyên. Và bạn phải tự viết và đồng bộ trạng thái đếm giữa các máy.
• **C. Dùng Gateway Load Balancer kiểm tra lưu lượng HTTP và throttle qua thiết bị tường lửa bên thứ ba — sai loại dịch vụ: GWLB dùng để chèn thiết bị bảo mật ở tầng mạng (tường lửa, IDS). Nó không hiểu API key hay hạn ngạch của từng client.

Ghi nhớ

Ba mức throttling của API Gateway — bảng phải thuộc: | Mức | Áp cho | Cấu hình ở | |---|---|---| | Account-level | toàn tài khoản | Service Quotas | | Stage / Method-level | toàn bộ API hoặc một method | stage settings | | Usage plan | từng API key | usage plan ← câu này |

Ba thành phần của usage plan: | Thành phần | Việc | |---|---| | Throttle (rateLimit, burstLimit) | giới hạn TỐC ĐỘ | | Quota (limit, period) | giới hạn TỔNG SỐ trong ngày/tuần/tháng | | API stage | usage plan áp cho stage nào |

Throttle và quota là hai thứ khác nhau:

Throttle: 100 request/giây     → chống bùng phát
Quota:    1.000.000/tháng      → chống dùng quá gói dịch vụ
        ↓
    Cả hai cùng áp

Ba loại API của API Gateway và hỗ trợ usage plan: | Loại | Usage plan và API key | |---|---| | REST API | ✅ ← câu này | | HTTP API | ❌ | | WebSocket API | ✅ |

Đây là lý do phải chọn REST API cho tình huống này — HTTP API rẻ hơn nhưng không có usage plan.

REST API và HTTP API — bảng phân biệt: | | REST API | HTTP API | |---|---|---| | Usage plan, API key | ✅ | ❌ | | Caching | ✅ | ❌ | | AWS WAF | ✅ | ❌ | | Private endpoint | ✅ | ❌ | | Request validation | ✅ | hạn chế | | Chi phí | cao hơn | rẻ hơn ~70% | | Độ trễ | cao hơn | thấp hơn |

Ba lưu ý về API key: | Lưu ý | Chi tiết | |---|---| | API key KHÔNG phải cơ chế XÁC THỰC | chỉ để nhận diện client cho việc đo lường | | Phải kết hợp với authorizer thật | IAM, Cognito, hoặc Lambda authorizer | | Gửi trong header x-api-key | |

Điểm đầu tiên rất quan trọng:

AWS nêu rõ: API key không dùng để uỷ quyền
    → nó nhận diện client để áp usage plan
    → xác thực thật phải dùng cơ chế khác
        ↓
    Kết hợp: API key (đo lường) + Cognito/JWT (xác thực)

Ba cách bảo vệ API: | Lớp | Cơ chế | |---|---| | Xác thực | IAM, Cognito, Lambda authorizer, JWT | | Giới hạn tần suất | usage plan ← câu này | | Lọc tấn công tầng 7 | AWS WAF |

Và WAF bổ sung cho usage plan:

Usage plan: giới hạn theo API KEY (client đã đăng ký)
WAF rate-based rule: giới hạn theo IP (kể cả client chưa đăng ký)
        ↓
    Hai lớp bổ sung nhau

Ba cách theo dõi mức dùng:

aws apigateway get-usage --usage-plan-id up-abc   --start-date 2026-08-01 --end-date 2026-08-31

Ba lưu ý về 429 Too Many Requests: | Lưu ý | Chi tiết | |---|---| | API Gateway tự trả về khi vượt giới hạn | không tới backend | | Client nên thử lại với exponential backoff | | | Tuỳ chỉnh được nội dung phản hồi | gateway response |

Ba tính năng khác của API Gateway đáng dùng: | Tính năng | Việc | |---|---| | Caching | giảm tải backend cho request lặp lại | | Request validation | loại payload sai định dạng sớm | | Canary deployment | triển khai dần phiên bản mới |

Caching đặc biệt hữu ích cho API công khai:

aws apigateway update-stage --rest-api-id abc123 --stage-name prod   --patch-operations op=replace,path=/cacheClusterEnabled,value=true                      op=replace,path=/cacheClusterSize,value=0.5

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | REST API | ~3,50 USD/triệu request | | Caching | theo giờ, tuỳ dung lượng cache | | API key và usage plan | không có phí riêng |

Ba mô hình phân hạng client: | Hạng | Cấu hình gợi ý | |---|---| | Miễn phí | 10 req/giây, 10.000/tháng | | Tiêu chuẩn | 100 req/giây, 1 triệu/tháng | | Cao cấp | 1.000 req/giây, không giới hạn quota |

Và một lời khuyên: hãy theo dõi get-usage định kỳ và cảnh báo khi client sắp chạm hạn ngạch. Với ứng dụng di động của bên thứ ba, việc bị chặn đột ngột vì hết quota giữa tháng là trải nghiệm rất xấu — và một thông báo trước vài ngày biến vấn đề kỹ thuật thành cơ hội bán gói dịch vụ cao hơn.

Đáp án

A — Dựng Amazon FSx for NetApp ONTAP, cấu hình file system trên volume gốc và chuyển dữ liệu sang volume của FSx for ONTAP.

Vì sao đúng

Đề nêu ba yêu cầu, và FSx for ONTAP là dịch vụ duy nhất thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | Truy cập bằng CẢ SMB LẪN NFS | ONTAP hỗ trợ đa giao thức nguyên bản | | Một phần dữ liệu truy cập thường xuyên, phần còn lại thưa | tự phân tầng dữ liệu lạnh | | Ít công vận hành nhất | dịch vụ được quản lý hoàn toàn |

Vế đầu tiên là điểm phân biệt tuyệt đối:

Windows, Mac VÀ Linux cùng truy cập:
    → Windows dùng SMB
    → Linux dùng NFS
    → Mac dùng cả hai
        ↓
    Cần hệ thống tệp phục vụ CẢ HAI giao thức
    trên CÙNG dữ liệu

Và chỉ FSx for ONTAP làm được: | Dịch vụ | NFS | SMB | Đa giao thức trên cùng dữ liệu | |---|---|---|---| | FSx for ONTAP | ✅ | ✅ | ✅ | | FSx for Windows | ❌ | ✅ | ❌ | | FSx for Lustre | ✅ (POSIX) | ❌ | ❌ | | EFS | ✅ | ❌ | ❌ | | FSx for OpenZFS | ✅ | ❌ | ❌ |

Và vế phân tầng cũng được ONTAP giải quyết tự động:

FSx for ONTAP có hai tầng lưu trữ:
    ✓ SSD tier — dữ liệu nóng, hiệu năng cao
    ✓ Capacity pool tier — dữ liệu lạnh, RẺ HƠN NHIỀU
        ↓
    Chính sách tiering tự chuyển dữ liệu ít truy cập xuống

aws fsx create-file-system --file-system-type ONTAP   --storage-capacity 2048 --subnet-ids subnet-a subnet-b   --ontap-configuration '{
    "DeploymentType": "MULTI_AZ_1",
    "ThroughputCapacity": 512,
    "PreferredSubnetId": "subnet-a"}'

aws fsx create-volume --volume-type ONTAP --name du-lieu-chung   --ontap-configuration '{
    "JunctionPath": "/du-lieu",
    "SecurityStyle": "MIXED",
    "SizeInMegabytes": 1048576,
    "StorageEfficiencyEnabled": true,
    "TieringPolicy": {"Name": "AUTO", "CoolingPeriod": 31},
    "StorageVirtualMachineId": "svm-0abc"}'

SecurityStyle: MIXED là cấu hình cho truy cập đa giao thức.

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

• **B. Dùng EFS với Intelligent-Tiering và DataSync để chuyển dữ liệu — đây là phương án gần nhất và vế phân tầng hoàn toàn đúng, nhưng nó thiếu vế SMB: EFS chỉ phục vụ NFS. Máy Windows không mount được EFS một cách tự nhiên.
• **C. Dùng EFS với Infrequent Access — cùng lỗi về giao thức, và IA là lớp lưu trữ chứ không phải cơ chế tự phân tầng như Intelligent-Tiering.
• **D. Dùng FSx for OpenZFS — chỉ hỗ trợ NFS: nó dành cho việc di chuyển từ hệ thống ZFS tại chỗ, không phục vụ SMB.

Ghi nhớ

Bốn dịch vụ FSx theo giao thức — bảng phải thuộc: | Dịch vụ | Giao thức | Đặc trưng | |---|---|---| | FSx for NetApp ONTAP | NFS, SMB, iSCSI | đa giao thức, tiering, snapshot, cloning ← câu này | | FSx for Windows File Server | SMB | DFS, AD, NTFS ACL | | FSx for Lustre | Lustre (POSIX) | HPC, tích hợp S3 | | FSx for OpenZFS | NFS | di chuyển từ ZFS | | Amazon EFS | NFS | tự co giãn, đơn giản |

Từ khoá nhận diện:

"both SMB and NFS", "Windows and Linux and Mac" → FSx for ONTAP "SMB only, Windows" → FSx for Windows "NFS only, Linux, simple" → EFS "HPC, parallel" → FSx for Lustre

Ba tính năng riêng của FSx for ONTAP: | Tính năng | Chi tiết | |---|---| | Đa giao thức trên CÙNG dữ liệu | NFS, SMB, iSCSI ← câu này | | Tự phân tầng dữ liệu lạnh | tiết kiệm rất nhiều | | Storage efficiency | dedup, nén, compaction | | SnapMirror, FlexClone | sao chép và nhân bản tức thì |

Hai tầng lưu trữ của ONTAP: | Tầng | Chi tiết | |---|---| | SSD tier | hiệu năng cao, giá cao | | Capacity pool tier | rẻ hơn nhiều, cho dữ liệu lạnh |

Bốn chính sách tiering: | Chính sách | Chuyển gì xuống tầng rẻ | |---|---| | AUTO | dữ liệu ít truy cập, kể cả block đang dùng ← khuyến nghị | | SNAPSHOT_ONLY | chỉ dữ liệu snapshot | | ALL | mọi thứ | | NONE | không phân tầng |

CoolingPeriod quyết định sau bao lâu thì coi là lạnh:

CoolingPeriod: 2–183 ngày (mặc định 31)
    ↓
    Dữ liệu không truy cập trong khoảng đó → chuyển xuống capacity pool

Ba lợi ích của storage efficiency: | Tính năng | Tiết kiệm | |---|---| | Deduplication | loại bỏ block trùng lặp | | Compression | nén dữ liệu | | Compaction | gộp block nhỏ | | Tổng | thường 50–70% với dữ liệu doanh nghiệp |

Ba khái niệm của FSx for ONTAP: | Khái niệm | Việc | |---|---| | File system | tài nguyên gốc, có SSD tier và capacity pool | | Storage Virtual Machine (SVM) | đơn vị cách ly, có endpoint riêng, tham gia AD riêng | | Volume | đơn vị dữ liệu, có junction path và chính sách tiering |

Ba SecurityStyle của volume: | Style | Dùng khi | |---|---| | UNIX | chủ yếu NFS | | NTFS | chủ yếu SMB | | MIXED | cả hai giao thức truy cập cùng dữ liệu ← câu này |

Và ánh xạ danh tính là chi tiết cần cấu hình:

Người dùng Windows (SID trong AD) và người dùng Linux (uid POSIX)
    → ONTAP cần biết ai là ai
        ↓
    Cấu hình name mapping trong SVM

Ba lưu ý khi triển khai: | Lưu ý | Chi tiết | |---|---| | Cần Active Directory cho SMB | tham gia domain ở mức SVM | | Multi-AZ cho sản xuất | tự chuyển đổi | | Cấu hình name mapping cho truy cập đa giao thức | tránh vấn đề quyền |

Ba cách chuyển dữ liệu lên FSx for ONTAP: | Cách | Đặc điểm | |---|---| | AWS DataSync | giữ metadata và ACL | | NetApp SnapMirror | từ hệ thống ONTAP tại chỗ — hiệu quả nhất | | Robocopy, rsync | thủ công |

SnapMirror rất hiệu quả nếu đã dùng NetApp tại chỗ:

SnapMirror:
    → sao chép ở mức block, chỉ chuyển phần thay đổi
    → giữ nguyên mọi thuộc tính
    → đồng bộ liên tục cho tới lúc cắt chuyển

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | SSD tier | đắt hơn, cấp phát trước | | Capacity pool | rẻ hơn nhiều, trả theo lượng dùng | | Throughput capacity | khai riêng |

Và tiering là cách kiểm soát chi phí chính:

Cấp SSD tier vừa đủ cho dữ liệu nóng
    → phần còn lại tự xuống capacity pool
        ↓
    Chi phí thấp hơn nhiều so với để tất cả trên SSD

Ba lựa chọn nếu chỉ cần một giao thức: | Nhu cầu | Dịch vụ | |---|---| | Chỉ SMB | FSx for Windows (rẻ hơn, đơn giản hơn) | | Chỉ NFS | EFS (tự co giãn, đơn giản nhất) | | Cả hai | FSx for ONTAP ← câu này |

Và một lời khuyên: hãy bật storage efficiency và tiering ngay khi tạo volume. Cả hai đều giảm chi phí đáng kể mà không ảnh hưởng gì tới cách người dùng truy cập — và bật sau khi đã có hàng terabyte dữ liệu thì quá trình tối ưu hoá lại mất nhiều thời gian hơn.

Đáp án

B — Dùng AWS Global Accelerator để phân phối kết quả thể thao trực tiếp với độ trễ thấp.

Vì sao đúng

Đề cho một từ khoá quyết định: giao thức UDP.

Ứng dụng độc quyền dùng UDP
    ↓
    CloudFront: CHỈ hỗ trợ HTTP/HTTPS → LOẠI
    ELB: ALB chỉ HTTP, NLB có UDP nhưng chỉ MỘT Region
        ↓
    Global Accelerator: hỗ trợ CẢ TCP LẪN UDP, toàn cầu

Và Global Accelerator cho độ trễ thấp nhất:

Người xem → điểm biên AWS gần nhất (anycast)
    → MẠNG XƯƠNG SỐNG RIÊNG của AWS
    → Region đích
        ↓
    ✓ ít chặng hơn Internet công cộng
    ✓ mất gói thấp hơn
    ✓ JITTER thấp hơn — rất quan trọng với dữ liệu trực tiếp

Ba lợi ích cho việc phân phối kết quả trực tiếp: | Lợi ích | Chi tiết | |---|---| | Hỗ trợ UDP | ← yêu cầu bắt buộc | | Độ trễ và jitter thấp | mạng riêng của AWS | | Hai IP anycast TĨNH | không phụ thuộc bộ đệm DNS |

Cấu hình:

aws globalaccelerator create-accelerator --name ket-qua-the-thao --enabled

aws globalaccelerator create-listener --accelerator-arn <arn>   --protocol UDP --port-ranges FromPort=5000,ToPort=5000   --client-affinity SOURCE_IP

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region ap-northeast-1   --endpoint-configurations EndpointId=<arn-nlb>,Weight=100

Và --protocol UDP là điều mà CloudFront không có.

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

• **D. Dùng Amazon CloudFront — đây là phương án gần nhất và là CDN cho phân phối nội dung toàn cầu, nhưng nó chỉ hỗ trợ HTTP và HTTPS. Ứng dụng độc quyền dùng UDP không đi qua CloudFront được.
• **A. Dùng Elastic Load Balancing — chỉ hoạt động trong MỘT Region: ELB không phân phối lưu lượng toàn cầu. (NLB có hỗ trợ UDP, nhưng không giải quyết được vấn đề độ trễ liên lục địa.)
• **C. Dùng Auto Scaling group — không phải dịch vụ phân phối: ASG quản lý số lượng và vòng đời instance, nó không định tuyến lưu lượng hay giảm độ trễ.

Ghi nhớ

Global Accelerator và CloudFront — bảng phân biệt cốt lõi: | | Global Accelerator | CloudFront | |---|---|---| | Giao thức | TCP và UDP, MỌI cổng | CHỈ HTTP/HTTPS | | Caching | ❌ không đệm | ✅ đệm nội dung | | Địa chỉ | 2 IP anycast TĨNH | tên miền | | Chuyển vùng | ~30 giây, không đụng DNS | theo origin | | Phù hợp | game, VoIP, IoT, UDP, API độ trễ thấp | web, video theo yêu cầu, tệp tĩnh |

Từ khoá nhận diện — bảng quan trọng:

"UDP", "non-HTTP protocol", "static IP", "fast regional failover" → Global Accelerator "cache static content", "HTTP", "reduce origin load" → CloudFront "single Region load balancing" → ELB

Ba lợi ích của Global Accelerator: | Lợi ích | Chi tiết | |---|---| | Giảm độ trễ và jitter | mạng riêng của AWS | | IP anycast TĨNH | không phụ thuộc bộ đệm DNS | | Chuyển vùng nhanh (~30 giây) | ở tầng mạng |

Và jitter thấp đặc biệt quan trọng với dữ liệu trực tiếp:

Kết quả thể thao trực tiếp:
    → độ trễ trung bình quan trọng
    → nhưng BIẾN ĐỘNG độ trễ (jitter) còn quan trọng hơn
        ↓
    Mạng riêng của AWS cho jitter thấp hơn Internet công cộng đáng kể

Ba khái niệm của Global Accelerator: | Khái niệm | Việc | |---|---| | Accelerator | tài nguyên gốc, mang hai IP tĩnh | | Listener | cổng và giao thức (TCP hoặc UDP) | | Endpoint group | một Region, có traffic dial | | Endpoint | ALB, NLB, EC2, Elastic IP |

Các loại endpoint được hỗ trợ: | Endpoint | Hỗ trợ UDP | |---|---| | Network Load Balancer | ✅ ← phù hợp cho UDP | | EC2 instance | ✅ | | Elastic IP | ✅ | | Application Load Balancer | ❌ (ALB chỉ HTTP) |

Với ứng dụng UDP, endpoint phải là NLB, EC2 hoặc Elastic IP.

Hai loại accelerator: | Loại | Đặc điểm | |---|---| | Standard | định tuyến theo độ trễ và sức khoẻ ← câu này | | Custom routing | ánh xạ cố định IP+cổng → instance cụ thể |

Custom routing đáng biết cho ứng dụng thời gian thực:

Nhiều phiên trên cùng fleet EC2
    → mỗi cổng ánh xạ tới đúng một instance và cổng
    → client luôn tới đúng máy chủ phiên của mình

Ba tuỳ chọn ClientAffinity: | Tuỳ chọn | Việc | |---|---| | NONE (mặc định) | phân phối theo luồng (5-tuple) | | SOURCE_IP | cùng IP nguồn luôn tới cùng endpoint |

Với ứng dụng trực tiếp, SOURCE_IP giúp giữ phiên ổn định.

Ba yếu tố quyết định định tuyến: | Yếu tố | Chi tiết | |---|---| | Sức khoẻ endpoint | không gửi tới endpoint hỏng | | Traffic dial | tỷ lệ lưu lượng mỗi Region | | Vị trí client | Region gần nhất khoẻ mạnh |

Và traffic dial cho triển khai dần:

aws globalaccelerator update-endpoint-group   --endpoint-group-arn <arn> --traffic-dial-percentage 10

Hoặc đặt 0 để rút một Region ra tức thì — công cụ khôi phục sự cố rất nhanh.

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Phí cố định | ~0,025 USD/giờ (~18 USD/tháng) | | Phí truyền dữ liệu cao cấp | theo GB, khác nhau theo Region | | Không có phí request | khác CloudFront |

Ba lựa chọn khác cho độ trễ cực thấp: | Lựa chọn | Chi tiết | |---|---| | Global Accelerator | toàn cầu, mọi giao thức ← câu này | | AWS Local Zones | gần người dùng hơn cả Region | | AWS Wavelength | trong mạng 5G của nhà mạng |

Local Zones đáng cân nhắc cho phân phối dữ liệu trực tiếp:

Local Zone đặt tại các thành phố lớn
    → độ trễ một chữ số mili giây trong khu vực đó
    → chạy EC2, EBS, ALB ngay tại đó

Ba biện pháp bảo mật đi kèm: | Biện pháp | Chi tiết | |---|---| | AWS Shield Standard tự động | chống DDoS tầng 3/4 | | Security group trên NLB hoặc EC2 | giới hạn nguồn | | — | WAF KHÔNG gắn được vào Global Accelerator |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | NewFlowCount | số luồng mới | | ProcessedBytesIn/Out | lưu lượng | | Health check của endpoint | Region nào đang phục vụ |

Ba lưu ý khi thiết kế ứng dụng UDP: | Lưu ý | Chi tiết | |---|---| | UDP không đảm bảo giao hàng | ứng dụng phải chịu được mất gói | | Không có kiểm soát tắc nghẽn dựng sẵn | tự cài đặt nếu cần | | Health check của Global Accelerator dùng TCP hoặc HTTP | không dùng UDP |

Dòng cuối là chi tiết vận hành quan trọng — bạn cần một cổng TCP hoặc HTTP riêng để Global Accelerator kiểm tra sức khoẻ endpoint.

Và một lời khuyên: hãy đo độ trễ thật từ nhiều vị trí trước và sau khi bật Global Accelerator. Mức cải thiện phụ thuộc nhiều vào chất lượng đường Internet giữa người xem và Region — với tuyến xa và nhiều chặng, cải thiện thường rất rõ; với tuyến vốn đã tốt, có thể không đáng kể so với chi phí thêm vào.

Đáp án

A — Cấu hình Amazon CloudFront để phân phối dữ liệu đang lưu trên S3 một cách tiết kiệm hơn.

Vì sao đúng

Đề nêu chính xác vấn đề: chi phí truyền dữ liệu RA của S3 tăng vọt khi lưu lượng tăng 300%.

Truyền dữ liệu từ S3 ra Internet: ~0,09 USD/GB
Truyền dữ liệu từ CloudFront ra Internet: ~0,085 USD/GB
    → và truyền từ S3 tới CloudFront (origin fetch): MIỄN PHÍ
        ↓
    Với tỷ lệ trúng cache cao, phần lớn request KHÔNG chạm tới S3

Và đây mới là khoản tiết kiệm lớn nhất:

Tỷ lệ trúng cache 90%:
    → chỉ 10% request phải lấy từ S3
    → 90% phục vụ từ điểm biên
        ↓
    Giảm cả phí truyền dữ liệu LẪN phí request của S3

Ba khoản tiết kiệm cụ thể: | Khoản | Chi tiết | |---|---| | Phí truyền dữ liệu | CloudFront rẻ hơn, và có bậc giảm giá theo khối lượng | | Phí request của S3 | giảm theo tỷ lệ trúng cache | | Truyền từ S3 tới CloudFront | MIỄN PHÍ hoàn toàn |

Và vế "giữ độ trễ thấp" cũng được cải thiện:

Nội dung phục vụ từ hơn 600 điểm biên
    → người học ở xa tải nhanh hơn hẳn
        ↓
    Vừa rẻ hơn vừa nhanh hơn

Cấu hình cơ bản:

aws cloudfront create-origin-access-control   --origin-access-control-config   'Name=oac-web,OriginAccessControlOriginType=s3,SigningBehavior=always,SigningProtocol=sigv4'

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::trang-dao-tao/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1ABC"}}}

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

• **C. Chuyển dữ liệu sang EBS volume gắn với EC2 để giảm chi phí S3 — đây là phương án gần nhất vì nó cũng nhắm tới việc đổi cách lưu trữ, nhưng nó làm mọi thứ tệ hơn: bạn thêm chi phí EC2 chạy 24/7, mất khả năng mở rộng của S3, và phí truyền dữ liệu ra Internet từ EC2 cũng bằng S3 — không tiết kiệm gì mà lại phải quản lý máy chủ.
• **B. Dùng S3 Batch Operations đọc dữ liệu hàng loạt để giảm số lời gọi — sai chức năng: Batch Operations dùng để thực hiện thao tác hàng loạt trên object (sao chép, gắn thẻ, khôi phục), không phải cơ chế phục vụ nội dung cho người dùng cuối.
• **D. Dùng Amazon EFS — đắt hơn nhiều: EFS có giá mỗi GB cao hơn S3 khoảng 13 lần, và nó là hệ thống tệp NFS trong VPC, không phục vụ website ra Internet được.

Ghi nhớ

Nguyên tắc giá truyền dữ liệu của AWS — bảng phải thuộc: | Chiều | Chi phí | |---|---| | VÀO AWS từ Internet | MIỄN PHÍ | | RA Internet từ S3 hoặc EC2 | ~0,09 USD/GB | | RA Internet từ CloudFront | ~0,085 USD/GB, có bậc giảm giá | | Từ S3 tới CloudFront | MIỄN PHÍ | | Giữa các Region | ~0,02 USD/GB |

Dòng thứ tư là khoản tiết kiệm mà nhiều người bỏ qua.

Ba lợi ích của việc đặt CloudFront trước S3: | Lợi ích | Chi tiết | |---|---| | Chi phí | rẻ hơn và giảm request tới S3 | | Hiệu năng | đệm gần người dùng | | Bảo mật | HTTPS, WAF, và khoá bucket bằng OAC |

Ba cách tăng tỷ lệ trúng cache: | Cách | Chi tiết | |---|---| | Đặt TTL dài cho nội dung tĩnh | dùng mã băm trong tên tệp | | Chỉ chuyển tiếp header thật sự cần | header thừa làm giảm tỷ lệ trúng cache | | Bật nén tự động | Gzip và Brotli |

Dòng giữa là lỗi hiệu năng phổ biến nhất:

Chuyển tiếp mọi header và cookie
    → mỗi request thành một khoá cache riêng
    → tỷ lệ trúng cache về gần 0
    → CloudFront trở thành lớp trung gian vô ích

Ba loại chính sách của CloudFront: | Chính sách | Việc | |---|---| | Cache policy | cái gì tạo nên KHOÁ CACHE | | Origin request policy | cái gì được CHUYỂN TIẾP tới origin | | Response headers policy | header thêm vào phản hồi |

Hai chính sách đầu tách biệt là điều quan trọng:

Origin cần header X nhưng không nên đưa vào khoá cache
    → cache policy: KHÔNG gồm X
    → origin request policy: CÓ chuyển tiếp X
        ↓
    Tỷ lệ trúng cache cao mà origin vẫn nhận đủ thông tin

Ba chính sách quản lý sẵn hay dùng: | Chính sách | Dùng khi | |---|---| | CachingOptimized | nội dung tĩnh | | CachingDisabled | API và nội dung cá nhân hoá | | AllViewer (origin request) | chuyển tiếp mọi thứ tới origin |

Ba cách giảm chi phí CloudFront thêm: | Cách | Tiết kiệm | |---|---| | Chọn price class phù hợp | bỏ các điểm biên đắt nếu không cần | | Bật Origin Shield | giảm request tới origin | | CloudFront Security Savings Bundle | cam kết đổi lấy giảm giá |

Price class đáng cân nhắc:

aws cloudfront update-distribution --id E1ABC   --distribution-config '{"PriceClass": "PriceClass_100", ...}'

Ba lưu ý về Free Tier của CloudFront: | Khoản | Miễn phí mỗi tháng | |---|---| | Truyền dữ liệu ra | 1 TB | | Request HTTP/HTTPS | 10 triệu | | CloudFront Function | 2 triệu lời gọi |

Free Tier này KHÔNG giới hạn 12 tháng — nó áp dụng vĩnh viễn, nên với website quy mô vừa có thể gần như miễn phí.

Ba lưu ý khi triển khai: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ ACM phải ở us-east-1 | yêu cầu bắt buộc của CloudFront | | Distribution mất 5–15 phút để triển khai | | | Dùng OAC để khoá bucket | không cho truy cập trực tiếp |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | nên trên 90% với nội dung tĩnh | | BytesDownloaded | lưu lượng phục vụ | | OriginLatency | thời gian lấy từ S3 |

Và một lời khuyên: hãy so hoá đơn tháng trước và tháng sau khi bật CloudFront. Với website tăng trưởng đột ngột như trong đề, con số thật thường ấn tượng hơn mọi ước tính — và nó cũng cho biết tỷ lệ trúng cache thực tế đang ở mức nào để tiếp tục tối ưu.