DEV Community

Cover image for The OSI Model Explained: How Data Really Flows Through the Internet

The OSI Model Explained: How Data Really Flows Through the Internet

I am studying for my AWS certifications.

Everyone said: "Learn networking first."

So I dove into the OSI model. The concept clicked when I stopped trying to memorize layers and started understanding what problem each layer solves.

The OSI model is not something you memorize. It provides a framework for understanding how data moves from your laptop to AWS servers and back.

Here is what I wish someone told me on day one.

Why This Actually Matters for AWS

Before we dive in, let me explain why networking is not just theory.

You cannot configure AWS VPCs without understanding Layer 3 (IP addresses). You cannot write Security Group rules without understanding Layer 4 (ports). You cannot troubleshoot connectivity without understanding all 7 layers.

When you run this Python code:

import boto3

ec2 = boto3.client('ec2')
response = ec2.describe_instances()
Enter fullscreen mode Exit fullscreen mode

That simple call uses all 7 layers of the OSI model. Let me show you how.

The Problem Networking Solves

Imagine two computers in the same room. How do they share data?

Before networking:

  1. Walk to Computer A
  2. Plug in USB drive
  3. Copy files
  4. Walk to Computer B
  5. Plug in USB drive
  6. Copy files

With networking:

Computers share data automatically across the room, building, city, or world. No walking required.

But how? That is where the OSI model comes in.

The OSI Model: 7 Layers, 7 Solutions

OSI = Open Systems Interconnection

Think of it like the human body. The skeletal system handles structure. The respiratory system handles breathing. The cardiovascular system handles blood flow. Each has a specific function. All work together and the human lives.

Networking is the same. Seven layers, each with specific function. All work together and data flows across the internet.

Let me show you each layer by explaining the problem it solves.

Layer 1: Physical Layer

The Problem: How do we transport bits?

Data on computers equals 1s and 0s (bits). Something must physically transport those bits from one place to another.

The Solution: Physical medium

What operates at Layer 1:

  • Ethernet cables (copper or fiber)
  • Wi-Fi (radio waves)
  • Bluetooth
  • Repeaters (amplify signals)
  • Hubs (multi-port repeaters)

Key Concept: Do not get hung up on "physical" in the name. Layer 1 equals anything that moves bits.

Cables are physical. Wi-Fi uses radio waves. Both accomplish the same goal: Move 1s and 0s from here to there.

AWS Example:

When you use AWS DirectConnect, you establish a dedicated physical connection (Layer 1) between your data center and AWS.

Layer 2: Data Link Layer

The Problem: How do we deliver data hop-to-hop?

Layer 1 moves bits on a wire. But data often travels through multiple devices:

Your Computer → Switch → Router → Another Router → Server
Enter fullscreen mode Exit fullscreen mode

Each jump from one device to another equals one "hop."

The Solution: MAC addresses

MAC Address = 48-bit identifier

Every network card (NIC) has a unique MAC address.

Format: AA:BB:CC:DD:EE:FF

What operates at Layer 2:

  • Network Interface Cards (NICs)
  • Switches (forward data within networks)
  • Wi-Fi Access Cards

How Layer 2 Works

When your computer sends data to a router:

Layer 2 Header:
- Source MAC: AA:AA:AA:AA:AA:AA (your computer)
- Destination MAC: E5:E5:E5:E5:E5:E5 (router)
Enter fullscreen mode Exit fullscreen mode

This header gets the data from your NIC to the router's NIC (one hop).

At the router, this Layer 2 header is removed and replaced with a new one for the next hop:

Layer 2 Header (new):
- Source MAC: E5:E5:E5:E5:E5:E5 (router)  
- Destination MAC: E6:E6:E6:E6:E6:E6 (next router)
Enter fullscreen mode Exit fullscreen mode

Layer 2 changes at every hop.

AWS Example:

Your EC2 instance has an Elastic Network Interface (ENI). That is a Layer 2 network card with a MAC address.

Layer 3: Network Layer

The Problem: How do we deliver data end-to-end?

If Layer 2 handles each hop, what handles the complete journey from your laptop to a server across the internet?

The Solution: IP addresses

IP Address = 32-bit identifier (IPv4)

Format: 192.168.1.100 (4 octets, each 0-255)

What operates at Layer 3:

  • Routers (move data between networks)
  • Hosts (anything with an IP address)
  • Layer 3 switches

