Amazon Virtual Private Cloud (Amazon VPC) is a feature of Amazon Web Services that allows you to define a logically isolated virtual network in which you can provision your AWS resources. The components of a VPC include IP addresses, subnets, route tables, gateways, network interfaces, endpoints, and more. While Amazon has built security “into” VPCs to a certain degree, as an AWS administrator you also have to configure and manage your VPCs appropriately to ensure your hosted data, servers and applications are secure. In this article, I’ll share five tips on how you can make sure that your VPC and the resources it contains are in actual fact reasonably secure.
Always begin with a detailed plan
Before you create a new VPC you should always start with a plan in place that outlines the design and workings of your VPC. The key to good planning as far as VPC creation is concerned is to identify what the main purpose of your Virtual Private Cloud will be. Will you be using your VPC to host a public facing website? Will you use for the purpose of extending your on-premises corporate network into the AWS cloud? Which groups of users, applications or services should have access to your VPC once it has been created? What kinds of connectivity will be required between your Virtual Private Cloud and other internal and external networks belonging to your organization, partners, or customers? Will you need only one new VPC or will you need to create additional ones to ensure connectivity with resources in other regions? Answering these and as many other questions as you can think of will help you greatly in ensuring that the VPC you create will be designed for security from the ground up.
Start fresh by creating a new Virtual Private Cloud
While AWS provides you with a default Virtual Private Cloud in each region of your AWS account, it’s best if you don’t use the default VPC but create your own new VPCs instead. The reason for doing this is because the security configuration of the default VPC is basically wide open because subnets in the default VPC are associated with your main routing table and this doesn’t place any restrictions on inbound or outbound traffic. So it’s always best from the perspective of securing your AWS resources if you create new VPCs and then define custom route tables for each VPC. Because it’s a good practice not to mess around with your main routing table in case you break something that has a widespread impact upon your AWS environment.
Create more than one VPC even if you need only one
Even if you only need one VPC to host your applications, servers, and data, you should still start off by creating at least two VPCs, one for production and a mirror one for development. Always conduct your testing separate from your production environment so you can ensure that if something goes wrong the fallout from the result will be limited. While this probably seems obvious to most of us, this simple rule is often not followed in enterprise environments not used to the Agile development model.
Avoid using NACLs and use security groups instead
Security groups are basically virtual firewalls that control what kinds of traffic can enter and leave your VPC. Security groups are permissive only — there are no deny rules. When you create a new security group for a VPC it automatically allows unrestricted outbound traffic but no inbound traffic, which of course is the most secure configuration. In order to allow certain forms of inbound traffic to your Virtual Private Cloud, you must specifically create rules to enable such traffic to flow inwards. Network access control lists (NACLs), on the other hand, are another form of virtual firewall you can use to control the inward and outward flow of traffic to and from your VPC. And when you create a new NACL it won’t allow any type of traffic, inbound or outbound, to flow.
So what’s the difference then between security groups and NACLs? The answer is that security groups control traffic at the instance level for instances within your VPC. NACLs on the other hand control traffic for the subnets defined within your VPC. So if you have multiple instances hosted on a subnet then they’re all going to have their network traffic constrained by the NACL applied to that subnet. And that is often less than ideal from the point of view of securing your AWS resources. So it’s better generally to use security groups for controlling traffic since they can be used more granularly than NACLs can. The only advantage that NACLs can sometimes provide you with over security groups is that NACLs can contain both allow and deny rules while security groups only support allow rules. Remember also that if you don’t explicitly create a custom NACL for a subnet in your VPC the default NACL, which allows any inward or outward traffic, will automatically be used by instances on that subnet.
Stretch your thinking and use Elastic IP Addresses
Finally, if the resources that will be hosted in your VPC are going to require connectivity to the Internet so users and applications can access them then you have a choice of how you can make this connectivity happen. Specifically, you can either assign a public IP address to any instance or network interface in your VPC or you can use an Elastic IP Address (EIP) for such purposes. While the main reason for using EIPs is availability — if your instance fails for some reason and shuts down any public IP address associated with it would be lost, but if you’re using an EIP then you can move this EIP to another instance -- using EIPs will also make it easier for users and applications accessing your instance to whitelist it as an available resource, which makes using EIPs also a security consideration for your VPC architecture.
There’s always more
There are other practices, of course, that you can adopt to ensure the security of your AWS-hosted servers, applications, and data, and I’ll describe some of these best practices in future articles that specifically target each type of AWS hosted resource.
Featured image: Shutterstock