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

Đáp án

C và E.

• C — Cấu hình AWS CloudTrail ghi lại mọi hành động IAM
• E — Bật xác thực đa yếu tố (MFA) cho người dùng có đặc quyền

Vì sao đúng

Hai đáp án là hai thực hành tốt cốt lõi của IAM:

C — CloudTrail cho khả năng kiểm toán:

CloudTrail ghi lại:
    ✓ ai tạo hoặc xoá IAM user, role, policy
    ✓ ai gắn quyền cho ai
    ✓ từ IP nào, lúc nào
        ↓
    Với công ty dịch vụ tài chính, đây là yêu cầu TUÂN THỦ

Và trail nên được cấu hình đúng cách:

aws cloudtrail create-trail --name theo-doi-toan-to-chuc   --s3-bucket-name kho-log-kiem-toan   --is-multi-region-trail --enable-log-file-validation   --is-organization-trail

E — MFA là lớp bảo vệ mạnh nhất chống lộ mật khẩu:

Mật khẩu bị lộ (lừa đảo, dùng lại, rò rỉ):
    Không có MFA → kẻ tấn công vào được ngay
    Có MFA       → vẫn cần yếu tố thứ hai

Và bắt buộc MFA bằng chính sách:

{"Effect": "Deny", "NotAction": ["iam:ChangePassword",
   "iam:CreateVirtualMFADevice", "iam:EnableMFADevice",
   "sts:GetSessionToken"],
 "Resource": "*",
 "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}}

Dùng BoolIfExists chứ không phải Bool — với Bool, các lời gọi từ dịch vụ AWS không có khoá này sẽ bị chặn nhầm.

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

• **D. Dùng thông tin đăng nhập của user để cấp quyền cụ thể cho EC2 instance — đây là phương án gần nhất vì nó có vẻ như đang nói về việc phân quyền, nhưng nó đi ngược thực hành tốt nhất: EC2 phải dùng IAM role gắn qua instance profile. Nhúng access key vào instance là để lộ thông tin đăng nhập dài hạn — bất kỳ ai đọc được đĩa hoặc metadata đều lấy được.
• **A. Tạo ít tài khoản và CHIA SẺ thông tin đăng nhập giữa nhân viên — vi phạm nguyên tắc căn bản: mỗi người phải có danh tính riêng, nếu không thì CloudTrail chỉ ghi được "tài khoản chung X đã làm gì" mà không biết ai.
• **B. Cấp quyền TỐI ĐA để khỏi phải cấp lại — ngược hẳn nguyên tắc đặc quyền tối thiểu, và là nguyên nhân của phần lớn sự cố bảo mật do cấu hình sai.

Ghi nhớ

Bảy thực hành tốt nhất của IAM — bảng cần thuộc: | Thực hành | Lý do | |---|---| | Khoá tài khoản root, bật MFA | không dùng cho việc hằng ngày | | Mỗi người MỘT danh tính riêng | truy vết được | | Đặc quyền tối thiểu | giảm thiệt hại khi bị xâm nhập | | Dùng ROLE thay ACCESS KEY | thông tin đăng nhập tạm thời, tự hết hạn | | Bật MFA cho người có đặc quyền | ← câu này | | Bật CloudTrail | ← câu này | | Rà soát và gỡ quyền không dùng | qua Access Advisor |

Và AWS hiện khuyến nghị mạnh: dùng IAM Identity Center thay IAM user cho MỌI truy cập của con người.

Ba loại thông tin đăng nhập và mức rủi ro: | Loại | Rủi ro | |---|---| | Access key dài hạn | cao nhất — không tự hết hạn, hay bị commit vào git | | Thông tin đăng nhập tạm thời (STS) | thấp — tự hết hạn | | Mật khẩu console + MFA | thấp |

Ba nơi KHÔNG bao giờ đặt access key:

❌ Trong mã nguồn hoặc kho git
❌ Trên EC2 instance (dùng instance profile)
❌ Trong biến môi trường của container (dùng task role)

Bốn cơ chế cấp quyền không cần access key: | Ngữ cảnh | Cơ chế | |---|---| | EC2 | instance profile (IAM role) | | ECS | task role | | EKS | IRSA hoặc EKS Pod Identity | | Lambda | execution role | | Ứng dụng ngoài AWS | IAM Roles Anywhere hoặc OIDC federation |

Ba loại MFA mà AWS hỗ trợ: | Loại | Đặc điểm | |---|---| | Virtual MFA (ứng dụng điện thoại) | miễn phí, phổ biến | | Khoá bảo mật FIDO2 | chống lừa đảo tốt nhất | | Passkey | tiện lợi, chống lừa đảo |

AWS khuyến nghị FIDO2 hoặc passkey cho tài khoản có đặc quyền — mã OTP vẫn bị lừa lấy được qua trang giả.

Và từ 2024, AWS cho phép tối đa 8 thiết bị MFA cho mỗi người dùng root và IAM user — nên đăng ký nhiều thiết bị để tránh mất quyền truy cập.

Ba công cụ rà soát quyền: | Công cụ | Việc | |---|---| | IAM Access Analyzer | tìm tài nguyên chia sẻ ra ngoài tài khoản | | Access Advisor | dịch vụ nào thực sự được dùng | | Credential Report | liệt kê mọi user, trạng thái MFA, tuổi access key |

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

Báo cáo này là bước đầu tiên của mọi cuộc rà soát IAM — nó cho thấy ngay ai chưa bật MFA và access key nào đã quá cũ.

Ba biện pháp ở cấp tổ chức: | Biện pháp | Chi tiết | |---|---| | Service Control Policy | trần quyền cho cả tài khoản | | Tách tài khoản prod và dev | cách ly tuyệt đối | | Organization trail | một CloudTrail cho mọi tài khoản |

Và một lời khuyên cho công ty dịch vụ tài chính: hãy đặt alarm cho các sự kiện IAM nhạy cảm — đăng nhập root, tạo access key mới, gắn AdministratorAccess, tắt CloudTrail. CloudTrail ghi lại mọi thứ, nhưng log không ai đọc thì cũng chỉ hữu ích sau khi sự cố đã xảy ra.

Đáp án

B — Amazon FSx for Lustre.

Vì sao đúng

Đề mô tả chính xác kiến trúc mà FSx for Lustre được sinh ra để phục vụ: | Yêu cầu trong đề | FSx for Lustre | |---|---| | Dữ liệu NÓNG xử lý SONG SONG và PHÂN TÁN, tốc độ cao | hệ thống tệp song song hiệu năng cao | | Dữ liệu LẠNH giữ để tham chiếu, đọc ghi nhanh, CHI PHÍ THẤP | tích hợp nguyên bản với S3 | | Tăng tốc quy trình thiết kế chip (EDA) | EDA là trường hợp dùng chính thức của Lustre |

Lustre là gì:

Hệ thống tệp SONG SONG mã nguồn mở
    → dùng trong siêu máy tính và HPC hàng chục năm
    → thông lượng hàng trăm GB/giây
    → hàng triệu IOPS
    → độ trễ dưới mili giây

Và tích hợp S3 là thứ giải quyết vế "dữ liệu lạnh":

Liên kết file system với một bucket S3
    ↓
Dữ liệu trong S3 hiện ra như TỆP trong Lustre
    ↓ đọc lần đầu → Lustre TỰ nạp từ S3 (lazy loading)
    ↓ ghi kết quả → xuất ngược về S3
        ↓
    Dữ liệu nóng: trong Lustre, tốc độ cao
    Dữ liệu lạnh: trong S3, giá rẻ

aws fsx create-file-system --file-system-type LUSTRE   --storage-capacity 1200 --subnet-ids subnet-abc   --lustre-configuration '{
    "DeploymentType": "PERSISTENT_2",
    "PerUnitStorageThroughput": 1000,
    "DataRepositoryConfiguration": {
      "Bucket": "s3://kho-du-lieu-eda",
      "AutoImportPolicy": "NEW_CHANGED_DELETED"}}'

Và EDA được AWS nêu đích danh là trường hợp dùng của FSx for Lustre — cùng với học máy, phân tích gen, và mô phỏng khí động học.

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

