Default VPCs are often insecure cloud environments providing ease of access rather than a secure posture, enabling implicit configurations with insecure defaults
Default Virtual Private Clouds (VPC) are the VPCs that AWS designates as the default destination for resources that require VPC hosting in an AWS region. This means that creation of resources in a given region default to provisioning in the Default VPC. Removing the Default designation prevents AWS from automatically creating resources without specifying the destination VPC, which enforces explicit configuration of the VPC and associated subnets. This removes the potential for accidental provisioning resources in an unintended VPC or subnet.
Additionally, removing the Default VPC configuration also prevents assisted AWS provisioning for AWS managed services and other third party tools that default to utilising any VPC that is marked as the Default VPC. This is usually a net benefit as tools that do not allow the ability to explicitly define target network infrastructure remove the ability to control your network security and correlate with assumptive actions that may not be optimal for your use case.
Generally, if software or tool provisioning does not allow specific targeting of VPC and subnets and instead searches for the “Default” subnet, then it is unlikely to consider network security and architecture as part of it’s installation pattern. If the tool or software is required despite this, then it’s possible to mark the intended VPC as the default VPC temporarily for the installation and to remove that configuration once complete.
Removing the Default VPC configuration in this fashion also adds an additional layer of network discovery for malicious tooling in the case of AWS Account compromise. Rather than utilising whatever the Default VPC is there’s an additional layer of discovery required which would add an effort tax in case of widespread attacks.
Finally, the Default VPC provided by AWS at time of account provision is a VPC consisting solely of public subnets. This is done for a few reasons including:
In all of the above cases, the customer experience beats out the security burden. Hence, if pursuing a stronger security posture rather than ease of use it is best to dispense of the AWS provided VPCs and explicitly configure VPCs for your use case.
SkySiege’s AWS Vulnerability Scan automatically detects this vulnerability across all AWS Regions with the report delivered the same day.
Detecting default VPCs is simple but often time intensive as AWS provisions all accounts with a VPC in every default region. This results in a number of default VPCs packaged into every AWS account. Compounding this is whether those VPCs are already hosting resources.If those VPCs are under active use then deletion of the VPCs is not possible without a migration of those resources into a suitable replacement VPC.
The best method to do this depends entirely on what those resources are, what traffic they’re handling and what business needs they fulfill. Empty VPCs can be easily deleted from the VPC console alongside all the contained subnets and attached internet gateway. VPCs containing running resources would need architectural guidance to ensure that a migration is beneficial and that services remain online: