Skip to content

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)
  • 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
  • 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
  • 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
  • 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
  • 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?)

Elastic Load BalancerELBEC2EC2 InstanceEC2EC2 InstanceEC2EC2 Instance
  • 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 (/health is common)
  • If the response is not 200 (OK), then the instance is unhealthy
ELBElastic Load BalancerEC2EC2 InstanceHealth check — HTTP, port 4567, /healthHTTP 200 (OK) → healthy

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ụ
7ApplicationHTTP, HTTPS, WebSocket, DNS, FTP
6PresentationEncryption, Compression, SSL/TLS
5SessionQuản lý session, authentication
4TransportTCP, UDP — port number
3NetworkIP address, routing
2Data LinkMAC address, Ethernet
1PhysicalCá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 BalancerThế hệ / NămProtocolTầng (Layer)
Classic Load Balancer (CLB)v1 — cũ (old) · 2009HTTP, HTTPS, TCP, SSL (secure TCP)4 & 7
Application Load Balancer (ALB)v2 — mới (new) · 2016HTTP, HTTPS, WebSocket7
Network Load Balancer (NLB)v2 — mới (new) · 2017TCP, TLS (secure TCP), UDP4
Gateway Load Balancer (GWLB)2020IP 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

UsersHTTPS / HTTPfrom anywhere (0.0.0.0/0)LOAD BALANCERELBHTTPrestricted to Load BalancerEC2

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)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:

TypeProtocolPort RangeSourceDescription
HTTPTCP800.0.0.0/0Allow HTTP from anywhere
HTTPSTCP4430.0.0.0/0Allow HTTPS from anywhere

Application Security Groupchỉ cho phép traffic từ Load Balancer (allow traffic only from the Load Balancer):

TypeProtocolPort RangeSourceDescription
HTTPTCP80sg-054b5ff5ea02f2b6e (Load Balancer's SG)Allow traffic only from the Load Balancer

13. Classic Load Balancer (v1)

  • Hỗ trợ listener TCP (Layer 4)HTTP & HTTPS (Layer 7)
  • Health check dựa trên TCP hoặc HTTP
  • 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/2WebSocket
  • 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)
  • 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)
  • 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:

WWWWWWRoute /userRoute /searchExternal ApplicationLoad Balancer (v2)ELBHTTPHTTPTarget Group — UsersHealthCheckTarget Group — SearchHealthCheck

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
WWWWWWTCP + RulesTCP + RulesExternal NetworkLoad Balancer (v2)NLBTCPTCPTarget Group — UsersHealthCheckTarget Group — SearchHealthCheck

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)
Users(source)Application(destination)traffictrafficRoute TableGWLBGENEVE 6081Target Group — 3rd party security virtual appliances

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
  • Duration-based Cookies
    • Do load balancer sinh ra
    • Tên cookie là AWSALB (ALB) hoặc AWSELB (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
  • Duration-based Cookies
    • Generated by the load balancer
    • Cookie name is AWSALB (ALB) or AWSELB (CLB)

19. Cross-Zone Load Balancing

With Cross-Zoneevenly across ALL instances (all AZ)Without Cross-Zonesplit within each ELB node's AZ505025252525AZ 1AZ 2505025255050AZ 1 (2 inst)AZ 2 (2 inst)
  • 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 BalancerMặc địnhChi phí inter-AZ
Application Load BalancerBật (có thể tắt ở mức Target Group)Miễn phí
Network / Gateway Load BalancerTắtTính phí ($) nếu bật
Classic Load BalancerTắtMiễ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 BalancerDefaultInter-AZ cost
Application Load BalancerEnabled (can disable at Target Group level)Free
Network / Gateway Load BalancerDisabledCharged ($) if enabled
Classic Load BalancerDisabledFree 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)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
UsersHTTPS (encrypted)over wwwLBX.509 cert (ACM)HTTPover private VPCEC2

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à CloudFrontkhông dùng được với CLB (thế hệ cũ)

Hỗ trợ SSL certificate theo loại ELB:

Load BalancerHỗ 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 CloudFrontdoes NOT work for CLB (older gen)

SSL certificate support per ELB type:

Load BalancerSSL 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
  • 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
Minimum CapacityDesired CapacityScale Out as neededMaximum Capacity

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 instance
  • RequestCountPerTarget — đả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 instances
  • RequestCountPerTarget — 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

Personal notes by thanhlt