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

Đáp án

B và D.

• B — Thiết lập một Federation proxy hoặc Identity Provider, và dùng AWS Security Token Service (STS) để sinh token tạm thời
• D — Cấu hình một IAM role và IAM policy để truy cập bucket

Vì sao đúng

Đề nêu hai yêu cầu, và cặp B+D là kiến trúc chuẩn cho cả hai: | Yêu cầu | Cơ chế | |---|---| | Đăng nhập một lần từ AD hoặc LDAP của công ty | B — federation + STS | | Mỗi người chỉ vào được thư mục riêng của mình | D — IAM role + policy có biến |

B — vì sao federation là bắt buộc với 1.200 người:

Tạo 1.200 IAM user:
    → quản lý hai bộ danh tính song song (AD và IAM)
    → nhân viên nghỉ việc phải nhớ xoá ở CẢ HAI nơi
    → 1.200 bộ access key dài hạn cần xoay vòng
    → gần chạm hạn mức 5.000 IAM user mỗi tài khoản

Federation:
    → danh tính chỉ tồn tại ở AD
    → STS cấp token TẠM THỜI khi cần
    → nghỉ việc = vô hiệu hoá tài khoản AD là xong

D — và phần thú vị nhất là cách một policy DUY NHẤT phục vụ cả 1.200 người:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
  "Resource": "arn:aws:s3:::tai-lieu-nhan-vien/home/${aws:userid}/*"
}

${aws:userid} là BIẾN POLICY — nó được thay bằng định danh của chính người đang gọi lúc chạy:

Người dùng A gọi  → Resource thành .../home/A/*
Người dùng B gọi  → Resource thành .../home/B/*

Một policy, 1.200 phạm vi khác nhau — không phải viết 1.200 policy.

Với federation SAML, biến thường dùng là ${saml:sub} hoặc một thuộc tính tuỳ chỉnh ánh xạ từ tên đăng nhập AD.

Và statement cho phép liệt kê cũng cần biến, ở một dạng khác:

{
  "Effect": "Allow",
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::tai-lieu-nhan-vien",
  "Condition": {"StringLike": {"s3:prefix": ["home/${aws:userid}/*"]}}
}

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

• E. Tạo một IAM user tương ứng cho mỗi trong 1.200 người dùng trong thư mục công ty — đây là phương án gần nhất và về mặt kỹ thuật làm được (dưới hạn mức 5.000), nhưng nó trái thẳng yêu cầu single sign-on và tạo gánh nặng quản lý khổng lồ với hai bộ danh tính song song.
• **A. Dùng giải pháp Single Sign-On của bên thứ ba như Atlassian Crowd, OKTA, OneLogin — là một phần hợp lệ của giải pháp (chúng đóng vai trò identity provider), nhưng nó không đầy đủ: bạn vẫn cần STS để đổi lấy thông tin đăng nhập AWS, và vẫn cần IAM role với policy giới hạn thư mục. Phương án B mô tả cơ chế tổng quát hơn và chính xác hơn.
• C. Ánh xạ mỗi người dùng tới một thư mục riêng trong S3 bằng Amazon WorkDocs — thay thế bài toán bằng một dịch vụ khác: WorkDocs là dịch vụ lưu trữ và chia sẻ tài liệu riêng, không phải cách truy cập S3 bucket. Đề hỏi cách cấu hình truy cập S3.

Ghi nhớ

Các biến policy của IAM — công cụ then chốt cho mẫu "thư mục riêng": | Biến | Giá trị | |---|---| | ${aws:userid} | định danh duy nhất của principal | | ${aws:username} | tên IAM user (không có với danh tính liên kết) | | ${saml:sub} | subject từ SAML assertion | | ${cognito-identity.amazonaws.com:sub} | định danh Cognito | | ${aws:PrincipalTag/<key>} | giá trị session tag |

Lưu ý quan trọng: ${aws:username} không tồn tại cho người dùng liên kết — với federation phải dùng ${aws:userid} hoặc thuộc tính SAML.

Ba API của STS — chọn theo nguồn danh tính: | API | Dùng cho | |---|---| | AssumeRoleWithSAML | AD FS, Okta, Ping — federation doanh nghiệp | | AssumeRoleWithWebIdentity | Google, Facebook, OIDC | | AssumeRole | chéo tài khoản, hoặc identity broker tự viết | | GetFederationToken | broker tự viết, thời hạn dài hơn |

Ba lợi ích của thông tin đăng nhập tạm thời: | Lợi ích | Chi tiết | |---|---| | Tự hết hạn | 15 phút tới 12 giờ — không cần xoay vòng | | Không lưu ở đâu cả | không có bí mật dài hạn để rò rỉ | | Thu hồi được | vô hiệu hoá ở IdP hoặc dùng aws:TokenIssueTime |

Kiến trúc đầy đủ cho tình huống của đề:

Người dùng đăng nhập AD
    ↓ AD FS hoặc IAM Identity Center phát hành SAML assertion
    ↓ AssumeRoleWithSAML
STS cấp thông tin đăng nhập tạm thời cho role "nhan-vien-s3"
    ↓ role có policy dùng ${aws:userid}
Chỉ truy cập được /home/<chính-mình>/*

Và với triển khai mới hôm nay, IAM Identity Center là lựa chọn nên cân nhắc trước: nó tích hợp sẵn với AD, quản lý quyền cho nhiều tài khoản AWS qua permission set, và có sẵn giao diện portal cho người dùng — thay vì phải tự dựng và vận hành AD FS.

Một lưu ý về đặt tên thư mục: dùng ${aws:userid} cho ra chuỗi định danh nội bộ (dạng AROAEXAMPLE:tenNguoiDung), không phải tên dễ đọc. Nếu muốn thư mục mang tên đăng nhập, hãy ánh xạ một session tag từ thuộc tính AD rồi dùng ${aws:PrincipalTag/username} — dễ đọc hơn nhiều khi rà soát bucket.

Đáp án

C — Cấu hình ứng dụng giao dịch trên các Amazon EC2 Windows Server ở hai Availability Zone. Dùng Amazon FSx for NetApp ONTAP tạo một file system Multi-AZ và truy cập dữ liệu qua giao thức iSCSI.

Vì sao đúng

Đề nêu hai yêu cầu, và một từ khoá quyết định toàn bộ câu trả lời: | Yêu cầu | Cơ chế | |---|---| | Sẵn sàng cao qua nhiều AZ | FSx Multi-AZ file system | | Truy cập BLOCK STORAGE độ trễ thấp | iSCSI — giao thức khối |

Cụm "block storage" là điểm phân biệt duy nhất và quyết định:

LƯU TRỮ KHỐI (block):    hệ điều hành thấy một Ổ ĐĨA THÔ
                          → tự định dạng, tự quản lý hệ thống tệp
                          → giao thức: iSCSI, NVMe
                          → ví dụ: EBS, FSx ONTAP LUN

LƯU TRỮ TỆP (file):      truy cập qua chia sẻ mạng
                          → giao thức: SMB, NFS
                          → ví dụ: FSx for Windows, EFS

LƯU TRỮ ĐỐI TƯỢNG:       truy cập qua HTTP API
                          → ví dụ: S3

Trong các dịch vụ FSx, chỉ NetApp ONTAP cung cấp lưu trữ khối: | Dịch vụ | Giao thức | |---|---| | FSx for NetApp ONTAP | NFS, SMB, VÀ iSCSI (khối) | | FSx for Windows File Server | CHỈ SMB (tệp) | | FSx for Lustre | POSIX (tệp) | | FSx for OpenZFS | NFS (tệp) |

Và FSx ONTAP hỗ trợ triển khai Multi-AZ thật: dữ liệu được sao chép đồng bộ giữa hai AZ, với chuyển đổi dự phòng tự động — đáp ứng vế sẵn sàng cao.

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

• A. EC2 Windows Server ở hai AZ; dùng Amazon FSx for Windows File Server làm bộ nhớ chia sẻ — đây là phương án gần nhất và là lựa chọn tự nhiên cho Windows, nhưng nó cung cấp lưu trữ TỆP qua SMB, không phải lưu trữ KHỐI. Đề nêu rõ "low-latency access to block storage".
• B. Dùng Amazon EFS làm bộ nhớ chia sẻ, cấu hình cross-region replication để đồng bộ dữ liệu giữa các AZ — hai lỗi: EFS là lưu trữ tệp qua NFS, chủ yếu cho Linux (hỗ trợ Windows rất hạn chế); và "cross-region replication để đồng bộ giữa các AZ" là vô nghĩa — EFS vốn đã tự sao chép giữa các AZ trong cùng một Region.
• D. Dùng Amazon S3 làm bộ nhớ và cấu hình cross-region replication để đồng bộ giữa các bucket ở mỗi AZ — nhầm khái niệm cơ bản: S3 là lưu trữ đối tượng, và bucket không thuộc về một AZ nào cả — S3 tự động lưu dữ liệu trên nhiều AZ trong một Region.

Ghi nhớ

Ba loại lưu trữ — bảng nền tảng: | Loại | Giao thức | Dịch vụ AWS | |---|---|---| | Khối (block) | iSCSI, NVMe | EBS, instance store, FSx ONTAP (LUN) | | Tệp (file) | NFS, SMB | EFS, FSx for Windows, FSx for Lustre, FSx for OpenZFS | | Đối tượng | HTTP API | S3, S3 Glacier |

Từ khoá nhận diện:

"block storage", "iSCSI", "raw device", "SAN" → EBS hoặc FSx ONTAP "shared file system", "SMB", "NFS", "POSIX" → EFS hoặc FSx "objects", "unlimited", "static content" → S3

Bốn dịch vụ trong họ Amazon FSx: | Dịch vụ | Đặc điểm | |---|---| | FSx for Windows File Server | SMB, tích hợp Active Directory — cho ứng dụng Windows | | FSx for Lustre | hiệu năng song song cực cao — HPC, học máy | | FSx for NetApp ONTAP | đa giao thức (NFS+SMB+iSCSI), nhiều tính năng doanh nghiệp | | FSx for OpenZFS | NFS, snapshot và clone nhanh |

FSx ONTAP nổi bật ở tính linh hoạt: cùng một tập dữ liệu truy cập được từ Linux (NFS), Windows (SMB) và như một ổ đĩa thô (iSCSI) — hữu ích cho môi trường lai.

Ba tính năng doanh nghiệp của FSx ONTAP đáng biết: | Tính năng | Lợi ích | |---|---| | Snapshot và clone tức thì | clone không tốn dung lượng cho tới khi ghi | | Phân tầng tự động sang lưu trữ dung lượng | dữ liệu nguội chuyển sang tầng rẻ hơn | | Nén và loại bỏ trùng lặp | giảm đáng kể dung lượng thực dùng | | SnapMirror | sao chép sang Region khác hoặc về tại chỗ |

Vì sao EBS không phải đáp án dù nó là lưu trữ khối: volume EBS gắn vào MỘT AZ và (trừ EBS Multi-Attach trong cùng AZ) không chia sẻ được giữa các instance ở AZ khác nhau. Yêu cầu "sẵn sàng cao qua nhiều AZ" cần một lớp lưu trữ tự sao chép giữa các AZ.

Và một lưu ý về chi phí: FSx ONTAP đắt hơn đáng kể so với EBS hay FSx for Windows. Với ứng dụng giao dịch tài chính nơi độ trễ và tính sẵn sàng là ưu tiên hàng đầu, đó là đánh đổi hợp lý — nhưng đừng chọn nó theo mặc định cho mọi workload Windows.

Đáp án

B — Thiết lập một EventBridge rule phát hiện thao tác S3 object PUT và đặt target là ECS cluster để chạy một ECS task mới.

Vì sao đúng

Đề hỏi cách ít công nhất (LEAST amount of effort), và B là phương án duy nhất không cần viết một dòng mã nào.

EventBridge gọi trực tiếp ECS RunTask được:

Object được tải lên S3
    ↓ S3 gửi sự kiện tới EventBridge
EventBridge rule khớp "Object Created"
    ↓ target: ECS task definition
ECS chạy một task Fargate mới

So sánh số thành phần với phương án A: | | B | A | |---|---|---| | Luồng | EventBridge → ECS | EventBridge → Lambda → ECS | | Mã phải viết | KHÔNG | có — Lambda gọi StartTask | | Phải bảo trì | không | mã, runtime, execution role |

ECS là một target dựng sẵn của EventBridge — không cần Lambda làm trung gian chỉ để gọi một API.

Event pattern:

{
  "source": ["aws.s3"],
  "detail-type": ["Object Created"],
  "detail": {"bucket": {"name": ["kho-du-lieu-vao"]}}
}

Điều kiện cần bật trên bucket — chi tiết hay bị bỏ sót:

aws s3api put-bucket-notification-configuration   --bucket kho-du-lieu-vao   --notification-configuration '{"EventBridgeConfiguration": {}}'

Không bật cấu hình này thì S3 không gửi sự kiện sang EventBridge, và rule sẽ không bao giờ khớp.

Và cách tiếp cận này khớp với mô hình chi phí mà đề mong muốn: task count tối thiểu giữ ở 1, mỗi tệp mới sinh ra đúng một task chạy rồi kết thúc — không có dung lượng nhàn rỗi nào.

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

• A. EventBridge rule phát hiện S3 PUT, target là một Lambda function chạy lệnh StartTask API — đây là phương án gần nhất và hoạt động hoàn toàn đúng, nhưng nó thêm một thành phần không cần thiết. Với yêu cầu "least amount of effort", bỏ được Lambda là bỏ được cả mã lẫn việc bảo trì.
• C. Đặt alarm trong CloudWatch giám sát thao tác object-level ghi trong CloudTrail; tạo EventBridge rule kích hoạt ECS cluster khi phát hiện sự kiện CloudTrail mới — thừa một tầng và tốn chi phí: phải bật CloudTrail data event (tính phí theo sự kiện) trong khi S3 gửi thẳng sang EventBridge được miễn phí. Và CloudWatch alarm ở giữa là hoàn toàn không cần.
• D. Đặt alarm trong CloudWatch giám sát thao tác object-level trong CloudTrail; đặt hai alarm action cập nhật ECS task count để scale-out/scale-in — sai mô hình xử lý: đề cần chạy một task cho mỗi tệp (xử lý theo lô), không phải điều chỉnh số lượng service task. Và CloudWatch alarm không đặt được task count trực tiếp.

Ghi nhớ

Các target trực tiếp của EventBridge — không cần Lambda trung gian: | Target | Dùng cho | |---|---| | ECS RunTask | chạy container theo sự kiện ← câu này | | SNS topic | thông báo | | SQS queue | xếp hàng xử lý | | Step Functions | quy trình nhiều bước | | SSM Automation document | khắc phục tự động không cần mã | | Lambda function | logic tuỳ ý | | Kinesis, API destination, EventBridge bus khác | |

Quy tắc thực dụng:

Nếu EventBridge gọi thẳng được đích cuối, đừng chèn Lambda vào giữa.

Hai cách S3 phát sự kiện: | Cách | Đặc điểm | |---|---| | S3 Event Notification | đích: SNS, SQS, Lambda, EventBridge — lọc theo prefix/suffix | | EventBridge (bật trên bucket) | lọc theo BẤT KỲ trường nào, nhiều target hơn |

EventBridge linh hoạt hơn đáng kể: nó lọc được theo kích thước object, theo người gọi, theo bất kỳ thuộc tính nào trong sự kiện — trong khi S3 Event Notification chỉ lọc theo prefix và suffix của tên khoá.

Ba loại sự kiện S3 gửi sang EventBridge: | detail-type | Khi nào | |---|---| | Object Created | PUT, POST, COPY, hoàn tất multipart | | Object Deleted | xoá hoặc tạo delete marker | | Object Restore Completed | khôi phục xong từ Glacier | | Object Tags Added / Deleted | thay đổi tag |

Cấu hình target ECS trong EventBridge rule:

{
  "Arn": "arn:aws:ecs:ap-northeast-1:111122223333:cluster/cum-xu-ly",
  "RoleArn": "arn:aws:iam::111122223333:role/EventBridgeECSRole",
  "EcsParameters": {
    "TaskDefinitionArn": "arn:aws:ecs:...:task-definition/xu-ly-tep:5",
    "LaunchType": "FARGATE",
    "TaskCount": 1,
    "NetworkConfiguration": {"awsvpcConfiguration": {
      "Subnets": ["subnet-0abc"], "AssignPublicIp": "DISABLED"}}
  }
}

InputTransformer đáng dùng để truyền tên tệp vào container:

"InputTransformer": {
  "InputPathsMap": {"khoa": "$.detail.object.key"},
  "InputTemplate": "{\"containerOverrides\":[{\"name\":\"app\",\"environment\":[{\"name\":\"TEP\",\"value\":\"<khoa>\"}]}]}"
}

Không có nó, task chạy nhưng không biết phải xử lý tệp nào.

Và một lưu ý về khối lượng: nếu bucket nhận rất nhiều tệp cùng lúc, chạy một task cho mỗi tệp có thể vượt hạn mức Fargate. Khi đó SQS làm bộ đệm với ECS service scale theo độ sâu hàng đợi là mô hình bền hơn — nhưng với yêu cầu đơn giản của đề, EventBridge → ECS là đủ và gọn nhất.

Đáp án

B — Triển khai chiến lược canary release cho API Gateway. Triển khai phiên bản API mới lên canary stage và chuyển một phần lưu lượng người dùng sang đó. Kiểm chứng, tăng dần tỷ lệ lưu lượng, theo dõi, và nếu ổn thì promote canary stage lên production.

Vì sao đúng

Đề nêu ba yêu cầu, và canary release của API Gateway đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Giảm gián đoạn cho khách hàng | chỉ một phần nhỏ lưu lượng gặp phiên bản mới | | Mất dữ liệu tối thiểu | phát hiện lỗi khi mới ảnh hưởng vài phần trăm | | Tiết kiệm chi phí nhất | tính năng DỰNG SẴN — không cần hạ tầng thứ hai |

Canary deployment là tính năng gốc của API Gateway stage:

aws apigateway update-stage --rest-api-id abc123 --stage-name prod   --patch-operations     op=replace,path=/canarySettings/percentTraffic,value=10     op=replace,path=/canarySettings/deploymentId,value=<deployment-moi>

Cách hoạt động:

Stage "prod" phục vụ 100% lưu lượng
    ↓ bật canary với percentTraffic = 10
90% request  → deployment CŨ
10% request  → deployment MỚI (canary)
    ↓ theo dõi metric và log riêng cho canary
    ↓ tăng dần: 10% → 25% → 50% → 100%
    ↓ promote canary
Canary trở thành deployment chính, canary settings bị xoá

Và vế "MOST cost-effective" là điểm phân biệt quyết định với blue-green: | | Canary (B) | Blue-green (D) | |---|---|---| | Hạ tầng | MỘT stage, một API Gateway | HAI môi trường song song | | Chi phí | không phát sinh thêm | gần gấp đôi trong thời gian chuyển đổi | | Cơ chế | tính năng dựng sẵn | phải tự dựng và tự chuyển DNS | | Quay lui | đặt percentTraffic về 0 | chuyển DNS về blue |

Điểm mạnh riêng của canary trong API Gateway: metric và log TÁCH RIÊNG. CloudWatch có metric riêng cho canary, nên bạn so sánh trực tiếp tỷ lệ lỗi và độ trễ giữa hai phiên bản trên cùng một lưu lượng thật.

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

• D. Triển khai blue-green deployment, đưa phiên bản mới lên môi trường green, chuyển một phần lưu lượng, kiểm chứng rồi promote — đây là phương án gần nhất và là chiến lược triển khai hợp lệ, nhưng nó tốn kém hơn: phải duy trì hai môi trường đầy đủ song song. Và API Gateway không có tính năng blue-green dựng sẵn — bạn phải tự dựng bằng hai API và điều khiển bằng Route 53 weighted routing.
• A. Tạo một API Gateway MỚI với phiên bản API cập nhật ở định dạng OpenAPI JSON/YAML, nhưng giữ CÙNG custom domain name — không thực hiện được như mô tả: một custom domain name chỉ ánh xạ tới một API và stage cho mỗi base path tại một thời điểm. Và chuyển đổi hoàn toàn như vậy là triển khai một lần (big bang) — đúng thứ mà đề muốn tránh.
• C. Sửa API Gateway hiện có với phiên bản mới bằng import-to-update ở chế độ overwrite hoặc merge — là triển khai một lần: nó thay thế toàn bộ định nghĩa API ngay lập tức. 100% người dùng gặp phiên bản mới cùng lúc, không có cơ chế kiểm chứng dần hay quay lui nhanh.

Ghi nhớ

Ba chiến lược triển khai — bảng phân biệt: | Chiến lược | Cách làm | Chi phí hạ tầng | |---|---|---| | Canary | chuyển dần % lưu lượng sang phiên bản mới | thấp — một môi trường | | Blue-green | hai môi trường đầy đủ, chuyển hẳn sang | cao — gấp đôi | | Rolling | thay thế dần từng instance | thấp | | All-at-once | thay hết cùng lúc | thấp, rủi ro cao nhất |

Canary và blue-green đều cho khả năng quay lui nhanh — khác biệt nằm ở chi phí và độ mịn của việc chuyển lưu lượng.

Bốn tham số của canary trong API Gateway: | Tham số | Việc | |---|---| | percentTraffic | phần trăm request đi vào canary (0–100) | | deploymentId | deployment nào đóng vai trò canary | | stageVariableOverrides | biến stage riêng cho canary (ví dụ trỏ sang Lambda alias khác) | | useStageCache | canary có dùng chung cache với stage chính không |

stageVariableOverrides rất hữu ích: nó cho phép canary gọi một Lambda alias khác hoặc một backend khác, trong khi stage chính không đổi.

Ba metric cần theo dõi trong giai đoạn canary: | Metric | Cảnh báo khi | |---|---| | 5XXError | tăng so với phiên bản cũ | | 4XXError | tăng bất thường (hợp đồng API thay đổi) | | Latency và IntegrationLatency | chậm hơn đáng kể |

Đặt CloudWatch alarm trên metric của canary và tự động quay lui khi vượt ngưỡng là bước hoàn thiện đáng làm — nó biến việc theo dõi thủ công thành cơ chế tự bảo vệ.

Ba lệnh của quy trình canary:

# ① Bắt đầu với 10%
op=replace,path=/canarySettings/percentTraffic,value=10

# ② Tăng dần sau khi kiểm chứng
op=replace,path=/canarySettings/percentTraffic,value=50

# ③ Promote — canary thành bản chính
aws apigateway update-stage --patch-operations   op=replace,path=/deploymentId,value=<deployment-moi>   op=remove,path=/canarySettings

Quay lui chỉ là đặt percentTraffic về 0 — nhanh hơn nhiều so với chuyển DNS, vốn còn phụ thuộc vào TTL và cache của trình phân giải.

Và một lưu ý về "minimal data loss" trong đề: canary giúp phát hiện lỗi sớm, nhưng nếu phiên bản mới ghi dữ liệu sai định dạng, thì 10% dữ liệu đó vẫn hỏng. Với thay đổi chạm tới lược đồ dữ liệu, hãy đảm bảo phiên bản mới tương thích ngược với dữ liệu cũ trước khi bật canary — chiến lược triển khai không thay thế được việc thiết kế thay đổi an toàn.

Đáp án

B — Dùng Amazon EFS.

Vì sao đúng

Đề nêu ba yêu cầu trong một câu, và cả ba đều chỉ tới EFS: | Yêu cầu | EFS | |---|---| | Hệ thống tệp chia sẻ (shared) | nhiều EC2 mount cùng lúc | | Tương thích POSIX | giao thức NFSv4 — quyền, symlink, khoá tệp | | Mở rộng được và sẵn sàng cao | tự mở rộng, dữ liệu trên nhiều AZ |

Vấn đề với kiến trúc hiện tại — và vì sao nó gây chậm:

Trước:  Mỗi EC2 có EBS volume RIÊNG
        → tệp người dùng tải lên nằm trên MỘT máy
        → request tiếp theo tới máy khác thì KHÔNG THẤY tệp
        → phải đồng bộ giữa các máy, hoặc dùng sticky session
        → Auto Scaling thêm máy mới thì máy đó không có dữ liệu

Sau:    Mọi EC2 mount CÙNG MỘT EFS
        → mọi máy thấy cùng một tập tệp ngay lập tức
        → thêm hay bớt instance không ảnh hưởng dữ liệu

"POSIX-compliant" là từ khoá loại trừ S3: | | EFS (POSIX) | S3 (đối tượng) | |---|---|---| | Truy cập | mount như thư mục, mở tệp bằng lệnh thường | HTTP API — GetObject, PutObject | | Ghi một phần tệp | ✅ được | ❌ phải ghi lại cả object | | Quyền POSIX, symlink, khoá tệp | ✅ | ❌ | | Sửa mã ứng dụng | KHÔNG cần | CÓ — phải viết lại phần I/O |

Dòng cuối là lý do thực dụng nhất: hệ thống CMS hiện đang đọc ghi tệp bằng lời gọi hệ thống thông thường. Chuyển sang EFS chỉ cần đổi đường dẫn mount; chuyển sang S3 phải viết lại toàn bộ tầng lưu trữ.

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

• A. Tạo một S3 bucket và dùng nó làm nơi lưu trữ cho CMS — đây là phương án gần nhất và là lựa chọn tốt cho nhiều kiến trúc web, nhưng nó không tương thích POSIX: S3 là lưu trữ đối tượng truy cập qua API. Đề nêu rõ yêu cầu "POSIX-compliant shared file system".
• **C. Nâng cấp EBS volume hiện tại lên Provisioned IOPS SSD — cải thiện tốc độ nhưng không giải quyết vấn đề chia sẻ: volume EBS vẫn gắn với một instance (trừ Multi-Attach trong cùng AZ với io1/io2). Tệp tải lên máy này vẫn không thấy được từ máy khác.
• **D. Dùng Amazon ElastiCache — sai loại dịch vụ: ElastiCache là cache trong bộ nhớ (Redis hoặc Memcached) cho dữ liệu tạm thời, không phải hệ thống tệp lưu trữ tài liệu.

Ghi nhớ

Bốn dịch vụ lưu trữ chia sẻ của AWS — chọn theo giao thức: | Dịch vụ | Giao thức | Hệ điều hành | |---|---|---| | Amazon EFS | NFSv4 (POSIX) | Linux | | FSx for Windows File Server | SMB | Windows | | FSx for Lustre | POSIX hiệu năng cao | Linux — HPC, học máy | | FSx for NetApp ONTAP | NFS + SMB + iSCSI | đa nền tảng |

Câu hỏi phân biệt:

"POSIX", "NFS", "Linux shared storage" → EFS "SMB", "Windows", "Active Directory" → FSx for Windows "HPC", "machine learning", "parallel" → FSx for Lustre

Bốn đặc điểm của EFS: | Đặc điểm | Chi tiết | |---|---| | Tự mở rộng | không khai dung lượng trước — từ vài KB tới petabyte | | Nhiều AZ | mount target ở mỗi AZ, dữ liệu tự sao chép | | Hàng nghìn client đồng thời | đúng cho Auto Scaling group | | Trả tiền theo dung lượng thực dùng | không trả cho phần chưa dùng |

Bốn lớp lưu trữ của EFS: | Lớp | Dùng cho | |---|---| | Standard | truy cập thường xuyên | | Infrequent Access (IA) | rẻ hơn ~92%, phí truy xuất | | Archive | dữ liệu rất ít truy cập | | One Zone | một AZ — rẻ hơn, ít bền hơn |

Lifecycle policy tự chuyển tệp không truy cập sang IA:

aws efs put-lifecycle-configuration --file-system-id fs-0abc   --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"},
                          {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

Đây là tối ưu chi phí quan trọng cho CMS: tài liệu cũ ít ai xem tự chuyển sang lớp rẻ, và tự quay lại Standard khi có người mở.

Ba lưu ý khi dùng EFS: | Lưu ý | Chi tiết | |---|---| | Security group của mount target phải mở cổng 2049 (NFS) | lỗi cấu hình phổ biến nhất | | Mỗi AZ một mount target | thiếu một cái thì instance ở AZ đó không mount được | | Độ trễ cao hơn EBS | EFS đi qua mạng; EBS gắn trực tiếp |

Dòng cuối là đánh đổi cần biết: EFS chậm hơn EBS cho thao tác I/O đơn lẻ. Với CMS lưu tài liệu người dùng thì hoàn toàn chấp nhận được, nhưng đừng đặt cơ sở dữ liệu có tải cao lên EFS.

Và ba tính năng nên bật cho môi trường sản xuất: mã hoá at-rest (bật lúc tạo, không đổi được sau), mã hoá in-transit (mount -o tls), và EFS Access Point để mỗi ứng dụng chỉ thấy thư mục riêng của mình với danh tính POSIX cố định.

Đáp án

B — Dùng Aurora Auto Scaling để tự động điều chỉnh số lượng read replica.

Vì sao đúng

Đề nêu vấn đề rõ: read replica không theo kịp lưu lượng đọc trong giờ cao điểm, và cần giải pháp tiết kiệm chi phí nhất.

Aurora Auto Scaling giải quyết đúng bản chất của bài toán — tải biến động:

Giờ thấp điểm:  2 replica  → đủ dùng, chi phí thấp
Giờ cao điểm:   tự tăng lên 8 replica → phục vụ được tải
Hết cao điểm:   tự giảm về 2 → không trả tiền cho dung lượng thừa

aws application-autoscaling put-scaling-policy   --service-namespace rds   --resource-id cluster:cum-aurora-ban-hang   --scalable-dimension rds:cluster:ReadReplicaCount   --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "RDSReaderAverageCPUUtilization"}}'

Vì sao nó tiết kiệm hơn việc tăng kích thước cụm (phương án A): | | Auto Scaling replica | Tăng kích thước instance | |---|---|---| | Chi phí giờ thấp điểm | thấp — ít replica | cao — trả cho máy lớn 24/7 | | Phản ứng với tải | tự động | thủ công | | Thời gian ngừng | không | có — thay đổi loại instance cần khởi động lại |

Và điểm mạnh riêng của Aurora: thêm replica rất nhanh.

Aurora tách TÍNH TOÁN khỏi LƯU TRỮ
    → replica mới KHÔNG cần sao chép dữ liệu
    → nó gắn thẳng vào lớp lưu trữ chung
    → sẵn sàng trong vài phút

Đây là khác biệt lớn so với RDS thường, nơi tạo read replica phải sao chép toàn bộ dữ liệu.

Và reader endpoint tự động cân bằng tải: khi replica mới được thêm, endpoint đọc tự đưa nó vào vòng luân phiên — ứng dụng không cần biết gì.

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

• **A. Tăng kích thước của Aurora DB cluster — đây là phương án gần nhất và giải quyết được vấn đề hiệu năng, nhưng nó không tiết kiệm: bạn trả tiền cho instance lớn suốt 24 giờ dù cao điểm chỉ vài tiếng. Và nó cần khởi động lại instance để áp dụng.
• **C. Triển khai read scaling bằng Aurora Global Database — giải pháp cho vấn đề khác và đắt hơn nhiều: Global Database phục vụ khôi phục thảm hoạ đa Region và giảm độ trễ đọc cho người dùng ở Region xa. Đề không nói gì về nhiều Region.
• **D. Thiết lập một read replica hoạt động ở Region khác — cùng vấn đề: cross-Region replica tăng chi phí (phí truyền dữ liệu giữa Region) mà không giải quyết đúng bài toán, vốn là thiếu dung lượng đọc trong giờ cao điểm ở cùng một Region.

Ghi nhớ

Ba loại endpoint của Aurora — cần dùng đúng: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) endpoint | instance chính — cho ghi | | Reader endpoint | cân bằng tải giữa MỌI replica — cho đọc | | Custom endpoint | nhóm instance do bạn chọn (xem câu #8145) | | Instance endpoint | một instance cụ thể |

Dùng reader endpoint là điều kiện để Auto Scaling có tác dụng — nếu ứng dụng nối thẳng vào instance endpoint, replica mới thêm sẽ không nhận được lưu lượng nào.

Bốn tham số của Aurora Auto Scaling: | Tham số | Việc | |---|---| | MinCapacity / MaxCapacity | số replica tối thiểu và tối đa (tối đa 15) | | Metric mục tiêu | RDSReaderAverageCPUUtilization hoặc RDSReaderAverageDatabaseConnections | | TargetValue | giá trị cần duy trì | | Cooldown | thời gian chờ giữa các lần điều chỉnh |

Chọn metric nào: CPU phù hợp khi truy vấn nặng tính toán; số kết nối phù hợp khi vấn đề là số lượng client đồng thời.

Kiến trúc Aurora — vì sao nó khác RDS:

Aurora:  Compute (writer + tối đa 15 reader)
              ↓ tất cả dùng chung
         Lớp lưu trữ phân tán: 6 bản sao trên 3 AZ

RDS thường:  mỗi instance có bản sao dữ liệu RIÊNG

Ba lựa chọn khác để mở rộng đọc — theo tình huống: | Lựa chọn | Phù hợp | |---|---| | Aurora Auto Scaling | tải biến động theo giờ ← câu này | | Aurora Serverless v2 | tải rất khó đoán — tự co giãn cả dung lượng từng instance | | ElastiCache trước Aurora | truy vấn lặp lại nhiều — rẻ nhất cho dữ liệu nóng |

Dòng cuối đáng cân nhắc nghiêm túc cho trang thương mại điện tử: phần lớn truy vấn đọc trong giờ cao điểm thường hỏi cùng những dữ liệu (danh mục sản phẩm, trang chủ). Đặt ElastiCache for Redis phía trước có thể cắt tới 80–90% lưu lượng đọc xuống cơ sở dữ liệu — thường rẻ hơn nhiều so với thêm replica.

Và một lưu ý về giới hạn: Aurora hỗ trợ tối đa 15 read replica cho mỗi cụm. Nếu chạm trần đó, các lựa chọn tiếp theo là caching, tách workload đọc sang cụm khác, hoặc xem lại chính các truy vấn — thường có vài câu SQL thiếu chỉ mục đang gây phần lớn tải.

Đáp án

D — Bật DynamoDB Stream và tạo một AWS Lambda trigger, cùng IAM role chứa mọi quyền Lambda cần lúc chạy. Dữ liệu từ bản ghi stream được Lambda xử lý, rồi publish thông điệp lên SNS topic để thông báo cho người theo dõi qua email.

Vì sao đúng

Đề cần một luồng phản ứng với thay đổi dữ liệu, và D là cách gọn nhất mà DynamoDB cung cấp:

Người dùng cập nhật dữ liệu
    ↓ DynamoDB Stream ghi bản ghi thay đổi
    ↓ Lambda trigger tự động được gọi (event source mapping)
Lambda đọc bản ghi, xác định ai đang theo dõi
    ↓ publish lên SNS topic
Người theo dõi nhận email

Điểm mấu chốt: "DynamoDB trigger" là tích hợp GỐC giữa DynamoDB Streams và Lambda. | Đặc điểm | Chi tiết | |---|---| | Không cần viết consumer | AWS quản lý việc đọc stream, chia shard, checkpoint | | Tự mở rộng theo số shard | song song theo shard | | Tự thử lại khi lỗi | có DLQ nếu cấu hình |

So sánh với cách dùng KCL (phương án A và B):

DynamoDB Streams Kinesis Adapter + KCL:
    → bạn tự viết ứng dụng consumer
    → tự quản lý bảng checkpoint (DynamoDB Leases)
    → tự vận hành máy chủ chạy ứng dụng đó
    → nhiều công hơn hẳn, cho cùng một kết quả

Và vế "IAM role chứa mọi quyền cần lúc chạy" trong đáp án là chi tiết đúng và cần thiết:

{
  "Effect": "Allow",
  "Action": [
    "dynamodb:GetRecords", "dynamodb:GetShardIterator",
    "dynamodb:DescribeStream", "dynamodb:ListStreams"
  ],
  "Resource": "arn:aws:dynamodb:...:table/nguoi-dung/stream/*"
},
{"Effect": "Allow", "Action": "sns:Publish", "Resource": "arn:aws:sns:...:thong-bao"}

(Managed policy AWSLambdaDynamoDBExecutionRole chứa sẵn nhóm quyền đầu.)

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

• B. Tạo Lambda function dùng DynamoDB Streams Kinesis Adapter để lấy dữ liệu từ endpoint DynamoDB Streams; thiết lập SNS topic thông báo — đây là phương án gần nhất và về mặt kỹ thuật khả thi, nhưng nó thừa hoàn toàn: Kinesis Adapter tồn tại cho ứng dụng dùng KCL. Lambda đã có tích hợp trực tiếp với DynamoDB Streams và không cần adapter nào.
• A. Viết ứng dụng dùng Kinesis Client Library (KCL) với DynamoDB Streams Kinesis Adapter — nhiều công nhất: phải tự viết ứng dụng, tự vận hành máy chủ chạy nó, tự quản lý checkpoint và mở rộng.
• C. Thiết lập một cụm DAX để truy cập bảng nguồn; tạo DynamoDB trigger và Lambda function... — thêm một dịch vụ hoàn toàn không liên quan: DAX là cache đọc trong bộ nhớ để giảm độ trễ truy vấn. Nó không đóng vai trò gì trong việc phát hiện thay đổi dữ liệu. (Phần còn lại của phương án mô tả đúng trigger, nhưng DAX là chi tiết thừa và sai.)

Ghi nhớ

Bốn tuỳ chọn StreamViewType của DynamoDB Streams: | Giá trị | Bản ghi chứa | |---|---| | KEYS_ONLY | chỉ khoá chính | | NEW_IMAGE | trạng thái item SAU thay đổi | | OLD_IMAGE | trạng thái item TRƯỚC thay đổi | | NEW_AND_OLD_IMAGES | cả hai — cần khi muốn biết cái gì đã đổi |

Cho tính năng "follow" của đề, NEW_AND_OLD_IMAGES là lựa chọn hợp lý — nó cho biết trường nào thay đổi để quyết định có đáng thông báo hay không.

Ba đặc điểm của DynamoDB Streams: | Đặc điểm | Chi tiết | |---|---| | Giữ bản ghi 24 GIỜ | không dài hơn được | | Đảm bảo thứ tự trong một partition key | | | Chính xác một bản ghi cho mỗi thay đổi | không trùng lặp trong stream |

Dòng đầu là ràng buộc quan trọng: nếu Lambda lỗi liên tục quá 24 giờ, bản ghi bị mất vĩnh viễn. Nên cấu hình DLQ và cảnh báo.

Bốn tham số của event source mapping: | Tham số | Việc | |---|---| | BatchSize | số bản ghi mỗi lần gọi Lambda (tối đa 10.000) | | MaximumRetryAttempts | mặc định là thử tới khi hết hạn — nên đặt giới hạn | | BisectBatchOnFunctionError | chia đôi lô khi lỗi để tách bản ghi hỏng | | DestinationConfig (DLQ) | nơi gửi bản ghi thất bại |

Ba tham số cuối là bắt buộc cho môi trường sản xuất: mặc định, một bản ghi lỗi sẽ chặn cả shard và Lambda thử lại mãi cho tới khi bản ghi hết hạn sau 24 giờ — nghĩa là mọi thay đổi sau đó cũng bị kẹt.

DynamoDB Streams và Kinesis Data Streams cho DynamoDB — hai lựa chọn: | | DynamoDB Streams | Kinesis Data Streams for DynamoDB | |---|---|---| | Giữ dữ liệu | 24 giờ | tới 365 ngày | | Số consumer | 2 | nhiều, qua enhanced fan-out | | Thứ tự | đảm bảo theo khoá | có thể trùng và lệch thứ tự | | Dùng khi | trigger đơn giản ← câu này | phân tích, nhiều consumer, cần phát lại |

Và một lưu ý về thiết kế cho tính năng "follow": nếu một người dùng có hàng triệu người theo dõi, publish một SNS message cho mỗi người sẽ rất chậm và tốn kém. Mô hình bền hơn là ghi bản ghi thông báo vào một bảng, rồi gửi email theo lô — hoặc dùng SNS với một topic cho mỗi người dùng nổi tiếng, để việc phát tán do SNS lo thay vì Lambda lặp qua danh sách.

Đáp án

B — Dùng một AWS Glue ETL job để xử lý và chuyển tệp .csv sang Apache Parquet, rồi lưu tệp kết quả vào bucket đích. Thiết lập S3 Event Notification theo dõi mọi sự kiện PUT và kích hoạt job Glue qua Amazon SQS.

Vì sao đúng

Đề nêu ba yêu cầu, và mấu chốt là "LEAST operational overhead": | Yêu cầu | Cơ chế | |---|---| | Chuyển CSV sang Parquet | Glue ETL — dịch vụ được quản lý cho việc này | | Tự động kích hoạt khi có tệp mới | S3 Event Notification | | Ít công vận hành nhất | không máy chủ nào phải quản lý |

Vì sao Glue là dịch vụ đúng:

AWS Glue = Apache Spark ĐƯỢC QUẢN LÝ
    → không dựng cụm, không vá lỗi, không mở rộng thủ công
    → hỗ trợ sẵn CSV, JSON, Parquet, ORC, Avro
    → tính phí theo DPU-giờ khi job chạy

Và kích thước tệp 2 GB là chi tiết loại trừ Lambda: | Giới hạn Lambda | Giá trị | |---|---| | Thời gian chạy tối đa | 15 phút | | Bộ nhớ tối đa | 10.240 MB | | Dung lượng /tmp | 512 MB – 10 GB |

Xử lý tệp 2 GB mỗi giờ từ nhiều nguồn trong 15 phút là rủi ro — và Glue không có giới hạn đó.

Vì sao Parquet đáng để chuyển đổi: | Định dạng | Đặc điểm | |---|---| | CSV | theo DÒNG — đọc một cột phải quét cả tệp | | Parquet | theo CỘT, có nén và metadata thống kê |

Kết quả đo được trong thực tế: truy vấn Athena trên Parquet thường quét ít hơn 30–90% dữ liệu so với CSV — và vì Athena tính phí theo dữ liệu quét, đó là khoản tiết kiệm trực tiếp.

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

• D. Tạo ETL job và Data Catalog table trong Glue; cấu hình Glue crawler chạy theo lịch mỗi giờ để kiểm tra tệp mới và chuyển sang Parquet — đây là phương án gần nhất và dùng đúng dịch vụ, nhưng nó sai cơ chế kích hoạt: đề yêu cầu chuyển đổi tự động khởi động mỗi khi có tệp mới, không phải quét theo lịch. Và crawler không chuyển đổi định dạng — nó chỉ phát hiện lược đồ và cập nhật Data Catalog.
• A. Lambda function kích hoạt bởi S3 PUT để chuyển CSV sang Parquet; dùng AWS Transfer Family với SFTP để chuyển tệp kết quả sang bucket đích — hai vấn đề: Lambda gặp giới hạn thời gian và bộ nhớ với tệp 2 GB; và dùng SFTP để chuyển tệp giữa hai bucket S3 là hoàn toàn vô lý — một lời gọi CopyObject là đủ.
• C. Chạy Apache Spark job trên EC2 instance; EventBridge rule theo dõi S3 PUT; Lambda gọi Spark job qua Function URL — công vận hành cao nhất: bạn phải tự dựng, vá, mở rộng và giám sát cụm Spark — đúng thứ mà "least operational overhead" muốn tránh.

Ghi nhớ

Bốn thành phần của AWS Glue: | Thành phần | Việc | |---|---| | ETL job | chuyển đổi dữ liệu — Spark hoặc Python shell | | Crawler | phát hiện lược đồ, cập nhật Data Catalog | | Data Catalog | kho metadata — Athena, Redshift Spectrum, EMR cùng dùng | | Trigger / Workflow | điều phối chuỗi job |

Phân biệt job và crawler là điểm sai của phương án D:

Crawler PHÁT HIỆN dữ liệu có gì. ETL job BIẾN ĐỔI dữ liệu.

Ba cách kích hoạt Glue job: | Cách | Đặc điểm | |---|---| | Theo lịch (cron) | định kỳ | | EventBridge event | theo sự kiện — đúng cho yêu cầu này | | Job trước hoàn tất | chuỗi phụ thuộc |

(Mô tả "qua Amazon SQS" trong đáp án hơi lỏng lẻo. Cách triển khai chuẩn hiện nay là S3 → EventBridge → Glue workflow, hoặc S3 → Lambda → StartJobRun. Nhưng B vẫn là phương án duy nhất kết hợp đúng dịch vụ ETL với cơ chế kích hoạt theo sự kiện.)

Ba định dạng cột và khi nào dùng: | Định dạng | Đặc điểm | |---|---| | Parquet | phổ biến nhất, hỗ trợ rộng | | ORC | nén tốt, mạnh trong hệ sinh thái Hive | | Avro | theo dòng, tốt cho streaming và tiến hoá lược đồ |

Ba tối ưu nên áp dụng khi ghi Parquet: | Tối ưu | Lợi ích | |---|---| | Phân vùng theo ngày/giờ | truy vấn một ngày chỉ quét một phân vùng | | Nén Snappy | cân bằng tốc độ và tỷ lệ nén | | Gộp tệp nhỏ | hàng nghìn tệp nhỏ làm truy vấn chậm hẳn |

Dòng cuối là vấn đề thực tế hay gặp: đề nói dữ liệu đến từ nhiều nguồn mỗi giờ, nên rất dễ sinh ra vô số tệp nhỏ. Glue có tính năng grouping để gộp chúng, và nên bật.

Ba lựa chọn thay thế cho Glue — tuỳ quy mô: | Lựa chọn | Phù hợp | |---|---| | Glue ETL | được quản lý, ít công nhất ← câu này | | Amazon EMR Serverless | cần kiểm soát Spark chi tiết hơn | | Athena CTAS | chuyển đổi bằng SQL thuần — rất gọn cho việc đơn giản |

Dòng cuối đáng biết: một câu CREATE TABLE AS SELECT của Athena chuyển được CSV sang Parquet có phân vùng mà không cần viết mã Spark nào:

CREATE TABLE du_lieu_parquet
WITH (format = 'PARQUET', partitioned_by = ARRAY['ngay'],
      external_location = 's3://bucket-dich/du-lieu/')
AS SELECT *, date(thoi_gian) AS ngay FROM du_lieu_csv;

Đáp án

B — Bật throttling limits và result caching trong API Gateway.

Vì sao đúng

Đề cần bảo vệ hệ thống backend khỏi đợt tăng đột biến lưu lượng, và hai cơ chế này bảo vệ theo hai cách bổ sung nhau: | Cơ chế | Bảo vệ bằng cách | |---|---| | Throttling | GIỚI HẠN số request đi tới backend | | Caching | TRẢ LỜI mà không cần gọi backend |

Throttling dùng thuật toán token bucket:

Rate limit  = số request mỗi giây ở trạng thái ổn định
Burst limit = dung lượng "thùng" cho đợt tăng ngắn

Vượt quá → API Gateway trả 429 Too Many Requests
         → backend KHÔNG bị chạm tới

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

Caching cắt tải ngay từ gốc:

Request tới /gia/bitcoin
    ├─ có trong cache (TTL chưa hết) → trả về NGAY, backend không biết gì
    └─ không có → gọi backend, lưu kết quả vào cache

Với tình huống của đề, caching đặc biệt hiệu quả: hàng trăm nghìn người cùng hỏi giá Bitcoin — một lời gọi backend phục vụ được tất cả trong khoảng TTL.

Và cả hai đều là tính năng cấu hình thuần — không sửa mã, không đổi kiến trúc.

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

• C. Dùng CloudFront trước API Gateway làm cache — đây là phương án gần nhất và có tác dụng cache thật, nhưng nó thừa và phức tạp hơn: API Gateway đã có caching tích hợp, và endpoint edge-optimized vốn đã đi qua mạng CloudFront. Thêm một distribution riêng làm tăng độ phức tạp mà không giải quyết vế throttling.
• **A. Chuyển từ Lambda và API Gateway sang kiến trúc EC2, ELB và Auto Scaling — đi ngược hướng: Lambda và API Gateway mở rộng nhanh hơn nhiều so với EC2 Auto Scaling (vài giây so với vài phút). Đây là bước lùi về khả năng chịu tải đột biến.
• D. Đưa Lambda function vào VPC — không liên quan tới bảo vệ khỏi tăng tải: đặt Lambda trong VPC là để truy cập tài nguyên riêng tư (RDS, ElastiCache). Nó không giới hạn lưu lượng và thậm chí thêm độ trễ khởi tạo ENI.

Ghi nhớ

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

Usage plan đáng dùng cho API thương mại: mỗi khách hàng một API key với hạn mức riêng — khách hàng này gây tăng tải không ảnh hưởng khách hàng khác.

Hai tham số của throttling: | Tham số | Ý nghĩa | |---|---| | rateLimit | số request/giây ở trạng thái ổn định | | burstLimit | dung lượng thùng token — cho phép đợt tăng NGẮN vượt rate |

burstLimit là thứ cho phép đối phó với đợt tăng đột ngột mà vẫn giữ được giới hạn trung bình.

Ba cấu hình của API Gateway caching: | Cấu hình | Chi tiết | |---|---| | Kích thước cache | 0,5 GB tới 237 GB | | TTL | 0–3600 giây (mặc định 300) | | Cache key | dựa trên tham số request được chọn | | Mã hoá cache | tuỳ chọn |

Chọn TTL là đánh đổi giữa độ tươi và mức bảo vệ:

Giá tiền mã hoá thay đổi liên tục
    → TTL 5 giây vẫn cắt được phần lớn tải
    → 100.000 request/5 giây → chỉ 1 lời gọi backend

Ngay cả TTL rất ngắn cũng hiệu quả khi lưu lượng lớn — đây là điểm hay bị đánh giá thấp.

Ba cách bảo vệ backend qua API Gateway: | Cách | Chống | |---|---| | Throttling | quá tải do khối lượng | | Caching | request lặp lại | | WAF | request độc hại, bot, tấn công tầng 7 |

Với sàn giao dịch tiền mã hoá, WAF cũng đáng bật: rate-based rule chặn được bot thu thập dữ liệu giá, và managed rule chặn các mẫu tấn công phổ biến.

Ba lưu ý về caching: | Lưu ý | Chi tiết | |---|---| | Tính phí theo GIỜ, không theo lượt dùng | cache 6,1 GB chạy 24/7 tốn đáng kể | | Chỉ cache phương thức GET | POST, PUT không cache | | Cần cơ chế vô hiệu hoá cache | header Cache-Control: max-age=0 với quyền phù hợp |

Và một điểm về mã phản hồi: 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 — nên tài liệu API nên nêu rõ điều này, nếu không client sẽ thử lại ngay lập tức và làm tình hình tệ hơn.

Đáp án

B — Dùng AWS Artifact để xem các báo cáo bảo mật và những tài liệu tuân thủ khác của AWS.

Vì sao đúng

Đề yêu cầu báo cáo về mọi tài liệu liên quan tới tuân thủ cho tài khoản — và AWS Artifact là cổng tài liệu tuân thủ chính thức và duy nhất của AWS.

AWS Artifact cung cấp gì:

Cổng tự phục vụ trong AWS Console
    → tải về báo cáo kiểm toán do BÊN THỨ BA thực hiện trên AWS
    → xem và chấp nhận các thoả thuận pháp lý

Điểm quan trọng cần hiểu rõ về phạm vi:

AWS Artifact chứng minh: HẠ TẦNG CỦA AWS đạt các chuẩn nào
                          → phần "an ninh CỦA đám mây"

AWS Artifact KHÔNG nói:   ứng dụng CỦA BẠN có tuân thủ không
                          → phần "an ninh TRONG đám mây" là của bạn

Đây chính là mô hình trách nhiệm chung — và với đội kiểm toán, báo cáo Artifact là bằng chứng cho nửa dưới của mô hình.

Truy cập rất đơn giản: Console → AWS Artifact → chọn báo cáo → tải PDF. Miễn phí, có sẵn cho mọi tài khoản.

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

• D. Xem mọi báo cáo tuân thủ bảo mật của AWS từ AWS Security Hub — đây là phương án gần nhất và Security Hub có liên quan tới tuân thủ, nhưng nó làm việc khác: nó đánh giá tài nguyên CỦA BẠN theo các chuẩn (CIS, PCI DSS, AWS Foundational). Nó không cung cấp báo cáo kiểm toán về hạ tầng AWS mà đội kiểm toán cần.
• A. Chạy Amazon Inspector để tải về mọi thông tin tuân thủ của AWS — sai chức năng: Inspector quét lỗ hổng phần mềm (CVE) trên EC2, ECR và Lambda. Nó không có tài liệu tuân thủ nào.
• C. Chạy Amazon Macie để xem báo cáo SOC, PCI và các báo cáo tuân thủ khác từ AWS Certificate Manager (ACM) — nhầm hai dịch vụ và cả nguồn tài liệu: Macie phát hiện dữ liệu nhạy cảm trong S3, còn ACM quản lý chứng chỉ TLS. Không cái nào chứa báo cáo tuân thủ.

Ghi nhớ

Ba dịch vụ liên quan tới tuân thủ — phân biệt phạm vi: | Dịch vụ | Trả lời | |---|---| | AWS Artifact | "HẠ TẦNG AWS đạt chuẩn nào?" — tài liệu của AWS | | AWS Config | "Tài nguyên CỦA TÔI có cấu hình đúng chuẩn không?" | | AWS Security Hub | "Tổng quan tuân thủ của TÔI theo CIS, PCI DSS..." | | AWS Audit Manager | thu thập bằng chứng tự động cho một cuộc kiểm toán |

Dòng cuối đáng biết thêm: AWS Audit Manager tự động thu thập bằng chứng từ CloudTrail, Config, Security Hub và ánh xạ chúng vào khung kiểm soát (SOC 2, PCI DSS, HIPAA, GDPR). Nó là công cụ cho cuộc kiểm toán về phía bạn, bổ sung cho Artifact vốn nói về phía AWS.

Mô hình trách nhiệm chung — nền tảng của câu hỏi này:

AWS chịu trách nhiệm:  AN NINH CỦA ĐÁM MÂY
    → trung tâm dữ liệu, phần cứng, ảo hoá, mạng vật lý
    → BẰNG CHỨNG: báo cáo trong AWS Artifact

Bạn chịu trách nhiệm:  AN NINH TRONG ĐÁM MÂY
    → dữ liệu, mã hoá, IAM, cấu hình mạng, hệ điều hành khách
    → BẰNG CHỨNG: Config, Security Hub, Audit Manager, CloudTrail

Các chuẩn quan trọng có trong Artifact: | Chuẩn | Nội dung | |---|---| | SOC 1 | kiểm soát ảnh hưởng tới báo cáo tài chính | | SOC 2 | bảo mật, tính khả dụng, toàn vẹn, bảo mật riêng tư | | SOC 3 | bản tóm tắt công khai của SOC 2 | | PCI DSS AOC | tuân thủ ngành thẻ thanh toán | | ISO 27001 | hệ thống quản lý an toàn thông tin |

Lưu ý về SOC 1 và SOC 2: chúng được xếp là tài liệu mật, nên tải về cần chấp nhận NDA trong Artifact. SOC 3 thì công khai và chia sẻ tự do được.

Thoả thuận BAA cho HIPAA cũng nằm trong Artifact — tổ chức y tế bắt buộc phải chấp nhận nó trước khi xử lý dữ liệu sức khoẻ được bảo vệ trên AWS. Đây là bước dễ bị bỏ sót trong dự án y tế.

Ba việc đội kiểm toán thường cần, và lấy ở đâu: | Nhu cầu | Nguồn | |---|---| | "AWS có được chứng nhận không?" | AWS Artifact ← câu này | | "Tài nguyên của chúng ta có tuân thủ không?" | Config + Security Hub | | "Ai đã làm gì, khi nào?" | CloudTrail | | "Thu thập bằng chứng cho khung kiểm soát X" | Audit Manager |

Và một lưu ý về quyền: truy cập AWS Artifact được kiểm soát bằng IAM (artifact:Get, artifact:DownloadAgreement). Với tổ chức lớn, nên cấp quyền này cho đội tuân thủ và pháp chế thay vì để mọi quản trị viên tải tài liệu mật — nhất là khi việc tải về kèm theo ràng buộc NDA.