You work for a startup that has developed a new photo-sharing application for mobile devices.
Over recent months your application has increased in popularity; this has resulted in a decrease in the performance of the application due to the increased load.
Your application has a two-tier architecture that is composed of an Auto Scaling PHP application tier and a MySQL RDS instance initially deployed with AWS Cloud Formation.
Your Auto Scaling group has a min value of 4 and a max value of 8
The desired capacity is now at 8 because of the high CPU utilization of the instances.
After some analysis, you are confident that the performance issues stem from a constraint in CPU capacity, although memory utilization remains low.
You therefore decide to move from the general-purpose M3 instances to the compute-optimized C3 instances.
How would you deploy this change while minimizing any interruption to your end users?
Click on the arrows to vote for the correct answer
A. B. C. D.Answer - D.
The AWS::AutoScaling::AutoScalingGroup resource supports an UpdatePolicy attribute.
This is used to define how an Auto Scaling group resource is updated when an update to the CloudFormation stack occurs.
A common approach to updating an Auto Scaling group is to perform a rolling update, which is done by specifying the AutoScalingRollingUpdate policy.
This retains the same Auto Scaling group and replaces old instances with new ones, according to the parameters specified.
For more information on rolling updates, please visit the below link:
https://aws.amazon.com/premiumsupport/knowledge-center/auto-scaling-group-rolling-updates/The correct answer is D. Update the launch configuration specified in the AWS CloudFormation template with the new C3 instance type. Also, add an UpdatePolicy attribute to your Auto Scaling group that specifies AutoScalingRollingUpdate. Run a stack update with the new template.
Explanation:
The scenario described in the question involves moving from M3 general-purpose instances to C3 compute-optimized instances in order to address CPU constraints while minimizing any interruption to end-users. The two-tier architecture consists of an Auto Scaling PHP application tier and a MySQL RDS instance that was initially deployed with AWS CloudFormation. The Auto Scaling group has a minimum value of 4 and a maximum value of 8, and the desired capacity is currently at 8 due to high CPU utilization.
To deploy the change from M3 to C3 instances, we need to update the launch configuration used by the Auto Scaling group, which specifies the instance type, security groups, key pairs, and other settings used to launch new instances. There are several ways to achieve this, but we need to choose a method that minimizes disruption to end-users.
Option A: Sign in to the AWS Management Console, copy the old launch configuration, and create a new launch configuration that specifies the C3 instances. Update the Auto Scaling group with the new launch configuration. Auto Scaling will then update the instance type of all running instances.
This approach involves creating a new launch configuration that specifies the C3 instance type and updating the Auto Scaling group with the new launch configuration. Auto Scaling will then launch new instances with the new configuration, terminate old instances, and gradually replace them with the new instances. However, this approach requires downtime during the deployment since the old instances are terminated before new instances are launched.
Option B: Sign in to the AWS Management Console, and update the existing launch configuration with the new C3 instance type. Add an UpdatePolicy attribute to your Auto Scaling group that specifies AutoScalingRollingUpdate.
This approach involves updating the existing launch configuration used by the Auto Scaling group with the new C3 instance type and adding an UpdatePolicy attribute that specifies AutoScalingRollingUpdate. This attribute instructs Auto Scaling to perform a rolling update, which replaces old instances with new instances one at a time while maintaining a steady-state capacity. However, this approach requires downtime during the deployment since the old instances are terminated before new instances are launched.
Option C: Update the launch configuration specified in the AWS CloudFormation template with the new C3 instance type. Run a stack update with the new template. Auto Scaling will then update the instances with the new instance type.
This approach involves updating the launch configuration specified in the AWS CloudFormation template with the new C3 instance type and running a stack update with the new template. This will trigger a stack update that updates the Auto Scaling group and launches new instances with the new launch configuration while maintaining the existing capacity. However, this approach requires downtime during the deployment since the old instances are terminated before new instances are launched.
Option D: Update the launch configuration specified in the AWS CloudFormation template with the new C3 instance type. Also, add an UpdatePolicy attribute to your Auto Scaling group that specifies AutoScalingRollingUpdate. Run a stack update with the new template.
This approach is similar to option C, but it also adds an UpdatePolicy attribute to the Auto Scaling group that specifies AutoScalingRollingUpdate. This attribute instructs Auto Scaling to perform a rolling update, which replaces old instances with new instances one at a time while maintaining a steady-state capacity. This approach minimizes disruption to end-users since old instances are only terminated after new instances are launched and verified to be healthy. Therefore, the correct answer is D.
In summary, to deploy the change from M3 to C3 instances while minimizing disruption to end-users, we need