Servisphere

Module 3 · SAA-C03

Compute: EC2, Auto Scaling, Lambda, container

Chọn loại máy và cách mua EC2, tự co giãn, serverless với Lambda, container trên ECS / EKS / Fargate.

  • DomainThiết kế chịu lỗi
  • DomainThiết kế hiệu năng cao
  • DomainTối ưu chi phí
  • 9 sơ đồ
  • 10 tình huống
  • 11 dịch vụ

5 phút phải nhớ

  1. EC2 là máy ảo bạn tự quản hệ điều hành; Lambda chạy hàm theo sự kiện, tối đa 15 phút mỗi lần; Fargate chạy container mà không quản máy.Đề hay cho ràng buộc "ít vận hành nhất" → nghiêng về Lambda / Fargate; cần chạy lâu, cần GPU hay hệ điều hành riêng → EC2.
  2. Họ instance: C = tính toán, R / X = bộ nhớ, I / D = đĩa local nhanh, P / G = GPU, T = burstable, M = cân bằng.Đề không hỏi tên chính xác từng đời, nhưng hay hỏi chọn họ theo đặc điểm tải (in-memory cache → R, HPC → C, ML training → P).
  3. Cách mua EC2: On-Demand (không cam kết), Savings Plans / Reserved (cam kết 1 hoặc 3 năm), Spot (rẻ nhất, có thể bị thu hồi), Dedicated Host (cần giấy phép theo socket / core).Tải ổn định chạy 24/7 → Savings Plans hoặc Reserved; tải chịu ngắt được (batch, CI) → Spot; giấy phép BYOL theo máy vật lý → Dedicated Host.
  4. Spot nhận cảnh báo 2 phút trước khi bị thu hồi (qua EventBridge và instance metadata).Ứng dụng phải chịu được ngắt: lưu trạng thái ra ngoài (S3, DynamoDB, SQS), checkpoint công việc.
  5. Compute Savings Plans áp cho EC2, Fargate và Lambda, đổi họ / Region / hệ điều hành thoải mái; EC2 Instance Savings Plans rẻ hơn nhưng khoá họ instance trong một Region.Đề hỏi "linh hoạt nhất mà vẫn giảm giá" → Compute Savings Plans.
  6. Auto Scaling group giữ số máy giữa min và max, thay máy hỏng, trải đều các AZ; target tracking là chính sách nên dùng mặc định.Theo dõi một chỉ số (CPU 50%, request mỗi target) và tự thêm / bớt máy; scheduled scaling cho tải biết trước giờ; predictive scaling cho tải theo chu kỳ.
  7. ALB: tầng 7 (HTTP/HTTPS), định tuyến theo đường dẫn / host / header, target là EC2, IP, Lambda, container. NLB: tầng 4 (TCP/UDP/TLS), độ trễ rất thấp, IP tĩnh mỗi AZ. GWLB: chèn thiết bị bảo mật bên thứ ba.Cần IP cố định hoặc UDP → NLB; định tuyến /api, /images → ALB.
  8. Placement group: cluster (cùng AZ, mạng nhanh nhất), partition (tối đa 7 phân vùng mỗi AZ, tách rack cho Hadoop / Cassandra), spread (tối đa 7 instance mỗi AZ, mỗi máy một rack).HPC độ trễ thấp → cluster; vài máy quan trọng không được hỏng cùng lúc → spread.
  9. Lambda: bộ nhớ 128 MB–10 GB (CPU tăng theo bộ nhớ), /tmp tới 10 GB, mặc định 1.000 lần chạy đồng thời mỗi Region (xin tăng được).Cần nhanh hơn → tăng bộ nhớ; cold start với hàm cần phản hồi đều → provisioned concurrency.
  10. Lambda gọi đồng bộ (API Gateway, ALB) trả lỗi cho người gọi; gọi bất đồng bộ (S3, SNS, EventBridge) tự thử lại 2 lần rồi gửi tới DLQ / destination.Đọc từ SQS, Kinesis, DynamoDB Streams là event source mapping: Lambda tự kéo theo lô.
  11. ECS và EKS là bộ điều phối container; Fargate hoặc EC2 là nơi container chạy; ECR là kho image.Đã dùng Kubernetes, cần chuyển nguyên lên AWS → EKS; muốn đơn giản nhất → ECS trên Fargate.
  12. Elastic Beanstalk và App Runner dựng sẵn hạ tầng từ code / image; AWS Batch xếp hàng và chạy job lô trên EC2 / Spot / Fargate.Đề "nhóm dev không rành hạ tầng, muốn đưa web lên nhanh" → Beanstalk / App Runner; "hàng nghìn job xử lý lô" → Batch.
  13. EC2 Hibernate giữ RAM xuống EBS root (được mã hoá) để khởi động lại nhanh; user data chạy script lúc khởi tạo; AMI là khuôn để dựng máy giống nhau.Ứng dụng khởi động chậm vì nạp bộ nhớ lớn → hibernate hoặc AMI dựng sẵn (golden AMI).

