Lộ trình học Amazon API Gateway
Tuần 1: Nền tảng REST API và ra quyết định kiến trúc (Ngày 1-5)
Ngày 1
Sáng: Vai trò của API Gateway trong kiến trúc serverless; vòng đời một request (client → resource policy → authorizer → validation → integration → mapping → backend → response).
Chiều: So sánh REST API/HTTP API/WebSocket API bằng khung ra quyết định thay vì học thuộc bảng tính năng:
Cần usage plan/API key cho bên thứ ba, cache tích hợp sẵn, hoặc mapping template phức tạp → REST API.
Không cần các thứ trên → mặc định chọn HTTP API (rẻ hơn và độ trễ thấp hơn REST API ở cùng khối lượng traffic theo công bố của AWS).
Cần giao tiếp hai chiều thời gian thực (chat, dashboard live, streaming AI/LLM) → WebSocket API.
Lưu ý production: đừng chọn REST API "cho chắc" - chênh lệch chi phí và độ trễ là thật ở quy mô lớn; chỉ chọn REST API khi có lý do kỹ thuật cụ thể.
Bài tập:
Tạo tài khoản AWS, làm quen giao diện quản lý API Gateway.
Với 3 ứng dụng thực tế tự chọn (app di động, dashboard nội bộ, hệ thống IoT), áp dụng khung quyết định ở trên để chọn loại API Gateway phù hợp và giải thích bằng tiêu chí, không chỉ bằng cảm tính.
Vẽ sơ đồ vòng đời một request đi qua API Gateway, đánh dấu rõ điểm nào có thể chặn request (resource policy, authorizer, validation) trước khi tới backend.
Đọc tài liệu chính thức "What is Amazon API Gateway?" và ghi lại giới hạn hiện hành (payload size, integration timeout) - không dùng số liệu từ tài liệu cũ vì các giới hạn này có thể đã thay đổi.
Ngày 2
Sáng: Tạo REST API đầu tiên; phân biệt Lambda proxy integration (API Gateway chuyển nguyên request cho Lambda, Lambda tự trả đúng format
{statusCode, headers, body}) và non-proxy integration (transform bằng mapping template VTL ở tầng Gateway).Chiều: Request validation ở tầng Gateway: định nghĩa JSON Schema model, bật request validator (body/query/header) để chặn request sai trước khi chạm Lambda - kỹ thuật giảm invocation lãng phí và giảm bề mặt tấn công mà nhiều khóa học bỏ qua.
Lưu ý production: mặc định dùng proxy integration; chỉ dùng non-proxy khi cần tách hợp đồng API khỏi logic backend (nhiều team dùng chung backend nhưng cần hình dạng API khác nhau) hoặc tích hợp trực tiếp DynamoDB/S3 không qua Lambda.
Bài tập:
Hoàn thành "Hello World API" bằng Lambda proxy integration, tùy biến response.
Tạo cùng một API bằng non-proxy integration với mapping template, so sánh độ khó debug giữa hai cách.
Thêm JSON Schema model cho request body của một endpoint POST, bật request validator, thử gửi request sai định dạng và xác nhận bị chặn ở Gateway (400) trước khi Lambda chạy - kiểm tra log Lambda để chứng minh Lambda không hề được gọi.
Ghi chú lại: trường hợp nào nên chọn proxy, trường hợp nào nên chọn non-proxy, dựa trên bài tập vừa làm chứ không phải lý thuyết suông.
Ngày 3
Sáng: Tổ chức resource/method theo chuẩn RESTful cho API nhiều tài nguyên lồng nhau (
/products,/products/{id},/products/{id}/reviews).Chiều: Xử lý lỗi - phân biệt 3 tầng: (1) Gateway response (lỗi trước integration: 403 resource policy, 429 throttle, 400 validation - sửa bằng Gateway Responses, không sửa được bằng code); (2) integration response mapping theo
selectionPattern; (3) lỗi runtime trong Lambda nên trả structured error, tránh lộ stack trace ra client.Bẫy thường gặp: để lộ stack trace nguyên bản qua integration response mặc định - luôn map lỗi qua
selectionPatternthay vì để nguyên.Bài tập:
Tạo REST API quản lý sản phẩm (CRUD) với resource lồng nhau, dùng proxy integration.
Tạo non-proxy integration cho endpoint tìm kiếm sản phẩm, xử lý logic tìm theo tên/danh mục bằng mapping template.
Tùy biến 3 loại Gateway Response (403, 429, 400) với message thân thiện, không lộ chi tiết nội bộ.
Viết Lambda trả structured error
{errorType, errorMessage}và cấu hìnhselectionPatternmap sang đúng mã HTTP.Viết ghi chú ngắn: điểm khác nhau giữa 3 tầng lỗi, khi nào sửa ở đâu.
Ngày 4
Sáng: Triển khai API: stage, deployment, custom domain name, base path mapping. Phân biệt rõ deployment (snapshot cấu hình) và stage (một deployment gắn với địa chỉ cụ thể, có stage variable riêng để trỏ backend khác nhau theo môi trường).
Chiều: Custom domain - cân nhắc dual-stack IPv6 (API Gateway hiện hỗ trợ IPv6 trên mọi loại endpoint, custom domain, và API quản trị, ở cả region thương mại lẫn GovCloud) thay vì mặc định chỉ IPv4 như cách làm cũ.
Bài tập:
Triển khai API sản phẩm lên 2 stage (dev, prod), mỗi stage có stage variable trỏ Lambda alias riêng.
Cấu hình custom domain cho stage prod, bật dual-stack IPv6 và kiểm tra API vẫn truy cập được qua cả IPv4 và IPv6.
Thiết lập CloudWatch Logs ghi request/response - chỉ bật "log full request/response" ở stage dev, tuyệt đối không bật ở prod trừ khi đã che dữ liệu nhạy cảm.
Tạo CloudWatch alarm cảnh báo khi tỷ lệ lỗi 5XX vượt ngưỡng trong 5 phút (không dùng số lỗi tuyệt đối, vì traffic thấp sẽ khiến alarm vô nghĩa).
Ngày 5
Sáng: Bảo mật cơ bản: HTTPS bắt buộc qua ACM, các lớp policy: IAM policy (caller có quyền
execute-api:Invokekhông), resource policy (nguồn nào được gọi API), và sự khác biệt giữa hai lớp này.Chiều: Tích hợp trực tiếp API Gateway với S3/DynamoDB (không qua Lambda) để giảm cold start và chi phí invocation cho thao tác CRUD đơn giản - đánh đổi là mất khả năng validate/transform phức tạp phía code.
Bẫy thường gặp: sửa resource policy chặn theo IP nhưng vẫn bị 403/traffic lạ vì quên rằng CloudFront (nếu có ở phía trước) sẽ đổi IP nguồn - cần dùng header viewer address hoặc chuyển logic chặn IP lên WAF.
Bài tập:
Cấu hình HTTPS bằng ACM cho custom domain.
Tạo resource policy chỉ cho phép một dải IP cụ thể gọi API, kiểm tra bằng cách gọi từ IP khác để xác nhận bị chặn.
Tạo API Gateway proxy trực tiếp tới S3 bucket (upload/download file) không qua Lambda.
So sánh độ trễ giữa integration trực tiếp S3 và integration qua Lambda proxy cho cùng thao tác download.
Viết ngắn gọn: khi nào chấp nhận đánh đổi "mất khả năng validate phức tạp" để đổi lấy độ trễ thấp hơn.
Tuần 2: Bảo mật và HTTP API (Ngày 6-10)
Ngày 6
Sáng: Các loại authorizer và khi nào dùng loại nào: IAM/SigV4 (caller là dịch vụ AWS nội bộ đã có credential), Cognito User Pool authorizer (end-user, không cần viết code xác thực), Lambda authorizer token-based/request-based (logic uỷ quyền tuỳ biến).
Chiều: Cấu hình cache cho Lambda authorizer theo TTL và
identitySource- bẫy bảo mật nghiêm trọng nếuidentitySourcekhông đủ thành phần: hai user khác nhau có thể vô tình dùng chung kết quả cache của nhau.Bài tập:
Tạo Lambda authorizer kiểm tra API key + chữ ký từ request header.
Bật cache cho authorizer, cố tình cấu hình
identitySourcethiếu (ví dụ chỉ dựa vào IP thay vì token) để tận mắt thấy hiện tượng rò rỉ cache giữa 2 "user" giả lập khác nhau - sau đó sửa lại đúng.So sánh chi phí/độ phức tạp giữa dùng Lambda authorizer tự viết và dùng Cognito User Pool authorizer dựng sẵn cho cùng một use case end-user thông thường.
Ghi chú: TTL cache bao nhiêu là hợp lý nếu hệ thống cần revoke token gần thời gian thực.
Ngày 7
Sáng: VPC endpoint policy - tầng policy thứ 3 dễ bị bỏ quên (kiểm soát traffic đi qua VPC endpoint được phép gọi API nào). Kết hợp với IAM policy và resource policy tạo thành 3 tầng cần kiểm tra đủ cả 3 khi debug lỗi 403 khó hiểu.
Chiều: Tối ưu hiệu suất: caching (REST API - lưu ý tính phí theo giờ dựa trên kích thước cache đã cấp phát kể cả khi không có traffic, nên tắt ở stage dev/test), throttling theo method riêng cho endpoint nặng (không dùng chung ngưỡng mặc định toàn stage/account).
Bẫy thường gặp: một endpoint bị lạm dụng (ví dụ export dữ liệu) dùng chung throttle với toàn API sẽ kéo sập cả những endpoint khác - phải set throttle riêng theo method.
Bài tập:
Dựng một API private truy cập qua VPC endpoint, cấu hình đủ 3 tầng policy (IAM, resource, VPC endpoint policy), rồi cố tình xoá từng tầng một để quan sát lỗi 403 xuất hiện/biến mất tương ứng.
Bật cache cho API sản phẩm, đo chi phí ước tính nếu để cache chạy 24/7 ở stage dev không có traffic.
Set throttle riêng cho endpoint search/export cao hơn nhiều so với endpoint CRUD thông thường, kiểm chứng bằng cách gọi dồn dập.
Benchmark hiệu suất trước/sau khi bật cache.
Ngày 8
Sáng: Giới thiệu HTTP API: kiến trúc tối ưu cho serverless/HTTP backend, không có usage plan/API key, không có mapping template VTL đầy đủ như REST API.
Chiều: Tạo HTTP API bằng giao diện quản lý và từ OpenAPI; tích hợp Lambda và HTTP proxy.
Bài tập:
Tạo HTTP API đơn giản tích hợp Lambda.
Chuyển định nghĩa REST API (Ngày 3) sang OpenAPI, tạo HTTP API từ file đó, ghi chú phần nào (mapping template phức tạp) không chuyển được nguyên vẹn.
So sánh chi phí và độ trễ thực đo giữa HTTP API và REST API tương đương ở cùng khối lượng request.
Xác định: nếu cần usage plan/API key cho đối tác thứ ba mà vẫn muốn dùng HTTP API, giải pháp thực tế là gì (gợi ý: thêm lớp CloudFront/Lambda@Edge, hoặc tách riêng nhóm endpoint đối tác sang REST API).
Ngày 9
Sáng: Bảo mật HTTP API - native OIDC/OAuth2 authorizer (tính năng mới): xử lý luôn phần redirect/token exchange chuẩn OAuth2 authorization code flow, giảm việc tự dựng Lambda xử lý callback so với trước đây. Phân biệt với JWT authorizer (chỉ verify JWT theo issuer/audience, không xử lý luồng OAuth2 đầy đủ).
Chiều: VPC Link v2 cho HTTP API - trỏ thẳng tới ALB/NLB/AWS Cloud Map (ví dụ ECS service) mà không cần tạo NLB trung gian như VPC Link v1 (REST API) từng yêu cầu - đơn giản hoá đáng kể kiến trúc private API.
Bẫy thường gặp: khi migrate từ Lambda authorizer tự viết sang OIDC/OAuth2 native, nếu logic uỷ quyền cũ đọc custom claim đặc thù mà cơ chế native không hỗ trợ, vẫn phải giữ lại Lambda authorizer riêng cho phần đó - không thể thay thế 100%.
Bài tập:
Cấu hình native OIDC/OAuth2 authorizer cho HTTP API, tích hợp với một identity provider chuẩn OIDC (ví dụ Auth0/Cognito).
So sánh lượng code cần viết giữa cách cũ (Lambda authorizer tự xử lý OAuth2) và cách mới (native).
Dựng VPC Link v2 kết nối HTTP API tới một ALB private, so sánh độ phức tạp cấu hình với VPC Link v1 đã học ở REST API.
Liệt kê trường hợp nào native OIDC/OAuth2 KHÔNG đủ, buộc phải quay lại Lambda authorizer.
Ngày 10
Sáng: Routing nâng cao trong HTTP API:
$defaultroute (bắt tất cả request không khớp - dễ che giấu lỗi cấu hình nếu không log rõ route nào đã match), greedy path variable{proxy+}(chuyển toàn bộ path cho backend tự route), path parameter thường{userId}(enforce cấu trúc rõ ràng, hỗ trợ tốt hơn cho OpenAPI tự sinh).Chiều: Tích hợp HTTP API với DynamoDB, EventBridge.
Bài tập:
Tạo HTTP API với route phức tạp
/users/{userId}/orders/{orderId}, so sánh với cách dùng{proxy+}cho cùng bài toán - nêu rõ khi nào chọn cách nào.Tích hợp trực tiếp HTTP API với DynamoDB tạo CRUD API không qua Lambda.
Dùng EventBridge kích hoạt Lambda khi có sự kiện từ HTTP API (ví dụ đơn hàng mới → gửi email xác nhận bất đồng bộ).
Log rõ route nào đã match cho mỗi request, kiểm tra
$defaultcó đang âm thầm bắt các request bị gõ sai path không (dấu hiệu lỗi client cần được thông báo rõ thay vì rơi vào fallback).
Tuần 3: WebSocket API và vận hành (Ngày 11-15)
Ngày 11
Sáng: Kiến trúc WebSocket API cho ứng dụng thời gian thực, so với HTTP polling.
Chiều: Vòng đời kết nối:
$connect→ lưuconnectionId(thường vào DynamoDB, có TTL) → route tuỳ biến/$default→$disconnect. Lưu ý:$disconnectkhông đảm bảo luôn được gọi (client rớt mạng đột ngột) - bắt buộc phải có cơ chế dọn rác định kỳ bằng TTL trên DynamoDB, không phụ thuộc hoàn toàn vào$disconnect.Bài tập:
Hoàn thành "WebSocket chat app" mẫu, tùy biến thêm tính năng.
Xây dựng WebSocket API theo dõi giá chứng khoán thời gian thực, lưu connectionId vào DynamoDB có TTL.
Cố tình ngắt kết nối đột ngột (tắt client không qua
$disconnect) và xác nhận cơ chế TTL dọn rác vẫn hoạt động đúng dù$disconnectkhông được gọi.Viết ngắn so sánh WebSocket API và HTTP polling: chi phí, độ trễ, độ phức tạp vận hành.
Ngày 12
Sáng: Gửi tin nhắn qua
@connectionsAPI (postToConnection) từ Lambda.Chiều: Broadcast ở quy mô lớn - gọi tuần tự từng connection từ một Lambda sẽ chậm/timeout khi có hàng chục nghìn connection đồng thời; cần fan-out qua SQS hoặc Step Functions Map để chia batch song song.
Bài tập:
Tạo Lambda gửi tin nhắn tới tất cả client đang kết nối.
Giả lập số lượng connection lớn (mock), đo thời gian nếu gửi tuần tự, sau đó refactor sang fan-out qua SQS và so sánh thời gian broadcast.
Xây dựng ứng dụng bảng trắng (whiteboard) cộng tác đơn giản dùng WebSocket API.
Xây dựng chat nhóm, xử lý trường hợp một connection gửi message dồn dập (throttle theo route).
Ngày 13
Sáng: Bảo mật WebSocket API: IAM authorizer, Lambda authorizer, Cognito authorizer - giới hạn số connection/IP để tránh bị lạm dụng làm kênh khuếch đại tấn công.
Chiều: Cập nhật quan trọng: AWS SAM giờ hỗ trợ đầy đủ WebSocket API (trước đây phải tự khai báo toàn bộ resource CloudFormation bên dưới, rất dễ thiếu IAM permission cho Lambda - SAM hiện tạo tự động, tương đương tính năng với REST/HTTP API gồm IAM/Lambda authorization, custom domain, RouteSettings, Models, StageVariables).
Bài tập:
Thêm IAM authorizer vào WebSocket API, kiểm soát truy cập theo vai trò.
Viết lại toàn bộ WebSocket API ở Ngày 11-12 bằng AWS SAM template thay vì CloudFormation thô, so sánh số dòng code và số lỗi IAM permission gặp phải giữa hai cách.
Set giới hạn throttle theo route và theo IAM/API key, thử tấn công giả lập (nhiều connection dồn dập) để kiểm chứng giới hạn có tác dụng.
Dùng X-Ray truy vết một request từ client qua Lambda và ngược lại trong WebSocket API.
Ngày 14
Sáng: Giám sát - phân biệt vai trò 3 công cụ: CloudWatch Metrics (số liệu tổng hợp: Count, Latency, IntegrationLatency, 4XX/5XXError, CacheHitCount - dùng cho alarm/dashboard xu hướng), CloudWatch Logs + Logs Insights (chi tiết từng request, dùng để truy vấn nguyên nhân cụ thể), X-Ray (trace toàn bộ đường đi một request qua nhiều service để tìm điểm nghẽn độ trễ - không phải để đếm lỗi tổng quan).
Chiều: Bộ alarm tối thiểu cho production: tỷ lệ lỗi 5XX vượt ngưỡng trong cửa sổ thời gian (không phải số tuyệt đối), p99 latency vượt SLA, số request bị throttle (429), số connection đồng thời gần chạm giới hạn (WebSocket).
Bài tập:
Xây hệ thống xử lý lỗi đầy đủ cho API sản phẩm (Gateway response + Lambda error handling + logging có cấu trúc).
Dùng CloudWatch Logs Insights tìm lỗi thường gặp và phân tích nguyên nhân gốc.
Dựng đủ 4 alarm tối thiểu nêu trên cho API sản phẩm.
Tạo dashboard CloudWatch tổng hợp gồm cả metric REST API và WebSocket API trên cùng một màn hình.
Ngày 15
Sáng: Kiểm thử API: thủ công (Postman), tự động (Newman, Jest), viết test case, tạo mock data.
Chiều: Phân tích chi phí - REST API tính theo triệu request + cache (tính theo giờ bất kể traffic nếu bật) + data transfer; HTTP API rẻ hơn đáng kể ở cùng khối lượng nhưng không có cache tích hợp (nếu cần cache phải tự dựng, chi phí đó không biến mất mà chuyển chỗ khác).
Bài tập:
Viết test case và kiểm thử tự động cho API sản phẩm bằng Newman hoặc Jest.
Ước tính chi phí hàng tháng cho API sản phẩm ở 3 kịch bản traffic (thấp/trung bình/cao), so sánh REST API vs HTTP API bằng số liệu thực từ bảng giá hiện hành (kiểm tra giá mới nhất, không dùng số cũ).
Xác định điểm hoà vốn traffic mà tại đó chi phí cache REST API (tính theo giờ) vượt qua lợi ích giảm tải backend.
Tuần 4: Triển khai, kiến trúc mạng, và microservices (Ngày 16-20)
Ngày 16
Sáng: Deployment/stage/canary - phân biệt rõ: deployment là snapshot cấu hình, stage là deployment gắn với địa chỉ cụ thể (có stage variable riêng), canary release là triển khai bản mới song song trên cùng một stage, định tuyến % traffic nhỏ sang bản mới (không phải cách để chạy môi trường dev/staging).
Chiều: WAF + Shield - phân vai: WAF chặn theo luật tầng ứng dụng (SQLi, XSS, rate-based, geo-blocking), Shield chống DDoS tầng mạng/transport (Standard miễn phí có sẵn, Advanced trả phí kèm hỗ trợ sự cố 24/7). Best practice: đặt CloudFront trước API Gateway kể cả cho API thuần để tận dụng WAF/Shield/cache biên hiệu quả hơn.
Bài tập:
Thực hiện canary deployment cho API sản phẩm, gắn CloudWatch Alarm để tự động phát hiện lỗi tăng - không chỉ chia traffic thủ công mà không có cơ chế phản ứng.
Cấu hình WAF chặn SQL injection và XSS cho API.
Đặt CloudFront trước API Gateway, cấu hình forward đúng header
Authorizationvà custom header API key (bẫy thường gặp: CloudFront mặc định không forward hết header, khiến authorizer luôn fail nếu quên cấu hình).Cấu hình mTLS: tạo truststore trên S3, bật mTLS trên custom domain, kiểm chứng client không có cert hợp lệ bị từ chối. Ghi chú quy trình rotate truststore không downtime (thêm CA mới trước, đợi client chuyển đổi, rồi mới gỡ CA cũ).
Ngày 17
Sáng: Ba khái niệm mạng dễ nhầm vì tên gần giống nhau nhưng phục vụ 3 hướng traffic khác nhau: Private API (API chỉ truy cập từ trong VPC qua VPC endpoint, không có endpoint public), VPC Link (để API Gateway gọi vào tài nguyên private trong VPC), VPC Endpoint/Interface endpoint cho execute-api (để tài nguyên trong VPC gọi ra API Gateway mà không cần NAT Gateway).
Chiều: IaC cho API Gateway: AWS SAM (tốt nhất cho kiến trúc serverless thuần, cú pháp gọn), Terraform (tốt khi đa cloud hoặc quản lý nhiều dịch vụ AWS ngoài serverless), CloudFormation thô (khi cần tính năng vừa ra mắt mà SAM/Terraform chưa map kịp).
Bài tập:
Tạo Private API và truy cập từ EC2 instance trong VPC.
Cấu hình VPC Link kết nối API Gateway với RDS/ALB trong VPC.
Tạo VPC Endpoint cho API Gateway, truy cập từ EC2 ở VPC khác, xác nhận không cần NAT Gateway.
Viết cùng một API bằng cả SAM và Terraform, so sánh độ dài code và tốc độ triển khai.
Ngày 18
Sáng: Tích hợp API Gateway với Route 53 (alias record + health check + failover routing đa vùng) và CloudFront (đặt trước API Gateway để giảm độ trễ toàn cầu qua edge location, không chỉ dùng cho static content).
Chiều: ELB (ALB/NLB) trước nhiều VPC Link/backend, dùng khi cần phân phối traffic tới nhiều nguồn hoặc kiến trúc hybrid (một phần backend on-prem qua Direct Connect).
Bài tập:
Cấu hình Route 53 định tuyến traffic tới API Gateway custom domain kèm health check.
Tạo distribution CloudFront cho API Gateway, cấu hình cache đúng theo route (không cache endpoint ghi dữ liệu).
Dùng ALB phân phối traffic tới nhiều VPC Link endpoint.
Thực hiện bài lab tích hợp đủ cả 3 (Route 53 + CloudFront + ELB) cho một API production giả lập.
Ngày 19
Sáng: Mẫu thiết kế microservices: API Gateway pattern (một gateway, route theo path prefix tới nhiều service), Backend for Frontend/BFF (mỗi loại client có tầng tổng hợp riêng, tối ưu payload theo client thay vì một API chung), Strangler pattern (route dần traffic từ hệ thống cũ sang service mới theo path, migrate không downtime).
Chiều: Tích hợp dịch vụ khác theo đúng bài toán: Step Functions (quy trình nhiều bước, cần retry/error handling per-step), EventBridge (kích hoạt sự kiện bất đồng bộ fan-out, không cần phản hồi đồng bộ), AppSync/GraphQL (client cần truy vấn linh hoạt nhiều nguồn, tránh over/under-fetching - là lựa chọn kiến trúc khác cho lớp API, không phải tính năng bổ trợ của API Gateway REST/HTTP).
Bài tập:
Thiết kế kiến trúc microservices đơn giản dùng API Gateway pattern.
Tích hợp API Gateway với Step Functions cho một quy trình nghiệp vụ nhiều bước (ví dụ xử lý đơn hàng: kiểm tra kho → thanh toán → gửi email).
Dùng EventBridge fan-out một sự kiện từ API Gateway tới nhiều consumer.
Viết ngắn: khi nào chọn AppSync thay vì API Gateway REST/HTTP cho lớp API của một sản phẩm mới.
Ngày 20
Sáng: Amazon API Gateway Portal (tính năng mới, thay thế cách tự dựng developer portal): tổ chức API thành "API products", tính năng "Try it" tương tác, chia sẻ đa tài khoản qua AWS RAM, kiểm soát truy cập bằng Cognito (MFA, password policy). Portal tôn trọng authorizer đã cấu hình trên API gốc, không bypass - chủ sở hữu API gốc vẫn giữ toàn quyền kiểm soát dù đã share qua RAM.
Chiều: Ôn tập tổng hợp toàn bộ 20 ngày; chạy qua checklist production-readiness cuối khóa.
Bài tập:
Tạo API Gateway Portal cho bộ API sản phẩm, publish một "API product", thử tính năng "Try it".
Chia sẻ portal đó cho một tài khoản AWS thứ hai qua AWS RAM, xác nhận quyền truy cập vẫn theo đúng authorizer gốc (không bị bypass).
Chạy qua Checklist production-readiness bên dưới cho toàn bộ API đã xây trong khóa học, đánh dấu mục nào còn thiếu và khắc phục.
Làm một bài thi thử tổng hợp (nếu đang ôn chứng chỉ liên quan, ví dụ AWS Certified Advanced Networking – Specialty, dành thêm 3-5 ngày ôn các dịch vụ mạng liên quan: Direct Connect, Transit Gateway, Route 53 routing policies).
Checklist production-readiness
[ ] Request validation bật ở Gateway, không chỉ trong code Lambda
[ ] Throttle riêng theo method cho endpoint nặng, không dùng chung ngưỡng mặc định
[ ] Log production không bật "log full request/response" trừ khi đã che dữ liệu nhạy cảm
[ ] Alarm dựa trên tỷ lệ lỗi + p99 latency + số throttle, không chỉ đếm lỗi tuyệt đối
[ ] Đã kiểm tra đủ 3 tầng policy (resource, IAM, VPC endpoint) khi debug lỗi 403
[ ] Lambda authorizer cache TTL và
identitySourceđủ để tránh rò rỉ cache giữa user[ ] Canary deployment có cơ chế rollback tự động, không chỉ chia traffic thủ công
[ ] Đã ước tính chi phí theo bảng giá hiện hành, đặc biệt cache REST API tính theo giờ bất kể traffic
[ ] Custom domain đã cân nhắc dual-stack IPv6
[ ] Nếu có đối tác thứ ba dùng API: đã cân nhắc API Gateway Portal thay vì tự dựng developer portal
[ ] CloudFront phía trước đã forward đúng header cần thiết cho authorizer (Authorization, API key header)
[ ] WebSocket: có cơ chế dọn rác connection bằng TTL, không phụ thuộc hoàn toàn vào
$disconnect