AWS Elastic Load Balancer and Auto Scaling Group - Basics

Before understanding Elastic Load Balancers(ELB) and Auto Scaling Groups we need to look at a few definitions.

Scalability: Increase or decrease a system`s performance in response to a greater or smaller load

Vertical Scaling: Changing the power of an instance by switching the type. The type might have more RAM or CPU for example. Increasing the power means to scale up, decreasing it to scale down.

Horizontal Scaling: Increase ("scale out") or decrease ("scale in") the number of AWS instances.

High Availability: Run an app in at least 2 Availabilty Zones. If there's a disaster in one of the AZs the second one is still available.

Elastic Load Balancer /ELB

An Elastic Load Balancer is a server that forwards the traffic to multiple instances. The ELB serves as a single point of access for clients. It performs health checks on the instances and forwards the traffic only to the healthy ones. ELBs can offer a high availability across Availability Zones and AWS takes care of their maintenance. You only need to configure the ELB according to your needs. Its possible to create your own custom Load Balancer, but then you have to maintain it yourself so its more time consuming.

There are four types of Load Balancers:

1. Application Load Balancer - works on layer 7 of the OSI model
2. Network Load Balancer - functions on layer 4
3. Gateway Load Balancer - layer 3, forwards traffic to 3rd Party security virtual apps. Only when the security checks pass, the traffic is forwarded to the destination
4. Classic Load Balancer (retires in 2023) - layer 4 and 7

Auto Scaling Groups / ASG

An Auto Scaling group contains EC2 instances that are treated as a group for automatic scaling and it can automatically scale in or out depending on the load. When scaling out, instances are added, when scaling in, instances are removed. New instances can be auto-registered to your Load Balancer. Unhealthy instances can be replaced by the ASG.

Scaling Strategies

There are a few scaling strategies that can be used:

• Manual scaling: change size manually
• Simple/ Step Scaling: choose threshold values for CloudWatch alarms that invoke the scaling process. E.g.: when the CPU utilization is >80%, add 2 instances
• Target tracking Scaling: specify an Amazon CloudWatch average utilization value for your app, e.g. the CPU utilization should stay at 70% for each instance
• Scheduled Scaling: E.g. each Friday at 5 p.m. add 2 instances for 4 hours.
• Predictive Scaling: uses machine learning to predict capacity requirements based on data from CloudWatch and adjusts the number of instances accordingly