Serverless – Lambda, DynamoDB, API Gateway, Cognito

1. Serverless là gì?

Serverless là một mô hình (paradigm) mới, trong đó lập trình viên không phải quản lý server nữa — họ chỉ deploy code, mà cụ thể hơn là deploy… function (hàm).

Ban đầu, serverless gần như đồng nghĩa với FaaS (Function as a Service). Serverless được AWS Lambda khai phá, nhưng ngày nay khái niệm này đã mở rộng ra mọi thứ được quản lý (managed): database, messaging, storage…

Những dịch vụ serverless trên AWS

Danh sách các dịch vụ được coi là serverless trong phạm vi khóa học:

AWS Lambda
DynamoDB
AWS Cognito
AWS API Gateway
Amazon S3
AWS SNS & SQS
AWS Kinesis Data Firehose
Aurora Serverless
Step Functions
Fargate

Một kiến trúc serverless điển hình ghép chúng lại như sau: S3 bucket phục vụ static content, API Gateway phơi ra REST API, Cognito lo phần đăng nhập của Users, Lambda chạy logic, và DynamoDB lưu dữ liệu.

2. Vì sao dùng AWS Lambda?

Cách nhanh nhất để hiểu Lambda là đặt nó cạnh EC2:

	Amazon EC2	AWS Lambda
Bản chất	Server ảo trên cloud	Virtual function — không có server nào để quản lý
Giới hạn	Bị giới hạn bởi RAM và CPU	Bị giới hạn bởi thời gian — chỉ chạy các tác vụ ngắn
Cách chạy	Chạy liên tục	Chạy theo yêu cầu (on-demand)
Scale	Scale nghĩa là phải can thiệp để thêm/bớt server	Scale tự động

Lợi ích của AWS Lambda

Giá dễ hiểu: trả tiền theo request và theo thời gian tính toán; free tier gồm 1.000.000 request và 400.000 GB-s thời gian tính toán.
Tích hợp với toàn bộ hệ dịch vụ AWS.
Tích hợp với nhiều ngôn ngữ lập trình.
Giám sát dễ dàng qua AWS CloudWatch.
Dễ tăng tài nguyên cho từng function — lên tới 10GB RAM. Và một điểm quan trọng: tăng RAM cũng đồng thời cải thiện CPU và network.

Ngôn ngữ được hỗ trợ

Node.js (JavaScript)
Python
Java
C# (.NET Core) / Powershell
Ruby
Custom Runtime API — do cộng đồng hỗ trợ, ví dụ Rust hoặc Golang.
Lambda Container Image — container image này phải implement Lambda Runtime API.

Các tích hợp chính

Các dịch vụ thường gắn với Lambda: API Gateway, Kinesis, DynamoDB, S3, CloudWatch Logs, SNS, SQS, Cognito, CloudFront, và CloudWatch Events / EventBridge.

Hai ví dụ kinh điển:

Tạo thumbnail serverless: có ảnh mới trong S3 → trigger một Lambda Function tạo thumbnail → push thumbnail mới trở lại S3, đồng thời push metadata (tên ảnh, kích thước ảnh, ngày tạo…) vào DynamoDB.
CRON job serverless: CloudWatch Events / EventBridge trigger một Lambda Function mỗi 1 giờ để thực thi một tác vụ.

Giá của Lambda

Lambda tính tiền theo hai chiều:

Theo số lần gọi (pay per calls): 1.000.000 request đầu tiên miễn phí, sau đó $0.20 / 1 triệu request (tức $0.0000002 mỗi request).
Theo thời gian chạy (pay per duration): tính theo bước 1 ms; miễn phí 400.000 GB-second mỗi tháng — tương đương 400.000 giây nếu function có 1GB RAM, hoặc 3.200.000 giây nếu function chỉ 128 MB RAM. Vượt mức đó thì $1.00 cho mỗi 600.000 GB-second.

Vì các con số này rất nhỏ, chạy Lambda thường rất rẻ — đó cũng là lý do Lambda phổ biến đến vậy.

3. Các giới hạn của Lambda cần nhớ

Các giới hạn dưới đây tính theo region, và chúng xuất hiện trong đề thi khá thường xuyên.

