SAA
Load Balancer
- LBs can scale but not instantaneously -- contact AWS for a "warm-up"
- 4xx errors are client induced errors
- 5xx errors are application induced errors
- Load Balancer Errors 503 means at capacity or no registered target
- If the LB can't connect to your application, checkyour security groups!
- ELB access logs will log all access request for debugging
- CloudWatch etrics will give you aggregate statistics
- ELB Load Balancers provides a static DNS name
ALB
- Routing to different target group
- Health check at target group level
- ALB support HTTP / HTTPS and WebSocket as well
NLB
- Network Load balancers (Layer 4) allow to:
- Forward TCP & UDP traffic to your instances
- Handle millions of request per seconds
- Less altency 100ms (vs 400 ms for ALB)
- NLB has one static IP per AZ, and supports assigning Elastic IP (helpful for whitelisting specific IP)
- ALB has one static hostname
- NLB are used for extreme performance, TCP or UDP traffic
- For application load balancer
- For target group level settings
- With CZ Load Balancing: Each EC2 instances get even number of traffic
Gateway Load Balancer
-
Deploy, scale, and manage a fleet of 3th party network virtual appliances in AWS
- Example, Firewalls, intrusion Detection and Prevention Systems, Deep Packet Inspection Systems, payload manipulation...
- Operates at Layer 3 (Network Layer) - IP Packets
- Combines the following functions:
- Transparent Network Gateway - Single entry/exit for all traffic
- Load Balancer - distributes traffic to your virtual
- Use the GENEVE protocol on port 6081
In short, using Gateway Load balacner, will redirect the traffic transparently from Application to a 3th party Virtual appliances.
ASG
- Scaling policies can be on CPU, Networkm... nad can even be on custom metrics or based on a schedule (if you know the time patterns)
- ASGs use Launch configurations or Launch Teplates (newer)
- To update an ASG, you must provide a new launch confgiuration / launch template
- IAM role attached to an ASG will get assigned to EC2 instances
- ASG itself is free
- Having instnaces under an ASG means that if they got terminated for whatever reason, the ASG will automatically create new one as a replacement.
- Based on the Metrics to create CloudWatch alarms and send SNS topic
ASG Custom Metric
- We can auto scale based on a custom metric (ex. number of connected users)
- 1. Send Custom metric from application on EC2 to CloudWatch (PutMetric API)
- 2. Create CloudWatch alarm to react to low / high values
- 3. Use the CloudWatch alaram as the scaling policy for ASG
- After an Auto scaling action, there is a cooldown period to prevent further action
- Can create additional Cooldown for Simple scaling policy
- To achieve AZ balance
- Termiated older EC2 instanaces first in one AZ
- Choose Launch Template for better service
Application Load Balaner provide a static DNS name. Network load balancer provide IP address.
- Reason chose a wrong answer was because just thinking about detail monorning enables 1 mins intervel data collections; but there is no such metric about request pre minutes... so need to use Custom metric, so not everything is just abot time, content matters
SAP
ALB
- ALB are a great fit micro services & container-based application
- Has a port mapping feature to redirect to a dynamic port in ECS
NLB
- For NLB, you don't have Lambda as target group
- You don't need to have X-Forward-For in header, it send additional connection information such as source and destination
Stickness
- Alternative is to cache session data in ElasticCache, DynamoDB for example
ASG
- Health check should be simple
- If calling a route to communicate with DB, then it is a bad health check, because it might take too long time for waiting response, then ASG consider EC2 as unhealthy.
Auto Scaling - Updating an application
1. Same target group + Two Launch Template + Shared traffic
- Keep the ALB
- Create a new Launch Template
- Then it will double the EC2 size
- Still belong to same Target group
- All EC2 instances shared the traffic because in the same target group
- Shutdown V1 instances when V2 working fine
2. Two Target groups + split traffic
- Same the same ALB, so no cache issue on client side
- Create new Target groups
- Therefore, we can split the traffic on target group level
- Send 5% traffic to TG2 in order to test whether it is working
- Shift all traffic to V2 if confident
3. Two ALBs + Route 53
- Create new ALB
- In order to test ALB v2, we neeed to use Route 53 to split traffic
- Then it become Client based LB, it might happen that client still talks to V1, although we want it talks to V2.
- Mirgraion will be slow because of TTL, DNS, cache
- But since we have a new ALB, we can do separate manual testing against ALB2, to make sure it works fine.
