How Amazon CloudWatch Works with Other AWS Services

Amazon CloudWatch is AWS’s monitoring and observability platform. AWS services and applications can publish metrics, logs, and events to CloudWatch, where you can visualise the data, create alarms, build dashboards, and trigger automated actions.

This is Part 50 of the AWS Cloud Practitioner Study Notes. The central model is:

AWS services and applications
        ↓
Metrics, logs, and events
        ↓
CloudWatch
        ↓
Dashboards, alarms, queries, and investigations
        ↓
SNS, Lambda, Auto Scaling, Systems Manager, or EventBridge

CloudWatch does not automatically perform every operational action itself. It collects and evaluates telemetry, then invokes configured integrations when an alarm or event matches.

The three CloudWatch responsibilities

1. Collect

CloudWatch receives or collects:

• Metrics such as CPU, request count, latency, errors, and storage
• Logs from services and applications
• Events such as alarm state changes and service activity
• Traces and application signals through supported CloudWatch features and agents

2. Analyse

CloudWatch can display metrics and logs, run Logs Insights queries, create metric filters, compare values against thresholds, detect anomalies, and evaluate alarms.

3. Act

When a condition is met, CloudWatch can notify people, invoke code, scale capacity, perform supported EC2 actions, create Systems Manager items or incidents, and emit events to EventBridge.

EC2 and CloudWatch

Amazon EC2 publishes standard instance metrics to CloudWatch, including:

• CPUUtilization
• NetworkIn and NetworkOut
• DiskReadOps and DiskWriteOps
• Status-check metrics such as StatusCheckFailed

Basic EC2 monitoring commonly publishes metrics at five-minute intervals. EC2 Detailed Monitoring publishes at one-minute intervals and may incur additional charges. CloudWatch Agent can collect additional operating-system metrics such as memory and disk-space usage; those are not all provided by default EC2 metrics.

EC2 CPUUtilization > 80%
        ↓
CloudWatch alarm
        ↓
SNS notification or Auto Scaling action

CloudWatch can also trigger supported EC2 alarm actions such as stop, terminate, reboot, or recover for eligible EC2 metrics. Use those actions carefully in production.

EC2 Auto Scaling and CloudWatch

EC2 Auto Scaling commonly uses CloudWatch alarms or target-tracking policies to adjust capacity:

Average CPU or request load increases
        ↓
CloudWatch alarm or scaling policy
        ↓
Auto Scaling group launches instances

When demand falls, the scaling policy can remove capacity. CloudWatch does not launch or terminate instances simply because it sees a metric; the Auto Scaling policy defines the scaling behavior and the alarm or target-tracking mechanism supplies the signal.

Common scaling signals include CPU utilisation, Application Load Balancer request count per target, and custom application metrics.

Lambda and CloudWatch

AWS Lambda publishes invocation metrics and can send function logs to CloudWatch Logs. Common metrics include:

• Invocations
• Errors
• Duration
• Throttles
• Concurrent executions

Typical Lambda logs include request start, application output, errors, and request completion information. The function execution role needs the appropriate logging permissions, and the runtime or application must write useful messages.

Lambda invocation
        ↓
CloudWatch Logs
        ↓
Logs Insights query or metric filter
        ↓
Alarm, dashboard, or notification

For example, an alarm can detect an elevated error count and invoke SNS or Lambda. CloudWatch can also trigger a Lambda function directly as an alarm action.

RDS and CloudWatch

Amazon RDS publishes database metrics to CloudWatch. Useful examples include:

• CPU utilisation
• Free storage space
• Database connections
• Read and write IOPS
• Read and write latency
• Replica lag where supported

RDS FreeStorageSpace becomes low
        ↓
CloudWatch alarm
        ↓
SNS notification to the database team

CloudWatch helps detect a condition; the remediation might be increasing storage, removing unnecessary data, changing the instance size, or investigating an application connection leak.

Application Load Balancer and CloudWatch

Application Load Balancers publish metrics such as:

• RequestCount
• TargetResponseTime
• HealthyHostCount
• HTTPCode_ELB_5XX_Count
• HTTPCode_Target_5XX_Count

