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

Đáp án

B — Cài Amazon CloudWatch agent lên mọi EC2 instance để thu thập dữ liệu bộ nhớ và dung lượng đĩa, rồi xem các custom metric đó trong CloudWatch Console.

Vì sao đúng

Đề yêu cầu giám sát bộ nhớ và dung lượng đĩa cho cả instance Linux lẫn Windows — và đó là hai metric mà CloudWatch không tự có.

Nguyên nhân nằm ở ranh giới hypervisor:

CloudWatch lấy metric từ HYPERVISOR
    → thấy: CPU, mạng, I/O đĩa
    → KHÔNG thấy vào bên trong hệ điều hành khách

Bộ nhớ đã dùng và dung lượng đĩa còn trống
    → là thông tin BÊN TRONG hệ điều hành
    → phải có AGENT chạy trong máy để báo ra

Unified CloudWatch agent hỗ trợ cả hai nền tảng — đúng nhu cầu của đề:

{
  "metrics": {
    "metrics_collected": {
      "mem": {"measurement": ["mem_used_percent"]},
      "disk": {"measurement": ["disk_used_percent"], "resources": ["*"]},
      "LogicalDisk": {"measurement": ["% Free Space"]}
    },
    "append_dimensions": {"InstanceId": "${aws:InstanceId}"}
  }
}

(mem và disk cho Linux; LogicalDisk và Memory cho Windows.)

Và triển khai ở quy mô lớn nên dùng Systems Manager:

aws ssm send-command   --document-name "AWS-ConfigureAWSPackage"   --parameters '{"action":["Install"],"name":["AmazonCloudWatchAgent"]}'   --targets "Key=tag:MoiTruong,Values=production"

Lưu cấu hình trong SSM Parameter Store để sửa một chỗ và mọi máy nạp lại được — thay vì sửa tệp trên từng máy.

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

• C. Bật tuỳ chọn Enhanced Monitoring trong EC2 và cài CloudWatch agent để xem bộ nhớ và dung lượng đĩa — đây là phương án gần nhất và có vế cài agent đúng, nhưng "Enhanced Monitoring" là tính năng của RDS, không phải EC2. EC2 có "detailed monitoring" (giảm chu kỳ từ 5 phút xuống 1 phút), và nó không thêm metric bộ nhớ hay đĩa nào.
• A. Dùng cấu hình CloudWatch mặc định vì metric bộ nhớ và đĩa đã có sẵn; cài SSM Agent lên mọi instance — sai tiền đề: hai metric đó không có sẵn. Và SSM Agent phục vụ quản lý vận hành (chạy lệnh, vá lỗi, Session Manager), không thu thập metric hệ thống.
• D. Dùng Amazon Inspector và cài Inspector agent lên mọi instance — sai chức năng: Inspector quét lỗ hổng bảo mật (CVE) và khả năng tiếp cận mạng. Nó không phải công cụ giám sát hiệu năng.

Ghi nhớ

Quy tắc phân biệt — thuộc lòng cái này là trả lời được cả nhóm câu hỏi:

Hypervisor nhìn thấy được → CloudWatch có sẵn Chỉ hệ điều hành bên trong biết → cần agent

Chú ý khác biệt tinh tế: hoạt động đọc ghi đĩa (DiskReadOps) có sẵn, nhưng dung lượng đĩa còn trống thì không — hypervisor đếm được thao tác I/O nhưng không biết hệ thống tệp bên trong đầy bao nhiêu.

