ELB & Auto Scaling Groups
Đây là nơi mọi thứ đã học ghép lại thành một kiến trúc thật: EC2 chạy ứng dụng, ELB phân phối tải, ASG tự tăng giảm số máy. Gần như mọi câu hỏi kiến trúc trong đề thi đều có ít nhất một trong ba thành phần này.
Scalability & High Availability
Ba khái niệm dễ nhầm và đề thi thích hỏi ngay câu đầu.
Vertical vs Horizontal Scalability
| Vertical Scaling | Horizontal Scaling | |
|---|---|---|
| Làm gì | Tăng kích cỡ một máy: t2.micro → t2.large | Tăng số lượng máy: 3 instance → 10 instance |
| Còn gọi là | Scale up / scale down | Scale out / scale in, elasticity |
| Hợp với | Hệ thống không phân tán: database, RDS, ElastiCache | Hệ thống phân tán: web app, ứng dụng nhiều tầng |
| Giới hạn | Có trần phần cứng — không có máy nào to vô hạn | Gần như không giới hạn |
| Công cụ | Đổi instance type | Auto Scaling Group + Load Balancer |
Thấy tên instance đổi kích cỡ (r4.large → r4.4xlarge) → vertical. Thấy số lượng máy tăng giảm qua ASG → horizontal. Đây là hai câu mở đầu quiz gốc, gần như cho điểm.
High Availability
High Availability nghĩa là chạy ứng dụng ở ít nhất 2 Availability Zone, mục tiêu là sống sót khi mất trọn một data center. Nó có thể ở dạng chủ động (nhiều instance cùng phục vụ, như horizontal scaling qua nhiều AZ) hoặc bị động (một bản standby chờ sẵn, như RDS Multi-AZ).
Scalability ≠ Elasticity ≠ Agility
| Khái niệm | Nghĩa |
|---|---|
| Scalability | Khả năng gánh được tải lớn hơn — bằng cách máy khỏe hơn hoặc thêm máy |
| Elasticity | Tự động co giãn theo tải thực tế, trả tiền theo mức dùng |
| Agility | Tài nguyên mới có trong vài phút thay vì vài tháng — không liên quan tới scaling |
Một sàn thương mại điện tử trước ngày sale: vertical — nâng database RDS từ db.m5.large lên db.m5.4xlarge vì database khó chia nhỏ. Horizontal — web tier tăng từ 4 lên 30 instance qua ASG. High availability — 30 máy đó trải đều 3 AZ để một AZ chết vẫn còn 20 máy. Ba khái niệm cùng xuất hiện trong một hệ thống, mỗi cái giải một tầng khác nhau.
ELB Overview & Health Checks
Load Balancer là máy chủ đứng trước, nhận request rồi chuyển tiếp xuống nhiều máy phía sau. ELB là bản được AWS quản lý — AWS lo nâng cấp, bảo trì và tính sẵn sàng, bạn chỉ chỉnh vài tham số.
Load Balancer giải quyết những gì
- Trải tải ra nhiều instance phía sau
- Cho ra một điểm truy cập duy nhất (một DNS name) — client không cần biết có bao nhiêu máy
- Tự xử lý khi một máy chết, nhờ health check
- Kết thúc SSL (SSL termination) cho traffic HTTPS
- Giữ phiên người dùng bằng cookie (stickiness)
- Tách bạch traffic công khai và traffic nội bộ
ELB cho bạn một static DNS name, KHÔNG phải static IP. Lý do: AWS cần thay đổi hạ tầng bên dưới bất cứ lúc nào mà endpoint vẫn ổn định. Ngoại lệ duy nhất là NLB — nó có một IP tĩnh mỗi AZ và gắn được Elastic IP.
Health Checks
Health check là cơ chế sống còn: ELB gọi thử một port và một đường dẫn (thường là /health). Nếu phản hồi không phải 200 OK thì instance bị đánh dấu unhealthy và ELB ngừng gửi traffic vào đó.
Một API bị rò rỉ bộ nhớ, cứ khoảng 6 tiếng thì một instance treo và trả lỗi 502. Người dùng gặp lỗi ngẫu nhiên — lúc được lúc không, tùy request rơi vào máy nào. Bật health check trên /health: ELB phát hiện máy hỏng trong vòng ~30 giây và ngừng gửi traffic tới nó, người dùng không còn thấy lỗi trong khi đội kỹ thuật xử lý nguyên nhân gốc.
Bốn loại Load Balancer
| Loại | Năm | Tầng | Ghi chú |
|---|---|---|---|
| CLB (Classic) | 2009 | 4 & 7 | Thế hệ cũ, AWS đã ngừng khuyến nghị — đề mới hầu như không hỏi |
| ALB (Application) | 2016 | Layer 7 | HTTP, HTTPS, WebSocket |
| NLB (Network) | 2017 | Layer 4 | TCP, UDP, TLS — hiệu năng cực cao |
| GWLB (Gateway) | 2020 | Layer 3 | Gói IP, dành cho thiết bị mạng ảo |
Mọi loại đều có thể là internal (chỉ truy cập từ trong VPC) hoặc internet-facing (công khai).
SG của Load Balancer: mở port 80/443 cho 0.0.0.0/0. SG của EC2 phía sau: chỉ mở port ứng dụng từ Security Group của Load Balancer, không mở cho internet. Đây chính là kỹ thuật tham chiếu SG đã học ở Section 5.
Application Load Balancer (Layer 7)
ALB làm việc ở tầng HTTP nên nó đọc hiểu được nội dung request — đây là nguồn gốc mọi khả năng routing thông minh của nó.
Định tuyến theo bốn tiêu chí
| Theo | Ví dụ |
|---|---|
| Path trong URL | example.com/users → target group A, example.com/posts → target group B |
| Hostname | one.example.com vs other.example.com |
| Query string | example.com/users?id=123&order=false |
| HTTP header (gồm cả source IP) | Định tuyến theo header tùy ý hoặc theo IP nguồn |
ALB KHÔNG định tuyến theo vị trí địa lý của client. Muốn định tuyến theo quốc gia thì dùng Route 53 Geolocation (Section 10) hoặc CloudFront. Bốn tiêu chí ở bảng trên là tất cả những gì ALB làm được.
Target Groups — đích của traffic
| Loại target hợp lệ | Ghi chú |
|---|---|
| EC2 instances | Thường do ASG quản lý |
| ECS tasks | Có dynamic port mapping cho container |
| Lambda functions | Request HTTP được chuyển thành JSON event |
| Private IP addresses | Ví dụ server on-premise qua Direct Connect |
Không thể đăng ký một Network Load Balancer làm target của ALB. Chiều ngược lại thì được: NLB có thể trỏ tới ALB — mô hình này dùng khi cần vừa có static IP của NLB vừa có routing Layer 7 của ALB.
Health check được cấu hình ở mức target group, không phải mức load balancer.
Các tính năng khác
- Hỗ trợ HTTP, HTTPS, WebSocket và HTTP/2 — không hỗ trợ TCP thuần (đó là việc của NLB).
- Hỗ trợ redirect, phổ biến nhất là HTTP → HTTPS.
- Rất hợp với microservices và container: mỗi service một target group, ECS tự map port động.
Ứng dụng phía sau ALB chỉ thấy private IP của ALB, không thấy IP thật của client. Muốn lấy IP thật, đọc header X-Forwarded-For. Hai header họ hàng: X-Forwarded-Port (port client gọi) và X-Forwarded-Proto (giao thức client dùng).
Hệ thống có 3 dịch vụ tách rời: /api/* đi tới cụm backend Java, /admin/* đi tới cụm quản trị, còn /* còn lại đi tới web tĩnh. Một ALB duy nhất với 3 rule là đủ — trước kia mỗi ứng dụng phải một Classic Load Balancer riêng, tốn tiền gấp ba.
Hệ quả thường gặp: đội bảo mật báo log ứng dụng chỉ ghi nhận vài IP nội bộ lặp đi lặp lại, tưởng bị tấn công. Thực ra đó là IP của ALB — sửa code đọc X-Forwarded-For là log hiện đúng IP người dùng.
Network Load Balancer (Layer 4)
NLB làm việc ở tầng TCP/UDP, không đọc nội dung HTTP, nên nó nhanh hơn hẳn.
| Đặc điểm | Chi tiết |
|---|---|
| Giao thức | TCP, UDP, TLS |
| Hiệu năng | Hàng triệu request mỗi giây |
| Độ trễ | Khoảng 100 ms, so với ~400 ms của ALB |
| Địa chỉ IP | Một static IP mỗi AZ, và gắn được Elastic IP |
| Target hợp lệ | EC2 instances · private IP addresses · Application Load Balancer |
| Health check | Hỗ trợ TCP, HTTP và HTTPS |
| Chi phí | Không nằm trong free tier |
1. "Static IP" / "firewall rules" / "whitelist IP" → NLB, vì ALB chỉ có DNS name.
2. "Millions of requests per second" / "ultra-low latency" / "extreme performance" → NLB.
NLB có hỗ trợ health check HTTP và HTTPS, không chỉ TCP. Nếu ứng dụng nói HTTP và bạn đang dùng TCP health check, chỉ cần đổi health check sang HTTP — không cần chuyển sang ALB.
Công ty tích hợp với hệ thống của một ngân hàng, phía ngân hàng yêu cầu khai báo trước dải IP nguồn và không chấp nhận tên miền. Dùng ALB thì không có IP tĩnh để khai. Giải pháp: NLB gắn Elastic IP ở mỗi AZ, khai đúng những IP đó với ngân hàng, và nếu vẫn cần routing theo path thì đặt ALB phía sau NLB.
Ca khác: game server dùng UDP cho luồng dữ liệu thời gian thực — ALB không hỗ trợ UDP, buộc phải dùng NLB.
Gateway Load Balancer (Layer 3)
GWLB sinh ra cho một bài toán hẹp: triển khai và mở rộng cụm thiết bị mạng ảo của bên thứ ba — firewall, hệ thống phát hiện và ngăn chặn xâm nhập (IDS/IPS), thiết bị phân tích sâu gói tin.
| Đặc điểm | Chi tiết |
|---|---|
| Tầng hoạt động | Layer 3 — gói IP |
| Kết hợp hai vai trò | Transparent Network Gateway (một cửa vào/ra duy nhất cho mọi traffic) + Load Balancer (trải tải sang các thiết bị) |
| Giao thức | GENEVE, port 6081 |
| Target hợp lệ | EC2 instances · private IP addresses |
GENEVE / port 6081 hoặc "third-party virtual appliance" xuất hiện trong đề thì đáp án gần như chắc chắn là GWLB. Ngoài hai từ khóa đó, GWLB ít khi ra thi.
Một ngân hàng bắt buộc mọi traffic ra vào VPC phải đi qua firewall của Palo Alto để tuân thủ quy định. GWLB đứng ở giữa: mọi gói tin bị chuyển hướng qua cụm firewall, gói nào sạch mới đi tiếp tới ứng dụng. Khi lưu lượng tăng, GWLB tự trải tải sang thêm thiết bị mà không phải sửa bảng định tuyến.
Sticky Sessions
Bình thường mỗi request có thể rơi vào một máy khác nhau. Sticky session ép cùng một client luôn về đúng một instance, dựa vào cookie.
Mục đích: để người dùng không mất dữ liệu phiên làm việc.
Website chạy tốt ở môi trường dev với 1 instance, nhưng lên production với 10 instance thì người dùng cứ chuyển trang là bị bắt đăng nhập lại. Nguyên nhân: session lưu trong bộ nhớ của từng máy, request tiếp theo rơi sang máy khác nên máy đó không biết người dùng là ai. Cách chữa nhanh: bật sticky session. Cách chữa đúng về lâu dài: đưa session ra ngoài — vào ElastiCache hoặc DynamoDB — để ứng dụng thành stateless.
Hai loại cookie
| Duration-based cookie | Application-based cookie | |
|---|---|---|
| Ai tạo | Load Balancer tạo | Ứng dụng đích tạo |
| Tên cookie | AWSALB (ALB), AWSELB (CLB) | Bạn tự đặt tên cho từng target group |
| Thời hạn | Bạn cấu hình | Do ứng dụng quyết định, có thể mang thuộc tính riêng |
Ba tên AWSALB, AWSALBAPP, AWSALBTG do ELB giữ chỗ — không được dùng làm tên cookie tùy chỉnh của bạn. Quiz gốc có hẳn một câu bắt chọn tên hợp lệ trong danh sách toàn tên bị cấm.
Bật stickiness dễ gây mất cân bằng tải: một máy vô tình nhận nhiều phiên dài sẽ nặng hơn hẳn các máy khác. Đây là lý do thiết kế stateless luôn được ưu tiên.
Cross-Zone Load Balancing
Mặc định, mỗi node của load balancer trong một AZ chỉ chia traffic cho các instance trong AZ của chính nó. Bật cross-zone load balancing thì mọi node chia đều cho toàn bộ instance ở mọi AZ.
Bạn có 2 instance ở us-east-1b và 5 instance ở us-east-1e. Traffic được chia đều 50/50 cho hai AZ, nên mỗi máy ở 1b gánh 25% tổng tải, còn mỗi máy ở 1e chỉ gánh 10%. Kết quả: CPU ở 1b cao gấp 2,5 lần dù cùng loại máy. Bật cross-zone load balancing là cả 7 máy nhận đều nhau, mỗi máy khoảng 14%.
Mặc định và chi phí — bảng phải thuộc
| Loại LB | Mặc định | Phí truyền dữ liệu giữa AZ |
|---|---|---|
| ALB | Bật sẵn (tắt được ở mức target group) | Không tính phí |
| NLB | Tắt sẵn | Có tính phí nếu bật |
| GWLB | Tắt sẵn | Có tính phí nếu bật |
| CLB | Tắt sẵn | Không tính phí |
Chỉ ALB bật sẵn và miễn phí. NLB và GWLB đều tắt sẵn và tính tiền khi bật — hợp lý vì chúng thiên về hiệu năng và chi phí thấp.
SSL/TLS Certificates & SNI
Chứng chỉ SSL cho phép mã hóa traffic giữa client và load balancer (in-flight encryption). SSL là tên cũ, TLS là chuẩn hiện dùng, nhưng mọi người vẫn quen gọi là SSL.
- Load balancer dùng chứng chỉ X.509, quản lý qua ACM (AWS Certificate Manager), hoặc tự upload chứng chỉ riêng.
- Listener HTTPS phải có một chứng chỉ mặc định, và thêm được danh sách chứng chỉ phụ cho nhiều tên miền.
- Có security policy để hỗ trợ client cũ dùng phiên bản SSL/TLS đời trước.
SNI — Server Name Indication
SNI giải bài toán: nhiều chứng chỉ SSL trên cùng một listener, để một load balancer phục vụ nhiều tên miền HTTPS khác nhau.
Cách hoạt động: client nói rõ hostname muốn kết nối ngay trong bước bắt tay SSL đầu tiên, server nhờ đó chọn đúng chứng chỉ; không khớp cái nào thì trả về chứng chỉ mặc định.
SNI chỉ hoạt động với ALB, NLB và CloudFront — các thế hệ mới. Classic Load Balancer không hỗ trợ SNI: nó chỉ mang được một chứng chỉ, muốn nhiều tên miền thì phải dựng nhiều CLB.
Một ALB phục vụ ba tên miền: users.example.com, api.external.example.com, checkout.example.com, mỗi cái một chứng chỉ riêng. Nhờ SNI, cả ba dùng chung một listener HTTPS 443 thay vì phải dựng ba load balancer.
Kèm theo đó, để không ai vào được bằng HTTP: thêm listener port 80 với rule redirect HTTP sang HTTPS ngay trên ALB — không cần sửa code ứng dụng, không cần đụng tới DNS.
Connection Draining
Tính năng này có hai tên tùy loại load balancer — đề thi dùng cả hai:
| Loại LB | Tên gọi |
|---|---|
| CLB | Connection Draining |
| ALB & NLB | Deregistration Delay |
Nó là khoảng thời gian cho các request đang dở được chạy xong khi một instance đang bị gỡ khỏi target group hoặc bị đánh dấu unhealthy. Trong lúc đó, load balancer ngừng gửi request mới tới máy đó nhưng vẫn để request cũ hoàn tất.
- Giá trị từ 1 đến 3600 giây, mặc định 300 giây.
- Đặt 0 để tắt hẳn.
- Request ngắn thì nên đặt giá trị thấp để việc thay máy diễn ra nhanh.
Website bán vé đang deploy phiên bản mới lúc 22h. Có khách đang ở bước thanh toán, request mất khoảng 20 giây để xử lý xong. Nếu deregistration delay bằng 0, instance bị gỡ ngay và giao dịch đứt giữa chừng. Đặt 60 giây thì mọi giao dịch dở dang hoàn tất trước khi máy cũ biến mất.
Ngược lại, một API trả về trong 200 ms mà để mặc định 300 giây thì mỗi lần thay máy phải chờ 5 phút vô ích — nên hạ xuống khoảng 30 giây.
Auto Scaling Group Overview
ASG làm bốn việc: thêm máy khi tải tăng, bớt máy khi tải giảm, giữ số máy trong khoảng min–max, và tự thay thế instance chết. Nó cũng tự đăng ký instance mới vào load balancer.
ASG miễn phí — bạn chỉ trả tiền cho EC2 bên dưới.
Ba con số cấu hình
| Tham số | Ý nghĩa |
|---|---|
| Minimum capacity | Số máy tối thiểu luôn phải có |
| Desired capacity | Số máy ASG đang muốn duy trì — con số này tự thay đổi khi scale |
| Maximum capacity | Trần cứng — ASG không bao giờ vượt qua, bất kể tải cao đến đâu |
Desired = 3, Maximum = 3, CloudWatch Alarm báo CPU 80% vượt ngưỡng 60%. Chuyện gì xảy ra? Không có gì cả. ASG đã chạm trần maximum nên không thể thêm máy — alarm kêu nhưng vô tác dụng. Đây là lỗi cấu hình rất hay gặp ngoài đời.
Launch Template
Khuôn để tạo instance mới, gồm: AMI + instance type, EC2 User Data, EBS volume, Security Group, SSH key pair, IAM Role, thông tin mạng và subnet, và load balancer gắn kèm.
Health Check của ASG
| Kiểu | Kiểm tra gì |
|---|---|
| EC2 Status Checks (mặc định) | Máy có sống ở mức hạ tầng không |
| ELB Health Checks | Ứng dụng có trả lời đúng không |
Khi bật ELB health check và một instance bị báo unhealthy, ASG terminate instance đó và tạo máy mới thay thế — không phải "khởi động lại ứng dụng", cũng không phải "gỡ ra rồi để đấy".
Ứng dụng Java thỉnh thoảng bị treo do deadlock: tiến trình vẫn chạy nên EC2 status check vẫn báo khỏe, nhưng không trả lời request nào. Người dùng gặp lỗi mà không máy nào bị thay. Chuyển ASG sang dùng ELB health check: máy treo bị phát hiện qua endpoint /health, ASG terminate và dựng máy mới trong vài phút, hệ thống tự lành mà không cần ai trực đêm.
Scaling Policies
Bốn kiểu scaling
| Kiểu | Cách hoạt động | Dùng khi |
|---|---|---|
| Target Tracking | Bạn nêu một mục tiêu, AWS tự lo phần còn lại — ví dụ "giữ CPU trung bình quanh 40%" | Đơn giản nhất, nên chọn mặc định |
| Simple / Step Scaling | Gắn với CloudWatch Alarm: CPU > 70% thì thêm 2 máy; CPU < 30% thì bớt 1 máy | Cần kiểm soát chi tiết mức tăng giảm theo từng ngưỡng |
| Scheduled Actions | Đặt lịch trước theo giờ: "17h thứ Sáu nâng min capacity lên 10" | Biết trước quy luật tải |
| Predictive Scaling | Học từ dữ liệu lịch sử, dự báo tải rồi scale trước khi tải đến | Tải lặp theo chu kỳ ngày/tuần |
Đề mô tả một con số mục tiêu cần duy trì ("giữ số kết nối trung bình quanh 1000", "CPU quanh 40%") → Target Tracking. Đề mô tả ngưỡng kèm hành động cụ thể ("khi vượt 70% thì thêm 2 máy") → Step Scaling.
Metric nào nên dùng để scale
CPUUtilization— mức CPU trung bình toàn ASGRequestCountPerTarget— số request mỗi instance đang gánh- Average Network In / Out — hợp với workload nặng mạng
- Custom metric — bất cứ chỉ số nào bạn tự đẩy lên CloudWatch
"Scale theo số request mỗi phút tới database" — CloudWatch không có sẵn metric này. Cách làm: tạo CloudWatch Custom Metric, rồi đặt alarm trên metric đó để scale. Đáp án không phải "bật Detailed Monitoring", cũng không phải "không làm được".
Scaling Cooldown
Sau mỗi lần scale, ASG bước vào cooldown mặc định 300 giây và không thêm/bớt máy nào trong khoảng đó, để các chỉ số kịp ổn định. Nếu không có cooldown, ASG dễ rơi vào cảnh thêm máy rồi lại bớt liên tục.
Dùng AMI dựng sẵn để instance mới sẵn sàng phục vụ nhanh nhất — nhờ đó rút ngắn được cooldown. Đây là lý do golden image ở Section 7 có ý nghĩa trực tiếp với ASG.
Nền tảng học trực tuyến có quy luật rất rõ: 19h–22h mỗi tối lượng truy cập gấp 5 lần ban ngày. Cấu hình thực tế thường là kết hợp: Scheduled Action nâng min capacity lên 20 lúc 18h45 (để máy kịp khởi động trước giờ cao điểm), cộng với Target Tracking giữ CPU quanh 50% để xử lý những đêm đông bất thường. Chỉ dùng target tracking không thôi thì 19h05 người dùng vẫn gặp chậm, vì máy mới cần vài phút mới sẵn sàng.
Instance Refresh: khi đổi launch template (ví dụ dùng AMI mới), tính năng này thay dần toàn bộ instance theo tỷ lệ minimum healthy percentage bạn đặt — cách chuẩn để rollout phiên bản mới mà không mất phục vụ.
Map từ khóa & cheat sheet
| Đề nhắc đến… | Nghĩ ngay tới |
|---|---|
| "static IP", "firewall rules", "whitelist" | NLB (gắn Elastic IP) |
| "millions of requests per second", "lowest latency" | NLB |
| "route theo URL path / hostname" | ALB |
| "route theo vị trí địa lý" | Không phải ALB — Route 53 hoặc CloudFront |
| "chỉ thấy IP của load balancer trong log" | Đọc header X-Forwarded-For |
| "người dùng bị đăng xuất khi chuyển trang" | Bật Sticky Sessions (dài hạn: session ra ElastiCache) |
| "AZ này CPU cao hơn AZ kia dù traffic chia đều" | Bật Cross-Zone Load Balancing |
| "instance thỉnh thoảng crash, người dùng gặp lỗi" | Bật ELB Health Checks |
| "nhiều tên miền HTTPS trên một listener" | SNI (chỉ ALB, NLB, CloudFront) |
| "ép người dùng dùng HTTPS" | Rule redirect HTTP → HTTPS trên ALB |
| "chờ request đang dở chạy xong trước khi gỡ máy" | Deregistration Delay / Connection Draining |
| "giữ chỉ số quanh một con số mục tiêu" | Target Tracking Policy |
| "vượt ngưỡng X thì thêm N máy" | Step Scaling Policy |
| "scale theo metric AWS không có sẵn" | CloudWatch Custom Metric + Alarm |
| "GENEVE", "port 6081", "third-party appliance" | Gateway Load Balancer |
| "ASG không thêm máy dù CPU cao" | Đã chạm maximum capacity |
Cheat sheet 90 giây
- Vertical = đổi cỡ máy (database). Horizontal = đổi số máy (ASG). HA = chạy ở ≥ 2 AZ.
- ELB cho static DNS name; chỉ NLB mới có static IP và gắn được Elastic IP.
- ALB = Layer 7, HTTP/HTTPS/WebSocket, không TCP. Route theo path, hostname, query string, header — không theo geography.
- ALB target: EC2, ECS task, Lambda, private IP — không phải NLB. Ngược lại NLB trỏ được tới ALB.
- IP thật của client nằm ở header X-Forwarded-For.
- NLB: TCP/UDP, triệu request/giây, ~100 ms, health check hỗ trợ TCP, HTTP, HTTPS, không có trong free tier.
- GWLB: Layer 3, GENEVE port 6081, cho firewall/IDS của bên thứ ba.
- Sticky session dùng cookie; tên bị cấm: AWSALB, AWSALBAPP, AWSALBTG.
- Cross-zone: ALB bật sẵn + miễn phí; NLB và GWLB tắt sẵn + tính phí liên AZ.
- SNI cho nhiều chứng chỉ trên một listener — CLB không hỗ trợ.
- Deregistration Delay: 1–3600 giây, mặc định 300, đặt 0 để tắt.
- ASG miễn phí; maximum capacity là trần cứng; ELB health check fail → terminate và thay máy mới.
- Target Tracking = nêu mục tiêu. Step = ngưỡng + hành động. Scheduled = theo lịch. Predictive = dự báo.
- Cooldown mặc định 300 giây.
Sáu câu tự kiểm tra trước khi qua file quiz
1. Đổi instance từ r4.large sang r4.4xlarge gọi là gì?
2. Cần IP tĩnh để đối tác khai báo firewall. Chọn loại load balancer nào?
3. ALB định tuyến được theo những tiêu chí nào, và tiêu chí nào KHÔNG làm được?
4. Desired = 3, Max = 3, CPU lên 90%. ASG làm gì?
5. 2 máy ở AZ-a, 5 máy ở AZ-b, CPU ở AZ-a cao bất thường. Bật tính năng nào?
6. Muốn giữ số kết nối trung bình mỗi instance quanh 1000. Dùng scaling policy nào?
Đáp án: (1) Vertical scalability. (2) NLB — nó có static IP mỗi AZ và gắn được Elastic IP; ALB chỉ có DNS name. (3) Làm được: URL path, hostname, query string, HTTP header (gồm source IP). Không làm được: vị trí địa lý của client. (4) Không làm gì — đã chạm trần maximum capacity. (5) Cross-Zone Load Balancing. (6) Target Tracking Policy — có một con số mục tiêu cần duy trì.