Dynamic scaling VS Fleet management scaling
Tags: aws, autoscaling
Published: 2019-06-05 16:27:42

---
title: Dynamic scaling VS Fleet management scaling
published: true
description: 
tags: aws, auto-scaling
---

Aws Auto scaling divides into 2 categories: Fleet Management and Dynamic Scaling.

---

### Fleet management
Used for:

- Replacing unhealthy instances;
- Distributing instances among availability-zones to maximize resilience; E.g: You're running instances in us-east, so auto-scaling can provision instances in the following AZs: us-east-1a, us-east-1b, us-east-1c, us-east-1d, and us-east-1e;

---

### Dynamic scaling

Used for:
- Scaling based on cloudWatch alarm metrics or a metric type (more on that later) when a threshold is met or different measures should be taken depending on the breach of a cloudWatch alarm threshold.

#### Types of Dynamic scaling

- Simple scaling: Scales based on a single cloudwatch alarm metric, and apply the measures you define;
- Step scaling: Scales based on different levels of cloud watch alarm metrics, and apply the actions you define;
- Target tracking scaling: Scales based on a metric type, but delegates the action to be taken to AWS;

---

#### Which one to use?
That's not the right question to ask. Actually you'll be using **Fleet Management** out-of-the-box, with the possibility of configuring **Dynamic Scaling** to take some custom actions;

---

### Let's go through some exemples:

> To get to the auto-scaling configuration you should go to the `EC2` dashboard and find `Auto Scaling Groups` in the sidebar. Select one auto-scaling group and find in the tabs below the auto-scaling groups listing the one called `Scaling Policies`

**Fleet management**: An application running on an EC2 instance stops responding health check, then auto-scaling stops routing traffic to it and moves that instance to quarantine to be analyzed, and spins up another instance one to replace it;

**Dynamic scaling - Simple scaling**: You have a cloudWatch alarm that monitors EC2 instances for cpu utilization and fires an alarm whenever it goes beyond 80% for 300 seconds (5 min). Your **simple scaling policy** defines the action to be taken is to spin up 1 more instance.

![Simple scaling policy](https://thepracticaldev.s3.amazonaws.com/i/0sys39f0994rrake8oox.png)

**Dynamic scaling - Step scaling**:

You have a cloudWatch alarm that monitors EC2 instances for cpu utilization and fires an alarm whenever it goes beyond 50% for 300 seconds (5 min). Your **step scaling policy** defines the action to be taken is to:
- Spin up 1 more instance when cpu utilization is <= 50% and < 60%;
- Spin up 3 more instances when cpu utilization is <= 60% and < 70%;
- Spin up 5 more instances when cpu utilization is <= 70% and < infinity;

Keep in mind that these instances will add up, so if your cpu utilization goes progressively until 70% you'll end up having 9 EC2 instances;

![Step scaling policy](https://thepracticaldev.s3.amazonaws.com/i/0vcoj23wmy5hyoh9ljt8.png)

**Target tracking scaling**:
You want to keep the cpu utilization of your fleet at 50%, but let AWS handle how many instances should be launched or terminated in order to keep that metric.

Good to know: Aws runs algorithms and defines how to best take actions to scale out/in your EC2 instances based on the receiving demand.

**Metric types**:
- Application Load Balancer Request Count Per Target;
- Average CPU Utilization;
- Average Network In (Bytes);
- Average Network Out (Bytes);

![Target tracking scaling policy](https://thepracticaldev.s3.amazonaws.com/i/mq4s5xmg3lxl4dlh702z.png)

---

Let me know if it was all clear in the comments below or with a reaction.

---

### References:
- https://aws.amazon.com/solutions/server-fleet-management-at-scale/
- https://aws.amazon.com/blogs/compute/fleet-management-made-easy-with-auto-scaling
- https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html
- https://www.youtube.com/watch?v=WUUbOQyrnJU
- https://www.youtube.com/watch?v=srofVz6xvkE