Event-Driven Website Monitoring System on AWS

This project was completed as one of the capstone projects in the Digital Cloud Training 'AWS Solutions Architect (Associate)' module. The project brief was provided as part of the course, while the architecture, implementation, testing and documentation shown here are my own work.

The objective was to create an event-driven monitoring solution that automatically checks website availability and sends email notifications based on the result.

The monitored website was hosted as a private static website on AWS. The monitoring components were implemented using AWS Lambda, Amazon EventBridge Scheduler and Amazon SNS.

Key requirements:

Use a fully serverless architecture with no continuously running compute resources.
Check the public CloudFront website endpoint automatically on a defined schedule.
Send email notifications for both successful and failed availability checks.
Keep IAM permissions limited to the actions and resources required by each component.
Test both healthy and unavailable website states end to end.

Amazon EventBridge Scheduler invokes a Lambda function at regular intervals. The function sends an HTTPS request to the website's CloudFront URL and evaluates the returned response.

The website content is stored in a private S3 bucket and can be accessed only through CloudFront using Origin Access Control. This allows the monitoring function to test the same public endpoint that a real website visitor would use rather than checking the underlying storage service directly.

After evaluating the result, Lambda publishes a status message to an SNS topic. Amazon SNS then delivers the notification to a confirmed email subscription.

Lambda uses a dedicated execution role for logging and publishing to SNS. EventBridge Scheduler uses a separate managed role that permits it to invoke only the monitoring function.

Monitor the CloudFront endpoint rather than the S3 bucket

Why: CloudFront was the public entry point for the website. Testing it verified the complete delivery path that a visitor would use, including CloudFront and access to the private S3 origin.

Trade-off: CloudFront caching can sometimes return previously cached content even when the origin has changed, so cache behaviour must be considered when interpreting monitoring results.

Use EventBridge Scheduler instead of continuously running compute

Why: Website checks are short, periodic tasks. EventBridge Scheduler and Lambda provide the required automation without an EC2 instance, container or persistent monitoring server.

Trade-off: Scheduled checks confirm availability only at the configured interval. A failure that begins and ends between checks may not be detected.

Use SNS for email notifications

Why: SNS provides a simple managed method of distributing monitoring results without adding an email server or third-party notification platform.

Trade-off: Basic SNS emails are functional rather than highly formatted and provide limited control over presentation.

Remove Route 53 and ACM from the design

Why: The default CloudFront domain already provided a public HTTPS endpoint suitable for testing, so a custom domain and separate certificate were unnecessary.

Trade-off: The website used a CloudFront-generated hostname rather than a branded domain.

Restrict Lambda to one SNS topic

Why: The Lambda execution role used a custom inline policy allowing sns:Publish only to the SiteMonitor topic rather than granting broad access to SNS.

Trade-off: The IAM policy would need to be updated if the function later published to additional topics.

After configuring the website infrastructure, I implemented the monitoring workflow by configuring Lambda, Amazon SNS and EventBridge Scheduler to perform automated availability checks and send notifications.

The Lambda function was configured with environment variables containing the monitored site details and the SNS topic ARN. When invoked, it sent an HTTPS GET request to the CloudFront URL, evaluated the response and published the result to SNS.

The Lambda execution role included the AWS-managed AWSLambdaBasicExecutionRole policy for CloudWatch logging and a custom inline policy permitting sns:Publish only to the required SNS topic.

EventBridge Scheduler was configured to invoke the function automatically. A one-minute interval was used during testing so that successful and failed checks could be verified quickly. A less frequent schedule, such as every five minutes, would be more appropriate for normal operation.

Resolving an unexpected 403 error

When I first tested the solution, CloudFront returned a 403 Forbidden error even though the website content had been uploaded successfully. The issue was that the CloudFront distribution had no default root object configured, so requests to the site root could not resolve index.html. After identifying and correcting the configuration, the website loaded as expected. I also added this reminder to the architecture diagram as a useful reference for future projects and as a practical troubleshooting tip for other AWS students building similar solutions.

Testing the failure path safely

A successful health check did not prove that the monitoring workflow would detect a real outage. To create a controlled failure, I renamed the website's index.html object. CloudFront then returned a 403 response, which Lambda detected before publishing a failure notification through SNS. Restoring the object returned the website to its healthy state.

I tested the system across its complete workflow rather than verifying each AWS service only in isolation.

Healthy website: Lambda received a successful response from CloudFront and SNS delivered a success email.
Unavailable website: Renaming index.html caused CloudFront to return a 403 response, which produced a failure email.
Scheduled execution: EventBridge Scheduler invoked the Lambda function automatically every minute during testing.
IAM permissions: Lambda could publish to the designated SNS topic without requiring broader SNS access.

After successful end-to-end testing, the AWS resources were decommissioned.

The test evidence above shows the EventBridge schedule together with the successful and failed SNS email notifications generated by the monitoring workflow.

Cost was not a primary design consideration for this project. The objective was to design and validate a serverless monitoring solution that met the project requirements rather than optimise for production operating costs.

The architecture uses managed AWS services with no continuously running compute resources, so infrastructure costs for a project of this size remain very low. During development, the environment was used only for testing before being decommissioned on completion.

In a production environment, operating costs would depend primarily on the monitoring frequency, the number of websites being checked and the volume of notifications generated.

End-to-end testing confirmed that scheduled health checks, failure detection and automated email notifications all operated as designed.

Designed an event-driven serverless monitoring architecture.
Protected the S3 origin using CloudFront Origin Access Control.
Automated website checks using EventBridge Scheduler and Lambda.
Applied least-privilege access to SNS publishing.
Verified both success and failure paths end to end.
Produced a custom architecture diagram and documented test evidence.

The project demonstrated how several small managed AWS services can be combined into a complete operational workflow with scheduling, execution, validation and notification.

Related projects can be viewed on the AWS architecture projects page.

Monitoring should test the public endpoint used by real visitors wherever possible. Checking the S3 bucket directly would have confirmed that the content existed, but it would not have tested whether CloudFront could deliver it successfully.

Scheduled serverless functions are well suited to short monitoring tasks because the system consumes resources only when a check is performed. This avoids maintaining an always-running monitoring server for a lightweight workload.

The current design provides a working foundation for a broader monitoring platform. Possible improvements include:

Monitoring multiple websites from a single function or configuration source.
Publishing custom CloudWatch metrics for availability and latency.
Creating alarms based on repeated failures rather than sending an email after every check.
Creating an HTML status dashboard showing current and historical results.

Designing an Event-Driven Website Monitoring System

Context

Architecture

Key Decisions

Implementation

Challenges

Testing

Cost

Outcome

Lessons Learned

Next Steps