Why Alarms Matter in Cloud Infrastructure
In any modern cloud-based architecture, monitoring and alerting play a critical role in maintaining reliability, performance, and security.
It's not enough to just have logs—you need a way to act on those logs when something goes wrong. That's where CloudWatch alarms come in.
Imagine a situation where your application starts throwing 5xx errors, and you don't know until a customer reports it. By the time you act, you've already lost trust.
Alarms prevent this reactive chaos by enabling proactive monitoring—you get notified the moment an issue surfaces, allowing you to respond before users even notice.
Without proper alarms:
You might miss spikes in 4xx/5xx errors.
You're always proactive instead of reactive.
Your team lacks visibility into critical system behavior.
Diagnosing issues becomes more difficult due to a lack of early signals.
Due to all the reasons Above, that's why I decided to implement AWS CloudWatch Alarms using Metric Filters—a cost-effective, powerful way to monitor logs and trigger alerts based on specific patterns.
Why To Choose CloudWatch
We choose Amazon CloudWatch because:
It integrates tightly with other AWS services.
It offers native support for metric filtering and alarms.
It's scalable and works well with EC2 instances, ECS, EKS, Lambda, etc.
It's cost-effective for log-based monitoring.
Instead of pushing logs to third-party tools, we kept everything inside AWS for tighter security and easier maintenance.
Do you also want to know How I integrate the CloudWatch Follow the Steps Below.
Step 1: Install the CloudWatch Agent (For EC2 Logs)
👉 Official AWS Setup Link:
After installation:
Create a custom config file to push only needed logs (to reduce noise and cost).
👉 Full example config and Metrics Filters available on my GitHub: https://github.com/Naresh-b17/cloud-watch-alarms/tree/main
️ Step 2: Create an IAM Role for CloudWatch Agent
Minimum IAM Permissions:
logs:CreateLogGroup
logs:CreateLogStream
logs:PutLogEvents
cloudwatch:PutMetricData
Attach this role to your EC2 instance running the CloudWatch Agent.
Step 3: Create Metric Filters for Your Log Group
Go to:
Examples:
✅ 4xx Errors:
[...statusCode=%4[0-9]{2}%...]
✅ 5xx Errors:
[...statusCode=%5[0-9]{2}%...]
👉 Full example config and Metrics Filters available on my GitHub: https://github.com/Naresh-b17/cloud-watch-alarms/tree/main
For Each Filter:
Click Test Pattern
Create Metric → Give Namespace (Example: Custom/ALB/ErrorMetrics)
Step 4: Setup SNS (Simple Notification Service) for Alerts
SNS = Your Notification Pipeline
If you don’t have an SNS Topic:
To Add Email Recipients:
Open the SNS Topic
Create Subscription → Protocol: Email → Enter Email IDs → Create
Team members will get a confirmation email (They must click confirm!)
In your Alarm setup, select this SNS topic under Notification section.
Step 5: Create CloudWatch Alarms on These Metrics
Once your Metric Filters are in place and actively generating metrics, it's time to put CloudWatch Alarms into action. This is where the magic happens—turning raw log patterns into real-time alerts.
Example Alarm Scenarios:
If 5xx errors > 5 within 5 minutes → Trigger an Alert
If 4xx errors > 10 within 10 minutes → Trigger an Alert
If Large payloads (>100KB) exceed 50 events in 1 hour → Trigger an Alert
Detailed Steps to Create Alarms:
Go to AWS Console → CloudWatch → Alarms → Create Alarm
Click Select metric → Choose “Log Metrics”
Browse and select your custom metric (created earlier using Metric Filters)
Click Select Metric
Under Conditions:
Choose the threshold type (Static/Anomaly detection)
Set threshold value (example: Greater than 5 errors)
Choose datapoint evaluation (e.g., 1 out of 1 datapoint breaching threshold)
Under Actions:
Select an existing SNS topic or create a new one (SNS setup explained next)
Add a name and description for easy identification (e.g., ALB-5XX-Error-Alarm)
Click Create Alarm
Comments
Post a Comment