Nhóm	Giới hạn
Execution — RAM	128 MB – 10GB, bước tăng 1 MB
Execution — thời gian chạy tối đa	900 giây (15 phút)
Execution — environment variables	4 KB
Execution — dung lượng đĩa trong “function container” (`/tmp`)	512 MB đến 10GB
Execution — concurrency executions	1000 (có thể xin tăng)
Deployment — kích thước gói deploy (`.zip` đã nén)	50 MB
Deployment — kích thước khi giải nén (code + dependencies)	250 MB
Deployment — environment variables	4 KB

Ghi chú thêm: bạn có thể dùng thư mục /tmp để tải thêm file lúc khởi động (startup), đây là cách lách giới hạn kích thước gói deploy.

4. Concurrency và Throttling

Concurrency limit của Lambda là tối đa 1000 lần thực thi đồng thời. Bạn có thể đặt “reserved concurrency” ở mức từng function — đây thực chất là một giới hạn (limit) riêng cho function đó.

Mỗi lần gọi vượt quá concurrency limit sẽ bị “Throttle” (chặn nhịp). Hành vi throttle khác nhau tùy kiểu gọi:

Gọi đồng bộ (synchronous invocation) → trả về ThrottleError – 429.
Gọi bất đồng bộ (asynchronous invocation) → tự động retry, rồi cuối cùng đẩy vào DLQ (Dead Letter Queue).

Nếu cần giới hạn cao hơn, bạn phải mở support ticket.

Vấn đề concurrency khi không reserve

Nếu bạn không reserve (không giới hạn) concurrency cho từng function thì có thể xảy ra tình huống sau: một function nhận traffic từ Application Load Balancer với rất nhiều người dùng chiếm hết 1000 lần thực thi đồng thời, làm cho các function khác — ví dụ function sau API Gateway hoặc function được gọi từ SDK / CLI với rất ít người dùng — bị THROTTLE! oan, dù bản thân chúng gần như không có tải.

Concurrency với gọi bất đồng bộ

Khi một S3 bucket liên tục phát new file event mà function không còn đủ concurrency để xử lý hết, các request thêm sẽ bị throttle. Lúc đó:

Với lỗi throttling (429) và lỗi hệ thống (500-series), Lambda đưa event trở lại queue và thử chạy lại function trong tối đa 6 giờ.
Khoảng thời gian giữa các lần retry tăng theo hàm mũ, từ 1 giây sau lần thử đầu tiên cho tới tối đa 5 phút.

5. Cold Start, Provisioned Concurrency và SnapStart

Cold Start (khởi động lạnh) xảy ra khi Lambda dựng một instance mới: code được nạp và phần code nằm ngoài handler được chạy (bước init). Nếu phần init lớn (code nhiều, nhiều dependency, SDK…), bước này có thể mất khá nhiều thời gian. Kết quả: request đầu tiên được phục vụ bởi instance mới có độ trễ cao hơn các request sau.

Provisioned Concurrency là cách xử lý: concurrency được cấp phát trước khi function được gọi, nên cold start không bao giờ xảy ra và mọi lần gọi đều có độ trễ thấp. Application Auto Scaling có thể quản lý phần concurrency này (theo lịch hoặc theo target utilization).

Ghi chú từ slide: cold start trong VPC đã được giảm rất đáng kể từ tháng 10 và 11 năm 2019.

Lambda SnapStart

Lambda SnapStart cải thiện hiệu năng của function lên tới 10 lần, không tốn thêm phí, dành cho Java, Python & .NET.

Khi bật, function được gọi từ một trạng thái đã khởi tạo trước (pre-initialized) — không phải init lại từ đầu.
Khi bạn publish một version mới: Lambda init function, chụp snapshot trạng thái memory và disk của function đã init, và cache snapshot đó để truy cập với độ trễ thấp.

So sánh vòng đời gọi function:

	SnapStart disabled	SnapStart enabled
Các pha sau khi invoke	Init → Invoke → Shutdown	Invoke → Shutdown (function đã được pre-initialized)

6. Customization At The Edge

Rất nhiều ứng dụng hiện đại chạy một phần logic ngay tại edge. Edge Function là đoạn code bạn viết và gắn vào CloudFront distribution, chạy gần người dùng để giảm độ trễ tối đa.

CloudFront cung cấp hai loại: CloudFront Functions và Lambda@Edge. Điểm chung của cả hai:

Bạn không phải quản lý server nào, và code được deploy toàn cầu.
Use case: tùy biến nội dung CDN.
Chỉ trả tiền cho những gì bạn dùng, và hoàn toàn serverless.

