An application is deployed on Amazon EC2 instances that run in an Auto Scaling group. The Auto Scaling group configuration uses only one type of instance.
CPU and memory utilization metrics show that the instances are underutilized. A solutions architect needs to implement a solution to permanently reduce the EC2 cost and increase the utilization.
Which solution will meet these requirements with the LEAST number of configuration changes in the future?
To permanently reduce EC2 costs and increase utilization, it is effective to select an instance type based on the application's CPU and memory utilization requirements. This ensures that the instance type aligns with the usage needs, optimizing both performance and cost. By modifying the Auto Scaling group's configuration to use the new instance type and removing the old one, you maintain a single configuration that is tailored to the application’s needs. This approach minimizes the need for future adjustments, as it directly addresses the issue of overallocation by selecting an appropriate instance size from the start.
It's C. You change the instance type/size in the launch template not the ASG. ASG can change the min/max size, not instance type.
I’ve tested it myself in the AWS Console – correct answer is “B”. To change the instance type you have 3 options, and all of them require modifying the ASG’s config: 1. Create a new revision of the current launch template, then change the ASG config to use it. 2. Create a new launch template, then change the ASG config to use it. 3. Use the option “Override launch template” in the ASG config. If you only create a new revision of the launch template, the ASG will continue to use the old revision. The state that you cannot change the instance type from the ASG config is NOT true and anybody can verify it in the AWS Console.
In the launch template, you can only select one instance type. You can however override the Launch Template in the ASG configuration and specify multiple instance types.
It could be B or C, but "LEAST number of configuration changes in the future" makes it C.
Key to the Answer is "Modify". Launch templates are immutable; after you create a launch template, you can't modify it. Instead, you can create a new version of the launch template that includes any changes you require. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/manage-launch-template-versions.html
The answer used to be C, but now it's B. But not for the reasons others here have mentioned. The question states that "The Auto Scaling group configuration uses only one type of instance". This implies the ASG config has implemented instance overrides, which - you guessed it - overrides the instance type that's specified in the launch template. You could cut new versions of launch templates until you're blue in the face, it wont make a lick of difference if the ASG config is overriding the instance type. And because ASGs can be modified, I reckon that puts a nail in C's coffin, making B the new correct answer. I think this is the first question (out of 400+) where the moderator-selected solution was correct and the community-voted solution was incorrect.
I believe "The Auto Scaling group configuration uses only one type of instance." is just a badly phrased sentence and the question designer only meant that instances running under AutoScaling Group are of one instance type. I understand the sentence as a suggestion to improve the state by specifying multiple types instead. Apart from the wording, there's nothing wrong with answer C. It lets you stop worrying about the future instance generations, too, compared to B where you have to modify the instance type whenever a new generation is released. Also, as specific instance types can be temporarily unavailable (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html#troubleshooting-launch-capacity), C can smoothly use another available instance automatically.
attribute-based instance types
we cannot change/modify launch config or launch template
Option C
I’ve tested it myself in the AWS Console – correct answer is “B”. To change the instance type you have 3 options, and all of them require modifying the ASG’s config: 1. Create a new revision of the current launch template, then change the ASG config to use it. 2. Create a new launch template, then change the ASG config to use it. 3. Use the option “Override launch template” in the ASG config. If you only create a new revision of the launch template, the ASG will continue to use the old revision. The state that you cannot change the instance type from the ASG config is NOT true and anybody can verify it in the AWS Console.
its a B
ah, damn, clicked the wrong one. It's a C! not B
AWS does not allow to edit launch configuration. If you notice, we define instance type at time of launch configuration. So if you want to change instance type in Auto Scaling group than you need to create new launch configuration for that.
C for me
Correct C.
b IS ANS Minimal configuration changes: This solution only requires modifying the Auto Scaling group configuration to add the new, more efficient instance type and remove the old, underutilized type. This minimizes future maintenance and reduces the risk of introducing errors. Scalability and flexibility: The Auto Scaling group will automatically scale up and down based on demand, even with the new instance type. This ensures high availability and cost-effectiveness. Future-proof: This approach doesn't rely on specific instance types or the AWS Price List Bulk API, making it more adaptable to future changes and updates in the AWS ecosystem.
C is wrong. Let's assume a scenario where the optimal hardware requirement for a program under load is 4GB of RAM for every 1 CPU. However, you have specified only one type of instance with 1CPU and 1GB RAM. Even if you choose Option C and apply load balancing, having 4 instances of 1CPU and 1GB RAM (totaling 4CPU and 4GB RAM) will still result in an issue of low CPU utilization.
C: Auto scaling group is built on top of launch template, you can reference AMI in template, but not in auto scaling group
Correct answer is A: This solution allows for a mix of instance types, which can help optimize costs and increase utilization. By using similar instance types, it ensures compatibility with the application's requirements. This approach requires the least number of configuration changes in the future as it provides flexibility to automatically use different instance types as they become available or as prices change. B. This option limits the Auto Scaling group to a single instance type again, which doesn't provide flexibility for future changes. C. Specifying CPU and memory requirements without instance types may lead to unexpected instance selections and potential compatibility issues. D. Using a script with the AWS Price List Bulk API could lead to frequent changes and may select instance types that aren't optimal for the application's needs.