Projects
Selected work.
Practical AWS and cloud work, from development through deployment and operation.
This portfolio brings together live production work, projects in development and hands-on learning. Each project’s status is shown explicitly so that experimental work is not presented as completed client delivery.
Commercial website
NextFoundry — AWS-hosted commercial website
Status: Live
NextFoundry is a live website created as both a commercial proposition and a practical AWS/cloud project. It is hosted in AWS using S3, CloudFront, Route 53 and ACM, with a Lambda function supporting website contact-form functionality.
Purpose & practical focus
Taking a website from development through infrastructure, deployment and ongoing operation. Infrastructure has been developed using Infrastructure as Code and deployment automation, including Terraform and GitHub Actions.
Monitoring & FinOps
AWS Synthetic Monitoring & Cost Optimisation
Client: Next Foundry — “Client Zero”
AWS Services: Amazon CloudWatch Synthetics, CloudWatch, Amazon S3
Infrastructure: Terraform
Focus: Monitoring, Infrastructure as Code, FinOps, Cost Optimisation
The Challenge
How frequently should a business website test itself?
The answer should reflect the importance and usage of the service—not simply the default configuration of the monitoring platform.
Using Next Foundry as “Client Zero,” I wanted to implement automated monitoring that could independently confirm that the website was available and responding correctly.
The Solution
I deployed an Amazon CloudWatch Synthetics canary to perform automated homepage checks.
The monitoring infrastructure was created and managed through Terraform, keeping the configuration repeatable, version-controlled and consistent with the wider Next Foundry AWS environment.
Initially, the canary ran once every hour.
Technically, the solution worked exactly as intended.
However, AWS subsequently notified me that 88 of the 100 monthly free canary runs had already been consumed.
That prompted a review of whether the monitoring frequency was proportionate to the service being monitored.
The Review
Rather than simply accepting the original configuration, I assessed:
- How quickly a website failure genuinely needed to be detected
- Current traffic levels and business criticality
- Successful and failed canary-run retention
- S3 artifact retention
- CloudWatch monitoring requirements
- The expected cost once the free allowance was exceeded
An hourly schedule would generate approximately 720 synthetic checks per month.
For a high-volume transactional or revenue-critical service, that frequency—or considerably more frequent monitoring—could be entirely justified.
For the current Next Foundry website, however, 720 checks per month provided limited additional business value.
The Optimisation
I revised the Terraform configuration to reduce the canary frequency while retaining meaningful availability checks throughout the day.
The change was deployed through the existing GitHub Actions CI/CD workflow, maintaining the Infrastructure as Code approach rather than making an unmanaged console change.
The website remains automatically monitored, but the monitoring now reflects the actual operating requirements of the service.
The Outcome
The project reduced unnecessary synthetic monitoring activity while retaining useful availability assurance.
More importantly, it demonstrated a wider cloud engineering principle:
More monitoring is not automatically better monitoring.
Every test, log, metric and retained artifact should have a purpose. Otherwise, a technically sound control can increase cloud consumption and operational overhead without materially improving the customer outcome.
Cloud cost optimisation does not begin by removing useful controls.
It begins by making those controls proportionate to the service they protect.
Skills Demonstrated
Website migration
andyhopla.com — Hostinger to AWS migration
Status: Live
This portfolio website has been rebuilt and migrated from Hostinger Website Builder to AWS and is now live.
Purpose & practical focus
A static website hosted in a private S3 bucket and delivered through CloudFront using Origin Access Control, with HTTPS and DNS integration. Infrastructure is managed using Terraform and deployment is automated through GitHub Actions.
Cloud security
Hardening the Security of andyhopla.com on AWS
Building security into this website’s AWS architecture, with a private S3 bucket, controlled access through CloudFront, HTTPS and browser security headers. Infrastructure is defined in Terraform and deployed through GitHub Actions.
Read the security case studyProduct development
Pulse — cloud-based SaaS product
Status: In development
Pulse is a SaaS product being developed under the NextFoundry brand. It is being designed as an independently deployable application with separate frontend, backend, infrastructure and data boundaries.
Purpose & practical focus
Defining application boundaries and an architecture that supports maintainability, security, monitoring and controlled deployment. Current architectural work includes AWS serverless technologies and Infrastructure as Code.
Application & cloud security
Pulse — strengthening security for production
Preparing Pulse, my website health checker for small businesses, for production by strengthening its scanner, protecting scan reports and email delivery, and improving AWS deployment security and analytics privacy.
Read the Pulse security case studyLearning projects
AWS learning & infrastructure projects
Status: Ongoing
A collection of hands-on AWS exercises and implementations used to develop practical cloud operations and architecture skills.
Purpose & practical focus
Building practical experience in implementation, troubleshooting, monitoring, security and operational management. The focus is on understanding how cloud infrastructure behaves and how to operate it, beyond completing tutorials.