Appearance
High Availability & Scalability (Bản gốc slide / Original slide)
1. Scalability & High Availability — Tổng quan (Overview)
- Scalability nghĩa là một ứng dụng/hệ thống có thể xử lý tải lớn hơn bằng cách thích ứng (adapt)
- Có hai loại scalability:
- Vertical Scalability (mở rộng theo chiều dọc)
- Horizontal Scalability (theo chiều ngang, = elasticity)
- Scalability liên quan nhưng khác với High Availability
- Sẽ đi sâu vào sự khác biệt qua ví dụ một call center (tổng đài)
- Scalability means that an application / system can handle greater loads by adapting
- There are two kinds of scalability:
- Vertical Scalability
- Horizontal Scalability (= elasticity)
- Scalability is linked but different to High Availability
- Let's deep dive into the distinction, using a call center as an example
2. Vertical Scalability
- Vertical scalability nghĩa là tăng kích thước (size) của instance
- Ví dụ: ứng dụng đang chạy trên
t2.micro- Scale dọc = chạy nó trên
t2.large
- Scale dọc = chạy nó trên
- Rất phổ biến cho hệ thống không phân tán (non-distributed), chẳng hạn database
- RDS, ElastiCache là các service có thể scale vertically
- Thường có giới hạn về mức scale dọc (giới hạn phần cứng)
- Vertically scalability means increasing the size of the instance
- For example, your application runs on a
t2.micro- Scaling that application vertically means running it on a
t2.large
- Scaling that application vertically means running it on a
- Vertical scalability is very common for non distributed systems, such as a database
- RDS, ElastiCache are services that can scale vertically
- There's usually a limit to how much you can vertically scale (hardware limit)
3. Horizontal Scalability
- Horizontal scalability nghĩa là tăng số lượng instance/hệ thống cho ứng dụng
- Scale ngang ngụ ý hệ thống phân tán (distributed systems)
- Rất phổ biến cho web application / ứng dụng hiện đại
- Dễ scale ngang nhờ các dịch vụ cloud như Amazon EC2
- Horizontal Scalability means increasing the number of instances / systems for your application
- Horizontal scaling implies distributed systems
- This is very common for web applications / modern applications
- It's easy to horizontally scale thanks to the cloud offerings such as Amazon EC2
4. High Availability
- High Availability thường đi đôi với horizontal scaling
- Nghĩa là chạy ứng dụng/hệ thống ở ít nhất 2 data center (== Availability Zones)
- Mục tiêu của high availability là sống sót khi mất một data center
- High availability có thể là:
- Passive (thụ động) — ví dụ RDS Multi-AZ
- Active (chủ động) — ví dụ horizontal scaling
- High Availability usually goes hand in hand with horizontal scaling
- High availability means running your application / system in at least 2 data centers (== Availability Zones)
- The goal of high availability is to survive a data center loss
- The high availability can be passive (for RDS Multi-AZ for example)
- The high availability can be active (for horizontal scaling)
5. High Availability & Scalability cho EC2 (For EC2)
- Vertical Scaling: tăng instance size (= scale up / down)
- Từ:
t2.nano— 0.5 GB RAM, 1 vCPU - Đến:
u-12tb1.metal— 12.3 TB RAM, 448 vCPU
- Từ:
- Horizontal Scaling: tăng số lượng instance (= scale out / in)
- Auto Scaling Group
- Load Balancer
- High Availability: chạy instance của cùng ứng dụng trên nhiều AZ
- Auto Scaling Group multi-AZ
- Load Balancer multi-AZ
- Vertical Scaling: Increase instance size (= scale up / down)
- From:
t2.nano– 0.5G of RAM, 1 vCPU - To:
u-12tb1.metal– 12.3 TB of RAM, 448 vCPUs
- From:
- Horizontal Scaling: Increase number of instances (= scale out / in)
- Auto Scaling Group
- Load Balancer
- High Availability: Run instances for the same application across multi AZ
- Auto Scaling Group multi AZ
- Load Balancer multi AZ
6. Load balancing là gì? (What is load balancing?)
- Load Balancer là các server làm nhiệm vụ forward traffic tới nhiều server phía sau (downstream), ví dụ các EC2 instance
- Load Balancers are servers that forward traffic to multiple servers (e.g., EC2 instances) downstream
7. Vì sao dùng Load Balancer? (Why use a load balancer?)
- Phân tán tải (spread load) trên nhiều instance phía sau
- Cung cấp một điểm truy cập duy nhất (DNS) cho ứng dụng
- Xử lý mượt mà sự cố của các instance phía sau (seamlessly handle failures)
- Health check định kỳ tới các instance
- Cung cấp SSL termination (HTTPS) cho website
- Áp dụng stickiness bằng cookie
- High availability qua nhiều zone
- Tách biệt public traffic khỏi private traffic
- Spread load across multiple downstream instances
- Expose a single point of access (DNS) to your application
- Seamlessly handle failures of downstream instances
- Do regular health checks to your instances
- Provide SSL termination (HTTPS) for your websites
- Enforce stickiness with cookies
- High availability across zones
- Separate public traffic from private traffic
8. Vì sao dùng Elastic Load Balancer? (Why use an ELB?)
- Elastic Load Balancer là một load balancer được quản lý (managed)
- AWS đảm bảo nó luôn hoạt động
- AWS lo phần upgrade, maintenance, high availability
- AWS chỉ cung cấp một số ít "nút" cấu hình (configuration knobs)
- Tự dựng load balancer riêng thì rẻ hơn nhưng tốn nhiều công sức hơn rất nhiều
- Được tích hợp với nhiều dịch vụ AWS:
- EC2, EC2 Auto Scaling Groups, Amazon ECS
- AWS Certificate Manager (ACM), CloudWatch
- Route 53, AWS WAF, AWS Global Accelerator
- An Elastic Load Balancer is a managed load balancer
- AWS guarantees that it will be working
- AWS takes care of upgrades, maintenance, high availability
- AWS provides only a few configuration knobs
- It costs less to setup your own load balancer but it will be a lot more effort on your end
- It is integrated with many AWS offerings / services:
- EC2, EC2 Auto Scaling Groups, Amazon ECS
- AWS Certificate Manager (ACM), CloudWatch
- Route 53, AWS WAF, AWS Global Accelerator
9. Health Checks
- Health Check rất quan trọng với Load Balancer
- Giúp load balancer biết các instance mà nó forward traffic tới có sẵn sàng trả lời request hay không
- Health check thực hiện trên một port và một route (thường là
/health) - Nếu response không phải 200 (OK) → instance bị coi là unhealthy (và LB ngừng gửi traffic tới nó)
- Health Checks are crucial for Load Balancers
- They enable the load balancer to know if instances it forwards traffic to are available to reply to requests
- The health check is done on a port and a route (
/healthis common) - If the response is not 200 (OK), then the instance is unhealthy
10. Mô hình OSI 7 tầng (OSI Model) — tham khảo (reference)
Nhiều dịch vụ mạng — đặc biệt là Load Balancer — được phân loại theo tầng (layer) mà chúng hoạt động trong mô hình OSI 7 tầng:
Many networking services — Load Balancers in particular — are categorized by the OSI layer they operate at:
| Tầng (Layer) | Tên (Name) | Vai trò / Ví dụ |
|---|---|---|
| 7 | Application | HTTP, HTTPS, WebSocket, DNS, FTP |
| 6 | Presentation | Encryption, Compression, SSL/TLS |
| 5 | Session | Quản lý session, authentication |
| 4 | Transport | TCP, UDP — port number |
| 3 | Network | IP address, routing |
| 2 | Data Link | MAC address, Ethernet |
| 1 | Physical | Cáp mạng, WiFi, tín hiệu vật lý |
Liên hệ với Load Balancer trên AWS:
- Application Load Balancer (ALB) → tầng 7 (Application — HTTP/HTTPS)
- Network Load Balancer (NLB) → tầng 4 (Transport — TCP/UDP)
- Gateway Load Balancer (GWLB) → tầng 3 (Network — IP Protocol)
Mapping to AWS Load Balancers:
- Application Load Balancer (ALB) → layer 7 (Application — HTTP/HTTPS)
- Network Load Balancer (NLB) → layer 4 (Transport — TCP/UDP)
- Gateway Load Balancer (GWLB) → layer 3 (Network — IP Protocol)
11. Các loại Load Balancer trên AWS (Types of load balancer on AWS)
AWS có 4 loại managed Load Balancer:
AWS has 4 kinds of managed Load Balancers:
| Load Balancer | Thế hệ / Năm | Protocol | Tầng (Layer) |
|---|---|---|---|
| Classic Load Balancer (CLB) | v1 — cũ (old) · 2009 | HTTP, HTTPS, TCP, SSL (secure TCP) | 4 & 7 |
| Application Load Balancer (ALB) | v2 — mới (new) · 2016 | HTTP, HTTPS, WebSocket | 7 |
| Network Load Balancer (NLB) | v2 — mới (new) · 2017 | TCP, TLS (secure TCP), UDP | 4 |
| Gateway Load Balancer (GWLB) | 2020 | IP Protocol (GENEVE) | 3 |
- Nhìn chung, nên dùng các load balancer thế hệ mới (ALB / NLB / GWLB) vì có nhiều tính năng hơn
- Một số load balancer có thể cấu hình là internal (private) hoặc external (public)
- Overall, it is recommended to use the newer generation load balancers as they provide more features
- Some load balancers can be setup as internal (private) or external (public) ELBs
12. Load Balancer Security Groups
Mô hình Security Group điển hình khi đặt EC2 phía sau một Load Balancer:
- Security Group của Load Balancer: cho phép HTTP (80) và HTTPS (443) từ bất kỳ đâu (
0.0.0.0/0), vì người dùng truy cập từ Internet - Security Group của Application (EC2): chỉ cho phép traffic đến từ Security Group của Load Balancer — tham chiếu SG (không phải dải IP)
- Nhờ vậy, EC2 chỉ nhận traffic đi qua Load Balancer, không ai truy cập trực tiếp EC2 được — dù IP của LB có thay đổi thì rule vẫn đúng (vì tham chiếu theo SG)
A typical Security Group setup when EC2 instances sit behind a Load Balancer:
- Load Balancer's Security Group: allows HTTP (80) and HTTPS (443) from anywhere (
0.0.0.0/0), since users come from the Internet - Application's (EC2) Security Group: allows traffic only from the Load Balancer's Security Group — referencing the SG (not an IP range)
- This way, EC2 only receives traffic through the Load Balancer; nobody can reach EC2 directly, and the rule keeps working even if the LB's IP changes (it references the SG)
Load Balancer Security Group:
| Type | Protocol | Port Range | Source | Description |
|---|---|---|---|---|
| HTTP | TCP | 80 | 0.0.0.0/0 | Allow HTTP from anywhere |
| HTTPS | TCP | 443 | 0.0.0.0/0 | Allow HTTPS from anywhere |
Application Security Group — chỉ cho phép traffic từ Load Balancer (allow traffic only from the Load Balancer):
| Type | Protocol | Port Range | Source | Description |
|---|---|---|---|---|
| HTTP | TCP | 80 | sg-054b5ff5ea02f2b6e (Load Balancer's SG) | Allow traffic only from the Load Balancer |
13. Classic Load Balancer (v1)
- Hỗ trợ listener TCP (Layer 4) và HTTP & HTTPS (Layer 7)
- Health check dựa trên TCP hoặc HTTP
- Có hostname cố định:
XXX.region.elb.amazonaws.com - Luồng: Client → CLB → EC2
- (Thế hệ cũ — AWS khuyến nghị chuyển sang ALB / NLB)
- Supports TCP (Layer 4), HTTP & HTTPS (Layer 7) listeners
- Health checks are TCP or HTTP based
- Fixed hostname:
XXX.region.elb.amazonaws.com - Flow: Client → CLB → EC2
- (Old generation — AWS recommends moving to ALB / NLB)
14. Application Load Balancer (v2)
- Application Load Balancer hoạt động ở Layer 7 (HTTP)
- Cân bằng tải tới nhiều HTTP application trên nhiều máy (target groups)
- Cân bằng tải tới nhiều application trên cùng một máy (ví dụ: containers)
- Hỗ trợ HTTP/2 và WebSocket
- Hỗ trợ redirect (ví dụ từ HTTP → HTTPS)
- Application load balancers is Layer 7 (HTTP)
- Load balancing to multiple HTTP applications across machines (target groups)
- Load balancing to multiple applications on the same machine (ex: containers)
- Support for HTTP/2 and WebSocket
- Support redirects (from HTTP to HTTPS for example)
15. Application Load Balancer (v2) — Routing & Use cases
- Routing table định tuyến tới các target group khác nhau:
- Theo path trong URL (
example.com/users&example.com/posts) - Theo hostname trong URL (
one.example.com&other.example.com) - Theo Query String / Headers (
example.com/users?id=123&order=false)
- Theo path trong URL (
- ALB rất phù hợp cho microservices & ứng dụng container (ví dụ: Docker & Amazon ECS)
- Có tính năng port mapping để redirect tới dynamic port trong ECS
- So sánh: nếu dùng Classic Load Balancer thì cần nhiều CLB — mỗi application một cái
- Routing tables to different target groups:
- Routing based on path in URL (
example.com/users&example.com/posts) - Routing based on hostname in URL (
one.example.com&other.example.com) - Routing based on Query String, Headers (
example.com/users?id=123&order=false)
- Routing based on path in URL (
- ALB are a great fit for micro services & container-based applications (example: Docker & Amazon ECS)
- Has a port mapping feature to redirect to a dynamic port in ECS
- In comparison, we'd need multiple Classic Load Balancer per application
Sơ đồ — ALB (v2) định tuyến HTTP theo path tới các Target Group:
Diagram — Application Load Balancer (v2), HTTP-based traffic routed by path to Target Groups:
16. Network Load Balancer (NLB) (v2)
- Network Load Balancer hoạt động ở Layer 4 — cho phép:
- Forward traffic TCP & UDP tới các instance
- Xử lý hàng triệu request mỗi giây
- Độ trễ cực thấp (ultra-low latency)
- NLB có một static IP cho mỗi AZ, và hỗ trợ gán Elastic IP (hữu ích khi cần whitelist một IP cụ thể)
- NLB dùng cho các workload cần hiệu năng cực cao, traffic TCP hoặc UDP
- Network Load Balancers operate at Layer 4 and allow you to:
- Forward TCP & UDP traffic to your instances
- Handle millions of requests per second
- Ultra-low latency
- NLB has one static IP per AZ, and supports assigning an Elastic IP (helpful for whitelisting a specific IP)
- NLB are used for extreme performance, TCP or UDP traffic
Target Groups của NLB có thể là:
- EC2 instances
- IP Addresses — bắt buộc là private IP
- Application Load Balancer (đặt ALB sau NLB để có static IP của NLB + routing layer 7 của ALB)
- Health check hỗ trợ các protocol TCP, HTTP và HTTPS
NLB Target Groups can be:
- EC2 instances
- IP Addresses — must be private IPs
- Application Load Balancer (put an ALB behind an NLB to combine the NLB static IP with ALB layer-7 routing)
- Health checks support the TCP, HTTP and HTTPS protocols
17. Gateway Load Balancer (GWLB)
- Dùng để triển khai, scale và quản lý một fleet các network virtual appliance của bên thứ ba trong AWS
- Ví dụ: Firewall, Intrusion Detection & Prevention System (IDS/IPS), Deep Packet Inspection, payload manipulation…
- Hoạt động ở Layer 3 (Network Layer) — làm việc với IP Packets
- Kết hợp hai chức năng:
- Transparent Network Gateway — một điểm vào/ra duy nhất (single entry/exit) cho toàn bộ traffic
- Load Balancer — phân phối traffic tới các virtual appliance
- Sử dụng giao thức GENEVE trên port 6081
- Target Groups: EC2 instances, IP Addresses (phải là private IP)
- Deploy, scale, and manage a fleet of 3rd party network virtual appliances in AWS
- Example: Firewalls, Intrusion Detection and Prevention Systems, Deep Packet Inspection, payload manipulation…
- Operates at Layer 3 (Network Layer) — works on IP Packets
- Combines the following functions:
- Transparent Network Gateway — single entry/exit for all traffic
- Load Balancer — distributes traffic to your virtual appliances
- Uses the GENEVE protocol on port 6081
- Target Groups: EC2 instances, IP Addresses (must be private IPs)
18. Sticky Sessions (Session Affinity)
- Có thể bật stickiness để cùng một client luôn được định tuyến tới cùng một instance phía sau load balancer
- Hoạt động với Classic Load Balancer, Application Load Balancer và Network Load Balancer
- Với CLB & ALB, "cookie" dùng cho stickiness có thời hạn (expiration date) do bạn kiểm soát
- Use case: đảm bảo user không mất session data (ví dụ: giỏ hàng, trạng thái đăng nhập)
- Nhược điểm: bật stickiness có thể gây mất cân bằng tải giữa các EC2 phía sau (một số instance nhận nhiều hơn)
- You can enable stickiness so that the same client is always redirected to the same instance behind a load balancer
- This works for Classic Load Balancer, Application Load Balancer, and Network Load Balancer
- For both CLB & ALB, the "cookie" used for stickiness has an expiration date you control
- Use case: make sure the user doesn't lose their session data (e.g., cart, login state)
- Downside: enabling stickiness may bring imbalance to the load over the backend EC2 instances
Sticky Sessions — Tên cookie (Cookie Names):
- Application-based Cookies
- Custom cookie
- Do target (ứng dụng) sinh ra
- Có thể chứa bất kỳ thuộc tính tùy chỉnh nào ứng dụng cần
- Tên cookie phải được chỉ định riêng cho từng target group
- Không dùng
AWSALB,AWSALBAPP,AWSALBTG(reserved cho ELB)
- Application cookie
- Do load balancer sinh ra
- Tên cookie là
AWSALBAPP
- Custom cookie
- Duration-based Cookies
- Do load balancer sinh ra
- Tên cookie là
AWSALB(ALB) hoặcAWSELB(CLB)
Sticky Sessions — Cookie Names:
- Application-based Cookies
- Custom cookie
- Generated by the target (application)
- Can include any custom attributes required by the application
- Cookie name must be specified individually for each target group
- Don't use
AWSALB,AWSALBAPP,AWSALBTG(reserved for the ELB)
- Application cookie
- Generated by the load balancer
- Cookie name is
AWSALBAPP
- Custom cookie
- Duration-based Cookies
- Generated by the load balancer
- Cookie name is
AWSALB(ALB) orAWSELB(CLB)
19. Cross-Zone Load Balancing
- Có Cross-Zone Load Balancing: mỗi node của load balancer phân phối traffic đều trên tất cả instance đã đăng ký ở mọi AZ
- Không có Cross-Zone: traffic được chia đều theo từng AZ trước, rồi mới chia cho các instance trong AZ đó → nếu số instance mỗi AZ khác nhau sẽ mất cân bằng
Mặc định & chi phí theo từng loại LB:
| Load Balancer | Mặc định | Chi phí inter-AZ |
|---|---|---|
| Application Load Balancer | Bật (có thể tắt ở mức Target Group) | Miễn phí |
| Network / Gateway Load Balancer | Tắt | Tính phí ($) nếu bật |
| Classic Load Balancer | Tắt | Miễn phí nếu bật |
- With Cross-Zone Load Balancing: each load balancer node distributes traffic evenly across all registered instances in all AZ
- Without Cross-Zone: traffic is spread per AZ first, then split among that AZ's instances → uneven if AZs have a different instance count
Defaults & cost per LB type:
| Load Balancer | Default | Inter-AZ cost |
|---|---|---|
| Application Load Balancer | Enabled (can disable at Target Group level) | Free |
| Network / Gateway Load Balancer | Disabled | Charged ($) if enabled |
| Classic Load Balancer | Disabled | Free if enabled |
20. SSL/TLS Certificates & SNI
SSL/TLS — Cơ bản:
- SSL Certificate cho phép traffic giữa client và load balancer được mã hóa khi truyền (in-flight / in-transit encryption)
- SSL = Secure Sockets Layer; TLS = Transport Layer Security (phiên bản mới hơn). Ngày nay chủ yếu dùng TLS nhưng nhiều người vẫn quen gọi là SSL
- Public SSL certificate được cấp bởi các Certificate Authority (CA): Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Let's Encrypt…
- Certificate có ngày hết hạn (bạn đặt) và phải gia hạn
SSL/TLS — Basics:
- An SSL Certificate lets traffic between clients and your load balancer be encrypted in transit (in-flight encryption)
- SSL = Secure Sockets Layer; TLS = Transport Layer Security (a newer version). Today mostly TLS is used, but people still say "SSL"
- Public SSL certificates are issued by Certificate Authorities (CA): Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Let's Encrypt…
- Certificates have an expiration date (you set) and must be renewed
Load Balancer — SSL Certificates:
- Load balancer dùng một X.509 certificate (SSL/TLS server certificate)
- Quản lý certificate bằng ACM (AWS Certificate Manager), hoặc tự upload certificate của bạn
- Với HTTPS listener:
- Phải chỉ định một default certificate
- Có thể thêm danh sách cert tùy chọn để hỗ trợ nhiều domain
- Client dùng SNI (Server Name Indication) để chỉ định hostname muốn truy cập
- Có thể chỉ định security policy để hỗ trợ phiên bản SSL/TLS cũ (legacy client)
Load Balancer — SSL Certificates:
- The load balancer uses an X.509 certificate (SSL/TLS server certificate)
- Manage certificates with ACM (AWS Certificate Manager), or upload your own
- For an HTTPS listener:
- You must specify a default certificate
- You can add an optional list of certs to support multiple domains
- Clients use SNI (Server Name Indication) to specify the hostname they reach
- You can specify a security policy to support older SSL/TLS versions (legacy clients)
SNI (Server Name Indication):
- SNI giải quyết bài toán nạp nhiều SSL certificate lên cùng một server (để phục vụ nhiều website)
- Là giao thức "mới hơn", yêu cầu client chỉ ra hostname của server đích ngay trong bước SSL handshake đầu tiên
- Server sẽ tìm đúng certificate tương ứng, hoặc trả về certificate mặc định
- Chỉ hoạt động với ALB & NLB (thế hệ mới) và CloudFront — không dùng được với CLB (thế hệ cũ)
Hỗ trợ SSL certificate theo loại ELB:
| Load Balancer | Hỗ trợ SSL certificate |
|---|---|
| Classic Load Balancer (v1) | Chỉ một SSL cert → phải dùng nhiều CLB cho nhiều hostname/cert |
| Application Load Balancer (v2) | Nhiều listener, nhiều cert — dùng SNI |
| Network Load Balancer (v2) | Nhiều listener, nhiều cert — dùng SNI |
SNI (Server Name Indication):
- SNI solves the problem of loading multiple SSL certificates onto one server (to serve multiple websites)
- It's a "newer" protocol that requires the client to indicate the hostname of the target server in the initial SSL handshake
- The server then finds the correct certificate, or returns the default one
- Only works for ALB & NLB (newer generation) and CloudFront — does NOT work for CLB (older gen)
SSL certificate support per ELB type:
| Load Balancer | SSL certificate support |
|---|---|
| Classic Load Balancer (v1) | Only one SSL cert → must use multiple CLB for multiple hostnames/certs |
| Application Load Balancer (v2) | Multiple listeners, multiple certs — uses SNI |
| Network Load Balancer (v2) | Multiple listeners, multiple certs — uses SNI |
21. Connection Draining (Deregistration Delay)
- Tên gọi theo loại LB:
- Connection Draining — cho CLB
- Deregistration Delay — cho ALB & NLB
- Là khoảng thời gian để hoàn tất các "in-flight request" (request đang xử lý dở) trong khi instance đang de-register hoặc unhealthy
- LB ngừng gửi request mới tới instance đang de-register; request mới được đưa tới các instance khác
- Giá trị từ 1 đến 3600 giây (mặc định 300 giây); có thể tắt bằng cách đặt 0
- Đặt giá trị thấp nếu các request của bạn ngắn
- Feature naming per LB type:
- Connection Draining — for CLB
- Deregistration Delay — for ALB & NLB
- The time to complete "in-flight requests" while the instance is de-registering or unhealthy
- The LB stops sending new requests to the de-registering instance; new requests go to the other instances
- Value from 1 to 3600 seconds (default 300 seconds); can be disabled by setting it to 0
- Set a low value if your requests are short
22. Auto Scaling Group (ASG) — Tổng quan (Overview)
- Trong thực tế, tải trên website/ứng dụng thay đổi liên tục; trên cloud ta có thể tạo/hủy server rất nhanh
- Mục tiêu của Auto Scaling Group (ASG):
- Scale out (thêm EC2 instance) khi tải tăng
- Scale in (bớt EC2 instance) khi tải giảm
- Đảm bảo có số instance tối thiểu (min) và tối đa (max) đang chạy
- Tự động đăng ký instance mới vào Load Balancer
- Tự tạo lại EC2 instance nếu một instance bị terminate (ví dụ: unhealthy)
- ASG miễn phí — bạn chỉ trả tiền cho các EC2 instance bên dưới
- In real life, the load on your website/app changes constantly; in the cloud you can create and destroy servers very quickly
- The goal of an Auto Scaling Group (ASG) is to:
- Scale out (add EC2 instances) to match increased load
- Scale in (remove EC2 instances) to match decreased load
- Ensure a minimum and maximum number of instances running
- Automatically register new instances to a Load Balancer
- Re-create an EC2 instance if a previous one is terminated (e.g., unhealthy)
- ASG are free — you only pay for the underlying EC2 instances
23. ASG — Attributes & CloudWatch
Auto Scaling Group Attributes:
- Một Launch Template (các "Launch Configuration" cũ đã deprecated), gồm:
- AMI + Instance Type
- EC2 User Data
- EBS Volumes
- Security Groups
- SSH Key Pair
- IAM Roles cho EC2 instance
- Network + Subnets information
- Load Balancer information
- Min Size / Max Size / Initial Capacity
- Scaling Policies
Auto Scaling — CloudWatch Alarms & Scaling:
- Có thể scale ASG dựa trên CloudWatch alarm
- Một alarm giám sát một metric (ví dụ Average CPU, hoặc custom metric)
- Các metric như Average CPU được tính trên toàn bộ instance của ASG
- Dựa trên alarm, tạo scale-out policy (tăng số instance) và scale-in policy (giảm số instance)
Auto Scaling Group Attributes:
- A Launch Template (older "Launch Configurations" are deprecated), containing:
- AMI + Instance Type
- EC2 User Data
- EBS Volumes
- Security Groups
- SSH Key Pair
- IAM Roles for your EC2 instances
- Network + Subnets information
- Load Balancer information
- Min Size / Max Size / Initial Capacity
- Scaling Policies
Auto Scaling — CloudWatch Alarms & Scaling:
- You can scale an ASG based on CloudWatch alarms
- An alarm monitors a metric (such as Average CPU, or a custom metric)
- Metrics like Average CPU are computed for the overall ASG instances
- Based on the alarm, create scale-out policies (increase instances) and scale-in policies (decrease instances)
24. ASG — Scaling Policies & Cooldowns
Dynamic Scaling:
- Target Tracking Scaling
- Đơn giản nhất để thiết lập
- Ví dụ: muốn Average CPU của ASG luôn quanh 40%
- Simple / Step Scaling
- Khi một CloudWatch alarm được kích hoạt (ví dụ CPU > 70%) → thêm 2 unit
- Khi một CloudWatch alarm được kích hoạt (ví dụ CPU < 30%) → bớt 1 unit
Scheduled Scaling:
- Dự đoán trước việc scale dựa trên pattern sử dụng đã biết
- Ví dụ: tăng min capacity lên 10 vào 17:00 thứ Sáu hằng tuần
Predictive Scaling:
- Liên tục dự báo tải và lên lịch scale trước (forecast + schedule ahead)
Dynamic Scaling:
- Target Tracking Scaling
- Simplest to set up
- Example: keep the average ASG CPU around 40%
- Simple / Step Scaling
- When a CloudWatch alarm is triggered (e.g., CPU > 70%) → add 2 units
- When a CloudWatch alarm is triggered (e.g., CPU < 30%) → remove 1 unit
Scheduled Scaling:
- Anticipate scaling based on known usage patterns
- Example: increase min capacity to 10 at 5 pm on Fridays
Predictive Scaling:
- Continuously forecast load and schedule scaling ahead of time
Các metric tốt để scale (Good metrics to scale on):
CPUUtilization— mức sử dụng CPU trung bình trên các instanceRequestCountPerTarget— đảm bảo số request trên mỗi EC2 ổn định- Average Network In / Out — nếu ứng dụng bị giới hạn bởi mạng
- Custom metric bất kỳ (đẩy lên qua CloudWatch)
Scaling Cooldowns:
- Sau mỗi lần scaling, ASG vào cooldown period (mặc định 300 giây)
- Trong cooldown, ASG không launch/terminate thêm instance (để metric ổn định lại)
- Lời khuyên: dùng AMI dựng sẵn (ready-to-use) để giảm thời gian cấu hình → phục vụ request nhanh hơn và rút ngắn cooldown
Good metrics to scale on:
CPUUtilization— average CPU utilization across your instancesRequestCountPerTarget— keep the number of requests per EC2 stable- Average Network In / Out — if your application is network-bound
- Any custom metric (pushed via CloudWatch)
Scaling Cooldowns:
- After each scaling activity, the ASG enters a cooldown period (default 300 seconds)
- During cooldown, the ASG will not launch/terminate additional instances (to let metrics stabilize)
- Advice: use a ready-to-use AMI to reduce configuration time → serve requests faster and shorten the cooldown