Launch configuration can’t be modified after creation and needs to be created new if any modification required: True/False
True
How would you add detailed monitoring on EC2 under ASG?
Basic or Detailed monitoring for the instances in the Auto Scaling group can be enabled when a launch configuration is created.
Default monitoring types:
- From AWS Console
- Via CLI or API
By default, basic monitoring is enabled when you create the launch configuration using the AWS Management Console and detailed monitoring is enabled when you create the launch configuration using the AWS CLI or an API
Desired capacity Vs Minimum Capacity
o To determine the number of instances the ASG must maintain at all times. If missing, it equals to the minimum size.
o Desired capacity is different from minimum capacity.
o An Auto Scaling group’s desired capacity is the default number of instances that should be running. A group’s minimum capacity is the fewest number of instances the group can have running
Auto Scaling groups span multiple regions: True/False?
False
What happens old instances launched via old LC, when LC config changes?
When the launch configuration for the Auto Scaling group is changed, any new instances launched use the new configuration parameters, but the existing instances are not affected.
Minimum Vs Desired Vs Maximum Capacity
MIN: This will be the minimum number of instances that can run in your auto scale group. If your scale down CloudWatch alarm is triggered, your auto scale group will never terminate instances below this number
DESIRED: If you trip a CloudWatch alarm for a scale up event, then it will notify the auto scaler to change it’s desired to a specified higher amount and the auto scaler will start an instance/s to meet that number. If you trip a CloudWatch alarm to scale down, then it will change the auto scaler desired to a specified lower number and the auto scaler will terminate instance/s to get to that number.
MAX: This will be the maximum number of instances that you can run in your auto scale group. If your scale up CloudWatch alarm stays triggered, your auto scale group will never create instances more than the maximum amount specified.
How does ALB determine the health state of each instance?
- Auto Scaling group determines the health state of each instance by periodically checking the results of EC2 instance status checks
- Auto Scaling group can be associated with a load balancer enabled to use the Elastic Load Balancing health check, Auto Scaling determines the health status of the instances by checking the results of both EC2 instance status and Elastic Load Balancing instance health.
Can we mark unhealthy instance back to healthy?
• For an unhealthy instance, the instance’s health check can be changed back to healthy manually but you will get an error if the instance is already terminating. Because the interval between marking an instance unhealthy and its actual termination is so small, attempting to set an instance’s health status back to healthy is probably useful only for a suspended group
Actions you need to take to perform Manual Scaling?
Manual scaling can be performed by:
- Changing the desired capacity limit of the Auto Scaling group
- Attaching/Detaching instances to the Auto Scaling group
Pre-requisite to attach or detach the instance in ASG?
- Instance is in the running state.
- AMI used to launch the instance must still exist.
- Instance is not a member of another Auto Scaling group.
- Instance is in the same Availability Zone as the Auto Scaling group.
- If the Auto Scaling group is associated with a load balancer, the instance and the load balancer must both be in the same VPC.
What is effect of attaching/detaching instance on desired capacity value?
- Auto Scaling increases the desired capacity of the group by the number of instances being attached. But if the number of instances being attached plus the desired capacity exceeds the maximum size of the group, the request fails.
- When Detaching instances, you have the option of decrementing the desired capacity for the Auto Scaling group by the number of instances being detached. If you choose not to decrement the capacity, Auto Scaling launches new instances to replace the ones that you detached
V.IMP*
Does Scheduled scaling support multiple Scheduled actions?
Multiple Scheduled Actions can be specified but should have unique time value and they cannot have overlapping time scheduled which will lead to its rejection.
Note: This is different to having multiple policies in Dynamic Scheduling
V.IMP*
What is role of Scheduled Actions in Scheduled Scaling?
Scheduled scaling requires configuration of Scheduled actions, which tells Auto Scaling to perform a scaling action at certain time in future, with the start time at which the scaling action should take effect, and the new minimum, maximum, and desired size the group should have
V.IMP*
2 important components of Dynamic Scaling
Auto Scaling group uses a combination of alarms & policies to determine when the conditions for scaling are met.
- An alarm is an object that watches over a single metric over a specified time period. When the value of the metric breaches the defined threshold, for the number of specified time periods the alarm performs one or more actions (such as sending messages to Auto Scaling).
- A policy is a set of instructions that tells Auto Scaling how to respond to alarm messages.
V.IMP*
Dynamic scaling process works as below
- Amazon CloudWatch monitors the specified metrics for all the instances in the Auto Scaling group
- Changes are reflected in the metrics as the demand grows or shrinks
- When the change in the metrics breaches the threshold of the CloudWatch alarm, the CloudWatch alarm performs an action. Depending on the breach, the action is a message sent to either the scale-in policy or the scale-out policy
- After the Auto Scaling policy receives the message, Auto Scaling performs the scaling activity for the Auto Scaling group.
- This process continues until you delete either the scaling policies or the Auto Scaling group
Can ASG have multiple policies attached?
Yes
Each Auto Scaling group would have at least two policies: one to scale the architecture out and another to scale the architecture in.
V.IMP*
When there are multiple policies in force at the same time, there’s a chance that each policy could instruct the Auto Scaling group to scale out (or in) at the same time. How does ASG prioritises this?
When these situations occur, Amazon EC2 Auto Scaling chooses the policy that provides the largest
capacity for both scale out and scale in (even when
the policies use different criteria for scaling out. )
Eg.if one policy terminates three instances,
another policy decreases capacity by 25 percent, and the group currently has eight instances, Amazon
EC2 Auto Scaling gives precedence to the policy that provides the largest number of instances at that
time. This results in the Auto Scaling group terminating two instances (25% of 8 = 2)
Is AS Cool Down possible during Manual Scaling?
When manually scaling the Auto Scaling group, the default is not to wait for the cooldown period, but you can override the default and honor the cooldown period.
If an instance becomes unhealthy, will AS honour Cool Down time?
If an instance becomes unhealthy, Auto Scaling does not wait for the cooldown period to complete before replacing the unhealthy instance.
What is Default Termination policy?
Default termination policy is designed to help ensure that the network architecture spans Availability Zones evenly
V.IMP*
How does Default Termination policy select AZ for instance termination? (Criteria)
- selects the AZ, in multiple AZs environment, with the most instances and at least one instance that is not protected from scale in.
- selects the AZ with instances that use the oldest launch configuration, if there are more than one AZ with same number of instances
V.IMP*
How does Default Termination policy select instance in AZ termination? (Criteria)
- terminates the unprotected instance using the oldest launch configuration, if one exists.
- terminates unprotected instances closest to the next billing hour, If multiple instances with oldest launch configuration. This helps in maximizing the use of the EC2 instances while minimizing the number of hours billed for EC2 usage.
- terminates instances at random, if more than one unprotected instance closest to the next billing hour
How does Customised Termination Policy selects AZ?
- Auto Scaling first assesses the AZs for any imbalance. If an AZ has more instances than the other AZs that are used by the group, then it applies the specified termination policy on the instances from the imbalanced AZ
- If the Availability Zones used by the group are balanced, then Auto Scaling applies the termination policy across all of the Availability Zones for the group.