Các use case chung mà slide liệt kê: bảo mật & quyền riêng tư website, ứng dụng web động tại edge, SEO, định tuyến thông minh giữa nhiều origin và data center, chống bot tại edge, biến đổi ảnh theo thời gian thực, A/B testing, xác thực & phân quyền người dùng, ưu tiên người dùng (user prioritization), và theo dõi & phân tích người dùng.

CloudFront Functions

Các function nhẹ, viết bằng JavaScript.
Dành cho các tùy biến CDN quy mô lớn, nhạy cảm với độ trễ.
Thời gian khởi động dưới 1 ms, xử lý hàng triệu request/giây.
Dùng để thay đổi Viewer request và response: Viewer Request (sau khi CloudFront nhận request từ viewer) và Viewer Response (trước khi CloudFront trả response về cho viewer).
Là tính năng gốc của CloudFront — bạn quản lý code hoàn toàn bên trong CloudFront.

Lambda@Edge

Là Lambda function viết bằng NodeJS hoặc Python.
Scale tới hàng nghìn request/giây.
Can thiệp được vào cả bốn điểm: Viewer Request, Origin Request (trước khi CloudFront chuyển request tới origin), Origin Response (sau khi CloudFront nhận response từ origin), Viewer Response.
Bạn viết function ở một region duy nhất (us-east-1), rồi CloudFront tự nhân bản tới các location của nó.

Bảng so sánh

Tiêu chí	CloudFront Functions	Lambda@Edge
Runtime	JavaScript	Node.js, Python
Số request	Hàng triệu request/giây	Hàng nghìn request/giây
CloudFront Triggers	Viewer Request/Response	Viewer Request/Response, Origin Request/Response
Thời gian thực thi tối đa	< 1 ms	5 – 10 giây
Bộ nhớ tối đa	2 MB	128 MB đến 10 GB
Kích thước package tối đa	10 KB	1 MB – 50 MB
Truy cập network, truy cập file system	Không	Có
Truy cập request body	Không	Có
Giá	Có free tier, giá bằng 1/6 Lambda@Edge	Không có free tier, tính theo request & duration

Use case tương ứng:

CloudFront Functions: chuẩn hóa cache key (biến đổi header, cookie, query string, URL để tạo cache key tối ưu), thao tác header (thêm/sửa/xóa HTTP header ở request hoặc response), URL rewrite hoặc redirect, xác thực & phân quyền request (tạo và kiểm tra token do người dùng sinh ra, ví dụ JWT, để cho phép/chặn request).
Lambda@Edge: cần thời gian thực thi dài hơn (vài ms), cần điều chỉnh CPU hoặc memory, code phụ thuộc thư viện bên thứ ba (ví dụ AWS SDK để gọi các dịch vụ AWS khác), cần truy cập network để dùng dịch vụ bên ngoài, hoặc cần truy cập file system / body của HTTP request.

7. Lambda và networking

Lambda mặc định nằm ngoài VPC của bạn

Mặc định, Lambda function được chạy bên ngoài VPC của bạn — trong một VPC do AWS sở hữu. Hệ quả: nó không truy cập được các tài nguyên trong VPC của bạn (RDS, ElastiCache, internal ELB…). Nó truy cập được public www bình thường, nhưng một Private RDS trong VPC của bạn thì không.

Lambda trong VPC

Muốn Lambda nói chuyện được với tài nguyên riêng, bạn phải đưa nó vào VPC:

Phải khai báo VPC ID, các Subnet, và các Security Group.
Lambda sẽ tạo một ENI (Elastic Network Interface) trong các subnet đó.

Khi đó, Lambda Function (với Lambda Security group của nó) kết nối qua ENI tới Amazon RDS nằm trong VPC (với RDS Security group riêng) — hai security group ở hai đầu đường kết nối.

Lambda với RDS Proxy

Nếu Lambda function truy cập trực tiếp vào database, chúng có thể mở quá nhiều connection khi tải cao. RDS Proxy giải quyết chuyện đó:

Cải thiện khả năng scale bằng cách pooling và chia sẻ các connection tới DB.
Cải thiện tính sẵn sàng — giảm 66% thời gian failover và giữ nguyên các connection.
Cải thiện bảo mật — bắt buộc xác thực bằng IAM và lưu credential trong Secrets Manager.

Gọi Lambda từ RDS & Aurora