How Layer 3 Works

Your laptop accessing Google's server:

Your Computer: 192.168.1.100
Google Server: 8.8.8.8

Path: Your Computer → 5 routers → Google Server
Enter fullscreen mode Exit fullscreen mode

Layer 3 header stays constant throughout the entire journey:

Layer 3 Header (constant):
- Source IP: 192.168.1.100 (you)
- Destination IP: 8.8.8.8 (Google)
Enter fullscreen mode Exit fullscreen mode

This header never changes from start to finish. That is end-to-end delivery.

AWS Example:

When you create a VPC, you define Layer 3 addressing:

import boto3

ec2 = boto3.client('ec2')

vpc = ec2.create_vpc(CidrBlock='10.0.0.0/16')
print(f"VPC created with IP range: 10.0.0.0/16")
Enter fullscreen mode Exit fullscreen mode

That 10.0.0.0/16 equals Layer 3 addressing for your entire VPC.

The Critical Question: Why Both?

"If Layer 3 handles end-to-end with IP addresses, why do we need Layer 2 MAC addresses?"

This confused me for weeks. Here is the answer.

They serve different purposes:

  • Layer 3 (IP addresses): End-to-end delivery

    • Stays constant throughout journey
    • Like destination address on envelope
  • Layer 2 (MAC addresses): Hop-to-hop delivery

    • Changes at every router
    • Like the truck driver who changes at each distribution center

Example journey: Your Laptop → Web Server

Your Laptop (IP: 192.168.1.100)
  ↓
Router 1 (IP: 192.168.1.1)
  ↓  
Router 2 (IP: 10.20.30.1)
  ↓
Web Server (IP: 142.250.80.46)
Enter fullscreen mode Exit fullscreen mode

Layer 3 header (constant):

Source: 192.168.1.100
Destination: 142.250.80.46
[NEVER CHANGES]
Enter fullscreen mode Exit fullscreen mode

Layer 2 headers (change at each hop):

Hop 1: Your Laptop → Router 1

