Default VPCs and Unused Resources: Delete or Keep?

Default VPCs and Unused Resources: Delete or Keep?

Should I delete default VPCs and unused resources? This question comes up so often with both new and seasoned AWS customers that I will summarize the best practice here at the top of this post.

  • Delete VPCs in regions you do not use, especially the default VPCs.  
  • Don’t use default settings, ever.
  • Delete unused resources, even if they have no cost.
  • Invest in automation that takes care of these for you.

On Jan 6th, 2016 AWS announced ap-northeast-2 in Seoul, South Korea.  On Jun 27th, ap-south-1 in Mumbai, India was made public. (According to this map, there are at least four more AWS regions coming on-line, as AWS continues to expand around the globe.)  When the new Seoul and Mumbai regions opened, they immediately triggered an influx of new alerts for many Evident.io customers.  This is a benefit to having a continuous security monitor that dynamically expands to match the services being deployed by AWS, but at the same time, most folks had no resources in these new regions, so why the alerts? If you haven’t launched any AWS resources in a region, that region is secure by default, right?

Let’s answer that by first stepping back in time to what is now known as EC2 Classic. Back then when you launched EC2 resources, the resulting instances were defended primarily by Security Groups. In today’s security landscape, this may seem inconceivable, but it is true. Over time, AWS gave customers the ability to create their own Virtual Private Clouds (VPCs). VPCs came with additional security controls and grew to be very robust in their capacity to layer security checks in-between the Internet-at-large and corporate data. Today, VPCs are standard fare, and there are no new AWS accounts provisioned with legacy EC2 Classic regions any more. Unless you have one of the older AWS accounts, you do not have the ability to launch old fashioned classic ec2 resources; and that is a good thing for security.

AWS: Simple & Easy to Use

The DevOps and infrastructure as code movements took off to a great part due to the ease of ability to deploy entire farms of systems with very few buttons, knobs, or approval requests. This ease of use came with many default settings. Imagine the challenges to adopting public cloud if you had to be a network engineer to get traffic to and from your virtual resources? To ensure you and I and everyone could launch resources with little friction, AWS comes with default settings. These “defaults” are usually good enough to get things up and running, but may be less than ideal for security. As an example, the default VPC comes with a default Security Group that denies all inbound traffic but allows all outbound traffic. All internal traffic within the VPC is also allowed. The internal network trust set by default helps me deploy web, app, and database servers in my VPC and they all can connect to each other by default. Since my default VPC comes with an Internet gateway, it is relatively easy to allow traffic from the Internet while outbound connections are fully allowed without any additional configurations.  

This ease of use is a double-edged sword. On one hand, it is easy to set up and run infrastructure, while on the other, I may have by-passed several security considerations by accepting the defaults. Thankfully, services like the Evident Security Platform can help get visibility to the default settings that are implemented and identify the risks and remediation steps.  

Security Impacts of Default VPCs

VPCs come with de facto defaults that are inherently less than ideal from a security perspective. How to deal with it? Well, AWS has given you the ability to turn this into a positive by just removing the offending item. In this case, that is the VPC. Yes, you can remove the entire default VPC. If you are not going to use a region, if you have regions that are not in use, or if you are not using the default VPCs created by AWS, then now is a good time to delete any and all of the VPCs from those regions. A VPC by itself has no cost, so it is also easy to forget about VPCs that were created temporarily and no longer in use. These temporary VPCs are common when first learning how AWS works and when testing out a new project or feasibility to use AWS. Take this time to go ahead and audit and delete them as well.

Is it safe?  Sure, this is the cloud: you can destroy and rebuild in a simple script or with a few mouse clicks in the AWS console. As a safety precaution, you cannot delete a VPCs if they have current resources. A default VPC will also warn you if you try and remove it in the console. You always have the ability to create a VPC after you have removed the default one.

A key benefit of removing the default VPC in each unused region is that you cannot launch resources without a VPC. Before launching new resources, you must provision new VPC. This dependency works to your security advantage because when you provision the VPC, you have the opportunity to review the security settings. The lack of a default VPC is a layer of safety in itself, preventing launches and unexpected resources. So, if it hasn’t been abundantly clear, you should remove all empty VPCs. Not only does their value fade when not being used, but without clear documentation on why the VPC was there, or it’s purpose, the VPC may be inadvertently used for something other than its intended purpose.

While you are in cleanup mode, if a configuration item like a Security Group or Network Access Control List is not in use, delete that, too. Even though it might be free, there are few reasons to keep unused items around. It is easy to rebuild security groups if needed, but not so much if the wrong application ends up in the wrong security group. Go ahead and take the time to audit your unused items. Since there is no cost to many of these items, they tend to slip under the radar. It is a good security best practice, in general, to always delete unused items, especially those that are security-related.

Convert from Classic EC2 to VPC

If you have a region that is still Classic-EC2, fear not, you can ask AWS to convert it to VPC by default. Turning an AWS region to only support VPCs helps secure your environments. Before you do this, however, make sure there are no legacy applications that depend on this configuration. If you have some, AWS has tooling to help migrate into a VPC from EC2 Classic. AWS security best practices include ensuring that you have no inactive, empty or default VPCs. Regions not in use should have no resources in them, even if those resources are logical and have zero cost.

In summary, delete the defaults, so they cannot be used. And, delete infrastructure and configurations not in use, too. Can this be scripted? Yes, you can inspect an AWS account via the CLI or one of the SDKs and look for these items, then delete them. You can also leverage a service like Evident Security Platform (ESP) that makes these inspections automatically and can trigger a Lambda function to do that for you, continuously.

Curious how many default VPCs and unused resources you have in your AWS account? In just 5 minutes, you can have Evident Security Platform (ESP) up and running and have complete visibility of your AWS infrastructure. Try it today.

About John Robel

John Robel is a Principle Solutions Architect for Evident.io with over 20 years experience, and his previous role was as a Senior Technical Account Manager at AWS where he managed customer relationships with some of the largest AWS enterprise customers like Netflix and Adobe. John is an AWS Certified Solutions Architect and has been both Cisco Certified as a Network Associate and ITIL Foundation certified.

More posts by John

Tags: , , , , ,