Chiều ngược lại cũng làm được: gọi Lambda function từ bên trong DB instance, cho phép bạn xử lý các data event ngay trong database.

Được hỗ trợ cho RDS for PostgreSQL và Aurora MySQL.
Phải cho phép outbound traffic từ DB instance tới Lambda function (qua Public, NAT GW, hoặc VPC Endpoints).
DB instance phải có quyền cần thiết để gọi Lambda function — gồm Lambda Resource-based Policy và IAM Policy.

Ví dụ trong slide: người dùng register (một câu INSERT) vào RDS DB Instance → DB invoke một Lambda function → function dùng Amazon SES để gửi email.

RDS Event Notifications

RDS Event Notifications là các thông báo về bản thân DB instance (được tạo, bị dừng, được start…). Điểm quan trọng: bạn không nhận được thông tin gì về dữ liệu bên trong.

Đăng ký theo các event category: DB instance, DB snapshot, DB Parameter Group, DB Security Group, RDS Proxy, Custom Engine Version.
Event ở mức gần thời gian thực (tối đa 5 phút).
Gửi thông báo tới SNS, hoặc đăng ký event thông qua EventBridge (từ đó đi tiếp tới Lambda function, SQS Queue…).

8. Amazon DynamoDB

Amazon DynamoDB là database được quản lý hoàn toàn, tính sẵn sàng cao nhờ nhân bản trên nhiều AZ. Đây là database NoSQL — không phải database quan hệ — nhưng vẫn hỗ trợ transaction.

Scale được tới các workload rất lớn, là database phân tán.
Hàng triệu request mỗi giây, hàng nghìn tỷ dòng, hàng trăm TB lưu trữ.
Hiệu năng nhanh và ổn định — độ trễ ở mức single-digit millisecond.
Tích hợp IAM cho bảo mật, phân quyền và quản trị.
Chi phí thấp và có khả năng auto-scaling.
Không cần bảo trì hay patch, luôn sẵn sàng.
Có hai table class: Standard và Infrequent Access (IA).

Những khái niệm cơ bản

DynamoDB gồm các Table.
Mỗi table có một Primary Key — phải quyết định ngay lúc tạo table.
Mỗi table có thể chứa số lượng item (= dòng) không giới hạn.
Mỗi item có các attribute — có thể thêm dần theo thời gian, và có thể null.
Kích thước tối đa của một item là 400KB.
Các kiểu dữ liệu được hỗ trợ:
- Scalar Types — String, Number, Binary, Boolean, Null
- Document Types — List, Map
- Set Types — String Set, Number Set, Binary Set

Nhờ vậy, trong DynamoDB bạn có thể tiến hóa schema rất nhanh.

Ví dụ một table có Primary Key gồm Partition Key là User_ID và Sort Key là Game_ID, cùng các attribute Score và Result:

User_ID      Game_ID   Score   Result
7791a3d6-…   4421      92      Win
873e0634-…   4521      77      Win
873e0634-…   1894      14      Lose

Read/Write Capacity Modes

Capacity mode quyết định cách bạn quản lý throughput đọc/ghi của table.

Mode	Cách hoạt động
Provisioned Mode (mặc định)	Bạn khai báo số read/write mỗi giây; phải lên kế hoạch capacity trước; trả tiền cho RCU (Read Capacity Units) và WCU (Write Capacity Units) đã cấp phát; có thể bật thêm auto-scaling cho RCU & WCU
On-Demand Mode	Read/write tự động scale lên/xuống theo workload; không cần capacity planning; trả tiền theo mức dùng thực tế nhưng đắt hơn; rất phù hợp cho workload khó dự đoán, có spike tăng vọt đột ngột

DynamoDB Accelerator (DAX)

DAX là cache in-memory được quản lý hoàn toàn, tính sẵn sàng cao, và liền mạch (seamless) cho DynamoDB.

Giúp giải quyết tắc nghẽn khi đọc (read congestion) bằng cách cache.
Độ trễ ở mức microsecond cho dữ liệu đã được cache.
Không cần sửa logic ứng dụng — tương thích với các API DynamoDB hiện có.
TTL của cache mặc định là 5 phút.

Về kiến trúc: Application → DAX Cluster (gồm nhiều node) → các DynamoDB Table.

Stream Processing

DynamoDB Streams là một dòng (stream) có thứ tự các thay đổi ở mức item (create/update/delete) trong một table. Use case:

