84. ASG

ASG = Auto Scaling Groups
Scalability means an application/ system can handle greater loads by adapting to new conditions. In real life the load on websites and application can change. In the cloud, we can create and get rid of servers very quickly. The goal of ASG is to:
i) Scale out(add EC2 instances) to match an increased load
ii) Scale in(remove EC2 instances) to match an decreased load
iii) Ensure to have a min and max number of machines running.
iv) Automatically register new instances to a load balancer
v) Replace unhealthy instances
Cost savings: Only run at an optimal capacity
ASG offers the capacity to scale-out and scale-in by adding or removing instances based on demand.

Minimum size >> Actual size/ Desired capacity >> Maximum size

Two types of scalability: Vertical scalability and Horizontal scalability (also called elasticity). Scalability is going to be linked but different to high availability. High Availability means applications running at least in two AZs to survive a data center loss.

Vertical Scalability Horizontal Scalability
Increase the size of an instance (scale up/ down) Increase the number instances/ systems for applications (scale out/ in). Scale out = add
Example: A junior developer being promoted to senior developer and can handle more work load. Example: Hiring multiple junior developers in a team
In AWS if your application runs on t2.micro then upgrading to t2.large
Very common for non distributed systems such as database This implies distributed systems and very common for web applications/ modern applications
There’s usually a limit to how much we can vertically scale (hardware limit) Easy to scale horizontally
ASG, ELB
Auto Scaling has three components:

Groups Configuration Templates Scaling Options
Logical component to put EC2 instances. Webserver group or Application group or DB group etc. Groups uses a launch template or a launch configuration as a configuration template for its EC2 instances. We can specify information such as AMI ID, instance type, key pair, security groups and block device mapping for EC2 instances. Scaling options provides several ways to scale Auto Scaling groups. For example, we can configure a group to scale based on the occurrence of specified conditions (dynamic scaling) or on a schedule.
Five types of Scaling Options:

Maintain current instance levels at all times Scale manually Scheduled sacling or Scale based on a schedule Scale based on demand Predictive scaling
We can configure Auto Scaling group to maintain a specified number of running instances at all times. To maintain current instance levels, EC2 Auto Scaling performs a periodic health check on running instances within an Auto Scaling group. When EC2 Auto Scaling finds an unhealthy instance, it terminates that instance and launches a new one. Manual scaling is the most basic way to scale your resources, where you specify only the change in the maximum, minimum or desired capacity of your Auto Scaling group. EC2 Auto Scaling manages the process of creating or terminating instances to maintain the updated capacity. Scaling actions are performed automatically as a function of date and time. Something like scaling 10 instances on every Monday morning at 9AM. This is useful when we know exactly when to increase or decrease the number of instances in a group, simply because the need arises on a predictable schedule. A more advanced way to scale your resources – using scaling policies which lets you define parameters that control the scaling process. For example, lets say you have a web application that currently runs on two instances and you want CPU utilization of the Auto Scaling group to stay at around 50% when the load on the application changes. This method is useful for scaling in response to changing conditions, when we dont know when those conditions will change. We can set up EC2 Auto Scaling to respond. Use Amazon EC2 Auto Scaling and AWS Auto Scaling to scale resources across multiple services. AWS Auto Scaling can help you maintain optimal availability and performance by combining predictive scaling and dynamic scaling (proactive & reactive approaches) to scale your EC2 capacity faster. Predictive scaling is based on previous performance when we need scaling options.

Scalability Elasticity Agility
Ability to accommodate larger load by making hardware stronger (scale up), or by adding nodes (scale in) Once the system is scalable, elasticity means that there will be some ‘auto-scaling’ so that the system can scale based on the load. This is cloud friendly, pay per use, match demand and optimize costs. Not related to scalability or elasticity. New IT resources are only a click away, which means that you reduce the time to make those resources available to developers from weeks to just minutes.
Questions:
1. What AWS best practice is recommended for creating fault tolerant systems?
A. vertical scaling
B. Elastic IP (EIP)
C. security groups
D. horizontal scaling
E. RedShift
Answer (D)

