Other Articles

Removing Default VPCs and Blocking Their Recreation with an AWS SCP

Support > Tech Best Practices

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