Amazon EC2 Auto Scaling helps you ensure that you have the correct number of Amazon EC2 instances available to handle the load for your application.

https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html

Autoscaling Beyond EC2 Autoscaling

https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html

Components of Autoscaling

Scaling Options

Autoscaling Group

Configuration Options

Benefits

• Adjust the workload with the varied demand

• Distribute Instances across AZ for HA

  • instance distribution

  • AZ rebalance

  • Capacity rebalancing for Spot instance type

• Optimum utilization of the resources

Lifecycle

Scale Out

• ASG launches the required number of EC2 instances, using its assigned launch template. instances start in the Pending state.

• When each instance is fully configured and passes the Amazon EC2 health checks, it is attached to the Auto Scaling group and enters the InService state.

• If your ASG is configured with ELB, it will automatically register your instance with the load balancer before it marks the instance as InService.

• The instance is counted against the desired capacity after it gets to InService stage.

Scale In

• The ASG uses its termination policy to determine which instances to terminate.

• Instances that are in the process of terminating from the ASG and shutting down enter the Terminating state, and can't be put back into service.

• If you add a lifecycle hook to your Auto Scaling group, you can perform a custom action here.

• If your ASG is configured to receive traffic from an ELB, ASG automatically deregisters the terminating instance from the load balancer before running lifecycle hooks.

Attach Instance

You can attach existing EC2 Instance which meets certain criteria to be managed by the ASG.

For an instance to be attached, it must meet the following criteria:

• The instance is in the running state with Amazon EC2.

• The AMI used to launch the instance must still exist.

• The instance is not a member of another Auto Scaling group.

• The instance is launched into one of the Availability Zones defined in your Auto Scaling group.

• If the Auto Scaling group has an attached load balancer target group or Classic Load Balancer, the instance and the load balancer must both be in the same VPC.

When you attach instances, consider the following:

• The desired capacity of the group increases by the number of instances being attached. If the number of instances being attached plus the desired capacity exceeds the maximum size of the group, the request fails.

• If you attach an instance to an Auto Scaling group that has an attached load balancer target group or Classic Load Balancer, the instance is registered with the load balancer.

Detach Instance

You can detach EC2 Instance from ASG and the instance will no longer be managed by the ASG.

When you detach instances, consider the following:

• The desired capacity of the group decreases by the number of instances being detached. If the number of instances being detached makes the desired count lower than the minimum size of the group, the request fails. To skip this behavior you can select replace flag to maintain the same desired capacity where ASG adds another EC2 Instance in replacement.

• If detach multiple instances from the same Availability Zone, Amazon EC2 Auto Scaling can rebalance the Availability Zones unless you suspend the AZRebalance process. For more information, see Suspend and resume a process for an Auto Scaling group.

• If you detach an instance from an Auto Scaling group that has an attached load balancer target group or Classic Load Balancer, the instance is deregistered from the load balancer. If connection draining (deregistration delay) is enabled for your load balancer, Amazon EC2 Auto Scaling waits for in-flight requests to complete.

Enter and Exit Standby

You can change the state of the EC2 Instance from temporary to standby mode to debug and put it back to the Inservice stage. ASG still manages the Instance even in the StandBy stage except the fact is that it doesn't receive live traffic.

Things to know when dealing with Standby:

• You put the instance into the standby state. The instance remains in this state until you exit the standby state.

• By default, the value that you specified as your desired capacity is decremented when you put an instance on standby. This prevents the launch of an additional instance while you have this instance on standby. Alternatively, you can specify that your desired capacity is not decremented.

• After you put an instance back in service, the desired capacity is incremented. If you did not decrement the capacity when you put the instance on standby, the Auto Scaling group detects that you have more instances than you need. It applies the termination policy in effect to reduce the size of the group.

• Amazon EC2 Auto Scaling does not perform health checks on instances that are in a standby state. For example, if you put a healthy instance on standby and then terminate it, Amazon EC2 Auto Scaling continues to report the instance as healthy.

Lifecycle hooks

• If you added an autoscaling:EC2_INSTANCE_LAUNCHING lifecycle hook to your Auto Scaling group, the instances move from the Pending state to the Pending:Wait state.

• After completion, the instances enter the Pending:Proceed state.

• When the instances are fully configured, they are attached to the Auto Scaling group and they enter the InService state.

• If you added an autoscaling:EC2_INSTANCE_TERMINATING lifecycle hook to your Auto Scaling group, the instances move from the Terminating state to the Terminating:Wait state.

• After completion, the instances enter the Terminating:Proceed state.

Launch Templates

Not all Amazon EC2 Auto Scaling features are available when you use launch configurations. For example, you cannot create an Auto Scaling group that launches both Spot and On-Demand Instances or that specifies multiple instance types. You must use a launch template to configure these features.

With launch templates, you can also use newer features of Amazon EC2. This includes

• Systems Manager parameters (AMI ID),

• the current generation of EBS Provisioned IOPS volumes (io2),

• EBS volume tagging,

• T2 Unlimited instances,

• Elastic Inference, and

• Dedicated Hosts

