AWS DevOps Monitoring: Metrics, Tools, and Best Practices
Published on · Updated on
Reworked AWS monitoring guidance for current signal types, service roles, alert design, OpenTelemetry, and monitoring as code.
A useful AWS monitoring setup answers two questions: can customers complete the work they came to do, and where should the team look when they cannot? Start with customer and business outcomes, then collect the metrics, logs, traces, and events that help detect and explain a failure. Amazon CloudWatch is the main AWS service for workload telemetry and alarms, while CloudTrail, AWS Config, security services, and AWS cost tools answer different questions.
Collecting more data does not automatically improve visibility. Every signal should help someone decide whether to investigate, act, or recover. AWS recommends monitoring every important workload component, including the customer experience and the dependencies behind it; see the AWS Well-Architected guidance for monitoring workload resources.
Monitoring duties also follow AWS's shared responsibility model. AWS operates the infrastructure that runs AWS services, while customers manage the applications and resource configuration they use; the boundary varies by service. Identify which layer each signal covers and who is expected to respond.
Monitoring in AWS DevOps
Monitoring is the ongoing collection and evaluation of evidence about a workload. Observability is the ability to use that evidence to understand behavior you did not anticipate. In practice, DevOps teams need both: signals should detect a change in service health, and enough context should remain to explain the change and guide a response.
Keep the customer path in view. A running instance or a healthy process does not prove that a customer can sign in, complete a payment, or retrieve an object. Monitor representative user journeys and business operations alongside the infrastructure and dependencies that serve them. Treat each workload as a system of connected components, not as a collection of unrelated AWS resources.
Key metrics for AWS DevOps monitoring
Choose a small set of signals that describe the health of a service and its operation. The examples below are starting points; the right names, dimensions, and targets depend on the workload.
| Area | Useful signals | What they help answer |
|---|---|---|
| User and service health | Successful transaction rate, request volume, error rate, and latency percentiles for key operations | Are customers able to use the service, and is it responding within its service objective? |
| Business outcomes | Completed orders, accepted jobs, queue age, rejected transactions, or other workload-specific measures | Is the system delivering the work it exists to perform? |
| Resources and dependencies | CPU, network, storage, database connections, queue depth, throttles, and dependency errors | Which component may be limiting the service or nearing a capacity limit? |
| Software delivery | Change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate | How quickly can the team deliver changes, and how often do changes create production problems or unplanned repair work? |
| Security and configuration | Relevant account activity, threat findings, network-flow records, resource configuration changes, and compliance evaluations | What changed, what looks suspicious, and which resources no longer match required configuration? |
| Cost and usage | Spend by service, account, owner, or cost allocation tag; budget variance; and unusual spend | Where is cost growing, and which team or workload should investigate it? |
For application latency, look beyond averages. A service can have an acceptable average while a smaller set of requests is slow, so measure relevant upper percentiles as well as success and error rates. Include successful work metrics: a quiet error log can mean the service is healthy, or it can mean that no work is getting through.
Resource metrics need context. Many AWS services publish service-specific CloudWatch metrics, but guest memory and filesystem usage on an EC2 instance are not the same as the instance-level metrics available by default. Use the CloudWatch agent when you need in-guest system metrics, file logs, or application telemetry. For Lambda-specific system and invocation diagnostics, see the site's Lambda Insights monitoring guide.
Delivery measures are not infrastructure metrics. DORA's current model separates software delivery throughput from instability: it includes change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. Define them from your source-control, deployment, and incident records, and correlate them with service impact rather than treating deployment frequency as a proxy for reliability. See DORA's current software delivery performance metrics.
Setting baselines and thresholds
A threshold should represent a condition that matters to the workload or its customers, not simply a value slightly above the historical average. Start from a service objective, a resource limit, or a known failure condition. Use historical behavior to understand normal variation and seasonality, then check that the chosen threshold leaves enough time for the response the team can take.
Choose what wakes someone up
Page for a condition that is urgent, actionable, and owned by an on-call responder. Send lower-urgency trends or capacity warnings to a dashboard, ticket, or scheduled review. A useful alert names the affected service, states what crossed the condition, links to the relevant dashboard or runbook, and says who should respond.
Use sustained or multi-period evaluation where a single brief spike would create noise. For latency-sensitive services, consider an alert on an error or latency objective rather than paging on every underlying resource metric. Resource alerts still matter when they give responders time to prevent a customer-visible failure.
Decide how to handle missing data
Missing telemetry can mean a broken collector, an unavailable service, or a metric that reports only when an event occurs. Decide how each alarm should treat missing data instead of accepting a default by accident. For example, no data for a continuously reported health metric can indicate a monitoring gap, while no data for an error-only metric may simply mean no errors occurred. AWS explains the options in its guide to CloudWatch alarm missing-data treatment.
Review alert history after incidents and false alarms. Adjust metric selection, periods, missing-data behavior, and notification routing when evidence shows the alert did not arrive, could not be acted on, or did not represent customer impact. The site's CloudWatch alarm guide covers alarm conditions and threshold choices in more detail.
AWS monitoring tools
These services have different purposes. Use the service that owns the signal, and connect the signals when responders need a shared view.
| Service or tool | Use it for | Important distinction |
|---|---|---|
| Amazon CloudWatch | AWS service metrics, custom metrics, logs, dashboards, alarms, and application-level observability features | CloudWatch combines several kinds of telemetry; configure the data and alarms the workload actually needs. |
| CloudWatch agent | Guest operating-system metrics, instance and application logs, and supported telemetry collection from EC2, on-premises servers, and containers | Agent-collected metrics are custom metrics and affect CloudWatch charges. Select only useful metrics and dimensions. |
| AWS X-Ray with OpenTelemetry | Distributed traces that show how a request moves through services and where latency or errors occur | As of this update, the X-Ray SDKs and daemon entered maintenance mode on February 25, 2026: AWS limits their releases to security fixes and plans to discontinue support for them on February 25, 2027. AWS recommends migrating instrumentation to OpenTelemetry. The notice applies to the SDKs and daemon; see AWS's migration guidance for collection options. |
| AWS CloudTrail | Account activity and AWS API events, including who made a change and when | Trails and event data stores log management events by default; data events need to be selected. CloudTrail Event history covers management events only. |
| AWS Config | Resource inventory, configuration history, relationships, and rule-based compliance evaluation | It helps explain resource state and configuration drift; it is not application performance monitoring. |
| Amazon GuardDuty, VPC Flow Logs | Security findings and records describing IP traffic to and from VPC network interfaces | Use findings and flow records for security investigation; they do not replace application request metrics or distributed traces. |
| AWS Cost Explorer, Budgets, and Cost Anomaly Detection | Spend trends, budget thresholds, and unusual cost patterns | Billing data is not real-time workload telemetry. AWS says anomaly detection can take up to 24 hours after usage to detect an anomaly. |
Amazon CloudWatch is a practical starting point for many AWS workloads because many AWS services publish metrics there, and it can also store logs, show dashboards, and evaluate alarms. Check which metrics each service publishes and where the gaps are. Do not assume that a service metric covers application behavior, guest operating-system state, or a complete customer journey.
Third-party monitoring tools
Prometheus is a metrics system, while Grafana is commonly used to query and visualize data sources such as CloudWatch and Prometheus. A hosted observability platform can be useful when you need a common workflow across AWS and other environments. Compare tools by supported data sources, cross-account access, retention, alert routing, access controls, query and ingestion costs, and how much telemetry duplication they introduce. For a practical CloudWatch dashboard connection, see the site's CloudWatch and Grafana setup guide.
Combining monitoring tools for better visibility
Metrics, logs, traces, and account events explain different parts of an incident. A metric can reveal that latency rose, a trace can show which dependency contributed to it, and a log can provide request-specific context. CloudTrail or a deployment record can help identify a change that occurred around the same time. These signals are easier to use together when services and environments have consistent names and timestamps.
- Include service, environment, and version identifiers in telemetry so responders can filter to the affected workload.
- Propagate trace or request identifiers where supported so a request can be followed across logs and traces.
- Mark deployments and configuration changes on dashboards so a change can be compared with service behavior.
- Limit sensitive data in logs and traces, and set access and retention according to the data's purpose.
CloudTrail records account activity such as AWS API calls and console sign-ins; it does not provide packet-level network telemetry. For network-flow investigation, VPC Flow Logs record IP traffic metadata; for potential threats, GuardDuty produces security findings. For a focused comparison of storage access and account activity, see S3 access logs vs. CloudTrail logs.
Setting up monitoring in AWS
- Map the workload. Identify the user journeys, critical operations, service owner, dependencies, and the service objectives that define acceptable behavior.
- Inventory the available signals. Check AWS service metrics, application logs, deployment events, and security or configuration records. Record gaps such as missing guest memory metrics or an unmonitored external endpoint.
- Instrument the gaps. Add only the required custom metrics, logs, traces, or synthetic checks. Use the CloudWatch agent for supported host telemetry and OpenTelemetry instrumentation for new distributed tracing work where appropriate.
- Define alerts and responses. Set thresholds around customer impact or operational limits, decide how missing data should be treated, and assign each alert an owner and runbook.
- Build dashboards around investigations. Show service health and recent changes first, then provide links or drill-down paths to the logs, traces, and resource metrics responders need.
- Exercise the alert path. Confirm that the condition is detected, the right team is notified, and the runbook leads to a safe response. Review the result after real incidents and adjust the signals.
Include external endpoints and dependencies in the monitoring plan. A workload can look healthy internally while a customer-facing route or a required third-party dependency is unavailable. Synthetic checks can help test representative customer actions independently of ordinary production traffic.
Monitoring with code
Monitoring as code means managing telemetry configuration through the same reviewed and repeatable workflow used for infrastructure. Define CloudWatch alarms and dashboards, log groups and retention, metric filters, agent configuration, notification routes, and any required IAM permissions in version-controlled configuration. Teams can then review what signals will change alongside the infrastructure or application change that needs them.
What to manage as code
- Metrics and log collection settings, including the specific resources and dimensions collected.
- Alarm conditions, missing-data behavior, severity, notification destinations, and safe automated actions.
- Dashboards, log retention, metric filters, and routing rules for events.
- Permissions that allow agents and monitoring services to publish or read telemetry.
How to deploy monitoring changes
Use CloudFormation, AWS CDK, Terraform, or the infrastructure tool already responsible for the workload. Review generated changes for replacements, deletions, and permission changes. Apply monitoring configuration through the deployment pipeline, verify that the expected metrics and alarms appear, and keep a recovery path for a bad configuration. This avoids environment drift and lets a monitoring change be traced to a reviewed source change. The site's guide to common AWS infrastructure-as-code pitfalls covers ownership and review risks that also apply to monitoring resources.
Monitoring dashboards
A dashboard should help a particular audience make a decision. An operations view might emphasize service objectives, error and latency trends, dependency health, and active alarms. A development view might add recent releases, trace links, and detailed application metrics. A security view should focus on findings and relevant account or network activity. A business view should show customer or transaction outcomes rather than infrastructure detail alone.
Keep the first view focused on the signals that change an action. Group related metrics, use clear names and units, show useful time ranges, and link to the next level of detail. Avoid copying every available metric onto one screen: a dashboard that cannot quickly distinguish healthy from unhealthy behavior slows down incident response.
AWS monitoring best practices
- Monitor outcomes and components. Pair customer-facing availability and transaction measures with infrastructure and dependency signals.
- Make every alert actionable. Name an owner, severity, notification route, and runbook; remove or lower alerts that do not lead to a useful action.
- Watch the telemetry pipeline. Missing metrics or logs can hide an outage. Monitor collection and delivery where a gap would leave responders blind.
- Control data volume and access. Collect the dimensions and detail needed for diagnosis, protect sensitive fields, set retention deliberately, and review ingestion, storage, query, and custom-metric charges against the CloudWatch pricing model.
- Keep security, configuration, and cost signals in their proper tools. CloudTrail events, Config evaluations, GuardDuty findings, network-flow records, and billing data answer different questions; route each to the team that can act.
- Improve the system from evidence. Revisit alert noise, blind spots, recovery time, and dashboard usefulness after incidents and operational reviews.
Good AWS monitoring is not a larger collection of charts. It is a small, maintained set of signals that reveals customer impact, helps responders find a cause, and supports a safe recovery. Define it with the workload, review it as code, and keep checking that each signal still supports a real decision.