DEV Community: Khushi Nandwani

Seven Layers That Explain Almost Every Network Problem 🌐

Khushi Nandwani — Wed, 19 Aug 2026 11:16:33 +0000

Before the OSI Model

In the early days of computer networking, different vendors often developed their own networking technologies and protocols.
An IBM mainframe might use IBM’s networking stack, while a DEC system used DEC’s protocols and a Xerox system followed Xerox’s approach. Each system could work well on its own, but getting systems from different vendors to communicate with each other was much more difficult.
The problem was not that networking itself was impossible. The problem was that there was no common framework that clearly defined how different networking responsibilities should work together.
This created vendor dependency. If an organization invested heavily in one vendor’s networking technology, adding equipment from another vendor could require significant additional engineering to make the systems communicate.

The Problem, Simply Explained

The underlying problem was a lack of standardization.
There was no widely accepted way to separate networking responsibilities.
For example:

Who should handle physical transmission?
Who should handle addressing?
Who should decide where packets should go?
Who should handle lost or corrupted data?
How should applications communicate across the network?

Without clear boundaries, vendors could build complete networking systems in different ways, making interoperability more difficult.
What was needed was a common way to organize and describe the different responsibilities involved in network communication.

Why OSI Was Introduced

In 1984, the International Organization for Standardization (ISO) published the OSI (Open Systems Interconnection) reference model. The OSI Model was not a networking protocol, but a conceptual framework for understanding how network communication could be divided into separate responsibilities. Instead of treating networking as one large process, it divided communication into seven layers, with each layer responsible for a specific function and interacting with the layers above and below it.

This separation made networking easier to design, standardize, understand, and troubleshoot. For example, an application does not need to know whether the underlying network uses Ethernet, Wi Fi, or fiber, just as the physical network does not need to understand what application data is being transmitted. This separation of responsibilities is one of the most important ideas behind the OSI Model.

The OSI Model: Seven Layers from Sender to Receiver

The Seven Layers of the OSI Model

Physical Layer

The Physical Layer is responsible for transmitting raw bits, represented as electrical signals, light pulses, or radio signals. It deals with physical components such as cables, connectors, and wireless signals.

Data unit: Bits

Data Link Layer

The Data Link Layer handles communication between devices on the same local network. It uses MAC addresses and organizes data into frames. Technologies such as Ethernet and Wi Fi primarily operate at this layer.

Data unit: Frame

Network Layer

The Network Layer is responsible for IP addressing and routing. It determines how packets move from one network to another, often passing through multiple routers before reaching their destination.

Data unit: Packet

Transport Layer

The Transport Layer provides communication between applications running on different systems. TCP provides reliable and ordered delivery, while UDP provides a simpler connectionless communication method. Ports are also used at this layer to identify specific services or applications.

Protocols: TCP, UDP
Data unit: Segment for TCP, Datagram for UDP

Session Layer

The Session Layer manages communication sessions between applications. It is responsible for establishing, maintaining, and terminating sessions. In modern networks, these responsibilities are often handled by protocols at other layers, so this layer is not always visible as a separate component.

Presentation Layer

The Presentation Layer is concerned with how data is represented and understood by different systems. It can handle tasks such as data formatting, encryption, decryption, compression, and character encoding.

Application Layer

The Application Layer is closest to the applications that use network communication. It includes protocols such as HTTP, HTTPS, DNS, SSH, and SMTP, which allow applications to communicate over a network.
The application itself is not the OSI Application Layer. Rather, the layer represents the network protocols and services used by applications.

OSI Layers and Their Common Protocols

Layer	Name	Common Protocols / Technologies
7	Application	`HTTP`, `HTTPS`, `DNS`, `DHCP`, `FTP`, `SSH`, `SMTP`, `SNMP`
6	Presentation	`TLS/SSL`, `JPEG`, `PNG`, `JSON`, `XML`
5	Session	`RPC`, `NetBIOS`, `SMB`, `SIP`
4	Transport	`TCP`, `UDP`
3	Network	`IPv4`, `IPv6`, `ICMP`, `IPsec`, `OSPF`
2	Data Link	`Ethernet`, `Wi-Fi`, `PPP`, `HDLC`
1	Physical	`USB`, `Bluetooth`, `Fiber`

