Which solution will meet these requirements?
Create an Amazon CloudWatch alarm that enters the ALARM state when the CPUUtilization metric is less than 20%. Create an AWS Lambda function that the CloudWatch alarm invokes to terminate one of the EC2 instances in the ALB target group.
Create an EC2 Auto Scaling group. Select the existing ALB as the load balancer and the existing target group as the target group. Set a target tracking scaling policy that is based on the ASGAverageCPUUtilization metric. Set the minimum instances to 2, the desired capacity to 3, the maximum instances to 6, and the target value to 50%. Add the EC2 instances to the Auto Scaling group.
Create an EC2 Auto Scaling group. Select the existing ALB as the load balancer and the existing target group as the target group. Set the minimum instances to 2, the desired capacity to 3, and the maximum instances to 6. Add the EC2 instances to the Auto Scaling group.
Create two Amazon CloudWatch alarms. Configure the first CloudWatch alarm to enter the ALARM state when the average CPUUtilization metric is below 20%. Configure the second CloudWatch alarm to enter the ALARM state when the average CPUUtilization matric is above 50%. Configure the alarms to publish to an Amazon Simple Notification Service (Amazon SNS) topic to send an email message. After receiving the message, log in to decrease or increase the number of EC2 instances that are running.
Explanations:
This option suggests terminating an instance when CPU usage is low, which does not address the need for scaling up during surges in CPU usage. Additionally, using a CloudWatch alarm to terminate instances does not ensure that sufficient resources are available when needed, as it could lead to under-provisioning during traffic spikes.
This option implements an EC2 Auto Scaling group with a target tracking scaling policy based on average CPU utilization. This setup allows for automatic scaling based on demand, optimizing costs by adjusting the number of instances according to traffic patterns while ensuring sufficient resources are available during CPU usage surges. The specified minimum, desired, and maximum instance counts provide a balance between cost and performance.
While this option sets up an Auto Scaling group with defined minimum, desired, and maximum instances, it lacks a scaling policy. Without a policy based on CPU utilization or other metrics, this setup would not automatically scale the instances up or down in response to changes in traffic, which fails to optimize costs and ensure resource availability during surges.
This option relies on manual intervention after receiving notifications from CloudWatch alarms, which is not an automated solution. While it monitors CPU utilization, it does not automatically adjust the number of instances based on demand, which does not meet the requirements for automation and cost optimization.
I infer that the answer is:
Create an EC2 Auto Scaling group. Select the existing ALB as the load balancer and the existing target group as the target group. Set a target tracking scaling policy that is based on the ASGAverageCPUUtilization metric. Set the minimum instances to 2, the desired capacity to 3, the maximum instances to 6, and the target value to 50%. Add the EC2 instances to the Auto Scaling group.