Phản ứng với thay đổi theo thời gian thực (ví dụ gửi email chào mừng người dùng mới).
Phân tích usage theo thời gian thực.
Insert vào các table dẫn xuất (derivative tables).
Triển khai cross-region replication.
Gọi AWS Lambda khi table DynamoDB có thay đổi.

Có hai lựa chọn stream, và đây là bảng so sánh phải nhớ:

	DynamoDB Streams	Kinesis Data Streams (mới hơn)
Thời gian lưu	24 giờ	1 năm
Số consumer	Giới hạn	Nhiều
Cách xử lý	AWS Lambda Triggers, hoặc DynamoDB Stream Kinesis adapter	AWS Lambda, Kinesis Data Analytics, Kinesis Data Firehose, AWS Glue Streaming ETL…

Kiến trúc tổng: thao tác create/update/delete trên Table → DynamoDB Streams (đi tiếp qua DynamoDB KCL Adapter hoặc Lambda) hoặc Kinesis Data Streams → tầng xử lý (Processing Layer) → nhiều đích khác nhau: Amazon SNS (messaging, notifications), DDB Table (filtering, transforming), Kinesis Data Firehose → Amazon Redshift (analytics), Amazon S3 (archiving), Amazon OpenSearch (indexing).

DynamoDB Global Tables

Global Tables làm cho một table DynamoDB truy cập được với độ trễ thấp ở nhiều region.

Nhân bản kiểu Active-Active.
Ứng dụng có thể ĐỌC và GHI vào table ở bất kỳ region nào.
Điều kiện tiên quyết: phải bật DynamoDB Streams.

Ví dụ: một GLOBAL TABLE có bản ở US-EAST-1 và AP-SOUTHEAST-2, nhân bản hai chiều (two-way replication).

Time To Live (TTL)

TTL tự động xóa item sau một mốc thời gian hết hạn (expiry timestamp). Use case: giảm dữ liệu lưu trữ bằng cách chỉ giữ item còn hiệu lực, tuân thủ nghĩa vụ pháp lý (regulatory obligations), và xử lý web session.

Cách hoạt động: table có một attribute chứa timestamp dạng epoch (ví dụ ExpTime (TTL) = 1631274971); một Expiration Process quét và đánh dấu hết hạn các item có mốc thời gian đã qua thời điểm hiện tại, sau đó một Deletion Process quét và xóa chúng.

Backup cho disaster recovery

Kiểu backup	Đặc điểm
Continuous backups dùng point-in-time recovery (PITR)	Bật tùy chọn cho 35 ngày gần nhất; khôi phục về bất kỳ thời điểm trong khoảng backup; quá trình khôi phục tạo ra một table mới
On-demand backups	Full backup cho lưu trữ lâu dài, giữ tới khi bạn xóa tường minh; không ảnh hưởng hiệu năng hay độ trễ; có thể cấu hình và quản lý trong AWS Backup (cho phép copy cross-region); quá trình khôi phục cũng tạo ra một table mới

Tích hợp với Amazon S3

Export sang S3 (phải bật PITR):

Hoạt động cho bất kỳ thời điểm nào trong 35 ngày gần nhất.
Không ảnh hưởng read capacity của table.
Dùng để phân tích dữ liệu trên DynamoDB, giữ snapshot cho mục đích audit, hoặc làm ETL trên dữ liệu S3 trước khi import trở lại DynamoDB.
Export ở định dạng DynamoDB JSON hoặc ION.

Import từ S3:

Import định dạng CSV, DynamoDB JSON hoặc ION.
Không tiêu tốn write capacity nào.
Tạo ra một table mới.
Lỗi import được ghi vào CloudWatch Logs.

Luồng phân tích điển hình: DynamoDB export → S3 → Athena query.

9. AWS API Gateway

Ví dụ cơ bản nhất của một Serverless API: Client gọi REST API tới API Gateway, API Gateway PROXY REQUESTS tới Lambda, và Lambda thực hiện các thao tác CRUD trên DynamoDB.

Ghép AWS Lambda + API Gateway thì không còn hạ tầng nào phải quản lý. Các tính năng của API Gateway:

