AWS: Auto Scaling 2nd Part

ASG Health Checks

Auto Scaling classifies its EC2 instances health status as either Healthy or Unhealthy.

By default, As uses EC2 Status Checks only to determince the health status of an instance.

When you hve one or more ELBs defined with the AS Group, you can configure Auto Scaling to use “both” the EC2 Health Checks and the ELB Health Checks to determine the Instances health status.

Health Check Grace period:

By default is 300 seconds

• Is the time Auto Scaling waits from the time an Instance comes into service (becomes In-Service) before checking its health status.

A value of “zero” no grace period and the instance health is checked once it is in service.

Until the grace period timer expires, any unhealthy status reported by EC2 status checks or the ELB attached to the AS Group, will not be acted upon.

After Grace period expires, Auto Scaling would consider an instance unhealthy in any of the following cases:

EC2 status checks report to Auto Scaling an instance status other than running

• If the instance status is impaired due to a host Hardware or Software Problem.

If ELB health checks are configured to be used by the Auto Scaling, then if the ELB reports the Instance as “Out-of-Service”

• If you have multiple ELBs attached to the AS Group, if any of them reports the EC2 instance status as “Out-of-Service”.

One source reporting the instance as unhealthy is enough for Auto Scaling to mark it for replacement.

AS- Unhealthy Instance Termination

Once Auto Scaling identifies an instance as unhealthy, it gets schedules for termination

• The instance will never recover its health again automatically.

During a very short time period, you can use the AWS Command (as-set-instance-health) to set the instance health back to healthy.

• If the Auto Scaling started terminating the Instance,you will get an error if you try to apply this command.

Unlike AZ Rebalancing, termination of unhealthy instances happens first, then Auto Scaling attempts to launch new instances to replace the ones terminated.

Elastic IP and EBS volumes gets detached from the terminated instances, you need to manually attach them to the new instances.

AS and Spot Instance

You can choose to use Spot instances in your launch configuration, and specify your bid price.

Auto Scaling treats the spot instance the same way it treats on-demand instances.

You can NOT mix and match on-demand with Spot instances in your AS launch configuration.

If you want to change the bid price, you have to create a new launch configuration.

If the AS tries to launch spot instances in an AZ unsuccessfully because of the market price, it will try in another AZ if its market price drops below bis price,

• If the original AZ’s spot market price drops below the bis price, then the Auto scaling process will try to re balance between the two AZs.

AS and SNS Notifications

You can configure Auto Scaling to send a SNS email notification whenever:

• An instance is launched
• An instance is Terminated
• An instance fails to launch
• An instance fails to terminate

Merging Auto Scaling Groups

Can only be done from the CLI (not AWS Console)

You can merge multiple, single AZ, Auto Scaling Groups into a single, one Multi-AZ, Auto Scaling group.

To do this:

• Re-zone one of the groups to cover/span the other AZs for the other ASGs
• Delete the other ASGs

This can be used in merging ASGs with/without ELB attached to them.

The resulting ASG must be one of the pre existing ASGs, not a new one.

AS Policy Scaling actions

Scale-Out:

• Is the process in which more EC2 instances are launched-by the scaling policy.

Scale-In:

• Is the process in which EC2 instances are terminated by the scaling policy.

It is always recommended to create a scale-in event for each scale-out event you create.

Scaling Policies

Manual Scaling

• Maintain a current number of instances all the time.
• Manually change ASG’S min/desired/max, attach/detach instances.

Cyclic Scaling

• Predictable load change.

On-demand/Dynamic Scaling

• Scaling in response to an event/alarm.

An ASG can have multiple policies attached to it at any time.

ASG- Schedule/Cyclic Scaling

Use for predictable load change (increase or decrease)

You need to configure a scheduled action(s) for a scale out at a specified date/time and to a required capacity.

You can configure this cation to happen once or at a recurring schedule.

A scheduled action must have aunique data/time,

• You can not configure two scheduled activities at the same date/time.
• You can update/edit a scheduled action after you have created it.
• You can use AWS Console or CLI for this.

ASG Dynamic/On-demand Scaling

Is scaling out, or, in response to an alarm (demand)

An alarm is an object that watches over a single metric (CPU utilization, memory, network in/out… etc)

You need to have a scale-out and scale-in policy configured, which will instruct Auto Scaling what to do in response to Alarms.

You can use Cloud Watch to monitor and generate the Alarms.

Simple scaling:

• Single adjustment (up or down) in response to an alarm.
• Waits for a cool down timer to expire before responding to more alarms.

Cool down Period:

Is the period of time auto scaling waits after a scaling activity (launching a new instance or terminating one instance) until the effect of the scaling activity becomes visible

Default is 300 seconds, the time during which ASG will not respond to any additional alarms.

It is not supported for scheduled scaling or step on-demand scaling.

Step Scaling:

Multiple steps/ adjustments.

Does not support/wait for a cool down timer.

• Can respond to multiple alarms and initiate multiple scaling activities.

Supports a warm-up timer

• The time it will take a newly launched instance to be ready and contribute to the watched metric

Warm-up period:

• The period of time before which a newly created EC2 instance by ASG, using step scaling, is not considered/counted toward the ASG metrics.

For Simple or Step scaling, a scaling adjustment can’t change the capacity of the group above the maximum group size or below the minimum group size.

ASG Monitoring

AWS EC2 service sends EC2 metrics to cloud watch about the ASG instances

• Basic Monitoring (Every 5 minutes enabled by efault- free of charge)
• You can enable detailed monitoring (Every 1 minute- chargeable)

When the launch configuration is done by AWS CLI, detailed monitoring for EC2 instances in enabled by default.

When enabled, Auto Scaling service sends to Cloud watch aggregate metrics about the AG Group itself.

• Every minute by default (once enabled)

If you want to change the instance monitoring from basic to detailed (using AWS console), you have to create a new a new Launch configuration and use that for the AS Group

• newly launched instances will then use the updated monitoring settings

You have now two settings that need to match:

AS policy alarm settings for cloud watch (CPU utilization cehcking for CPU utilization)

• Ex: If CPU utilization is above 75% for one min, then scale-out

The actual Cloud Watch metric monitoring frequency for the EC2 service itself (Cloud Watch revieving EC2 Status Checks from the EC2 service)

• EC2 CPU metrics are sent to Cloud Watch every 5 minutes (via EC2 status checks)

The above two need to match or else, Cloud Watch alarm monitoring will do 4 reads and will not find any data and with the 5th, it will find the metric information.

Ex: If the EC2 monitoring is set to default (basic or 5 min), then set your ASG Alarm period to 300 seconds.

If the EC2 monitoring is detailed (1 min), then set your ASG alarm to 60 seconds.

Avoid to have ASG alarm doing 60 seconds when the EC2 monitoring is set to basic.

Finally, done with ASG and In next blog, I will start with Database Services.