Networking in AWS is not about "checkboxes somewhere in the console" — it defines the one question that matters most: who can reach whom. It drives both security (is the database exposed to the outside world?) and functionality (can the application see the database?). The good news: the whole model is built from a handful of clear building blocks, and you can assemble it in your head in one sitting.

Imagine AWS as a giant data-center building, and you rent your own isolated floor with your own wiring. No outsider gets onto your floor, and you alone decide which doors to open to the outside. This "personal floor" is the VPC. If you don't have the basic cloud concepts down yet, start with the AWS fundamentals, then come back here for the full networking model.

What a VPC is

A VPC (Virtual Private Cloud) is your isolated virtual network inside AWS. It has its own range of IP addresses, defined via CIDR — a notation like 10.0.0.0/16. The number after the slash tells you how many addresses are in the range: /16 is about 65 thousand addresses, /24 is about 256. The smaller the number, the more addresses.

There's nothing foreign inside a VPC: it's your address space, and traffic between two VPCs doesn't flow until you explicitly allow it. A VPC is created with a single command, and from there you fill it with subnets.

aws ec2 create-vpc --cidr-block 10.0.0.0/16

Subnets: public and private

The large VPC range is sliced into smaller pieces — subnets. Each subnet lives in exactly one availability zone (a separate physical data center within a region). This matters for reliability: if you put everything in one zone, a failure there takes down the entire service.

The main division of subnets is into public and private. The difference comes down to just one thing: whether the subnet has a road to the internet.

  • A public subnet has a route to the outside. This is where you place things that must be reachable from the internet: a load balancer, sometimes a bastion host for SSH access.
  • A private subnet has no direct way out to the internet. This is where you place applications, databases, caches — everything that should not be reachable from outside.

An analogy: a public subnet is the reception desk in an office, where visitors from the street walk in. A private subnet is the inner offices, which you can't reach from the street.

The typical layout of almost any application looks like this: a load balancer in a public subnet, the application and database in private ones, and all of it duplicated across several availability zones for fault tolerance.

aws ec2 create-subnet --vpc-id vpc-0abc --cidr-block 10.0.1.0/24 --availability-zone eu-central-1a
aws ec2 create-subnet --vpc-id vpc-0abc --cidr-block 10.0.2.0/24 --availability-zone eu-central-1b

Routing: where traffic goes

A subnet on its own doesn't "know" whether it's public or private. That's what the route table handles — a simple list of rules of the form "send packets destined for these addresses over there." Each subnet has exactly one route table attached to it.

An Internet Gateway is the VPC's door to the internet. A subnet becomes public precisely because its route table contains a line 0.0.0.0/0 (that is, "the entire rest of the internet") pointing at the Internet Gateway. A private subnet simply doesn't have that line — which is why it has no way out.

But a private service often still needs outbound access: to download an update, call a third-party API, send an event to a payment provider. It doesn't need inbound access for this — nobody from outside should initiate a connection. That's what a NAT Gateway is for.

A NAT Gateway works like a one-way turnstile: traffic from the inside out — go ahead; traffic from the outside in on its own initiative — not allowed. An important detail beginners often get wrong: the NAT Gateway itself sits in a public subnet, because it needs a way out to the internet. Meanwhile the private subnet's route table sends outbound 0.0.0.0/0 traffic not to the Internet Gateway but to this NAT Gateway. That way the service reaches the outside while staying invisible from it.

aws ec2 create-route --route-table-id rtb-public --destination-cidr-block 0.0.0.0/0 --gateway-id igw-0abc
aws ec2 create-route --route-table-id rtb-private --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-0abc

Security groups versus NACLs

Once traffic has reached the subnet and the resource, it gets filtered. AWS has two levels of filtering, and people constantly mix them up.

A security group is a firewall at the level of a specific resource (a virtual machine, a container, a database endpoint). It has two key characteristics:

  • it is stateful ("with memory"): if you allow an inbound connection, the response to it goes out automatically — you don't need to write a separate outbound rule;
  • it only has allow rules. You can't explicitly deny anything — whatever isn't allowed is already closed.

A Network ACL (NACL) is a firewall at the level of an entire subnet. Its characteristics are the opposite:

  • it is stateless ("without memory"): you need separate rules for inbound and outbound. If you allow an inbound request, don't forget to allow the outbound response too, or the connection will hang;
  • it has both allow and deny rules.

In practice, the main working tool is security groups: they're targeted and tied to a resource. NACLs are used less often, for coarse blocking at the subnet level (for example, banning an entire address range).

A very handy trick: reference one security group from another. Instead of writing down IP addresses (which change), the rule "the application may reach the database" is phrased like this: the database's security group accepts traffic from the application's security group.

aws ec2 authorize-security-group-ingress \
  --group-id sg-database \
  --protocol tcp --port 5432 \
  --source-group sg-application

Connecting networks

Real-world systems rarely fit into a single VPC: different teams, different environments, different accounts. There are several ways to connect networks.

  • VPC peering — a direct connection between two VPCs. An important nuance: it is not transitive. If A is connected to B, and B is connected to C, that does not mean A can see C. Each pair must be connected separately — as the number of networks grows, this turns into a web of connections.
  • Transit Gateway — a central hub that many VPCs (and even an on-premises office network) connect to. Instead of a scatter of peering connections, everyone goes through a single node. This is a lifesaver when the number of networks grows large.
  • PrivateLink and VPC endpoints — access to a service over a private network, without going out to the internet at all. Through a VPC endpoint, a private subnet can, for example, reach object storage S3 or Secrets Manager without opening an internet route. The traffic never leaves the AWS network.

VPC endpoints are almost always the right answer to the question "how can a private service securely reach a managed AWS service."

Where this is used

AWS networking is the foundation everything else stands on. A load balancer in a public subnet, the application and database in private ones, NAT for outbound calls, security groups describing "who can reach whom" — you'll encounter this layout in practically any production deployment. When traffic is distributed across several availability zones, as in the article on scaling and availability, this exact networking model is at work under the hood.

Typical beginner mistakes worth memorizing in advance:

  • placing a database in a public subnet — it becomes reachable from the internet, which is a direct security hole;
  • expecting outbound access from a private subnet without a NAT Gateway — outbound calls will silently hang;
  • placing a NAT Gateway in a private subnet — it won't get a way out to the internet itself and won't work;
  • forgetting about the stateless nature of NACLs — allowing inbound but not the return outbound, and the connection won't establish;
  • writing down IP addresses instead of references between security groups — addresses change, and the rules break.

What to learn next: networking answers "who can reach where," but who is allowed to do what with resources — that's already IAM, the second layer of security. After that it's useful to look at where exactly your services live — on virtual machines from the compute section or in the serverless model. And to avoid configuring all of this by hand every time, learn the "infrastructure as code" approach: start with the IaC fundamentals, then move on to Terraform or CloudFormation. If your application runs on Kubernetes, the cluster's networking model layers on top of the VPC — see the section on Kubernetes fundamentals.