[SAA + SAP] 04 ALB + ASG
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.
Access Log
Access Log is disabled by default.
It capture information relating to incoming requests to your Elastic Load Balancer.
Log are encrypted and stored in an S3 bucket and decrypted when you access them.
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.
F: Step scaling policy doesn't have cooldown period.
E: Launch configuration cannot be edit
C: Traffic is unpredicatable, scheduled scaling won't help
B: IGW has no bindwidth limit
What's the Source IP address the APP Sees?
- If you were using ALB, the application will see ALB's IP, NOT clinet IP
- If you were using NLB, depends on how you locate EC2 instances
- Instance specified by InstanceID: then application see Client IP
- Instance specified by IP Address: then application see NLB IP
SSL/TLS
