# Scalability & High Availability

• **Scalability** means that an application / system can handle greater loads by adapting.&#x20;

**• There are two kinds of scalability:**&#x20;

&#x20;     <mark style="color:green;">**• Vertical Scalability**</mark>&#x20;

&#x20;      <mark style="color:green;">**• Horizontal Scalability (= elasticity)**</mark>&#x20;

**• Scalability is linked but different to** **High Availability**&#x20;

• Let’s deep dive into the distinction, using a call center as an example



### <mark style="color:blue;">Vertical Scalability</mark>&#x20;

**• Vertically scalability means&#x20;**<mark style="color:green;">**increasing the size**</mark>**&#x20;of the instance**&#x20;

• For example, your application runs on a t2.micro&#x20;

• Scaling that application vertically means running it on a t2.large&#x20;

• Vertical scalability is very common for non distributed systems, such as a database.&#x20;

• RDS, ElastiCache are services that can scale vertically.&#x20;

• There’s usually a limit to how much you can vertically scale (hardware limit)

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FjnNKiW93QAGjqqvQKL0n%2Fimage.png?alt=media\&token=096a3019-ea63-4bcb-8e13-159a8a94bf29)

### <mark style="color:blue;">Horizontal Scalability</mark>&#x20;

**• Horizontal Scalability means&#x20;**<mark style="color:green;">**increasing the number of instances / systems**</mark>**&#x20;for your application**&#x20;

• Horizontal scaling implies distributed systems.&#x20;

• This is very common for web applications / modern applications&#x20;

• It’s easy to horizontally scale thanks the cloud offerings such as Amazon EC2

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FrYfgetp2yWFUrgIjuqJi%2Fimage.png?alt=media\&token=6948bd8f-08dd-446e-8c90-47fca0f8f1a6)

## <mark style="color:blue;">High Availability</mark>

• High Availability usually goes hand in hand  with horizontal scaling&#x20;

**• High availability means running your application / system in at least 2 data centers** (== **Availability Zones)**&#x20;

**• The goal of high availability is to survive a data center loss**&#x20;

**• The high availability can be passive (for RDS Multi AZ for example)**&#x20;

**• The high availability can be active (for horizontal scaling)**

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2Fd7qIyT0kVZu0ZDx6fAyk%2Fimage.png?alt=media\&token=43006b20-9c52-42b1-982a-5fe2e925b382)

### <mark style="color:blue;">High Availability & Scalability For EC2</mark>&#x20;

**• Vertical Scaling: Increase instance size (= scale up / down**)&#x20;

&#x20;         • From: t2.nano - 0.5G of RAM, 1 vCPU&#x20;

&#x20;       • To: u-12tb1.metal – 12.3 TB of RAM, 448 vCPUs

**• Horizontal Scaling: Increase number of instances (= scale out / in)**&#x20;

&#x20;       • Auto Scaling Group&#x20;

&#x20;       • Load Balancer&#x20;

**• High Availability: Run instances for the same application across multi AZ**

&#x20;      • Auto Scaling Group multi AZ&#x20;

&#x20;     • Load Balancer multi AZ

##

## <mark style="color:orange;">What is load balancing</mark>

**• Load Balances are servers that forward traffic to multiple servers (e.g., EC2 instances) downstream**

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2F1GKEUDoohHQDu0yk2lJ6%2Fimage.png?alt=media\&token=4b4e9ad3-ae7d-4080-9580-e50ed8d6e879)

### <mark style="color:blue;">Why use a load balancer?</mark>&#x20;

**• Spread load across multiple downstream instances**&#x20;

**• Expose a single point of access (DNS) to your application**&#x20;

**• Seamlessly handle failures of downstream instances**&#x20;

**• Do regular health checks to your instances**&#x20;

**• Provide SSL termination (HTTPS) for your websites**&#x20;

**• Enforce stickiness with cookies**&#x20;

**• High availability across zones**&#x20;

**• Separate public traffic from private traffic**

### <mark style="color:blue;">Why use an Elastic Load Balancer?</mark>&#x20;

**• An Elastic Load Balancer is a managed load balancer**&#x20;

&#x20;      • AWS guarantees that it will be working&#x20;

&#x20;     • AWS takes care of upgrades, maintenance, high availability&#x20;

&#x20;      • AWS provides only a few configuration knobs&#x20;

