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

Đáp án

D — Tạo VPC Endpoint Service nhận lưu lượng TCP, đặt sau một Network Load Balancer; cho phép truy cập dịch vụ IT qua kết nối Direct Connect.

Vì sao đúng

Đề có hai yêu cầu, và chúng quyết định hai lựa chọn khác nhau: dữ liệu không được đi qua Internet, và phơi dịch vụ cho công ty khác dùng AWS.

⚠ Điểm mấu chốt: endpoint service CHỈ đứng sau Network Load Balancer hoặc Gateway Load Balancer — không đứng sau ALB:

VPC Endpoint Service
        ↓
    Yêu cầu một NLB (hoặc GWLB) làm điểm vào
        ↓
    ALB KHÔNG phải lựa chọn hợp lệ
        ↓
    → đây chính là chỗ phương án B sai

Đây là ràng buộc kỹ thuật cứng và là điểm phân biệt duy nhất giữa B và D.

Vì sao PrivateLink là mô hình đúng cho việc phơi dịch vụ. Công ty là bên cung cấp, các công ty khác là bên tiêu thụ:

Công ty (nhà cung cấp)                    Khách hàng (bên tiêu thụ)
    NLB ← Endpoint Service  ◄─────────────  Interface Endpoint
                                                   │
    → khách hàng khởi tạo kết nối một chiều
    → không có gì trong VPC của khách phơi ra cho bạn, và ngược lại

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

aws ec2 modify-vpc-endpoint-service-permissions \
  --service-id vpce-svc-0abc \
  --add-allowed-principals arn:aws:iam::<tai-khoan-khach>:root

⚠ Endpoint service nằm trong một Region — khách ở Region khác cần cấu hình thêm:

Mặc định chỉ khách hàng trong CÙNG Region tạo endpoint được
        ↓
    Muốn phục vụ Region khác → bật cross-Region endpoint,
      hoặc dựng endpoint service ở từng Region

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

• B (VPC Endpoint Service nhận lưu lượng HTTP/HTTPS, đặt sau một Application Load Balancer) — đây là phương án gần nhất và nó chọn đúng công nghệ PrivateLink, đúng mô hình nhà cung cấp. Nó chỉ sai ở loại load balancer: endpoint service không hỗ trợ ALB. Nếu bạn thật sự cần định tuyến tầng 7, mẫu chuẩn là đặt NLB trước ALB — NLB làm điểm vào cho endpoint service, chuyển tiếp sang ALB phía sau. Ngoài ra đề nói "IT services" chung chung, không giới hạn ở HTTP, nên NLB ở tầng 4 cũng phù hợp hơn về phạm vi. Đây là bẫy kiểm tra đúng một chi tiết kiến trúc.

• C (mesh các kết nối VPN CloudHub giữa tài khoản khách hàng và tài khoản nhà cung cấp) — sai công cụ và không co giãn. VPN CloudHub dùng để nối nhiều chi nhánh tại chỗ với nhau qua AWS, không phải để phơi dịch vụ giữa các tài khoản AWS. Mỗi khách hàng mới là một kết nối VPN phải cấu hình thủ công hai đầu, và VPN chạy trên Internet — vi phạm yêu cầu dữ liệu không đi qua Internet.

• A (gắn internet gateway vào VPC và dùng NACL cùng security group để lọc) — vi phạm thẳng yêu cầu bảo mật. Internet gateway nghĩa là dịch vụ phơi ra Internet công cộng; lọc bằng security group chỉ thu hẹp chứ không thay đổi bản chất đó.

Ghi nhớ

⚠ Bốn thành phần của PrivateLink phía nhà cung cấp — bảng phải thuộc: | Thành phần | Nội dung | |---|---| | NLB hoặc Gateway Load Balancer | bắt buộc — ALB không dùng được | | Endpoint service | phơi load balancer đó ra | | Danh sách principal | tài khoản, role hoặc user nào được tạo endpoint | | Acceptance | tự động hoặc duyệt thủ công từng kết nối |

Từ khoá nhận diện:

"offer services to other companies on AWS" → PrivateLink endpoint service "data cannot traverse the internet" → PrivateLink hoặc Direct Connect "endpoint service behind an ALB" → LUÔN SAI, phải là NLB hoặc GWLB "VPN CloudHub" để phơi dịch vụ giữa tài khoản AWS → SAI công cụ "internet gateway + security group" khi cấm Internet → SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khách đã tạo endpoint chưa | describe-vpc-endpoint-connections | | Có duyệt kết nối chưa | trạng thái pendingAcceptance | | Lưu lượng có đi đúng đường không | traceroute từ phía khách, không được thấy hop Internet |

Và một lời khuyên: hãy bật acceptance-required và duyệt từng kết nối thủ công, ít nhất trong giai đoạn đầu. Danh sách principal cho phép ai được tạo endpoint, nhưng nó không cho bạn biết khi nào ai đó thực sự tạo — và với một dịch vụ phơi cho nhiều công ty, việc mất dấu ai đang kết nối là chuyện xảy ra rất nhanh. Chế độ duyệt thủ công biến mỗi kết nối mới thành một sự kiện bạn nhìn thấy và ghi lại, thay vì một dòng trong danh sách mà không ai kiểm tra. Khi số khách hàng đủ lớn để việc duyệt trở nên phiền, lúc đó bạn đã có quy trình để tự động hoá nó một cách có kiểm soát.

Đáp án

A — Chuyển cơ sở dữ liệu sang Aurora MySQL; đặt ứng dụng web trên Auto Scaling group EC2 sau Application Load Balancer; dùng Amazon AppStream 2.0 để cải thiện trải nghiệm người dùng.

Vì sao đúng

Đề có một chi tiết dễ bị lướt qua và nó quyết định toàn bộ: ứng dụng gồm cả một desktop client lẫn một web application, và người dùng từ xa than phiền về thời gian tải chậm.

⚠ Điểm mấu chốt: ứng dụng nhạy cảm với độ trễ thì phải đưa PHẦN XỬ LÝ tới gần dữ liệu, không phải ngược lại:

Desktop client chạy trên máy người dùng ở xa
        ↓
    Mỗi thao tác là một vòng gọi qua mạng tới máy chủ
        ↓
    Độ trễ nhân lên theo số vòng gọi → cảm giác chậm
        ↓
AppStream 2.0
        ↓
    Chạy chính ứng dụng đó TRONG AWS, cạnh cơ sở dữ liệu
    Chỉ truyền hình ảnh màn hình về người dùng
        ↓
    → số vòng gọi qua WAN giảm còn một luồng pixel

Đây là lý do AppStream giải được vấn đề mà cache hay CDN không giải được: vấn đề không phải nội dung tĩnh, mà là số lượt trao đổi giữa client và server.

Vì sao Aurora MySQL. Đề nói cơ sở dữ liệu MySQL chạy trên một máy ảo duy nhất — không đạt được SLA nào. Aurora giữ nguyên tương thích MySQL (không sửa ứng dụng), lưu trữ sao chép sáu bản trên ba AZ, và chuyển dự phòng thường dưới 30 giây.

⚠ SLA 99,5% nghe dễ nhưng vẫn đòi kiến trúc nhiều AZ:

99,5% mỗi tháng ≈ được phép ngừng khoảng 3,6 giờ
        ↓
    Một máy ảo đơn lẻ chỉ cần một lần bảo trì hoặc một lần hỏng đĩa là vượt
        ↓
    → cần cả tầng web lẫn tầng dữ liệu đều dự phòng

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

• B (MySQL trên EC2, ECS sau ALB, cấp một WorkSpaces cho MỖI người dùng cuối) — đây là phương án gần nhất và nó nhận ra đúng vấn đề: đưa môi trường làm việc lên cloud để giảm độ trễ. Nhưng nó chọn công cụ nặng hơn nhiều. WorkSpaces cấp một máy tính để bàn đầy đủ, trả tiền theo tháng hoặc theo giờ cho từng người, trong khi người dùng chỉ cần chạy một ứng dụng client. AppStream phát đúng ứng dụng đó, chi phí thấp hơn hẳn và không phải quản một đội desktop ảo. Ngoài ra, MySQL tự quản trên EC2 đi ngược yêu cầu "minimize changes" và "minimize costs" — bạn phải tự lo sao chép, chuyển dự phòng và vá lỗi.

• C (RDS MySQL Multi-AZ, Fargate sau NLB, ElastiCache để cải thiện trải nghiệm) — tầng dữ liệu hợp lý, nhưng hai chỗ còn lại lệch. NLB ở tầng 4 không phù hợp cho ứng dụng web cần định tuyến tầng 7. Và ElastiCache giảm tải cơ sở dữ liệu, không giảm độ trễ mạng giữa người dùng từ xa và máy chủ — nó không chạm tới nguyên nhân mà người dùng đang than phiền. Chuyển sang Fargate cũng đòi đóng gói lại ứng dụng.

• D (chuyển cơ sở dữ liệu sang cụm EMR, ECS sau ALB, CloudFront) — sai loại kho dữ liệu. EMR là nền tảng xử lý dữ liệu lớn, không phải cơ sở dữ liệu giao dịch thay thế cho MySQL. CloudFront giúp cho nội dung tĩnh, không giúp cho một desktop client gọi API liên tục.

Ghi nhớ

⚠ AppStream 2.0 so với WorkSpaces — bảng phải thuộc: | | AppStream 2.0 | WorkSpaces | |---|---|---| | Phát cái gì | một hoặc vài ứng dụng | cả máy tính để bàn | | Phiên | tạm thời, không lưu trạng thái theo mặc định | lâu dài, mỗi người một máy | | Chi phí | theo giờ dùng thật | theo tháng hoặc theo giờ, mỗi người một máy | | Hợp với | chạy một ứng dụng client từ xa | thay thế máy tính văn phòng |

Từ khoá nhận diện:

"desktop client application" + người dùng từ xa chậm → AppStream 2.0 "replace the whole desktop" → WorkSpaces "minimize changes to the application" → rehost, giữ engine tương thích "ElastiCache" để chữa độ trễ mạng người dùng → SAI, nó giảm tải CSDL "EMR" thay cho MySQL giao dịch → SAI loại kho dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ có giảm thật không | đo từ chính máy người dùng ở xa, trước và sau | | Aurora có nhiều AZ không | đếm instance và AZ của chúng, không chỉ xem nhãn | | Chi phí AppStream | phụ thuộc số giờ phiên — ước lượng theo thói quen dùng thật |

Và một lời khuyên: hãy đo số vòng gọi mạng mà desktop client thực hiện cho một thao tác điển hình, trước khi chọn giải pháp. Đây là con số quyết định giữa việc cần AppStream và việc chỉ cần một CDN hay một cache: nếu client gọi ba lần cho mỗi màn hình thì tăng băng thông và giảm độ trễ đường truyền là đủ; nếu nó gọi ba trăm lần — điều rất phổ biến với các ứng dụng client cũ nói chuyện trực tiếp với cơ sở dữ liệu — thì mọi cải thiện về đường truyền đều bị nhân với ba trăm và không bao giờ đủ. Không có chỉ số nào trên AWS cho bạn con số đó; nó chỉ hiện ra khi ai đó bắt gói tin trên máy của một người dùng thật.

Đáp án

D — Kiểm tra xem IAM role có quyền giải mã bằng khoá KMS được tham chiếu hay không.

Vì sao đúng

Đề đã loại sẵn gần hết mọi khả năng: role đúng, IAM policy cho phép tải object, bucket policy hợp lệ, NACL hợp lệ. Chỉ còn một mắt xích chưa được kiểm — và đề nêu nó ngay trong câu mô tả: bucket được mã hoá bằng khoá KMS.

⚠ Điểm mấu chốt: với SSE-KMS, tải một object cần HAI quyền ở HAI dịch vụ khác nhau:

GET object từ bucket mã hoá bằng KMS
        ↓
    S3 kiểm tra s3:GetObject  → đạt
        ↓
    S3 gọi KMS để giải mã data key
        ↓
    KMS kiểm tra kms:Decrypt cho principal đó → THIẾU
        ↓
    → trả về 403 Access Denied, và thông báo KHÔNG nói rõ là do KMS

Đây là nguyên nhân của rất nhiều giờ gỡ lỗi trong thực tế: lỗi hiện ra ở S3 nhưng gốc nằm ở KMS.

Quyền cần có ở cả hai phía:

// Trong IAM policy của role
{
  "Effect": "Allow",
  "Action": ["kms:Decrypt", "kms:DescribeKey"],
  "Resource": "arn:aws:kms:ap-southeast-1:111122223333:key/abc-123"
}

// Trong key policy của KMS key
{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/NhanVien"},
  "Action": ["kms:Decrypt", "kms:DescribeKey"],
  "Resource": "*"
}

⚠ Key policy là bắt buộc — khác với hầu hết dịch vụ khác:

Với S3, một IAM policy đủ để cấp quyền
        ↓
Với KMS, key policy là nguồn quyền GỐC
        ↓
    IAM policy chỉ có tác dụng nếu key policy đã uỷ quyền cho tài khoản
      (mệnh đề "Enable IAM User Permissions")
        ↓
    → thiếu điều đó thì không IAM policy nào cứu được

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

• C (kiểm tra xem Block Public Access đã bật trên bucket chưa) — đây là phương án gần nhất và nó nhắm vào một nguyên nhân 403 rất phổ biến. Nhưng nó không áp dụng ở đây: nhân viên đã assume một IAM role và truy cập bằng thông tin đăng nhập của role đó, tức là một request đã xác thực. Block Public Access chỉ ảnh hưởng tới truy cập ẩn danh hoặc công khai; nó không chặn một principal có quyền. Đây là bẫy hay vì nó là câu trả lời đúng cho một câu hỏi rất giống — chỉ khác ở chỗ người truy cập là ai.

• B (kiểm tra trust relationship của IAM role) — đề đã nói nhân viên đã assume thành công role đó. Nếu trust policy sai thì lỗi xảy ra ở bước AssumeRole với thông báo khác hẳn, và nhân viên sẽ không bao giờ tới được bước tải object. Điều này đã được loại bởi chính mô tả của đề.

