AWS re/Start Lab · Monitoring

Managing Services & Monitoring

Learn to interact with background system services like the Apache HTTP server, and utilize real-time monitoring tools such as CloudWatch to evaluate system health.

AWS Services Used

Amazon EC2

Hosted the Amazon Linux 2 instance and the Apache Web Server application.

AWS CloudWatch

Monitored EC2 infrastructural performance including CPU, memory, and disk reads.

Step-by-Step Walkthrough

Detailed record of each task performed during the lab.

01

SSH Connection

  • Connected to the EC2 instance via PuTTY following the process described in Lab 225.
02

Manage the httpd Service

  • Checked the service status using sudo systemctl status httpd.service and observed it was loaded but inactive (dead).
  • Started the Apache web server by executing sudo systemctl start httpd.service.
  • Validated the status again with sudo systemctl status httpd.service, revealing it was now active and running.
  • Opened a new browser tab using the instance's public IP address (e.g., http://52.39.0.27/) to confirm the Apache HTTP Server Test Page loaded successfully.
  • Halted the web server using sudo systemctl stop httpd.service.
Terminal displaying active status of the httpd service
Terminal: Starting the httpd service changes status to running
Browser showing the Apache test page
Browser: Connecting to the instance's public IP verifies HTTP access
The httpd daemon operates in the background to serve HTTP requests. By default, Amazon Linux 2 does not automatically start this service upon install.
03

Monitor the Linux Instance

  • Displayed running processes locally utilizing the top command.
  • Ran a workload simulation script with ./stress.sh & top, spiking CPU percentage used by the stress command.
  • Logged into the AWS Management Console and navigated to AWS CloudWatch.
  • Opened the EC2 Automatic dashboard to visualize metrics like CPU Utilization, DiskReadBytes, and NetworkIn.
  • Observed the spike in the CPU Utilization graph matching the time the stress.sh script ran.
  • Waited 5 minutes to confirm the CPU utilization dropped back down when the script terminated.
AWS CloudWatch dashboard showing CPU, Disk, and Network metrics
AWS CloudWatch: Dashboard visualizing spikes in EC2 infrastructural usage

Command Reference

Commands utilized for system service management.

cmd

systemctl

Used to introspect and control the state of the systemd system and service manager.

  • status [service.name] : Prints the execution state of the specified target
  • start [service.name] : Initiates the background daemon
  • stop [service.name] : Halts the background daemon gracefully

Key Learnings

What Was Learned

✓
Differences between loaded/inactive versus active/running daemon states using systemctl.
✓
How to manually boot and test a lightweight Apache web server inside an EC2 instance.
✓
Correlating terminal-based resource stress tests (top) with GUI-based metrics (CloudWatch).
✓
Locating the Automatic EC2 Dashboard within CloudWatch to assess network and disk I/O.

Technical Conclusion

Direct service management through systemctl allows granular control over which background applications consume hardware quotas. Proper verification demands both checking internal daemon status and confirming external accessibility (e.g., loading the web page).

By combining local terminal observability (top) with vast data aggregation platforms like AWS CloudWatch, operators can accurately diagnose infrastructural limits and scale instances proactively upon detecting consistent CPU spikes.