Monitoring, Logging, Analysis, Remediation, and Performance Optimization
Workload Telemetry, CloudWatch Alarms, Dashboards, and Notifications
CoreCollect the right workload evidence, turn signals into low-noise alarm states, present them at the correct account and Region scope, and deliver actionable notifications.
Aligned to AWS Certified CloudOps Engineer - Associate (SOA-C03) Version 1.1, verified August 24, 2026.
Why this matters
Operations starts with evidence. Default service metrics rarely provide guest memory, application logs, API history, alarm correlation, cross-account visibility, and responder delivery through one undifferentiated surface.
Must Know
- Use CloudWatch for workload metrics, logs, alarms, and dashboards; use CloudTrail for API activity and governance history rather than guest operating-system telemetry.
- Install and configure the CloudWatch agent when EC2, ECS, or EKS workloads need guest metrics or log files that the service does not publish by default. The agent also needs a running process, valid configuration, permissions, and a network path to the endpoints.
- A metric alarm evaluates a metric or query. A composite alarm evaluates the states of other alarms with Boolean logic and can reduce duplicate notifications during one incident.
- Alarm actions occur on state transitions and support defined targets. Composite alarms have a narrower action set than metric alarms, so verify the target is supported before choosing direct invocation.
- Cross-account observability or explicit sharing supplies the data boundary for a central view; dashboard widgets remain Region-aware and do not automatically discover every account and Region.
- SNS delivery is a chain: publisher or alarm action, topic policy, confirmed subscription, endpoint delivery, and delivery evidence must all be valid.
Compare and Distinguish
- CloudWatch metrics and logs describe workload behavior; CloudTrail records AWS API activity; AWS Health reports events affecting AWS resources and accounts.
- A metric filter turns matching log events into a metric; Logs Insights runs analysis but does not by itself create an alarmable time series.
- A single alarm represents one evaluated condition; a composite alarm combines alarm states and suppresses redundant actions.
- A dashboard displays evidence; an alarm evaluates it; SNS transports a notification. None substitutes for the other two.
Scenario examples
- Scenario: An EC2 application lacks memory and application-error signals. Deploy the CloudWatch agent with the intended metric and file definitions, an authorized role, and endpoint connectivity.
- Scenario: Ten component alarms fire during the same dependency outage. Put the responder action on a composite alarm whose rule represents the incident condition.
- Scenario: A central operations account needs one view of multiple source accounts. Establish the supported observability-sharing relationship and build Region-specific widgets.
Exam traps
- Do not expect default EC2 metrics to include every guest operating-system metric or application log.
- Do not treat an ALARM state as proof that SNS delivered to the final subscriber.
- Do not attach unsupported EC2 or Auto Scaling actions to a composite alarm.
- Do not treat a public or broadly shared dashboard as a replacement for scoped operations access.
Key takeaways
- Choose the evidence surface before configuring the visualization.
- Treat collection, evaluation, action, and delivery as separate boundaries.
- Use composite logic for alarm-state correlation, not metric averaging.
- Verify telemetry and notification chains end to end.
How it works
- Start at the expected source and confirm that the metric or log reaches the intended namespace or log group.
- Validate alarm type, dimensions, evaluation settings, action support, and the account and Region selected by each dashboard widget.
- Trace notification delivery from the alarm action through topic policy and subscription status to endpoint evidence.
When to use it
- Choose CloudWatch metrics and logs to investigate workload behavior, CloudTrail to reconstruct AWS API activity, and AWS Health to identify service events affecting resources or accounts.
- Create a metric filter when matching log events must become an alarmable metric; use CloudWatch Logs Insights for interactive log analysis that does not need to create a time series.
- Use a metric alarm for one evaluated condition. Use a composite alarm when the operational decision depends on multiple alarm states or duplicate actions must be suppressed.
- Build a dashboard to present evidence, configure an alarm to evaluate a condition, and use Amazon SNS to transport notifications; each serves a different stage of the response path.
Security and governance implications
- Give agents, monitoring accounts, dashboards, and SNS publishers only the permissions required for their own collection or delivery step.
- Restrict access to operational logs and shared dashboards because telemetry can expose workload and account details.
Failure signals and diagnosis
- For missing telemetry, inspect source support, agent state/configuration, IAM, endpoint reachability, namespace, and log group.
- For a noisy incident, inspect evaluation periods, missing-data treatment, dimensions, anomaly behavior, and composite logic.
- For missing notifications, trace the alarm action, topic policy, subscription confirmation, endpoint response, and delivery status.
More detail
- Know which signals require the CloudWatch agent and which service metrics are available without guest collection.
- Distinguish metric alarms from composite alarms before assigning an action or trying to suppress duplicate notifications.
- Treat cross-account access, Region selection, dashboard sharing, and SNS delivery as separate configuration boundaries.
Ready for the quiz?
- An EC2 instance is missing memory metrics and application logs. What should you inspect to determine whether collection fails at the CloudWatch agent, IAM, or network layer?
- When should matching log events become a metric filter instead of remaining an interactive Logs Insights query?
- How would you prove whether a missing notification failed at alarm evaluation, the alarm action, the SNS topic, or the subscription endpoint?
Related objectives
- D1.1 — Task 1.1: Implement metrics, alarms, and filters by using AWS monitoring and logging services.
- 1.1.1 — Use AWS services (for example, Amazon CloudWatch, AWS CloudTrail, Amazon Managed Service for Prometheus) to configure monitoring and logging for workloads (for example, serverless, compute, AI).
- 1.1.2 — Configure and manage the CloudWatch agent to collect metrics and logs from EC2 instances, Amazon ECS clusters, or Amazon EKS clusters.
- 1.1.3 — Configure, identify, and troubleshoot CloudWatch alarms that can invoke AWS services directly or through Amazon EventBridge (for example, by creating composite alarms and identifying their invokable actions).
- 1.1.4 — Create, implement, and manage customizable and shareable CloudWatch dashboards that display metrics and alarms for AWS resources across multiple accounts and AWS Regions.
- 1.1.5 — Configure AWS services to send notifications to Amazon SNS and to invoke alarms that send notifications to Amazon SNS.