• **A. FSx for Windows File Server — đây là phương án gần nhất vì cũng là FSx và cũng là hệ thống tệp chia sẻ, nhưng nó sai loại: nó phục vụ SMB cho Windows, tối ưu cho chia sẻ tệp văn phòng và ứng dụng .NET. Nó không phải hệ thống tệp song song và không có thông lượng cho HPC.
• **D. Amazon EMR — sai tầng kiến trúc: EMR là nền tảng xử lý dữ liệu lớn (Spark, Hadoop). Nó là compute, không phải storage. Và mô hình MapReduce không phù hợp với mô phỏng EDA.
• **C. AWS Glue — sai mục đích: Glue là dịch vụ ETL không máy chủ cho chuẩn bị dữ liệu phân tích, không liên quan tới lưu trữ hiệu năng cao.

Ghi nhớ

Bốn dịch vụ trong họ Amazon FSx — bảng cần thuộc: | Dịch vụ | Giao thức | Phù hợp | |---|---|---| | FSx for Lustre | Lustre (POSIX) | HPC, học máy, EDA, phân tích gen ← câu này | | FSx for Windows File Server | SMB | chia sẻ tệp Windows, AD tích hợp | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | đa giao thức, tính năng doanh nghiệp | | FSx for OpenZFS | NFS | di chuyển từ ZFS tại chỗ |

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

"HPC", "parallel", "machine learning", "EDA", "genomics", "high throughput" → FSx for Lustre "Windows", "SMB", "Active Directory" → FSx for Windows "multi-protocol", "NetApp", "snapshot, clone" → FSx for ONTAP "Linux NFS đơn giản, tự co giãn" → Amazon EFS

Hai kiểu triển khai của FSx for Lustre: | Kiểu | Đặc điểm | |---|---| | Scratch | KHÔNG sao chép, dữ liệu MẤT nếu máy chủ hỏng — rẻ, cho việc tạm | | Persistent | có sao chép trong AZ, tự thay phần cứng hỏng |

Quy tắc: dữ liệu nguồn ở S3 thì scratch đủ dùng — mất thì nạp lại từ S3.

Ba loại lưu trữ của Persistent: | Loại | Thông lượng | |---|---| | SSD | 125, 250, 500, 1000 MB/giây mỗi TiB | | HDD | 12 hoặc 40 MB/giây mỗi TiB | | HDD + SSD cache | đọc lại nhanh |

Ba khái niệm của tích hợp S3 (data repository): | Khái niệm | Việc | |---|---| | Lazy loading | tệp chỉ nạp từ S3 khi ĐƯỢC ĐỌC lần đầu | | AutoImportPolicy | tự cập nhật khi S3 đổi | | Data repository task | xuất kết quả ngược về S3 |

Lazy loading rất quan trọng về chi phí:

Bucket S3 chứa 500 TB dữ liệu lạnh
    → KHÔNG cần file system Lustre 500 TB
    → chỉ cần đủ chứa phần dữ liệu NÓNG đang xử lý
    → phần còn lại nạp theo nhu cầu

Và xuất kết quả về S3:

aws fsx create-data-repository-task --type EXPORT_TO_REPOSITORY   --file-system-id fs-0abc123 --paths /ket-qua   --report Enabled=true,Path=s3://kho-du-lieu-eda/bao-cao/

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Thông lượng tỷ lệ với DUNG LƯỢNG | muốn nhanh hơn phải cấp lớn hơn | | Dùng instance có băng thông mạng cao | nếu không mạng thành nút thắt | | Cài Lustre client trên instance | amazon-fsx-lustre-client |

Và data compression giảm cả chi phí lẫn thời gian:

--lustre-configuration '{"DataCompressionType": "LZ4"}'

Với dữ liệu EDA (nhiều tệp văn bản và netlist), tỷ lệ nén thường rất tốt.

Ba lựa chọn lưu trữ cho HPC trên AWS: | Lựa chọn | Phù hợp | |---|---| | FSx for Lustre | thông lượng cao nhất, chia sẻ giữa nhiều node ← câu này | | Instance store NVMe | I/O ngẫu nhiên cao nhất, không chia sẻ | | EFS | đơn giản, thông lượng thấp hơn nhiều |

Và với cụm HPC, nhớ đặt instance trong cluster placement group — độ trễ mạng thấp là điều kiện để Lustre phát huy thông lượng.

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Trả tiền theo DUNG LƯỢNG CẤP PHÁT | không phải theo lượng dùng thật | | Scratch rẻ hơn Persistent đáng kể | | | Xoá file system khi xong việc | dữ liệu đã xuất về S3 thì giữ Lustre là lãng phí |

Và một lời khuyên về quy trình EDA: hãy dựng file system Lustre theo từng đợt chạy — tạo trước khi chạy, nạp dữ liệu từ S3, chạy mô phỏng, xuất kết quả về S3, rồi xoá. Cách đó biến chi phí lưu trữ hiệu năng cao thành chi phí theo giờ thay vì theo tháng.

Đáp án

D và E.

• D — Đặt Amazon RDS Proxy giữa ứng dụng và cụm Aurora PostgreSQL; đưa EC2 vào Auto Scaling group có thử lại giao dịch
• E — Sửa ứng dụng để đẩy sự kiện mua hàng vào SQS; dùng Auto Scaling group các worker EC2 đọc hàng đợi và xử lý bất đồng bộ

Vì sao đúng

Đề nêu ràng buộc quan trọng: không được thiết kế lại tầng database. Vậy phải giải quyết ở tầng ứng dụng và tầng kết nối.

E — SQS giải quyết vấn đề gốc: đỉnh tải đột ngột.

Không có hàng đợi:
    Mở bán vé → 100.000 người bấm cùng lúc
        → mọi request đánh thẳng vào database
        → cạn connection pool → timeout → đơn hàng hỏng

Có SQS:
    → request được nhận NGAY và xếp hàng
    → worker xử lý theo tốc độ database chịu được
    → KHÔNG mất giao dịch nào
    → người dùng nhận phản hồi ngay lập tức

Đây là mẫu "load levelling" — hàng đợi hấp thụ đỉnh và làm phẳng tải xuống database.

D — RDS Proxy giải quyết vấn đề cạn kết nối:

Aurora PostgreSQL có giới hạn số kết nối theo cỡ instance
    → hàng trăm EC2 mỗi máy giữ vài chục kết nối
    → cạn sạch → "too many connections"

RDS Proxy:
    ✓ GOM và DÙNG CHUNG kết nối (connection pooling)
    ✓ hàng nghìn kết nối từ ứng dụng → ít kết nối tới database
    ✓ tự chuyển hướng khi failover, rút thời gian gián đoạn tới 66%

aws rds create-db-proxy --db-proxy-name proxy-ban-ve   --engine-family POSTGRESQL   --auth '[{"SecretArn":"<arn-secret>","IAMAuth":"REQUIRED"}]'   --role-arn <arn-role> --vpc-subnet-ids subnet-a subnet-b

Hai đáp án bổ sung nhau:

SQS      → làm phẳng đỉnh tải (bảo vệ khỏi số LƯỢNG request)
RDS Proxy → gom kết nối    (bảo vệ khỏi số KẾT NỐI)
    → và cả hai đều KHÔNG đụng tới thiết kế database

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

• **A. Dùng ElastiCache làm bộ nhớ đệm, và ghi giao dịch vào cache TRƯỚC khi ghi database — đây là phương án gần nhất và vế đệm truy vấn đọc là hợp lý, nhưng vế thứ hai rất nguy hiểm: ElastiCache không phải kho lưu trữ bền vững. Node hỏng hoặc bị đuổi khỏi bộ nhớ là mất giao dịch mua vé đã thu tiền.
• **C. Tạo read replica ở Region KHÁC và cho EC2 đọc VÀ GHI vào replica gần nhất — sai về mặt kỹ thuật: read replica chỉ đọc, không ghi được. Và replica xuyên Region có độ trễ sao chép, không phù hợp với giao dịch tài chính.
• **B. Dùng API Gateway throttling để làm chậm request lúc cao điểm — giải quyết bằng cách từ chối khách hàng: throttling giữ hệ thống ổn định nhưng người mua nhận lỗi 429. Với đợt mở bán vé, đó là thất bại về mặt kinh doanh chứ không phải giải pháp mở rộng.

Ghi nhớ

Ba mẫu kiến trúc chịu đỉnh tải — bảng cần thuộc: | Mẫu | Cơ chế | |---|---| | Queue-based load levelling | hàng đợi hấp thụ đỉnh, worker xử lý dần ← câu này | | Connection pooling | RDS Proxy gom kết nối ← câu này | | Caching | giảm tải ĐỌC (không dùng cho GHI) | | Throttling | bảo vệ hệ thống bằng cách từ chối |

