DAY-9 AWS-CSA

1] what is an auto scaling group ?

An Auto Scaling Group (ASG) is a feature in cloud computing that automatically adjusts the number of instances (virtual machines) in response to changing demand. It helps maintain application availability and optimize costs by scaling up (adding instances) when traffic increases and scaling down (removing instances) when demand decreases.

Key Features of an Auto Scaling Group:

1. Automatic Scaling – Adjusts the number of instances based on predefined conditions (e.g., CPU usage, network traffic).
2. Load Balancing – Works with a load balancer to distribute traffic evenly across instances.
3. Health Monitoring – Replaces unhealthy instances automatically.
4. Cost Optimization – Ensures you're only using the necessary amount of resources.

How It Works:

1. Define Scaling Policies – Set rules for increasing or decreasing instances.
2. Set Minimum & Maximum Limits – Define the range of instances allowed in the group.
3. Attach to a Load Balancer (Optional) – Distributes traffic among instances.
4. Monitor Performance – Cloud providers (like AWS, GCP, Azure) continuously check instance health.

Use Case Examples:

• Handling unpredictable web traffic.
• Ensuring high availability for applications.
• Managing workloads in distributed systems.

2] Auto scaling group in AWS With load balancer

In AWS, an Auto Scaling Group (ASG) works with an Elastic Load Balancer (ELB) to ensure high availability and fault tolerance for your applications. The ASG automatically scales instances up or down based on demand, while the ELB distributes incoming traffic across healthy instances.

How It Works

1. The ELB receives incoming traffic and distributes it across ASG instances.
2. ASG maintains the desired number of instances and replaces unhealthy ones.
3. If demand increases, ASG scales up (adds instances).
4. If demand decreases, ASG scales down (removes instances).
5. Health checks ensure only healthy instances receive traffic.

Benefits of ASG with ELB

? High Availability – Ensures traffic is always served, even if instances fail.

? Automatic Scaling – Adds/removes instances based on demand.

? Load Balancing – Distributes traffic evenly for better performance.

? Cost Optimization – Avoids over-provisioning and saves costs.

3] Auto Scaling Group Attributes

An Auto Scaling Group (ASG) in AWS has several attributes that control how instances are launched, managed, and scaled. These attributes define the behavior of the ASG and help optimize performance, availability, and cost efficiency.

? Summary

An Auto Scaling Group (ASG) is a powerful tool that manages EC2 instances dynamically. Its attributes control:

• Scaling behavior (min/max size, policies).
• Networking (VPC, subnets, load balancers).
• Health & monitoring (health checks, termination policies).
• Advanced settings (lifecycle hooks, instance refresh).

4] Auto Scaling Groups - Scaling Policies

Auto Scaling Groups (ASGs) in AWS automatically adjust the number of EC2 instances based on demand. Scaling policies define how instances are added or removed, ensuring cost efficiency and performance.

1?? Dynamic Scaling (Real-time Auto Scaling)

Dynamic scaling policies adjust the number of instances in response to real-time traffic changes.

?? Target Tracking Scaling

• Automatically adjusts instances to keep a specific metric (e.g., CPU utilization) at a target value.
• Works similarly to AWS Auto Scaling for DynamoDB and EC2.
• Example: Keep CPU utilization at 50%. If CPU goes above 50%, new instances are added.

? Best For: Maintaining a stable metric value over time (e.g., CPU usage, request count). ?? Example Metric:

• CPUUtilization (keeps CPU at 50%)
• RequestCountPerTarget (keeps a steady request load per instance)

?? Simple Scaling & Step Scaling

• Simple Scaling: Adds or removes instances based on CloudWatch alarms.Example: If CPU > 70% for 5 minutes → Add 1 instance.If CPU < 30% for 5 minutes → Remove 1 instance.
• Step Scaling: Adjusts the number of instances based on how much the metric exceeds or falls below thresholds.Example:If CPU > 70%, add 2 instances.If CPU > 90%, add 4 instances.If CPU < 30%, remove 2 instances.

? Best For: Gradual or tiered scaling based on workload changes. ?? Use Case: Handling sudden traffic spikes effectively.

