For new AWS accounts, default VPCs with subnets in every AWS region are created automatically. AWS does this to make it easy for new users to get started quickly; however it’s a nuisance to manage for your next account and every one after that. Most enterprise customers have dozens, if not hundreds of accounts, and default VPCs add complexity as they are automatically created in every region, have overlapping CIDR ranges, and assume public routing. Having default VPCs lying around creates risk that developers will deploy into the wrong region or will accidentally create public resources. This week we will look at how Turbot can help enforce the removal of unneeded default VPCs.
Traditional Workflow
Most Turbot customers have defined cloud networking requirements:
Specific approved regions that align to the corporate network (e.g. only us-east-1, eu-west-1 and ap-southeast-1).
Majority of workloads are internal facing, public workloads are the exception.
CIDR ranges are predefined per region, and allocated purposely per VPC to avoid overlapping CIDR ranges across the network.
Because default VPCs exist, we must decide how to handle them:
Delete all default VPCs and create custom VPCs in approved regions automatically?
Delete all default VPCs and create custom VPCs as needed?
A few services (like LightSail) require the default VPC, is an exception process needed for those services in some regions?
Keep the default VPCs, but remove Internet gateways and public routing to limit risk?
Leave in place, but clean up resources when discovered.
Our best practice recommendation is that customers delete all default VPCs and then recreate a template VPC in approved regions. Once you have made the decision that deleting default VPCs makes sense for your situation, taking action quickly will avoid more pain later trying to delete when resources are running those VPCs.
Get it done with Turbot
Approved guardrails exist for every standard cloud resource in Turbot. By changing the setting of “AWS > VPC > Default VPC > Approved” to “Not Approved” we tell Turbot’s automation that no default VPCs are allowed to exist. Once Turbot’s automation identifies a resource (e.g. a default VPC) as not approved, it has the ability to remediate it with complimentary corrective controls (or alert you with detective controls).
Create a new policy to force the default VPC key to “Not Approved”:
Create a new policy to take corrective action for resources that are in a “not approved” state:
After setting these policies, Turbot automation will identify all default VPCs that are not approved, and then handle remediation (default VPC deletion). This setting is safe, even in enforcement mode, because AWS does not allow you to delete VPCs with resources deployed in them (even if that resource is just a security group). This means that even if you have some default VPCs in use, you can safely set Turbot to clean default VPCs with the confidence that Turbot will only raise an alert and be unable to take enforcement action until the offending resources are cleaned up.
Make it happen
See for yourself how easy it is to remove default VPCs with just a few clicks. The policy examples above are available as a Terraform template in the Turbot Development Kit (TDK). If you need any assistance getting this configured in your environment please reach out to Turbot Support, and keep an eye on your inbox for another Turbot tip next week!
Cheers,
Bob