Question 1:
You have set up an Auto Scaling group to increase the availability of your infrastructure. However, due to a configuration issue, the group was unable to launch the instance for more than 30 hours, even if the Auto Scaling configuration criteria were met.
Given this situation, what would Auto scaling’s action/reaction be?
Options:
A. Auto Scaling will continue to try launching an instance for up to 48 hours
B. Auto Scaling stops the startup process
C. Auto Scaling begins the startup process in another AZ
D. Auto Scaling notifies CloudWatch when it fails to start
Answer: B
Explanation
If Auto Scaling encounters a problem when launching an instance, Auto Scaling will suspend processes running within that group and this can be restarted later on at any time. You would use this time to analyze configuration issues. Therefore, option 2 is the correct answer.

Question 2:
A company runs an application on six web application servers in an Amazon EC2 Auto Scaling group in a single Availability Zone. The application is fronted by an Application Load Balancer (ALB). A Solutions Architect needs to modify the infrastructure to be highly available without making any modifications to the application.
Which architecture should the Solutions Architect choose to enable high availability?
Options:
A. Create an Auto Scaling group to launch three instances across each of two Regions
B. Modify the Auto Scaling group to use two instances across each of three Availability Zones
C. Create an Amazon CloudFront distribution with a custom origin across multiple Regions
D. Create a launch template that can be used to quickly create more instances in another Region
Answer: B
Explanation
The only thing that needs to be changed in this scenario to enable HA is to split the instances across multiple Availability Zones. The architecture already uses Auto Scaling and Elastic Load Balancing so there is plenty of resilience to failure. Once the instances are running across multiple AZs there will be AZ-level fault tolerance as well.
CORRECT: “Modify the Auto Scaling group to use two instances across each of three Availability Zones” is the correct answer.
INCORRECT: “Create an Amazon CloudFront distribution with a custom origin across multiple Regions” is incorrect. CloudFront is not used to create HA for your application, it is used to accelerate access to media content.
INCORRECT: “Create a launch template that can be used to quickly create more instances in another Region” is incorrect. Multi-AZ should be enabled rather than multi-Region.
INCORRECT: “Create an Auto Scaling group to launch three instances across each of two Regions” is incorrect. HA can be achieved within a Region by simply enabling more AZs in the ASG. An ASG cannot launch instances in multiple Regions.

Question 3:
A company hosts a multiplayer game on AWS. The application uses Amazon EC2 instances in a single Availability Zone and users connect over Layer 4. Solutions Architect has been tasked with making the architecture highly available and also more cost-effective.
How can the solutions architect best meet these requirements? (Select TWO.)
A. Configure an Auto Scaling group to add or remove instances in the Availability Zone automatically
B. Configure an Auto Scaling group to add or remove instances in multiple Availability Zones automatically
C. Configure a Network Load Balancer in front of the EC2 instances
D. Increase the number of instances and use smaller EC2 instance types
E. Configure an Application Load Balancer in front of the EC2 instances
Answer: B & C
Explanation
The solutions architect must enable high availability for the architecture and ensure it is cost-effective. To enable high availability an Amazon EC2 Auto Scaling group should be created to add and remove instances across multiple availability zones.
In order to distribute the traffic to the instances the architecture should use a Network Load Balancer which operates at Layer 4. This architecture will also be cost-effective as the Auto Scaling group will ensure the right number of instances are running based on demand.
CORRECT: “Configure a Network Load Balancer in front of the EC2 instances” is a correct answer.
CORRECT: “Configure an Auto Scaling group to add or remove instances in multiple Availability Zones automatically” is also a correct answer.
INCORRECT: “Increase the number of instances and use smaller EC2 instance types” is incorrect as this is not the most cost-effective option. Auto Scaling should be used to maintain the right number of active instances.
INCORRECT: “Configure an Auto Scaling group to add or remove instances in the Availability Zone automatically” is incorrect as this is not highly available as it’s a single AZ.
INCORRECT: “Configure an Application Load Balancer in front of the EC2 instances” is incorrect as an ALB operates at Layer 7 rather than Layer 4.

Question 4:
The payroll department at a company initiates several computationally intensive workloads on EC2 instances at a designated hour on the last day of every month. The payroll department has noticed a trend of severe performance lag during this hour. The engineering team has figured out a solution by using Auto Scaling Group for these EC2 instances and making sure that 10 EC2 instances are available during this peak usage hour. For normal operations only 2 EC2 instances are enough to cater to the workload.
As a solutions architect, which of the following steps would you recommend to implement the solution?
Options:
A. Configure your Auto Scaling group by creating a scheduled action that kicks-off at the designated hour on the last day of the month. Set the desired capacity of instances to 10. This causes the scale-out to happen before peak traffic kicks in at the designated hour
B. Configure your Auto Scaling group by creating a scheduled action that kicks-off at the designated hour on the last day of the month. Set the min count as well as the max count of instances to 10. This causes the scale-out to happen before peak traffic kicks in at the designated hour
C. Configure your Auto Scaling group by creating a target tracking policy and setting the instance count to 10 at the designated hour. This causes the scale-out to happen before peak traffic kicks in at the designated hour
D. Configure your Auto Scaling group by creating a simple tracking policy and setting the instance count to 10 at the designated hour. This causes the scale-out to happen before peak traffic kicks in at the designated hour
Answer: A
Explanation
Correct option:
Configure your Auto Scaling group by creating a scheduled action that kicks-off at the designated hour on the last day of the month. Set the desired capacity of instances to 10. This causes the scale-out to happen before peak traffic kicks in at the designated hour
Scheduled scaling allows you to set your own scaling schedule. For example, let’s say that every week the traffic to your web application starts to increase on Wednesday, remains high on Thursday, and starts to decrease on Friday. You can plan your scaling actions based on the predictable traffic patterns of your web application. Scaling actions are performed automatically as a function of time and date.
A scheduled action sets the minimum, maximum, and desired sizes to what is specified by the scheduled action at the time specified by the scheduled action. For the given use case, the correct solution is to set the desired capacity to 10. When we want to specify a range of instances, then we must use min and max values.
Incorrect options:
Configure your Auto Scaling group by creating a scheduled action that kicks-off at the designated hour on the last day of the month. Set the min count as well as the max count of instances to 10. This causes the scale-out to happen before peak traffic kicks in at the designated hour – As mentioned earlier in the explanation, only when we want to specify a range of instances, then we must use min and max values. As the given use-case requires exactly 10 instances to be available during the peak hour, so we must set the desired capacity to 10. Hence this option is incorrect.
Configure your Auto Scaling group by creating a target tracking policy and setting the instance count to 10 at the designated hour. This causes the scale-out to happen before peak traffic kicks in at the designated hour
Configure your Auto Scaling group by creating a simple tracking policy and setting the instance count to 10 at the designated hour. This causes the scale-out to happen before peak traffic kicks in at the designated hour
Target tracking policy or simple tracking policy cannot be used to effect a scaling action at a certain designated hour. Both these options have been added as distractors.

Question 5:
A social gaming startup has its flagship application hosted on a fleet of EC2 servers running behind an Elastic Load Balancer. These servers are part of an Auto Scaling Group. 90% of the users start logging into the system at 6 pm every day and continue till midnight. The engineering team at the startup has observed that there is a significant performance lag during the initial hour from 6 pm to 7 pm. The application is able to function normally thereafter.
As a solutions architect, which of the following steps would you recommend addressing the performance bottleneck during that initial hour of traffic spike?
A. Configure your Auto Scaling group by creating a scheduled action that kicks-off before 6 pm. This causes the scale-out to happen even before peak traffic kicks in at 6 pm
B. Configure your Auto Scaling group by creating a lifecycle hook that kicks-off before 6 pm. This causes the scale-out to happen even before peak traffic kicks in at 6 pm
C. Configure your Auto Scaling group by creating a target tracking policy. This causes the scale-out to happen even before peak traffic kicks in at 6 pm
D. Configure your Auto Scaling group by creating a step scaling policy. This causes the scale-out to happen even before peak traffic kicks in at 6 pm
Answer: A
Explanation
Correct option:
Configure your Auto Scaling group by creating a scheduled action that kicks-off before 6 pm. This causes the scale-out to happen even before peak traffic kicks in at 6 pm
The scheduled action tells the Amazon EC2 Auto Scaling group to perform a scaling action at specified times. To create a scheduled scaling action, you specify the start time when the scaling action should take effect, and the new minimum, maximum, and desired sizes for the scaling action. For the given use-case, the engineering team can create a daily scheduled action to kick-off before 6 pm which would cause the scale-out to happen even before peak traffic kicks in at 6 pm. Hence this is the correct option.
Incorrect options:
Configure your Auto Scaling group by creating a lifecycle hook that kicks-off before 6 pm. This causes the scale-out to happen even before peak traffic kicks in at 6 pm – Auto Scaling group lifecycle hooks enable you to perform custom actions as the Auto Scaling group launches or terminates instances. For example, you could install or configure software on newly launched instances, or download log files from an instance before it terminates. Therefore, lifecycle hooks cannot cause a scale-out to happen at a specified time. Hence this option is incorrect.
Configure your Auto Scaling group by creating a target tracking policy. This causes the scale-out to happen even before peak traffic kicks in at 6 pm – With target tracking scaling policies, you choose a scaling metric and set a target value. Application Auto Scaling creates and manages the CloudWatch alarms that trigger the scaling policy and calculates the scaling adjustment based on the metric and the target value. Target tracking policy cannot cause a scale-out to happen at a specified time. Hence this option is incorrect.
Configure your Auto Scaling group by creating a step scaling policy. This causes the scale-out to happen even before peak traffic kicks in at 6 pm – With step scaling, you choose scaling metrics and threshold values for the CloudWatch alarms that trigger the scaling process as well as define how your scalable target should be scaled when a threshold is in breach for a specified number of evaluation periods. Step scaling policy cannot cause a scale-out to happen at a specified time. Hence this option is incorrect.
In addition, both the target tracking as well as step scaling policies entail a lag wherein the instances will be provisioned only when the underlying CloudWatch alarms go off. Therefore we would still see performance lag during some part of the initial hour.

Question 6:
The DevOps team at an e-commerce company wants to perform some maintenance work on a specific EC2 instance that is part of an Auto Scaling group using a step scaling policy. The team is facing a maintenance challenge – every time the team deploys a maintenance patch, the instance health check status shows as out of service for a few minutes. This causes the Auto Scaling group to provision another replacement instance immediately.
As a solutions architect, which are the MOST time/resource efficient steps that you would recommend so that the maintenance work can be completed at the earliest? (Select two)
Options:
A. Take a snapshot of the instance, create a new AMI and then launch a new instance using this AMI. Apply the maintenance patch to this new instance and then add it back to the Auto Scaling Group by using the manual scaling policy. Terminate the earlier instance that had the maintenance issue
B. Put the instance into the Standby state and then update the instance by applying the maintenance patch. Once the instance is ready, you can exit the Standby state and then return the instance to service
C. Delete the Auto Scaling group and apply the maintenance fix to the given instance. Create a new Auto Scaling group and add all the instances again using the manual scaling policy
D. Suspend the ReplaceUnhealthy process type for the Auto Scaling group and apply the maintenance patch to the instance. Once the instance is ready, you can manually set the instance’s health status back to healthy and activate the ReplaceUnhealthy process type again
E. Suspend the ScheduledActions process type for the Auto Scaling group and apply the maintenance patch to the instance. Once the instance is ready, you can you can manually set the instance’s health status back to healthy and activate the ScheduledActions process type again
Answer: B & D
Explanation
Correct options:
Put the instance into the Standby state and then update the instance by applying the maintenance patch. Once the instance is ready, you can exit the Standby state and then return the instance to service – You can put an instance that is in the InService state into the Standby state, update some software or troubleshoot the instance, and then return the instance to service. Instances that are on standby are still part of the Auto Scaling group, but they do not actively handle application traffic.
Suspend the ReplaceUnhealthy process type for the Auto Scaling group and apply the maintenance patch to the instance. Once the instance is ready, you can manually set the instance’s health status back to healthy and activate the ReplaceUnhealthy process type again – The ReplaceUnhealthy process terminates instances that are marked as unhealthy and then creates new instances to replace them. Amazon EC2 Auto Scaling stops replacing instances that are marked as unhealthy. Instances that fail EC2 or Elastic Load Balancing health checks are still marked as unhealthy. As soon as you resume the ReplaceUnhealthly process, Amazon EC2 Auto Scaling replaces instances that were marked unhealthy while this process was suspended.
Incorrect options:
Take a snapshot of the instance, create a new AMI and then launch a new instance using this AMI. Apply the maintenance patch to this new instance and then add it back to the Auto Scaling Group by using the manual scaling policy. Terminate the earlier instance that had the maintenance issue – Taking the snapshot of the existing instance to create a new AMI and then creating a new instance in order to apply the maintenance patch is not time/resource optimal, hence this option is ruled out.
Delete the Auto Scaling group and apply the maintenance fix to the given instance. Create a new Auto Scaling group and add all the instances again using the manual scaling policy – It’s not recommended to delete the Auto Scaling group just to apply a maintenance patch on a specific instance.
Suspend the ScheduledActions process type for the Auto Scaling group and apply the maintenance patch to the instance. Once the instance is ready, you can you can manually set the instance’s health status back to healthy and activate the ScheduledActions process type again – Amazon EC2 Auto Scaling does not execute scaling actions that are scheduled to run during the suspension period. This option is not relevant to the given use-case.

Question 07:
The engineering team at a data analytics company has observed that its flagship application functions at its peak performance when the underlying EC2 instances have a CPU utilization of about 50%. The application is built on a fleet of EC2 instances managed under an Auto Scaling group. The workflow requests are handled by an internal Application Load Balancer that routes the requests to the instances.
As a solutions architect, what would you recommend so that the application runs near its peak performance state?
Options:
A. Configure the Auto Scaling group to use step scaling policy and set the CPU utilization as the target metric with a target value of 50%
B. Configure the Auto Scaling group to use simple scaling policy and set the CPU utilization as the target metric with a target value of 50%
C. Configure the Auto Scaling group to use target tracking policy and set the CPU utilization as the target metric with a target value of 50%
D. Configure the Auto Scaling group to use a Cloudwatch alarm triggered on a CPU utilization threshold of 50%
Answer: C
Explanation
Correct option:
Configure the Auto Scaling group to use target tracking policy and set the CPU utilization as the target metric with a target value of 50%
An Auto Scaling group contains a collection of Amazon EC2 instances that are treated as a logical grouping for the purposes of automatic scaling and management. An Auto Scaling group also enables you to use Amazon EC2 Auto Scaling features such as health check replacements and scaling policies.
With target tracking scaling policies, you select a scaling metric and set a target value. Amazon EC2 Auto Scaling creates and manages the CloudWatch alarms that trigger the scaling policy and calculates the scaling adjustment based on the metric and the target value. The scaling policy adds or removes capacity as required to keep the metric at, or close to, the specified target value.
For example, you can use target tracking scaling to:
Configure a target tracking scaling policy to keep the average aggregate CPU utilization of your Auto Scaling group at 50 percent. This meets the requirements specified in the given use-case and therefore, this is the correct option.
Incorrect options:
Configure the Auto Scaling group to use step scaling policy and set the CPU utilization as the target metric with a target value of 50%
Configure the Auto Scaling group to use simple scaling policy and set the CPU utilization as the target metric with a target value of 50%
With step scaling and simple scaling, you choose scaling metrics and threshold values for the CloudWatch alarms that trigger the scaling process. Neither step scaling nor simple scaling can be configured to use a target metric for CPU utilization, hence both these options are incorrect.
Configure the Auto Scaling group to use a Cloudwatch alarm triggered on a CPU utilization threshold of 50% – An Auto Scaling group cannot directly use a Cloudwatch alarm as the source for a scale-in or scale-out event, hence this option is incorrect.

