Lộ trình
Amazon Web ServicesCơ bảnTuần 2: Dịch vụ cốt lõi (Compute, Storage, Database, Networking)Bài 9 / 30

Ngày 9: Compute nâng cao và serverless

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
aws-clf-c02ngày 9
hoàn thành9 / 30 bài
Bối cảnh bài học

Phân biệt ALB, Auto Scaling, Lambda và Elastic Beanstalk theo vai trò, không học chúng như các tên gọi thay thế nhau.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Phân biệt ALB, Auto Scaling, Lambda và Elastic Beanstalk theo vai trò, không học chúng như các tên gọi thay thế nhau.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Tìm hiểu Auto Scaling, Elastic Load Balancing
  • So sánh EC2, Lambda, Elastic Beanstalk
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

Một website cần tiếp tục phục vụ khi một instance lỗi và tự tăng capacity khi traffic tăng. Team đang nhầm ALB là công cụ scale và Lambda là lựa chọn thay thế cho mọi workload; bài học tách rõ từng responsibility.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • ALB nhận và phân phối HTTP/HTTPS đến target group, có health check.
  • ASG duy trì desired/min/max capacity và thay instance không khỏe; nó không tự phân phối request.
  • Lambda chạy function theo event với execution role, timeout và memory; không phải ứng dụng dài hạn mặc định.
  • Elastic Beanstalk đơn giản hóa deployment ứng dụng, nhưng vẫn có resource bên dưới cần hiểu và quản lý.

Mục tiêu bài học

Phân biệt ALB, Auto Scaling, Lambda và Elastic Beanstalk theo vai trò, không học chúng như các tên gọi thay thế nhau.

Bài giảng chi tiết

Bài toán thực tế

Một website cần tiếp tục phục vụ khi một instance lỗi và tự tăng capacity khi traffic tăng. Team đang nhầm ALB là công cụ scale và Lambda là lựa chọn thay thế cho mọi workload; bài học tách rõ từng responsibility.

Đừng học nội dung này như một danh sách tên dịch vụ. Hãy đi theo chuỗi: requirement → khái niệm → quyết định → bằng chứng. Một câu trả lời tốt phải nói được vì sao lựa chọn phù hợp, phương án gần nhất bị loại ở đâu, và kiểm tra nào chứng minh lựa chọn đó hoạt động.

Khái niệm được giải thích theo scenario

  1. ALB nhận và phân phối HTTP/HTTPS đến target group, có health check.
  2. ASG duy trì desired/min/max capacity và thay instance không khỏe; nó không tự phân phối request.
  3. Lambda chạy function theo event với execution role, timeout và memory; không phải ứng dụng dài hạn mặc định.
  4. Elastic Beanstalk đơn giản hóa deployment ứng dụng, nhưng vẫn có resource bên dưới cần hiểu và quản lý.

Ví dụ khi gặp một scenario mới, hãy thay các từ khóa trong đề bằng một hệ thống cụ thể: ai là người dùng, dữ liệu đi qua đâu, thành phần nào có thể lỗi, quyền nào cần có và điều gì phải được quan sát. Cách làm này giúp phân biệt các đáp án gần đúng thay vì chọn theo trí nhớ tên service.

flowchart LR
  A[Scenario / requirement] --> B[Concept and boundary]
  B --> C[Service or control choice]
  C --> D[Evidence and trade-off]
  D --> E[Failure variant]

Khái niệm cốt lõi

ALB phân phối HTTP/HTTPS tới target group và dùng health check. Auto Scaling Group duy trì desired/min/max capacity và thay instance lỗi. Lambda chạy function theo event mà không quản lý server. Elastic Beanstalk đơn giản hóa triển khai ứng dụng nhưng có thể dùng EC2 bên dưới.

Ví dụ giảng viên: phân loại một quyết định cloud

Hãy phân biệt “phân phối traffic”, “duy trì capacity” và “chạy code theo event”. ALB không tự tạo instance; ASG không tự hiểu request nếu không có launch template/health/scaling signal; Lambda giảm quản lý server nhưng vẫn có timeout, concurrency, retry và permission; Beanstalk là abstraction triển khai chứ không làm biến mất các resource bên dưới.

Ví dụ checkout API: ALB nhận HTTPS và health check /health; ASG giữ tối thiểu hai target ở hai AZ; Lambda xử lý event gửi email với execution role tối thiểu. Nếu health check chỉ trả 200 dù database đã lỗi, ALB có thể tiếp tục gửi traffic vào app “healthy giả”. Nếu Lambda retry event thanh toán mà handler không idempotent, có thể gửi email hoặc ghi dữ liệu trùng.

Bài tập phải chỉ rõ metric, failure signal, retry behavior và rollback, không chỉ vẽ bốn hộp service.

Thực hành có kiểm soát

Vẽ flow client → ALB → target group → EC2 ở hai AZ. Ghi health-check path, min/max capacity và metric scale-out. Với Lambda, xác định event source, timeout, memory và execution role. Không đặt access key dài hạn trong function.

Expected state và recovery

Trước khi thực hành, ghi rõ target/account/region, trạng thái hiện tại và output mong đợi. Sau thao tác, kiểm chứng bằng trạng thái thực tế hoặc command phù hợp; nếu kết quả sai, giữ lại evidence, quay về thay đổi nhỏ nhất và cleanup đúng owner. Không coi exit code 0 hoặc thông báo “success” là bằng chứng duy nhất.

  1. Chỉ ra component nhận traffic, component duy trì capacity và component kiểm tra health.
  2. Giải thích điều gì xảy ra khi một target fail health check.
  3. Chọn Lambda hoặc EC2 cho hai workload khác nhau và nêu giới hạn runtime/event.
  4. Không đặt access key dài hạn trong Lambda hoặc instance.

Bẫy đề thi và cách tự kiểm tra

ALB không tự tạo instance; ASG không phân phối traffic. Lambda phù hợp function/event ngắn, không phải mọi workload. Beanstalk là managed application platform, không đồng nghĩa SaaS.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
aws sts get-caller-identity --profile study
aws elbv2 describe-load-balancers --profile study --output table
aws autoscaling describe-auto-scaling-groups --profile study --query "AutoScalingGroups[].{Name:AutoScalingGroupName,Desired:DesiredCapacity,Min:MinSize,Max:MaxSize}" --output table
Hands-on lab

Thực hành theo scenario

Vẽ flow client → ALB → target group → EC2 ở hai AZ. Đánh dấu health-check path, desired/min/max và tín hiệu scale-out. Tạo một bảng so sánh cùng workload khi chạy EC2, Lambda và Beanstalk. Không cần tạo tài nguyên; nếu có sandbox chỉ đọc trạng thái ASG/target.

Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Chỉ ra component nhận traffic, component duy trì capacity và component kiểm tra health.
  • Giải thích điều gì xảy ra khi một target fail health check.
  • Chọn Lambda hoặc EC2 cho hai workload khác nhau và nêu giới hạn runtime/event.
  • Không đặt access key dài hạn trong Lambda hoặc instance.
Transfer to exam / production

Bẫy thường gặp và trade-off

ALB không tự tạo instance; ASG không phân phối traffic. Lambda phù hợp function/event ngắn, không phải mọi workload. Beanstalk là managed application platform, không đồng nghĩa SaaS.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Thành phần nào duy trì số lượng EC2 theo min/desired/max?

Kết thúc bài

Checklist trước khi sang Ngày 2