When you create a launch template, all parameters are optional. However, if a launch template does not specify an AMI, you cannot add the AMI when you create your Auto Scaling group. If you specify an AMI but no instance type, you can add one or more instance types when you create your Auto Scaling group.

Replacing Instances

Instance refresh

An instance refresh can be helpful when you have a new Amazon Machine Image (AMI) or a new user data script. To use an instance refresh, first, create a new launch template that specifies the new AMI or user data script. Then, start an instance refresh to begin updating the instances in the group immediately.

NOTE: Can cause downtime if there is only 1 EC2 Instance in the ASG, because it terminates the EC2 Instance first and then only adds after that

Replace based on maximum instance lifetime

The maximum instance lifetime specifies the maximum amount of time (in seconds) that an instance can be in service before it is terminated and replaced. A common use case might be a requirement to replace your instances on a schedule because of internal security policies or external compliance controls.

NOTE: Can cause downtime if there is only 1 EC2 Instance in the ASG, because it terminates the EC2 Instance first and then only adds after that

Scaling

Manual Scaling

You can scale in/out by using the following methods

• Update min/desired/max capacity as per the need and scale your EC2 Instances.

• Attach/Detach EC2 Instance

Dynamic Scaling

Target Tracking Autoscaling

Increase and decrease the current capacity of the group based on a Amazon CloudWatch metric and a target value.

• It will scale out the Auto Scaling group if any of the target tracking policies are ready for scale out, but will scale in only if all of the target tracking policies (with the scale-in portion enabled) are ready to scale in.

• Scaling might determine that adding 1.5 instances will decrease the CPU utilization to close to 50 percent. Because it is not possible to add 1.5 instances, AWS rounds up and adds two instances. This might decrease the CPU utilization to a value below 50 percent, but it ensures that your application has enough resources to support it. Similarly, if Scaling determines that removing 1.5 instances increases your CPU utilization to above 50 percent, it removes just one instance.

• Per-defined metrics to choose from: ALBRequestCountPerTarget, ASGAverageNetworkOut, ASGAverageNetworkIn, ASGAverageCPUUtilization.

• AWS recommends that you only use metrics that are available at one-minute intervals to help you scale faster in response to utilization changes.

Simple Autoscaling

Increase and decrease the current capacity of the group based on a single scaling adjustment, with a cooldown period between each scaling activity.

Step Autoscaling

It is similar to simple autoscaling but we can work with multiple slices of the alarm values. Increase and decrease the current capacity of the group based on a set of scaling adjustments, known as step adjustments, that vary based on the size of the alarm breach.

Scheduled Based Autoscaling

Predictive Autoscaling

Termination Policies:

Default Termination Policy

Determines which instance to terminate on the scale-in events, instance refresh and AZ balance.

• The instance in the AZ with most instances

• The instance with the older version of the launch template

• If instances have the same launch template, terminate the instance with the closed billing hour

Allocation Strategy

Terminate instance based on the lowest price, lowest priority for OnDemand Instance

Oldest Launch Template

Terminate instances that have the oldest launch template.

Oldest Launch Configurations

Terminate instances that have the oldest launch configuration.

Closest to Next Launch Hour

Terminate instances that are closest to the next billing hour.

Newest Instance

Terminate the newest instance in the group. This policy is useful when you're testing a new launch configuration but don't want to keep it in production.

Oldest Instances

Terminate the oldest instance in the group. This option is useful when you're upgrading the instances in the Auto Scaling group to a new EC2 instance type.

Custom Policy

This can be defined by using the lambda backed custom policy.

NOTE: Amazon EC2 Auto Scaling always balances instances across Availability Zones first, regardless of which termination policy is used. As a result, you might encounter situations in which some newer instances are terminated before older instances.

Suspending the ASG Process

There are certain times when we want to suspend various automatic processes that ASG conducts. For example: when we are deploying the changes to EC2 Instance we don't want to Launch a new instance and Terminate existing ones. We can achieve this by suspending the Launch and Terminate Process.

• Launch—Adds instances to the Auto Scaling group when the group scales out, or when Amazon EC2 Auto Scaling chooses to launch instances for other reasons, such as when it adds instances to a warm pool.

• Terminate—Removes instances from the Auto Scaling group when the group scales in, or when Amazon EC2 Auto Scaling chooses to terminate instances for other reasons, such as when an instance is terminated for exceeding its maximum lifetime duration or failing a health check.

• AddToLoadBalancer—Adds instances to the attached load balancer target group or Classic Load Balancer when they are launched.

• AlarmNotification—Accepts notifications from CloudWatch alarms that are associated with dynamic scaling policies.

• AZRebalance—Balances the number of EC2 instances in the group evenly across all of the specified Availability Zones when the group becomes unbalanced.

• HealthCheck—Checks the health of the instances and marks an instance as unhealthy if Amazon EC2 or Elastic Load Balancing tells Amazon EC2 Auto Scaling that the instance is unhealthy.

• InstanceRefresh—Terminates and replaces instances using the instance refresh feature.

• ReplaceUnhealthy—Terminates instances that are marked as unhealthy and then create new instances to replace them.

• ScheduledActions—Performs the scheduled scaling actions that you create or that are created for you when you create an AWS Auto Scaling scaling plan and turn on predictive scaling.