Least Overhead for Custom EC2 Metrics

DOP-C02 By islever Editorial Last updated

Configure the collection, aggregation, and storage of logs and metrics.

Short answer

A Install the Amazon CloudWatch agent on the instances and configure it to collect the custom metrics.

Question

A company is developing a web application that runs on Amazon EC2 Linux instances. The application requires monitoring of custom performance metrics. The company must collect metrics for API response times and database query latency across multiple instances.
Which solution will generate the custom metrics with the LEAST operational overhead?
  1. Install the Amazon CloudWatch agent on the instances. Configure the agent to collect the custom metrics. Instrument the application to send the metrics to the agent. Correct Answer
  2. Use Amazon Managed Service for Prometheus to scrape the custom metrics from the application. Use the Amazon CloudWatch agent to forward the metrics to CloudWatch.
  3. Create a custom AWS Lambda function that polls the application endpoints and database at regular intervals. Program the Lambda function to calculate the custom metrics and to send the metrics to Amazon CloudWatch by using PutMetricData API calls.
  4. Implement custom logging in the application code to record the custom metrics. Use Amazon CloudWatch Logs Insights to extract and analyze the metrics.

Key Takeaways

Tests knowledge of native metric collection tools versus manual instrumentation or log parsing, highlighting that agent-based collection reduces code maintenance compared to Lambda or Logs Insights.

Determines the optimal method for collecting custom performance metrics from Amazon EC2 instances with minimal operational overhead using the CloudWatch Agent.

Common mistake: Candidates often select Option D (CloudWatch Logs Insights) because it requires no agent installation, but this incurs higher operational overhead due to complex log parsing and query management.

Expert Analysis

Why the Answer Is Correct

Option A is correct because the Amazon CloudWatch Agent is specifically designed to collect custom application metrics directly from the instance OS and application environment. By configuring the agent to accept metrics (e.g., via StatsD or TCP/UDP), the application can push data without complex polling logic, and the agent handles transmission to CloudWatch, representing the least operational overhead for infrastructure-level monitoring.

Why the Other Options Are Wrong

Option B introduces unnecessary complexity by combining Managed Service for Prometheus with an agent, which is overkill for simple EC2 metrics. Option C requires maintaining a Lambda function that polls endpoints, adding significant development and operational burden. Option D relies on log parsing, which is less efficient for structured metrics and requires managing log groups and queries rather than direct metric ingestion.

Community Comment Notes

Community consensus supports Option A, noting that the CloudWatch Agent provides native support for protocols like StatsD, allowing collection of internal application metrics with minimal configuration. As one user noted, "Options C and D require additional development maintenance," reinforcing that agent-based collection is superior for operational simplicity.

Official Reference

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

When asked for 'least operational overhead' in monitoring, prioritize managed agents or native services over custom code (Lambda) or log parsing. Avoid solutions that require you to write and maintain polling scripts if a standard agent exists.

Frequently Asked Questions

Why is CloudWatch Logs Insights not the best choice?

Logs Insights parses text logs, which is inefficient for structured metrics and requires managing log schemas and queries, increasing operational overhead.

Does the CloudWatch Agent add significant overhead?

No, it is a lightweight daemon installed once on the instance that handles metric aggregation and transmission, reducing application-side coding effort.

More DOP-C02 FAQ →

Discussion 2 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 2

  1. emupsx1 👍 2 Answered A
    Option A is the best choice because the CloudWatch Agent provides native support for protocols like StatsD, allowing the collection of internal application metrics (such as latency) with minimal configuration. In contrast, Options C and D require additional development maintenance (Lambda) or higher-cost log analysis overhead.
  2. meng 👍 1 Answered A
    https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Optimizing Amazon Timestream Query Performance

S-grade

Deploy the CloudWatch agent as a StatefulSet with IRSA and CloudWatchAgentServerPolicy, and configure the OIDC provider

S-grade

Disable cross-zone load balancing on the target group and start an Application Recovery Controller zonal shift

S-grade

Stream all CloudWatch metrics to Firehose, transform with Lambda, and deliver to S3

S-grade

Practice All DOP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full DOP-C02 Practice Test →

← Back to DOP-C02 Study Guide