Three crucial steps for securing your
Virtual Private Cloud (VPC)

Security is one of those aspects that is often neglected during an initial phase of architecting your cloud infrastructure. 

Cloud computing has certainly made it convenient to spin-up the workloads and get started within a day. But as you know, "with great power comes great responsibility". While it's easy to deploy infra in AWS, it's equally easy to make mistakes in basic network security. Sometimes these mistakes can even expose your private infra to the public. As an example, one of the major e-commerce retailers based in Melbourne had their backend APIs exposed to the public and attackers made their way through to place online orders bypassing payment gateways. These networking issues are very difficult to overcome once you have a production workload deployed in your Virtual Private Cloud (VPC). Hence it’s important to set them correctly while planning your infra in the cloud.

In this blog, we’ll take a look at some of those industry standards that can certainly help you to define security boundaries in your cloud infra. Rather than going into too much technicality, let's take a look at how a good VPC should look in three simple steps:

1. Isolating workloads

VPC Subnets provide a great way to isolate various kinds of workloads. Some examples of subnets are RDS Databases, EC2 servers, ECS clusters, Load Balancers, and so on. They allow you to impose various restrictions in inter-subnet communication through routing tables.

Obviously not all workloads need to be public facing. Things like Database, Web, or Application Servers should be protected from hacker attacks. That’s why it's important for them to be deployed into separate subnets which do not have public incoming connections. One of the patterns you can follow is a 'three tier architecture' as below:

Refer the diagram below which simply outlines the placement of these subnets:

As you can see in the diagram, although all three kinds of subnets have outgoing internet connectivity through NAT gateway, it's only the 'Public subnet' that has incoming internet connectivity through internet gateway. This ensures none of your servers (and operating systems) are exposed to the attackers. For production workload, any Application Load Balancers (ALBs) can also be secured with the help of Web Application Firewall (WAF) to take security to the next level.

2. Setting up boundaries

I’ve seen a few engineers who deployed Databases in Public Subnet, attached a security group by whitelisting their home internet IP, so that they could access the database from their computer. Although this is very convenient, it's equally a terrible pattern to follow and can seriously cause massive risk to the business. There's even the possibility of someone deploying a database into a public subnet by mistake. Hence, it's a no-brainer to set some boundaries in your Cloud infra that can enforce people to do the right thing. This can be easily achieved through VPC Network Access Control Lists (ACLs).

If you follow the diagram above, you would notice the orange boxes for defining Network ACLs. The ACLs of the public subnet only has port 443 for serving web traffic. Restricting it to a specific port helps us avoid the risk of someone deploying a database into a public subnet as it won't be accessible on a DB port despite what you put in the security groups.

Similarly, if someone ends up deploying an EC2 server in a Public subnet, they must be stopped from accessing databases deployed in the database subnet. This is just to protect your DB in case the public facing EC2 is compromised by some attacker. Hence, tightening the ACLs of database subnet to open only a specific port to Private Subnet enforces humans to deploy their apps into Private Subnet.

3. Being proactive, not reactive

We are humans, so mistakes will happen! However, if we put the right systems in place, we could proactively address those mistakes and help the business maintain its security. One of the best ways is to set up AWS Config rules that run an audit of your infrastructure and notify relevant parties to act on any non-compliant practices.

You could even leverage AWS EventBridge to monitor specific VPC events and perform certain actions using Lambda/SNS/Chatbot depending on its severity.

Final words 

I hope this article was helpful to put a security lens around your cloud infrastructure. Strengthening the security of your cloud environments will help you gain control over your business operations and instil confidence that your data, applications, and customer information are protected. The above steps are a great way to get started.