5 tips for securing your Amazon Virtual Private Cloud

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

Amazon Web Services

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

Mitch Tulloch

Mitch Tulloch is Senior Editor of both WServerNews and FitITproNews and is a widely recognized expert on Windows Server and cloud technologies. He has written more than a thousand articles and has authored or been series editor for over 50 books for Microsoft Press and other publishers. Mitch has also been a twelve-time recipient of the Microsoft Most Valuable Professional (MVP) award in the technical category of Cloud and Datacenter Management. He currently runs an IT content development business in Winnipeg, Canada.

Share
Published by
Mitch Tulloch

Recent Posts

User-friendly web design tools for a user-friendly website

If you want your business to succeed these days, you need a user-friendly website. Put these tools in your toolbox…

9 hours ago

New kids vs. old reliable: Can chat apps replace email?

Do businesses rely too heavily on email for communication? Yes! Is the answer to replace email with chat apps? No!…

14 hours ago

PowerShell function to standardize message box script outputs

If you got your start with Visual Basic, you remember msgbox. This PowerShell function will bring back memories and help…

17 hours ago

Microsoft Ignite 2019: Top announcements and product unveilings

Microsoft Ignite 2019 included a slew of updates on products and services. Among the announcements was Azure Arc, which may…

1 day ago

Who says configuration management can’t be fun?

Managing change in an enterprise isn’t easy and it’s usually no fun. Here’s a book on configuration management that will…

2 days ago

Choosing the right communication tools for your business

Choosing communication tools is like choosing a first progamming language. While you want easy, you also want cross-platform, security, and…

2 days ago