Và quy tắc: caching cho ĐỌC, hàng đợi cho GHI.

Ba lợi ích của RDS Proxy: | Lợi ích | Chi tiết | |---|---| | Gom kết nối | hàng nghìn client → ít kết nối database | | Rút ngắn thời gian failover | giảm tới 66% | | Xác thực bằng IAM và Secrets Manager | không nhúng mật khẩu trong ứng dụng |

RDS Proxy đặc biệt hữu ích với Lambda:

Không có Proxy:
    1.000 lượt Lambda đồng thời → 1.000 kết nối database
    → cạn sạch ngay lập tức

Có Proxy:
    → gom lại còn vài chục kết nối thật

Ba lưu ý về RDS Proxy: | Lưu ý | Chi tiết | |---|---| | Có phí theo vCPU của database | không miễn phí | | Nằm trong VPC | cần subnet ở ít nhất hai AZ | | Không hỗ trợ mọi engine | MySQL, PostgreSQL, MariaDB, SQL Server |

SQS Standard và FIFO — chọn cho bán vé: | | Standard | FIFO | |---|---|---| | Thứ tự | không đảm bảo | đảm bảo | | Trùng lặp | có thể (at-least-once) | không (exactly-once) | | Thông lượng | gần như không giới hạn | 300/giây (3.000 khi gom lô) |

Với bán vé, FIFO đáng cân nhắc — nó đảm bảo thứ tự "ai đặt trước được trước" và tránh xử lý trùng một giao dịch. Nhưng nếu thông lượng cao hơn hạn mức FIFO, phải dùng high-throughput FIFO với nhiều message group.

Ba cách đảm bảo không xử lý trùng: | Cách | Chi tiết | |---|---| | SQS FIFO với deduplication ID | dựng sẵn, cửa sổ 5 phút | | Khoá idempotency trong database | UNIQUE trên mã giao dịch | | Điều kiện trong DynamoDB | attribute_not_exists |

Cách thứ hai là lưới an toàn cuối cùng — với tiền bạc, nên có cả hai.

Ba cách co giãn worker theo hàng đợi: | Metric | Đặc điểm | |---|---| | ApproximateNumberOfMessagesVisible | số thông điệp đang chờ | | Backlog mỗi instance | metric tuỳ chỉnh — chuẩn xác nhất | | ApproximateAgeOfOldestMessage | cảnh báo khi xử lý không kịp |

Công thức backlog mỗi instance:

Backlog mỗi instance = số thông điệp chờ ÷ số instance đang chạy
    → đặt target tracking giữ con số này ở mức mong muốn

Ba cấu hình SQS quan trọng: | Cấu hình | Chi tiết | |---|---| | Visibility timeout | dài hơn thời gian xử lý, nếu không sẽ xử lý hai lần | | Dead-letter queue | thông điệp hỏng không kẹt mãi | | Long polling | giảm request rỗng và chi phí |

Ba biện pháp bổ sung cho đợt mở bán vé: | Biện pháp | Chi tiết | |---|---| | Làm ấm ASG TRƯỚC giờ mở bán | scheduled scaling — không chờ phản ứng | | Aurora Auto Scaling cho replica đọc | tra cứu vé không đụng writer | | CloudFront + trang chờ tĩnh | giảm tải trang chủ |

Và một lời khuyên: hãy dùng scheduled scaling cho những sự kiện có giờ biết trước. Target tracking phản ứng sau khi tải tăng, và với đợt mở bán vé mà lưu lượng nhảy 100 lần trong 10 giây, phản ứng sau là quá muộn.

Đáp án

D — Tạo scheduled action khởi động vào giờ đã định của ngày cuối tháng, đặt desired capacity = 10.

Vì sao đúng

Đề mô tả tải biết trước chính xác thời điểm — và đó là định nghĩa của scheduled scaling.

"at a designated hour on the LAST DAY of every month"
    ↓
    Biết CHÍNH XÁC khi nào cần
    → không cần chờ metric phản ứng
    → scheduled action mở rộng TRƯỚC khi tải tới

Và điểm phân biệt giữa D và A là ba tham số của ASG: | Tham số | Ý nghĩa | |---|---| | MinSize | số máy TỐI THIỂU — ASG không bao giờ xuống dưới | | MaxSize | số máy tối đa | | DesiredCapacity | số máy ASG ĐANG muốn có |

Đặt DesiredCapacity = 10 là cách đúng:

Scheduled action đặt desired = 10 lúc 2 giờ sáng ngày cuối tháng
    → ASG khởi động thêm máy cho đủ 10
    → xong đợt xử lý, một scheduled action khác đặt desired = 2
        → hoặc để scaling policy tự thu hẹp

aws autoscaling put-scheduled-update-group-action   --auto-scaling-group-name asg-tinh-luong   --scheduled-action-name mo-rong-cuoi-thang   --recurrence "0 2 28-31 * *" --desired-capacity 10

aws autoscaling put-scheduled-update-group-action   --auto-scaling-group-name asg-tinh-luong   --scheduled-action-name thu-hep-sau-khi-xong   --recurrence "0 6 28-31 * *" --desired-capacity 2

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

• **A. Scheduled action đặt cả MinSize LẪN MaxSize = 10 — đây là phương án gần nhất và cũng dùng scheduled action đúng loại, nhưng nó khoá cứng nhóm ở 10 máy: MinSize = 10 nghĩa là ASG không bao giờ được xuống dưới 10, kể cả sau khi đợt xử lý xong. Và MaxSize = 10 chặn luôn khả năng mở rộng thêm nếu tải cao hơn dự kiến. Muốn về 2 máy phải có hành động khác đặt lại MinSize.
• **C. Target tracking policy và "đặt instance count = 10 vào giờ đã định" — hiểu sai cơ chế: target tracking khai một giá trị metric mục tiêu (ví dụ CPU 50%), không khai số instance và không có khái niệm thời điểm.
• **B. Simple tracking policy — không tồn tại loại policy nào tên như vậy. AWS có simple scaling và target tracking, không có "simple tracking".

Ghi nhớ

Ba tham số dung lượng của ASG — phân biệt rõ:

MinSize  ≤  DesiredCapacity  ≤  MaxSize

MinSize:          sàn cứng, ASG không xuống dưới
MaxSize:          trần cứng, ASG không vượt qua
DesiredCapacity:  con số ASG đang nhắm tới, THAY ĐỔI theo scaling policy

Quy tắc: scheduled action nên đặt DesiredCapacity, không đặt MinSize — trừ khi bạn thực sự muốn đảm bảo sàn.

Năm loại scaling policy: | Loại | Bạn khai gì | |---|---| | Scheduled scaling | thời điểm + dung lượng ← câu này | | Target tracking | một giá trị metric mục tiêu | | Step scaling | ngưỡng + các bậc điều chỉnh | | Simple scaling | ngưỡng + một hành động (cũ) | | Predictive scaling | học máy dự báo, mở rộng TRƯỚC |

Từ khoá nhận diện:

"at a specific time", "last day of month", "every Monday 9am" → scheduled scaling "maintain CPU at 50%" → target tracking "recurring pattern", "forecast" → predictive scaling

Cú pháp recurrence là cron của Unix (giờ UTC):

 ┌─ phút
 │ ┌─ giờ
 │ │  ┌─ ngày trong tháng
 │ │  │      ┌─ tháng
 │ │  │      │ ┌─ thứ trong tuần
 0 2 28-31  * *

Lưu ý: cron của AWS ASG dùng UTC — quên đổi múi giờ là hành động chạy sai giờ.

Và "ngày cuối tháng" không biểu diễn trực tiếp được bằng cron:

28-31 chạy vào CẢ BỐN ngày cuối
    → phải thêm logic trong ứng dụng, hoặc
    → dùng EventBridge Scheduler với biểu thức linh hoạt hơn

EventBridge Scheduler là lựa chọn tốt hơn cho lịch phức tạp: | Ưu điểm | Chi tiết | |---|---| | Hỗ trợ MÚI GIỜ | không phải tự quy đổi UTC | | Biểu thức L cho ngày cuối tháng | cron(0 2 L * ? *) | | Tự xử lý giờ mùa hè | |

aws scheduler create-schedule --name mo-rong-cuoi-thang   --schedule-expression "cron(0 2 L * ? *)"   --schedule-expression-timezone "Asia/Ho_Chi_Minh"   --target '{"Arn":"arn:aws:scheduler:::aws-sdk:autoscaling:setDesiredCapacity",
             "RoleArn":"<arn>",
             "Input":"{\"AutoScalingGroupName\":\"asg-tinh-luong\",\"DesiredCapacity\":10}"}'   --flexible-time-window '{"Mode":"OFF"}'