• A (kiểm tra tường lửa cục bộ có chặn S3 endpoint không) — tường lửa chặn thì triệu chứng là timeout hoặc connection refused, không phải 403 Access Denied. Mã 403 nghĩa là request đã tới nơi và được xử lý, rồi bị từ chối vì quyền — nghĩa là mạng đang thông.

Ghi nhớ

⚠ Bốn nguyên nhân 403 khi tải object từ S3 — bảng phải thuộc: | Nguyên nhân | Dấu hiệu phân biệt | |---|---| | Thiếu s3:GetObject | IAM policy không có hành động đó | | Bucket policy từ chối | có Deny tường minh | | Thiếu kms:Decrypt | bucket mã hoá bằng SSE-KMS | | Block Public Access | chỉ với request ẩn danh |

Từ khoá nhận diện:

"bucket encrypted with KMS" + 403 → kiểm kms:Decrypt trước tiên "IAM policy đã đúng nhưng vẫn 403" → KMS, hoặc SCP, hoặc permissions boundary "403" mà nghi tường lửa → SAI, tường lửa gây timeout không phải 403 "Block Public Access" với principal đã xác thực → không liên quan truy cập liên tài khoản → cần cả key policy lẫn IAM policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lời gọi KMS có bị từ chối không | CloudTrail, sự kiện Decrypt với errorCode | | Role có quyền KMS không | aws iam simulate-principal-policy với action kms:Decrypt | | Key policy có uỷ quyền cho tài khoản không | aws kms get-key-policy |

Và một lời khuyên: hãy tìm sự kiện Decrypt trong CloudTrail thay vì chỉ tìm sự kiện GetObject. Đây là chỗ việc gỡ lỗi đi lạc hướng lâu nhất: bản ghi GetObject hiện AccessDenied và bạn bắt đầu rà soát mọi thứ liên quan tới S3 — IAM policy, bucket policy, ACL, Block Public Access — trong khi tất cả đều đúng. Bản ghi thật sự chứa câu trả lời nằm dưới tên dịch vụ KMS, ở một sự kiện riêng biệt mà không ai nghĩ tới việc đi tìm, vì thao tác người dùng thực hiện là tải một tệp chứ không phải giải mã một khoá.

Đáp án

C — Auto Scaling group EC2 trải ba Availability Zone sau Application Load Balancer; Aurora PostgreSQL ở một AZ và thêm Aurora Replica ở hai AZ còn lại.

Vì sao đúng

Đề đòi cả tầng ứng dụng lẫn tầng dữ liệu đều sẵn sàng cao trên ba AZ. Chỉ một phương án đạt được điều đó ở cả hai tầng.

⚠ Điểm mấu chốt: một cụm Aurora chỉ có writer thì lưu trữ đã trải ba AZ, nhưng KHẢ NĂNG PHỤC VỤ thì không:

Aurora luôn sao chép lưu trữ sáu bản trên ba AZ — mặc định, không cần cấu hình
        ↓
    Nhưng nếu chỉ có MỘT instance
        ↓
    AZ chứa instance đó hỏng → dữ liệu vẫn an toàn, nhưng không có gì phục vụ
        ↓
    → phải có instance ở nhiều AZ mới có tự chuyển dự phòng

Thêm hai Aurora Replica ở hai AZ khác giải quyết đúng chuyện đó: khi writer hỏng, một replica được thăng cấp tự động, thường dưới 30 giây.

aws rds create-db-cluster --db-cluster-identifier ung-dung \
  --engine aurora-postgresql --manage-master-user-password

# writer
aws rds create-db-instance --db-instance-identifier ung-dung-1 \
  --db-cluster-identifier ung-dung --db-instance-class db.r6g.large \
  --engine aurora-postgresql --availability-zone ap-southeast-1a
# hai replica ở hai AZ khác
aws rds create-db-instance --db-instance-identifier ung-dung-2 ... --availability-zone ap-southeast-1b
aws rds create-db-instance --db-instance-identifier ung-dung-3 ... --availability-zone ap-southeast-1c

Vì sao ALB chứ không NLB. Đề mô tả ứng dụng web hai tầng — đó là HTTP, và ALB cho định tuyến theo đường dẫn, theo host, tích hợp WAF, sticky session. NLB ở tầng 4 không có những thứ đó và không mang lại lợi ích nào ở đây.

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

• B (Auto Scaling group ba AZ sau NLB; RDS Multi-AZ PostgreSQL trên hai AZ, thêm Read Replica ở AZ thứ ba) — đây là phương án gần nhất và tầng dữ liệu của nó thật sự phủ ba AZ: Multi-AZ dùng hai AZ, read replica thêm AZ thứ ba. Nhưng nó có hai điểm yếu. Thứ nhất, NLB là lựa chọn sai cho ứng dụng web — mất hết khả năng tầng 7. Thứ hai, và tinh tế hơn: read replica của RDS không tự động được thăng cấp khi cụm chuyển dự phòng; nó chỉ là bản sao đọc, phải promote thủ công. Vậy nên AZ thứ ba đóng góp vào khả năng đọc chứ không đóng góp vào cơ chế tự chuyển dự phòng, trong khi Aurora Replica thì có.

• A (Auto Scaling group ba AZ sau NLB; Aurora PostgreSQL trong MỘT AZ với storage auto scaling) — sai ở tầng dữ liệu. Storage auto scaling là chuyện dung lượng, không phải tính sẵn sàng. Một instance duy nhất nghĩa là mất AZ đó là mất khả năng phục vụ. Cộng thêm lỗi chọn NLB.

• D (Auto Scaling group ba AZ sau ALB; Aurora Global Database) — chọn đúng ALB nhưng nhắm sai vấn đề. Aurora Global Database là giải pháp cho nhiều REGION, dành cho thảm hoạ vùng — nó không phải cách để đạt tính sẵn sàng trên ba AZ trong một Region, đắt hơn nhiều, và Region phụ chỉ đọc được cho tới khi promote.

Ghi nhớ

⚠ Bốn khái niệm sẵn sàng của Aurora — bảng phải thuộc: | Khái niệm | Nội dung | |---|---| | Lưu trữ | luôn 6 bản trên 3 AZ — mặc định, không cấu hình | | Aurora Replica | instance đọc, tự động thăng cấp khi writer hỏng | | Cross-Region replica | sang Region khác, promote thủ công | | Global Database | đa Region, RPO ~1 giây, cho thảm hoạ vùng |

Từ khoá nhận diện:

"highly available across three AZs" → instance ở ba AZ, không chỉ lưu trữ "web application" → ALB, không phải NLB "storage auto scaling" để đạt tính sẵn sàng → SAI, đó là dung lượng "Global Database" cho tính sẵn sàng trong một Region → SAI, đó là đa Region RDS read replica → promote THỦ CÔNG, không tự chuyển dự phòng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance nằm ở AZ nào | describe-db-instances, xem AvailabilityZone của từng cái | | Chuyển dự phòng có chạy không | aws rds failover-db-cluster trong giờ thấp điểm | | Ứng dụng có dùng đúng endpoint không | kiểm chuỗi kết nối dùng cluster endpoint, không phải instance endpoint |