Sơ đồ

Auto Scaling group sau ALB, co giãn theo CPU

Auto Scaling group sau ALB, co giãn theo CPURegionVPCAuto Scaling group · min 2, max 6HTTPS1113CPU2vượt mục tiêu2thêm máy3Người dùngALBEC2AZ aEC2AZ bEC2 mớiscale-outCloudWatch alarmTarget trackingCPU 50%
ALB chia tải cho các EC2 trong Auto Scaling group trải hai AZ. CloudWatch theo dõi CPU; target tracking thêm máy khi vượt mục tiêu và bớt máy khi rảnh.

Từng bước

  1. ALB chia request cho các máy khoẻ trong Auto Scaling group (health check của ALB).
  2. CPU trung bình vượt 50%: báo động CloudWatch do target tracking tự tạo kích hoạt.
  3. ASG thêm máy (ở AZ còn ít máy); máy đạt health check thì ALB bắt đầu gửi request.

Auto Scaling group trộn On-Demand và Spot

Auto Scaling group trộn On-Demand và SpotAuto Scaling group (mixed instances)Spot interruption22trả việc3On-Demandphần nềnSpotm6iSpotc6a / r6gEventBridgecảnh báo 2 phútLambdarút máy, lưu tiến độSQSviệc chưa xong
Phần nền chạy On-Demand, phần còn lại chạy Spot với nhiều họ instance. Khi Spot sắp bị thu hồi, EventBridge nhận cảnh báo 2 phút để rút máy khỏi tải và lưu tiến độ.

Từng bước

  1. Phần nền On-Demand giữ dịch vụ tối thiểu; Spot đa dạng họ instance để giảm rủi ro bị thu hồi cùng lúc.
  2. AWS cần lại dung lượng: EventBridge nhận "EC2 Spot Instance Interruption Warning" trước 2 phút.
  3. Việc dở được trả về hàng đợi; ASG tự xin máy thay thế.

Ba kiểu placement group

Ba kiểu placement groupCluster · 1 AZPartitionSpreadPhân vùng 1Phân vùng 2độ trễ thấpEC2EC2EC2Kafka 1Kafka 2Rack ARack BRack C
Cluster: dồn máy gần nhau trong một AZ để mạng nhanh nhất. Partition: chia nhóm rack riêng (tối đa 7 mỗi AZ). Spread: mỗi máy một rack (tối đa 7 máy mỗi AZ).

ALB định tuyến theo đường dẫn; NLB cho TCP/UDP với IP tĩnh

