Create Security Groups on AWS

Written by Raz

Raz Rahman is an IT Management Professional working for a Fortune 20 Company. He has built successful Engineering and Operations teams supporting critical workloads both on-premise and in the Cloud. He has a passion for all things web and specializes in WordPress Hosting on AWS. When not thinking about technology, Raz loves all things Disney, bears (the animal), and BBQ!

January 15, 2021

Thank you for checking out this post!  Please note that the information is provided for general informational and educational purposes only and is not a substitute for professional advice.  If you have any questions or concerns, please leave a comment on the post!

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.

 

You May Also Like…

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.