A useful production alarm is:

HealthyHostCount = 0
        ↓
CloudWatch alarm
        ↓
SNS, incident workflow, or EventBridge

ALB metrics help distinguish load-balancer-side errors from target-application errors. A high HTTPCode_ELB_5XX_Count and a high HTTPCode_Target_5XX_Count point to different investigation paths.

API Gateway and CloudWatch

Amazon API Gateway publishes API metrics such as:

• Request count
• Latency
• Integration latency
• 4XX errors
• 5XX errors
• Cache metrics where caching is configured

API Gateway 5XX errors increase
        ↓
CloudWatch alarm
        ↓
SNS or Lambda notification

API Gateway metrics can be combined with Lambda, ALB, and application logs to follow a request through the architecture.

ECS, EKS, and CloudWatch Container Insights

Amazon ECS publishes cluster and service metrics, including running tasks and resource utilisation. ECS container logs can be sent to CloudWatch Logs using a supported log driver.

Amazon EKS and self-managed Kubernetes clusters can use CloudWatch Container Insights to collect cluster, node, pod, and container telemetry.

Container workload
        ↓
CloudWatch agent or Container Insights
        ↓
Metrics and logs
        ↓
Dashboard and alarms

Container Insights adds visibility beyond the basic service metrics. Confirm the required agent, permissions, and collection configuration for the cluster platform.

S3 and CloudWatch

Amazon S3 publishes storage and request-related metrics to CloudWatch. Common storage metrics include:

• BucketSizeBytes
• NumberOfObjects

Request metrics can be enabled for more detailed monitoring of S3 request activity. Storage metrics and request metrics have different availability and cost characteristics.

S3 bucket size grows unexpectedly
        ↓
CloudWatch metric or dashboard
        ↓
Alarm and cost or lifecycle investigation

CloudWatch does not replace S3 access logging, CloudTrail data events, or S3 Storage Lens for every use case. Choose the data source that answers the operational or security question.

CloudTrail and CloudWatch Logs

AWS CloudTrail records AWS API activity. You can configure a CloudTrail trail to deliver events to CloudWatch Logs, then use metric filters and alarms for security monitoring.

IAM or AWS API activity
        ↓
CloudTrail trail
        ↓
CloudWatch Logs
        ↓
Metric filter
        ↓
CloudWatch alarm
        ↓
SNS notification

Example detections include root-user activity, changes to security groups, disabling CloudTrail, or attaching a powerful IAM policy. CloudTrail answers “who did what and when”; CloudWatch provides the filtering, visualisation, and alerting layer.

VPC Flow Logs and CloudWatch Logs

VPC Flow Logs capture metadata about network traffic accepted or rejected by network interfaces, subnets, or VPCs. They can be delivered to CloudWatch Logs.

VPC Flow Logs show REJECT records
        ↓
CloudWatch Logs metric filter or Logs Insights query
        ↓
Alarm or security investigation

Flow Logs do not capture packet payloads. They are useful for identifying traffic patterns, rejected connections, unexpected sources, and connectivity problems, but they do not replace packet capture or application logs.

CloudWatch alarms and SNS

Amazon SNS is one of the most common CloudWatch alarm targets:

CloudWatch alarm
        ↓
SNS topic
        ├── Email
        ├── SMS where supported
        ├── Lambda
        ├── HTTP or HTTPS endpoint
        └── SQS or another subscriber

Using SNS decouples the alarm from individual recipients. Add or remove subscribers without changing every CloudWatch alarm.

CloudWatch and EventBridge

CloudWatch alarm state changes can be emitted to Amazon EventBridge. EventBridge can then route the event based on an event pattern:

CloudWatch alarm changes state
        ↓
EventBridge rule
        ↓
Lambda, SNS, Step Functions, or incident workflow

EventBridge also receives many AWS service events independently of CloudWatch metrics. Use CloudWatch alarms for threshold or metric conditions, and EventBridge for matching structured service events and state changes.

CloudWatch and Systems Manager

CloudWatch alarms can create Systems Manager OpsItems or Incident Manager incidents. A Lambda function or Systems Manager automation can also be used for a controlled response.

