QuestionQ5
Resilient Cloud SolutionsA DevOps engineer manages a Java-based application running in an Amazon Elastic Container Service (Amazon ECS) cluster on AWS Fargate. Auto scaling is not configured for the application.
The DevOps engineer has identified the Java Virtual Machine (JVM) thread count as a good indicator for when the application should scale. The application serves customer traffic on port 8080 and exposes JVM metrics on port 9404.
Application usage has recently increased. The DevOps engineer must configure auto scaling for the application.
Which solution meets these requirements with the LEAST operational overhead?
Choose two
- A Deploy the Amazon CloudWatch agent as a container sidecar. Configure the CloudWatch agent to retrieve JVM metrics from port 9404. Create CloudWatch alarms on the JVM thread count metric to scale the application. Add a step scaling policy in Fargate to scale up and scale down based on the CloudWatch alarms.
- B Deploy the Amazon CloudWatch agent as a container sidecar. Configure a metric filter for the JVM thread count metric on the CloudWatch log group for the CloudWatch agent. Add a target tracking policy in Fargate. Select the metric from the metric filter as a scale target.
- C Create an Amazon Managed Service for Prometheus workspace. Deploy AWS Distro for OpenTelemetry as a container sidecar to publish the JVM metrics from port 9404 to the Prometheus workspace. Configure rules for the workspace to use the JVM thread count metric to scale the application. Add a step scaling policy in Fargate. Select the Prometheus rules to scale up and scaling down.
- D Create an Amazon Managed Service for Prometheus workspace. Deploy AWS Distro for OpenTelemetry as a container sidecar to retrieve JVM metrics from port 9404 to publish the JVM metrics from port 9404 to the Prometheus workspace. Add a target tracking policy in Fargate. Select the Prometheus metric as a scale target.
Community Discussion