Disclaimer: This is a personal blog, any views or opinions expressed in this blog are personal and belong solely to the blog author and do not represent those of people, institutions, or organizations that the author may or may not be associated with in a professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
This post is part of our series on how to Create a Multi-Tier Auto-Scaling WordPress Site on Amazon Web Services. If you haven’t checked out our previous posts, be sure to click the link above.
As a reminder, we’ll follow the AWS Reference architecture as close as possible; however, we will try to use Free Tier resources whenever available. For this tutorial, we are going to create a database on AWS RDS to use for our WordPress backend.
Scalability does come with some drawbacks with regard to keeping themes/plugins up to date; however, it all depends on your goal and what you need for your site. The way you’ve traditionally managed WordPress will be different with this architecture and that needs to be taken into account long-term.
Please note that we are going to put the whole WordPress installation on EFS which does have some latency and performance concerns. We will try to overcome this with caching and CDN; however, if that’s not performant enough for your use case, you may want to only put the “uploads” directory on EFS and then have a process to update the base AMI going forward.
Prerequisite: AWS Reference Architecture and Previous Posts
As mentioned above, please ensure that you check out the AWS Reference architecture as well as our previous posts.
Once you are logged into your AWS Management Console, navigate to the “RDS” Service.
Once there, simply click on “Create database” either at the top of the page or under the “Resource” section.
Create RDS Database
We are going to use the “Standard create” method to create our database. Also, since we are sticking with the Free Tier and this is a tutorial, we will use a MySQL database as opposed to Amazon Aurora.
- Creation Method: Standard
- Database Engine: MySQL
- Edition: MySQL Community 8.x
- Template: Free Tier
- DB Instance Identifier: Give a friendly name for your
- Master username: Feel free to change or use “admin”
- Password: auto-generate
- DB Instance Size: We are sticking with the Free Tier so db.t2.micro
- Storage Type: General Purpose
- Storage: 20GB
- Storage Autoscaling: Enabled
- Availability & durability: For the purposes of the tutorial and using the Free Tier, this will be greyed out. For Production use cases, ensure you have a Multi-AZ set up as well as large DB Instance Size, etc.
- VPC: Select the VPC we created for this series
- Subnet: Leave as-is for now as this setting is a bit confusing.
- Public Access: No
- VPC Security Group: Select the RDS Security Group we created in our previous post
- Availability Zone: Select where you would like your DB to reside
- Authentication: Password is fine for our purposes
- Additional Configuration
- Provide an initial database name to make configuration easier: 3t_wordpress
Note: In many fields, you need to be wary of using special characters or having your strings start with a number. You’ll see in our screenshots that we used “threet” instead of “3T”.
Then click on “Create database” and it’ll take a few minutes for AWS RDS to get everything set up. You’ll see that the status is “Creating”.
RDS Database Credentials
Ensure that you capture your user’s password by clicking “View credential details” in the top right of your screen since we used an auto-generated password.
RDS Database Endpoint/Connection Details
Once the database is created, you may see that the status changes to “Backing-up” or “Available”.
Click on your DB Identifier name to be taken to the details about your database.
You’ll want to note the endpoint as we’ll use this to configure WordPress, as well as the port.
You can see that our VPC is selected with the correct Security Group; however, our database subnet group has our public and web/app tier subnets. We’ll want to remove those.
RDS Database Subnet Group Refinements
Click on “Subnet groups” in the left sidebar, and then click on the checkbox next to the default subnet group that was created for your database. Then click on “Edit” in the top right.
You’ll want to select all the Availability Zones that you have enabled and then de-select the items that you want to remove.
Now we are left with the subnets that are part of our Database Tier.
We could have created a new database subnet group to begin with, and then assigned it as part of the wizard, but you live and learn 🙂
In our next post, we’ll create our Bastion host so that we can test connecting to our new Database.