A company wants to reduce the cost of its containerized ML applications. The applications use ML models that run on Amazon EC2 instances, AWS Lambda functions, and an Amazon Elastic Container…

Question

Options

• ACreate code to evaluate each instance's memory and compute usage.
• BAdd cost allocation tags to the resources. Activate the tags in AWS Billing and Cost Management.
• CCheck AWS CloudTrail event history for the creation of the resources.
• DRun AWS Compute Optimizer.

• A
  4% (2)
• B
  2% (1)
• C
  9% (4)
• D
  84% (38)

Explanation

AWS Compute Optimizer is purpose-built for exactly this use case - it analyzes historical utilization metrics from EC2 instances, Lambda functions, ECS workloads, and EBS volumes, then automatically generates actionable right-sizing recommendations. It requires zero custom code and integrates natively with all the services mentioned, meeting the requirement with the least development effort.

Why the distractors are wrong:

• A - Writing custom code to evaluate memory and compute usage accomplishes the same thing Compute Optimizer does natively, but with significant development effort. It's the manual, reinventing-the-wheel approach.
• B - Cost allocation tags help you categorize and attribute costs in billing reports, but they do not identify inefficient resources or generate optimization recommendations. Tagging alone changes nothing.
• C - CloudTrail logs API calls and resource creation events for auditing and compliance purposes. It tells you who did what and when, not whether a resource is over-provisioned or wasteful.

Memory tip: Think of Compute Optimizer as a "right-sizing advisor" - whenever an AWS question asks about identifying underutilized resources and generating recommendations with minimal effort across EC2, Lambda, ECS, or EBS, Compute Optimizer is almost always the answer. The phrase "least development effort" is a strong signal to look for a managed AWS service rather than a custom-built solution.

No community discussion yet for this question.