Cùng nguyên tắc áp cho các dịch vụ khác: | Dịch vụ | Công cụ cho metric mức hệ điều hành | |---|---| | EC2 | CloudWatch agent ← câu này | | RDS | Enhanced Monitoring (xem câu #8127) | | ECS / EKS | Container Insights | | Lambda | Lambda Insights |

Ba khả năng của unified CloudWatch agent: | Khả năng | Chi tiết | |---|---| | Metric hệ thống | bộ nhớ, đĩa, swap, tiến trình, kết nối TCP | | Log | tệp log ứng dụng, Windows Event Log, systemd journal | | Trace | qua OpenTelemetry, X-Ray |

Quyền cần cho agent — managed policy CloudWatchAgentServerPolicy:

cloudwatch:PutMetricData
ec2:DescribeVolumes, ec2:DescribeTags
logs:CreateLogGroup, CreateLogStream, PutLogEvents, DescribeLogStreams
ssm:GetParameter

Ba lỗi thường gặp khi agent không gửi metric: | Lỗi | Triệu chứng | |---|---| | Thiếu quyền cloudwatch:PutMetricData | agent chạy nhưng không có metric nào | | Tạo AMI SAU khi agent đã chạy | tệp trạng thái cũ gây lỗi (xem câu #7771) | | Sai đường dẫn trong cấu hình | thu thập sai thứ |

Nơi gỡ lỗi đầu tiên luôn là log của chính agent:

/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log

Hai lưu ý về chi phí custom metric: | Lưu ý | Chi tiết | |---|---| | Tính phí theo số metric | mỗi tổ hợp dimension là một metric riêng | | Tránh dimension độ phân giải cao | đừng thêm request ID hay timestamp làm dimension |

Với đội máy lớn, hãy cân nhắc thu thập ít metric hơn: mem_used_percent và disk_used_percent thường là đủ để đặt cảnh báo — thu thập cả chục metric bộ nhớ chi tiết cho hàng nghìn máy sẽ tốn đáng kể mà ít khi ai nhìn tới.

Và vì sao hai metric này quan trọng: rò rỉ bộ nhớ và đĩa đầy là hai nguyên nhân sự cố phổ biến nhất mà CloudWatch mặc định hoàn toàn không thấy — ứng dụng chết dần trong khi biểu đồ CPU vẫn bình thường.

Đáp án

A, B và E:

• A — Người dùng có policy này đọc được object từ MỌI S3 bucket thuộc tài khoản
• B — Người dùng ghi được object vào bucket boracay
• E — Người dùng đọc được object từ bucket boracay

Vì sao đúng

Policy có hai statement, và phân tích từng cái là ra hết:

Statement 1 — quyền đọc rộng:

{"Effect": "Allow", "Action": ["s3:Get*", "s3:List*"], "Resource": "*"}

→ A đúng (đọc mọi bucket) và E đúng (boracay nằm trong "mọi bucket").

Statement 2 — quyền ghi hẹp:

{"Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::boracay/*"}

→ B đúng: chỉ PutObject, chỉ trên object của bucket boracay.

Tổng hợp quyền hiệu lực: | Thao tác | Bucket boracay | Bucket khác | |---|---|---| | Đọc object | ✅ | ✅ | | Liệt kê | ✅ | ✅ | | Ghi object | ✅ | ❌ | | Xoá object | ❌ | ❌ | | Đổi quyền truy cập | ❌ | ❌ |

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

• F. Người dùng đọc VÀ XOÁ object từ bucket boracay — đây là phương án gần nhất và sai ở vế xoá: s3:DeleteObject không được cấp ở đâu cả. s3:Get* không bao gồm xoá, và statement thứ hai chỉ có PutObject.
• C. Người dùng đổi được quyền truy cập (access rights) cho bucket boracay — sai: đổi quyền cần s3:PutBucketAcl, s3:PutBucketPolicy hoặc s3:PutObjectAcl. Statement thứ hai chỉ có s3:PutObject, không phải s3:Put*.
• D. Người dùng đọc được object trong boracay nhưng KHÔNG liệt kê được object trong bucket — sai: s3:List* với Resource: "*" cho phép ListBucket trên mọi bucket, bao gồm boracay.

Ghi nhớ

Nguyên tắc đọc một IAM policy:

① Đọc TỪNG statement độc lập
② Quyền hiệu lực = HỢP của mọi statement Allow
③ Bất kỳ statement Deny nào cũng THẮNG mọi Allow
④ Không có Allow nào khớp = từ chối ngầm định

Ký tự đại diện trong Action — đọc chính xác rất quan trọng: | Mẫu | Bao gồm | |---|---| | s3:Get* | mọi hành động bắt đầu bằng Get | | s3:PutObject | CHỈ đúng hành động này | | s3:Put* | PutObject, PutBucketPolicy, PutBucketAcl... — rộng hơn nhiều | | s3:* | mọi hành động S3 |

Khác biệt giữa s3:PutObject và s3:Put* là điểm phân biệt của phương án C — và trong thực tế là khác biệt giữa "ghi tệp" và "đổi được cả chính sách bảo mật của bucket".

Hai dạng ARN của S3 — phải khai đúng: | ARN | Dùng cho hành động | |---|---| | arn:aws:s3:::bucket | ListBucket, GetBucketLocation, PutBucketPolicy | | arn:aws:s3:::bucket/* | GetObject, PutObject, DeleteObject |

Lỗi hay gặp nhất với S3 policy: khai thiếu một trong hai dạng. Triệu chứng là "liệt kê được nhưng không tải xuống được", hoặc ngược lại.

Các hành động S3 hay bị nhầm nhóm: | Hành động | Nhóm | |---|---| | s3:GetObject | đọc nội dung object | | s3:ListBucket | liệt kê object — thao tác trên BUCKET, không phải object | | s3:PutObject | tải object lên | | s3:DeleteObject | xoá — KHÔNG nằm trong Get* hay Put* | | s3:PutObjectAcl | đổi quyền của object — nằm trong Put* nhưng KHÔNG trong PutObject |

Dòng cuối là chi tiết bảo mật quan trọng: cấp s3:Put* vô tình cho phép người dùng đặt object thành công khai qua PutObjectAcl — đó là lý do nên cấp s3:PutObject cụ thể thay vì dùng ký tự đại diện.

Ba nguyên tắc viết policy an toàn: | Nguyên tắc | Lý do | |---|---| | Liệt kê hành động cụ thể, tránh * | biết chính xác đang cấp gì | | Giới hạn Resource tới đúng bucket và prefix | Resource: "*" như statement 1 là quá rộng | | Thêm điều kiện khi có thể | aws:SourceVpce, aws:SecureTransport, MFA |

Statement 1 của policy trong đề là ví dụ điển hình về quyền quá rộng: nó cho đọc mọi bucket trong tài khoản, kể cả bucket chứa log kiểm toán hay dữ liệu nhạy cảm của đội khác. Trong thực tế nên thu hẹp Resource xuống đúng những bucket cần thiết.

Và một công cụ nên dùng: IAM Access Analyzer policy validation rà policy và cảnh báo về quyền quá rộng, cú pháp sai, hoặc quyền chưa từng được dùng — chạy nó trước khi triển khai tiết kiệm nhiều rắc rối về sau.

Đáp án

D — Dùng Signed Cookies để kiểm soát ai truy cập được các tệp riêng tư trong CloudFront distribution. Sửa ứng dụng để xác định người dùng có quyền hay không; với thành viên, gửi các header Set-Cookie cần thiết để mở khoá nội dung.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai đều chỉ tới signed cookie thay vì signed URL: | Yêu cầu | Cơ chế | |---|---| | NHIỀU tệp riêng tư | một cookie mở khoá cả nhóm tệp | | KHÔNG đổi URL hiện tại | cookie đi kèm request, URL giữ nguyên |

Đây chính là khác biệt định nghĩa giữa hai cơ chế:

Signed URL:
    https://cdn.vidu.com/phim.mp4?Expires=...&Signature=...&Key-Pair-Id=...
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                  URL BỊ THAY ĐỔI
    → mỗi tệp một URL ký riêng

Signed Cookie:
    https://cdn.vidu.com/phim.mp4          ← URL GIỮ NGUYÊN
    Cookie: CloudFront-Policy=...; CloudFront-Signature=...; CloudFront-Key-Pair-Id=...
    → một bộ cookie mở khoá MỌI tệp khớp policy

Bảng chọn — thuộc bảng này là trả lời được mọi câu hỏi dạng này: | | Signed URL | Signed Cookie | |---|---|---| | Phạm vi | MỘT tệp | NHIỀU tệp theo mẫu đường dẫn | | URL có đổi không | ✅ CÓ | ❌ KHÔNG | | Phù hợp | tải một tệp, link chia sẻ | thư viện nội dung, streaming | | Client cần hỗ trợ | không đặc biệt | phải hỗ trợ cookie |

Custom policy trong cookie cho phép giới hạn theo mẫu đường dẫn:

{
  "Statement": [{
    "Resource": "https://cdn.vidu.com/thanh-vien/*",
    "Condition": {
      "DateLessThan": {"AWS:EpochTime": 1756598400},
      "IpAddress": {"AWS:SourceIp": "203.0.113.0/24"}
    }
  }]
}

Luồng đầy đủ:

Người dùng đăng nhập
    ↓ ứng dụng kiểm tra: có phải thành viên trả phí không?
    ↓ nếu có: sinh chữ ký và gửi 3 header Set-Cookie
Trình duyệt lưu cookie
    ↓ mọi request tới CDN tự động kèm cookie
CloudFront xác minh chữ ký → phục vụ nội dung

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

• B. Tạo Signed URL với custom policy chỉ cho thành viên xem tệp riêng tư — đây là phương án gần nhất và cũng bảo vệ được nội dung, nhưng nó vi phạm yêu cầu "without having to change the current URLs": signed URL bắt buộc phải thêm tham số truy vấn vào URL.
• C. Cấu hình CloudFront dùng Field-Level Encryption để bảo vệ dữ liệu riêng tư và chỉ cho thành viên truy cập — sai mục đích hoàn toàn: field-level encryption mã hoá các trường nhạy cảm mà NGƯỜI DÙNG GỬI LÊN (số thẻ tín dụng trong form). Nó không kiểm soát ai xem được nội dung tải xuống.
• A. Cấu hình CloudFront dùng Match Viewer làm Origin Protocol Policy để tự động khớp yêu cầu người dùng, cho phép nếu là thành viên và từ chối nếu không — hiểu sai hoàn toàn tính năng: Match Viewer chỉ quyết định CloudFront dùng HTTP hay HTTPS khi kết nối tới origin, khớp với giao thức mà người xem đã dùng. Nó không liên quan gì tới xác thực.

Ghi nhớ

Ba cách hạn chế truy cập nội dung trong CloudFront: | Cách | Kiểm soát theo | |---|---| | Signed URL | từng tệp, có thời hạn | | Signed Cookie | nhóm tệp, có thời hạn ← câu này | | Geo restriction | quốc gia (miễn phí) | | WAF | IP, quy tắc tầng 7 |

Ba cookie mà CloudFront yêu cầu:

CloudFront-Policy       — policy đã mã hoá base64
CloudFront-Signature    — chữ ký của policy
CloudFront-Key-Pair-Id  — định danh cặp khoá dùng để ký

Thiếu một trong ba là CloudFront từ chối — cả ba phải được gửi cùng nhau.

Hai loại policy cho signed URL và cookie: | Loại | Đặc điểm | |---|---| | Canned policy | chỉ đặt được thời hạn; URL ngắn hơn; CHỈ cho signed URL | | Custom policy | thêm được dải IP, thời điểm bắt đầu, mẫu đường dẫn có ký tự đại diện |

Signed cookie BẮT BUỘC dùng custom policy — đó cũng là lý do nó hỗ trợ mẫu đường dẫn.

Hai cơ chế quản lý khoá ký: | Cơ chế | Trạng thái | |---|---| | Trusted key groups | KHUYẾN NGHỊ hiện nay — quản lý bằng CloudFront API | | Trusted signers (CloudFront key pair) | cơ chế cũ — đòi thông tin đăng nhập root |

Dòng thứ hai là lý do nên chuyển sang key group: tạo CloudFront key pair cũ yêu cầu đăng nhập bằng root user, trái với mọi thực hành bảo mật.

Ba lưu ý khi triển khai signed cookie: | Lưu ý | Chi tiết | |---|---| | Cookie gắn với TÊN MIỀN | dùng custom domain, không dùng *.cloudfront.net | | Đặt Secure và HttpOnly | ngăn đánh cắp qua JavaScript | | Thời hạn ngắn, làm mới định kỳ | cookie bị lộ thì nhanh vô dụng |

Và điều kiện tiên quyết mà đề không nhắc tới: origin S3 phải được khoá lại bằng OAC. Nếu bucket vẫn truy cập công khai, người ta gọi thẳng URL của S3 và bỏ qua toàn bộ cơ chế signed cookie — mọi biện pháp ở tầng CDN trở nên vô nghĩa.

Và với nội dung streaming (video HLS hoặc DASH), signed cookie gần như là lựa chọn bắt buộc: một video được chia thành hàng trăm segment, và ký từng URL segment là bất khả thi trong thực tế.

Đáp án

C — Instance EC2 được khởi chạy từ launch template CŨ NHẤT.

Vì sao đúng

Đề nói Auto Scaling group dùng cấu hình mặc định, nên câu trả lời nằm ở default termination policy của AWS.

Thuật toán chọn instance để chấm dứt, theo thứ tự:

① Chọn AZ có NHIỀU instance nhất
   (trong số các AZ còn instance không được bảo vệ khỏi scale-in)
        ↓
② Trong AZ đó, chọn instance dùng LAUNCH TEMPLATE hoặc
   LAUNCH CONFIGURATION CŨ NHẤT          ← câu trả lời
        ↓
③ Nếu vẫn còn nhiều, chọn instance GẦN NHẤT với mốc tính phí giờ tiếp theo
        ↓
④ Nếu vẫn hoà, chọn NGẪU NHIÊN

Vì sao AWS thiết kế bước ① trước: mục tiêu hàng đầu là giữ cân bằng giữa các AZ. Chấm dứt instance ở AZ đông nhất giữ cho ứng dụng phân bố đều — nếu không, sau vài đợt scale-in bạn có thể còn toàn bộ instance trong một AZ và mất tính sẵn sàng.

Và bước ② phục vụ mục tiêu làm mới đội máy: instance chạy cấu hình cũ được thay dần bằng instance dùng cấu hình mới nhất — nên việc cập nhật launch template sẽ tự lan ra theo thời gian.

Đề nói ba AZ và cấu hình mặc định, nên nếu các AZ đang cân bằng thì bước ① không phân định được, và bước ② quyết định — đúng như đáp án C.

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

• B. Instance chạy lâu nhất — đây là phương án gần nhất và là hiểu lầm phổ biến nhất về Auto Scaling: "thời gian chạy" không phải tiêu chí nào trong default termination policy. Nó thường tương quan với launch template cũ, nhưng không phải cùng một thứ — một instance mới khởi chạy từ template cũ vẫn bị chọn trước.
• D. Instance được chọn ngẫu nhiên — chỉ đúng ở bước cuối cùng, sau khi cả ba tiêu chí trên đều hoà. Nó không phải tiêu chí đầu tiên.
• A. Instance có ít phiên người dùng nhất — Auto Scaling không biết gì về phiên người dùng: đó là thông tin ở tầng ứng dụng. ASG chỉ nhìn thấy instance, AZ, cấu hình khởi chạy và mốc tính phí.

Ghi nhớ

Các chính sách chấm dứt của Auto Scaling — chọn được thay cho mặc định: | Chính sách | Chọn instance | |---|---| | Default | theo thuật toán bốn bước ở trên | | OldestInstance | chạy lâu nhất — cho việc nâng cấp loại instance | | NewestInstance | mới nhất — cho việc quay lui bản triển khai thử | | OldestLaunchConfiguration | dùng cấu hình cũ nhất | | OldestLaunchTemplate | dùng template cũ nhất | | ClosestToNextInstanceHour | tối ưu chi phí theo giờ | | AllocationStrategy | cân bằng theo chiến lược phân bổ (Spot) |

Có thể xếp chồng nhiều chính sách — ASG áp dụng lần lượt cho tới khi còn một ứng viên:

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-ung-dung   --termination-policies "OldestLaunchTemplate" "ClosestToNextInstanceHour"

Ba cách bảo vệ instance khỏi bị chấm dứt: | Cách | Chi tiết | |---|---| | Instance scale-in protection | bảo vệ một instance cụ thể | | Group-level scale-in protection | áp cho mọi instance mới | | Lifecycle hook | tạm dừng để hoàn tất công việc trước khi chấm dứt |

Lifecycle hook là công cụ quan trọng cho ứng dụng có trạng thái: nó cho instance thời gian đẩy log lên, hoàn tất request đang xử lý, rút khỏi cụm trước khi bị tắt:

aws autoscaling put-lifecycle-hook   --lifecycle-hook-name don-dep-truoc-khi-tat   --auto-scaling-group-name asg-ung-dung   --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING   --heartbeat-timeout 300

Và với ứng dụng web sau load balancer, deregistration_delay (connection draining) mới là cơ chế quan trọng nhất: nó khiến ALB ngừng gửi request mới tới instance sắp tắt nhưng vẫn để các request đang xử lý hoàn tất — mặc định 300 giây, điều chỉnh được.

Ba lưu ý về launch template so với launch configuration: | | Launch template | Launch configuration | |---|---|---| | Trạng thái | khuyến nghị hiện nay | cơ chế cũ, không thêm tính năng mới | | Sửa được | có phiên bản, tạo version mới | BẤT BIẾN — phải tạo cái mới | | Hỗ trợ mixed instance, Spot | ✅ | hạn chế |

Launch template có phiên bản là chi tiết liên quan tới câu hỏi này: "template cũ nhất" thực ra so sánh theo phiên bản mà instance được khởi chạy từ đó.

Và một lưu ý thực dụng: nếu bạn muốn thay thế có kiểm soát toàn bộ đội máy sau khi cập nhật cấu hình, đừng dựa vào việc scale-in tự nhiên — dùng instance refresh (xem câu #7793). Nó thay thế theo lô với tỷ lệ lành mạnh được đảm bảo, thay vì chờ một sự kiện giảm tải nào đó xảy ra.

Đáp án

A — Cấu hình S3 bucket gỡ bỏ quyền đọc công khai và dùng pre-signed URL có thời hạn.

Vì sao đúng

Đề mô tả hiện tượng hotlinking: các trang web khác nhúng thẳng ảnh từ S3 của bạn, và bạn trả tiền băng thông cho lưu lượng của họ.

Nguyên nhân gốc: URL công khai vĩnh viễn.

Bucket công khai:
    https://bucket.s3.amazonaws.com/anh-dep.jpg
    → ai copy được URL là dùng được MÃI MÃI
    → nhúng vào trang khác, chia sẻ khắp nơi
    → bạn trả phí truyền dữ liệu cho mọi lượt xem

Pre-signed URL cắt đứt vấn đề ở gốc:

Bucket RIÊNG TƯ + ứng dụng sinh URL có chữ ký và HẠN DÙNG
    https://bucket.s3.amazonaws.com/anh-dep.jpg
        ?X-Amz-Expires=3600&X-Amz-Signature=...
    → hết hạn sau 1 giờ
    → trang khác copy URL thì nó chết ngay sau đó

url = boto3.client('s3').generate_presigned_url(
    'get_object',
    Params={'Bucket': 'anh-du-lich', 'Key': 'anh-dep.jpg'},
    ExpiresIn=3600)

Vì sao đây là biện pháp "hiệu quả nhất" trong các lựa chọn: nó là cách duy nhất không phụ thuộc vào thiện chí của bên kia. Mọi cơ chế dựa trên header (như kiểm tra Referer) đều giả mạo được bằng một dòng lệnh.

Và bước "gỡ quyền đọc công khai" là điều kiện bắt buộc: nếu bucket vẫn công khai, URL gốc vẫn dùng được và pre-signed URL không có ý nghĩa gì.

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

• B. Dùng CloudFront distribution cho ảnh — đây là phương án gần nhất và giảm được CHI PHÍ truyền dữ liệu (giá CloudFront rẻ hơn S3 và có cache), nhưng nó không ngăn hotlinking: nếu URL CloudFront vẫn công khai, các trang khác chỉ việc nhúng URL đó thay vì URL S3. (CloudFront + signed URL/cookie thì mới giải quyết được — nhưng phương án chỉ nói dùng CloudFront.)
• **C. Chặn IP của các trang web vi phạm bằng NACL — sai tầng và không hiệu quả: NACL áp cho subnet trong VPC, không áp cho S3. Và ngay cả khi chặn được, request đến từ trình duyệt của người xem, không phải từ máy chủ của trang kia — nên bạn sẽ phải chặn IP của chính độc giả.
• D. Lưu và phục vụ ảnh chất lượng cao trên Amazon WorkDocs — thay bài toán bằng một dịch vụ khác: WorkDocs là nền tảng chia sẻ tài liệu nội bộ, không phải giải pháp phục vụ nội dung cho website công khai.

Ghi nhớ

Bốn cách chống hotlinking trên AWS — theo độ mạnh: | Cách | Độ mạnh | Ghi chú | |---|---|---| | Pre-signed URL có hạn | cao | ← câu này | | CloudFront + signed URL/cookie | cao | thêm lợi ích CDN | | Kiểm tra header Referer | thấp — GIẢ MẠO ĐƯỢC | aws:Referer hoặc WAF | | WAF rate-based rule | vừa | giới hạn khối lượng, không chặn hẳn |

Vì sao aws:Referer yếu — dù nó là mẹo thường được nhắc tới:

{"Condition": {"StringLike": {"aws:Referer": ["https://trang-cua-toi.com/*"]}}}

curl -H "Referer: https://trang-cua-toi.com/" https://bucket.s3.../anh.jpg
# → vượt qua dễ dàng

AWS ghi rõ trong tài liệu rằng không nên dùng nó làm cơ chế bảo vệ chính — chỉ để giảm nhiễu.

Ba đặc điểm của pre-signed URL: | Đặc điểm | Chi tiết | |---|---| | Thời hạn tối đa | 7 ngày với SigV4; ngắn hơn nếu dùng thông tin đăng nhập tạm thời | | Kế thừa quyền của người ký | người ký phải có quyền trên object đó | | Dùng được cho cả GET và PUT | tải xuống lẫn tải lên |

Dòng giữa là chi tiết quan trọng: nếu ứng dụng ký URL bằng IAM role của EC2 hoặc Lambda, URL chỉ sống được tối đa bằng thời hạn của phiên đó — thường 1 đến 12 giờ, không phải 7 ngày.

Kiến trúc đầy đủ cho một trang chia sẻ ảnh:

Người dùng đăng nhập
    ↓ ứng dụng xác thực
    ↓ sinh pre-signed URL (hoặc signed cookie nếu dùng CloudFront)
Trình duyệt tải ảnh
    ↓
CloudFront (cache, giảm chi phí)
    ↓ OAC
S3 bucket RIÊNG TƯ

Kết hợp cả CloudFront lẫn signed URL lấy được cả hai lợi ích: chi phí truyền dữ liệu thấp và kiểm soát truy cập chặt.

Ba biện pháp bổ sung nên cân nhắc: | Biện pháp | Lợi ích | |---|---| | Thời hạn URL RẤT ngắn (5–15 phút) | URL bị chia sẻ nhanh chóng vô dụng | | Đóng dấu chìm (watermark) ảnh chất lượng cao | giảm động cơ sao chép | | Phục vụ ảnh xem trước độ phân giải thấp công khai | ảnh gốc chỉ cho người đã trả tiền |

Dòng cuối là mô hình kinh doanh phổ biến của các trang ảnh: bản xem trước công khai để thu hút, bản gốc sau tường phí với signed URL.

Và một lưu ý về chi phí trước khi chọn giải pháp: kiểm tra S3 Server Access Logs hoặc CloudFront log để biết chính xác bao nhiêu phần trăm lưu lượng đến từ hotlinking. Đôi khi việc chuyển sang CloudFront (rẻ hơn về mặt truyền dữ liệu) đã giải quyết phần lớn thiệt hại tài chính, và biện pháp kiểm soát truy cập chỉ cần cho nhóm ảnh có giá trị nhất.

Đáp án

A — Dùng throttling limits trong API Gateway.

Vì sao đúng

Đề cần bảo vệ hệ thống backend khỏi đợt tăng đột biến — và throttling là cơ chế trực tiếp cho việc đó.

Cơ chế token bucket của API Gateway:

Rate limit  = số request/giây ở trạng thái ổn định
Burst limit = dung lượng "thùng" — cho phép đợt tăng NGẮN vượt rate

Request vượt quá → API Gateway trả 429 Too Many Requests
                 → BACKEND KHÔNG BỊ CHẠM TỚI

Điểm mấu chốt: throttling bảo vệ ở TẦNG BIÊN, trước khi request tới backend.

Không có throttling:
    1.000.000 request → API Gateway → Lambda → cơ sở dữ liệu
                                                    ↑ SẬP

Có throttling (giới hạn 5.000 req/giây):
    1.000.000 request → API Gateway
                        ├─ 5.000/giây → backend (chịu được)
                        └─ phần còn lại → 429, không tới backend

Và "bảo vệ backend" là mục tiêu đúng của câu hỏi: API Gateway tự nó mở rộng rất tốt, nhưng Lambda có hạn mức concurrency và cơ sở dữ liệu phía sau có giới hạn kết nối — throttling giữ cho tải xuống dưới ngưỡng chịu đựng của mắt xích yếu nhất.

aws apigateway update-stage --rest-api-id abc123 --stage-name prod   --patch-operations     op=replace,path=/*/*/throttling/rateLimit,value=5000     op=replace,path=/*/*/throttling/burstLimit,value=10000

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

• **B. API Gateway tự động mở rộng và xử lý được đợt tăng lớn nên không cần làm gì — đây là phương án gần nhất và phần đầu là sự thật: API Gateway thật sự tự mở rộng. Nhưng nó bỏ qua đúng vấn đề mà đề đặt ra: câu hỏi là bảo vệ BACKEND, và backend không mở rộng vô hạn như API Gateway.
• **C. Nâng cấp thủ công các EC2 instance mà API Gateway đang dùng — sai tiền đề: API Gateway là dịch vụ hoàn toàn được quản lý và không máy chủ. Bạn không có EC2 instance nào để nâng cấp.
• **D. Triển khai Multi-AZ cho API Gateway kèm Read Replica — nhầm khái niệm giữa các loại dịch vụ: Multi-AZ và Read Replica là khái niệm của cơ sở dữ liệu (RDS, Aurora). API Gateway vốn đã dư thừa trên nhiều AZ và không có cấu hình như vậy.

Ghi nhớ

Bốn mức throttling của API Gateway — áp theo thứ tự từ hẹp tới rộng: | Mức | Phạm vi | |---|---| | Usage plan + API key | theo từng khách hàng | | Method level | từng phương thức của từng tài nguyên | | Stage level | toàn bộ stage | | Account level | 10.000 request/giây mỗi Region (mặc định) |

Usage plan là công cụ quan trọng cho API phục vụ nhiều khách hàng: mỗi bên một API key với hạn mức riêng, nên một khách hàng gây tăng tải không ảnh hưởng những người khác:

aws apigateway create-usage-plan --name goi-co-ban   --throttle rateLimit=100,burstLimit=200   --quota limit=10000,period=DAY

Bốn cách bảo vệ backend qua API Gateway: | Cách | Chống | |---|---| | Throttling | quá tải do khối lượng ← câu này | | Caching | request lặp lại — cắt tải ngay từ gốc | | WAF | request độc hại, bot, tấn công tầng 7 | | Reserved concurrency cho Lambda | giữ dung lượng cho hàm quan trọng |

Dòng cuối đáng biết cho kiến trúc trong đề: nếu tài khoản có nhiều Lambda function dùng chung hạn mức concurrency, một đợt tăng tải trên API này có thể làm cạn concurrency của mọi hàm khác. Đặt reserved concurrency giới hạn hàm này và bảo vệ phần còn lại.

Ba mắt xích có thể thành nút thắt phía sau API Gateway: | Mắt xích | Giới hạn | |---|---| | Lambda concurrency | 1.000 mỗi Region (mặc định, tăng được) | | Số kết nối tới RDS | phụ thuộc loại instance | | Hạn mức của dịch vụ backend | tuỳ dịch vụ |

Dòng giữa là vấn đề thực tế nghiêm trọng: hàng nghìn Lambda đồng thời mở kết nối tới RDS sẽ làm cạn số kết nối cho phép. RDS Proxy gộp và tái sử dụng kết nối, biến hàng nghìn Lambda thành vài chục kết nối thật — gần như bắt buộc cho kiến trúc này.

Và về hành vi khi throttling kích hoạt: API Gateway trả 429 kèm header Retry-After. Client được viết tốt sẽ thử lại với backoff luỹ thừa và jitter — nên tài liệu API nên nêu rõ điều này. Nếu không, client thử lại ngay lập tức và đồng loạt, làm tình hình tệ hơn chính đợt tăng ban đầu.

Đáp án

C — Tạo một custom endpoint trong Aurora theo tiêu chí cho lưu lượng production, và một custom endpoint khác để xử lý truy vấn báo cáo.

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: lưu lượng production đi tới instance dung lượng CAO, còn truy vấn báo cáo của nhân viên nội bộ đi tới instance dung lượng THẤP.

Custom endpoint là cơ chế duy nhất của Aurora cho phép chọn nhóm instance:

aws rds create-db-cluster-endpoint   --db-cluster-identifier cum-ban-hang   --db-cluster-endpoint-identifier endpoint-production   --endpoint-type READER   --static-members instance-lon-1 instance-lon-2

aws rds create-db-cluster-endpoint   --db-cluster-identifier cum-ban-hang   --db-cluster-endpoint-identifier endpoint-bao-cao   --endpoint-type READER   --static-members instance-nho-1

Vì sao reader endpoint mặc định không đủ (phương án A):

Reader endpoint:
    → cân bằng tải qua MỌI replica, không phân biệt
    → truy vấn báo cáo nặng có thể rơi vào instance lớn
    → và làm chậm chính lưu lượng production

Custom endpoint:
    → mỗi nhóm instance một endpoint riêng
    → hai loại workload KHÔNG ảnh hưởng nhau

Đây là lợi ích thật, không chỉ là chuyện phân chia: truy vấn báo cáo thường quét nhiều dữ liệu và chạy lâu. Nếu nó chạy chung với lưu lượng production, nó chiếm bộ nhớ đệm và làm giảm hiệu năng của truy vấn giao dịch.

Hai kiểu thành viên của custom endpoint: | Kiểu | Hành vi | |---|---| | static-members | danh sách cố định các instance | | excluded-members | mọi instance TRỪ danh sách — instance mới tự động được thêm |

Kiểu thứ hai hữu ích khi kết hợp với Auto Scaling: replica mới sinh ra tự động vào endpoint production, trong khi instance báo cáo được loại trừ.

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

• A. Dùng reader endpoint cho CẢ lưu lượng production LẪN truy vấn báo cáo, để Aurora tự cân bằng tải giữa các replica — đây là phương án gần nhất và là cách dùng chuẩn của Aurora, nhưng nó không phân tách được hai loại workload: reader endpoint đối xử với mọi replica như nhau, nên truy vấn báo cáo vẫn có thể rơi vào instance dành cho production.
• B. Dùng instance endpoint cho lưu lượng production và cluster endpoint cho truy vấn báo cáo — sai vai trò của cluster endpoint: nó luôn trỏ tới instance GHI (writer). Gửi truy vấn báo cáo nặng vào đó là chất tải lên chính instance quan trọng nhất. Và instance endpoint trỏ vào một máy cụ thể, mất khả năng cân bằng tải và chuyển đổi dự phòng.
• D. Không làm gì, vì Aurora mặc định tự động điều hướng lưu lượng production tới instance dung lượng cao và truy vấn báo cáo tới instance dung lượng thấp — Aurora không có hành vi như vậy: nó không biết gì về việc truy vấn nào là "production" hay "báo cáo".

Ghi nhớ

Bốn loại endpoint của Aurora — bảng cần thuộc: | Endpoint | Trỏ tới | Dùng cho | |---|---|---| | Cluster (writer) | instance GHI hiện tại | mọi thao tác ghi | | Reader | cân bằng tải qua MỌI replica | đọc thông thường | | Custom | nhóm instance do BẠN chọn | phân tách workload ← câu này | | Instance | một instance cụ thể | gỡ lỗi, không nên dùng trong ứng dụng |

Cluster endpoint tự trỏ sang instance mới khi có chuyển đổi dự phòng — đó là lý do ứng dụng luôn nên dùng nó thay vì instance endpoint.

Ba tình huống dùng custom endpoint: | Tình huống | Cách phân nhóm | |---|---| | Phân tách theo dung lượng máy | production dùng máy lớn, báo cáo dùng máy nhỏ ← câu này | | Phân tách theo phòng ban | mỗi đội một endpoint, không ảnh hưởng nhau | | Cách ly truy vấn phân tích | tách hẳn workload OLAP khỏi OLTP |

Kiến trúc Aurora — vì sao phân tách hiệu quả:

Compute:  1 writer + tối đa 15 reader (kích thước KHÁC NHAU được)
              ↓ tất cả dùng chung
Lưu trữ:  6 bản sao trên 3 AZ

Dòng đầu là điều kiện tiên quyết cho giải pháp này — với RDS thường, mọi read replica thường được cấu hình giống nhau và việc phân tách kém linh hoạt hơn.

Ba lưu ý khi dùng custom endpoint: | Lưu ý | Chi tiết | |---|---| | Tối đa 5 custom endpoint mỗi cụm | | | Instance có thể thuộc nhiều endpoint | không loại trừ nhau | | Kết hợp với Auto Scaling thì nên dùng excluded-members | replica mới tự vào đúng nhóm |

Và một cân nhắc thay thế cho truy vấn báo cáo nặng: nếu báo cáo chạy trên khối lượng dữ liệu rất lớn, cân nhắc xuất dữ liệu sang S3 và truy vấn bằng Athena, hoặc dùng Amazon Redshift. Cơ sở dữ liệu giao dịch không được tối ưu cho truy vấn tổng hợp quét toàn bảng — tách hẳn sang hệ thống phân tích thường hiệu quả và rẻ hơn là thêm replica.

Với Aurora, còn một lựa chọn nữa đáng biết: Aurora zero-ETL integration với Redshift tự động sao chép dữ liệu sang Redshift gần thời gian thực, cho phép chạy phân tích mà không chạm gì tới cụm giao dịch.

Đáp án

B — Bật S3 Versioning và Multi-Factor Authentication Delete trên bucket.

Vì sao đúng

Đề mô tả sự cố: một kỹ sư vô tình xoá tệp, gây gián đoạn dịch vụ. Cần ngăn tái diễn.

Versioning biến thao tác xoá thành thao tác cộng thêm:

Xoá khi versioning BẬT:
    S3 KHÔNG xoá gì cả
    → tạo một DELETE MARKER đè lên trên
    → mọi phiên bản cũ VẪN CÒN NGUYÊN
    → xoá delete marker là tệp trở lại ngay

Khôi phục chỉ mất vài giây:

# Tìm delete marker
aws s3api list-object-versions --bucket du-lieu --prefix tep-quan-trong.pdf

# Xoá delete marker → tệp xuất hiện lại
aws s3api delete-object --bucket du-lieu --key tep-quan-trong.pdf   --version-id <id-cua-delete-marker>

Và MFA Delete khoá đúng cái công tắc nguy hiểm nhất: | Thao tác | Cần MFA | |---|---| | Xoá VĨNH VIỄN một phiên bản cụ thể | ✅ | | TẮT versioning trên bucket | ✅ | | Xoá thông thường (tạo delete marker) | ❌ |

Vế thứ hai quan trọng hơn vẻ ngoài: không có MFA Delete, ai đó tắt versioning rồi xoá — và toàn bộ lớp bảo vệ biến mất. MFA Delete ngăn chính điều đó.

Cách bật — có ràng buộc đặc biệt:

aws s3api put-bucket-versioning --bucket du-lieu   --versioning-configuration Status=Enabled,MFADelete=Enabled   --mfa "arn:aws:iam::111122223333:mfa/root-account-mfa-device 123456"

Chỉ ROOT USER bật được, và bắt buộc qua CLI hoặc API — Console không làm được.

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

• **D. Tạo IAM bucket policy vô hiệu hoá thao tác xoá — đây là phương án gần nhất và là lớp bảo vệ hợp lệ, nhưng nó quá cứng và gỡ được: cấm hoàn toàn s3:DeleteObject chặn cả việc dọn dẹp hợp lệ; và quản trị viên sửa được bucket policy để bỏ hạn chế. Versioning bảo vệ dữ liệu chứ không phụ thuộc vào việc ai còn quyền gì.
• **C. Thiết lập signed URL cho mọi người dùng — giải quyết vấn đề khác: signed URL kiểm soát ai truy cập được và trong bao lâu. Nó không ngăn người có quyền xoá thực hiện việc xoá.
• A. Dùng S3 Infrequent Access để lưu dữ liệu — tính năng tối ưu CHI PHÍ: nó chuyển dữ liệu ít truy cập sang lớp rẻ hơn. Hoàn toàn không liên quan tới bảo vệ khỏi xoá nhầm.

Ghi nhớ

Bốn lớp bảo vệ dữ liệu trên S3 — theo độ mạnh: | Lớp | Chống lại | |---|---| | Versioning | xoá nhầm và ghi đè — NỀN TẢNG | | MFA Delete | xoá phiên bản, tắt versioning | | Object Lock (COMPLIANCE) | xoá bởi BẤT KỲ AI, kể cả root | | Cross-Region Replication | mất mát do sự cố Region | | Bucket policy Deny | thao tác nhầm (nhưng gỡ được) |

Cách versioning xử lý các thao tác: | Thao tác | Kết quả | |---|---| | PutObject lên khoá đã có | tạo phiên bản mới, bản cũ còn nguyên | | DeleteObject | tạo delete marker — KHÔNG xoá gì | | DeleteObject kèm versionId | XOÁ VĨNH VIỄN ← cần MFA | | GetObject | trả phiên bản mới nhất |

Ba lưu ý về versioning: | Lưu ý | Chi tiết | |---|---| | Bật rồi chỉ TẠM DỪNG được, không tắt hẳn | trạng thái Suspended | | MỌI phiên bản đều tính phí lưu trữ | chi phí tăng theo số lần ghi đè | | Cần lifecycle rule dọn phiên bản cũ | bắt buộc cho bucket ghi nhiều |

Lifecycle rule là bắt buộc, không phải tuỳ chọn:

{
  "Rules": [{
    "Status": "Enabled",
    "NoncurrentVersionExpiration": {"NoncurrentDays": 90},
    "Expiration": {"ExpiredObjectDeleteMarker": true}
  }]
}

Một tệp 1 GB ghi đè hằng ngày trong một năm sẽ chiếm 365 GB nếu không dọn.

Ba hạn chế của MFA Delete cần biết trước khi bật: | Hạn chế | Chi tiết | |---|---| | Chỉ root user bật/tắt được | trái với thực hành "không dùng root" | | Không dùng được từ Console | chỉ CLI hoặc API | | KHÔNG tương thích với lifecycle rule | lifecycle không xoá được phiên bản khi MFA Delete bật |

Dòng cuối là xung đột thực tế nghiêm trọng: bật MFA Delete nghĩa là mất khả năng tự động dọn dẹp, và chi phí lưu trữ tăng mãi. Với nhiều tổ chức, Object Lock chế độ GOVERNANCE là lựa chọn cân bằng hơn — nó ngăn xoá nhưng cho phép ngoại lệ có kiểm soát và vẫn tương thích với lifecycle.

Và một biện pháp về quy trình mà đề gợi mở: tách quyền xoá khỏi quyền ghi hằng ngày. Kỹ sư DevOps cần PutObject mỗi ngày, nhưng DeleteObject nên thuộc về một role riêng phải assume có chủ đích — nó biến việc xoá thành hành động có ý thức thay vì một cú nhấp nhầm. Với ba kỹ sư như đề mô tả, đó là thay đổi rất nhẹ nhàng mà hiệu quả.

Đáp án

B — Bật Multi-AZ failover.

Vì sao đúng

Đề mô tả vấn đề rõ: AZ chứa RDS instance gặp sự cố nhiều lần tới mức mất truy cập cơ sở dữ liệu. Cần ngăn tái diễn.

Multi-AZ giải quyết đúng loại sự cố đó:

Trước:  RDS instance duy nhất ở AZ-a
        → AZ-a sập → MẤT TRUY CẬP hoàn toàn

Sau:    Primary ở AZ-a  ──ĐỒNG BỘ──>  Standby ở AZ-b
        → AZ-a sập
        → RDS tự động CHUYỂN ĐỔI sang standby
        → DNS endpoint trỏ sang AZ-b
        → ứng dụng kết nối lại và chạy tiếp

Ba đặc điểm khiến nó là câu trả lời đúng: | Đặc điểm | Chi tiết | |---|---| | Standby ở AZ KHÁC | sự cố một AZ không chạm tới cả hai | | Chuyển đổi TỰ ĐỘNG | 60–120 giây, không cần ai can thiệp | | Endpoint KHÔNG đổi | ứng dụng không phải sửa chuỗi kết nối |

Và sao chép đồng bộ nghĩa là không mất dữ liệu:

Ứng dụng ghi → Primary ghi → CHỜ standby xác nhận → trả về thành công
    → standby luôn khớp chính xác với primary
    → RPO = 0

Dòng cuối là lý do Multi-AZ vượt trội so với read replica cho mục đích này: read replica dùng sao chép bất đồng bộ, nên chuyển sang nó có thể mất những giao dịch cuối.

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

• **D. Tạo một read replica — đây là phương án gần nhất và cũng tạo một bản sao dữ liệu, nhưng nó khác Multi-AZ ở ba điểm quan trọng: sao chép BẤT ĐỒNG BỘ (có thể mất dữ liệu), chuyển đổi THỦ CÔNG (phải promote bằng tay), và endpoint KHÁC (ứng dụng phải đổi chuỗi kết nối). Nó là công cụ mở rộng đọc, không phải cơ chế sẵn sàng cao.
• **A. Chụp snapshot của cơ sở dữ liệu — là biện pháp sao lưu, không phải sẵn sàng cao: khi AZ sập, khôi phục từ snapshot mất nhiều phút tới nhiều giờ, và mất toàn bộ dữ liệu kể từ lúc chụp. Snapshot vẫn cần thiết, nhưng cho mục đích khác.
• **C. Tăng kích thước instance của cơ sở dữ liệu — không liên quan tới sự cố AZ: máy to hơn vẫn nằm trong cùng một AZ và vẫn chết khi AZ đó chết.

Ghi nhớ

Multi-AZ và Read Replica — bảng phân biệt quan trọng nhất về RDS: | | Multi-AZ | Read Replica | |---|---|---| | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Phục vụ truy vấn đọc | ❌ | ✅ | | Chuyển đổi | tự động | thủ công (promote) | | Mất dữ liệu khi chuyển | ❌ (RPO = 0) | ✅ có thể | | Endpoint | giữ nguyên | khác | | Khác Region | ❌ | ✅ |

Cả hai dùng chung được và thường nên dùng chung: Multi-AZ cho tính sẵn sàng, read replica cho mở rộng đọc và khôi phục thảm hoạ đa Region.

Bốn sự kiện kích hoạt chuyển đổi tự động: | Sự kiện | |---| | Mất khả dụng cả một AZ ← tình huống của đề | | Hỏng primary instance | | Hỏng ổ đĩa của primary | | Vá lỗi hệ điều hành hoặc thay đổi loại instance |

Dòng cuối là lợi ích phụ đáng kể: Multi-AZ khiến việc bảo trì gần như không gián đoạn — AWS vá standby trước, chuyển đổi, rồi vá bản còn lại.

Ba việc ứng dụng cần làm để tận dụng Multi-AZ: | Việc | Lý do | |---|---| | Luôn dùng ENDPOINT, không dùng IP | IP thay đổi sau chuyển đổi | | Đặt TTL DNS thấp ở phía client | JVM cache DNS vĩnh viễn theo mặc định — phải chỉnh networkaddress.cache.ttl | | Có logic thử lại kết nối | có khoảng 60–120 giây gián đoạn |

Dòng giữa là bẫy hay gặp với ứng dụng Java: JVM cache kết quả phân giải DNS mãi mãi, nên sau chuyển đổi nó vẫn cố kết nối tới IP cũ. Đặt networkaddress.cache.ttl=5 để khắc phục.

Hai chế độ Multi-AZ của RDS: | Chế độ | Đặc điểm | |---|---| | Multi-AZ instance deployment | một standby, KHÔNG phục vụ đọc | | Multi-AZ DB cluster | HAI replica CÓ phục vụ đọc, chuyển đổi dưới 35 giây |

Chế độ thứ hai là bản mới hơn (MySQL và PostgreSQL) — nó khắc phục đúng nhược điểm "standby nằm không" và chuyển đổi nhanh hơn.

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Chi phí gần gấp đôi | trả tiền cho cả standby | | Độ trễ ghi tăng nhẹ | phải chờ xác nhận từ AZ khác | | KHÔNG thay thế cho sao lưu | xoá nhầm dữ liệu thì standby cũng xoá theo |

Dòng cuối quan trọng: Multi-AZ chống sự cố hạ tầng, không chống lỗi con người. Cho vế đó cần automated backup và point-in-time recovery — nên phương án A vẫn là việc nên làm, chỉ là nó không trả lời câu hỏi này.

Đáp án

A và E.

• A — Dùng Lambda@Edge để chạy quá trình xác thực ở các vị trí AWS gần người dùng hơn
• E — Triển khai origin failover bằng cách tạo một origin group gồm origin chính và origin phụ, để CloudFront tự chuyển sang origin phụ khi origin chính trả về mã lỗi HTTP nhất định

Vì sao đúng

Đề nêu hai triệu chứng khác nhau, và mỗi đáp án giải quyết một cái: | Triệu chứng | Nguyên nhân | Giải pháp | |---|---|---| | Thời gian đăng nhập lâu | xác thực phải đi tới origin ở xa | A — Lambda@Edge | | Lỗi HTTP 504 | origin không phản hồi kịp | E — origin failover |

A — vì sao Lambda@Edge giảm thời gian đăng nhập:

Trước:  Người dùng ở Việt Nam → điểm biên gần → ORIGIN ở Mỹ
                                                  ↑ xác thực ở đây
        → mỗi lần đăng nhập phải đi vòng nửa vòng trái đất

Sau:    Người dùng → điểm biên gần → Lambda@Edge XÁC THỰC TẠI ĐÓ
        → không phải tới origin
        → độ trễ giảm từ hàng trăm mili giây xuống vài chục

Bốn sự kiện Lambda@Edge có thể can thiệp: | Sự kiện | Chạy khi | |---|---| | Viewer request | ngay khi CloudFront nhận request — nơi đặt xác thực | | Origin request | trước khi gọi origin (chỉ khi cache miss) | | Origin response | sau khi nhận phản hồi từ origin | | Viewer response | trước khi trả về người dùng |

E — vì sao origin failover xử lý lỗi 504:

HTTP 504 Gateway Timeout = CloudFront KHÔNG NHẬN ĐƯỢC phản hồi từ origin

Origin group:
    Origin chính: ALB ở Region A
    Origin phụ:   ALB ở Region B (hoặc S3 tĩnh dự phòng)
        ↓ origin chính trả 504
    CloudFront TỰ ĐỘNG thử origin phụ
        ↓
    Người dùng nhận nội dung, không thấy lỗi

Và vế "cost-effective" loại bỏ phương án D: dựng ứng dụng ở nhiều Region với Route 53 latency routing hoạt động được, nhưng chi phí nhân theo số Region.

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

• C. Cấu hình origin thêm chỉ thị Cache-Control: max-age với giá trị dài nhất có thể để tăng tỷ lệ trúng cache — đây là phương án gần nhất và là tối ưu hữu ích cho nội dung tĩnh, nhưng nó không giúp gì cho ĐĂNG NHẬP: quá trình xác thực là động và riêng cho từng người dùng — không cache được.
• D. Triển khai ứng dụng ở nhiều Region và dùng Route 53 latency routing — hiệu quả nhưng đắt: phải duy trì hạ tầng đầy đủ ở mỗi Region. Đề yêu cầu "cost-effective solution".
• B. Dựng nhiều VPC ở các Region và cấu hình transit VPC để nối tất cả; dùng Lambda với AWS SAM ở mỗi Region — phức tạp không cần thiết và không giải quyết đúng vấn đề: transit VPC là mẫu kết nối mạng, không liên quan tới độ trễ đăng nhập hay lỗi 504.

Ghi nhớ

Hai dịch vụ tính toán ở biên của CloudFront: | | CloudFront Functions | Lambda@Edge | |---|---|---| | Ngôn ngữ | chỉ JavaScript | Node.js, Python | | Thời gian chạy tối đa | dưới 1 mili giây | 5 giây (viewer), 30 giây (origin) | | Truy cập mạng | ❌ KHÔNG | ✅ gọi được dịch vụ khác | | Sự kiện | viewer request/response | cả bốn sự kiện | | Chi phí | rẻ hơn ~6 lần | cao hơn | | Phù hợp | viết lại URL, thêm header, kiểm tra token đơn giản | xác thực phức tạp, gọi API |

Chọn CloudFront Functions khi đủ — nó rẻ hơn và nhanh hơn nhiều. Lambda@Edge cần thiết khi phải gọi ra ngoài (ví dụ tra cơ sở dữ liệu người dùng).

Bốn mã lỗi HTTP hay gặp với CloudFront: | Mã | Ý nghĩa | |---|---| | 502 Bad Gateway | origin trả phản hồi không hợp lệ, hoặc lỗi TLS | | 503 Service Unavailable | origin quá tải | | 504 Gateway Timeout | origin không phản hồi kịp trong thời gian chờ | | 403 Forbidden | geo restriction, WAF, hoặc signed URL sai |

Ba nguyên nhân phổ biến của 504: | Nguyên nhân | Cách xử lý | |---|---| | Origin xử lý chậm | tối ưu backend, tăng OriginReadTimeout | | Security group chặn CloudFront | cho phép prefix list cloudfront.origin-facing | | Origin quá tải | origin failover, Auto Scaling |

Giới hạn của origin group cần biết: | Giới hạn | Chi tiết | |---|---| | Chỉ 2 origin mỗi group | không có origin thứ ba | | Chỉ áp cho GET, HEAD, OPTIONS | request GHI KHÔNG failover | | Kích hoạt theo mã trạng thái hoặc timeout | không có health check chủ động |

Dòng giữa quan trọng cho ứng dụng động: origin group không bảo vệ thao tác ghi. Cho vế đó cần Route 53 failover routing tới Region khác.

Ba cách tăng tỷ lệ trúng cache — dù không giúp cho đăng nhập: | Cách | Lợi ích | |---|---| | Cache-Control: max-age dài | ít request tới origin | | Giảm số thứ trong cache key | mỗi biến thể là một mục cache riêng | | Bật nén Gzip/Brotli | ít byte truyền hơn |

Và một biện pháp đáng cân nhắc cho chính bài toán đăng nhập: dùng token JWT có thời hạn thay vì kiểm tra phiên ở origin mỗi lần. Lambda@Edge chỉ cần xác minh chữ ký của token ngay tại biên — không gọi ra ngoài, nên dùng được CloudFront Functions và rẻ hơn nhiều.