AWS Monitoring & Alerting Stack (Terraform)

Infrastructure-as-Code project that provisions a complete CloudWatch observability pipeline on AWS: an EC2 instance is monitored via a CloudWatch dashboard (CPU + Network) and a CPU alarm that notifies subscribers by email through SNS.

Built to practice Terraform/IaC and apply the observability patterns I use in production (New Relic / Splunk / PagerDuty) to AWS-native tooling.

Architecture

EC2 (Ubuntu, t2.micro) --metrics--> CloudWatch (Dashboard + CPU Alarm)
|
alarm breaches threshold
v
SNS Topic --> Email subscriber\

What it provisions

File	Resources
aws-vpc.tf	VPC, public subnet, internet gateway, route table + association
aws-sg.tf	Security group + ingress/egress rules
aws-kp.tf	EC2 key pair (from local public key)
instance.tf	Ubuntu AMI data source + EC2 instance
aws-cloudwatch.tf	CPU metric alarm + dashboard (CPU & NetworkIn widgets)
aws-sns.tf	SNS topic + email subscription
provider.tf / terraform.tf	AWS provider & Terraform config
variables.tf / outputs.tf	Inputs and outputs

Prerequisites

• AWS account (Free Tier) with credentials configured via aws configure
• Terraform installed
• An SSH key pair — generate one in the project dir: ssh-keygen -t rsa -b 4096 -f id_rsa (The public key id_rsa.pub is read by Terraform; keys are gitignored.)

Usage

terraform init
terraform plan
terraform apply # then confirm the SNS email subscription (check spam!)
terraform destroy # tear down when done\

Testing the alarm

Force the pipeline instantly:
aws cloudwatch set-alarm-state --alarm-name "terraform-cpu-alert"
--state-value ALARM --state-reason "Manual test"
Or trigger it naturally by stressing CPU on the instance:
sudo apt update && sudo apt install stress -y
stress --cpu 2 --timeout 600\

Key design decisions (observability notes)

• period = 300 — EC2 basic monitoring emits CPU every 5 min, so the alarm evaluates the 5-minute average, not instantaneous spikes.
• evaluation_periods = 2 — CPU must stay above 50% for 2 datapoints (10 min) before firing, which avoids false alarms on transient spikes and reduces alert fatigue.
• CPU is hypervisor-level (no agent needed). Memory/disk would require the CloudWatch Agent (CWAgent namespace) — a planned enhancement.

Security notes

• AWS credentials are supplied via the local credential chain (aws configure), not committed to the repo.
• SSH (port 22) is restricted to my own IP via cidr_ipv4.

Future enhancements

• Memory monitoring via CloudWatch Agent
• CloudWatch Logs + metric filters
• Refactor into reusable modules with remote state (S3 + DynamoDB)

Author

Tushar Kashyap — SRE / DevOps Engineer · linkedin.com/in/terrykashyap