Launching an Amazon EC2 instance is only the beginning of running an application in the cloud. A real operations team must know whether the server is healthy, whether CPU usage is rising, whether the operating system is running out of disk space, and whether an important failure needs immediate attention. This AWS EC2 monitoring project shows beginners how to connect Amazon EC2, Amazon CloudWatch, Amazon SNS and AWS Lambda to create a practical alerting workflow.
The project is designed as a portfolio lab. You will launch an Ubuntu server, install Nginx, observe EC2 metrics, create alarms, receive an email notification and optionally invoke a Lambda function when an alarm changes state. The purpose is not simply to click through the AWS console. The purpose is to understand how monitoring data becomes an operational decision.
What will you build?
You will build a small web server monitoring system with this flow:
- An Ubuntu EC2 instance runs the Nginx web server.
- Amazon CloudWatch collects available EC2 metrics such as CPU utilization and status checks.
- The CloudWatch agent sends operating-system metrics such as disk usage when it is installed and configured.
- A CloudWatch alarm evaluates a defined threshold over a selected period.
- An Amazon SNS topic sends an email when the alarm changes state.
- An optional Lambda function performs a controlled automated action or records additional information.
This architecture teaches an important cloud principle: monitoring should produce a useful signal, and that signal should reach the correct person or automation system. A dashboard alone is not enough if nobody checks it during a failure.
AWS services used in the monitoring project
Amazon EC2
Amazon EC2 provides the virtual server. For a beginner lab, an Ubuntu instance with a suitable low-cost instance type is enough. The instance needs a security group that allows SSH only from your trusted IP address and HTTP traffic on port 80 for testing Nginx. Avoid allowing SSH from every IPv4 address unless a short-lived lab absolutely requires it.
Amazon CloudWatch
CloudWatch receives metrics, stores logs, displays dashboards and evaluates alarms. EC2 publishes several infrastructure metrics automatically. CPUUtilization is commonly used in beginner projects. EC2 status-check metrics help identify system-level or instance-level problems. Disk space inside the operating system is different: it is not a standard EC2 metric, so the CloudWatch agent must be installed and configured to publish it.
Amazon SNS
Amazon Simple Notification Service distributes messages to subscribers. In this project, an SNS topic has an email subscription. The subscription remains pending until the recipient clicks the confirmation link. A CloudWatch alarm can then use the topic as an alarm action.
AWS Lambda
Lambda is optional in the first version. It can receive an event and perform a small automated task without maintaining another server. For example, it could add context to an alert, create a support record through an approved API, or tag a lab resource. Any function that changes infrastructure needs a carefully restricted IAM role and testing before production use.
Prerequisites and safety checks
Before starting, choose one AWS Region and create all project resources in that Region. Keep a simple resource list containing the instance ID, security group, SNS topic, alarms, IAM role and Lambda function. This makes troubleshooting and cleanup easier.
Use an IAM identity with the permissions required for the lab instead of using the root user. Turn on multi-factor authentication for important identities. Set an AWS Budget for learning accounts and remember that some services or configurations can create charges. Pricing and Free Tier eligibility can change, so check the current AWS pricing pages before keeping resources running.
Step 1: Launch the EC2 Ubuntu web server
- Open the EC2 console and choose the correct Region.
- Launch an Ubuntu AMI using an instance type appropriate for your account and lab.
- Create or select a key pair if you plan to use SSH.
- Create a security group that allows HTTP on port 80 and limits SSH on port 22 to your trusted source IP.
- Launch the instance and record its instance ID and public address.
- Connect to the server and update the available package information.
- Install Nginx, start the service and enable it to start after a reboot.
- Open the public address in a browser and verify that the Nginx page loads.
This validation matters because the later alarm should monitor a known working resource. If Nginx is not reachable, check the instance state, public addressing, route to the internet gateway, security-group rules and the Nginx service before moving forward.
Step 2: Create an SNS email notification
- Open Amazon SNS and create a standard topic with a clear name such as
ec2-operations-alerts. - Create an email subscription and enter an address that you can verify.
- Open the confirmation email and confirm the subscription.
- Return to SNS and verify that the subscription status is confirmed.
- Use the publish option to send a harmless test message before connecting the topic to an alarm.
If the test email does not arrive, check the subscription status, spam folder and recipient address. CloudWatch cannot deliver an alarm notification to an unconfirmed email subscription.
Step 3: Create a CPU utilization alarm
Open CloudWatch, select the EC2 per-instance CPUUtilization metric and choose the correct instance. For this lab, you can create an alarm when average CPU usage is greater than 80 percent for a chosen number of evaluation periods. Select the SNS topic as the notification action.
The exact period and number of datapoints should match the purpose. A very short period may create noise from temporary spikes. A very long period may delay a useful response. In a learning project, document why you chose the threshold and how you would tune it after observing normal behavior.
CloudWatch alarms commonly show three states: OK, ALARM and INSUFFICIENT_DATA. An alarm action normally runs when the alarm changes state. That means repeatedly receiving the same alert is not guaranteed while the alarm remains unchanged. Understanding state transitions helps you explain why a test notification behaved in a particular way.
Step 4: Monitor EC2 status checks
Create another alarm for a relevant EC2 status-check metric. System status checks identify issues related to the AWS infrastructure that hosts the instance. Instance status checks identify problems that may require attention inside the instance, such as networking or operating-system behavior. A combined status-check metric is useful when the first goal is simply to notify an operator that the instance is unhealthy.
Use a different alarm name and include the instance purpose in the description. Clear names make dashboards and emails easier to understand when an account contains several servers.
Step 5: Add disk-usage monitoring
Disk-used percentage is an operating-system metric, so install the unified CloudWatch agent on Ubuntu. Create an IAM role for the instance with only the permissions required to publish monitoring data, attach the instance profile and configure the agent to collect the disk percentage for the required filesystem.
After starting the agent, check the CloudWatch agent log on the server and then look for the custom metric in CloudWatch. Do not create the disk alarm until the metric is visible. A practical threshold may warn before the disk is completely full, giving the team time to remove temporary files, rotate logs or expand storage through an approved change.
A frequent beginner mistake is searching for disk percentage among the default EC2 metrics. EC2 exposes storage performance metrics for EBS-backed workloads, but filesystem capacity inside Linux requires information from the guest operating system. This distinction is an excellent interview point.
Step 6: Add controlled Lambda automation
After email alerts work, subscribe a Lambda function to a suitable event path or configure an appropriate alarm action. Keep the first function simple. It can read the event, write structured information to CloudWatch Logs and return successfully. This proves the integration without changing production resources.
If you later automate a response, apply least privilege. For example, a function that is intended to tag one lab instance should not receive broad administrator access. Add conditions and resource restrictions where the AWS service supports them. Automation should also be idempotent, meaning repeated execution does not create harmful duplicate changes.
How to test the project safely
First test SNS independently. Next verify that metrics are arriving. Then test one alarm at a time. For CPU testing, use a controlled workload for a short period and watch the metric graph. Stop the workload after the alarm changes state. Never run an unknown stress command on an important server.
For disk monitoring, avoid filling the root volume until the instance becomes unstable. Use a safe test environment and a small controlled file, or temporarily lower the alarm threshold below the current measured value. Restore the intended threshold after validation. Record screenshots of the metric graph, alarm history, received email and Lambda log entry for your project evidence.
Troubleshooting common problems
- No email: confirm the SNS subscription and verify that the alarm action points to the correct topic and Region.
- Alarm stays in INSUFFICIENT_DATA: confirm that the correct metric, dimensions, period and instance were selected.
- No disk metric: check the instance IAM role, CloudWatch agent configuration, agent service and agent logs.
- Website does not open: check Nginx, security groups, routing, addressing and the instance state.
- Lambda access denied: review the execution role and add only the exact actions and resources required.
- Too many alerts: adjust the evaluation periods or threshold after reviewing normal server behavior.
How to explain this AWS project in an interview
Start with the business problem: an application server needed automatic health visibility. Explain that EC2 ran Nginx, CloudWatch collected infrastructure and agent-based metrics, an alarm evaluated thresholds, SNS notified the operator, and Lambda demonstrated an automated response. Then explain one security decision, such as restricting SSH or using an EC2 IAM role instead of storing access keys.
Finish with evidence and improvement ideas. You can mention dashboards, log-based alarms, Systems Manager access, multiple notification channels, infrastructure as code and an incident runbook. A good project explanation connects services to an operational purpose instead of only listing AWS names.
Build the next AWS projects
Monitoring becomes more valuable when applications are deployed consistently. Continue with the AWS CI/CD pipeline project using GitHub, Jenkins, Docker and EC2 to understand automated builds and deployments. To place web and database resources in controlled network layers, complete the AWS VPC project with public and private subnets.
Learners who want structured guidance across EC2, IAM, VPC, S3, RDS, Lambda, CloudWatch and practical labs can explore AWS training in Vizag at Softenant Technologies.
Frequently asked questions
Does EC2 automatically publish Linux disk-used percentage?
No. Filesystem disk-used percentage is collected from inside the operating system, so the CloudWatch agent or another approved monitoring solution is required.
Can CloudWatch send an email directly?
A common design is to connect the CloudWatch alarm to an SNS topic and subscribe an email address to that topic. The recipient must confirm the subscription.
Should Lambda automatically stop an instance when CPU is high?
Not by default. High CPU may indicate useful work or a scaling requirement. Start with notification and investigation. Add automated remediation only when the action is safe, approved and tested.
What should be included in the portfolio?
Include the architecture flow, resource list, alarm settings, screenshots, test result, troubleshooting notes, security controls, cost cleanup and a short explanation of what you would improve for production.
Conclusion
This AWS EC2 monitoring project moves beyond launching a server. It teaches how to observe infrastructure, detect unhealthy conditions, notify the correct person and introduce controlled automation. When you can explain why each metric, threshold, role and notification exists, the project becomes strong evidence of practical cloud operations knowledge.