High Availability and Scalability: ELB & ASG
Scalability
There are two type of scalability, vertical scalability and horizontal scalability.
Vertical scalability/scalable
It means that you are increasing the size of the instance on a more persistent level to meet workload growth.
For example, if you have a call center and your instances are the people taking the calls. We have a junior operator who can take 5 calls per minute, if we want to vertical scale the operator that means we need to hire say a senior operator who can take 10 calls per minute.
Or if we have a chain of piazza place, if we want to vertical scale our business that would mean we need to build more piazza restaurant to adopt to the need of the customer. It is more permanent.
For AWS, it would mean switching from t2.micro to t2.large to meet workload demand.
Vertical scaling is common for distributed systems like database.
Horizontal scalability/elasticity
You increase the number of instances to meet peak of workload demand.
Going back to the example of call center instead of hiring senior operator, you would just increase the number of junior operator to handle the calls.
Horizontal scaling implies distributed systems.
High availability
You run your application or system in at least 2 data center. The goal of high availability is to be able to survive through a data center loss, that you can quickly recover after one of the instances goes down by using the backup instance.
High availability can be passive, or active. Exact replica of the application or a smaller replica of the application that you can scale up after disaster recovery.
High availability & scalability for EC2
You can increase the instance size to have more hardware capability for vertical scaling.
You can increase the number of the same instance for horizontal scaling, this can be done by auto scaling group automatically with load balancer.
Finally you run those instances for same application across multiple availability zones, in case one goes down, the other EC2 instances in other availability zone will be fine, this is for high availability.
ELB
Elastic load balancer. A load balancer is a server that distribute traffic to other servers called downstream servers (EC2 instances to actually handle the request) in order to avoid overloading one instances with too many requests.
You use load balancer to spread load across multiple downstream instances. It will expose one single point of access to your application.
Failures of downstream instances can be handle easily because there is built-in health checks for ELB. it also provide SSL certificates for your websites.
AWS's Elastic load balancer is a managed one so you don't have to worry about upgrading it, making it highly availability, it is all done by AWS. Using it will cost less and you have to do less work than setting up your own load balancer.
Health checks
A way for ELB to verify whether an EC2 instance is working properly. If the instance is not working properly then load balancer will not forward traffic to that dead EC2 instances.
Health check is done on a port and a route to the EC2 instances. EX: on port 5677, endpoint /health, if there is a response that comes back from that endpoint then it is good, otherwise, it is not healthy.
Types of load balancer
There are 4 kinds of managed load balancers.
Classic load balancer
This is the old generation of the load balancer, AWS do not recommend using this load balancer anymore.
Application load balancer (ALB)
Supports HTTP, HTTPS, WebSocket.
Target group: They can be EC2 instances, ECS tasks, Lambda functions, or IP addresses (must be private, your own on premise servers). They designate a set of resources that the ALB can route traffic to.
ALB can route to multiple target groups, it doesn't just have to be one target group, you can have multiple of them. Health checks are done on target group basis.
You can route the traffic to different target groups based on path, host name, or even query strings and headers.
ALB are great for micro services & container-based application.
When you create an ALB you get a fixed hostname. In addition, the server application (the target group instances) do not see the client's IP directly, they are inserted in X-Forwraded-(For,Port,Proto) headers. This is because the load balancer is doing the request, not the client. If the application server wishes to see the client's traffic then they need to inspect those extra headers.
Network load balancer (NLB)
Supports TCP, TLS, UDP
Gateway load balancer (GWLB)
Operates at layer 3 (network layer).
Security group for load balancer
The user can access the load balancer using HTTPS/HTTP from anywhere. This means that the security group attached to the load balancer should be accepting on port 80 and 443 with IP range anywhere.
On the other hand for the EC2 instances, because it is being fronted by the load balancer, it should not be accepting any external traffics except from load balancer itself. Which means that the security group for the EC2 instances should reference the security group that the load balancer have. Remember that if you reference a security group, then any traffic that comes from entity that has the security group will be accepted. In this case, only traffic forwarded from the load balancer will be accepted by the EC2 instance.