Và một lời khuyên: hãy kiểm tra ứng dụng đang kết nối bằng cluster endpoint chứ không phải instance endpoint. Đây là chỗ toàn bộ thiết kế sẵn sàng cao bị vô hiệu hoá bởi một chuỗi kết nối: nếu ứng dụng trỏ thẳng vào endpoint của một instance cụ thể, thì khi instance đó hỏng, Aurora vẫn thăng cấp replica đúng như thiết kế trong vài chục giây — nhưng ứng dụng vẫn kiên trì gọi vào cái đã chết. Cụm hiện trạng thái khoẻ mạnh, chuyển dự phòng ghi nhận thành công, mọi chỉ số của cơ sở dữ liệu đều xanh, và chỉ có ứng dụng là không kết nối được. Không có gì trong bảng điều khiển RDS gợi ý rằng vấn đề nằm ở tên máy chủ mà ứng dụng đang dùng.

Đáp án

D — ALB trước Auto Scaling group EC2 trong MỘT Region và ba Availability Zone; ElastiCache đứng trước cụm Aurora MySQL Multi-AZ; chuyển tệp dùng chung sang EFS; CloudFront với ALB làm origin, chọn price class gồm Mỹ và châu Âu.

Vì sao đúng

Đề nêu năm yêu cầu, và mấu chốt là nhận ra SLA 99,9% không đòi nhiều Region — điều đó loại hai phương án đắt nhất.

⚠ Điểm mấu chốt: ba AZ trong một Region thừa sức cho 99,9% — nhiều Region là mức đầu tư cho một bài toán khác:

99,9% ≈ được phép ngừng 43 phút mỗi tháng
        ↓
    Multi-AZ trong một Region đạt được mức này với biên an toàn lớn
        ↓
    Nhiều Region giải quyết THẢM HOẠ VÙNG, một rủi ro khác hẳn
        ↓
    → chi phí và độ phức tạp tăng gấp bội mà không phục vụ yêu cầu nào đã nêu

Vì sao CloudFront đủ để giảm độ trễ toàn cầu. Đây là điểm nhiều người bỏ qua: đề đòi giảm độ trễ cho người dùng ở châu Âu và Mỹ, và CloudFront làm được điều đó mà không cần triển khai hạ tầng ở nhiều Region — nội dung được cache ở hơn 600 điểm biên, và ngay cả nội dung động cũng đi qua mạng xương sống AWS thay vì Internet công cộng.

Price class là chi tiết tối ưu chi phí: chọn đúng gói phủ Mỹ và châu Âu thay vì toàn cầu.

⚠ ElastiCache phải được ứng dụng chủ động dùng — nó không tự chen vào giữa:

Dựng cụm ElastiCache
        ↓
    Ứng dụng vẫn gọi thẳng cơ sở dữ liệu như cũ
        ↓
    → cache tồn tại, tốn tiền, và không được dùng lần nào
        ↓
    → phải sửa mã theo mẫu cache-aside: tra cache trước, trượt thì đọc DB rồi ghi lại cache

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

• B (hai Region, hai AZ mỗi Region, Aurora Global Database, EFS với cross-Region replication) — đây là phương án gần nhất và nó đáp ứng được mọi yêu cầu về mặt kỹ thuật, thậm chí vượt mức. Nhưng nó vượt xa nhu cầu: SLA 99,9% không cần hai Region, và đề nói rõ mục tiêu là "optimizing operational efficiency". Hai Region nghĩa là nhân đôi hạ tầng, nhân đôi việc triển khai, thêm Aurora Global Database và cơ chế đồng bộ EFS xuyên Region — tất cả đều là chi phí và độ phức tạp cho một rủi ro mà đề không đặt ra. Ngoài ra hai AZ mỗi Region cho biên an toàn thấp hơn ba AZ trong phương án D.

• A (hai Region, ba AZ mỗi Region, FSx với đồng bộ xuyên Region) — cùng vấn đề thừa thãi như B, cộng thêm lựa chọn lưu trữ lệch: ứng dụng chạy trên Linux (web servers, MySQL), nên EFS (NFS) là lựa chọn tự nhiên, còn FSx for Windows File Server phục vụ SMB cho máy Windows.

• C (một Region ba AZ — đúng; nhưng đặt Amazon DocumentDB trước cụm Aurora MySQL, và price class toàn cầu) — hai lỗi. DocumentDB là cơ sở dữ liệu tài liệu tương thích MongoDB, không phải lớp cache; đặt nó "trước" một cơ sở dữ liệu quan hệ là một kiến trúc không có nghĩa. Và price class gồm mọi vị trí toàn cầu là trả tiền cho các điểm biên ở những nơi không có người dùng, đi ngược mục tiêu tối ưu.

Ghi nhớ

⚠ Bốn cách giảm độ trễ cho người dùng ở xa — bảng phải thuộc: | Cách | Khi nào | |---|---| | CloudFront | nội dung tĩnh và động qua HTTP — rẻ nhất, hiệu quả nhất | | Global Accelerator | TCP/UDP, API động, cần IP tĩnh | | Nhiều Region | khi cần chịu thảm hoạ vùng, hoặc yêu cầu lưu trú dữ liệu | | Local Zones / Outposts | độ trễ cực thấp tại một địa phương cụ thể |

Từ khoá nhận diện:

"99.9% SLA" → nhiều AZ trong một Region là đủ "reduce latency across regions/countries" → CloudFront, chưa cần triển khai đa Region "read-heavy workload" → ElastiCache + read replica "optimizing operational efficiency" → loại phương án nhân đôi hạ tầng "DocumentDB làm cache" → LUÔN SAI, đó là CSDL tài liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cache có được dùng không | chỉ số CacheHits và CacheMisses của ElastiCache | | CloudFront có cache không | CacheHitRate | | Độ trễ thực tế | đo từ máy ở châu Âu và Mỹ, không đo từ máy dev |

Và một lời khuyên: hãy kiểm tra tỷ lệ trúng cache của ElastiCache trong tuần đầu sau khi triển khai. Đây là chỗ một khoản đầu tư hạ tầng trở thành chi phí thuần: cụm cache được dựng đúng, nằm đúng subnet, security group đúng, trạng thái available — và ứng dụng chưa bao giờ gọi tới nó vì phần sửa mã bị hoãn sang sprint sau rồi bị quên. Không có cảnh báo nào cho một cache không được dùng; nó chỉ đơn giản là báo cáo tỷ lệ trúng bằng 0 trên một biểu đồ mà không ai mở, trong khi vẫn tính tiền theo giờ đều đặn như một cụm đang phục vụ hàng triệu truy vấn.

Đáp án

D — Chuyển endpoint Regional của API Gateway thành edge-optimized và bật caching ở stage production.

Vì sao đúng

Đề mô tả một mẫu tải rất cụ thể: rất nhiều HTTP request truy vấn CÙNG một dữ liệu, dồn thành từng đợt ngắn. Với mẫu đó, cache ở tầng ngoài cùng là đòn bẩy lớn nhất.

⚠ Điểm mấu chốt: cache ở API Gateway chặn request ngay tại tầng đầu — nó bảo vệ MỌI tầng phía sau:

Request lặp lại tới cùng endpoint với cùng tham số
        ↓
    API Gateway trả từ cache
        ↓
    → Lambda KHÔNG được gọi
    → Aurora KHÔNG nhận truy vấn
        ↓
    → giảm cùng lúc chi phí Lambda, tải cơ sở dữ liệu, và độ trễ

So với việc thêm một lớp cache ở giữa Lambda và cơ sở dữ liệu, cách này chặn sớm hơn một tầng và không cần sửa mã ứng dụng — chỉ là cấu hình trên stage.

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations \
    op=replace,path=/cacheClusterEnabled,value=true \
    op=replace,path=/cacheClusterSize,value=1.6 \
    op=replace,path=/*/*/caching/enabled,value=true \
    op=replace,path=/*/*/caching/ttlInSeconds,value=300

⚠ TTL quyết định mức độ "cũ" mà người dùng chấp nhận — phải chọn theo nghiệp vụ:

TTL dài → tỷ lệ trúng cache cao, backend nhẹ, nhưng dữ liệu cũ hơn
TTL ngắn → dữ liệu mới hơn, nhưng ít trúng cache hơn
        ↓
    Với dữ liệu theo dõi thể dục, vài phút thường chấp nhận được
        ↓
    → và có thể vô hiệu hoá có chọn lọc bằng header Cache-Control: max-age=0

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

• B (thêm ElastiCache for Redis để cache kết quả truy vấn, sửa Lambda để dùng cache) — đây là phương án gần nhất và nó thật sự giảm tải cơ sở dữ liệu. Nhưng so với đáp án đúng, nó chặn muộn hơn một tầng: Lambda vẫn được gọi cho mọi request, nên bạn vẫn trả tiền cho từng lời gọi và vẫn chịu độ trễ khởi tạo. Nó cũng đòi sửa mã ứng dụng và thêm một cụm ElastiCache phải vận hành và trả tiền theo giờ — đi ngược yêu cầu "minimizing the increase in costs". Xem thêm ghi chú về chất lượng câu hỏi bên dưới.

• C (đổi sang instance Aurora có nhiều bộ nhớ hơn) — mở rộng dọc: giải quyết triệu chứng bằng cách nâng trần, và chỉ nâng được một lần. Nó không đụng tới nguyên nhân là hàng loạt truy vấn giống hệt nhau, và là phương án tăng chi phí nhiều nhất trong bốn phương án.

• A (tạo usage plan và phát API key, giới hạn truy cập có đo đếm) — giới hạn tần suất chứ không tăng năng lực phục vụ. Nó ngăn hệ thống sập bằng cách từ chối bớt request, tức là đổi lỗi hệ thống lấy lỗi người dùng. Đề nói mục tiêu là hỗ trợ được lượng dùng tăng thêm, không phải chặn bớt.

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

⚠ Bộ đề có một câu gần trùng với khoá đáp án NGƯỢC LẠI — câu #10938:

#10918 (câu này): API Gateway + Lambda + Aurora, request GET lặp lại
        → khoá: edge-optimized + API Gateway caching

#10938: API Gateway + Lambda + Aurora Serverless, request GET lặp lại
        → khoá: ElastiCache for Redis
        ↓
    Hai đề mô tả gần như cùng một tình huống, hai khoá loại trừ nhau

Cách phân biệt khi làm bài: đọc kỹ phương án nào có mặt trong danh sách. Ở câu này ElastiCache là phương án B và API Gateway caching là D; ở #10938 thì ngược lại về vai trò đúng/sai. Khi hai kỹ thuật đều hợp lý, hãy chọn theo tín hiệu phụ trong đề — ở đây là "significant increase in requests" từ một chiến dịch quảng bá (tải đọc lặp lại ở tầng API), còn ở #10938 là "database memory errors" gắn với Aurora Serverless (tải dồn vào tầng dữ liệu).

Không sửa khoá đáp án, chỉ ghi chú. Trong thực tế, hai kỹ thuật này bổ sung cho nhau chứ không loại trừ: một hệ thống chịu tải cao thường có cả cache ở API Gateway lẫn cache ở tầng dữ liệu.

Ghi nhớ

⚠ Bốn tầng cache trong kiến trúc serverless — bảng phải thuộc, theo thứ tự từ ngoài vào: | Tầng | Công cụ | Chặn được gì | |---|---|---| | Biên | CloudFront | request chưa tới Region | | API | API Gateway cache | Lambda và mọi thứ phía sau | | Ứng dụng | ElastiCache | truy vấn tới cơ sở dữ liệu | | Cơ sở dữ liệu | buffer pool của engine | đọc đĩa |

Từ khoá nhận diện:

"repeated GET requests for the same data" → cache — chọn tầng theo phương án có sẵn "minimize cost increase" → cache ở tầng ngoài chặn được nhiều chi phí nhất "usage plan" khi cần tăng năng lực → SAI, đó là giới hạn "tăng instance size" khi vấn đề là truy vấn lặp → mở rộng dọc, không bền cache ở API Gateway → không cần sửa mã, chỉ cấu hình stage

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỷ lệ trúng cache | CacheHitCount so với CacheMissCount | | Tải cơ sở dữ liệu có giảm không | số kết nối và CPU của Aurora trước/sau | | Số lời gọi Lambda có giảm không | chỉ số Invocations |

Và một lời khuyên: hãy khai đúng những tham số nào tham gia vào cache key, đừng để mặc định. Đây là chỗ cache hoặc trở nên vô dụng hoặc trở nên nguy hiểm, tuỳ hướng sai: nếu bạn đưa cả những tham số biến thiên theo từng người dùng vào cache key, mỗi request thành một mục riêng và tỷ lệ trúng gần bằng 0 — bạn trả tiền cho một cụm cache không giúp gì. Còn nếu bạn bỏ sót một tham số thật sự ảnh hưởng tới nội dung trả về, hai người dùng khác nhau sẽ nhận cùng một phản hồi. Trường hợp thứ hai không gây lỗi, không ghi log gì bất thường, và chỉ lộ ra khi có người nhìn thấy dữ liệu của người khác.

Đáp án

C — Triển khai Amazon S3 File Gateway, cấu hình để lưu cả hồ sơ bệnh nhân lẫn ảnh chẩn đoán trong S3 Standard-Infrequent Access, truy cập qua SMB.

Vì sao đúng

Đề nêu bốn ràng buộc, và ràng buộc cuối cùng — truy xuất trong thời gian ngắn — quyết định lớp lưu trữ.

⚠ Điểm mấu chốt: Standard-IA lấy ra ngay lập tức, còn Glacier thì không — đó là chỗ phương án D sai:

S3 Standard-IA
        ↓
    Rẻ hơn Standard khoảng 45% về lưu trữ
    Có phí truy xuất mỗi GB
    → NHƯNG độ trễ lấy ra giống hệt Standard: vài mili giây
        ↓
S3 Glacier Flexible Retrieval
        ↓
    Rẻ hơn nữa, nhưng phải KHÔI PHỤC trước khi đọc
    → từ vài phút tới vài giờ tuỳ tier
        ↓
    → không đáp ứng "retrievable within a short time frame" cho dữ liệu y tế

