Fixing the AWS Lightsail WordPress Blueprint (2GB RAM)

I recently started a 2 vCPU, 2 GB RAM AWS Lightsail instance using the default WordPress blueprint. It should be fine for a small site, but in practice it chokes under even modest traffic. Database connections drop, static assets hang, and the whole server starts to crawl. Given the size of the instance, it is not supposed to behave like this.

The problem was not the hardware. It was the default configuration. The blueprint underallocates memory, caps Apache workers too aggressively, and configures MariaDB with a much lower footprint than it should have. I learned this the hard way while trying to keep the site responsive.

Check where it breaks

Before changing anything, I checked which layer is collapsing.

I installed a few basic monitoring tools:

bash
sudo apt update
sudo apt install htop atop

After restarting the core services (sudo systemctl restart apache2 mariadb) to clear stale PHP OPcache and database memory buffers, the issue became obvious. Checking /var/log/apache2/error.log showed the server was repeatedly hitting MaxRequestWorkers.

The default config hard-caps concurrent connections at 10. A small traffic spike immediately maxes out the workers and leaves browsers stuck waiting for static files. That was exactly the kind of failure pattern I was seeing.

Tune Apache (mpm_prefork)

This was the balancing act: raise the worker count enough to absorb real traffic without letting Apache consume the whole 2 GB of RAM.

I opened the prefork config:

bash
sudo nano /etc/apache2/mods-available/mpm_prefork.conf

Then I adjusted the directives:

apache
<IfModule mpm_prefork_module>
    StartServers             5
    MinSpareServers          5
    MaxSpareServers         10
    MaxRequestWorkers       40
    MaxConnectionsPerChild   0
</IfModule>

These numbers were conservative but effective:

• MaxRequestWorkers (40): raises the concurrency ceiling from 10 to 40.

• MinSpareServers (5): keeps a ready pool of workers available.

• MaxSpareServers (10): gives Apache enough breathing room without ballooning memory use.

I applied the change:

bash
sudo systemctl restart apache2

Fix MariaDB

Just to be sure, I also tuned the database. The default MariaDB config is very conservative, which is fine for a small site but not for one that actually gets traffic.

I edited the MariaDB server config:

bash
sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

Then I tuned the [mysqld] section:

ini
[mysqld]
# InnoDB memory settings
innodb_buffer_pool_size = 256M
innodb_buffer_pool_instances = 1

# Connections and logging
max_connections = 50
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mariadb-slow.log
long_query_time = 2

This kept the database from eating available memory during traffic spikes:

• innodb_buffer_pool_size (256M): caps the main InnoDB cache.

• innodb_buffer_pool_instances (1): keeps it simple and stable on a small instance.

• max_connections (50): prevents connection floods from exhausting RAM.

• slow_query_log: helps identify plugin or query patterns that create bottlenecks.

I applied the changes:

bash
sudo systemctl restart mariadb

Offload static content to Cloudflare

And as a best practice to maximize performance, I installed the official Cloudflare plugin for page caching and used Certbot to automate TLS:

bash
sudo certbot --apache

With Cloudflare handling the static layer and Apache/MariaDB tuned for a 2 GB ceiling, the Lightsail instance finally behaved like the machine it actually was.