An inherited AWS environment, put back in order.
The same funding portal we made readable by AI assistants had an AWS environment inherited from a previous provider. We took over its systems management.
We took over systems management of a grants and funding portal's AWS environment: several EC2 instances across Ireland and Milan and an Amazon RDS MySQL database. We removed the previous provider's access, made the Debian servers manageable from the console without exposing SSH, recovered a staging server that wouldn't boot and analysed the bill, identifying savings of about 30%. The public site moved to a Laravel Forge server in Milan, behind Cloudflare.
Context
The portal collects grants and funding opportunities for businesses. The site had already been simplified and made readable by AI agents; the infrastructure underneath, however, was what the previous provider had left: EC2 instances in two regions, Ireland and Milan, an Amazon RDS MySQL database and access rules to review.
The problem
You get to know an inherited environment one piece at a time. The Security Groups still held the previous provider's access rules. A staging server was unreachable for about three days, with its sites' certificates expired. And the bill had line items nobody looked at any more, starting with MySQL 5.7 Extended Support.
What we did
- 01
Access from scratch
The previous provider's rules removed from the Security Groups. SSM agent and IAM roles installed on the Debian servers, which are now managed from the AWS console without exposing SSH.
- 02
The server that wouldn't boot
With AWS Support we found the cause in the boot log: a broken fstab entry was blocking startup. The disk was mounted on a rescue instance, fixed and put back.
- 03
The bill, line by line
Savings identified for about 30% of the monthly bill: mainly MySQL 5.7 Extended Support, which goes away with an upgrade to 8.0, and RDS storage from io1 to gp3. Then idle public IPv4 addresses, EBS from gp2 to gp3, a snapshot lifecycle.
- 04
The database at its size
The Milan RDS instance, on MySQL 8.0, averaged about 1.5% CPU: we took it down one size, from m5.xlarge to m5.large, and removed Multi-AZ.
- 05
phpMyAdmin locked down
phpMyAdmin connected to RDS with cookie authentication, reachable only from the company VPN IP, with HTTP Basic Auth as a fallback layer.
- 06
The public site on Forge
The public site moved to a Laravel Forge server in Milan, behind the Cloudflare proxy, with a Let's Encrypt certificate on the origin.
How it went
The environment has a single manager, access rules that can each be explained, and a database sized to its real load. The other savings are identified and being tackled one at a time, starting with the MySQL upgrade.
Tools
FAQ
Why SSM instead of SSH?
With Session Manager you reach the servers from the AWS console, with IAM permissions and logged sessions, without leaving the SSH port open to the internet.
Isn't removing Multi-AZ risky?
Multi-AZ keeps a standby copy in another zone and bills you for an extra instance. With an average load of 1.5%, the cost wasn't justified for this database; RDS backups stay on.
What is MySQL 5.7 Extended Support?
When a MySQL version leaves standard support, AWS keeps running it on RDS but charges for it separately. Upgrading to 8.0 removes that cost and puts the database back on a supported version.