Stephane Maarek의 「Ultimate AWS Certified Developer Associate 2021 - NEW!」 강의 내용 정리

1. High Availability and Scalability

Scalability means that an application/system can handle greater loads by adapting
Vertical scalability vs Horizontal scalability(=elasticity)
Scalability is related to availability but they are not exactly same

Vertical scalability

• increasing the size of the instance
• t2.micro <-> t2.large
• there’s usually a limit

Horizontal scalability

• increasing the number of instances/systems for your application
• implies distributed systems
• because of the cloud offerings such as EC2, it is easy to horizontally scale

High availability

• usually goes hand in hand with horizontal scaling
• means running your application / system in at least 2 data centers
• the goal of high availability is to survive a data center loss
• can be both passive and active

2. Elastic Load Balancing(ELB)

Load balancers are servers that forward internet traffic to multiple servers downstream

Why should we use load balancer?

• 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

Why should we use EC2 load balancer?

An ELB 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

Health Checks

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.
If the response is not 200, then the instance is unhealthy

Types of load balancer on AWS

• Classic load balancer(HTTP, HTTPS, TCP)
• Application load balancer(HTTP, HTTPS, web socket)
• Network load balancer(TCP, TLS, UDP)

You can setup internal(private) or external(public) ELBs

Classic Load Balancer

Supports TCP(layer4), HTTP and HTTPS(layer7)
Health checks are TCP or HTTP based

Application Load Balancer

Application load balancers is layer7(HTTP)
Load balancing to multiple HTTP applications across machines
Load balancing to multiple applications on the same machine
Support for HTTP/2 and web socket
Support redirects
Support route routing ➜ routing tables to different target groups:

• routing based on path in URL
• routing based on hostname in URL
• routing based on query strings, headers

ALB are great fit for micro services & container-based application(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

ALB target groups

• EC2 instances → can be managed by an auto scaling group
• ECS tasks → managed by ECS
• lambda functions
• IP addresses

Network Load Balancer

Network load balancer(layer4) allow to:

• forward TCP & UDP traffic to your instances
• handle millions of request per seconds
• less latency ~ 100ms(vs 400 ms for ALB)

Load balancer security groups

Load balancer has its security groups and EC2 instances’ security groups refer to them

Load Balancer Stickiness

If is possible to implement stickiness so that the same client is always redirected to the same instance behind a load balancer
This works for CLB and ALB
The ‘cookie’ used for stickiness has an expiration date you control
Enabling stickiness may bring imbalance to the load over the backend EC2 instances

Cross Zone Load Balancing

Each load balancer instance distributes evenly across all registered instances in all AZ

• CLB: disabled by default/no charges for inter AZ data if enabled
• ALB: always on(can’t be disabled)/no charges for inter AZ data
• NLB: disabled by default/you pay charges for inter AZ data

SSL Certificates

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

• SSL(Secure Sockets Layer): used to encrypt connections
• TLS(Transport Layer Security): newer version of SSL

Nowadays, TLS certificates are mainly used, but people still refer as SSL SSL certificates have an expirations dates Load Balancer - SSL Certificates

• the load balancer uses an X.509 certificate
• you can manage certificates using AWS Certificate Manager
• alternatively, you can create upload your own certificates
• HTTPS listener: you must specify a default certificate / you can add an optional list of certs to support multiple domains/clients can use SNI(Server Name Indication) to specify the hostname they reach

SNI

solves the problem of loading multiple SSL certificates onto one web server
requires the client to indicate the hostname of the target server in the initial SSL handshake
the server will then find the correct certificate, or return the default one
does not work for CLB

Connection Draining

Feature Naming:

• CLB: connection draining
• Target Group(for ALB, NLB): reregistration delay

Time to complete ‘in-flight requests’ while the instance is de-registering or unhealthy
Stops sending new requests to the instance which is de-registering

3. Auto Scaling Groups(ASG)

What is an ASG?

In real-life, the load on your websites and application can change and in the cloud, you can create and get rid of servers very quickly.
ASG adds EC2 instances(scale out) to mach and increased load, removes EC2 instances(scale in) to match a decreased load, ensures we have a minimum and a maximum number of machines running and automatically registers new instances to a load balancer. Having instances under an ASG means that if they get terminated for whatever reason, the ASG will automatically create new ones as replacement → EXTRA SAFETY!

Auto Scaling Alarms

It is possible to scale an ASG based on CloudWatch alarms.
An alarm monitors a metric(such as average CPU) and metrics are computed for the overall ASG instances.
It is now possible to define better auto scaling rules.

Scaling Policies

• Target Tracking Scaling → Most simple and easy to set-up
• Simple/Step Scaling → When a CloudWatch alarm is triggered
• Scheduled Actions → In case you know certain usage pattern

Scaling Cooldowns

The cool down period(default: 300 seconds) helps to ensure that your ASG doesn’t launch or terminate additional instances before the previous scaling activity takes effect