**• It costs less to setup your own load balancer but it will be a lot more effort on your end**&#x20;

**• It is integrated with many AWS offerings / services**&#x20;

&#x20;    • EC2, EC2 Auto Scaling Groups, Amazon ECS

&#x20;    • AWS Certificate Manager (ACM), CloudWatch

&#x20;   • Route 53, AWS WAF, AWS Global Accelerator

## <mark style="color:blue;">Health Checks</mark>&#x20;

**• Health Checks are crucial for Load Balancers**&#x20;

**• They enable the load balancer to know if instances it forwards traffic to are available to reply to requests**&#x20;

**• The health check is done on a port and a route (/health is common)**&#x20;

**• If the response is not 200 (OK), then the instance is unhealthy**

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FpmDpPJ05Ac1oPkyIYvpD%2Fimage.png?alt=media\&token=f91b73c5-74c3-447c-a0d1-fba516db29d8)

## Types of load balancer on AWS&#x20;

• AWS has 4 kinds of managed Load Balancers&#x20;

### **• Classic Load Balancer (v1 - old generation) – 2009 – CLB**&#x20;

&#x20;      • HTTP, HTTPS, TCP, SSL (secure TCP)&#x20;

### **• Application Load Balancer (v2 - new generation) – 2016 – ALB**&#x20;

&#x20;     • HTTP, HTTPS, WebSocket&#x20;

### **• Network Load Balancer (v2 - new generation) – 2017 – NLB**&#x20;

&#x20;     •  TCP, TLS (secure TCP), UDP&#x20;

### **• Gateway Load Balancer – 2020 – GWLB**&#x20;

&#x20;    • Operates at layer 3 (Network layer) – IP Protocol&#x20;

**• Overall, it is recommended to use the newer generation load balancers as they provide more features**&#x20;

**• Some load balancers can be setup as internal (private) or external (public) ELBs**

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FSUvJnm4oLCWy8utDNgCS%2Fimage.png?alt=media\&token=66905eee-3810-45f7-b620-7ff3a34bdec2)

## <mark style="color:orange;">Classic Load Balancers (v1)</mark>

l • Supports TCP (Layer 4), HTTP & HTTPS (Layer 7)&#x20;

• Health checks are TCP or HTTP based&#x20;

• Fixed hostname XXX.region.elb.amazonaws.com

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FyOKgphtTH2MmIbA8ShAT%2Fimage.png?alt=media\&token=ff5aabcd-7baa-4897-8af3-54940d8ee42f)

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FVZQbzQRblokLRI5CghcA%2Fimage.png?alt=media\&token=2963d17e-496d-43cb-b53d-2686d7d120e1)

## <mark style="color:orange;">Application Load Balancer (v2)</mark>&#x20;

• Application load balancers is Layer 7 (HTTP)&#x20;

• Load balancing to multiple HTTP applications across machines (target groups)&#x20;

• Load balancing to multiple applications on the same machine (ex: containers)&#x20;

• Support for HTTP/2 and WebSocket&#x20;

• Support redirects (from HTTP to HTTPS for example)

**• Routing tables to different target groups:**&#x20;

&#x20;       • Routing based on path in URL (example.com/users & example.com/posts)&#x20;

&#x20;      • Routing based on hostname in URL (one.example.com & other.example.com)&#x20;

&#x20;     • Routing based on Query String, Headers (example.com/users?id=123\&order=false)&#x20;

• ALB are a great fit for micro services & container-based application (example: Docker & Amazon ECS)&#x20;

• Has a port mapping feature to redirect to a dynamic port in ECS&#x20;

• In comparison, we’d need multiple Classic Load Balancer per application

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FOdF9T4HOVfCFrpYxhWCg%2Fimage.png?alt=media\&token=de5eff43-f357-48c2-ad51-32291524550c)

### <mark style="color:blue;">Application Load Balancer (v2) Target Groups</mark>&#x20;

• EC2 instances (can be managed by an Auto Scaling Group) – HTTP&#x20;

• ECS tasks (managed by ECS itself) – HTTP&#x20;

• Lambda functions – HTTP request is translated into a JSON event&#x20;

• IP Addresses – must be private IPs&#x20;

• ALB can route to multiple target groups&#x20;

