In the next few posts, I will go through some AWS service components. Today we’re going to cover:
- Elastic Load Balancer (ELB)
- EC2 Auto Scaling (AS)
ELB
Distributes incoming application or network traffic across multiple targets, such as EC2, ECS, and IP addresses, in multiple AZs
When you create a load balancer, you must specify one public subnet from at least 2 AZs. You can specify only 1 public subnet per AZ
Notice:
For automatic scaling of your compute capacity, you need another service called AWS Auto Scaling to go with your LB
Auto-scaling handles the scaling of capacity for you, so that your instances are not being overwhelmed
ELBs do not boost website performance
NLB is used for applications that need extreme network performance and static IP
Features
Accepts incoming traffic from clients and routes requests to its registered targets
Monitors the health of its registered targets and routes traffic only to healthy targets
Enable deletion protection to prevent your load balancer from being deleted accidentally (Disabled by default)
Deleting ELB won’t delete the instances registered to it
Cross Zone LB: Each LB node distributes traffic across the registered targets in all enabled AZs
Supports SSL Offloading, a feature that allows the ELB to bypass the SSL termination by removing the SSL-based encryption from the incoming traffic
3 types of LB
Application LB (ALB)
- Work at the application layer (layer 7)
- HTTP & HTTPS
- Must have >= 2 subnets
- Serve as single point of contact with client
- Listener: checks for connection requests from clients. Define default rule for each listener that has a target group, condition, and priority
- Target group routes requests to one or more registered targets. You can register a target with multiple target groups, and configure health checks on a per target group basis
Path-based / host-based routing (define host conditions / path conditions, Only ALB)
Host-based routing defines rules that forward requests to different target groups based on the host name in the host header, instead of the URL
Cross-zone LB, WebSocket support
Support for routing requests to multiple applications on a single EC2 instance
Support for registering targets by IP address, including targets outside the VPC for the LB
Supports load balancer-generated cookies only for sticky sessions
Monitor the health of each service independently
- CW metrics: retrieve statistics about data points for your LB & targets as an ordered set of time-series data ( metrics )
- CloudTrail logs: capture detailed information about the calls made to ELB API, and store them as logs in S3
- Access logs: capture detailed information about the requests made to LB and store them as logs in S3
- Request tracing: track HTTP requests
Network LB (NLB)
- Layer 4, TCP / UDP connections
- At least 1 subnet must be specified, but the recommended number is 2
- Same as ALB, single point of contact, listener, target groups
- Support for static IP addresses for the LB, or assign one Elastic IP address per subnet enabled for the LB
- Cross-zone LB disabled by default
- Same as last 3 points in ALB
- Support connections from clients over inter-region VPC peering, AWS managed VPN, and third-party VPNs
- CANNOT enable or disable AZs for a NLB after you create it
- Use Proxy Protocol v2 to send additional connection information such as the source and destination
- Automatically provides a static IP per AZ (subnet) that can be used by applications as the front-end IP of the load balancer
- If NLB is unresponsive, integration with Route 53 will remove the unavailable NLB IP address from service and direct traffic to an alternate NLB in another region
- Supports TLS termination on NLB. Additionally, NLB preserve the source IP of the clients to the back-end applications, while terminating TLS on the LB
Monitor health independently
- CW metrics & CT logs: Same as ALB
- VPC flow logs: Capture detailed information about the traffic going to and from NLB (Access logs in ALB)
Classic LB (CLB)
- Distributes incoming application traffic across multiple EC2 instances in multiple AZs
- For use with EC2 classic only. Register instances with CLB. AWS recommend using ALB / NLB instead
- Support EC2-classic, TCP/SSL listeners
- Sticky sessions using application-generated cookies
- An Internet-facing LB has a publicly resolvable DNS name, so it can route requests from clients over the Internet to the EC2 instances that are registered with the load balancer. Classic load balancers are always Internet-facing
Monitor
- CW metrics
- CT logs
- Access logs
Other
- Choose whether to make an internal LB or internet-facing LB (CLB)
- Nodes of internet-facing LB: public IPs
- Nodes of internal LB: private IPs
LB states
- Provisioning: being set up
- Active: fully set up, ready to route traffic
- Failed: cannot be set up
- ELB timeout: 60s (Backend: enable HTTP keep-alive for EC2)
- Listeners define port & protocol to listen on
- Slow start mode gives target time to warm up
- Sticky sessions route requests to the same target in a target group. You enable sticky sessions at the target group level. You can also set the duration for the stickiness of the load balancer-generated cookie, in seconds.
- Health checks verify the status of your targets
- initial
- healthy
- unhealthy
- unused
- draining
Security
- Use IAM policies to grant permissions
- Resource-level permissions, security groups (all)
- Tag-based permissions (ALB & NLB)
EC2 Auto Scaling (AS)
- Configure automatic scaling for the AWS resources quickly through a scaling plan that uses dynamic scaling and predictive scaling
- Optimized for availability, cost, and balance of availability & cost
1. Use cases
- Cyclical traffic such as high use of resources during regular business hours and low use of resources overnight
- On and off traffic patterns, such as batch processing, testing, or periodic analysis
- Variable traffic patterns, such as software for marketing campaigns with periods of spiky growth
2. Features
- Launch / terminate EC2 instances in AS groups
- Enable a DynamoDB table or a global secondary index to increase or decrease its provisioned read and write capacity to handle increases in traffic without throttling
- Dynamic Scaling: add and remove capacity for resources to maintain resource utilization at the specified target value
- Predictive Scaling: forecast future load demands by analyzing your historical records for a metric
- AS scans your environment and automatically discovers the scalable cloud resources, so you don’t have to manually identify these resources through individual service interfaces
3. AS Group
Contains a collection of EC2 instances that share similar characteristics and are treated as a logical grouping for the purposes of instance scaling and management
Use launch configuration as a template for its EC2 instances.
When you create a launch configuration, you can specify information such as the AMI ID, instance type, key pair, security groups, and block device mapping for your instances
Launch configuration: An instance configuration template that an AS group uses to launch EC2 instances, and you specify information for the instances
4. Scaling type
- Target tracking scaling: Scale a resource based on a target value for a specific CW metric
- Step scaling: Scale a resource based on a set of scaling adjustments that vary based on the size of the alarm breach (step adjustments)
- Simple scaling
- Scheduled scaling: based on date & time (If you know the exact peak hours already, then use Scheduled scaling!)
5. Cooldown period
A configurable setting that helps ensure to not launch or terminate additional instances before previous scaling activities take effect
6. Application AS
- ECS
- DynamoDB tables & global secondary index
- Aurora replicas
7. Monitoring
- Health checks
- EC2 status check (default)
- ELB health checks
- Custom
- CW metrics
- CW Events
- CT logs
- SNS notifications
8. Security
By default, a brand new IAM user has NO permissions to do anything. To grant permissions to call Auto Scaling actions, you attach an IAM policy to the IAM users or groups that require the permissions it grants.