Ký tự L giải quyết đúng vấn đề "ngày cuối tháng" mà cron của ASG không làm được.

Ba cách kết hợp scheduled với các policy khác: | Kết hợp | Lợi ích | |---|---| | Scheduled + target tracking | scheduled đặt nền, target tracking điều chỉnh tinh | | Hai scheduled action | một mở rộng, một thu hẹp | | Scheduled + warm pool | máy sẵn sàng ngay, không chờ khởi động |

Warm pool đáng biết cho workload nặng:

Warm pool giữ sẵn instance đã khởi động và cấu hình xong
    ở trạng thái Stopped hoặc Hibernated
        ↓
    Khi cần → chuyển sang InService trong vài giây
    thay vì vài phút khởi động từ đầu

Ba lưu ý khi dùng scheduled scaling: | Lưu ý | Chi tiết | |---|---| | Đặt sớm hơn giờ cần vài phút | máy cần thời gian khởi động | | Nhớ có hành động thu hẹp | không thì 10 máy chạy cả tháng | | Kiểm tra MaxSize đủ lớn | scheduled action không vượt được trần |

Dòng cuối là lỗi hay gặp: đặt DesiredCapacity = 10 mà MaxSize vẫn là 5 thì ASG chỉ lên tới 5 và không có lỗi rõ ràng — chỉ thấy trong Activity history.

Và một lời khuyên: hãy kiểm tra Activity history của ASG sau lần chạy đầu tiên để xác nhận scheduled action đã kích hoạt đúng giờ và đủ số máy. Với việc chạy mỗi tháng một lần, một cấu hình sai có thể nằm im 30 ngày trước khi lộ ra — đúng vào lúc phòng lương cần nó nhất.

Đáp án

D và E.

• D — Khi áp thời hạn lưu TƯỜNG MINH cho một phiên bản object, bạn khai Retain Until Date cho phiên bản đó
• E — Các phiên bản khác nhau của cùng một object có thể có chế độ và thời hạn lưu KHÁC NHAU

Vì sao đúng

Câu này kiểm tra chi tiết của S3 Object Lock — và hai đáp án là hai đặc điểm cốt lõi.

D — hai cách khai thời hạn, hai kiểu tham số: | Cách khai | Tham số | |---|---| | Tường minh cho từng phiên bản | Retain Until Date — một MỐC THỜI GIAN cụ thể | | Mặc định của bucket | Retention Period — SỐ NGÀY hoặc SỐ NĂM |

# Tường minh: mốc thời gian
aws s3api put-object-retention --bucket kho-ho-so   --key ho-so-2026.pdf --version-id <id>   --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2033-08-30T00:00:00Z"}'

# Mặc định bucket: số ngày, S3 tự tính mốc khi object được ghi
aws s3api put-object-lock-configuration --bucket kho-ho-so   --object-lock-configuration '{"ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Years":7}}}'

E — Object Lock áp cho PHIÊN BẢN, không phải cho object:

ho-so-2026.pdf
    ├── phiên bản v1 → COMPLIANCE tới 2033
    ├── phiên bản v2 → GOVERNANCE tới 2028
    └── phiên bản v3 → không khoá
        ↓
    Mỗi phiên bản có cấu hình ĐỘC LẬP

Điều này hợp lý vì mỗi phiên bản là một bản ghi riêng với yêu cầu tuân thủ riêng.

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

• **A. Cấu hình mặc định của bucket sẽ GHI ĐÈ cấu hình tường minh trên phiên bản object — đây là phương án gần nhất vì nó nói đúng rằng hai cấu hình cùng tồn tại, nhưng nó đảo ngược thứ tự ưu tiên: cấu hình tường minh trên phiên bản THẮNG cấu hình mặc định của bucket. Mặc định chỉ áp cho object không có cấu hình riêng.
• **B. Khi dùng mặc định bucket, bạn khai Retain Until Date — sai loại tham số: mặc định bucket khai khoảng thời gian (số ngày hoặc năm), S3 tự cộng vào thời điểm ghi để tính ra mốc.
• **C. KHÔNG thể đặt thời hạn qua cấu hình mặc định của bucket — sai hoàn toàn: đó chính là mục đích của DefaultRetention.

Ghi nhớ

Hai chế độ của S3 Object Lock — bảng cần thuộc: | Chế độ | Ai gỡ được trước hạn | |---|---| | GOVERNANCE | user có quyền s3:BypassGovernanceRetention | | COMPLIANCE | KHÔNG AI — kể cả tài khoản root |

COMPLIANCE là bất khả xâm phạm:

Đặt COMPLIANCE tới năm 2033:
    ✗ root không xoá được
    ✗ AWS Support không gỡ được
    ✗ xoá cả tài khoản cũng không (bucket không xoá được khi còn object bị khoá)
        ↓
    → Cân nhắc rất kỹ trước khi dùng

Ba điều kiện tiên quyết của Object Lock: | Điều kiện | Chi tiết | |---|---| | Versioning phải BẬT | Object Lock áp cho phiên bản | | Bật lúc TẠO bucket | (hoặc liên hệ AWS Support cho bucket có sẵn) | | Không tắt được | một khi đã bật |

Hai cơ chế bảo vệ của Object Lock: | Cơ chế | Đặc điểm | |---|---| | Retention period | có thời hạn, tự hết | | Legal hold | KHÔNG có thời hạn, giữ tới khi gỡ tay |

Legal hold độc lập với retention:

Object có thể vừa có retention period vừa có legal hold
    → hết hạn retention nhưng còn legal hold → vẫn không xoá được
    → dùng cho vụ kiện tụng chưa biết kéo dài bao lâu

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

Thứ tự ưu tiên của cấu hình — điểm của câu này:

Cấu hình TƯỜNG MINH trên phiên bản
        ↓ thắng
Cấu hình MẶC ĐỊNH của bucket

Ba điều Object Lock KHÔNG ngăn: | Không ngăn | Chi tiết | |---|---| | Ghi phiên bản MỚI | phiên bản cũ vẫn được bảo vệ | | Đặt delete marker | object "biến mất" nhưng phiên bản vẫn còn | | Xoá object KHÔNG bị khoá | trong cùng bucket |

Dòng giữa hay gây hiểu nhầm: người dùng vẫn DeleteObject được (tạo delete marker), object không hiện trong danh sách nữa — nhưng phiên bản gốc vẫn nguyên vẹn và khôi phục được.

Ba lớp bảo vệ chống xoá nhầm — theo mức độ: | Lớp | Chống lại | |---|---| | Versioning | ghi đè và xoá nhầm — khôi phục được | | MFA Delete | xoá phiên bản cần MFA | | Object Lock COMPLIANCE | không ai xoá được, kể cả kẻ tấn công có quyền root |

Object Lock là biện pháp chống ransomware mạnh nhất trên S3 — kẻ tấn công chiếm được toàn quyền vẫn không xoá hay mã hoá được dữ liệu đã khoá.

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Mọi phiên bản đều tính tiền lưu trữ | kể cả phiên bản cũ | | Lifecycle KHÔNG xoá được object bị khoá | phiên bản cũ tích tụ | | Cân nhắc thời hạn thực sự cần | 7 năm gấp bảy lần chi phí của 1 năm |

Và lifecycle vẫn CHUYỂN LỚP được cho object bị khoá:

{"Transitions": [{"Days": 90, "StorageClass": "DEEP_ARCHIVE"}]}

Đó là cách giảm chi phí lưu trữ tuân thủ dài hạn — Deep Archive rẻ hơn Standard hơn 20 lần.

Ba trường hợp dùng Object Lock: | Trường hợp | Chế độ | |---|---| | Yêu cầu pháp lý (SEC 17a-4, FINRA, HIPAA) | COMPLIANCE | | Chính sách nội bộ, cần linh hoạt | GOVERNANCE | | Chống ransomware | COMPLIANCE hoặc GOVERNANCE |

Và một lời khuyên: hãy thử nghiệm trên bucket riêng với thời hạn NGẮN (vài ngày) trước khi áp COMPLIANCE nhiều năm cho dữ liệu thật. Đặt nhầm chế độ COMPLIANCE với thời hạn 10 năm là sai lầm không có cách nào sửa — bạn sẽ trả tiền lưu trữ cho dữ liệu đó suốt một thập kỷ.