Source MAC: [Your NIC]
Dest MAC: [Router 1's NIC]
Enter fullscreen mode Exit fullscreen mode

Hop 2: Router 1 → Router 2

Source MAC: [Router 1's NIC]
Dest MAC: [Router 2's NIC]
Enter fullscreen mode Exit fullscreen mode

Hop 3: Router 2 → Web Server

Source MAC: [Router 2's NIC]  
Dest MAC: [Server's NIC]
Enter fullscreen mode Exit fullscreen mode

Both are necessary for different parts of the journey.

Layer 4: Transport Layer

The Problem: How do we distinguish different data streams?

Your computer runs multiple programs simultaneously:

Your Computer (IP: 192.168.1.100)
├── Web Browser (browsing)
├── Slack (chatting)
├── Spotify (music)
└── Email Client
Enter fullscreen mode Exit fullscreen mode

All these programs use the same network card and the same IP address. They all send and receive data.

Question: When data arrives at your computer, how does it know which program gets it?

The Solution: Port numbers

Layer 4 uses port numbers to distinguish data streams.

Port number = 16-bit number (0-65,535)

Two types:

  • TCP ports: Reliable transmission (confirms delivery)
  • UDP ports: Fast transmission (no confirmation)

How Ports Work

Well-known server ports:

HTTP (web):         TCP port 80
HTTPS (secure web): TCP port 443
SSH (remote login): TCP port 22
DNS (name lookup):  UDP port 53
Enter fullscreen mode Exit fullscreen mode

Client ports (random):

When you connect to a server:

  • Destination port = Server's well-known port
  • Source port = Random port your computer picks

Example: Browsing to aws.amazon.com

Your Computer → AWS Web Server

Source: 192.168.1.100:54321 (random port)
Destination: 142.250.80.46:443 (HTTPS)
Enter fullscreen mode Exit fullscreen mode

Server's response:

Source: 142.250.80.46:443
Destination: 192.168.1.100:54321 (same random port)
Enter fullscreen mode Exit fullscreen mode

Why random ports? This allows multiple connections to same server.

Tab 1 → aws.amazon.com (port 54321)
Tab 2 → aws.amazon.com (port 54322)
Tab 3 → aws.amazon.com (port 54323)
Enter fullscreen mode Exit fullscreen mode

Different ports keep data streams separate.

AWS Example:

Security Group rules are Layer 4 rules:

# Allow HTTPS traffic (Layer 4: TCP port 443)
security_group_rule = {
    'IpProtocol': 'tcp',
    'FromPort': 443,
    'ToPort': 443,
    'IpRanges': [{'CidrIp': '0.0.0.0/0'}]
}
Enter fullscreen mode Exit fullscreen mode

You are saying: "Allow TCP (Layer 4) on port 443 (Layer 4) from any IP (Layer 3)."

Layers 5-7: Application Layers

The Reality

The OSI model defines Layer 5 (Session Layer), Layer 6 (Presentation Layer), and Layer 7 (Application Layer).

In practice, modern networking combines these into one "Application Layer."

Why? Every application implements them differently. There is no strict separation anymore.

What You Need to Know

Layer 5: Session Management

Example: HTTP cookies that keep you logged in even when your IP changes

Layer 6: Data Formatting

Example: Encoding data as ASCII, JSON, or base64

Layer 7: Application Protocols

Example: HTTP, FTP, SMTP, DNS

AWS Example:

Application Load Balancer operates at Layer 7 (HTTP/HTTPS):

# Create Layer 7 load balancer
elb = boto3.client('elbv2')

load_balancer = elb.create_load_balancer(
    Name='my-application-lb',
    Type='application',  # Layer 7
    Scheme='internet-facing',
    IpAddressType='ipv4'
)
Enter fullscreen mode Exit fullscreen mode

It can route based on HTTP headers (Layer 7), URL paths (Layer 7), and HTTP methods (Layer 7).

Encapsulation: How Layers Stack

When your application sends data, each layer adds its header:

APPLICATION:
  [DATA]
    ↓
LAYER 4 (Transport):
  [TCP Header: Ports] + [DATA] = SEGMENT
    ↓
LAYER 3 (Network):
  [IP Header: IPs] + [SEGMENT] = PACKET
    ↓  
LAYER 2 (Data Link):
  [Ethernet Header: MACs] + [PACKET] = FRAME
    ↓
LAYER 1 (Physical):
  FRAME → 1010101010... (bits on wire)
Enter fullscreen mode Exit fullscreen mode

When data arrives, the process reverses (de-encapsulation):

LAYER 1: Bits received
    ↓
LAYER 2: Check MAC address (is this for me?)
         Remove Ethernet header
    ↓
LAYER 3: Check IP address (is this for me?)
         Remove IP header
    ↓
LAYER 4: Check port number (which program?)
         Remove TCP header
    ↓
APPLICATION: Process [DATA]
Enter fullscreen mode Exit fullscreen mode

Real Example: Your boto3 Call Through All 7 Layers

Remember this from the beginning?

import boto3

ec2 = boto3.client('ec2')
response = ec2.describe_instances()
Enter fullscreen mode Exit fullscreen mode

Here is what actually happens:

Layer 7 (Application):

boto3 constructs HTTPS API request and formats JSON data

Layer 6 (Presentation):

Encodes data as UTF-8 and prepares for encryption

Layer 5 (Session):

Manages TLS session with AWS and handles authentication tokens

Layer 4 (Transport):

Uses TCP for reliable delivery. Destination port: 443 (HTTPS). Source port: Random (e.g., 54321)

Layer 3 (Network):

Destination IP: AWS API endpoint (e.g., 52.94.133.131). Source IP: Your computer's public IP. Routed through internet

Layer 2 (Data Link):

Source MAC: Your computer's NIC. Dest MAC: Your router's NIC (first hop). Changes at each hop through internet

Layer 1 (Physical):

Bits transmitted over Wi-Fi or Ethernet. Travels through cables and radio waves

The response comes back through all 7 layers in reverse.

AWS VPC Through the OSI Lens

Let me map AWS networking services to OSI layers:

Layer 1 (Physical):

  • AWS DirectConnect (dedicated fiber connection)
  • Physical infrastructure (AWS manages)

Layer 2 (Data Link):

  • ENI (Elastic Network Interface)
  • MAC addresses on EC2 instances

Layer 3 (Network):

  • VPC CIDR blocks (10.0.0.0/16)
  • Subnets (10.0.1.0/24, 10.0.2.0/24)
  • Route Tables
  • Internet Gateway
  • NAT Gateway
  • VPC Peering

Layer 4 (Transport):

  • Security Groups (port rules)
  • NACLs (port-based filtering)

Layer 7 (Application):

  • Application Load Balancer
  • API Gateway
  • CloudFront (CDN)

Example VPC configuration:

import boto3

ec2 = boto3.client('ec2')

# Layer 3: Create VPC with IP range
vpc = ec2.create_vpc(CidrBlock='10.0.0.0/16')
vpc_id = vpc['Vpc']['VpcId']

# Layer 3: Create subnet  
subnet = ec2.create_subnet(
    VpcId=vpc_id,
    CidrBlock='10.0.1.0/24'
)
subnet_id = subnet['Subnet']['SubnetId']

# Layer 2: Create network interface (ENI)
eni = ec2.create_network_interface(
    SubnetId=subnet_id,
    Description='My application ENI'
)

# Layer 4: Create security group with port rules
sg = ec2.create_security_group(
    GroupName='web-server-sg',
    Description='Allow HTTPS',
    VpcId=vpc_id
)

# Allow Layer 4 (TCP port 443)
ec2.authorize_security_group_ingress(
    GroupId=sg['GroupId'],
    IpPermissions=[{
        'IpProtocol': 'tcp',
        'FromPort': 443,
        'ToPort': 443,
        'IpRanges': [{'CidrIp': '0.0.0.0/0'}]
    }]
)
Enter fullscreen mode Exit fullscreen mode

Every AWS networking service maps to OSI layers.

Troubleshooting with OSI Layers

The OSI model provides your debugging framework. When something breaks, check layer by layer.

Problem: "I cannot reach my EC2 instance"

Layer 1: Is there network connectivity?

$ ip link show
Enter fullscreen mode Exit fullscreen mode

Layer 2: Can you reach your default gateway?

$ arp -a
Enter fullscreen mode Exit fullscreen mode

Layer 3: Can you route to the destination IP?

$ ping 10.0.1.50
$ traceroute 10.0.1.50
Enter fullscreen mode Exit fullscreen mode

Layer 4: Is the port open?

$ telnet 10.0.1.50 443
$ nc -zv 10.0.1.50 443
Enter fullscreen mode Exit fullscreen mode

Layer 7: Is the application responding?

$ curl -v https://your-instance.com
Enter fullscreen mode Exit fullscreen mode

Most common AWS issues and their layers:

  • Cannot SSH to EC2: Layer 4 (Security Group blocking port 22)
  • VPC peering not working: Layer 3 (Route Table missing routes)
  • Load balancer failing: Layer 7 (Health check configuration)
  • Slow API responses: Layer 4 and 7 (Connection limits, timeouts)

Key Takeaways

Layer 1 (Physical): Transports bits (cables, Wi-Fi, DirectConnect)

Layer 2 (Data Link): Hop-to-hop delivery (MAC addresses, switches, ENIs)

Layer 3 (Network): End-to-end delivery (IP addresses, routers, VPCs)

Layer 4 (Transport): Service-to-service (ports, TCP and UDP, Security Groups)

Layers 5-7 (Application): Application protocols (HTTP, DNS, Load Balancers)

Layer 2 changes every hop. Layer 3 stays constant.

Both MAC and IP addresses are necessary for different parts of the journey.

Every AWS service maps to these fundamental networking concepts.

What Comes Next: Part 2

Now you understand the OSI model conceptually. But how do switches and routers actually work?

In Part 2, I will show you:

  • How switches learn MAC addresses and forward frames
  • How routers use routing tables to forward packets
  • The three critical tables that make networking work
  • Real examples with AWS VPC Route Tables

Your Turn

Learning networking for AWS? What confuses you most?

Drop a comment below. I am documenting my entire journey to AWS certifications, and I want to help you with concepts that are not clicking.

Found this helpful? Follow me for:

  • Part 2: Switches and Routers
  • Part 3: IP Addresses and Protocols
  • Part 4: Complete data flow from browser to AWS

I am also sharing daily AWS learning on Twitter/X, code examples on GitHub, and weekly deep dives on Substack.

Let me learn AWS networking with you.

Resources

Official Specs:

My Learning Resources:

Stella Achar Oiro is a software developer with clinical healthcare experience, currently studying for AWS certifications while building HIPAA-compliant cloud infrastructure. She shares her learning journey to help other developers transition to cloud engineering.

This is Part 1 of a 4-part series on Networking Fundamentals for Cloud Engineers.

Top comments (0)