From Layers to Data Transfer

Now that we understand what each OSI layer is responsible for, the next question is: how do these layers actually work together when data is sent across a network?

When one device sends data to another, the data moves down through the layers on the sender’s side. Each layer adds the information needed for its role before passing the data to the layer below it. At the receiving end, the process happens in reverse, with each layer processing the information intended for it.

This process is known as encapsulation and decapsulation, and understanding it helps connect the individual OSI layers to what actually happens when data travels across a network.

Encapsulation and Decapsulation

When data travels from one computer to another, it changes as it moves through the OSI layers

Encapsulation happens on the sender’s side. As data moves down the layers, each relevant layer adds information required for communication. The application starts with data, the Transport Layer adds its header to create a segment, the Network Layer adds an IP header to create a packet, and the Data Link Layer adds a frame header and trailer to create a frame. Finally, the Physical Layer converts it into bits for transmission.

Data → Segment → Packet → Frame → Bits

At the receiving computer, the reverse process takes place. This is called decapsulation. Each layer processes and removes the information added by the corresponding layer until the original data reaches the application.

Bits → Frame → Packet → Segment → Data

In simple terms, encapsulation prepares and wraps the data for transmission, while decapsulation unwraps and delivers the data to the receiving application.

If modern networking doesn't actually follow seven clean layers, why am I learning this?

Modern networks do not strictly follow all seven OSI layers. The Internet primarily uses the TCP/IP model, with some OSI layers combined or handled differently in practice.

However, the OSI Model remains useful for understanding and troubleshooting networks. When something goes wrong, thinking in layers helps you identify where the problem is, whether it is related to DNS, TCP, IP, or the application itself. The real value of OSI is not memorizing the seven layers, but using them as a structured way to troubleshoot network problems.

Wrapping Up

The OSI Model gives us a structured way to understand how network communication works, from physical signals to application level protocols. More importantly, it provides a useful framework for identifying and troubleshooting network problems.

CineDB: Building a Movie Catalog with DocumentDB 📽️

Khushi Nandwani — Mon, 05 Jan 2026 10:11:13 +0000

📘 Introduction

This project demonstrates how to set up Amazon DocumentDB (with MongoDB compatibility) inside a custom Amazon VPC and securely connect to it from an EC2 instance and covers end-to-end steps starting from network creation, security configuration, cluster provisioning, client setup, and finally performing CRUD (Create, Read, Update, Delete) operations using the MongoDB shell (mongosh).

The goal is to understand how a managed NoSQL database like Amazon DocumentDB is deployed and accessed in a real-world AWS environment.

🏗️ Architecture Overview

The architecture is based on a private Amazon DocumentDB cluster deployed inside a custom VPC. An EC2 instance placed in a public subnet acts as the client machine to connect securely to the DocumentDB cluster using security groups and TLS encryption.

Key ideas:

DocumentDB runs inside private subnets
EC2 client accesses it through security group–based rules
Communication happens over port 27017 using TLSLS

🧩 Architecture Components

Amazon VPC: Custom VPC for isolation and network control
Public Subnet: Hosts the EC2 client instance
Amazon DocumentDB Cluster: MongoDB-compatible NoSQL database
Subnet Group: Defines subnets where DocumentDB can be deployed
Security Groups:
- DocumentDB cluster security group
- DocumentDB client (EC2) security group
Amazon EC2 (Amazon Linux 2): Client machine for database access
MongoDB Shell (mongosh): Used to interact with DocumentDB
TLS Certificate: Ensures encrypted communication

🎯 Why This Project?

To understand how Amazon DocumentDB works in a secure VPC setup
To learn networking and security concepts such as VPCs, subnets, and security groups
To practice MongoDB-style CRUD operations on a managed AWS service
To gain hands-on experience useful for cloud, DevOps, and database roles

✨ Key Features

Secure DocumentDB cluster deployment
Controlled access using security groups
MongoDB-compatible operations using mongosh
Full CRUD workflow on a sample movie catalog
Proper cleanup of AWS resources to avoid unnecessary costs