• Health checks are at the target group level

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FF81me496sayRErx1nhHt%2Fimage.png?alt=media\&token=d618f306-bae8-4443-9301-6e5a6db8d56c)

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FTNQtgr1seFQTtE4w8W0g%2Fimage.png?alt=media\&token=49146c38-2993-48c8-b140-75cd1d8800dd)

## <mark style="color:orange;">Network Load Balancer (v2)</mark>&#x20;

**• Network load balancers (Layer 4) allow to:**&#x20;

&#x20;      • Forward TCP & UDP traffic to your instances&#x20;

&#x20;      • Handle millions of request per seconds&#x20;

&#x20;      • Less latency \~100 ms (vs 400 ms for ALB)&#x20;

**• NLB has one static IP per AZ, and supports assigning Elastic IP (helpful for whitelisting specific IP)**&#x20;

**• NLB are used for extreme performance, TCP or UDP traffic**&#x20;

**• Not included in the AWS free tier**

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2F20BQzFMtf3DB6Uk3TArW%2Fimage.png?alt=media\&token=af21adb1-bbed-4e77-8f38-6af9cea99a66)

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FgEM1I7lvDrDqz6faaJRk%2Fimage.png?alt=media\&token=10f6f0a1-b5ef-45bc-ad0a-41bdd0463b55)

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FZmurcCnUWVBg9HqJq6ko%2Fimage.png?alt=media\&token=b657a06c-68cd-4a50-89ba-06dbf8364e03)

if you create Network load balancer but it is not working as unhealthy you must looking to security group because you added inbound trrafic just load balancer not others if you can change it will be working

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FshY5X4w9IcbwK1ERtjGC%2Fimage.png?alt=media\&token=69bc89b7-b829-47a4-ae02-12af926a4647)

##

## <mark style="color:orange;">Gateway Load Balancer</mark>&#x20;

• Deploy, scale, and manage a fleet of 3rd party network virtual appliances in AWS&#x20;

**• Example:** Firewalls, Intrusion Detection and Prevention Systems, Deep Packet Inspection Systems, payload manipulation, …&#x20;

• Operates at Layer 3 (Network Layer) – IP Packets&#x20;

**• Combines the following functions:**&#x20;

&#x20;       **• Transparent Network Gateway** – single entry/exit for all traffic&#x20;

&#x20;      **• Load Balancer** – distributes traffic to your virtual appliances&#x20;

**• Uses the GENEVE protocol on port 6081**

It **listens for all IP packets across all ports and forwards traffic to the target group that's specified in the listener rule**, using the GENEVE protocol on port 6081. You can add or remove targets from your load balancer as your needs change, without disrupting the overall flow of requests.&#x20;

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FoonrSR4OebMqX52cD4jv%2Fimage.png?alt=media\&token=9f49cf50-f0ec-4705-aeec-68b26c6841f9)

![\\](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FBjSBUjosKy382vaR9W6J%2Fimage.png?alt=media\&token=f1a4eb5b-2079-4558-a6f6-2b84bd082886)

## <mark style="color:orange;">Sticky Sessions (Session Affinity</mark>

**• It is possible to implement stickiness so that the same client is always redirected to the same instance behind a load balancer**&#x20;

**• This works for Classic Load Balancers & Application Load Balancers**&#x20;

**• The “cookie” used for stickiness has an expiration date you control**

&#x20;**• Use case: make sure the user doesn’t lose his session data**&#x20;

**• Enabling stickiness may bring imbalance to the load over the backend EC2 instances**

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FuJxKpfH4HFdj0IHHVGdI%2Fimage.png?alt=media\&token=258e00fb-f3e3-4be0-90bb-c8ae56df438e)![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2F8HLqvH03s5IYYCrb6Czg%2Fimage.png?alt=media\&token=05ceffe2-0cf8-41ce-a8bf-1a6681ddabec)

### <mark style="color:blue;">Sticky Sessions – Cookie Names</mark>&#x20;

### <mark style="color:blue;">**• Application-based Cookies**</mark>&#x20;

### &#x20; <mark style="color:green;">**• Custom cookie**</mark>&#x20;

&#x20;       • Generated by the target&#x20;

&#x20;       • Can include any custom attributes required by the application&#x20;

&#x20;       • Cookie name must be specified individually for each target group&#x20;

&#x20;       • Don’t use **AWSALB, AWSALBAPP, or AWSALBTG** (reserved for use by the ELB)&#x20;

### &#x20;  <mark style="color:green;">**• Application cookie**</mark>&#x20;