ALB định tuyến theo đường dẫn; NLB cho TCP/UDP với IP tĩnhHTTPS1/api/*1/img/*1UDP22Trình duyệtALBHTTPS :443ECS: /api/*Lambda: /img/*Game clientNLBUDP :7777 · EIPGame servers
ALB đọc HTTP nên chọn target group theo đường dẫn. NLB chỉ nhìn cổng TCP/UDP, giữ IP cố định ở mỗi AZ.

Từng bước

  1. ALB: luật listener theo đường dẫn; target có thể là container, EC2, IP hoặc Lambda.
  2. NLB: tầng 4, hỗ trợ UDP, IP tĩnh (gắn Elastic IP) để khách whitelist.

Lambda chạy theo sự kiện

Lambda chạy theo sự kiệntải lên1sự kiện11kéo lô22quá maxReceiveCount3Người dùngS3ảnh gốcLambdatạo ảnh nhỏS3ảnh nhỏSQSđơn hàngLambdaxử lý theo lôDynamoDBDLQtin lỗi
S3 gọi Lambda bất đồng bộ khi có file mới; Lambda tự kéo tin từ SQS theo lô (event source mapping). Lỗi quá số lần thử thì tin đi vào DLQ.

Từng bước

  1. Gọi bất đồng bộ: S3 gửi sự kiện, Lambda chạy, lỗi thì tự thử lại 2 lần.
  2. Event source mapping: Lambda tự poll SQS, nhận lô tin, xử lý xong thì xoá tin.
  3. Tin bị xử lý hỏng quá maxReceiveCount lần thì chuyển vào DLQ để xem lại.

Gọi Lambda đồng bộ và bất đồng bộ

Gọi Lambda đồng bộ và bất đồng bộClientAPI GatewayLambdaS3Destination1. GET /orders2. Gọi đồng bộ, chờ3. Kết quả hoặc lỗi4. 200 / 5xx5. Sự kiện ObjectCreated (bất đồng bộ)6. Lỗi: thử lại tối đa 2 lần7. Vẫn lỗi: on-failure destination / DLQ
Đồng bộ: người gọi chờ kết quả và tự xử lý lỗi. Bất đồng bộ: Lambda nhận sự kiện vào hàng đợi nội bộ, tự thử lại rồi gửi tới destination.

ECS trên Fargate sau ALB

ECS trên Fargate sau ALBVPCSubnet private (2 AZ)HTTPS22211kéo image1IAM task role3Người dùngALBtarget type: ipTaskFargateTaskFargateECS servicegiữ 2 taskECRS3qua task role
Mỗi task Fargate có ENI riêng trong subnet private và IAM task role riêng. Image kéo từ ECR; ALB dùng target type IP.

Từng bước

  1. ECS service giữ đúng số task mong muốn; Fargate kéo image từ ECR và chạy task, không có máy chủ để quản.
  2. ALB gửi request thẳng tới IP của từng task (chế độ mạng awsvpc).
  3. Task truy cập S3 bằng IAM task role, không cần access key.

Amazon EKS: control plane do AWS quản

Amazon EKS: control plane do AWS quảnDo AWS quản lýVPC của bạnManaged node groupFargate profile122lập lịch Pod1Control planeAPI server, etcdALB (Ingress)NodePod A, BNodePod CPod trên Fargate
AWS chạy và vá control plane Kubernetes ở nhiều AZ. Pod chạy trên managed node group (EC2) hoặc Fargate; Ingress tạo ALB qua AWS Load Balancer Controller.

Từng bước

  1. Control plane (do AWS quản, nhiều AZ) lập lịch Pod lên node EC2 của node group hoặc lên Fargate.
  2. Ingress được AWS Load Balancer Controller biến thành ALB trỏ tới các Pod.

AWS Batch chạy job lô trên Spot

AWS Batch chạy job lô trên SpotCompute environment (Spot)gửi job12222EventBridgelịch 2 giờ sángJob queueSpotjob 1..nSpotjob n..mS3 đầu vàoS3 kết quả
Job được gửi vào hàng đợi; Batch tự dựng compute environment (Spot, nhiều họ instance), chạy container, rồi thu nhỏ về 0 khi hết việc.

Từng bước

  1. EventBridge theo lịch gửi job vào hàng đợi của Batch.
  2. Batch dựng máy Spot đủ cho hàng đợi, chạy container, ghi kết quả lên S3; hết việc thì giảm về 0.

So sánh nhanh

EC2, Lambda, Fargate

EC2LambdaFargate (ECS / EKS)
Bạn quản lýHệ điều hành, vá lỗi, co giãnChỉ codeImage container, CPU / bộ nhớ của task
Thời gian chạyKhông giới hạnTối đa 15 phút mỗi lầnKhông giới hạn
Tính tiềnTheo giây khi máy chạyTheo số lần gọi và thời gian × bộ nhớTheo vCPU và bộ nhớ của task
Hợp vớiỨng dụng cũ, GPU, hệ điều hành riêng, chạy 24/7Xử lý sự kiện, API nhỏ, tác vụ ngắnMicroservice, container chạy lâu không muốn quản máy

Cách mua EC2

CáchCam kếtGiảm tối đaDùng khi
On-DemandKhông—Tải ngắn, khó đoán, thử nghiệm
Compute Savings Plans1 hoặc 3 năm, theo USD/giờTới 66%Tải ổn định, muốn đổi họ / Region / cả Fargate, Lambda
EC2 Instance Savings Plans / Reserved Instances1 hoặc 3 năm, theo họ instanceTới 72%Tải ổn định, biết chắc họ instance và Region
SpotKhông, có thể bị thu hồi (báo trước 2 phút)Tới 90%Batch, CI, xử lý ảnh, phân tích chịu ngắt được
Dedicated HostTheo giờ hoặc đặt trước—Giấy phép theo socket / core, yêu cầu tuân thủ máy vật lý riêng

ALB, NLB, GWLB

ALBNLBGWLB
Tầng7 (HTTP/HTTPS, gRPC, WebSocket)4 (TCP, UDP, TLS)3 (gói IP, giao thức GENEVE)
Định tuyếnTheo đường dẫn, host, header, queryTheo cổngQua thiết bị ảo (firewall, IDS)
IPĐổi được, dùng tên DNSIP tĩnh mỗi AZ, gắn được Elastic IP—
TargetEC2, IP, Lambda, containerEC2, IP, ALBThiết bị bảo mật
Ví dụ đềMicroservice /api, /webGame UDP, cần whitelist IP, hàng triệu kết nốiChèn firewall bên thứ ba cho mọi traffic

Placement group

ClusterPartitionSpread
Phạm viMột AZNhiều AZ, tối đa 7 phân vùng mỗi AZNhiều AZ, tối đa 7 instance mỗi AZ
Mục tiêuĐộ trễ thấp, băng thông cao giữa các máyCô lập lỗi phần cứng theo nhóm rackMỗi máy một rack riêng
Hợp vớiHPC, tính toán song songHDFS, HBase, Cassandra, KafkaVài máy quan trọng (primary / standby)

ECS, EKS và nơi chạy container

ECSEKS
Điều phốiCủa AWS, đơn giảnKubernetes chuẩn (control plane do AWS quản)
Chạy trênFargate hoặc EC2Fargate, managed node group, self-managed node
Chọn khiMuốn đơn giản, tích hợp sâu với AWSĐã dùng Kubernetes, cần di chuyển giữa nhiều nơi / công cụ K8s
Quyền truy cập AWSTask role (IAM) cho từng taskIAM role cho service account / Pod Identity

Tình huống đề hay gặp

1Web chạy EC2 sau ALB, lưu lượng tăng vọt vào giờ làm việc và giảm về đêm; cần tự co giãn và giữ CPU khoảng 50%.

Xem đáp án

Đúng: Auto Scaling group trải ≥ 2 AZ, gắn vào target group của ALB, target tracking giữ CPU trung bình 50%
Target tracking tự tạo báo động CloudWatch và thêm / bớt máy để bám mục tiêu; ASG thay máy hỏng và trải đều AZ.

Sai: Simple scaling policy với cooldown 300 giây
Chạy được nhưng chậm và giật; AWS khuyên dùng target tracking.

Sai: Tăng cỡ instance lên thật lớn
Scale-up tốn tiền cả lúc vắng và vẫn là một điểm hỏng.

2Hàng đêm xử lý 2 triệu ảnh, việc có thể làm lại nếu bị ngắt, cần chi phí thấp nhất.

Xem đáp án

Đúng: AWS Batch (hoặc Auto Scaling group) dùng Spot Instances, nhiều họ instance; việc đọc từ hàng đợi để làm lại khi bị thu hồi
Spot rẻ tới 90%; đa dạng họ instance giảm khả năng bị thu hồi cùng lúc; hàng đợi giữ việc chưa xong.

Sai: Reserved Instances 3 năm
Trả cho cả ngày trong khi chỉ chạy vài giờ đêm.

Sai: On-Demand
Đắt hơn Spot nhiều cho tải chịu ngắt được.

3Tải chạy ổn định 24/7 trên EC2 nhưng công ty dự định chuyển dần sang Fargate và Lambda trong 3 năm tới.

Xem đáp án

Đúng: Compute Savings Plans
Cam kết USD/giờ, áp tự động cho EC2, Fargate và Lambda ở mọi Region.

Sai: EC2 Instance Savings Plans
Khoá họ instance trong một Region, không áp cho Fargate / Lambda.

Sai: Spot
Tải 24/7 quan trọng không nên chịu thu hồi.

4Cụm tính toán HPC cần độ trễ mạng giữa các node thấp nhất có thể.

Xem đáp án

Đúng: Cluster placement group trong một AZ, instance có enhanced networking
Các máy nằm cùng phân đoạn mạng băng thông cao.

Sai: Spread placement group
Đặt máy ở rack khác nhau: tăng độ bền, không giảm độ trễ.

Sai: Rải máy ra 3 AZ
Độ trễ giữa AZ cao hơn trong một AZ.

5Ứng dụng game dùng UDP, khách hàng doanh nghiệp yêu cầu IP cố định của load balancer để mở tường lửa.

Xem đáp án

Đúng: Network Load Balancer với Elastic IP ở mỗi AZ
NLB làm ở tầng 4, hỗ trợ UDP, có IP tĩnh mỗi AZ.

Sai: Application Load Balancer
ALB không hỗ trợ UDP và IP thay đổi.

6Hàm Lambda xử lý ảnh khi người dùng tải lên S3; thỉnh thoảng lỗi và mất sự kiện.

Xem đáp án

Đúng: Cấu hình on-failure destination (hoặc DLQ) là SQS / SNS cho lời gọi bất đồng bộ; theo dõi rồi xử lý lại
Gọi bất đồng bộ được thử lại 2 lần; sau đó sự kiện đi tới destination thay vì mất.

Sai: Tăng timeout lên 15 phút
Không giải quyết được sự kiện lỗi thật sự.

7API trên Lambda có độ trễ không đều vì cold start vào sáng thứ Hai.

Xem đáp án

Đúng: Provisioned concurrency (có thể lên lịch theo giờ cao điểm)
Giữ sẵn số môi trường đã khởi tạo, nên lời gọi không chịu cold start.

Sai: Tăng reserved concurrency
Reserved concurrency chỉ giữ chỗ / giới hạn, không làm ấm môi trường chạy.

8Công ty có ứng dụng microservice trong container, không muốn quản lý máy chủ hay cụm, cần ít vận hành nhất.

Xem đáp án

Đúng: ECS trên Fargate, image trong ECR, ALB phía trước
Không có máy chủ để quản; mỗi task có ENI và IAM role riêng.

Sai: EKS với self-managed node group
Vẫn phải vá, co giãn và quản node.

Sai: Chạy Docker trên EC2 tự cài
Nhiều vận hành nhất.

9Đã có nhiều manifest và công cụ Kubernetes on-prem, muốn chuyển lên AWS mà giữ nguyên cách triển khai.

Xem đáp án

Đúng: Amazon EKS (managed node group hoặc Fargate)
API Kubernetes chuẩn, control plane do AWS quản.

Sai: ECS
Phải viết lại task definition, bỏ công cụ Kubernetes.

10Một tác vụ xử lý video mất 40 phút mỗi lần.

Xem đáp án

Đúng: ECS / Fargate task hoặc AWS Batch (kích hoạt bởi sự kiện qua EventBridge / Step Functions)
Container chạy không giới hạn thời gian, vẫn không cần quản máy.

Sai: Lambda
Giới hạn 15 phút mỗi lần chạy.

Chọn nhanh

Chạy code ở đâu?

Khi cầnDùng
Xử lý sự kiện ngắn (dưới 15 phút), lưu lượng thất thườngLambda · xem sơ đồ
Container, không muốn quản máyECS trên Fargate · xem sơ đồ
Đã dùng KubernetesEKS · xem sơ đồ
Cần toàn quyền hệ điều hành, GPU, phần mềm cũEC2 + Auto Scaling group · xem sơ đồ
Job lô số lượng lớn, chịu ngắt đượcAWS Batch trên Spot · xem sơ đồ
Web app, dev không rành hạ tầngElastic Beanstalk hoặc App Runner
HTTP, định tuyến theo đường dẫn / hostApplication Load Balancer · xem sơ đồ
TCP / UDP, IP tĩnh, độ trễ cực thấpNetwork Load Balancer · xem sơ đồ
Tải ổn định nhiều năm, có thể đổi sang Fargate / LambdaCompute Savings Plans
Tải chịu ngắt được, cần rẻ nhấtSpot (đa dạng họ instance) · xem sơ đồ
Máy cần độ trễ mạng thấp nhất giữa nhauCluster placement group · xem sơ đồ

Bẫy hay gặp

  • Dùng Lambda cho việc chạy quá 15 phút.
  • Chọn Reserved / Savings Plans cho tải chỉ chạy vài giờ mỗi ngày: Spot hoặc On-Demand + co giãn rẻ hơn.
  • Đặt Spot cho tải quan trọng không chịu ngắt (database chính, phiên người dùng giữ trong RAM).
  • Nhầm reserved concurrency (giới hạn / giữ chỗ) với provisioned concurrency (làm ấm, chống cold start).
  • Dùng ALB cho UDP hoặc khi đề đòi IP tĩnh: đó là NLB.
  • Auto Scaling group chỉ ở một AZ: AZ hỏng là mất hết.
  • Spread placement group cho HPC cần độ trễ thấp (phải là cluster), hoặc đặt hơn 7 máy mỗi AZ trong spread.
  • Lưu phiên người dùng trên đĩa / RAM của EC2 trong ASG: máy bị thay là mất; đưa phiên ra ElastiCache / DynamoDB.
  • Nghĩ Fargate là một bộ điều phối: Fargate là nơi chạy, ECS / EKS mới là bộ điều phối.
  • Cấp quyền AWS cho container bằng access key trong biến môi trường thay vì task role / IAM role cho Pod.
  • Nghĩ EC2 Instance Savings Plans áp cho Lambda / Fargate: chỉ Compute Savings Plans mới áp.

Dịch vụ trong module

Số liệu dễ thay đổi (đã kiểm với tài liệu AWS)

  • Lambda chạy tối đa 15 phút mỗi lần (900 giây); bộ nhớ 128 MB–10.240 MB; /tmp 512 MB–10.240 MB. kiểm ngày 2026-10-16 ↗
  • Lambda mặc định 1.000 lần chạy đồng thời mỗi Region (xin tăng được tới hàng chục nghìn). kiểm ngày 2026-10-16 ↗
  • Lambda: payload 6 MB cho gọi đồng bộ, 1 MB cho gọi bất đồng bộ; gói zip 50 MB (nén) / 250 MB (giải nén), container image tới 10 GB. kiểm ngày 2026-10-16 ↗
  • Spot Instance nhận cảnh báo 2 phút trước khi bị dừng / huỷ (EventBridge và instance metadata). kiểm ngày 2026-10-16 ↗
  • Spot giảm tới 90% so với On-Demand. kiểm ngày 2026-10-16 ↗
  • Compute Savings Plans giảm tới 66%, áp cho EC2, Fargate, Lambda; EC2 Instance Savings Plans giảm tới 72%; kỳ hạn 1 hoặc 3 năm. kiểm ngày 2026-10-16 ↗
  • Partition placement group tối đa 7 phân vùng mỗi AZ; spread placement group tối đa 7 instance đang chạy mỗi AZ; cluster placement group nằm trong một AZ. kiểm ngày 2026-10-16 ↗
  • Fargate Spot: task bị ngắt với cảnh báo 2 phút. kiểm ngày 2026-10-16 ↗
  • Cooldown mặc định của Auto Scaling là 300 giây và chỉ áp cho simple scaling policy; AWS khuyên dùng target tracking. kiểm ngày 2026-10-16 ↗
Luyện câu hỏi module này →