🛠️ Execution Workflow

I. VPC and Subnet Configuration

Open the AWS Management Console

Search for VPC and open the VPC Dashboard

Click Create VPC

Set VPC name as documentdb-demo-vpc

Keep all other settings as default

Click Create VPC

Once created, click View VPC

Go to Subnets

Select Public Subnet 1 and click edit subnet settings

Enable Auto-assign public IPv4 address

Save the subnet settings

II. DocumentDB Subnet Group Creation

Search for Amazon DocumentDB and open its dashboard

From the left menu, click Subnet groups

Click Create subnet group and enter the following details:
- Name: documentdb-subnet-group
- Description: Subnet group for DocumentDB
- VPC: Select the previously created VPC

Add all subnets associated with this VPC

Click Create subnet group

III. Security Group Configuration

A. DocumentDB Cluster Security Group

Open EC2 → Security Groups

Click Create security group, in Basic Details configure:
- Security group name: documentdb-sg
- Description: Security group for DocumentDB cluster
- VPC: documentdb-demo-vpc

Keep rest of the settings as defailt and click create security group

B. DocumentDB Client Security Group

Click Create security group again and in Basic Details configure:
- Security group name: documentdb-client-sg
- Description: Security group for DocumentDB clients
- VPC: documentdb-demo-vpc

Add an inbound rule with the following configuration:
- Type: SSH
- Port Range: 22
- Source: Anywhere-IPv4

Click Create security group

C. Inbound Rule Configuration

Open documentdb-sg and click edit inbound rules

Click Add rule and configure:
- Type: Custom TCP
- Port range: 27017
- Source: documentdb-client-sg
Save the rules

IV. Amazon DocumentDB Cluster Creation

Open Amazon DocumentDB

Click Create cluster & select instance-based cluster

In Cluster Configuration, configure:
- Cluster identifier: movie-catalog-cluster
- Engine version: 5.0

Choose DB instance class: Memory optimized

Keep cluster storage and connectivity settings as default

Under Authentication, configure:
- Username: docdbadmin
- Enable Self-managed passwords
- Enter and confirm username and password

Enable Advanced settings

Under Network settings:
- VPC: documentdb-demo-vpc
- Subnet group: documentdb-subnet-group
- Security group: documentdb-sg

Keep remaining settings as default

Disable Deletion Protection for cluster

Click Create cluster

Wait 10–15 minutes for cluster creation

V. EC2 Client Instance Setup

Open Amazon EC2 dashboard and click launch instance

Configure:
- Name: documentdb-client-ec2
- AMI: Amazon Linux 2
- Instance type: t2.micro or t3.micro

Create a Key Pair:
- Name: dynamodb-client
- Type: RSA
- Format: .pem

In Network settings:
- VPC: documentdb-demo-vpc
- Subnet: Choose a public subnet
- Security group: documentdb-client-sg

Click Launch instance

VI. Connect to EC2

Wait until instance status checks pass and click Connect

Choose EC2 Instance Connect and Click Connect

VII. MongoDB Shell Installation

Download MongoDB shell:

wget https://downloads.mongodb.com/compass/mongodb-mongosh-1.10.0.x86_64.rpm

Install mongosh:

sudo yum install -y mongodb-mongosh-1.10.0.x86_64.rpm

Verify installation:

mongosh --version

Download DocumentDB TLS certificate:

wget https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

VIII. Connect to DocumentDB

Open Amazon DocumentDB → Clusters

Go to Connectivity & Security and copy the mongosh connection string

Paste it into the EC2 terminal and enter the database password

IX. Database Operations (CRUD)

Switch database:

use movieCatalog

Create collection:

db.createCollection("movies")

Insert data:

db.movies.insertMany([ { title: "Inception", genre: "Sci-Fi", releaseYear: 2010, rating: 8.8 }, { title: "Interstellar", genre: "Sci-Fi", releaseYear: 2014, rating: 8.6 }, { title: "The Dark Knight", genre: "Action", releaseYear: 2008, rating: 9.0 }, { title: "Avengers: Endgame", genre: "Superhero", releaseYear: 2019, rating: 8.4 }, { title: "Parasite", genre: "Thriller", releaseYear: 2019, rating: 8.6 } ])