&#x20;        • Generated by the load balancer&#x20;

&#x20;        • Cookie name is **AWSALBAPP**&#x20;

### <mark style="color:blue;">**• Duration-based Cookies**</mark>&#x20;

**• Cookie generated by the load balancer**

&#x20;• **Cookie name is AWSALB for ALB, AWSELB for CLB**

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2Fisy6Za1uUM9WWqZzbDGG%2Fimage.png?alt=media\&token=4d8d5499-f064-4705-a188-9d5c68b8c52e)



##

## <mark style="color:orange;">Cross-Zone Load Balancing</mark>

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FRSkFWAarafaCykUIJrPp%2Fimage.png?alt=media\&token=8c80c3d4-bce0-454d-9663-e8d619d2833b)

### <mark style="color:green;">• Application Load Balancer</mark>&#x20;

&#x20;       • Always on (can’t be disabled)&#x20;

&#x20;       • No charges for inter AZ data&#x20;

### <mark style="color:green;">• Network Load Balancer</mark>&#x20;

&#x20;      • Disabled by default&#x20;

&#x20;     • You pay charges ($) for inter AZ data if enabled&#x20;

### <mark style="color:green;">• Classic Load Balancer</mark>&#x20;

&#x20;     • Disabled by default&#x20;

&#x20;     • No charges for inter AZ data if ena**bled**

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FIUCVWVtIVqHfOvzHFPt0%2Fimage.png?alt=media\&token=30cf1aff-3129-4e5b-bd61-14db1b226552)



## <mark style="color:orange;">SSL/TLS - Basics</mark>&#x20;

• An SSL Certificate allows traffic between your clients and your load balancer to be encrypted in transit (in-flight encryption)

&#x20;• SSL refers to Secure Sockets Layer, used to encrypt connections&#x20;

• TLS refers to Transport Layer Security, which is a newer version&#x20;

• Nowadays, **TLS certificates are mainly used,** but people still refer as SSL

&#x20;• Public SSL certificates are issued by Certificate Authorities (CA)&#x20;

• Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt, etc…&#x20;

**• SSL certificates have an expiration date (you set) and must be renewed**

### <mark style="color:blue;">Load Balancer - SSL Certificates</mark>

**• The load balancer uses an X.509 certificate (SSL/TLS server certificate)**&#x20;

**• You can manage certificates using ACM (AWS Certificate Manager)**&#x20;

**• You can create upload your own certificates alternatively**&#x20;

**• HTTPS listener:**&#x20;

&#x20;      • You must specify a default certificate&#x20;

&#x20;      • You can add an optional list of certs to support multiple domains&#x20;

&#x20;      • **Clients can use&#x20;**<mark style="background-color:green;">**SNI (Server Name Indication)**</mark>**&#x20;to specify the hostname they reach**&#x20;

&#x20;      • Ability to specify a security policy to support older versions of SSL / TLS (legacy clients)

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FqnddxR8eDb3Gj4oneNGw%2Fimage.png?alt=media\&token=c78f3958-2bad-4e4b-90c4-9700dc31ec19)

### <mark style="color:blue;">SSL – Server Name Indication (SNI)</mark>&#x20;

• **SNI solves the problem of loading multiple SSL certificates onto one web server (to serve multiple websites)**&#x20;

• It’s a “newer” protocol, and requires the client to indicate the hostname of the target server in the initial SSL handshake&#x20;

• The server will then find the correct certificate, or return the default one&#x20;

Note:&#x20;

&#x20;   **• Only works for ALB & NLB (newer generation), CloudFront**&#x20;

&#x20;     **• Does not work for CLB (older gen)**

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FCNyxiTn6pSF3S0ffAHcf%2Fimage.png?alt=media\&token=8d051106-ff6c-41b9-93e6-4dc2da0cde43)

## <mark style="color:blue;">**Elastic Load Balancers – SSL Certificates**</mark>&#x20;

### <mark style="color:green;">• Classic Load Balancer (v1)</mark>

&#x20;    • Support only one SSL certificate&#x20;

&#x20;     • Must use multiple CLB for multiple hostname with multiple SSL certificates&#x20;

### <mark style="color:green;">• Application Load Balancer (v2)</mark>&#x20;

&#x20;        • Supports multiple listeners with multiple SSL certificates

&#x20;         • Uses Server Name Indication (SNI) to make it work

