Alright, let’s get our hands dirty. Before you start launching anything, you need to understand the plot of land AWS is giving you: the Virtual Private Cloud, or VPC. Think of it not as some nebulous cloud thing, but as your own logically isolated section of the AWS data center. It’s your own private rack, with its own network rules, and nobody else gets to play in it unless you explicitly invite them. This is the foundation for everything else you’ll build on AWS, so pay attention.

Your VPC’s Address Plan: CIDR Blocks

Every network needs an address range, and in the networking world, we define that range using Classless Inter-Domain Routing (CIDR) notation. It looks scary, but it’s simple: it’s just a starting IP address and a number that defines the size of your pool. The format is x.x.x.x/y, where the /y (the prefix) is the number of bits locked in. More bits locked in means a smaller network.

When you create a VPC, you give it a CIDR block. The maximum size is a /16 (65,536 IP addresses) and the minimum is a /28 (16 addresses). For the love of all that is good and performant, do not use the tiny /28 for your main VPC. You’ll run out of space for subnets faster than you can say “I need to re-architect everything.” A /16 (like 10.0.0.0/16) is a safe, spacious bet for most projects.

Why does this matter? Because this CIDR block is the absolute universe of IP addresses your VPC can use. Every subnet, every EC2 instance, every internal ELB—everything gets its private IP from this pool. And you can’t change it later. So choose wisely.

# Creating a VPC with a sensible, large CIDR block.
# This gives us IPs from 10.0.0.0 to 10.0.255.255
aws ec2 create-vpc --cidr-block 10.0.0.0/16

The Default VPC: AWS’s Handy but Flawed Gift

When you first create an AWS account, they gift you a “Default VPC” in every region. It’s meant to be a friendly, quick-start environment. It comes with a /20 CIDR block, a public subnet in each Availability Zone, and an Internet Gateway already attached. This is great for kicking the tires, but it’s a horrible idea for any real, production workload.

Why? First, its CIDR is small (/20 is only 4096 addresses). Second, and more importantly, its default configuration is wildly insecure. The main “default” security group allows all traffic from other resources in the same group. It teaches terrible habits. My advice? Use it for quick experiments, then build your own proper, purpose-built VPCs from the ground up. Know where it is so you can avoid it.

# Listing your VPCs. The 'IsDefault' field is the tell.
aws ec2 describe-vpcs --query 'Vpcs[*].{VpcId:VpcId, CidrBlock:CidrBlock, IsDefault:IsDefault}'

The Shared Responsibility of Tenancy

“Tenancy” answers a simple question: does your EC2 instance run on dedicated physical hardware just for you (“dedicated”) or on shared hardware with other AWS customers (“default”)? For 99.9% of use cases, you want default. It’s vastly cheaper and AWS’s multi-tenant isolation is rock-solid; there’s no meaningful “noisy neighbor” risk for most workloads.

The dedicated tenancy option is ludicrously expensive and is really only for the most extreme regulatory or compliance requirements where you must have a physical separation. You can set this at the VPC level (instance-tenancy attribute) to force every instance in the VPC to be dedicated, but honestly, if you’re doing that, you probably have a compliance team telling you to do it. For everyone else, stick with default and stop worrying.

# Creating a VPC with default tenancy (shared hardware)
aws ec2 create-vpc --cidr-block 10.0.0.0/16 --instance-tenancy default

# Creating a VPC that will require dedicated ($$$) hardware for all instances
aws ec2 create-vpc --cidr-block 10.1.0.0/16 --instance-tenancy dedicated

Why Your VPC is Not an Island

Here’s the most common “aha!” moment for beginners: creating a VPC is just step one. A virgin VPC, fresh out of the create-vpc API, is a completely isolated network. It has no internet access, no connection to your corporate network, and not even a way to talk to other AWS services like S3 or DynamoDB via their public endpoints. It’s a castle with the drawbridge up and no doors installed yet.

This is by design. AWS gives you maximum flexibility to build exactly the network you need, which means you have to explicitly add the components—like subnets, route tables, and gateways—that define how traffic flows in and out. It feels tedious at first, but this explicit control is what makes building secure, complex architectures possible. Now, let’s start building those doors and drawbridges by slicing it up into subnets.