Đáp án

C — AWS Global Accelerator.

Vì sao đúng

Đề nêu ba ràng buộc, và chỉ Global Accelerator thoả cả ba: | Ràng buộc | Vì sao loại các lựa chọn khác | |---|---| | Ứng dụng dùng UDP | CloudFront chỉ hỗ trợ HTTP/HTTPS | | Cần chuyển vùng NHANH khi một Region hỏng | DNS failover chậm vì bộ đệm | | Muốn TIẾP TỤC dùng dịch vụ DNS RIÊNG của công ty | loại Route 53 |

Vế thứ ba là điểm phân biệt quyết định:

"wants to continue using its own custom DNS service"
    ↓
    → không dùng Route 53
    → nhưng vẫn cần chuyển vùng nhanh
        ↓
    Global Accelerator cho HAI ĐỊA CHỈ IP ANYCAST TĨNH
    → trỏ bản ghi DNS của công ty vào hai IP đó
    → chuyển vùng xảy ra ở tầng MẠNG, không đụng tới DNS

Và đó cũng là lý do chuyển vùng nhanh:

Route 53 failover:
    Region hỏng → health check phát hiện → đổi bản ghi DNS
        → nhưng client và ISP đã CACHE bản ghi cũ
        → phải chờ hết TTL, có khi vài phút tới vài giờ

Global Accelerator:
    IP KHÔNG BAO GIỜ ĐỔI
    → AWS đổi đích phía sau IP đó
    → client không cần tra DNS lại
    → chuyển vùng trong khoảng 30 giây

Và Global Accelerator hỗ trợ UDP: | Giao thức | Global Accelerator | CloudFront | |---|---|---| | TCP | ✅ | ✅ (chỉ HTTP/HTTPS) | | UDP | ✅ | ❌ |

Thêm nữa, lưu lượng đi qua mạng xương sống riêng của AWS:

Người chơi → điểm biên AWS gần nhất (anycast)
    → mạng riêng của AWS (không đi Internet công cộng)
    → Region đích
        ↓
    Độ trễ thấp hơn và ổn định hơn — quan trọng với game

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

• **D. Amazon Route 53 — đây là phương án gần nhất và failover routing policy thực sự chuyển vùng được, nhưng nó vi phạm hai ràng buộc: công ty muốn giữ dịch vụ DNS riêng, và DNS failover chậm vì bộ đệm ở client và ISP — không đáp ứng "fast regional failover".
• **B. Amazon CloudFront — không hỗ trợ UDP: CloudFront là CDN cho HTTP/HTTPS. Game dùng UDP không đi qua được.
• **A. Elastic Load Balancing — chỉ hoạt động trong MỘT Region: ELB không chuyển vùng giữa các Region được. (NLB hỗ trợ UDP, nhưng đó không phải vấn đề ở đây.)

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ỉ IP | 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, API độ trễ thấp | web, video, nội dung tĩnh |

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

"UDP", "non-HTTP", "static IP", "fast regional failover", "own DNS" → Global Accelerator "cache", "static content", "video streaming", "HTTP" → CloudFront

Ba lợi ích của IP anycast tĩnh: | Lợi ích | Chi tiết | |---|---| | Không phụ thuộc bộ đệm DNS | chuyển vùng tức thì | | Đưa vào danh sách trắng của tường lửa | khách hàng doanh nghiệp cần điều này | | Giữ nguyên khi đổi kiến trúc phía sau | client không biết gì |

Và bạn mang được IP của mình vào (BYOIP):

Nếu công ty đã có dải IP công cộng riêng
    → đưa vào AWS và dùng cho Global Accelerator
    → khách hàng không phải cập nhật danh sách trắng

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ó TRỌNG SỐ lưu lượng | | Endpoint | ALB, NLB, EC2, hoặc Elastic IP |

Và trọng số cho phép triển khai theo tỷ lệ:

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

traffic-dial-percentage là công cụ triển khai xanh–lam và thử nghiệm dần — chuyển 10% lưu lượng sang Region mới trước.

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

Custom routing sinh ra cho game:

Nhiều phiên chơi trên cùng một fleet EC2
    → mỗi cổng ánh xạ tới một instance và cổng cụ thể
    → người chơi trong cùng trận luôn tới đúng máy chủ trận đó

Đây là tính năng rất phù hợp với công ty game trong đề.

Ba yếu tố quyết định định tuyến của Standard accelerator: | Yếu tố | Chi tiết | |---|---| | Sức khoẻ endpoint | không định tuyến tới endpoint hỏng | | Trọng số của endpoint group | traffic dial | | Vị trí địa lý của client | tới Region gần nhất khoẻ mạnh |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí cố định | ~0,025 USD mỗi giờ mỗi accelerator | | 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 chuyển vùng giữa Region: | Lựa chọn | Tốc độ chuyển vùng | |---|---| | Global Accelerator | ~30 giây | | Route 53 failover với TTL thấp | phút, phụ thuộc bộ đệm | | Route 53 ARC (Application Recovery Controller) | kiểm soát chuyển vùng chủ động, đắt hơn |

Và một lời khuyên về health check: Global Accelerator dùng health check của chính endpoint (ALB, NLB) để quyết định định tuyến. Hãy đảm bảo health check đó kiểm tra đường đi thật của ứng dụng chứ không chỉ trả về 200 từ một endpoint tĩnh — nếu không, Region đã hỏng về mặt chức năng vẫn được coi là khoẻ mạnh.

Đáp án

C — Bật DynamoDB Accelerator (DAX) cho DynamoDB và Amazon CloudFront cho S3.

Vì sao đúng

Đề cho một dữ kiện quyết định: 90% request đọc là cho dữ liệu DÙNG CHUNG giữa mọi người dùng.

Dữ liệu giống nhau cho mọi người
    → đệm được ở tầng chung
    → mỗi tầng dùng đúng công cụ đệm của nó

DAX cho DynamoDB:

DAX là bộ đệm trong bộ nhớ ĐƯỢC QUẢN LÝ, dành riêng cho DynamoDB
    ✓ độ trễ từ mili giây xuống MICRO GIÂY (nhanh hơn tới 10 lần)
    ✓ TƯƠNG THÍCH API — chỉ đổi client, không sửa mã truy vấn
    ✓ tự quản lý cache invalidation khi ghi qua DAX

# Trước
import boto3
bang = boto3.resource('dynamodb').Table('du-lieu-nguoi-dung')

# Sau — chỉ đổi client
from amazondax import AmazonDaxClient
dax = AmazonDaxClient.resource(endpoint_url='dax://cum-dax.abc.dax-clusters.amazonaws.com')
bang = dax.Table('du-lieu-nguoi-dung')

CloudFront cho S3:

CloudFront đệm nội dung tĩnh ở HƠN 600 ĐIỂM BIÊN toàn cầu
    ✓ ảnh phục vụ từ điểm gần người dùng
    ✓ giảm tải và giảm phí request cho S3
    ✓ giảm phí truyền dữ liệu ra Internet

Và mỗi công cụ đúng cho tầng của nó: | Tầng | Công cụ đúng | Lý do | |---|---|---| | DynamoDB | DAX | được thiết kế riêng, tương thích API | | S3 (nội dung tĩnh) | CloudFront | đệm ở biên, gần người dùng |

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

• **A. ElastiCache Redis cho DynamoDB và CloudFront cho S3 — đây là phương án gần nhất vì vế CloudFront đúng và Redis thực sự đệm được, nhưng vế đầu kém hơn rõ rệt: dùng ElastiCache với DynamoDB buộc bạn tự viết logic đệm — tự kiểm tra cache, tự nạp khi trượt, tự vô hiệu hoá khi ghi. DAX làm hết những việc đó và không đòi sửa mã truy vấn.
• **B. DAX cho DynamoDB và ElastiCache Memcached cho S3 — vế đầu đúng, vế sau sai bản chất: ElastiCache là bộ đệm trong VPC, không phục vụ nội dung tĩnh cho người dùng toàn cầu. Và nó không giảm được độ trễ do khoảng cách địa lý.
• **D. ElastiCache Redis cho DynamoDB và ElastiCache Memcached cho S3 — kết hợp cả hai điểm yếu trên.

Ghi nhớ

Bốn tầng đệm trên AWS — bảng cần thuộc: | Tầng | Dịch vụ | Đệm gì | |---|---|---| | Biên (gần người dùng) | CloudFront | nội dung tĩnh và động qua HTTP | | Ứng dụng | ElastiCache (Redis/Memcached) | kết quả truy vấn, phiên, tính toán | | Database DynamoDB | DAX | item và kết quả query/scan | | API | API Gateway cache | phản hồi của endpoint |