### &#x20;<mark style="color:green;">• Network Load Balancer (v2)</mark>&#x20;

&#x20;         • Supports multiple listeners with multiple SSL certificates&#x20;

&#x20;         • Uses Server Name Indication (SNI) to make it work



## <mark style="color:orange;">Connection Draining</mark>&#x20;

#### • Feature naming

&#x20;     **• Connection Draining – for CLB**&#x20;

&#x20;      **• Deregistration Delay – for ALB & NLB**&#x20;

• Time to complete “in-flight requests” while the instance is de-registering or unhealthy

&#x20;• Stops sending new requests to the EC2 instance which is de-registering

&#x20;• Between 1 to 3600 seconds (default: 300 seconds)&#x20;

• Can be disabled (set value to 0)&#x20;

• Set to a low value if your requests are short

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FeUg1rCmCQt6CeeBNFYqN%2Fimage.png?alt=media\&token=bcf80a77-1a03-45ae-893c-04f72dfcfad0)

**Connection Draining**\
Today’s new feature sits squarely at the intersection of the activities I described above and the stream of incoming requests.

In order to provide a first-class use experience, you’d like to avoid breaking open network connections while taking an instance out of service, updating its software, or replacing it with a fresh instance that contains updated software. **Imagine each broken connection as a half-drawn web page, an aborted file download, or a failed web service call, each of which results in an unhappy user or customer.**

You can now avoid this situation by enabling the new **Connection Draining** feature for your Elastic Load Balancers. You can do this from the [AWS Management Console](https://aws.amazon.com/blogs/aws/elb-connection-draining-remove-instances-from-service-with-care/), the [AWS Command Line Interface](https://aws.amazon.com/cli/), or by calling the [**ModifyLoadBalancerAttributes**](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/APIReference/API_ModifyLoadBalancerAttributes.html) function in the [Elastic Load Balancing API](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/APIReference/Welcome.html). You simply enable the feature and enter a timeout between one second and one hour. Connection Draining is enabled by default for load balancers that are created using the Console.

In order to enable Connection Draining using the AWS Management Console you must use the new version of the EC2 console. To enable it, visit the EC2 tab, click on **Load Balancers** and look for the “cartoon bubble” in the top right corner:



## <mark style="color:orange;">What’s an Auto Scaling Group?</mark>&#x20;

• In real-life, the load on your websites and application can change&#x20;

• In the cloud, you can create and get rid of servers very quickly&#x20;

**• The goal of an Auto Scaling Group (ASG) is to:**&#x20;

&#x20;        • Scale out (add EC2 instances) to match an increased load&#x20;

&#x20;        • Scale in (remove EC2 instances) to match a decreased load&#x20;

&#x20;        • Ensure we have a minimum and a maximum number of EC2 instances running&#x20;

&#x20;        • Automatically register new instances to a load balancer&#x20;

&#x20;       • Re-create an EC2 instance in case a previous one is terminated (ex: if unhealthy)&#x20;

**• ASG are free (you only pay for the underlying EC2 instances)**

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FI2xzdtZKYbMd4Me1fg6v%2Fimage.png?alt=media\&token=e6d30da4-1a56-4e6b-8fb8-780f8397d73f)

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FJv6sQTetDPQqCyz8Zzmr%2Fimage.png?alt=media\&token=ca6bc774-0811-4f65-b270-b90cd9405dc8)

Auto Scaling Group Attributes&#x20;

**• A Launch Template (older “Launch Configurations” are deprecated)**&#x20;

&#x20;   • AMI + Instance Type&#x20;

&#x20;   • EC2 User Data&#x20;

&#x20;   • EBS Volumes&#x20;

&#x20;   • Security Groups&#x20;

&#x20;   • SSH Key Pair&#x20;

&#x20;   • IAM Roles for your EC2 Instances&#x20;

&#x20;   • Network + Subnets Information&#x20;

&#x20;   • Load Balancer Information&#x20;

**• Min Size / Max Size / Initial Capacity**&#x20;

**• Scaling Policies**

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FkN1gCoKEQXHrNgxiKOAf%2Fimage.png?alt=media\&token=7c83a8ee-3203-4953-9e40-2ce146e8d369)

### <mark style="color:blue;">Auto Scaling - CloudWatch Alarms & Scaling</mark>&#x20;

• It is possible to scale an ASG based on CloudWatch alarms

