The Open Systems Interconnection (OSI) model is a foundational concept in networking, providing a standardized framework for how network devices communicate. It divides the complex process of data transmission into seven distinct layers, each with specific functions. While traditionally applied to on-premises networks, understanding the OSI model is equally crucial in the evolving landscape of cloud computing.

Let’s demystify the OSI model and see how its principles translate from the physical cables of your office to the virtualized infrastructure of the cloud.

What is the OSI Model?

Imagine sending a letter. Before it reaches its destination, it goes through several stages like writing the letter, putting it in an envelope, adding the address, dropping it in a mailbox, sorting at the post office, transport, and finally, delivery. Each stage has a specific role, and if one fails, the letter might not arrive.

The OSI model works similarly for data. Each of its seven layers handles a particular aspect of communication, building upon the services of the layer below it. This modular approach helps in troubleshooting, designing, and understanding network interactions. 

OSI in Traditional Networking

In a traditional network, you can often pinpoint specific hardware and software components at each OSI layer. For instance, an Ethernet cable operates at the Physical Layer, while your web browser functions at the Application Layer. This direct mapping makes the model very tangible.

OSI in the Cloud Era

The cloud introduces a layer of abstraction. Instead of owning physical servers, you consume services. However, the underlying principles of the OSI model still apply. Cloud providers like OCI, AWS, Azure, and Google Cloud manage the lower layers of the OSI model (Physical, Data Link, Network, and often parts of the Transport Layer), providing them as a service to you. You, as the cloud consumer, typically focus on the higher layers, particularly from the Transport Layer upwards, depending on the service model (IaaS, PaaS, SaaS).

The beauty of the cloud is that it abstracts away much of the complexity of the lower layers, allowing users to focus on their applications and data. However, for network architects and engineers, understanding how the OSI model functions within a cloud environment is vital for designing secure, efficient, and resilient cloud-based solutions.

 

OSI Model Traditional vs. Cloud Examples

Here’s a table illustrating each OSI layer with example from both traditional networking and cloud environments:

OSI Model with Traditional vs Cloud Networking  
OSI Layer Layer Function Key Info Contained Traditional Networking Example
 

Cloud(OCI)

  Networking  Example

Command/Tool to Verify
7. Application Interfaces directly with user or application HTTP headers, cookies, request method Browser using HTTP to access a website VM running Apache via OCI Load Balancer Curl -l http://<LB-public-IP>
6. Presentation Data translation and encryption Encryption, compression, encoding format SSL/TLS encryption on a web server TLS via cloud LB, certificate management in key Vault/OCI Vault. Curl -l https://<LB-public-IP>
5. Session Manages communication sessions between applications Session tokens, session ID, control messages SSH session, video streaming session, SQL session Load balancer session persistence (Cookie-based) Browser DevTools> Application>Cookies
4. Transport Provides reliable data transfer between end system Source/destination ports, connection state TCP reliable, (connection-oriented), UDP (unreliable, connectionless) LB listener on port 80/443 telnet <LB-public-IP> 80
3. Network Determines the best path for data, manages logical addressing (IP addresses) Source/destination IP addresses Routers, IP addressing, BGP routing protocols OCI VCN route tables, Internet/NAT Gateways Traceroute/mtr <LB-public-IP>
2. Data Link Provides reliable data transfer across a physical link, handles MAC addressing and error detection Source/destination MAC addresses Ethernet switches, MAC address resolution, ARP Abstracted in cloud by underlying virtual switching infrastructure, managed by VNICs and virtual links Not visible directly in cloud (OCI)
1. Physical Transmission of raw bits Bits, fiber signals (In cloud we virtualized) Fiber optics, copper, cables, NICs Managed by cloud provider like OCI data centers Managed by Oracle

 

As you see, Cloud Networking is similar to Traditional Networking, it’s just virtualized, and the responsibility model falls more on the CSP (Cloud Service Provider). The core networking concepts have not changed, they’re just being abstracted in the cloud.

Here is how to think about it:

Traditional Concept Cloud (OCI) Equivalent
Physical router Virtual routing via VCN, DRG (Dynamic Routing Gateway)
Ethernet cable Virtual NIC in a subnet (VNIC), LPG (Local Peering Gateway), RPC (Remote Peering Gateway), VCN Attachments in DRG
Firewall appliance Cloud security lists or Network Security Groups (NSG) or OCI Network Firewall
Load balancer box OCI Load Balancer or OCI Network Load Balancer
DNS server OCI VCN DNS Resolver or Internet DNS resolver
Network zones Subnets
NAT device OCI NAT Gateway

 

Technically, you are still designing subnets, assigning IPs, routing traffic, and applying security policies, the same responsibilities, now managed through a UI or Terraform.

Now that we have explored the OSI model and how it maps to both traditional and cloud networking, it’s time to visualize it in action. Let’s map each OSI layer to my cloud example setup including Load Balancer and VM. You will see how simple tools like curl or traceroute interact with each layer.

Please check the screen record and table below.

LB-gif

OSI Layers with Load Balancer + VM (Simple View)

OSI Layer Name Example in my setup
7 Application Curl http://129.80.9.94 sends an HHTP request to the load balancer
6 Presentation Managed by protocol like TLS if using HTTPS (In my test, layer 6 is not utilized since the connection uses HTTP with no SSL/TLS encryption)
5 Session TCP session established between curl client and LB (LB forwarded to VM backend)
4 Transport TCP port 80 (HTTP) or 443(HTTPS), and LB forwards TCP traffic to the VM
3 Network IP routing, traceroute shows IP path from my machine to the LB
2 Data Link MAC address handling is invisible in curl/traceroute but used within the VCN
1 Physical Underlying hardware, cables, and NICs (OCI’s physical layer under the VCN)

 

Conclusion

This simple setup using a load balancer and a VM backend helped show how different OSI layers play a role in cloud networking. With tools like curl, traceroute, and telnet, we could trace the path of a request and understand how each layer contributes to the connection. Even without HTTPS or load balancer certificates, this exercise gave a clear, hands-on view of how traffic flows in a real cloud environment.

 

I hope you enjoyed it!