Read all movies:

db.movies.find()

Find by genre:

db.movies.find({ genre: "Sci-Fi" })

Update one movie:

db.movies.updateOne( { title: "Interstellar" }, { $set: { rating: 8.7 } } )

Update multiple movies:

db.movies.updateMany( { genre: "Sci-Fi" }, { $inc: { rating: 0.1 } } )

Delete a movie:

db.movies.deleteOne({ title: "Parasite" })

Verify deletion:

db.movies.find().pretty()

Compare the total number of documents in the collection after deletion

db.movies.countDocuments()

📂 Full Repository
All source code, configuration steps, and documentation are available here:
https://github.com/Knandwani07/aws-database-architectures/tree/main/documentdb-movie-catalog

X. Cleanup

Delete DocumentDB cluster instance and DocumentDB cluster

Delete Subnet Group

Delete EC2 instance

Delete Key Pair

Delete Security Groups

Delete VPC

✅ Conclusion

This project provides a complete, production-style walkthrough of deploying and using Amazon DocumentDB securely within AWS. It covers networking, security, database operations, and cleanup, reflecting real-world cloud practices.

🤝 Let’s Connect

For feedback, collaboration, or cloud discussions:

LinkedIn: https://www.linkedin.com/in/khushi-nandwani/

GitHub: https://github.com/Knandwani07

Deploying PHP Web Applications with Amazon EC2 and Aurora MySQL 📦

Khushi Nandwani — Sat, 03 Jan 2026 12:46:57 +0000

📘 Introduction

This project demonstrates the deployment of a PHP-based web application on Amazon EC2 and its integration with an Amazon Aurora (MySQL-compatible) database. The objective is to provision compute and database resources, configure secure connectivity, install a web application stack, and validate database interaction using PHP.

The project follows AWS best practices using free-tier eligible resources and focuses on clarity, reproducibility, and proper cleanup.

🏗️ Architecture Overview

The architecture consists of an Amazon EC2 instance hosting an Apache web server with PHP, connected to an Amazon Aurora MySQL-compatible database cluster within the same VPC. The EC2 instance handles application logic, while Aurora manages persistent data storage.

Communication between services is controlled using security groups, ensuring secure and private connectivity.

🧩 Architecture Components

Amazon EC2
- Amazon Linux AMI
- Apache HTTP Server
- PHP application runtime
Amazon Aurora (MySQL Compatible)
- Managed relational database
- Dev/Test configuration
- Single writer instance
Apache HTTP Server
- Serves PHP web pages
PHP
- Handles database connectivity and logic
MySQL Client (MariaDB)
- Used to validate database access
VPC & Security Groups
- Default VPC
- HTTP access enabled
- Database access restricted to EC2
Key Pair
- Secure EC2 authentication

🎯 Why This Project?

To understand real-world EC2–RDS integration
To gain hands-on experience with Amazon Aurora
To deploy a functional web application stack
To practice AWS resource lifecycle management
To build a portfolio-ready cloud project

✨ Key Features

End-to-end AWS service integration
Secure database connectivity
PHP-based application logic
Free-tier compatible setup
Structured cleanup to prevent unnecessary costs

🛠️Execution Workflow

I. EC2 Instance Setup

Launch an EC2 instance with Amazon Linux AMI

Select a free-tier eligible instance type (t2.micro / t3.micro)

Create and download an RSA key pair (.pem)

Allow HTTP traffic in the security group

Launch and verify the instance

II. Amazon Aurora Database Setup

Create an Amazon Aurora (MySQL Compatible) database

Select Dev/Test template

Configure DB cluster identifier and credentials

Use Aurora Standard storage

Select burstable instance class

Don't create aurora read replicas

Connect the database to the existing EC2 instance

Use default subnet group and VPC security group

In additional configuration, give a name to initialize database name

Create the database and wait for provisioning

III. Connect to EC2 Instance

Open EC2 Dashboard

Select the instance and Click Connect

Choose EC2 Instance Connect

IV. Install and Configure Apache Web Server

sudo dnf update -y

sudo dnf install -y httpd

