Other Articles
- Secure AWS Deployments with OIDC
- Build Secure Network Subnet Topology
- Instance/Host Roles in AWS
- Enable AWS GuardDuty for Threat Detection
- AWS CloudTrail: API Logging and Activity Monitoring
- Data Protection Using Envelope Encryption
- Restricting SSH Access on AWS Using IP Whitelisting
- GitHub – Enabling and Managing Dependabot Scans
Removing Default VPCs and Blocking Their Recreation with an AWS SCP
Overview
This article explains how to delete the default VPCs AWS creates in every region and how to use a Service Control Policy (SCP) in AWS Organizations to prevent anyone from recreating them.
Most teams only use one or two regions, but AWS creates a default VPC in every enabled region. Removing the ones you don't use, and blocking their recreation, keeps your network footprint intentional.
What is a Default VPC?
A default VPC is a ready-made network that AWS creates automatically in each region of your account. It comes with public subnets, an internet gateway, and a fixed CIDR range (172.31.0.0/16), so resources can be launched without any network setup.
A Service Control Policy (SCP) is an AWS Organizations policy that sets the maximum permissions for the accounts it is attached to. A "Deny" in an SCP applies to every user and role in the account, including administrators.
Why Remove Default VPCs?
- Default subnets are public, so resources launched into them without care can end up reachable from the internet
- Resources can be created in regions nobody monitors, since the default VPC makes it easy to launch there
- Every default VPC uses the same CIDR range, which can cause overlap problems when you later connect networks
- Supports network segregation expectations under frameworks like ISO 27001
- AWS security guidance recommends deleting default VPCs in all regions, not only the ones you deploy in
Benefits
- Teams must create purpose-built VPCs with deliberate network settings
- Smaller, cleaner set of resources to audit
- SCP enforcement means a deleted default VPC cannot be quietly recreated
- AWS Organizations and SCPs are free of charge
How It Works
1. Audit each region
Check that nothing is running in a default VPC before deleting it. Network interfaces cover most services that run inside a VPC (EC2, RDS, load balancers, Lambda in a VPC, NAT gateways):
for region in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
vpc=$(aws ec2 describe-vpcs --region $region --filters Name=isDefault,Values=true \
--query "Vpcs[0].VpcId" --output text)
[ "$vpc" = "None" ] && { echo "$region no default VPC"; continue; }
eni=$(aws ec2 describe-network-interfaces --region $region \
--filters Name=vpc-id,Values=$vpc --query "length(NetworkInterfaces)" --output text)
echo "$region $vpc network-interfaces: $eni"
done
Only delete a default VPC when its network interface count is 0.
2. Delete the default VPCs
- Open VPC → Your VPCs in the region
- Select the VPC marked Default VPC: Yes
- Choose Actions → Delete VPC. The console also removes the attached internet gateway and subnets
- Repeat for each region, keeping the regions you actively use
3. Create the SCP
From the organization's management account, go to AWS Organizations → Policy management → Service control policies (enable SCPs first if needed), create a policy named deny-default-vpc-creation, and use:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyDefaultVpcCreation",
"Effect": "Deny",
"Action": [
"ec2:CreateDefaultVpc",
"ec2:CreateDefaultSubnet"
],
"Resource": "*"
}
]
}
4. Attach the SCP
- Open the policy and go to the Targets tab
- Choose Attach and select the accounts or OU to protect
- Start with a test account, then widen to the root once confirmed
5. Test the policy
In a member account the SCP is attached to, pick a region where you deleted the default VPC and choose Actions → Create default VPC, or run aws ec2 create-default-vpc --region <region>. The request should fail with a message stating an explicit deny in a service control policy.
Common Use Cases
- Hardening a new AWS Organization before teams start deploying
- Cleaning up older accounts that still have default VPCs in unused regions
- Meeting audit requirements for network segregation and controlled resource placement
- Standardising on custom VPCs built through Terraform or CloudFormation
Example Scenario
- A company operates in the Mumbai region only, but its account has default VPCs in 17 other regions
- The audit shows no network interfaces in any of them
- The team deletes the default VPCs in the unused regions and keeps Mumbai
- An SCP denying ec2:CreateDefaultVpc and ec2:CreateDefaultSubnet is attached to the member accounts
- A test attempt to recreate a default VPC fails with an explicit deny from the SCP
Best Practices
- Run the audit first and delete only VPCs with no network interfaces
- Check Terraform and CloudFormation code for references to the default VPC before deleting it
- Test the SCP on a single non-production account before attaching it to the root
- Attach the SCP at an OU or the root once confirmed, so new accounts are covered
- Restrict who can enable new AWS regions, since unused regions invite unmanaged resources
- Delete default VPCs as part of onboarding every new account and newly enabled region
Common Mistakes to Avoid
- Deleting a default VPC without checking for resources or code that depends on it
- Assuming the SCP removes existing default VPCs. It only blocks creating new ones
- Forgetting that SCPs never apply to the management account, so its default VPCs must be deleted manually
- Expecting the SCP to stop AWS from automatically creating default VPCs for new accounts or newly enabled regions. Plan to delete them after creation
- Testing in the management account, where SCPs have no effect
Updated on 26 October, 2026