As cloud computing has grown to ubiquitous proportions, so too have concerns around data privacy and security in this seemingly nebulous environment. While the concept of security in the cloud is still often shrouded in confusion and anxiety, vendors such as Amazon Web Services (AWS) offer full-service security solutions which cover countless use cases and requirements. Although AWS’ cloud model breaks down many of the barriers around setting up and managing data and computing resources, the sheer volume of options available is often overwhelming. And as one of the key components of any cloud data environment, understanding your security options is critical. In an attempt to clarify some of this confusion, I’ve written a 3-part blog series using AWS’ security services as the vehicle for demonstration. Over the next 3 blog posts, we’ll explore:

  1. To VPC or Not to VPC? What is a Virtual Private Cloud, and when is it appropriate to use? Plus: Subnets vs. Network ACLs vs. Security Groups…what’s the difference? Route tables fit in somewhere here too.
  2. Encryption standards, options, and keys – what are they, how do you keep track of them, and what do you do with them?
  3. Putting it all together: best practices, tips and tricks for maintaining control of your data security… and therefore your mind!

Let’s get started!

To VPC or Not to VPC? That is the Question.
As you’ve probably guessed, VPC stands for Virtual Private Cloud. What that means is exactly what it sounds like – it’s a piece of the cloud which AWS has set aside only for your use. For purposes of this blog, we’ll discuss the 2 main types of configurations: depending on your use case, you can configure a public VPC (this sounds paradoxical, but it just means that access to the VPC is defined by the security groups or network ACLs instead of subnets; more on this in the next section), or a private-public VPC (some machines are fully segregated from traffic outside the VPC, while others can be reached by and send information to external traffic as specified by the user). If you’re looking to host your website on AWS, you’ll want to use the former so that the website is accessible to users searching via the internet; if on the other hand, you also want to maintain back-end servers that aren’t publicly accessible in addition to the website, the latter solution is appropriate.

Next you’ll want to determine the size of your VPC. The absolute maximum VPC size that AWS offers is 65,536 IPs. This means that you can have up to 65K+ AWS machines running inside your VPC at any given time. Obviously, this is an important factor in limiting the complexity of your data security architecture.

Now that we’ve reviewed the cruising altitude 37,000-foot view of AWS’ VPC, let’s spend a moment discussing whether you actually need it or not. My view is that it’s a good idea to put your AWS resources into a VPC in almost all cases. This is based on a few key factors:

  1. On its own, running your AWS machines inside a VPC doesn’t cost anything extra. The additional costs only kick in if you want to connect from the VPC to your corporate data center via a hardware VPN connection, for example.
  2. The downside to running your resources inside a VPC is very small – you have a few more components to keep track of (subnets, route tables, etc.; more on this below), but the downside to NOT getting started on AWS inside a VPC is potentially huge. This is because there is no way to simply move your resources into a VPC. You essentially have to re-configure and re-launch all of your applications inside the VPC, either from scratch or from an AMI/snapshot. This creates an increasing amount of work and complexity as the number of resources you’re running grows, which can be easily avoided by starting with your resources inside the VPC directly from the beginning.
  3. It’s also worth pointing out that based on current security trends, it’s much more likely that over time, companies will continue to increase security requirements for how their data will be stored and managed. Combined with the point above, this provides a strong argument for always starting inside the VPC.

So now that we’ve established that we’re all running our resources in AWS VPC, let’s break down some of its key components.

Subnets vs. Network ACLs vs. Security groups…what’s the difference?

In this section, we’ll just focus on laying out all the relevant terms and definitions that we’ll need for our discussions in the 2 posts which will follow:

  • VPC Security Groups – the VPC Security group is used at the instance level to specify individual ports and the source of traffic (explicit IP addresses or other security groups) which can connect in to the machine via those ports. Security groups only support “allow” rules which specify which traffic is authorized to connect to and from the instance, and on which ports (but do NOT support “deny” rules which reject certain traffic; this is discussed in more detail in the VPC Network ACLs section). Additionally, return traffic from the authorized inbound sources is automatically allowed. The security group is the “first layer” of defense, as it enables you to configure firewalls at the instance level. However, you must specify the security group each time you re-launch an instance (or launch from snapshot) – at start, instances are placed in the AWS default security group, and the intended security group must be specified after the instance is fully available.
  • VPC Route Tables and Subnets – each machine inside the VPC is (indirectly) associated with a route table which specifies the IP address targets to which each machine can connect and send data to, via an Internet Gateway. The association between the route table and the machine is made via subnets; each machine belongs to a subnet which in turn is associated with a route table. Subnets basically provide ways to group the resources inside your VPC based on their CIDR block (this is the “private IP” address that the machine takes on inside the VPC, which is different from the “public IP” which the machine assumes when interfacing with the outside world). This CIDR block grouping enables you to manage security across multiple resources simultaneously, and provides the “backup layer” of defense against security threats (see the next section for more details). Here’s a simple (slightly enhanced) image from AWS which illustrates the relationship between these entities:
    AWS Security Part 1_VPC Diagram
  • VPC Network ACLs – the Network ACL (access control list) is used in conjunction with the subnet to provide the “second layer” of security, as access rules are specified at the subnet level rather than at the instance level. This configuration provides backup security because unlike with security groups, resources are always launched directly into the specified subnet (where the Network ACLs will apply immediately). Therefore, even if you forget to move your instance from the default security group at startup, it will still be protected by the rules specified in your Network ACL associated with the subnet that the resource is in. Unlike security groups, Network ACLs also support allow and deny rules, and require return traffic to be explicitly allowed by rules.  Deny rules are useful, for example, in a situation where you need to open a wide range of ports for practical purposes, but there are certain ports within that range that you want to deny.

Phew! That feels like a good stopping point. Next time we’ll push the conversation further by exploring data encryption, and we’ll wrap by bringing it all together with some best practices, tips and tricks (many learned the hard way!).