Is Your AWS Virtual Private Cloud Really Private?

The key benefit of an Amazon Web Services (AWS) Virtual Private Cloud (VPC) or virtual private networks is a basic one: your devices are not openly accessible via the Internet. This keeps proprietary applications and data protected since they can be accessed only from within your own secure network.

But many businesses don’t actually benefit from the enhanced security of a VPC for one very simple reason: they didn’t configure it correctly. Amazon does provide a set of guidelines to follow, but those guidelines assume a certain level of networking knowledge—and the ability to take the time to work through the setup carefully.

AWS has a shared responsibility model, in which they take on responsibility for the security of the cloud, but their customers—in other words, you—are responsible for security in the cloud. This means that Amazon does not check to see if you configured your VPC correctly. That’s your responsibility, and it’s one of the most common security lapses we see.

And that’s really understandable. If non-technical personnel—or even software developers, who clearly have technical chops (but maybe not these technical chops)—set up your VPC, they may not know what they don’t know (the dreaded unknown unknowns!) and think they’ve done it all correctly. And if your staff has to rush through setup for whatever reason, it’s quite easy to overlook an important step and continue blindly on.

The solution? Make sure your VPC is configured by someone who’s done it before and knows what to look for. And make sure he or she has the bandwidth to focus on that setup.

The Most Common VPC Mistake: Making the Private Inadvertently Public

One of the most common mistakes in setting up a VPC is using the same routing table for all subnets**—public-facing devices, private devices, databases and utilities. It may seem like a simple approach, but it turns all those private devices into public devices. In other cases, businesses set up separate routing tables for each subnet, but they accidentally put some of their private devices into the public subnet.

The key component to make sure you install in front of your private subnet is a NAT (network address translation) gateway, which filters out incoming Internet traffic while allowing outbound traffic from private devices on the VPC. Enabling outbound traffic through the NAT is important as it allows devices to be updated and to reach any resources they might need.

But at the same time, the NAT gateway prevents external users from logging on to private devices. We recommend configuring the VPC infrastructure so that the public subnet sits between your private networks and the Internet. If a server in a public subnet gets compromised, then you can just trash that server.

An important point of emphasis: Private resources should never access the Internet directly; they should always go through the NAT gateway and never be directly accessible from the internet. You should always configure ALB (Application Load Balancers), ELB (Elastic Load Balancers) or VPNs to allow traffic to any specific instance if a user isn’t also on the device’s network.

Any devices that connect directly to the Internet are susceptible to DDOS (direct denial of service) or botnet attacks, which may allow malware installations to hijack machines or outsiders to log on to the private devices, like the Jenkins hack over port 8080. This can easily be mitigated by using an ALB or making the utility machine a private resource.

How to Check the Security of Your VPC

Given the importance of VPC security, whenever we bring on a new client, we always check if their VPC is truly private. We review the steps they have already taken and then look at how the VPC subnets are configured. We then advise on what to do but can also adjust the configuration—we can usually do the work faster and make sure it’s right!

For those of you who want to try this on your own, here’s a checklist to get you going:

• Check to see if the default VPC is being used: we recommend spinning up a new VPC to avoid any CIDR conflicts if you ever need to connect two VPCs
• Check the number of subnets.
• Are they across multiple AZs?
• Are there public and private subnets?
• Check the route tables:
• Are public and private subnets using the same route table?
• Does the private subnet have an internet gateway instead of a NAT gateway?
• Public Routing

• Private NAT Gateway Routing

VPCs: Now Required by AWS

A VPC is now required by Amazon unless you are a legacy customer still running on EC2 Classic. If you’re still on EC2 Classic, move off it immediately! EC2 Classic is no longer supported and lacks many of the features that users have grown to expect. Some EC2 customers worry that migrating will create a glitch in cloud performance, and while that’s a legitimate worry, it’s not a good reason not to migrate. A cloud expert (like G2, for instance!) can provide a process to make those migrations happen seamlessly and get you onto a VPC.

The move to VPC gives you fine-tune access controls so you can limit which machines your devices can talk to, both on the outside and internally. You can also limit which external machines can talk to your internal machines by creating a whitelist/blacklist at the instance, subnet or VPC level. You can even limit communications between devices on your network. AWS EC2 Classic does not allow for this kind of security control.

All these capabilities add up to a higher level of IT security and greater protection for your digital assets!

FAQ

1. What specific configurations are recommended for optimizing VPC security against DDoS attacks?

To optimize AWS Virtual Private Cloud (VPC) security against DDoS attacks, it is recommended that scalable protection features such as AWS Shield, especially the advanced version, be implemented, which provides enhanced DDoS mitigation. Additionally, configuring network access control lists (ACLs) and security groups to limit unnecessary exposure to traffic and employing Amazon CloudWatch for monitoring are crucial steps to defend against such threats.

1. How can organizations ensure compliance with industry-specific regulations when configuring their VPCs?

When configuring their AWS VPCs, organizations can ensure compliance with industry-specific regulations by implementing strict access controls, encryption methods for data at rest and in transit, and detailed logging that captures all access and usage details. Utilizing tools such as AWS Config for continuous monitoring and auditing also helps maintain compliance and align with regulatory standards.

1. What are the implications of misconfigured VPCs on an organization's overall cloud security posture?
2. Misconfigured VPCs can significantly impact an organization's overall cloud security posture, leading to vulnerabilities such as unintended data exposure or unauthorized access. Such misconfigurations may compromise sensitive data and violate compliance obligations, potentially resulting in financial penalties and reputational damage. Regular audits and adherence to AWS best practices are essential to mitigate these risks.