&#x20;• An alarm monitors a metric (such as Average CPU, or a custom metric)&#x20;

• Metrics such as Average CPU are computed for the overall ASG instances&#x20;

**• Based on the alarm:**&#x20;

&#x20;    **• We can create scale-out policies (increase the number of instances)**&#x20;

&#x20;      **• We can create scale-in policies (decrease the number of instances)**



## <mark style="color:blue;">Auto Scaling Groups – Dynamic Scaling Policies</mark>&#x20;

### • Target Tracking Scaling&#x20;

&#x20;      • Most simple and easy to set-up&#x20;

&#x20;      • Example: I want the average ASG CPU to stay at around 40%&#x20;

### • Simple / Step Scaling&#x20;

&#x20;    • When a CloudWatch alarm is triggered (example CPU > 70%), then add 2 units&#x20;

&#x20;    • When a CloudWatch alarm is triggered (example CPU < 30%), then remove 1&#x20;

### • Scheduled Actions&#x20;

&#x20;    • Anticipate a scaling based on known usage patterns&#x20;

&#x20;    • Example: increase the min capacity to 10 at 5 pm on Fridays

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FwSyq8Yw0mjCGEB6tLSP1%2Fimage.png?alt=media\&token=805d36df-6c3c-44ef-97f4-150ff44fd4dd)



## <mark style="color:blue;">Good metrics to scale on</mark>&#x20;

**• CPUUtilization:** Average CPU utilization across your instances&#x20;

**• RequestCountPerTarget:** to make sure the number of requests per EC2 instances is stable&#x20;

**• Average Network In / Out** (if you’re application is network bound)&#x20;

**• Any custom metric** (that you push using CloudWatch)

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FbNzYrs17VoCwldAkynQx%2Fimage.png?alt=media\&token=b943d3c3-c497-4e48-a0c6-d13aa100df1c)



### Auto Scaling Groups - Scaling Cooldowns

&#x20;• After a scaling activity happens, you are in the **cooldown period (default 300 seconds)**

&#x20;• During the cooldown period, the ASG will not launch or terminate additional instances (to allow for metrics to stabilize)&#x20;

• Advice: Use a ready-to-use AMI to reduce configuration time in order to be serving request fasters and reduce the cooldown period

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FqyVCvrPLsWxykPboSIGd%2Fimage.png?alt=media\&token=6834e74d-a5a8-451a-ac0b-767cd28d475d)



## <mark style="color:orange;">ASG for Solutions Architects</mark>&#x20;

**• ASG Default Termination Policy (simplified version):**

1. Find the AZ which has the most number of instances
2. If there are multiple instances in the AZ to choose from, delete the one with the oldest launch configuration&#x20;

**• ASG tries the balance the number of instances across AZ by default**

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2FLy9OGSwBT6FmyWzxuikM%2Fimage.png?alt=media\&token=26274174-3da1-4710-abb5-b9d1e7c74072)

### <mark style="color:orange;">ASG for Solutions Architects Lifecycle Hooks</mark>&#x20;

• By default as soon as an instance is launched in an ASG it’s in service.&#x20;

• You have the ability to perform extra steps before the instance goes in service (Pending state)

&#x20;• You have the ability to perform some actions before the instance is terminated (Terminating state)

![](https://604868167-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ9IWUW0VjkKLJPOeTIP3%2Fuploads%2F5KHvKAwgBilJGl1jFFZH%2Fimage.png?alt=media\&token=74fa3b07-6b2e-44c2-ad2d-3e23fd7f69fd)

{% embed url="https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html" %}

### <mark style="color:blue;">ASG for Solutions Architect Launch Template vs Launch Configuration</mark>&#x20;

• Both:&#x20;

• ID of the Amazon Machine Image (AMI), the instance type, a key pair, security groups, and the other parameters that you use to launch EC2 instances (tags, EC2 user-data...)&#x20;

### • Launch Configuration (legacy):&#x20;

&#x20;       • Must be re-created every time&#x20;

### **• Launch Template (newer):**&#x20;

&#x20;        • Can have multiple versions

&#x20;        • Create parameters subsets (partial configuration for re-use and inheritance)&#x20;

&#x20;        • Provision using both On-Demand and Spot instances (or a mix)&#x20;

&#x20;        • Can use T2 unlimited burst feature&#x20;

&#x20;        • Recommended by AWS going forward