2?? Scheduled Scaling (Time-based Scaling)

• Allows you to scale at specific times (e.g., during peak business hours).
• Example:Scale up to 5 instances at 9:00 AM.Scale down to 2 instances at 6:00 PM.

? Best For: Predictable workloads (e.g., e-commerce sales, batch jobs, office hours).

3?? Predictive Scaling (AI-driven Auto Scaling)

• Uses machine learning (ML) to analyze past traffic patterns and predict future demand.
• Automatically scales before demand spikes occur.
• Requires Amazon EC2 Auto Scaling service.

? Best For: Applications with seasonal trends or fluctuating demand (e.g., retail websites before holidays).

5] Good metrics to scale on

1?? CPU Utilization (CPUUtilization)

? Best For: Compute-heavy applications (e.g., web servers, APIs, machine learning models). ?? Scaling Strategy:

• Target Tracking: Maintain CPU usage at a set percentage (e.g., 50%).
• Step Scaling: Add/remove instances when CPU crosses thresholds.

?? Example Rule:

• If CPU > 70%, add 1 instance.
• If CPU < 30%, remove 1 instance.

2?? Request Count Per Target (RequestCountPerTarget)

? Best For: Load balancer-based scaling (e.g., ALB/NLB-backed applications). ?? Scaling Strategy:

• Ensure each instance handles a manageable number of requests.
• Works well for web apps, REST APIs, and microservices.

?? Example Rule:

• If requests per instance > 500, add 1 instance.
• If requests per instance < 100, remove 1 instance.

3?? Average Network In/Out (NetworkIn / NetworkOut)

? Best For: Applications with high network traffic (e.g., video streaming, file transfer, gaming servers). ?? Scaling Strategy:

• Scale based on total data transferred per instance.
• Useful for applications where network load is the primary bottleneck.

?? Example Rule:

• If NetworkOut > 200 MB/sec, add 1 instance.
• If NetworkIn < 50 MB/sec, remove 1 instance.

4?? Custom Metrics (CloudWatch Custom Metrics)

? Best For: Specialized scaling needs beyond built-in AWS metrics. ?? Examples:

• Queue Depth (SQS Message Count): Scale workers based on the number of pending messages.
• Database Query Latency: Scale database instances based on response times.
• Application Response Time: Scale when API response time exceeds a threshold.

?? Example Rule:

• If SQS queue depth > 1000, add 2 worker instances.
• If API response time > 200ms, add 1 instance.

6] Auto Scaling Groups - Scaling cooldowns

A scaling cooldown is a waiting period after an Auto Scaling action (scale-in or scale-out) to prevent excessive scaling and ensure the system stabilizes before triggering another scaling action.

1?? Types of Cooldowns in AWS Auto Scaling

?? Default Cooldown

• Applies after any scaling action (scale-in or scale-out).
• Default 300 seconds (5 minutes) for EC2 Auto Scaling.
• Ensures time for new instances to launch, become healthy, and start handling traffic before another scaling action occurs.

? Best For: General ASG setups without custom tuning.

?? Scaling Policy Cooldown

• Overrides the default cooldown for specific scaling policies.
• Useful when different scaling actions require different cooldown durations.

?? Example Use Case:

• Scale-out cooldown = 180 sec (faster response to traffic spikes).
• Scale-in cooldown = 600 sec (ensures instances are not removed too quickly).

? Best For: More precise scaling behavior per policy.

?? Instance Refresh Cooldown

• Used when updating instances (e.g., applying new AMI updates).
• Ensures that instances are gradually replaced without downtime.

? Best For: Rolling updates to ASG instances.

?? Warm Pool Cooldown (For Pre-Warmed Instances)

• Applies when using a warm pool (pre-started instances that can be quickly attached).
• Ensures pre-warmed instances stabilize before becoming active.

? Best For: Faster scaling by keeping pre-initialized instances ready to go.

3?? When to Adjust Cooldowns?

? Decrease cooldown time if:

• Your application can handle frequent scaling events.
• You need faster scaling to handle bursty traffic.

? Increase cooldown time if:

• Instances take longer to become stable.
• Your system experiences excessive scaling events (flapping).