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 Security Groups on AWS specific to our use case of scalable WordPress. Keep in mind that each AWS Account comes with a default VPC and Security Group that you can begin using right away; however, you may have a need to create your own or you just want to know how it all works together.
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.
What is a Security Group?
A security group is a virtual firewall that controls inbound and outbound traffic to your resources in AWS. For each security group, you must specify rules that control the inbound traffic, and a separate set of rules that control outbound traffic. You can use up to 5 security groups per instance.
Note: Security groups act at the instance level, NOT at the subnet level. If you don’t specify a Security Group at instance creation, it uses the default Security Group for the VPC.
Read more at the AWS Docs here.
What Security Groups do we need?
Looking at the AWS Reference Group, we are going to need groups for each of the following resources:
- Bastion Hosts
- Load Balancer
- Application/Web Server (EC2 Instances)
- RDS (Database)
- EFS (File Storage)
- ElastiCache
Bastion Hosts Security Group
Navigate to the Security Groups section by boing to the EC2 Service, and then clicking on “Security Groups” on the left side bar under “Network & Security” and then clicking on “Create security group” in the top right.
Disclaimer: We’ve set up a separate NAT Gateway EC2 instance, so we have the Security Groups already created, as noted in the screenshot above. Additionally, we have a Security Group created that allows our instances to communicate with the NAT instance. You could always use the AWS NAT Gateway service for ease of use.
To create the group, give it a friendly name and description, and ensure that you select the correct VPC.
Add an Inbound rule for Port 22 (SSH) from “Anywhere.” You could also lock this down to your IP address for additional security. Outbound rule can be left as is.
Then click on “Create security group”
Elastic Load Balancer Security Group
Repeat a similar process as above with Inbound rules for HTTP (Port 80) and HTTPS (Port 443) since we’ll be using SSL from ACM on our load balancer. Outbound rules can be left as is. Ensure you select the correct VPC.
Web/App Server Security Group
We only want the Elastic Load Balancer and Bastion hosts talking to our EC2 Instances so we’ll allow all TCP for the ELBs and Port 22 for the Bastion hosts. Outbound rules can be left as is. Ensure you select the correct VPC.
RDS Security Group
We only want the App/Web Server Instances and our Bastion hosts talking to RDS so we’ll allow those as a custom source to port 3306. Outbound rules can be left as is. Ensure you select the correct VPC.
EFS Security Group
Similar to RDS, we only want the App/Web Server Instances and our Bastion hosts talking to Elastic File System so we’ll allow those as a custom source to port 2409. Outbound rules can be left as is. Ensure you select the correct VPC.
ElastiCache Security Group
We only want the App/Web Server Instances and our Bastion hosts talking to ElastiCAche so we’ll allow those as a custom source to port 11211 (Memcached) and 6379 (Redis). Outbound rules can be left as is. Ensure you select the correct VPC.
Success
We now have all our Security Groups created! In our next posts, we’ll start setting up our AWS Resources.
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]