AWS re/Start Lab · Seguridad

Monitor an EC2 Instance with CloudWatch Alarms

This lab contrasts the disciplines of logging and monitoring to achieve a unified security and performance baseline. Establish automated metrics tracking utilizing CloudWatch, hook alerts into Amazon SNS, and synthetically stress test EC2 instances to emulate adversarial CPU hijacking (e.g., Crypto-miners).

Lab Summary

Established an architecture utilizing Amazon SNS to deliver administrative alerts natively triggered by an integrated Amazon CloudWatch Metric Alarm when EC2 utilization patterns breach predefined bounds.

Automated Workflows

Created robust Notification Topics within SNS and bound Email endpoints as subscribers. Configured CloudWatch to actively monitor EC2 and evaluate performance against a 60% CPU utilization ceiling cap over 1-minute intervals.

Emulated Threshold Validation

Validated the infrastructure by artificially stressing the instance utilizing the Linux stress utility, successfully pushing the system into an In Alarm state and firing the notification to immediately alert DevOps.

Step-by-Step Walkthrough

Detailed documentation spanning the integration of SNS Notification Topics to CloudWatch Dashboard mapping.

01

Configure Amazon SNS

  • Accessed Simple Notification Service (SNS) and deployed a Standard Topic labeled MyCwAlarm.
  • Created a new subscriber bound to the topic specifying the Email protocol.
  • Authenticated the endpoint externally by confirming the subscription through the automatically delivered verification email link.
Email Subscription Confirmed
AWS SNS: Assuring the external Email endpoint holds a "Confirmed" validation status
02

Create a CloudWatch alarm

  • Examined historical metric data under CloudWatch > Metrics > EC2 > Per-Instance Metrics specifying the CPUUtilization filter targeting the Stress Test machine.
  • Transitioned into building an Alarm measuring the Average statistics over a 1-minute evaluation period.
  • Defined a static threshold determining that the alarm initializes whenever the CPUUtilization grows greater than (>) 60%.
  • Tied the In alarm state trigger to seamlessly dispatch an event payload straight to the MyCwAlarm SNS topic.
CloudWatch Alarm Configuration settings
Amazon CloudWatch: Reviewing the active threshold settings governing the alarm rule
03

Stress test and validate the CloudWatch alarm

  • Connected to the EC2 Instance remotely operating under AWS Systems Manager constraints.
  • Injected an artificial system load executing sudo stress --cpu 10 -v --timeout 400s causing CPU utilization to rapidly spike toward 100%.
  • Utilized a parallel terminal instance running the top command viewing live CPU process metrics.
Active Stress Test Execution alongside Top Output
EC2 Terminal: Utilizing the stress package to max out internal compute
SNS Notification Email Delivered
External Email Client: Alert generated indicating a threshold breach triggered by CloudWatch
04

Create a CloudWatch dashboard

  • Constructed a customized visualization homepage under CloudWatch > Dashboards.
  • Added a continuous Line widget specifically plotting the previously stressed EC2 Instance's CPUUtilization.
  • Saved the visual framework, delivering an immediate high-level abstraction monitoring tool to quickly detect infrastructure anomalies directly at login.
Live CloudWatch Visualization Dashboard
Amazon CloudWatch: Tracking metric histories centralized within custom dashboards

Command Reference

Quick reference of alternative utilities leveraged internally interacting with system limits via CLI.

cmd

stress

A tool that imposes a configurable amount of CPU, memory, I/O, or disk stress on a POSIX-compliant operating system.

  • stress --cpu <N> --timeout <S>s : Spawns N workers spinning on sqrt() for S seconds.
cmd

top

Displays processor activity of Linux boxes actively providing an ongoing look at processor usage in real-time.

Key Learnings

What Was Actually Learned

✓
The conceptual discrepancies between deep low-level Logging and actionable analytical Monitoring architectures.
✓
How to chain multiple managed services (CloudWatch + SNS) enabling near-instant incident response.
✓
How to leverage Linux applications mimicking excessive unauthorized computational utilization simulating malware conditions.

Technical Conclusion

Relying simply on static security rulesets is inefficient for modern architectures. Threat actors finding entry points will routinely deploy resource intensive, often obfuscated toolkits. Coupling alerting capabilities to threshold-based anomalies allows Administrators to rapidly discern and terminate breaches otherwise quietly draining AWS credits.