Skip to content
AWS aws networking 5 min read

The Default VPC

When you first open an AWS account, you don’t start with a blank network. In every Region, AWS pre-builds a ready-to-use network called the default VPC (a VPC, or Virtual Private Cloud, is your own private network inside AWS). It’s wired up so that anything you launch can reach the internet immediately, with zero setup. That convenience is exactly why it’s great for learning and exactly why it’s risky for real workloads.

What the default VPC actually is

AWS automatically creates one default VPC per Region (so an account active in 5 Regions has 5 default VPCs). Each one comes fully assembled so you can launch an instance and connect to it in minutes. Out of the box it includes:

  • A VPC with a 172.31.0.0/16 CIDR block. A CIDR block (Classless Inter-Domain Routing) is just the range of private IP addresses the network can use. 172.31.0.0/16 gives you about 65,000 addresses.
  • One default subnet in each Availability Zone (an AZ is a separate data center location within a Region). A subnet is a smaller slice of the VPC’s IP range tied to one AZ.
  • An internet gateway (IGW) — the component that lets traffic flow between your VPC and the public internet — already attached.
  • A route table with a route sending all internet-bound traffic (0.0.0.0/0) to that internet gateway.
  • A default security group and a default network ACL that allow normal traffic.

Because every default subnet has a route to the internet gateway, every default subnet is a public subnet.

The single most important fact about the default VPC: every default subnet auto-assigns a public IP address to instances you launch into it. That means anything you start is internet-facing by default unless you change a setting.

When to use it (and when not to)

ScenarioUse the default VPC?Why
Learning AWS, following a tutorialYesFast to launch, nothing to configure
A quick throwaway test instanceYesYou’ll terminate it shortly anyway
A short-lived demo or proof of conceptMaybeFine if it holds no sensitive data
A production app, database, or anything with real dataNoYou need private subnets and controlled access
Anything that must meet a compliance or security baselineNoDefault-public networking fails most audits

The rule of thumb: the default VPC is a sandbox. The moment a workload matters, build a custom VPC with private subnets so your databases and application servers are not reachable from the internet.

Inspecting your default VPC

Console steps

  1. Open the AWS Management Console and go to the VPC service.
  2. In the left menu, choose Your VPCs.
  3. Look for the VPC with the Default VPC column set to Yes.
  4. Note its CIDR (172.31.0.0/16) and click it to view attached resources.
  5. Choose Subnets in the left menu to see one default subnet per Availability Zone.

AWS CLI

This works with AWS CLI v2. The --filters flag asks only for the VPC flagged as default.

aws ec2 describe-vpcs \
  --filters "Name=isDefault,Values=true" \
  --query "Vpcs[].{VpcId:VpcId,Cidr:CidrBlock,Default:IsDefault}" \
  --output table

Output:

---------------------------------------------
|               DescribeVpcs                |
+----------------+----------------+---------+
|     Cidr       |    Default     |  VpcId  |
+----------------+----------------+---------+
|  172.31.0.0/16 |  True          |  vpc-0a1b2c3d  |
+----------------+----------------+---------+

To confirm the public-IP behavior, check a default subnet’s MapPublicIpOnLaunch setting:

aws ec2 describe-subnets \
  --filters "Name=vpc-id,Values=vpc-0a1b2c3d" \
  --query "Subnets[].{Subnet:SubnetId,AZ:AvailabilityZone,AutoPublicIp:MapPublicIpOnLaunch}" \
  --output table

Output:

-----------------------------------------------------------
|                     DescribeSubnets                     |
+----------------+-----------------+----------------------+
|  AutoPublicIp  |       AZ        |       Subnet         |
+----------------+-----------------+----------------------+
|  True          |  us-east-1a     |  subnet-0a1b2c3d     |
|  True          |  us-east-1b     |  subnet-0b2c3d4e     |
|  True          |  us-east-1c     |  subnet-0c3d4e5f     |
+----------------+-----------------+----------------------+

AutoPublicIp: True is the gotcha. Anything you launch here gets a public IP and is exposed to the internet, gated only by its security group.

The gotcha, made concrete

Imagine you launch an EC2 instance to test a database and leave its security group open on port 22 (SSH) or 3306 (MySQL) to 0.0.0.0/0. In a default VPC that instance has a public IP the instant it boots, so the entire internet can attempt to connect. Automated bots scan public AWS IP ranges constantly and will find an open port within minutes.

In a properly built custom VPC, that same database would sit in a private subnet with no route to the internet gateway and no public IP — unreachable from outside no matter how the security group is set. That’s the safety net the default VPC simply does not give you.

Turning off auto-assign (a partial fix)

You can stop a default subnet from handing out public IPs without rebuilding anything:

aws ec2 modify-subnet-attribute \
  --subnet-id subnet-0a1b2c3d \
  --no-map-public-ip-on-launch

Output:

(no output on success)

This helps, but the subnet still has a route to the internet gateway, so it’s still a public subnet at heart. The real fix is a custom VPC with genuinely private subnets.

Recreating a deleted default VPC

If you (or a security policy) deleted the default VPC and later need it back, you don’t rebuild it by hand — AWS can regenerate it:

aws ec2 create-default-vpc

Output:

{
    "Vpc": {
        "VpcId": "vpc-0a1b2c3d",
        "CidrBlock": "172.31.0.0/16",
        "IsDefault": true,
        "State": "available"
    }
}

Cost note: the default VPC, its subnets, route tables, and internet gateway are all free. You only pay for resources you launch into it (EC2 instances, data transfer, etc.) and for any Elastic IP (a permanent public IP address) that is allocated but not attached to a running instance.

Best Practices

  • Treat the default VPC as a learning sandbox only — never run production, databases, or sensitive data in it.
  • Build a custom VPC with both public and private subnets for any real workload, and place backends in the private subnets.
  • Remember that every default subnet auto-assigns public IPs; disable that with --no-map-public-ip-on-launch if you must use it temporarily.
  • Never open security groups to 0.0.0.0/0 on management ports like 22 or 3389 in a default VPC — bots will find them fast.
  • Use AWS Organizations Service Control Policies or AWS Config rules to flag or block launches into default VPCs across your accounts.
  • Delete unused default VPCs in Regions you don’t operate in to shrink your attack surface (and recreate with create-default-vpc if ever needed).
Last updated June 15, 2026
Was this helpful?