Question 08:
A tax computation software runs on Amazon EC2 instances behind a Classic Load Balancer. The instances are managed by an Auto Scaling Group. The tax computation software has an optimization module, which can take up to 10 minutes to find the optimal answer.
How do you ensure that when the Auto Scaling Group initiates a scale-in event, the users do not see their current requests interrupted?
• Increase the deregistration delay to more than 10 minutes (Correct)
• Enable Stickiness on the CLB
• Enable ELB health checks on the ASG
• Create an ASG Scheduled Action
Explanation
Correct option:
Increase the deregistration delay to more than 10 minutes
Elastic Load Balancing stops sending requests to targets that are deregistering. By default, Elastic Load Balancing waits 300 seconds before completing the deregistration process, which can help in-flight requests to the target to complete. We need to update this value to more than 10 minutes to allow our tax software to complete in-flight requests. Therefore this is the correct option.
Incorrect options:
Create an ASG Scheduled Action – Scheduled scaling allows you to set your scaling schedule. For example, let’s say that every week the traffic to your web application starts to increase on Wednesday, remains high on Thursday, and starts to decrease on Friday. You can plan your scaling actions based on the predictable traffic patterns of your web application. Scaling actions are performed automatically as a function of time and date.
You cannot use a scheduled action to stop the current request from being interrupted in case of a scale-in event. Hence this option is incorrect.
Enable Stickiness on the CLB – By default, a Classic Load Balancer routes each request independently to the registered instance with the smallest load. However, you can use the sticky session feature (also known as session affinity), which enables the load balancer to bind a user’s session to a specific instance. This ensures that all requests from the user during the session are sent to the same instance. You cannot use sticky sessions to stop the current request from being interrupted in case of a scale-in event. Hence this option is incorrect.
Enable ELB health checks on the ASG – The default health checks for an Auto Scaling group are EC2 status checks only. If an instance fails these status checks, the Auto Scaling group considers the instance unhealthy and replaces it. To ensure that the group can determine an instance’s health based on additional tests provided by the load balancer, you can optionally configure the Auto Scaling group to use Elastic Load Balancing health checks.
ELB health checks, when enabled on an ASG, help let the ASG when instances are unhealthy and trigger a scale-in event. You cannot use ELB health checks on the ASG to stop the current request from being interrupted in case of a scale-in event. Hence this option is incorrect.

Question 47:
The engineering team at a logistics company has noticed that the Auto Scaling group (ASG) is not terminating an unhealthy Amazon EC2 instance.
As a Solutions Architect, which of the following options would you suggest to troubleshoot the issue? (Select three)
A• The EC2 instance could be a spot instance type, which cannot be terminated by ASG
B• The instance has failed the ELB health check status
C• The instance maybe in Impaired status
D• A custom health check might have failed. ASG does not terminate instances that are set unhealthy by custom checks
E• The health check grace period for the instance has not expired
F• A user might have updated the configuration of ASG and increased the minimum number of instances forcing ASG to keep all instances alive
Answer: B, C & E
Explanation
Correct options:
The health check grace period for the instance has not expired – Amazon EC2 Auto Scaling doesn’t terminate an instance that came into service based on EC2 status checks and ELB health checks until the health check grace period expires.
The instance maybe in Impaired status – Amazon EC2 Auto Scaling does not immediately terminate instances with an Impaired status. Instead, Amazon EC2 Auto Scaling waits a few minutes for the instance to recover. Amazon EC2 Auto Scaling might also delay or not terminate instances that fail to report data for status checks. This usually happens when there is insufficient data for the status check metrics in Amazon CloudWatch.
The instance has failed the ELB health check status – By default, Amazon EC2 Auto Scaling doesn’t use the results of ELB health checks to determine an instance’s health status when the group’s health check configuration is set to EC2. As a result, Amazon EC2 Auto Scaling doesn’t terminate instances that fail ELB health checks. If an instance’s status is OutofService on the ELB console, but the instance’s status is Healthy on the Amazon EC2 Auto Scaling console, confirm that the health check type is set to ELB.
Incorrect options:
The EC2 instance could be a spot instance type, which cannot be terminated by ASG – This is an incorrect statement. Amazon EC2 Auto Scaling terminates Spot instances when capacity is no longer available or the Spot price exceeds your maximum price.
A user might have updated the configuration of ASG and increased the minimum number of instances forcing ASG to keep all instances alive – This statement is incorrect. If the configuration is updated and ASG needs more number of instances, ASG will launch new, healthy instances and does not keep unhealthy ones alive.
A custom health check might have failed. ASG does not terminate instances that are set unhealthy by custom checks – This statement is incorrect. You can define custom health checks in Amazon EC2 Auto Scaling. When a custom health check determines that an instance is unhealthy, the check manually triggers SetInstanceHealth and then sets the instance’s state to Unhealthy. Amazon EC2 Auto Scaling then terminates the unhealthy instance.