DAX và ElastiCache — bảng phân biệt: | | DAX | ElastiCache | |---|---|---| | Dùng cho | CHỈ DynamoDB | mọi nguồn dữ liệu | | Sửa mã ứng dụng | chỉ đổi client | phải viết logic đệm | | Vô hiệu hoá cache | tự động khi ghi qua DAX | tự lo | | Độ trễ | micro giây | micro giây | | Cấu trúc dữ liệu | chỉ item DynamoDB | phong phú (list, set, sorted set) |

Quy tắc: đệm DynamoDB thì dùng DAX, trừ khi cần cấu trúc dữ liệu của Redis.

Hai loại cache trong DAX: | Loại | Đệm gì | TTL mặc định | |---|---|---| | Item cache | GetItem, BatchGetItem | 5 phút | | Query cache | Query, Scan | 5 phút |

Và query cache bị xoá sạch khi có ghi vào bảng:

Ghi một item bất kỳ
    → toàn bộ query cache của bảng đó bị vô hiệu
    → vì DAX không biết ghi đó ảnh hưởng query nào
        ↓
    → Bảng ghi rất nhiều thì query cache gần như vô dụng

Với 90% là đọc dữ liệu chung như đề mô tả, DAX phát huy tối đa.

Ba lưu ý quan trọng về DAX: | Lưu ý | Chi tiết | |---|---| | Nhất quán CUỐI CÙNG | cần đọc nhất quán mạnh thì phải bỏ qua DAX | | Chỉ chạy trong VPC | không gọi từ Internet | | Có phí theo node-giờ | như ElastiCache |

Dòng đầu quan trọng: ConsistentRead=True đi thẳng tới DynamoDB, không qua cache. Với dữ liệu như số dư tài khoản, đó là điều bắt buộc.

Ba lợi ích của CloudFront cho S3: | Lợi ích | Chi tiết | |---|---| | Giảm độ trễ | phục vụ từ điểm biên gần người dùng | | Giảm chi phí | truyền dữ liệu từ CloudFront rẻ hơn từ S3 | | Giảm tải S3 | ít request hơn tới bucket |

Và Origin Access Control (OAC) khoá bucket lại:

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

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

OAC thay thế OAI (đã lỗi thời) — nó hỗ trợ SSE-KMS và mọi Region.

Ba cấu hình CloudFront cho ảnh: | Cấu hình | Chi tiết | |---|---| | TTL dài cho tài nguyên bất biến | đặt mã băm vào tên tệp | | Bật nén | Gzip và Brotli | | Chỉ chuyển tiếp header cần thiết | header thừa làm giảm tỷ lệ trúng cache |

Dòng cuối là lỗi hiệu năng phổ biến nhất với CloudFront: chuyển tiếp mọi header hoặc cookie khiến mỗi request thành một khoá cache riêng, tỷ lệ trúng cache về gần 0.

Ba metric để đo hiệu quả: | Metric | Ý nghĩa | |---|---| | CacheHitRate của DAX | thấp nghĩa là dữ liệu không dùng chung như tưởng | | CacheHitRate của CloudFront | nên trên 90% với nội dung tĩnh | | ConsumedReadCapacityUnits của DynamoDB | giảm mạnh sau khi bật DAX là dấu hiệu tốt |

Và một lời khuyên: hãy đo tỷ lệ trúng cache sau khi bật, đừng chỉ giả định. Con số "90% request cho dữ liệu chung" trong đề là kết quả phân tích — nếu DAX báo tỷ lệ trúng chỉ 40%, nghĩa là giả định đó không còn đúng và cần xem lại mẫu truy cập.

Đáp án

A và D.

• A — Dùng multipart upload để tải tệp nhanh hơn
• D — Dùng Amazon S3 Transfer Acceleration (S3TA)

Vì sao đúng

Đề mô tả hai vấn đề khác nhau, và hai đáp án giải quyết hai vấn đề đó: | Vấn đề | Giải pháp | |---|---| | Tệp video RẤT LỚN | multipart upload — tải song song nhiều phần | | Văn phòng ở CHÂU ÂU và CHÂU Á, bucket ở Mỹ | S3TA — đi qua mạng riêng của AWS |

A — multipart upload chia tệp thành nhiều phần tải song song:

Tệp video 20 GB, tải một lần:
    → một luồng TCP duy nhất
    → hỏng giữa chừng = làm lại từ đầu

Multipart, chia thành 200 phần 100 MB:
    → tải SONG SONG nhiều phần cùng lúc
    → tận dụng hết băng thông
    → phần nào hỏng chỉ tải lại phần đó

aws configure set default.s3.multipart_threshold 100MB
aws configure set default.s3.multipart_chunksize 100MB
aws configure set default.s3.max_concurrent_requests 20
aws s3 cp video-lon.mp4 s3://kho-video/

AWS CLI và SDK tự dùng multipart cho tệp lớn — thường chỉ cần chỉnh tham số.

D — S3TA giải quyết vấn đề khoảng cách:

Không có S3TA:
    Tokyo → Internet công cộng (nhiều chặng, mất gói) → bucket ở Mỹ

Có S3TA:
    Tokyo → điểm biên CloudFront tại Tokyo (rất gần)
          → MẠNG XƯƠNG SỐNG RIÊNG của AWS
          → bucket ở Mỹ
        ↓
    Nhanh hơn 50–500% với đường truyền xa

aws s3api put-bucket-accelerate-configuration   --bucket kho-video --accelerate-configuration Status=Enabled

aws s3 cp video.mp4 s3://kho-video/   --endpoint-url https://kho-video.s3-accelerate.amazonaws.com

Và hai cách này KẾT HỢP được với nhau — dùng đồng thời cho kết quả tốt nhất.

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

• **B. Tạo nhiều kết nối Direct Connect giữa AWS và các văn phòng ở châu Âu và châu Á — đây là phương án gần nhất vì Direct Connect thực sự cho băng thông ổn định và nhanh, nhưng nó cực kỳ đắt và chậm triển khai: chi phí hàng nghìn đô mỗi tháng mỗi kết nối, cộng phí chéo, và mất hàng tuần tới hàng tháng để lắp đặt. Đề hỏi cách tiết kiệm chi phí nhất.
• **E. Tạo nhiều kết nối Site-to-Site VPN — không tăng tốc gì: VPN vẫn chạy trên Internet công cộng, và việc mã hoá thêm còn làm chậm hơn. Nó giải quyết vấn đề riêng tư, không phải tốc độ.
• **C. Dùng AWS Global Accelerator — sai công cụ cho S3: Global Accelerator tăng tốc lưu lượng tới ALB, NLB, EC2 và Elastic IP — không hỗ trợ S3 làm endpoint. Công cụ tương đương cho S3 chính là S3TA.

Ghi nhớ

Ba cách tăng tốc tải lên S3 — giải quyết ba nút thắt khác nhau: | Cách | Giải quyết | |---|---| | Multipart upload | kích thước tệp — tải song song | | S3 Transfer Acceleration | khoảng cách địa lý | | Nhiều prefix | số request mỗi giây |

Nhầm lẫn giữa ba thứ này là lỗi phổ biến trong đề thi.

Ba ngưỡng của multipart upload: | Ngưỡng | Giá trị | |---|---| | Bắt buộc dùng | trên 5 GB | | AWS khuyến nghị | trên 100 MB | | Kích thước phần | 5 MB – 5 GB (phần cuối được nhỏ hơn) | | Số phần tối đa | 10.000 |

Và phần dở dang tính phí mãi mãi:

{"Rules": [{"Status": "Enabled",
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

Đây là lifecycle rule nên có ở MỌI bucket — phần dở dang không hiện trong danh sách object nhưng vẫn tính tiền.

Ba đặc điểm của S3 Transfer Acceleration: | Đặc điểm | Chi tiết | |---|---| | Dùng mạng điểm biên của CloudFront | vào mạng AWS sớm nhất có thể | | Endpoint riêng | bucket.s3-accelerate.amazonaws.com | | CHỈ tính phí khi THỰC SỰ nhanh hơn | không nhanh hơn thì không tính |

Dòng cuối rất đáng nhớ — AWS đo và chỉ tính phí khi có cải thiện thật.

Và có công cụ đo trước khi bật:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html

Nó so tốc độ tải lên có và không có S3TA từ vị trí của bạn tới mọi Region.

Ba trường hợp S3TA KHÔNG giúp ích: | Trường hợp | Lý do | |---|---| | Client ở CÙNG Region với bucket | đã gần rồi | | Tệp rất nhỏ | chi phí thiết lập lấn át lợi ích | | Nút thắt ở băng thông cuối cùng của văn phòng | S3TA không nới được đường truyền |

Dòng cuối quan trọng: nếu văn phòng chỉ có đường 50 Mbps, không cách nào tải nhanh hơn 50 Mbps.

Các lựa chọn di chuyển dữ liệu vào AWS — bảng cần thuộc: | Khối lượng | Công cụ | |---|---| | Tệp lẻ, liên tục | multipart + S3TA ← câu này | | Đồng bộ thư mục định kỳ | AWS DataSync | | Truy cập liên tục kiểu NFS | Storage Gateway File Gateway | | Hàng chục TB tới PB, băng thông kém | Snow Family | | Băng thông chuyên dụng lâu dài | Direct Connect |

Và DataSync đáng cân nhắc cho tình huống này:

DataSync:
    ✓ nhanh hơn công cụ mã nguồn mở tới 10 lần
    ✓ tự kiểm tra tính toàn vẹn
    ✓ lên lịch được, có báo cáo
    ✓ tự thử lại khi hỏng

Với việc đẩy footage từ văn phòng lên S3 hằng ngày, DataSync là lựa chọn vận hành tốt hơn script tự viết.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | S3TA | ~0,04–0,08 USD/GB thêm vào | | Direct Connect | phí cổng theo giờ + phí truyền, đắt nhất để khởi đầu | | Truyền vào S3 | miễn phí (không tính S3TA) |

Ba tối ưu khác cho video: | Tối ưu | Lợi ích | |---|---| | Nén trước khi tải | ít byte hơn thì nhanh hơn | | Tải lên bucket ở Region GẦN NHẤT rồi replicate | giảm đường truyền quốc tế | | Tăng số luồng song song của CLI | tận dụng hết băng thông |

Cách thứ hai đáng cân nhắc nghiêm túc:

Văn phòng Tokyo → bucket ở ap-northeast-1 (rất gần)
    → S3 Cross-Region Replication → bucket chính ở Mỹ
        ↓
    Người tải lên thấy nhanh ngay
    Việc sao chép quốc tế do AWS lo ở nền

Và một lời khuyên: hãy đo bằng công cụ so sánh tốc độ trước khi bật S3TA. Nó miễn phí và cho con số thật từ đúng vị trí văn phòng của bạn — nếu mức cải thiện chỉ vài phần trăm, khoản phí thêm mỗi GB không đáng.

Đáp án

C — Dùng Amazon SQS FIFO queue làm vùng đệm chuyển biểu mẫu từ tầng web sang tầng xử lý.

Vì sao đúng

Đề nêu một yêu cầu rất cụ thể: mỗi hồ sơ phải được xử lý ĐÚNG MỘT LẦN, không mất dữ liệu.

"every submitted request is processed EXACTLY ONCE, with NO LOSS of data"
    ↓
    → cần đảm bảo KHÔNG TRÙNG LẶP
    → và KHÔNG MẤT
        ↓
    SQS FIFO là dịch vụ duy nhất trong các phương án cho cả hai

Bảng đảm bảo của SQS: | | Standard | FIFO | |---|---|---| | Giao hàng | ít nhất một lần (có thể TRÙNG) | đúng một lần | | Thứ tự | cố gắng giữ, không đảm bảo | đảm bảo trong message group | | Thông lượng | gần như không giới hạn | 300/giây (3.000 khi gom lô) |

Và cơ chế khử trùng của FIFO:

Mỗi thông điệp có MessageDeduplicationId
    → trong cửa sổ 5 PHÚT, thông điệp cùng id bị BỎ QUA
    → gửi lại do lỗi mạng không tạo ra bản ghi thứ hai

sqs.send_message(
    QueueUrl=url,
    MessageBody=json.dumps(ho_so),
    MessageGroupId='don-xin-giay-phep',
    MessageDeduplicationId=ma_ho_so)   # id nghiệp vụ, không phải ngẫu nhiên

Và hàng đợi cũng giải quyết vế "lưu lượng cao":

Đỉnh tải:
    → hồ sơ vào hàng đợi ngay, người dân nhận xác nhận
    → tầng xử lý làm việc theo tốc độ của nó
    → không mất hồ sơ nào dù tầng xử lý tạm ngừng

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

• **B. Dùng SQS STANDARD queue — đây là phương án gần nhất và cũng là hàng đợi, cũng không mất dữ liệu, nhưng nó vi phạm vế "exactly once": Standard queue giao ít nhất một lần, nghĩa là cùng một hồ sơ có thể được giao hai lần. Với đơn xin giấy phép, xử lý trùng là tạo ra hai hồ sơ cho một người.
• **A. API Gateway → Lambda xử lý thời gian thực — không có vùng đệm: Lambda bị throttle hoặc lỗi thì request hỏng và hồ sơ mất. Không có cơ chế nào đảm bảo xử lý đúng một lần.
• **D. Dùng Amazon EventBridge gửi sự kiện sang tầng xử lý — EventBridge cũng giao ít nhất một lần và không có cơ chế khử trùng dựng sẵn. Nó là bus định tuyến sự kiện, không phải hàng đợi bền bỉ có đảm bảo exactly-once.

Ghi nhớ

SQS FIFO — ba đảm bảo cần nhớ: | Đảm bảo | Cơ chế | |---|---| | Đúng một lần | MessageDeduplicationId, cửa sổ 5 phút | | Đúng thứ tự | MessageGroupId | | Không mất | lưu bền, chỉ xoá khi consumer xác nhận |

Hai id của FIFO — phân biệt rõ: | Id | Việc | |---|---| | MessageGroupId | nhóm cần giữ thứ tự — các nhóm khác nhau xử lý SONG SONG | | MessageDeduplicationId | khoá khử trùng |

Và MessageGroupId quyết định thông lượng:

Một message group → xử lý TUẦN TỰ, một thông điệp một lúc
Nhiều message group → xử lý SONG SONG
    ↓
Chỉ cần thứ tự trong phạm vi một hồ sơ?
    → dùng mã hồ sơ làm MessageGroupId
    → hàng nghìn hồ sơ xử lý song song

Đây là cách vừa giữ đảm bảo vừa đạt thông lượng cao.

Và high-throughput FIFO nâng trần lên rất cao:

FIFO thường:           300 thông điệp/giây (3.000 khi gom lô 10)
High-throughput FIFO:  tới 70.000/giây ở một số Region
    → bật bằng cách đặt DeduplicationScope = messageGroup
      và FifoThroughputLimit = perMessageGroupId

Ba cấu hình SQS quan trọng: | Cấu hình | Chi tiết | |---|---| | Visibility timeout | dài hơn thời gian xử lý, nếu không sẽ xử lý hai lần | | Dead-letter queue | thông điệp hỏng sau N lần thử | | Message retention | 1 phút – 14 ngày (mặc định 4 ngày) |

Visibility timeout là nguyên nhân xử lý trùng phổ biến nhất:

Visibility timeout = 30 giây, xử lý mất 45 giây
    → sau 30 giây thông điệp hiện lại
    → consumer thứ hai nhận và xử lý CÙNG một hồ sơ
        ↓
    → Đặt visibility timeout ≥ thời gian xử lý dài nhất
    → hoặc gọi ChangeMessageVisibility để gia hạn

Ba lớp đảm bảo idempotency — nên có nhiều lớp: | Lớp | Cơ chế | |---|---| | SQS FIFO | khử trùng trong 5 phút | | Khoá UNIQUE trong database | lưới an toàn cuối cùng, không giới hạn thời gian | | Bảng idempotency riêng | ghi mã hồ sơ đã xử lý |

Cửa sổ khử trùng của FIFO chỉ 5 phút — thông điệp gửi lại sau 6 phút sẽ lọt qua. Với dữ liệu quan trọng, ràng buộc ở database là bắt buộc.

Ba lựa chọn nhắn tin trên AWS — bảng phân biệt: | Dịch vụ | Mô hình | Đảm bảo | |---|---|---| | SQS | hàng đợi, một consumer nhận | bền, có FIFO | | SNS | phát tán, nhiều subscriber | ít nhất một lần | | EventBridge | bus định tuyến theo quy tắc | ít nhất một lần | | Kinesis Data Streams | stream, đọc lại được | thứ tự trong shard |

Và SNS cũng có FIFO topic — ghép với SQS FIFO queue để phát tán mà vẫn giữ đảm bảo.

Ba cách co giãn tầng xử lý: | Cách | Đặc điểm | |---|---| | Lambda với SQS event source | đơn giản nhất, tự co giãn | | ECS/EC2 với ASG theo độ sâu hàng đợi | cho việc chạy lâu | | Lambda + hàm xử lý lô | giảm số lần gọi |

Lưu ý với Lambda + FIFO: số lượt đồng thời bị giới hạn bởi số message group, không phải bởi hạn mức Lambda. Một message group cho toàn hệ thống nghĩa là chỉ một lượt Lambda chạy tại một thời điểm.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | tăng dần = xử lý không kịp | | ApproximateNumberOfMessagesVisible | độ sâu hàng đợi | | Số thông điệp trong DLQ | > 0 là phải xem ngay |

Và một lời khuyên cho hệ thống của cơ quan nhà nước: hãy đặt alarm cho DLQ có thông điệp. Một hồ sơ xin giấy phép rơi vào DLQ nghĩa là có người dân đã nộp mà không được xử lý — và họ sẽ không biết cho tới khi đi hỏi.

Đáp án

B — Dùng Amazon CloudFront với custom origin trỏ thẳng tới các máy chủ tại chỗ.

Vì sao đúng

Đề nêu bốn ràng buộc, và đáp án thoả cả bốn: | Ràng buộc | Cơ chế | |---|---| | Tối ưu thời gian tải cho người dùng ở châu Á | CloudFront có điểm biên khắp châu Á | | Backend PHẢI ở lại Mỹ | custom origin — không di chuyển gì | | Ra mắt trong VÀI NGÀY | cấu hình CloudFront mất vài giờ | | Website ĐỘNG | CloudFront phục vụ cả nội dung động |

CloudFront hỗ trợ origin ngoài AWS:

Custom origin có thể là:
    ✓ máy chủ TẠI CHỖ trong trung tâm dữ liệu của bạn
    ✓ ALB, EC2
    ✓ bất kỳ máy chủ HTTP nào có tên miền công khai

Và với website động, lợi ích không chỉ là đệm:

Người dùng ở Singapore → điểm biên CloudFront tại Singapore
    → kết nối TCP và bắt tay TLS diễn ra RẤT GẦN (độ trễ thấp)
    → từ điểm biên về Mỹ đi qua MẠNG XƯƠNG SỐNG RIÊNG của AWS
        ↓
    Nhanh hơn đáng kể ngay cả với nội dung KHÔNG ĐỆM ĐƯỢC

Vì sao mạng riêng nhanh hơn: | Yếu tố | Internet công cộng | Mạng AWS | |---|---|---| | Số chặng | nhiều, khó đoán | ít, tối ưu | | Mất gói | cao hơn | thấp | | Kết nối tới origin | mỗi người dùng một kết nối mới | giữ sẵn (keep-alive) |

Và cấu hình cho nội dung động:

aws cloudfront create-distribution --distribution-config '{
  "Origins": {"Items": [{
    "Id": "may-chu-tai-cho",
    "DomainName": "goc.congty.com",
    "CustomOriginConfig": {
      "HTTPSPort": 443, "OriginProtocolPolicy": "https-only",
      "OriginKeepaliveTimeout": 60}}]},
  "DefaultCacheBehavior": {
    "TargetOriginId": "may-chu-tai-cho",
    "ViewerProtocolPolicy": "redirect-to-https",
    "CachePolicyId": "<chinh-sach-cho-noi-dung-dong>"}}'

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

• **C. CloudFront với custom origin trỏ tới bản ghi DNS của website trên Route 53 — đây là phương án gần nhất và gần như đúng, nhưng nó thêm một lớp thừa và một phụ thuộc mới: origin của CloudFront cần một tên miền phân giải được tới máy chủ, không cần đi qua Route 53. Và đề không nói công ty đang dùng Route 53 — buộc phải chuyển DNS sang Route 53 là công việc thêm trong lúc chỉ còn vài ngày.
• **A. Dùng Route 53 geo-proximity routing trỏ tới máy chủ tại chỗ — không tăng tốc gì: chỉ có MỘT nhóm máy chủ ở Mỹ. Định tuyến theo vị trí địa lý chỉ có ý nghĩa khi có nhiều điểm phục vụ để chọn.
• **D. Chuyển website sang S3 và dùng Cross-Region Replication — hai lỗi: website là ĐỘNG, S3 chỉ phục vụ nội dung tĩnh. Và đề yêu cầu backend ở lại Mỹ, việc di chuyển là thay đổi lớn không làm được trong vài ngày.

Ghi nhớ

Bốn loại origin của CloudFront: | Loại | Ví dụ | |---|---| | S3 origin | bucket nội dung tĩnh | | Custom origin | ALB, EC2, hoặc MÁY CHỦ TẠI CHỖ ← câu này | | Lambda function URL | serverless | | MediaPackage | video streaming |

CloudFront không chỉ để đệm — ba lợi ích cho nội dung ĐỘNG: | Lợi ích | Chi tiết | |---|---| | Kết thúc TLS ở biên | bắt tay diễn ra gần người dùng — tiết kiệm nhiều vòng lượt | | Kết nối keep-alive tới origin | không phải bắt tay lại cho mỗi người dùng | | Mạng riêng của AWS | ít mất gói, đường đi tối ưu |

Số vòng lượt tiết kiệm được rất đáng kể:

Không có CloudFront (Singapore → Mỹ, RTT ~200ms):
    Bắt tay TCP (1 RTT) + TLS (2 RTT) + request (1 RTT) = 4 × 200ms = 800ms

Có CloudFront (bắt tay tại Singapore, RTT ~5ms):
    Bắt tay tại biên: 4 × 5ms = 20ms
    + một chặng tới origin qua mạng AWS
        ↓
    Cải thiện rất lớn ngay cả khi KHÔNG đệm được gì

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 (header, cookie, query string) | | 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 Authorization, nhưng không nên đưa vào khoá cache
    → cache policy: KHÔNG gồm Authorization
    → origin request policy: CÓ chuyển tiếp Authorization
        ↓
    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ấu hình bảo mật nên có: | Cấu hình | Chi tiết | |---|---| | OriginProtocolPolicy: https-only | mã hoá cả chặng tới origin | | Custom header bí mật | origin chỉ nhận request có header đó — chặn truy cập trực tiếp | | AWS WAF trên distribution | lọc tấn công ở biên |

Custom header là cách khoá origin tại chỗ:

CloudFront thêm: X-Origin-Verify: <chuỗi bí mật>
    → máy chủ tại chỗ TỪ CHỐI request không có header đó
    → không ai vòng qua CloudFront được

Nên xoay vòng chuỗi bí mật đó định kỳ.

Ba tính năng tăng tốc thêm: | Tính năng | Lợi ích | |---|---| | Origin Shield | thêm một lớp đệm giữa biên và origin — giảm mạnh tải origin | | Nén tự động | Gzip và Brotli | | HTTP/3 (QUIC) | nhanh hơn trên mạng di động |

Origin Shield rất phù hợp với origin tại chỗ:

Không có Origin Shield:
    600 điểm biên đều có thể gọi thẳng về máy chủ ở Mỹ

Có Origin Shield:
    600 điểm biên → 1 điểm shield → máy chủ
        ↓
    Giảm rất nhiều lưu lượng về trung tâm dữ liệu

Ba lưu ý khi ra mắt gấp: | Lưu ý | Chi tiết | |---|---| | Distribution mất 5–15 phút để triển khai | mỗi lần sửa cũng vậy | | Chứng chỉ ACM phải ở us-east-1 | yêu cầu bắt buộc của CloudFront | | Thử với TTL ngắn trước | dễ sửa nếu đệm nhầm nội dung cá nhân hoá |

Dòng giữa là lỗi hay gặp nhất khi triển khai gấp — chứng chỉ tạo ở Region khác sẽ không hiện ra trong danh sách chọn của CloudFront.

Và một lời khuyên: hãy kiểm tra kỹ những gì được đệm trước khi mở cho người dùng thật. Đệm nhầm một trang có thông tin đăng nhập của người dùng và phục vụ nó cho người khác là sự cố bảo mật nghiêm trọng — với website động, mặc định an toàn là CachingDisabled rồi mở dần cho từng đường dẫn tĩnh.