CloudWatch Log Metric Filter Lab

Goal

Reinforce Logs versus metrics, Metric filters, Alarms, Operational evidence through a small, inspectable activity. This is a learning exercise, not a production design: use a dedicated sandbox or test account, record what you observe, and do not copy the permissions or data-handling choices into production without review.

What you should be able to explain afterward: what AWS managed for you, what you configured, what evidence proves the result, and what could continue to cost money or expose data if you leave it behind.

Concepts Reinforced

• Logs versus metrics
• Metric filters
• Alarms
• Operational evidence

Prerequisites

• AWS CLI configured
• Permission to create CloudWatch Logs resources and alarms

Before you start

1. Choose one AWS Region and write it down; many resources and console views are Region-specific.
2. Confirm that you are operating only in an authorized non-production account and that you can identify the account ID before creating anything.
3. Open the AWS service documentation linked below if a console label or command option is unfamiliar. The lab is successful when you understand the observation, not when you click through it quickly.

Estimated Cost

Exact Steps

Read the entire sequence before beginning. Substitute your own test names for every placeholder, keep the Region consistent, and pause after each step to inspect the result. If a command returns an error, do not repeatedly retry it without reading the error: check Region, account, permissions, resource identifiers, and whether the preceding step actually completed.

1. Create a temporary log group.
2. Put a metric filter that counts lines containing ERROR.
3. Create an alarm on the custom metric.
4. Write a sample log event that contains ERROR.
5. Observe metric/alarm behavior after CloudWatch processes the event.

aws logs create-log-group --log-group-name /djames/study/cloudwatch
aws logs put-metric-filter --log-group-name /djames/study/cloudwatch --filter-name ErrorCount --filter-pattern "ERROR" --metric-transformations metricName=StudyErrorCount,metricNamespace=DJamesStudy,metricValue=1
aws cloudwatch put-metric-alarm --alarm-name DJamesStudyErrorAlarm --namespace DJamesStudy --metric-name StudyErrorCount --statistic Sum --period 60 --evaluation-periods 1 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold

Verification

Verification is the evidence that the concept worked. Capture the relevant ARN, status, identity, log entry, policy result, object version, or query output before cleanup. A successful command alone is not proof that the intended control behaved correctly.

• The metric filter exists.
• The custom metric appears in CloudWatch.
• The alarm can be described by name.

If the result is different

• Confirm the selected Region and AWS account.
• Check the exact resource identifier and current status.
• Review the service event history, CloudTrail event, CloudWatch log, or command output when available.
• Re-read the relevant IAM policy, trust policy, security rule, or service setting instead of assuming the service is at fault.

Cleanup Steps

Cleanup is part of the lab. Remove test resources in dependency order, delete temporary credentials or local files, and check the billing or resource console for anything that remains. Some services retain versions, snapshots, logs, or recovery artifacts even after the visible parent resource is deleted.

• Delete the alarm.
• Delete the metric filter.
• Delete the log group.

Sources and Review Metadata