Do I Really Need a VPC?

From a security standpoint, a VPC isn’t a magic power. It’s another layer of responsibility.

Running applications on AWS? You need a VPC: a virtual private network that keeps your servers safe from the ravages of the public internet, just like they were in your old data center.

Or so went the guiding philosophy of what we might call cloud 1.0 -- the IaaS wave, when EC2 was king.

But these days, when I build new applications in the cloud or talk to other builders doing the same, VPCs don’t always enter the conversation.

That’s because cloud-native applications increasingly run on higher-level managed services --  like Lambda, API Gateway, and DynamoDB -- that communicate with each other via API. In AWS, that might mean securing the interaction between microservices using IAM for both authentication and authorization. 

VPCs will always rule the roost if you need to connect back to legacy data centers. But should they still play a crucial role in securing modern, born-in-the-cloud applications? I’ve got my own opinion, but I decided to check with a few experts.

Checkbox or must-have?

Maybe you’ve sat in your share of meetings with security teams, trying to evaluate a cloud-native design using a checklist developed for on-prem applications. Well, so has PurpleBox Security’s Nihat Guven. “The security and compliance field are playing catch-up on this,” he says. “On the compliance front, it is more about following the standard and checking the box” than actually thinking through the real security advantages a VPC might or might not provide.

Teri Radichel, another AWS Hero and author of the forthcoming book “Cloud Security for Executives,” agrees that VPCs aren’t magic. “The VPC doesn’t do anything, really,” she points out. “You need a proper network architecture with NACLs, subnets, and security groups. You need to know how to build the architecture so you can monitor for attacks. People need to understand network layers, attacks, and how attackers pivot through networks.” 

Which brings us to the crux of the issue: the argument for adding a VPC to an otherwise-functioning application is always going to be about adding layers of security to the theoretical minimum imposed by IAM. You don’t bring in a VPC to fix a problem, you do so because you want additional layers of protection against data exfiltration, say, or more fine-grained analysis of traffic patterns.

And that’s where so many engineers get confused. 

A responsibility, not a superpower

From a security standpoint, a VPC is not a superpower, it’s an additional responsibility.

Don Magee, formerly a security specialist at AWS, now manages cloud assurance and observability at Allstate. “If there’s not a business need for a VPC -- such as legacy connectivity -- then you’re better off not having it,” he says. “Layers of security configuration can actually be more detrimental than beneficial, due to the added complexity you bring in.”

That’s right: in security configuration as in KonMari, more is not always better. If you’re not good at configuring IAM roles yet, what makes you think you’ll be better at VPC security? If you are leaving S3 buckets publicly exposed, are you sure you can police the web of security groups, ACLs, and subnets that a VPC brings in?

VPCs do give you some additional network monitoring tools such as flow logs, but again -- do you know how to use these effectively? If not, you’re just paying to capture expensive data with no clear plan on how to inspect it.

And it’s not like the VPC provides some intrinsic protection to your data once it’s inside the network. As Magee reminds us: “Even inside the VPC, your data is only as encrypted as your HTTPS traffic. Do you trust that?”

The way forward: abstraction, not abdication

I’m certainly not making an argument that you should punt on security in the cloud because it’s too hard. On the contrary, I’m saying that precisely because network security is both hard and important, you should rely on secure defaults wherever you can, instead of brewing your own soup of network controls.

If that sounds like a “serverless” mindset, you’re not far off. After all, as AWS Lambda inventor Tim Wagner is fond of pointing out, all Lambda functions run in a VPC by default -- it’s just an AWS-managed VPC, which (let’s face it) is probably better configured than the custom one you could bring in. 

This is all part of a larger trend. AWS is still handling host-level security for you with their higher-level services like AppSync and DynamoDB. It’s not that network security takes less prominence in these architectures, just that more of the responsibility has shifted down the stack to the cloud provider. Yes, you’re giving up some control. But you’re gaining the ability to build faster while staying within best-practice guardrails put up by AWS.

You might say that securing cloud-native applications is about “letting go and letting cloud.” That’s the paradigm shift legacy security teams are catching up on, but it’s a huge advantage for those who have figured out how to leverage it.

So do your threat modeling, understand your risks, and train your team appropriately. You may still end up with requirements that demand a VPC. But if your cloud-native Spidey senses start tingling, remember: sometimes, great power comes from less responsibility.

Forrest Brazeal is an AWS Serverless Hero and enterprise architect who has led cloud adoption initiatives for companies ranging from startups to the Fortune 50.

Become an AWS-certified security specialist

A Cloud Guru has the courses, hands-on labs, and exam simulators you need to go from novice to guru.