Hỗ trợ giao thức WebSocket.
Quản lý phiên bản API (v1, v2…).
Quản lý nhiều môi trường (dev, test, prod…).
Xử lý bảo mật (Authentication và Authorization).
Tạo API key, xử lý request throttling.
Import Swagger / Open API để định nghĩa API nhanh.
Biến đổi và kiểm tra (validate) request và response.
Sinh SDK và đặc tả API.
Cache response của API.

Các kiểu tích hợp

Lambda Function — gọi Lambda function; đây là cách dễ nhất để phơi ra một REST API chạy trên AWS Lambda.
HTTP — phơi ra các HTTP endpoint ở backend, ví dụ một HTTP API nội bộ on-premises, hoặc một Application Load Balancer. Vì sao? Để thêm rate limiting, caching, xác thực người dùng, API key…
AWS Service — phơi bất kỳ AWS API nào qua API Gateway, ví dụ khởi động một AWS Step Function workflow, hoặc đẩy message vào SQS. Vì sao? Để thêm xác thực, deploy công khai, kiểm soát rate…

Ví dụ tích hợp AWS Service: Client requests → API Gateway → Kinesis Data Streams (send records) → Kinesis Data Firehose → Amazon S3 (lưu các file .json).

Các loại Endpoint

Loại	Đặc điểm
Edge-Optimized (mặc định)	Dành cho client toàn cầu; request được định tuyến qua các CloudFront Edge location (cải thiện độ trễ); bản thân API Gateway vẫn chỉ nằm ở một region
Regional	Dành cho client trong cùng region; có thể tự ghép với CloudFront để kiểm soát nhiều hơn về chiến lược cache và distribution
Private	Chỉ truy cập được từ VPC của bạn qua interface VPC endpoint (ENI); dùng resource policy để định nghĩa quyền truy cập

Bảo mật cho API Gateway

Xác thực người dùng qua:

IAM Roles — hữu ích cho ứng dụng nội bộ.
Cognito — danh tính cho người dùng bên ngoài, ví dụ người dùng mobile.
Custom Authorizer — logic tự viết của bạn.

Bảo mật HTTPS cho Custom Domain Name được làm thông qua tích hợp với AWS Certificate Manager (ACM), và đây là điểm rất hay bị hỏi:

Nếu dùng endpoint Edge-Optimized, certificate phải nằm ở us-east-1.
Nếu dùng endpoint Regional, certificate phải nằm cùng region với API Gateway.
Phải thiết lập CNAME hoặc A-alias record trong Route 53.

10. AWS Step Functions

AWS Step Functions cho phép bạn xây dựng workflow trực quan, serverless để điều phối (orchestrate) các Lambda function của mình.

Các tính năng: sequence (tuần tự), parallel (song song), conditions (điều kiện), timeouts, error handling…
Tích hợp được với EC2, ECS, server on-premises, API Gateway, SQS queue…
Có thể triển khai tính năng human approval (chờ con người phê duyệt).
Use case: order fulfillment (hoàn tất đơn hàng), data processing, web application, và bất kỳ workflow nào.

11. Amazon Cognito

Amazon Cognito cấp cho người dùng một danh tính (identity) để tương tác với web app hoặc mobile app của bạn. Nó có hai phần rất khác nhau:

Cognito User Pools: chức năng đăng nhập (sign in) cho người dùng ứng dụng; tích hợp với API Gateway và Application Load Balancer.
Cognito Identity Pools (Federated Identity): cung cấp AWS credentials cho người dùng để họ truy cập trực tiếp tài nguyên AWS; tích hợp với Cognito User Pools như một identity provider.

Cognito User Pools (CUP) — tính năng người dùng

Tạo một database người dùng serverless cho web & mobile app.
Đăng nhập đơn giản: cặp Username (hoặc email) / password.
Reset password.
Xác minh email & số điện thoại.
Multi-factor authentication (MFA).
Federated Identities: người dùng từ Facebook, Google, SAML…

CUP tích hợp với API Gateway và Application Load Balancer:

Với API Gateway: client Authenticate với Cognito User Pools để lấy token, rồi gọi REST API + pass token; API Gateway đánh giá Cognito Token trước khi cho đi tới backend.
Với Application Load Balancer: ALB (cùng Listeners & Rules) tự Authenticate với Cognito User Pools rồi mới chuyển traffic tới Target Group.

Cognito Identity Pools (Federated Identities)

