CloudWatch Logs, Metrics, and Alarms for Security

CloudWatch is a monitoring service from Amazon Web Services (AWS). It collects data from your AWS resources — like virtual servers (Amazon EC2 instances), databases (Amazon RDS), and serverless functions (AWS Lambda). CloudWatch then helps you visualise, analyse, and act on that data. It has three main parts: Logs, Metrics, and Alarms. Each part serves a different purpose but they work together to give you a complete security picture.

CloudWatch Logs are the raw records of events. When something happens inside an AWS resource, it produces a log entry. For example, when someone tries to log into a server and fails, that attempt appears in a log. When an API call is made to delete a storage bucket (Amazon S3 bucket), CloudTrail (a separate service) sends that event to CloudWatch Logs. Logs are text-based, meaning you can read them, search them, and filter them. They are like the security guard’s notebook — every action gets recorded.

Why do logs matter for security? Because attackers leave digital footprints. A brute-force login attack might show hundreds of failed logins in a short period. An unauthorised data download might appear as a large transfer from an unusual IP address. CloudWatch Logs stores these events so you can investigate later. You can also send logs to other AWS services, like Amazon OpenSearch Service, to run complex searches.

CloudWatch Metrics are numerical measurements taken at regular intervals. Instead of reading a text event, you get a number. For example, the CPU utilisation of your EC2 instance might be recorded every minute. The number of HTTP 403 (Forbidden) errors from your web server count is another metric. Metrics are efficient — they take less storage than raw logs and are easy to graph. Think of them as the guard’s clipboard: "At 9am, there were 120 people in the building. At 10am, there were 145 people."

You do not have to create metrics manually. AWS automatically sends many metrics to CloudWatch for its services — these are called standard metrics. CPU utilisation, disk reads, network traffic — all covered. But you can also create custom metrics. For instance, you might send the number of failed login attempts per minute from your application. Custom metrics give you control over exactly what you measure.

CloudWatch Alarms are automated rules that watch a metric and do something when the metric crosses a threshold. For example, you could create an alarm that triggers when CPU utilisation exceeds 80% for five minutes. The alarm can send a notification via SNS (an email or text message to an administrator), or it can trigger an automated response, like launching a new EC2 instance to handle the load (using Auto Scaling). For security, alarms are vital. You might set an alarm when the number of failed SSH login attempts exceeds ten in five minutes. When that happens, the alarm sends a notification to your security team.

Alarms work on three states: OK (all good), ALARM (threshold breached), and INSUFFICIENT_DATA (not enough data to decide). You can also set the number of evaluation periods — meaning the alarm must breach the threshold for multiple consecutive periods before alarming, to avoid false positives from temporary spikes.

CloudWatch Logs, Metrics, and Alarms together create what is called observability. You can see what is happening (logs), measure how much it is happening (metrics), and get notified when something is wrong (alarms). This replaces the old method of manually checking servers or relying on users to report problems. It is automated, scalable, and centralised.

For the SCS-C02 exam, you also need to know about CloudWatch Logs Insights. This is a query language that lets you search and analyse logs in real time. For instance, you could run a query to find all log entries from the last hour that contain the words "UnauthorizedOperation". That helps you rapidly identify security events without reading every log line.

CloudWatch also integrates with AWS CloudTrail, which records API activity in your account. CloudTrail logs can be sent to CloudWatch Logs, giving you both resource-level events (from CloudTrail) and system-level events (from your operating systems and applications) in one place.

One important distinction: CloudWatch is for monitoring what is happening now and recently. It is not a long-term archive by default. Logs can be stored for a configurable retention period (from 1 day to forever). For cost reasons, you might keep recent logs in CloudWatch for quick access and move older logs to Amazon S3 (cheaper long-term storage) or Amazon Glacier (even cheaper archival storage). This is called log lifecycle management.

Finally, consider permissions. Not everyone in your organisation should be able to view logs or create alarms. AWS Identity and Access Management (IAM) lets you control who can read logs, who can create alarms, and who can delete them. This is critical for security — you do not want an attacker to be able to see your security logs or disable your alarms.

Imagine you work as a security engineer for an e-commerce company that runs its website on AWS. This website handles customer orders, payment details, and personal data. You must ensure that if an attack happens, you can detect it quickly and respond.

Every day, you start by checking CloudWatch dashboards. These are customisable views that show your most important metrics at a glance. You look at a dashboard showing the number of HTTP 500 (server error) responses from your web servers. If that number suddenly jumps, it might mean an attacker is trying to exploit a vulnerability. You also look at a metric tracking the number of unique IP addresses connecting to your database — a sudden increase could indicate a data scraping attempt.

At 10:15am, you receive an email from a CloudWatch Alarm. The alarm is named "SSH-Brute-Force". It triggered because the metric "FailedSSHAttempts" exceeded 20 in five minutes. You open the CloudWatch Logs console and search for log entries from the specific EC2 instance that reported the high number. Using CloudWatch Logs Insights, you run a query:

fields @timestamp, @message | filter @message like /Failed password/ | sort @timestamp desc | limit 50

This shows you the exact times of each failed login attempt, the usernames attempted, and the source IP addresses. You see dozens of attempts from an IP address in a country where your company has no customers. That looks like a brute-force attack. You then escalate: you block that IP address using an AWS Network Firewall rule and notify your security team.

After handling the incident, you refine your monitoring. You notice the alarm only looked at one EC2 instance, but you have ten instances. An attacker might spread login attempts across multiple instances to avoid triggering any single alarm. So you create a new custom metric that aggregates all failed SSH attempts across all instances — a global count. You set an alarm on that aggregate metric with a lower threshold, because the distributed attack might otherwise go undetected.

Later, you audit your CloudWatch Logs retention policy. You currently keep logs for 30 days. For security investigations, you often need logs from more than six months ago. You create a lifecycle policy to automatically export logs older than 30 days to an S3 bucket. In S3, you can store them for years at low cost. You also enable S3 server access logging and CloudTrail logging to that same bucket, so all evidence is in one place.

Finally, you review IAM permissions. You discover that a junior developer accidentally deleted an important log group yesterday because their IAM role had too broad permissions. You change the policy so that only senior engineers can delete log groups, while developers can only read and query logs. This prevents accidental or malicious deletion of evidence.

Throughout this entire process, CloudWatch Metrics, Logs, and Alarms work in sync. Metrics gave you the big picture numbers. Logs provided the detailed evidence. Alarms woke you up when something needed immediate attention. Without these three tools, you would be blind to attacks and unable to prove what happened during an incident.