The objective of creating a WordPress website using AWS is to build a highly available, scalable, and secure website that can handle variable traffic loads and provide a seamless user experience. To achieve this objective, various AWS services are used, such as VPC, security groups, EC2, NAT gateways, RDS, EFS, ALBs, Route 53, Auto Scaling Groups, AWS Certificate Manager, and a bastion host. The combination of these services provides a robust and scalable platform for hosting a WordPress website, while ensuring high availability, security, and ease of management.
Step 1: Build a Three-Tier AWS Network VPC from Scratch
Building a three-tier AWS network VPC from scratch involves creating a Virtual Private Cloud (VPC) from the AWS Management Console, setting up subnets for each tier (public, private, and database), and configuring routing tables and security groups to ensure traffic flows securely between the tiers. The VPC can then be launched with instances for each tier, and load balancers can be added for high availability and scalability.
1. Create a new VPC using the CIDR range from our reference architecture.
2. Enable DNS hostnames. Enabling DNS hostnames in an AWS VPC allows instances within the VPC to have DNS names associated with their IP addresses.
3. Create an Internet Gateway. The Internet Gateway is crucial for enabling internet traffic to enter and exit a VPC, allowing instances, NAT gateways, etc. within public subnets to have a public IP address and be directly accessible from the internet.
4. Attach the Internet Gateway to our VPC. We can only attach one Internet Gateway to a VPC at a time.
5. Create two public subnets in two different availability zones for high availability. We will create these with different CIDR blocks, since subnets cannot have overlapping CIDR blocks.
6. Enable auto-assign public IPv4 address.
7. Create a new public route table. When a new VPC is created, a Main route table is automatically created and associated with all subnets within the VPC. We will add a public route to our own public route table and associate our previously made public subnets with it.
8. Add a public route to the table. We'll do this by adding a target for our Internet Gateway.
9. Associate our previously made public subnets with the public route table.
10. Lastly, we will create four private subnets that will host our apps and databases. Two in Availability Zone 1 (AZ1), and two in AZ2. This will leave us with six subnets.
In a VPC, subnets can be designated as public or private based on their route table configuration. Public subnets are associated with a route table that has a route to an internet gateway, and private subnets are associated with a route table that does not have a route to an internet gateway.
Subnets not associated with a route table default to the Main route table, which is private by default.
Step 2: Create NAT Gateways
A NAT gateway allows instances in private subnets to securely access the internet or other AWS services, without needing public IP addresses or self-managed NAT.
1. Create a NAT gateway for AZ1 and allocate an elastic IP. This provides a static IP address that does not change even if the NAT gateway is stopped or restarted, and it ensures that the IP address of the NAT gateway remains constant, making it easier to maintain connectivity and security for external communication.
2. Create a private route table.
3. Add a route to our NAT gateway to route traffic to the internet.
4. Associate our private web and data subnets in AZ1 to the table.
5. Replicate steps 1-4, but this time for the subnets in AZ2.
Step 3: Create Security Groups
Security groups control the inbound and outbound traffic for resources in a VPC. They use rules to allow or block traffic based on protocol, IP addresses, and ports. We will create five security groups to control inbound traffic for our webservers.
1. Create the application load balancer security group. Inbound rules will allow access from HTTP (Port 80) and HTTPS (Port 443). We will add this security group to the application load balancer we create.
2. Create the SSH security group. Inbound rules will allow access from SSH (Port 22). We will limit this to only our IP address.
3. Create the webserver security group. Inbound rules will allow access from HTTP (Port 80), HTTPS (Port 443), and SSH (Port 22), and the source is our ALB and SSH security groups. We will add this security group to our EC2 instances.
4. Create the database security group. Inbound rules will allow access from port 3306, and the source will be our webserver security group. We will add this to our database instance.
5.Create the EFS security group. Inbound rules will allow access from port 2049 and 22, and the source will be our webserver and SSH security group. We will also add this security group as a source for itself.
Adding a security group as a source for itself means that the security group allows inbound traffic from other resources that are also assigned to the same security group. This is necessary for EFS because it requires the security group to be allowed to access the EFS mount target, which is also assigned to the same security group. Without allowing inbound traffic from the same security group, the EC2 instances won't be able to access the EFS mount target, which will result in errors when accessing shared files.
Step 4: Create the RDS Instance
Amazon Relational Database Service (Amazon RDS) is a fully managed database service provided by AWS that makes it easy to set up, operate, and scale a relational database in the cloud. With Amazon RDS, you can choose from six popular relational database engines, including MySQL, PostgreSQL, Oracle, SQL Server, MariaDB, and Amazon Aurora.
In this project, we will use MySQL as our database engine.
1. Create subnet groups. These will allow us to specify which subnets we want to create our RDS database in (Private Data Subnet AZ1 and Private Data Subnet AZ2).
2. Create the RDS database. We will create this, the Master DB, in Availability Zone 2 and have a stand-by in AZ1.
Step 5: Create the Elastic File System (EFS)
Amazon EFS is a cloud-based file storage service for applications and workloads that run in AWS. An EFS mount target is the access point to an EFS file system from an Amazon VPC subnet. It allows EC2 instances in the VPC subnet to mount the file system and access the shared data.
1. Create the file system. We will create our mount targets in the Private Data Subnet AZ1 and Private Data Subnet AZ2.
Step 6: Launch the Setup Server
We will now launch the EC2 instance setup server. We will utilize this instance to install WordPress and transfer the code to our EFS. We'll deploy it in the public subnet for ease of installation and file transfer to EFS. Once our files are stored in EFS, our servers in the private subnet will be able to access the code from there upon launch.
1. Create a key pair. We will use this to SSH into our EC2 instance.
2. Change permissions on our key. This will set the read-only permission for the owner of the file, and no permissions for anyone else.
3. Launch our setup EC2 instance with our three security groups: webserver security group, ALB security group, and SSH security group.
Step 7: Install WordPress
Now we'll download and extract WordPress files to the document root directory of our web server.
1. SSH into our Setup Server.
2. Create the HTML directory and mount the EFS to it.
3. Install Apache.
4. Install PHP 7.4.
5. Install MySQL 5.7.
6. Set permissions.
7. Download WordPress files.
8. Create the wp-config.php file.
9. Edit the wp-config.php file with our database settings.
10. Restart the webserver.
11. Finish installing WordPress.
Step 8: Create an Application Load Balancer
An Application Load Balancer (ALB) is a service that routes incoming traffic to multiple targets based on the content of the request, such as the URL or HTTP header. ALBs operate at the application layer (Layer 7) and support features like SSL/TLS termination, health checks, and content-based routing.
1. Launch EC2 instances in both private subnets. These will hold our webservers that will host our website, one in AZ1 and the other in AZ2.
2. Create a target group. We will put the EC2 instances we just created in the target group to allow the ALB to route traffic to them.
3. Create the application load balancer.
4. Go into the settings of our WordPress and change the WordPress URL and Site URL to the URL of our ALB.
5. We can now delete our Setup Server.
Step 9: Register a New Domain Name in Route 53 and Create a Record Set
We will create a domain name for our website and use Route 53 as a service that helps people find that website on the internet. It will ensure that people can access the website easily and reliably.
1. Create a domain name.
2. Create a record.
Creating a Route 53 alias record for an Application Load Balancer involves mapping the website or application's domain name to the ALB. This directs traffic to the targets behind the ALB. The user must specify the DNS name of the ALB and routing policy when creating the alias record.
3. Replace the ALB address for our WordPress site with the domain name we just created.
Step 10: Register for an SSL Certificate in AWS Certificate Manager
We will use an SSL Certificate to encrypt all communications between the web browser and our webservers. This is also referred to as encryption in transit. Currently we are not secure.
1. Create a public SSL Certificate in AWS Certificate Manager.
2. Create DNS records in Amazon Route 53. This is a validation process designed to ensure that only the domain owner can obtain the SSL certificate.
Our certificate is good to go.
Step 11: Launch Bastion Host
A bastion host is a dedicated server instance used to securely connect to other servers within a private network. It provides an additional layer of security by acting as a gateway that requires two-factor authentication and provides access control for remote connections.
1. Create the bastion host in the public subnet.
Step 12: SSH into an Instance in the Private Subnet
We can now use the bastion host to SSH into any instance in our private subnets.
1. First we will run the command that will allow us to SSH from the bastion host to any instance in the private subnet.
2. SSH into our bastion host.
3. SSH into the private webserver in AZ1. We will do this by using the instance's private IP address.
Step 13: Create an HTTPS (SSL) Listener for an Application Load Balancer
Creating an HTTPS (SSL) listener for an ALB involves configuring the ALB to handle SSL/TLS encryption for incoming requests. This requires associating the SSL certificate we created with the ALB's listener configuration. Once configured, the ALB can decrypt and forward incoming HTTPS requests to the appropriate backend target group.
1. Add listener.
2. Redirect traffic to the HTTPS listener from the HTTP listener.
3. Modify the wp-config file with the following code.
This code is used to make sure that our WordPress website uses a secure SSL connection when users access the admin pages. It also checks to see if the user is accessing the website through an AWS load balancer with SSL enabled, and if so, it sets the HTTPS protocol to be used for the request. This helps ensure that all user data transmitted between the website and users is encrypted and secure.
4. Check that our website is now secure.
5. Update the URL settings for our WordPress site from 'http' to 'https'.
Step 14: Create an Auto Scaling Group
An Auto Scaling Group (ASG) is a group of EC2 instances that can automatically scale up or down based on demand. This helps maintain the required number of instances for the application to handle variable traffic loads without downtime or performance degradation.
1. Terminate the EC2 instances we previously created manually.
2. Create a launch template. This contains the configurations of our EC2 instance that the ASG will use to launch new instances in the private app subnets.
3. Create the auto scaling group.
We now have two instances running in our ASG.
4. Check the health status of our running EC2 instances.
Our WordPress website is complete and running!
Step 15: Terminate Resources
To complete this project, we will delete the resources we created to avoid unwanted charges. This includes our ASG, launch templates, ALB, target group, RDS, bastion host, EFS, security groups, NAT gateways, VPC, elastic IPs, and record sets.
