Instance Types for WordPress and a General Overview
For a general overview of t4g.nano, t4g.micro, t4g.small, please see:
https://costcalc.cloudoptimo.com/aws-pricing-calculator/ec2/t4g.micro
My preference is for t4g.micro ARM architecture on Linux2023, with GP3 hard disk.
Website development or extremely low site use should work with a t4g.nano instance – however – it may have large delays when editing web pages with a theme editor. Be careful. One can test for a period of time before purchasing a Reserve Instance. It is not recommended to purchase for greater than 1 year’s standard pricing. Do not use nano instances to keep people happy.
A t4g.micro instance should ensure there is only standard burst CPU – do not configure unlimited, which is for specialised or high-volume mission critical websites for companies or shops who have a technical team. Otherwise you are subject to bill shock.
If possible, use Amazon Linux2023 on ARM/GP3. All the above is designed for performance.
If using Debian Linux, you can use ARM architecture, or x86 for applications that require it. E.g. on WordPress, an x86 t3a.micro, instance still using GP3 hard disk. Do not use t3.micro which is older and easy to mistakenly install. If fine to use ARM, then t4a.micro. An example of x86 architecture could be with CodeIgniter or email software. I have no recommendations for email software considering the bugs, crashes, memory leaks, use of time, instability and loss of data. The costs are more than simply using a 3rd party.
Other Considerations
Photography & Images
I do not optimise images as my preference is for detail, colour, contrast and blacks. I reduce image sizes via my DxO Labs software so that images are usually below 400KB – but not always. I use 2560 pixel width for banners. Generally, I use 1800 pixel width for photography and 1400 for artwork. Web browsers will not display the same clarity if less than these sizes. Small images can of course be much less in size. I do not compromise the clarity of the website logo. We determine what we want to do, not the Internet performance software. I use the EEEW plugin without compression, removing the multitude numbers of files contained in ./wp-content/uloads. I only create Thumbnail, Medium and Large, and ensure the theme and EEEW is set to 100% sizing and up to 5000 pixels width rather than any scaling. I make sure WordPress stores images in ./uploads and not according to the year and date. As an aside, your WP settings need Permalinks set to the Post Name. You can always re-save this option if having page link issues.
I use S3 bucket storage for thousands of photography files that may be accessed by the public, and EFS mounted disk for private long-term storage of files over 128MB, such as WordPress tar gzip and sql gzip backups. EFS works best with depositing files and not retrieving them again for some time unless really needed. S3 buckets are not really like Unix file systems, but you can install software to access them as a mounted “disk” for purposes of creating or restoring backups. Such software is highly unstable and not to be used like an NFS mount for production purposes.
If your site needs S3 backups to be distributed to two regions for backup security, configure the same. Another method is to sync files to another single-zone bucket. I always have file backups on my external PC USB drives.
CDN
I do not use a CDN Content Delivery Network as my sites are fine for Australia, and non-critical overseas.
WordPress Sizing and Nginx
A small business servicing the public, local businesses and government, with 50 to 100 page views per day may easily handle WordPress on a t4g.micro instance.
This type of instance may handle multiple websites using Nginx, memcached, and a caching plugin such as W3 Total Cache. The more websites, the slower performance and higher resource usage. Ensure your primary website is listed as such on Nginx. You will not have best performance on multiple sites using httpd/apache.
There is no reason to configure a database on a separate Instance. We are not talking about large websites. Two servers in this discussion implies another failure point in the architecture. It is important to write shell scripting that backs up WordPress to an S3 bucket, and have a snapshot of the instance volume now and then. Hardware can fail, and there is likely no chance of recovery otherwise.
Performance Troubleshooting & Security
If there is an undersized instance, you would see graphical presentation of AWS CPU and Memory statistics confirming the same.
Sometimes even well known WP plugins after upgrades can slow a website down until the authors fix their code. Therefore, a sudden drop in performance may not be anything to do with the instance. If an instance shows signs of hardware failure, rebuild on a new instance. If you install a fresh instance and it seems too slow doing operating system installation or upgrades, toss it and start again. You will know over time how an instance should respond. If you change to the root directory and do an “ls -lRa” command, and a file listing freezes, toss it. Ensure you use this “ls” command before a snapshot so that you do not backup a corrupted volume. I also use a shell script that does an mysql check. Make sure slowness is not due to your broadband service.
If an instance is compromised by a hacker, there will be odd behaviour. If security is not tight, and no monitoring of error logs to see what is going on, you can get hackers opening and flooding ports, leaving them open, causing issues. I install iptables, country blocking, removing ability of WP logins apart from a selected range of IP CIDR addresses, various Nginx security configurations, and even use of the Cloudflare reCaptcha system.
Do not expect to perfectly tune W3TC (or other plugins). Simply use what works. Achieve any percentage range in https://tools.pingdom.com/ of 85% or above. Depending on your plugins and the way the WP theme handles JavaScript, you can only work with what you have. In reality, a web page may display fast with 85%. Caching software is tiring and finicky.
It is important to be realistic about applications outside of WordPress. There can be security vulnerabilities that compromise WordPress if installed on the same instance, or debilitating instability, crashes, and memory leaks.