Vì sao dùng chung một lớp cho cả hai loại dữ liệu. Đề nói cả hai tập dữ liệu đều ít truy cập nhưng phải lấy được nhanh — không có lý do tách chúng ra hai lớp khác nhau, và việc tách còn tạo thêm phức tạp trong cấu hình lifecycle.

aws storagegateway create-smb-file-share \
  --gateway-arn <gw> --role <role> \
  --location-arn arn:aws:s3:::ho-so-benh-nhan \
  --default-storage-class S3_STANDARD_IA \
  --authentication ActiveDirectory

⚠ Standard-IA tính phí truy xuất và có thời gian lưu tối thiểu 30 ngày:

Object bị xoá hoặc chuyển lớp trước 30 ngày
        ↓
    Vẫn bị tính đủ tiền lưu trữ 30 ngày
        ↓
    Cộng với phí truy xuất mỗi lần đọc
        ↓
    → nếu dữ liệu thực ra được đọc thường xuyên, Standard-IA ĐẮT HƠN Standard

Vì thế câu "infrequently accessed" trong đề không phải chi tiết trang trí — nó là điều kiện để lựa chọn này đúng.

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

• D (S3 File Gateway, hồ sơ bệnh nhân vào Standard-IA còn ảnh chẩn đoán vào S3 Glacier) — đây là phương án gần nhất và việc phân tầng theo loại dữ liệu nghe rất hợp lý: ảnh chẩn đoán là tệp lớn, và Glacier rẻ hơn nhiều. Nhưng nó vi phạm yêu cầu "retrievable within a short time frame": dữ liệu trong Glacier Flexible Retrieval phải qua bước khôi phục mất từ vài phút tới vài giờ. Với ảnh chẩn đoán trong một kịch bản khôi phục thảm hoạ y tế, độ trễ đó là không chấp nhận được. Ngoài ra S3 File Gateway không phục vụ trực tiếp object nằm trong lớp Glacier — chúng phải được khôi phục về lớp truy cập tức thì trước.

• A (Amazon FSx File Gateway với FSx for Windows File Server Multi-AZ, lưu trữ HDD) — đắt hơn nhiều cho một kho sao lưu ít truy cập. FSx for Windows tính tiền theo dung lượng cấp phát và theo thông lượng, kể cả khi không ai đọc; S3 chỉ tính theo dung lượng thực dùng. Với dữ liệu chỉ đọc khi có sự cố, một hệ thống tệp có quản lý chạy 24/7 là chi phí không cần thiết.

• B (AWS Outposts với S3, dựng một EC2 Windows trên Outposts làm file server) — nặng nề nhất. Outposts là tủ rack vật lý AWS đặt tại chỗ, có chi phí cam kết lớn và thời gian triển khai dài; nó dành cho khối lượng công việc cần độ trễ cực thấp tại chỗ hoặc ràng buộc lưu trú dữ liệu. Dùng nó làm nơi sao lưu, rồi còn tự dựng và vận hành một file server Windows trên đó, đi ngược mọi mục tiêu của đề.

Ghi nhớ

⚠ Bốn lớp S3 và thời gian lấy ra — bảng phải thuộc: | Lớp | Lấy ra | Hợp với | |---|---|---| | Standard | tức thì | truy cập thường xuyên | | Standard-IA / One Zone-IA | tức thì | ít truy cập, cần ngay khi cần | | Glacier Instant Retrieval | tức thì | lưu trữ dài hạn, thỉnh thoảng đọc | | Glacier Flexible Retrieval | phút tới giờ | sao lưu, ít khi đọc | | Glacier Deep Archive | 12 giờ trở lên | lưu trữ tuân thủ nhiều năm |

Từ khoá nhận diện:

"SMB file share" + sao lưu lên AWS → S3 File Gateway "infrequently accessed but retrievable quickly" → Standard-IA hoặc Glacier Instant Retrieval "Glacier" khi đòi lấy ra nhanh → SAI trừ Glacier Instant Retrieval "FSx for Windows" làm kho sao lưu ít truy cập → đắt, tính tiền theo dung lượng cấp | "Outposts" cho việc sao lưu → quá nặng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Object đang ở lớp nào | aws s3api head-object, xem StorageClass | | Chi phí thật | so phí lưu trữ tiết kiệm với phí truy xuất phát sinh | | Gateway có đọc được không | mount SMB share và mở thử một tệp |

Và một lời khuyên: hãy đo tần suất truy cập thật trước khi chọn Standard-IA, đừng dựa vào giả định "dữ liệu sao lưu thì ít khi đọc". Đây là chỗ một tối ưu chi phí quay ngược lại cắn: Standard-IA rẻ hơn ở phần lưu trữ nhưng tính phí cho mỗi GB đọc ra, nên nếu thực tế có một quy trình nào đó quét qua dữ liệu định kỳ — một job kiểm tra tính toàn vẹn, một công cụ chống virus, một hệ thống lập chỉ mục — thì hoá đơn truy xuất có thể vượt xa khoản tiết kiệm. Những quy trình đó thường chạy âm thầm và không ai coi chúng là "truy cập dữ liệu", nên chúng không xuất hiện trong bất kỳ ước tính nào cho tới khi hoá đơn về.

Đáp án

A — Auto Scaling group Multi-AZ dùng AMI của ứng dụng; ALB với Auto Scaling group đó làm target; Kinesis Data Firehose đẩy tới ứng dụng kiểm toán bên thứ ba; tạo web ACL trong WAF, gắn vào ALB và bật logging với Firehose làm đích; đăng ký AWS Managed Rules từ Marketplace.

Vì sao đúng

Đề đòi hai thứ tách bạch, và chỉ một phương án làm đủ cả hai: tính sẵn sàng cao và lọc tấn công phổ biến kèm gửi request bị chặn sang hệ thống kiểm toán.

⚠ Điểm mấu chốt: WAF logging ghi trực tiếp vào Firehose — đó là đường chính thức để đẩy log ra hệ thống ngoài:

Request bị WAF chặn
        ↓
    WAF ghi một bản ghi log đầy đủ (IP, luật khớp, header, hành động)
        ↓
    Đích logging là Kinesis Data Firehose
        ↓
    Firehose đẩy tới HTTP endpoint của ứng dụng kiểm toán bên thứ ba
        ↓
    → không phải viết mã, không có Lambda trung gian nào phải bảo trì

Vì sao Multi-AZ Auto Scaling group (điểm phân biệt với B). Đề nói ứng dụng hiện chạy trong một AZ duy nhất và yêu cầu đầu tiên là làm cho nó sẵn sàng cao. Chỉ thêm ALB trước các instance cũ không đạt được điều đó — chúng vẫn ở cùng một AZ và vẫn không tự thay thế khi hỏng.

aws wafv2 put-logging-configuration --logging-configuration \
  ResourceArn=<web-acl-arn>,LogDestinationConfigs=<firehose-arn>

⚠ Tên Firehose dùng cho WAF phải bắt đầu bằng aws-waf-logs-:

Đặt tên khác quy ước
        ↓
    Firehose không hiện ra trong danh sách đích khi cấu hình WAF logging
        ↓
    → và không có thông báo nào giải thích vì sao

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

• B (ALB với target group thêm các EC2 hiện có, Firehose, WAF, Managed Rules) — đây là phương án gần nhất và toàn bộ phần bảo mật của nó chính xác bằng đáp án đúng: WAF, Managed Rules, logging qua Firehose đều chuẩn. Nó chỉ thiếu vế tính sẵn sàng cao: thêm ALB trước các instance đang có không làm chúng trải nhiều AZ và không tạo cơ chế tự thay thế máy hỏng. Đề nêu hai yêu cầu ngang nhau — "highly available and secure" — nên một phương án chỉ giải một nửa không thể đúng.

• C (Multi-AZ ASG + ALB — đúng; nhưng dùng Amazon Inspector giám sát và Lambda đẩy báo cáo Inspector sang bên thứ ba) — sai công cụ. Inspector đánh giá lỗ hổng phần mềm (CVE) trên tài nguyên, nó không giám sát lưu lượng và không biết request nào bị WAF từ chối. Báo cáo của Inspector không chứa thông tin về các request bị chặn, nên yêu cầu "rejected requests sent to auditing application" không được đáp ứng.

• D (ALB + các EC2 hiện có, WAF với logging vào CloudWatch Logs, Lambda định kỳ đẩy log sang bên thứ ba) — thiếu tính sẵn sàng cao như B, và cách chuyển log kém hơn: Lambda đẩy theo chu kỳ thay vì luồng liên tục, thêm mã phải bảo trì, thêm độ trễ, và thêm một chỗ có thể hỏng âm thầm.

Ghi nhớ

⚠ Bốn đích của WAF logging — bảng phải thuộc: | Đích | Khi nào | |---|---| | Kinesis Data Firehose | đẩy sang hệ thống ngoài, S3, Splunk, HTTP endpoint | | CloudWatch Logs | truy vấn bằng Logs Insights | | S3 trực tiếp | lưu trữ và phân tích bằng Athena |

Từ khoá nhận diện:

"filter common vulnerability attacks" → AWS Managed Rules trong WAF "send rejected requests to a third-party application" → WAF logging → Firehose "highly available" khi đang ở một AZ → Multi-AZ Auto Scaling group, không chỉ thêm ALB "Inspector" để giám sát lưu lượng → SAI, Inspector quét lỗ hổng "Lambda đẩy log định kỳ" khi có đường trực tiếp → thêm việc bảo trì không cần thiết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log có tới bên thứ ba không | kiểm chỉ số delivery của Firehose | | Có chặn nhầm không | so BlockedRequests với lưu lượng bình thường | | Instance có trải nhiều AZ không | kiểm phân bố của Auto Scaling group |

Và một lời khuyên: hãy bật mọi Managed Rule ở chế độ Count trước, và giữ nguyên như vậy ít nhất một tuần. Đây là chỗ một cải thiện bảo mật gây ra sự cố lớn hơn thứ nó ngăn chặn: các bộ luật quản lý được viết cho mọi loại ứng dụng, nên chúng chắc chắn sẽ khớp nhầm một số request hợp lệ của riêng ứng dụng bạn — một trường form chứa dấu nháy đơn, một payload JSON có cấu trúc lạ, một header do ứng dụng di động tự đặt. Ở chế độ Block, những request đó bị từ chối ngay từ giây đầu tiên, và người dùng bị ảnh hưởng thường không báo cáo mà chỉ bỏ đi. Ở chế độ Count, chúng xuất hiện trong log như những dòng chờ bạn đọc, không gây thiệt hại nào.

Đáp án

A — Dùng Auto Scaling group cho EC2 và bật RDS auto scaling để tự điều chỉnh dung lượng cơ sở dữ liệu theo nhu cầu.

Vì sao đúng

Đề đòi co giãn cả hai tầng với ít công phát triển nhất, và cả hai đều có cơ chế dựng sẵn không cần sửa mã.

⚠ Điểm mấu chốt: đề hỏi "scale the architecture" — tức là cả hai tầng, không chỉ tầng web:

Chỉ co giãn tầng web
        ↓
    Thêm máy web → thêm kết nối và truy vấn tới cùng một cơ sở dữ liệu
        ↓
    → nút thắt chuyển từ tầng web xuống tầng dữ liệu, không biến mất
        ↓
    → phải xử lý cả hai

Đây là lý do phương án C — vốn cũng có Auto Scaling group — không đủ.

# Auto Scaling group cho tầng web
aws autoscaling put-scaling-policy --auto-scaling-group-name web-asg \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration \
  '{"TargetValue":60,"PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"}}'

# RDS storage autoscaling
aws rds modify-db-instance --db-instance-identifier shop-db \
  --max-allocated-storage 1000 --apply-immediately

⚠ "RDS auto scaling" có hai nghĩa khác nhau — biết bạn đang cần cái nào: | Cơ chế | Co giãn cái gì | |---|---| | Storage autoscaling | dung lượng đĩa — tự tăng khi gần đầy | | Aurora Auto Scaling | số lượng read replica theo tải | | Aurora Serverless v2 | năng lực tính toán (ACU) theo tải |

Với một cụm RDS thường, cách co giãn năng lực đọc là thêm read replica; với Aurora thì có auto scaling cho replica.

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

• C (Auto Scaling group cho EC2 và bật RDS Multi-AZ để cải thiện hiệu năng và tính sẵn sàng cao) — đây là phương án gần nhất và nó đúng ở tầng web hoàn toàn. Nhưng nó hiểu sai Multi-AZ. Multi-AZ là cơ chế TÍNH SẴN SÀNG, không phải cơ chế hiệu năng: bản dự phòng đồng bộ ở AZ khác không phục vụ đọc (trừ cấu hình Multi-AZ DB cluster mới), nó chỉ chờ để tiếp quản khi bản chính hỏng. Bật Multi-AZ không thêm một truy vấn nào được xử lý, nên vấn đề chậm khi cao điểm còn nguyên. Đây là hiểu nhầm phổ biến nhất về RDS và là bẫy chính của câu hỏi.

• B (chuyển sang container ECS và thêm ElastiCache để giảm tải cơ sở dữ liệu) — về kỹ thuật là một kiến trúc tốt, thậm chí tốt hơn ở tải rất cao. Nhưng nó đòi đóng gói lại ứng dụng thành container và sửa mã để dùng cache — đi ngược tiêu chí "minimal development effort" mà đề nêu thẳng.

• D (chuyển ứng dụng web sang Lambda và tăng provisioned capacity của RDS) — đòi viết lại toàn bộ ứng dụng theo mô hình hàm. Và tăng capacity thủ công không phải co giãn: bạn cấp theo đỉnh rồi trả tiền mức đó suốt thời gian còn lại.

Ghi nhớ

⚠ Bốn cách mở rộng tầng dữ liệu RDS — bảng phải thuộc: | Cách | Mở rộng cái gì | |---|---| | Read replica | năng lực ĐỌC | | Tăng lớp máy (scale up) | cả đọc và ghi, nhưng có trần | | Storage autoscaling | dung lượng đĩa | | ElastiCache | giảm số truy vấn phải tới CSDL | | Multi-AZ | KHÔNG mở rộng gì — đó là tính sẵn sàng |