sudo systemctl start httpd

sudo systemctl enable httpd

V. Install PHP and Required Extensions

sudo dnf install -y php php-mysqlnd

sudo systemctl restart httpd

sudo systemctl status httpd

php --version

VI. Install MySQL Client (MariaDB)

sudo dnf install -y mariadb105

mysql --version

VII. Configure Database Environment Variables

export USERNAME=admin export PASSWORD=newadmin12345 export DATABASE=myapp

VIII. Create PHP Application Files

Create a PHP page to establish database connectivity

Create a PHP page to count total page views stored in the database

📂 Full Repository

All source code, configuration steps, and documentation are available here: https://github.com/Knandwani07/aws-database-architectures/tree/main/php-ec2-aurora-deployment

IX. Restart Web Server

sudo systemctl restart httpd

X. Application Validation

Access the EC2 public IP in a browser

Confirm page view count increments correctly

XI. Resource Cleanup

Delete DB instance

Delete Aurora database cluster

Terminate EC2 instance

Delete key pair

Verify all resources are removed

✅ Conclusion

This project demonstrates a complete workflow for deploying a PHP web application backed by Amazon Aurora. It provides practical experience with AWS compute, managed databases, security configurations, and application-level integration.

The structured approach ensures clarity, scalability, and cost awareness, making this project suitable for learning, portfolio use, and interview discussions.

🤝 Let’s Connect

For feedback, collaboration, or cloud discussions:

LinkedIn: https://www.linkedin.com/in/khushi-nandwani/

GitHub: https://github.com/Knandwani07

How to Install AWS CLI on Windows: A Step-by-Step Guide

Khushi Nandwani — Sun, 06 Apr 2025 18:03:39 +0000

The AWS Command Line Interface (AWS CLI) is a unified tool to manage your AWS services. With just one tool to download and configure, you can control multiple AWS services from the command line and automate them through scripts.

Prerequisites Before We Begin

✅ Create an IAM user in your AWS account.
✅ Assign AdministratorAccess permissions to this user.
✅ Generate an Access Key and Secret Access Key for this IAM user.

These credentials will come in handy once we complete the CLI setup. We'll use them to log in via the terminal and run our first command: 𝐚𝐰𝐬 𝐢𝐚𝐦 𝐥𝐢𝐬𝐭-𝐮𝐬𝐞𝐫𝐬 If everything's set up correctly, this command will return a list of users in your AWS account right in your CLI.

A Step-by-Step guide on installing AWS CLI on Windows:

Step 1: Visit the AWS Documentation website to download the installer.
https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

Step 2: Choose your operating system; in this case, I am selecting Windows.

Step 3: Click to download the AWS CLI MSI installer for Windows (64-bit).
https://awscli.amazonaws.com/AWSCLIV2.msi

Step 4: The setup process will take a minute or two.

Step 5: Once the setup is complete, click "Next."

Step 6: Accept the license agreement and click "Next."

Step 7: Click "Next" on the Custom Setup screen.

Step 8: Finally, click "Install."

Step 9: After a few minutes, the installation will be complete.

Step 10: Open the Search menu and type "Command" to find the Command Prompt or Terminal.

Step 11: Open the Command Prompt or Terminal.

Step 12: Input 𝐚𝐰𝐬 --𝐯𝐞𝐫𝐬𝐢𝐨𝐧 to check the successful installation and to see the AWS version.

Step 13: Now, configure AWS in your Command Prompt.

Step 14: Enter your access key and secret key.

Step 15: Enter the region you want to use (I am entering Stockholm, which corresponds to eu-north-1).

Step 16: For the default output format, just hit Enter.

Step 17: To test the CLI, input 𝐚𝐰𝐬 𝐢𝐚𝐦 𝐥𝐢𝐬𝐭-𝐮𝐬𝐞𝐫𝐬, and you will see the IAM users you created in the Management Console.

Conclusion

In this guide, we walked through the process of installing and configuring the AWS Command Line Interface (CLI) on a Windows system. With the setup complete and the CLI verified, you are now equipped to begin managing AWS services directly from your terminal.

Connect with me on Linkedin, let’s spark new ideas together!