Question 14: Correct
A retail company has a fleet of EC2 instances running behind an Auto Scaling group (ASG). The development team has configured two metrics that control the scale-in and scale-out policies of ASG. First one is a target tracking policy that uses a custom metric to add and remove two new instances, based on the number of SQS messages in the queue. The other is a step scaling policy that uses the CloudWatch CPUUtilization metric to launch one new instance when the existing instance exceeds 90 percent utilization for a specified length of time.
While testing, the scale-out policy criteria for both policies was met at the same time. How many new instances will be launched because of these multiple scaling policies?
• Amazon EC2 Auto Scaling chooses the sum of the capacity of all the policies that meet the criteria. So, three new instances will be launched by the ASG
• Amazon EC2 Auto Scaling chooses the policy that provides the largest capacity, so policy with the custom metric is triggered, and two new instances will be launched by the ASG
• Amazon EC2 Auto Scaling chooses the minimum capacity from each of the policies that meet the criteria. So, one new instance will be launched by the ASG
• Amazon EC2 Auto Scaling chooses the latest policy after running the algorithm defined during ASG configuration. Based on this output, either of the policies will be chosen for scaling out
Answer: B
Explanation
Correct option:
Amazon EC2 Auto Scaling chooses the policy that provides the largest capacity, so policy with the custom metric is triggered, and two new instances will be launched by the ASG – A scaling policy instructs Amazon EC2 Auto Scaling to track a specific CloudWatch metric, and it defines what action to take when the associated CloudWatch alarm is in ALARM. For an advanced scaling configuration, your Auto Scaling group can have more than one scaling policy. For example, you can define one or more target tracking scaling policies, one or more step scaling policies, or both. This provides greater flexibility to cover multiple scenarios.
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. For example, it’s possible that the CPUUtilization metric spikes and triggers the CloudWatch alarm at the same time that the SQS custom metric spikes and triggers the custom metric alarm.
When these situations occur, Amazon EC2 Auto Scaling chooses the policy that provides the largest capacity for both scale-out and scale-in. Suppose, for example, that the policy for CPUUtilization launches one instance, while the policy for the SQS queue launches two instances. If the scale-out criteria for both policies are met at the same time, Amazon EC2 Auto Scaling gives precedence to the SQS queue policy. This results in the Auto Scaling group launching two instances. The approach of giving precedence to the policy that provides the largest capacity applies even when the policies use different criteria for scaling in.
AWS recommends caution when using target tracking scaling policies with step scaling policies because conflicts between these policies can cause undesirable behavior. For example, if the step scaling policy initiates a scale-in activity before the target tracking policy is ready to scale in, the scale-in activity will not be blocked. After the scale-in activity completes, the target tracking policy could instruct the group to scale out again.
Incorrect options:
Amazon EC2 Auto Scaling chooses the minimum capacity from each of the policies that meet the criteria. So, one new instance will be launched by the ASG
Amazon EC2 Auto Scaling chooses the latest policy after running the algorithm defined during ASG configuration. Based on this output, either of the policies will be chosen for scaling out
Amazon EC2 Auto Scaling chooses the sum of the capacity of all the policies that meet the criteria. So, three new instances will be launched by the ASG
These three options contradict the explanation provided above, so these are.