CPU or status condition breaches threshold
        ↓
CloudWatch alarm
        ↓
Systems Manager OpsItem or Incident
        ↓
Runbook and human-approved remediation

For example, an alarm might create an incident and run a documented automation workflow. Avoid automatically restarting or terminating production resources without safeguards, approvals, and a recovery plan.

IAM and CloudWatch

CloudWatch does not directly provide a complete audit record of IAM activity. The common security path is:

IAM API call
        ↓
CloudTrail
        ↓
CloudWatch Logs
        ↓
Metric filter or Logs Insights query
        ↓
CloudWatch alarm

For example, an organisation can detect suspicious root-user use or a change to an administrator policy. CloudTrail is the source of API activity; CloudWatch is the monitoring and alerting layer.

The complete CloudWatch ecosystem

AWS service	CloudWatch input	Typical CloudWatch response
EC2	CPU, network, status checks	SNS, EC2 action, Auto Scaling
Auto Scaling	Uses metrics and scaling policies	Adds or removes capacity
Lambda	Logs, errors, duration, throttles	SNS, Lambda, dashboard
RDS	CPU, storage, connections, IOPS	SNS and database investigation
ALB	Requests, latency, healthy targets, 5XX	SNS and incident workflow
API Gateway	Requests, latency, 4XX, 5XX	SNS or Lambda
ECS	Cluster, service, task metrics and logs	Dashboard and alarms
EKS	Container Insights metrics and logs	Dashboard and alarms
S3	Storage and optional request metrics	Alarm and cost investigation
CloudTrail	API activity logs	Metric filters and security alarms
VPC Flow Logs	Network flow records	Logs queries and security alarms
EventBridge	Alarm state and service events	Rules and automated targets
SNS	Alarm notification fan-out	Email, Lambda, SQS, HTTP
Systems Manager	Alarm-driven incidents and OpsItems	Runbooks and operations

How to choose the right integration

Need a threshold on a number?
→ CloudWatch metric + alarm

Need to search application or audit text?
→ CloudWatch Logs + Logs Insights

Need a metric from a log pattern?
→ CloudWatch Logs metric filter

Need to notify multiple subscribers?
→ CloudWatch alarm → SNS

Need to change capacity?
→ CloudWatch signal → Auto Scaling policy

Need to react to a structured AWS event?
→ EventBridge rule

Need to audit who called an AWS API?
→ CloudTrail, optionally delivered to CloudWatch Logs

Common exam questions

An EC2 instance’s CPU exceeds a threshold and capacity must increase.

Use a CloudWatch alarm or scaling policy with an EC2 Auto Scaling group.

A Lambda function produces too many errors.

Use Lambda metrics or CloudWatch Logs with a CloudWatch alarm.

You need an email when an alarm enters ALARM state.

Send the alarm to an SNS topic with an email subscription.

You need to detect root-user API activity.

Use CloudTrail, deliver events to CloudWatch Logs if needed, then use a metric filter and alarm.

You need to know whether a Regional AWS infrastructure problem affects your account.

Use AWS Health Dashboard, covered in Part 49, not CloudWatch alone.

You need to react to a service event rather than a numeric threshold.

Use an EventBridge event pattern; CloudWatch alarm state changes can also be delivered to EventBridge.

Final memory trick

AWS services → CloudWatch
        ↓
Metrics + Logs + Events
        ↓
CloudWatch alarm or query
        ↓
SNS | Lambda | Auto Scaling | Systems Manager | EventBridge

Remember:

• CloudWatch = monitor my workload
• CloudTrail = record my API activity
• AWS Health = report AWS service and infrastructure events
• EventBridge = route structured events
• SNS = fan out notifications
• Auto Scaling = change capacity
• Systems Manager = operational response and runbooks

The exam takeaway is: CloudWatch collects and analyses telemetry; configured alarms and integrations turn that telemetry into notifications, scaling, and automated operations.

Sources

• What is Amazon CloudWatch?
• AWS services that publish CloudWatch metrics
• CloudWatch alarm actions
• CloudWatch alarm events and EventBridge
• Basic and detailed monitoring