Từ khoá nhận diện:

"scale the architecture" → cả tầng web lẫn tầng dữ liệu "minimal development effort" → bật tính năng có sẵn, không sửa mã "Multi-AZ để cải thiện hiệu năng" → LUÔN SAI, Multi-AZ là tính sẵn sàng chuyển sang container hoặc Lambda khi đề đòi ít công → viết lại quá nhiều "tăng provisioned capacity" → không phải co giãn tự động

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Auto Scaling có kích hoạt không | lịch sử hoạt động của group | | Cơ sở dữ liệu có phải nút thắt không | DatabaseConnections, CPUUtilization, ReadLatency | | Có chạm trần max không | so số instance hiện tại với max capacity |

Và một lời khuyên: hãy đặt cảnh báo khi Auto Scaling group chạm max capacity, đừng chỉ theo dõi CPU. Đây là giới hạn hỏng theo cách im lặng nhất trong toàn bộ cấu hình co giãn: khi group đã ở mức tối đa, nó ngừng thêm máy — nhưng nó không báo lỗi, không tạo sự kiện đáng chú ý, và các chỉ số vẫn tiếp tục được ghi bình thường. Thứ bạn thấy là CPU cắm trần và thời gian phản hồi tăng dần, y hệt như khi chưa có auto scaling — nên phản xạ tự nhiên là đi kiểm tra xem chính sách co giãn có hoạt động không, trong khi nó đã hoạt động hoàn hảo và đã làm hết những gì bạn cho phép.

Đáp án

A — Xuất dữ liệu từ instance đang mã hoá và nhập vào một instance không mã hoá.

Vì sao đúng

Câu này kiểm tra một sự thật đơn giản nhưng nhiều người không biết: trạng thái mã hoá của một RDS instance không thể đảo ngược.

⚠ Điểm mấu chốt: mọi thứ dẫn xuất từ một instance đã mã hoá đều tiếp tục được mã hoá:

Instance đã mã hoá
        ↓
    Snapshot của nó  → đã mã hoá
    Read replica của nó → đã mã hoá
    Instance khôi phục từ snapshot đó → đã mã hoá
        ↓
    → không có đường nào trong hệ thống RDS cho ra một bản không mã hoá
        ↓
    → cách duy nhất là đi qua tầng DỮ LIỆU: xuất ra rồi nhập vào nơi mới

Đây là lý do ba phương án còn lại đều mô tả những thao tác không tồn tại hoặc không được phép.

Quy trình thực tế:

# 1. Tạo instance mới, KHÔNG mã hoá
aws rds create-db-instance --db-instance-identifier db-moi \
  --engine mysql --db-instance-class db.r6g.large \
  --allocated-storage 100    # không có --storage-encrypted

# 2. Xuất và nhập ở tầng dữ liệu
mysqldump -h db-cu.xxx.rds.amazonaws.com -u admin -p ten_csdl > ban_sao.sql
mysql   -h db-moi.xxx.rds.amazonaws.com -u admin -p ten_csdl < ban_sao.sql

Với cơ sở dữ liệu lớn, AWS DMS làm việc này với downtime ít hơn nhiều nhờ CDC.

⚠ Cân nhắc lại trước khi làm: gỡ mã hoá hầu như không mang lại lợi ích gì:

Mã hoá at rest của RDS gần như không ảnh hưởng hiệu năng
Với AWS managed key thì cũng không tốn thêm tiền khoá
        ↓
    → "không còn yêu cầu mã hoá" không có nghĩa là "phải gỡ mã hoá"
        ↓
    → chi phí và rủi ro của việc di chuyển dữ liệu thường lớn hơn lợi ích

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

• D (tạo snapshot không mã hoá của instance rồi dựng instance mới từ snapshot đó) — đây là phương án gần nhất và nghe hoàn toàn hợp lý: sao chép snapshot là cách người ta vẫn dùng để đổi khoá hoặc chuyển Region. Nhưng nó bất khả thi: snapshot của một instance đã mã hoá luôn được mã hoá, và thao tác sao chép snapshot không cho phép bỏ mã hoá — bạn chỉ đổi được sang khoá KMS khác. Đây là bẫy chính của câu hỏi vì nó khai thác đúng giả định rằng mã hoá là một thuộc tính bật tắt được.

• C (tạo read replica không mã hoá rồi thăng cấp nó lên làm primary) — cùng lý do: read replica của một instance đã mã hoá bắt buộc phải mã hoá. Không có tuỳ chọn tạo replica không mã hoá từ nguồn đã mã hoá.

• B (gọi API CreateDBInstance với StorageEncrypted đặt thành false để tắt mã hoá) — sai về bản chất API. CreateDBInstance tạo một instance MỚI, nó không sửa instance đang có; và tham số StorageEncrypted chỉ có tác dụng lúc tạo, không phải một công tắc đổi được sau đó. Phương án này mô tả một thao tác không tồn tại.

Ghi nhớ

⚠ Bốn quy tắc mã hoá RDS — bảng phải thuộc: | Quy tắc | Nội dung | |---|---| | Chỉ đặt được lúc tạo | không bật cũng không tắt được sau đó | | Mọi thứ dẫn xuất đều thừa kế | snapshot, replica, bản khôi phục | | Đổi trạng thái | chỉ qua xuất/nhập ở tầng dữ liệu | | Đổi khoá KMS | sao chép snapshot sang khoá mới, rồi khôi phục |

Từ khoá nhận diện:

"unencrypt an encrypted DB" → xuất và nhập, không có cách nào khác "encrypt an unencrypted DB" → snapshot → sao chép có mã hoá → khôi phục "tạo snapshot không mã hoá từ instance đã mã hoá" → LUÔN SAI "read replica không mã hoá" từ nguồn đã mã hoá → LUÔN SAI "StorageEncrypted = false để tắt" → SAI, tham số chỉ có tác dụng lúc tạo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance có mã hoá không | describe-db-instances, xem StorageEncrypted | | Dữ liệu đã chuyển đủ chưa | so số bảng và số dòng hai bên | | Ứng dụng đã trỏ đúng chưa | kiểm chuỗi kết nối sau khi cắt chuyển |

Và một lời khuyên: hãy hỏi lại xem việc gỡ mã hoá có thật sự cần thiết không, trước khi lên kế hoạch di chuyển dữ liệu. Mã hoá at rest của RDS gần như không có chi phí hiệu năng đo được, và với khoá do AWS quản lý thì cũng không có chi phí tiền bạc. "Dữ liệu đã được phân loại lại và không còn yêu cầu mã hoá" là một tuyên bố về yêu cầu tuân thủ, không phải một chỉ thị phải gỡ bỏ. Đổi lại, việc xuất và nhập một cơ sở dữ liệu production mang theo downtime, rủi ro mất dữ liệu, và một cửa sổ trong đó bạn có hai bản sao cần đồng bộ — tất cả để đạt được một trạng thái không tốt hơn trạng thái hiện tại về bất kỳ mặt nào.