What Happens When You Type google.com? Networking Fundamentals Explained Through AWS
Follow a request from your browser to google.com to understand DNS, IP addresses, CIDR, subnets, ARP, routing, NAT, TCP, TLS, ports, HTTP, firewalls, and how these networking fundamentals map to AWS.
37 min read
Introduction
You open your browser and type:
https://google.comA fraction of a second later, Google's page appears.
It feels simple.
But your browser did not magically communicate with Google.
A lot happened between:
https://google.comand:
Google's response appearsYour computer had to answer questions like:
What is google.com?
What IP address belongs to it?
Is that IP on my local network?
If not, where should I send the packet?
How does the packet leave my home network?
How does it travel across the Internet?
Which application on Google's server should receive it?
How do we establish a reliable connection?
How do we encrypt that connection?
How does Google send the response back?These questions introduce most of the networking fundamentals developers need to understand.
And interestingly, the same concepts appear when you build applications inside AWS.
Conceptually, our request looks something like:
Browser
|
↓
DNS
|
↓
IP Address
|
↓
Local Network
|
↓
Router
|
↓
NAT
|
↓
ISP
|
↓
Internet Routers
|
↓
Google Network
|
↓
ServerLater, we will see a similar architecture inside AWS:
User
|
↓
Route 53
|
↓
Internet
|
↓
Internet Gateway
|
↓
VPC
|
↓
Route Table
|
↓
Load Balancer
|
↓
EC2 / ECS / EKSBut before AWS networking makes sense, we need to understand the networking underneath it.
So let's follow one request.
Step 1: You Enter google.com
You type:
https://google.comYour browser understands this as a URL.
Very roughly, it contains:
https://google.com
| |
| └── Hostname
|
└── ProtocolBut the Internet does not route packets using the string:
google.comNetworks primarily route packets using:
IP addressesSo before your computer can contact Google, it needs to answer:
What IP address belongs to google.com?This is where DNS enters the story.
What Is DNS?
DNS stands for:
Domain Name SystemIts basic job is to map names to information such as IP addresses.
Conceptually:
google.com
|
↓
DNS
|
↓
IP addressWithout DNS, you would need to remember IP addresses instead of domain names.
Instead of:
google.comyou might need to remember an address such as:
142.x.x.xThe exact address can vary because large services use many servers, networks, and traffic-management systems.
The important idea is:
Human-friendly name
|
↓
DNS
|
↓
Network addressYour Computer Does Not Always Ask the Internet
DNS resolution does not necessarily start by contacting distant DNS servers.
Your system may already know the answer.
DNS information can exist in caches at multiple levels.
Conceptually:
Browser DNS cache
|
↓
Operating system cache
|
↓
Configured DNS resolver
|
↓
Further DNS resolutionIf a valid cached answer exists, DNS resolution can stop early.
Otherwise, your machine sends a DNS query to its configured resolver.
That resolver might be provided by:
Your router
Your ISP
A public DNS provider
Your organizationThe resolver then works to obtain the answer.
Recursive DNS Resolution
Suppose the resolver does not already have the answer cached.
At a simplified level, DNS resolution can involve:
Resolver
|
↓
Root DNS
|
↓
.com DNS
|
↓
Authoritative DNS
|
↓
AnswerImagine asking:
Where is google.com?The root server does not necessarily return Google's final IP address.
Instead, it can direct the resolver toward the DNS infrastructure responsible for:
.comThe .com nameservers can then direct the resolver toward the authoritative DNS servers responsible for the domain.
Eventually, the resolver obtains the relevant DNS record.
Conceptually:
google.com
|
↓
DNS lookup
|
↓
142.x.x.xThe result is then commonly cached for a period determined by DNS configuration such as the record's TTL.
DNS in AWS
Now we can connect our first networking fundamental to AWS.
AWS provides DNS-related services through Route 53 and Route 53 Resolver.
A public application might conceptually look like:
example.com
|
↓
Route 53
|
↓
Application Load BalancerInstead of manually remembering the load balancer's generated DNS name, you can configure your domain to resolve toward your AWS infrastructure.
Inside a VPC, DNS resolution is also important.
For example:
EC2
|
| api.internal.example.com
↓
Route 53 Resolver
|
↓
Private Hosted Zone
|
↓
Private resourceSo:
Normal Networking AWS
DNS → Route 53
DNS Resolver → Route 53 Resolver
DNS Records → Hosted ZonesAWS did not invent DNS.
AWS provides services built around the same DNS fundamentals used across networks and the Internet.
Step 2: Now We Have an IP Address
After DNS resolution, our computer has a destination IP address.
Conceptually:
google.com
|
↓
DNS
|
↓
142.x.x.xNow another question appears:
What exactly is an IP address?What Is an IPv4 Address?
An IPv4 address contains 32 bits.
It is normally displayed using four decimal numbers.
For example:
192.168.1.20Each section represents 8 bits.
192 168 1 20
8 bits 8 bits 8 bits 8 bits
32 bitsAn IP address identifies an interface participating in an IP network.
But knowing an IP address alone is not enough.
Your computer also needs to understand which addresses belong to its local network.
That leads us to:
Subnet masks
and
CIDRWhat Does /24 Mean?
You may have seen addresses like:
192.168.1.20/24The /24 represents the prefix length.
It means that the first 24 bits identify the network prefix.
Conceptually:
192.168.1.20/24
Network portion Host portion
─────────────── ────────────
192.168.1 20For the network:
192.168.1.0/24the address range is based on that 24-bit prefix.
A simplified mental model is:
192.168.1.x
belongs to the same /24 networkSo if your laptop is:
192.168.1.20/24and another device is:
192.168.1.50they are in the same /24 network.
But Google's address is not:
192.168.1.xSo your computer realizes:
Google is not on my local subnet.That decision is extremely important.
CIDR in AWS
AWS VPCs use the same CIDR concept.
You might create a VPC:
10.0.0.0/16Then divide it into smaller subnets.
For example:
VPC
10.0.0.0/16
|
├── 10.0.1.0/24
|
├── 10.0.2.0/24
|
├── 10.0.3.0/24
|
└── 10.0.4.0/24The AWS console may make this feel like an AWS-specific configuration.
It is not.
You are applying ordinary IP addressing and subnetting concepts to a virtual network.
Networking Fundamental AWS
IP network → VPC CIDR
Subnet → VPC Subnet
IP address → Private/Public IP on resourcesUnderstanding CIDR outside AWS makes VPC design much easier to understand.
Step 3: Google Is Not on Our Local Network
Our laptop might have:
IP Address: 192.168.1.20
Subnet: 192.168.1.0/24
Default Gateway: 192.168.1.1Google's destination address is somewhere outside:
192.168.1.0/24So the laptop cannot treat Google as a local destination.
Instead, it sends the traffic toward its:
Default GatewayUsually, on a home network, that gateway is your router.
Conceptually:
Laptop
192.168.1.20
|
| Destination is not local
↓
Default Gateway
192.168.1.1But there is another problem.
How does the laptop actually send a frame to the router on the local network?
This introduces another networking layer.
IP Addresses and MAC Addresses Are Different
At the IP layer, your laptop knows:
Default Gateway IP
192.168.1.1But technologies such as Ethernet deliver frames on the local network using link-layer addresses.
A common link-layer identifier is a:
MAC addressSo your computer may need to determine:
Which MAC address corresponds to 192.168.1.1?For IPv4 networks, this is where ARP is used.
What Is ARP?
ARP stands for:
Address Resolution ProtocolAt a simplified level, your computer asks the local network:
Who has 192.168.1.1?The router responds with its MAC address.
Conceptually:
Laptop
Who has 192.168.1.1?
|
↓
ARP
|
↓
Router
192.168.1.1 is at
AA:BB:CC:DD:EE:FFNow your laptop knows where to send the local frame.
Layer 2 vs Layer 3
This introduces an important distinction.
Layer 2
────────
Local frame delivery
MAC addresses
Layer 3
────────
Routing between IP networks
IP addressesImagine the packet is traveling from your laptop to Google.
The destination IP remains associated with the remote destination.
But the local frame is initially sent to the next-hop router.
Conceptually:
Ethernet/Wi-Fi Frame
Source MAC:
Laptop
Destination MAC:
Router
IP Packet
Source IP:
Laptop
Destination IP:
GoogleThese are different responsibilities.
A useful mental model is:
IP address
|
└── Where should the packet ultimately go?
MAC address
|
└── Where does this local frame go next?What About ARP in AWS?
AWS VPC networking does not expose the underlying physical network in the same way as a traditional LAN.
AWS virtualizes much of this infrastructure.
As an application developer, you normally work with abstractions such as:
VPC
Subnets
ENIs
Private IP addresses
Route tables
Security groupsYou usually do not manage physical switches or physical MAC forwarding infrastructure.
This is an important cloud networking idea:
The networking fundamentals still exist.
But cloud providers abstract much of the physical implementation.Step 4: The Packet Reaches the Router
Our packet reaches the home router.
Now the router needs to answer:
Where should I send this packet next?This introduces one of the most important concepts in networking:
RoutingWhat Is Routing?
Routing is the process of deciding where packets should go next.
A machine can maintain a routing table.
A simplified laptop routing table might conceptually look like:
Destination Next Hop
192.168.1.0/24 Local network
0.0.0.0/0 192.168.1.1The first route means:
If destination belongs to 192.168.1.0/24,
it is reachable locally.The second means:
Everything else goes to the default gateway.What Is 0.0.0.0/0?
You will see this constantly in AWS.
0.0.0.0/0means the IPv4 default route.
Conceptually:
Any IPv4 destination
not matched by a more specific routeSo:
0.0.0.0/0 → gatewaymeans:
Send otherwise-unmatched traffic toward this next hop.Longest Prefix Match
Routers generally prefer the most specific matching route.
Imagine:
10.0.0.0/8 → Gateway A
10.10.0.0/16 → Gateway B
0.0.0.0/0 → Gateway CAnd the destination is:
10.10.5.20Multiple routes technically match.
But:
10.10.0.0/16is more specific than:
10.0.0.0/8So that more specific route is preferred.
This concept becomes extremely useful when debugging AWS networks.
Routing in AWS
AWS VPCs have route tables.
Suppose we have:
VPC
10.0.0.0/16A public subnet might have a route table resembling:
Destination Target
10.0.0.0/16 local
0.0.0.0/0 Internet GatewayThe local route allows communication within the VPC according to the network configuration and security controls.
The default route sends Internet-bound traffic toward the Internet Gateway.
Conceptually:
EC2
|
↓
Subnet
|
↓
Route Table
|
├── 10.0.0.0/16 → local
|
└── 0.0.0.0/0 → Internet GatewayAWS route tables are not an entirely new concept.
They are AWS's representation of fundamental IP routing behavior.
A Subnet Is Not Public Because of Its Name
Suppose you create:
10.0.1.0/24and name it:
public-subnetThat name does not make it public.
You could call it:
super-public-internet-subnetand nothing would change.
What matters is the networking configuration.
For IPv4 Internet access, an important part of a public subnet design is a route such as:
0.0.0.0/0 → Internet GatewayResources also need appropriate addressing and security configuration.
So:
Subnet name
≠
Public subnetThe routing and resource configuration determine the behavior.
Step 5: Our Laptop Has a Private IP Address
Our laptop has:
192.168.1.20Addresses from certain ranges are reserved for private networking.
Common IPv4 private ranges include:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16These addresses are widely used inside private networks.
They are not globally routed across the public Internet.
But our laptop needs to communicate with Google.
So how can:
192.168.1.20communicate with the public Internet?
This introduces:
NATWhat Is NAT?
NAT stands for:
Network Address TranslationA simplified home network might look like:
Laptop
192.168.1.20
|
↓
Home Router
|
↓
Public IP
|
↓
InternetThe router translates traffic between private addressing and its Internet-facing addressing.
Conceptually, the original connection might look like:
Source:
192.168.1.20:53000
Destination:
Google:443The router can translate the source into something based on its public address.
Private side
192.168.1.20:53000
|
↓
NAT
|
↓
Public side
Public-IP:62000The router maintains translation state so returning traffic can be mapped back to the correct internal connection.
Why Ports Matter for NAT
Suppose several devices use the same Internet connection.
Laptop
192.168.1.20
Phone
192.168.1.30
TV
192.168.1.40They may all share one public IPv4 address.
Conceptually:
192.168.1.20:53000 ──┐
|
192.168.1.30:54000 ──┼── NAT ── Public IP
|
192.168.1.40:55000 ──┘Port translations can help the NAT device distinguish these connections.
This commonly involves Port Address Translation, sometimes described as NAT overload.
NAT in AWS
Now AWS NAT Gateway becomes easier to understand.
Imagine an EC2 instance in a private subnet:
EC2
10.0.2.15It needs to download a package from the Internet.
But you do not want the instance to accept direct unsolicited Internet connections.
A common architecture is:
Private EC2
10.0.2.15
|
↓
Private Route Table
|
| 0.0.0.0/0
↓
NAT Gateway
|
↓
Internet Gateway
|
↓
InternetThe private subnet route table might contain:
Destination Target
10.0.0.0/16 local
0.0.0.0/0 NAT GatewayThe NAT Gateway itself is placed in a public subnet with the required Internet path.
Conceptually:
Private Subnet
|
↓
NAT Gateway
|
↓
Public Subnet
|
↓
Internet Gateway
|
↓
InternetAgain, AWS is applying the same networking principle.
Home Networking AWS
Home NAT Router → NAT Gateway
Private device → Private EC2 instance
Public Internet → InternetInternet Gateway and NAT Gateway Are Different
This distinction confuses many developers.
An Internet Gateway and NAT Gateway solve different problems.
Very roughly:
Internet Gateway
VPC
|
↓
Internetwhile:
NAT Gateway
Private resources
|
↓
Address translation
|
↓
Internet pathA typical architecture can use both:
Private EC2
|
↓
NAT Gateway
|
↓
Internet Gateway
|
↓
InternetDo not think:
NAT Gateway = Internet GatewayThey have different responsibilities.
Step 6: The Packet Enters the Internet
After leaving our home network, the packet reaches our ISP.
Now the journey might conceptually look like:
Laptop
|
↓
Home Router
|
↓
ISP Router
|
↓
Another Router
|
↓
Another Network
|
↓
Google NetworkThe Internet is not one giant router.
It is a network of networks.
Routers forward packets toward their destinations.
What Is a Hop?
Each router a packet passes through can be thought of as a hop.
Conceptually:
Laptop
|
↓
Router 1
|
↓
Router 2
|
↓
Router 3
|
↓
DestinationTools such as:
traceroute google.comor on some systems:
tracert google.comcan help reveal parts of the path packets take.
The exact output and visibility depend on network behavior and filtering.
What Is TTL?
IP packets contain a TTL field.
TTL stands for:
Time To LiveDespite the name, in IP forwarding it effectively limits the number of routing hops a packet can survive.
Each router forwarding the packet decreases the TTL.
Conceptually:
TTL 64
|
Router
↓
TTL 63
|
Router
↓
TTL 62If the value reaches zero, the packet is discarded.
Why?
Imagine a routing mistake creates a loop:
Router A
|
↓
Router B
|
↓
Router C
|
└────────→ Router AWithout a limit, packets could circulate indefinitely.
TTL prevents that.
How Does the Internet Know Google's Network Exists?
At the global Internet level, routing becomes more complicated.
The Internet consists of many independently operated networks.
These networks exchange information about which IP prefixes they can reach.
One important protocol used for this is:
BGPBGP stands for:
Border Gateway ProtocolYou do not need to master BGP to understand normal AWS application networking.
The important idea is:
Networks advertise reachability
Routers learn paths
Packets are forwarded between networksSo eventually, Internet routing brings our packet toward Google's network.
AWS and External Network Connectivity
AWS gives you several ways to connect networks.
Depending on the architecture, you may encounter:
Internet Gateway
Site-to-Site VPN
Direct Connect
VPC Peering
Transit GatewayThey solve different connectivity problems.
For example:
Office Network
|
↓
Site-to-Site VPN
|
↓
AWS VPCor:
VPC A
|
↓
Transit Gateway
|
↓
VPC BThe products are AWS-specific.
The underlying problem is not:
How can one network reach another network?That is a fundamental networking problem.
Step 7: Why Does the Browser Connect to Port 443?
Our packet finally reaches infrastructure serving Google.
But one server can run many network services.
For example, a machine could theoretically have services listening on different ports.
Server
|
├── Port 22
|
├── Port 80
|
├── Port 443
|
└── Port 5432How does the operating system know which application should receive incoming traffic?
This is one reason transport-layer ports exist.
What Is a Port?
A port is a transport-layer identifier used by protocols such as TCP and UDP to distinguish endpoints for applications.
Common examples include:
22 SSH
53 DNS
80 HTTP
443 HTTPS
5432 PostgreSQL
6379 RedisThese are conventions and registered/default ports, not laws preventing applications from using other ports.
Our browser is using:
https://google.comHTTPS normally uses:
TCP port 443So conceptually the destination becomes:
Google IP
+
TCP
+
Port 443IP Address vs Port
A useful mental model is:
IP address
|
└── Which host/interface?
Port
|
└── Which transport endpoint/application service?For example:
10.0.1.25:443means:
IP
10.0.1.25
Port
443What Is a Socket?
At a practical level, applications use sockets as operating-system abstractions for network communication.
A TCP connection can be identified using values such as:
Source IP
Source Port
Destination IP
Destination Port
ProtocolFor example:
192.168.1.20:53000
|
| TCP
↓
142.x.x.x:443The client's source port is typically an ephemeral port selected for that connection.
The server listens on:
443Ports in AWS
Now several AWS configurations become easier to understand.
For example, a Security Group rule might allow:
Protocol: TCP
Port: 443
Source: ...An Application Load Balancer might have:
Listener
HTTPS : 443and forward requests toward:
Target Group
Application : 8080Conceptually:
Internet
|
| TCP :443
↓
ALB
|
| TCP :8080
↓
ApplicationThe AWS console is exposing ordinary networking concepts:
Protocols
Ports
Addresses
ConnectionsStep 8: TCP Establishes a Connection
For HTTPS over traditional TCP-based HTTP versions, the client first establishes a TCP connection.
TCP stands for:
Transmission Control ProtocolTCP provides a reliable byte stream between endpoints.
Before application data is exchanged, TCP establishes the connection.
This begins with the famous:
Three-way handshakeTCP Three-Way Handshake
Conceptually:
Client Server
| |
| ----------- SYN ------------> |
| |
| <-------- SYN-ACK ----------- |
| |
| ----------- ACK ------------> |
| |
Connection establishedThe exact packet fields contain more detail, but the mental model is:
Client:
I want to establish a connection.
Server:
I received your request and I am ready.
Client:
Confirmed.Now the TCP connection can carry data.
Why Do We Need TCP?
Networks are not perfect.
Packets can:
Arrive late
Arrive out of order
Be duplicated
Be lostTCP provides mechanisms for reliable ordered delivery.
Important concepts include:
Sequence numbers
Acknowledgements
Retransmission
Flow control
Congestion controlSuppose data is conceptually divided into:
1
2
3
4
5If some data is lost in transit, TCP has mechanisms that allow missing data to be retransmitted.
The application does not normally need to manually reconstruct reliable delivery from raw IP packets.
TCP vs UDP
Another major transport protocol is UDP.
A simplified comparison is:
TCP
Connection-oriented
Reliable ordered byte stream
Retransmission mechanisms
More connection state
UDP
Connectionless datagrams
No built-in reliable ordered delivery
Lower protocol overhead
Applications can implement their own reliability if neededNeither is universally better.
They solve different problems.
Modern protocols can also build sophisticated transport behavior over UDP. For example, HTTP/3 uses QUIC, which runs over UDP.
TCP in AWS
TCP appears everywhere in AWS networking.
For example:
Client
|
| TCP :443
↓
Application Load Balancer
|
↓
Applicationor:
Application
|
| TCP :5432
↓
PostgreSQLor:
Application
|
| TCP :6379
↓
RedisWhen you configure:
Security Groups
NACLs
Load Balancer listeners
Target Groups
Health Checksyou are frequently configuring behavior involving transport protocols and ports.
Step 9: HTTPS Requires Encryption
We typed:
https://google.comnot:
http://google.comThe s represents secure HTTP communication using TLS.
Before normal HTTP application data is exchanged over a new HTTPS connection, the client and server establish cryptographic parameters through TLS.
What Is TLS?
TLS stands for:
Transport Layer SecurityTLS provides properties including:
Encryption
Integrity
AuthenticationWithout encryption, network traffic could potentially be readable by systems capable of observing the traffic path.
With TLS, application data is encrypted between the TLS endpoints.
The TLS Handshake
A simplified TLS flow looks like:
Client
|
| Hello / supported parameters
↓
Server
|
| Certificate + handshake data
↓
Client
|
| Verify / establish keys
↓
Server
|
↓
Encrypted communicationModern TLS handshakes are more sophisticated than this diagram.
The important idea is:
Establish trust
+
Agree on cryptographic parameters
+
Derive session keys
↓
Encrypted communicationWhat Is a TLS Certificate?
When you visit:
https://google.comyour browser needs confidence that it is communicating with a server authorized for that hostname.
The server presents a certificate.
The browser verifies properties such as:
Is the certificate valid for this hostname?
Is it within its validity period?
Does it chain to a trusted certificate authority?
Is the certificate chain valid?If verification succeeds and the handshake completes, encrypted communication can begin.
TLS in AWS
AWS Certificate Manager, commonly called ACM, can manage certificates used by supported AWS services.
A common architecture is:
Browser
|
| HTTPS :443
↓
Application Load Balancer
|
| TLS certificate from ACM
↓
ApplicationThe load balancer can terminate TLS.
Conceptually:
Encrypted Internet Traffic
|
↓
ALB
|
TLS termination
|
↓
ApplicationDepending on your security requirements, traffic from the load balancer to targets can also use encryption.
Now services such as ACM make more sense.
AWS did not invent TLS.
ACM helps you manage certificates used with the TLS infrastructure around your AWS applications.
Step 10: Finally, HTTP
We have already gone through:
DNS
|
↓
IP addressing
|
↓
Subnet decision
|
↓
Local delivery
|
↓
Routing
|
↓
NAT
|
↓
Internet routing
|
↓
TCP
|
↓
TLSOnly now are we ready for the application protocol:
HTTPThe browser can send an HTTP request through the established secure connection.
Conceptually:
GET / HTTP/1.1
Host: google.comThe real request may contain many additional headers and modern browsers may negotiate newer HTTP versions.
But the basic model remains:
Client
|
| HTTP Request
↓
Server
|
| HTTP Response
↓
ClientHTTP Is an Application-Layer Protocol
This distinction is important.
HTTP does not replace TCP, IP, or DNS.
They solve different problems.
Conceptually:
HTTP
Application communication
↓
TLS
Encryption/security
↓
TCP
Reliable transport
↓
IP
Addressing and routing
↓
Ethernet / Wi-Fi
Local network deliveryThis is why debugging web applications often requires understanding multiple networking layers.
Your HTTP code might be perfectly correct while the actual problem is:
DNS failure
Routing failure
Firewall rule
TCP connection failure
TLS certificate problemThe Request Reaches Google's Infrastructure
Large websites generally do not consist of one server sitting on the Internet.
There may be:
Global traffic systems
Load balancers
Reverse proxies
Application servers
Caches
Databases
Internal servicesA simplified model could be:
Internet
|
↓
Load Balancer
|
├─────────────┐
↓ ↓
Server A Server B
|
↓
Backend systemsThis introduces another important networking concept:
Load balancingWhat Is Load Balancing?
Imagine one server can handle:
10,000 requestsbut your application receives:
100,000 requestsYou may need multiple servers.
Server 1
Server 2
Server 3
Server 4But clients need a way to reach the service without manually choosing a server.
A load balancer can sit in front.
Load Balancer
/ | \
/ | \
↓ ↓ ↓
Server A Server B Server CThe load balancer distributes traffic according to its configuration and the health of available targets.
Load Balancing in AWS
AWS provides multiple load balancer types.
Two common ones are:
Application Load Balancer
Network Load BalancerAt a high level:
Application Load Balancer
|
↓
HTTP/HTTPS-aware routing
Network Load Balancer
|
↓
Layer 4-oriented TCP/UDP/TLS networkingA common web architecture is:
Internet
|
↓
ALB
|
├──────────────┐
↓ ↓
EC2 A EC2 BThe load balancer can perform health checks.
If:
EC2 A = healthy
EC2 B = unhealthytraffic can be directed toward healthy targets according to the service's behavior and configuration.
Step 11: What About Firewalls?
We have talked about routing.
But:
A route existsdoes not automatically mean:
Traffic is allowed.These are different questions.
Routing asks:
Where should the packet go?A firewall/security policy asks:
Should this traffic be allowed?Basic Firewall Idea
Imagine a server running:
SSH → TCP 22
HTTPS → TCP 443You might want:
443
Allowed from clients
22
Restricted to administratorsA firewall can inspect properties such as:
Source
Destination
Protocol
Portand decide whether traffic should be allowed.
Security Groups in AWS
AWS Security Groups act as stateful virtual firewalls associated with supported resources/network interfaces.
For a web server, you might allow:
Inbound
TCP :443
from expected clientsFor an application behind a load balancer, you can design the rules so the application receives traffic from the load balancer rather than being broadly reachable.
Conceptually:
Internet
|
| :443
↓
ALB Security Group
|
↓
ALB
|
| Application port
↓
App Security Group
|
↓
EC2This allows you to model:
Who can talk to whom?rather than simply opening everything.
Security Groups Are Stateful
Security Groups are stateful.
Conceptually, if allowed traffic establishes a connection:
Client
|
| Allowed request
↓
EC2
|
| Return traffic
↓
Clientthe return traffic is recognized as part of the connection flow.
You do not model Security Groups like a purely stateless packet filter.
What Are Network ACLs?
AWS also provides Network ACLs, commonly called NACLs.
They operate at the subnet level.
Conceptually:
VPC
|
↓
Subnet
|
├── Network ACL
|
↓
ResourcesAn important distinction is:
Security Groups
Stateful
Network ACLs
StatelessBecause NACLs are stateless, inbound and outbound rules need to account for traffic in both directions.
Routing and Security Are Separate
This is worth repeating because it causes many AWS networking problems.
Suppose:
Route Table
0.0.0.0/0 → Internet Gatewayexists.
That tells AWS where Internet-bound traffic should be routed.
But connectivity can still fail because of:
Security Groups
Network ACLs
Resource addressing
Application not listening
Operating system firewall
DNS
Other configurationThink about networking as multiple gates.
Can DNS resolve?
|
↓
Is there a route?
|
↓
Is traffic allowed?
|
↓
Is the service listening?
|
↓
Can TCP connect?
|
↓
Can TLS succeed?
|
↓
Can HTTP succeed?The Response Comes Back
Eventually, the remote service generates a response.
Now the journey happens in the other direction.
Conceptually:
Google
|
↓
Internet
|
↓
Your Public IP
|
↓
NAT
|
↓
192.168.1.20
|
↓
BrowserThe NAT device uses its connection/translation state to determine which private device should receive the returning traffic.
TCP ensures the byte stream is reliably delivered.
TLS decrypts the protected application data at the client endpoint.
HTTP gives the browser the application response.
Then the browser processes the returned HTML and other resources.
Those resources can trigger many additional requests.
For example:
HTML
|
├── CSS
|
├── JavaScript
|
├── Images
|
└── APIsEach resource may involve additional network activity.
The Complete google.com Journey
We can now see the full mental model.
You type:
https://google.com
|
↓
Browser parses URL
|
↓
DNS
google.com
→ IP address
|
↓
Subnet check
Is destination local?
|
↓
No
|
↓
Default Gateway
|
↓
ARP / local delivery
Find next-hop link-layer address
|
↓
Home Router
|
↓
NAT
Private IP
→ Public Internet identity
|
↓
ISP
|
↓
Internet Routing
Router
→ Router
→ Router
|
↓
Destination Network
|
↓
TCP :443
Three-way handshake
|
↓
TLS
Certificate
Encryption
|
↓
HTTP
GET /
|
↓
Load Balancing / Server Infrastructure
|
↓
HTTP Response
|
↓
TLS
|
↓
TCP
|
↓
Internet
|
↓
NAT
|
↓
Laptop
|
↓
Browser renders pageThat one request introduced a large portion of practical networking.
Now Let's Build the Same Mental Model in AWS
Suppose we are building:
api.example.comOur application runs on EC2 instances inside an AWS VPC.
A simplified architecture might look like:
Internet
|
↓
Route 53
|
↓
Application Load
Balancer
|
┌─────────┴─────────┐
↓ ↓
Availability Availability
Zone A Zone B
| |
↓ ↓
App Instance App Instance
| |
└─────────┬─────────┘
|
↓
Private ServicesNow let's map every networking concept we learned.
DNS Becomes Route 53
The user requests:
api.example.comDNS resolves that hostname toward the appropriate AWS endpoint, such as an Application Load Balancer.
Conceptually:
api.example.com
|
↓
Route 53
|
↓
ALBNetworking fundamental:
DNSAWS implementation:
Route 53Our Network Becomes a VPC
Suppose the application network is:
10.0.0.0/16We create:
VPC
10.0.0.0/16This is our private IP network inside AWS.
Conceptually:
AWS Account
VPC
10.0.0.0/16Networking fundamental:
IP network + CIDRAWS implementation:
VPC CIDRWe Divide the VPC Into Subnets
We could design:
VPC
10.0.0.0/16
├── Public Subnet A
│ 10.0.1.0/24
│
├── Public Subnet B
│ 10.0.2.0/24
│
├── Private Subnet A
│ 10.0.11.0/24
│
└── Private Subnet B
10.0.12.0/24These subnets can be placed across Availability Zones according to the architecture.
Networking fundamental:
SubnettingAWS implementation:
VPC SubnetsRoute Tables Decide Where Traffic Goes
A public subnet could use a route such as:
Destination Target
10.0.0.0/16 local
0.0.0.0/0 Internet GatewayA private application subnet that requires IPv4 Internet egress through NAT might use:
Destination Target
10.0.0.0/16 local
0.0.0.0/0 NAT GatewayNetworking fundamental:
RoutingAWS implementation:
VPC Route TablesInternet Gateway Connects the VPC to the Internet
For Internet-connected IPv4 resources, an Internet Gateway can provide the VPC-side Internet connectivity component.
Conceptually:
VPC
|
↓
Internet Gateway
|
↓
InternetNetworking fundamental:
Routing between networksAWS implementation:
Internet GatewayPrivate Instances Use NAT for Internet Egress
Suppose our application server needs to download:
Operating system updates
Packages
Container images
External API responsesbut should not accept direct unsolicited Internet connections.
We can use:
Private EC2
|
↓
Private Route Table
|
↓
NAT Gateway
|
↓
Internet Gateway
|
↓
InternetNetworking fundamental:
NATAWS implementation:
NAT GatewaySecurity Groups Control Allowed Traffic
Suppose:
Internet
|
↓
ALB
|
↓
EC2We might design:
ALB Security Group
Allow:
TCP 443
from expected Internet clientsThen:
Application Security Group
Allow:
Application port
from ALB Security GroupConceptually:
Internet
|
| 443
↓
[ ALB SG ]
|
↓
ALB
|
| 8080
↓
[ APP SG ]
|
↓
EC2Networking fundamental:
Firewall rulesAWS implementation:
Security GroupsTLS Can Terminate at the Load Balancer
Our client connects to:
https://api.example.comThe flow might be:
Client
|
| HTTPS :443
↓
ALB
|
| ACM Certificate
|
| TLS termination
↓
ApplicationOr the target connection can also use HTTPS depending on the architecture.
Networking fundamental:
TLS
Certificates
Encrypted communicationAWS implementation:
ACM
+
ALB HTTPS ListenerLoad Balancing Distributes Requests
Instead of:
User
|
↓
One EC2 instancewe can have:
ALB
/ \
/ \
↓ ↓
EC2 A EC2 Band scale further:
ALB
/ | \
↓ ↓ ↓
EC2 A EC2 B EC2 CNetworking fundamental:
Load balancingAWS implementation:
Application Load Balancer
or
Network Load BalancerThe Complete AWS Request Journey
Now suppose the user requests:
https://api.example.com/ordersThe request can conceptually travel like this:
Browser
|
↓
DNS
|
↓
Route 53
|
↓
ALB Address
|
↓
Internet
|
↓
AWS Edge / Network
|
↓
Internet-facing ALB
|
| Security Group
|
| TCP :443
|
| TLS
↓
ALB Listener
|
↓
Target Group
|
↓
Private EC2
|
↓
ApplicationThe response then travels back through the established path.
The Networking Fundamentals Behind AWS
Now the AWS services should look much less mysterious.
| Networking Fundamental | AWS Concept |
|---|---|
| IP Network | VPC |
| CIDR | VPC CIDR |
| Subnet | VPC Subnet |
| IP Address | Private/Public IP |
| Network Interface | Elastic Network Interface |
| Routing Table | VPC Route Table |
| Default Route | 0.0.0.0/0 |
| Internet Connectivity | Internet Gateway |
| NAT | NAT Gateway |
| DNS | Route 53 |
| DNS Resolver | Route 53 Resolver |
| Firewall | Security Group |
| Subnet Packet Filtering | Network ACL |
| TCP/UDP Ports | Security Group rules / listeners |
| TLS Certificate | ACM |
| Load Balancing | ALB / NLB |
| Network-to-Network Connectivity | VPC Peering / Transit Gateway / VPN |
| Dedicated Private Connectivity | Direct Connect |
AWS networking becomes much easier when you stop memorizing products independently.
Instead, ask:
What networking problem is this AWS service solving?A Practical AWS Architecture
Consider this architecture:
Internet
|
↓
Route 53
|
↓
Internet-facing
ALB
|
┌─────────┴─────────┐
| |
↓ ↓
Public Subnet Public Subnet
AZ-A AZ-B
────────────────────────────────────────────────
| |
↓ ↓
Private Subnet Private Subnet
AZ-A AZ-B
| |
↓ ↓
EC2 A EC2 B
\ /
\ /
└───────┬───────┘
|
↓
DatabaseNow add outbound Internet access:
Private EC2
|
↓
Private Route Table
|
↓
NAT Gateway
|
↓
Internet Gateway
|
↓
InternetUnderneath this architecture are concepts we already understand:
DNS
IP addresses
CIDR
Subnets
Routing
NAT
TCP
Ports
TLS
Firewalls
Load balancingThe cloud architecture is built on networking fundamentals.
How to Debug AWS Networking
Understanding the request path gives you a much better debugging strategy.
Suppose:
https://api.example.comdoes not work.
Do not randomly change Security Groups.
Follow the request.
Step 1: Does DNS Work?
Check:
api.example.com
|
↓
Expected DNS answer?Tools such as:
dig api.example.comor:
nslookup api.example.comcan help inspect DNS resolution.
Step 2: Is There a Network Path?
Ask:
Which subnet is the resource in?
Which route table is associated with it?
Where does 0.0.0.0/0 point?
Is the required gateway/path present?Remember:
Routing answers:
Where should this packet go?Step 3: Is Traffic Allowed?
Check:
Security Groups
Network ACLs
Host firewallAsk:
Is the protocol allowed?
Is the port allowed?
Is the expected source allowed?
Can return traffic work?Step 4: Is the Application Listening?
A perfect network cannot help if your application is not listening.
Suppose the ALB forwards to:
TCP :8080but your application listens on:
TCP :3000Then:
Network path = correct
Security rules = correct
Application port = wrongThe request still fails.
Step 5: Is the Target Healthy?
For an ALB, inspect target health.
Conceptually:
ALB
|
↓
Health Check
|
↓
EC2:8080/healthIf the health check fails, investigate:
Port
Path
Protocol
Security Group
Application response
Application startupStep 6: Does TLS Work?
If HTTP works but HTTPS does not, inspect:
Certificate
Hostname
TLS listener
Certificate association
Certificate validityAgain, follow the layer where the failure occurs.
Do Not Debug Networking Randomly
A common debugging strategy looks like:
Request failed
|
↓
Change Security Group
|
↓
Still broken
|
↓
Change NACL
|
↓
Still broken
|
↓
Change route table
|
↓
Still brokenThat can create new problems.
Instead:
Request
|
↓
DNS
|
↓
Addressing
|
↓
Routing
|
↓
Security
|
↓
TCP
|
↓
TLS
|
↓
ApplicationFind the layer where communication stops.
That is much more effective.
Common Networking Mistakes in AWS
Thinking a Public Subnet Is Public Because of Its Name
This:
Name = public-subnetdoes not create Internet connectivity.
Check the actual routing and resource configuration.
Confusing Security Groups With Route Tables
A Security Group does not tell packets where to go.
A route table does not decide application-level authorization.
Think:
Route Table
Where?
Security Group
Allowed?Confusing NAT Gateway With Internet Gateway
They are not interchangeable.
Think:
Internet Gateway
VPC Internet connectivityversus:
NAT Gateway
Address translation for suitable outbound flowsOpening Ports Without Understanding Them
Do not see:
Port 443as simply an AWS number.
Understand:
TCP
|
↓
Port
|
↓
Listening serviceThen Security Group rules become much easier to reason about.
Ignoring Return Traffic
Communication is not:
Client
|
↓
ServerIt is:
Client
|
↓
Server
|
↓
ClientStateful and stateless network controls handle this differently.
That matters especially when working with Network ACLs.
A Better Way to Learn AWS Networking
Do not start by memorizing:
VPC
Subnet
Route Table
Internet Gateway
NAT Gateway
Security Group
NACL
Route 53
ALB
Transit GatewayStart with:
How does one machine communicate with another?Then learn:
IP addressing
↓
CIDR
↓
Subnetting
↓
Local delivery
↓
Routing
↓
NAT
↓
DNS
↓
TCP / UDP
↓
Ports
↓
TLS
↓
HTTP
↓
Firewalls
↓
Load balancingThen AWS becomes:
Networking Fundamentals
|
↓
Cloud Networking Abstractions
|
↓
AWS ServicesYou are no longer memorizing random AWS products.
You understand why they exist.
Final Mental Model
When you type:
https://google.comdo not think:
Browser
|
↓
GoogleThink:
Browser
|
↓
URL
|
↓
DNS
|
↓
Destination IP
|
↓
Subnet decision
|
↓
Default Gateway
|
↓
Local Layer-2 Delivery
|
↓
Router
|
↓
NAT
|
↓
ISP
|
↓
Internet Routing
|
↓
Destination Network
|
↓
TCP :443
|
↓
TLS
|
↓
HTTP
|
↓
Load Balancer
|
↓
Server
|
↓
ResponseAnd when you see AWS:
Route 53
|
↓
VPC
|
↓
Subnet
|
↓
Route Table
|
↓
Internet Gateway / NAT Gateway
|
↓
Security Group
|
↓
ALB
|
↓
EC2remember that these are not isolated cloud concepts.
Underneath them are the same networking fundamentals:
DNS
IP addresses
CIDR
Subnets
Routing
NAT
TCP
UDP
Ports
TLS
Firewalls
Load balancingConclusion
A request to:
https://google.comlooks simple.
But underneath that request is an entire networking stack.
Your computer needs to:
Resolve the domain
↓
Find the destination IP
↓
Determine whether the destination is local
↓
Find the next hop
↓
Send traffic through the gateway
↓
Translate private addressing when necessary
↓
Travel through routed networks
↓
Establish transport communication
↓
Negotiate encryption
↓
Send the HTTP request
↓
Receive the responseAWS does not replace these fundamentals.
It builds abstractions and managed services around them.
A:
VPCis easier to understand when you understand IP networks.
A:
Subnetis easier to understand when you understand CIDR.
A:
Route Tableis easier to understand when you understand routing.
A:
NAT Gatewayis easier to understand when you understand NAT.
A:
Security Groupis easier to understand when you understand protocols, ports, and stateful filtering.
And:
Route 53is easier to understand when you understand DNS.
The goal is not:
Memorize AWS networking servicesThe goal is:
Understand how packets move
↓
Understand the networking problem
↓
Understand which AWS service solves itRemember:
AWS networking becomes much easier when you stop treating VPCs, subnets, route tables, NAT Gateways, Security Groups, and load balancers as isolated AWS features and start seeing them as implementations of networking fundamentals you already understand.
At the application boundary, these network layers lead into the concerns covered by the production-ready REST API guide. When load increases, the API scaling guide shows how the load balancer, application instances, pools, cache, and database behave as one capacity chain.
References
Related
Written by
Faisal
Software engineer writing about backend systems, Node.js, system design, scalable applications, and modern web and mobile development.