Cấp danh tính cho “users” để họ lấy được AWS credentials tạm thời.
Nguồn người dùng có thể là Cognito User Pools, các dịch vụ đăng nhập bên thứ ba…
Sau đó người dùng truy cập trực tiếp các dịch vụ AWS, hoặc đi qua API Gateway.
Các IAM policy áp cho credential đó được định nghĩa trong Cognito.
Policy có thể tùy biến theo user_id để kiểm soát ở mức chi tiết (fine grained).
Có IAM role mặc định riêng cho người dùng đã xác thực và cho guest user.

Luồng hoạt động: Web & Mobile Application đăng nhập và lấy token từ một Social Identity Provider (hoặc từ Cognito User Pools) → đổi token lấy AWS credentials tạm thời ở Cognito Identity Pools (Cognito validate token) → dùng credential đó truy cập trực tiếp Private S3 Bucket và DynamoDB Table.

Một ứng dụng đáng nhớ của Identity Pools: dựng Row Level Security trong DynamoDB — mỗi người dùng chỉ đọc/ghi được đúng các dòng của mình, vì IAM policy được gắn theo user_id.

Tóm tắt nhanh

Chủ đề	Phải nhớ
Serverless	Không phải “không có server” — mà là bạn không quản lý/cấp phát/thấy server. Gồm Lambda, DynamoDB, Cognito, API Gateway, S3, SNS & SQS, Kinesis Data Firehose, Aurora Serverless, Step Functions, Fargate
Lambda vs EC2	Lambda: virtual function, giới hạn thời gian, chạy on-demand, scale tự động · EC2: giới hạn RAM/CPU, chạy liên tục, scale phải can thiệp
Giới hạn Lambda	RAM 128 MB – 10GB · timeout 900s (15 phút) · env var 4 KB · `/tmp` 512 MB – 10GB · concurrency 1000 · zip 50 MB, giải nén 250 MB. Tăng RAM cũng tăng CPU và network
Throttling	Sync → ThrottleError 429 · Async → retry rồi vào DLQ; async gặp 429/5xx thì Lambda retry tới 6 giờ, giãn cách từ 1 giây tới 5 phút
Cold start	Provisioned Concurrency cấp phát trước để không có cold start · SnapStart cho Java, Python, .NET, nhanh tới 10x, miễn phí
Edge functions	CloudFront Functions: JavaScript, < 1 ms, hàng triệu req/s, chỉ Viewer Request/Response, không network/file system/body · Lambda@Edge: Node.js/Python, 5–10s, có Origin Request/Response, viết ở us-east-1
Lambda & VPC	Mặc định nằm ngoài VPC của bạn → không thấy RDS/ElastiCache/internal ELB; đưa vào VPC thì khai VPC ID + Subnet + Security Group, Lambda tạo ENI
RDS Proxy	Pool connection, giảm 66% thời gian failover, bắt buộc IAM auth + Secrets Manager; Lambda phải ở trong VPC vì proxy không public
DynamoDB cơ bản	NoSQL có transaction, multi-AZ, single-digit ms; item tối đa 400KB; Primary Key quyết định lúc tạo table; Standard & IA table class
Capacity mode	Provisioned (RCU/WCU, có auto-scaling, phải plan trước) · On-Demand (không plan, đắt hơn, tốt cho spike khó đoán)
DAX	Cache in-memory riêng cho DynamoDB, độ trễ microsecond, TTL mặc định 5 phút, không sửa code; cache object + Query/Scan (ElastiCache dùng để lưu kết quả tổng hợp)
Streams	DynamoDB Streams: 24 giờ, ít consumer · Kinesis Data Streams: 1 năm, nhiều consumer
Global Tables / TTL / Backup	Global Tables active-active, bắt buộc bật Streams · TTL tự xóa theo expiry timestamp · PITR 35 ngày (restore ra table mới) + on-demand backup qua AWS Backup
API Gateway	WebSocket, versioning, API key, throttling, caching, Swagger import; tích hợp Lambda / HTTP / AWS Service; endpoint Edge-Optimized (cert us-east-1) · Regional (cert cùng region) · Private (VPC endpoint + resource policy)
Step Functions	Workflow trực quan điều phối Lambda: sequence, parallel, condition, timeout, error handling, human approval
Cognito	User Pools = đăng nhập (tích hợp API Gateway & ALB, MFA, federated) · Identity Pools = AWS credential tạm thời, IAM policy định nghĩa trong Cognito, tùy biến theo `user_id` (row level security cho DynamoDB)