DEV Community: Vijaya Laxmi Kadham

🚀 AWS VPC Project: Build a Production-Ready Architecture with EC2, ALB, ASG & Bastion Host

Vijaya Laxmi Kadham — Thu, 11 Jun 2026 05:33:40 +0000

In the previous articles, we learned about:

VPC
subnets
Internet Gateway
Route Tables
Security Groups
Network ACLs
DNS and Route 53

Until now, we have learned individual AWS networking components separately.

But in real world projects, these services work together to build secure and highly available applications.

What We Will Build

In this project, we will create:

A custom VPC
Public and Private Subnets
Two Availability Zones
NAT Gateways
Bastion Host
Auto Scaling Group
Application Load Balancer
Target Group
EC2 Instances running inside Private Subnets

By the end of this project, you will understand how traffic flows inside AWS and how different networking components work together.

Why Are We Using Two Availability Zones?

In production environments, applications are usually deployed across multiple Availability Zones (AZs).

This improves High Availability.

For example, if one AZ experiences a failure, the application can continue serving users from the second AZ.

This helps reduce downtime and improves reliability.

Therefore, in this project, we will use:

2 Availability Zones (AZs)
2 Public Subnets
2 Private Subnets

Architecture Overview

Each Availability Zone (AZ) will contain:

Public Subnet

NAT Gateway
Application Load Balancer

Private Subnet

EC2 Instances launched using an Auto Scaling Group

The EC2 instances will remain private and will not have public IP addresses.

We will access them securely using a Bastion Host.

What You Will Learn

We will also understand:

How internet traffic reaches the application.
How private servers access the internet using a NAT Gateway.
How the Load Balancer distributes traffic.
How Auto Scaling Groups help applications handle increased traffic.

Before We Start

Before starting the implementation, let's first understand some of the concepts that we will use throughout this project.

Don't worry if these concepts seem new right now — we will see them in action during the implementation.

What is NAT Gateway?

A NAT (Network Address Translation) Gateway allows resources inside a private subnet to access the internet without exposing them directly to the internet.

In our project, the application servers will be running inside private subnets and will not have public IP addresses.

However, there may be situations where these servers need internet access, such as:

Downloading software packages
Installing updates
Accessing public APIs

This is where the NAT Gateway helps.

Example

Private EC2
     ↓
NAT Gateway
     ↓
  Internet

The private EC2 instance can access the internet, but internet users cannot directly access the EC2 instance.

This improves security while still allowing outbound internet connectivity.

What is Auto Scaling Group?

An Auto Scaling Group (ASG) helps automatically manage EC2 instances based on application demand.

Imagine your application normally runs on 2 EC2 instances.

Suddenly, a large number of users start accessing the application.

The existing servers may not be enough to handle the traffic.

In such situations, an Auto Scaling Group can automatically launch additional EC2 instances.

Similarly, when traffic decreases, it can terminate unnecessary instances.

Example

Normal Traffic
      ↓
2 EC2 Instances
      ↓
 High Traffic
      ↓
4 EC2 Instances
      ↓
 Low Traffic
      ↓
2 EC2 Instances

Benefits of Auto Scaling Groups

Auto Scaling Groups help to:

Improve availability
Handle traffic spikes
Optimize infrastructure costs

What is Load Balancer?

A Load Balancer distributes incoming traffic across multiple servers.

Instead of sending all requests to a single server, it spreads the traffic across multiple EC2 instances.

Example

Users
   ↓
Load Balancer
   ↓
├── EC2 Instance 1
├── EC2 Instance 2
└── EC2 Instance 3

Benefits of Load Balancer

A Load Balancer helps to:

Improve performance
Prevent server overload
Increase application availability

In this project, users will access the application through the Load Balancer.

What is Target Group?

A Target Group is a collection of servers that receive traffic from a Load Balancer.

Think of a Target Group as a list of backend servers.

When the Load Balancer receives a request, it forwards that request to one of the healthy servers registered inside the Target Group.

Example

Load Balancer
      ↓
Target Group
      ↓
├── EC2 Instance 1
├── EC2 Instance 2
└── EC2 Instance 3

How Target Groups Work

The Load Balancer does not directly send traffic to EC2 instances.

Instead, it sends traffic through the Target Group, which then routes requests to healthy EC2 instances.

This helps:

Route traffic efficiently
Perform health checks on backend servers
Improve application availability
Ensure requests are sent only to healthy instances

What is a Bastion Host?

A Bastion Host, also called a Jump Server, is an EC2 instance placed inside a public subnet that is used to securely access resources inside private subnets.

In our project, the application servers will be running in private subnets and will not have public IP addresses.

This means we cannot directly SSH into them.

To solve this problem, we create a Bastion Host.

Example

Developer Laptop
       ↓
   Bastion Host
       ↓
   Private EC2

Instead of exposing private servers to the internet, we first connect to the Bastion Host and then access the private servers.

Benefits of Using a Bastion Host

This approach provides:

Better security
Centralized access control
Better auditing and monitoring

Now that we understand the components used in this project, let's start building the architecture step by step.

Hands-On Implementation of the Project

Before starting, we will build the following architecture:

                    Internet
                        │
                       ▼
                Application Load Balancer
                        │
        ┌───────────────┴───────────────┐
        │                               │
 Availability Zone A             Availability Zone B
        │                               │
 Public Subnet A                 Public Subnet B
 ├── NAT Gateway A               ├── NAT Gateway B
 └── Bastion Host

        │                               │

 Private Subnet A               Private Subnet B
 └── EC2 Instance (ASG)         └── EC2 Instance (ASG)

Architecture Diagram

The above architecture diagram may look confusing at first, but don't worry.

Once we follow the implementation steps below and revisit the diagram, the overall flow and the relationship between the AWS components will become much easier to understand.

Step 1: Create the VPC

Go to AWS Console → VPC.

Click on Create VPC.

Select VPC and more.

Why?

Because AWS automatically creates:

VPC
Public Subnets
Private Subnets
Route Tables
Internet Gateway

This saves time and simplifies the setup process.

Now, give your VPC a name, for example:

aws-prod-proj

For the IPv4 CIDR Block, use:

10.0.0.0/16

This provides approximately 65,536 IP addresses, which is more than enough for our project.

For IPv6 CIDR Block, choose:

No IPv6 CIDR block

Why?

To keep the project simple.

Configure the following:

Number of Availability Zones (AZs): 2
Public Subnets: 2
Private Subnets: 2

So the architecture becomes:

AZ-1
├── Public Subnet
└── Private Subnet

AZ-2
├── Public Subnet
└── Private Subnet

Configure NAT Gateway

For NAT Gateway, choose:

Zonal → 1 per AZ

Why?

Private EC2 instances need internet access for:

Installing updates
Downloading software packages
Accessing public APIs

However, we do not want to assign public IP addresses to those instances.

The NAT Gateway solves this problem by providing outbound internet access while keeping the instances private.

Configure VPC Endpoints

For VPC Endpoints, choose:

None

Why?

We are not using VPC Endpoints in this project.

Finally, click Create VPC.

Wait for AWS to finish creating all the required resources.

Step 2: Verify the Resource Map

After the VPC creation is complete, navigate to:

VPC → Your VPC → Select Your VPC → Resource Map

You should see the following resources:

✅ VPC
✅ Internet Gateway
✅ Public Subnet A
✅ Public Subnet B
✅ Private Subnet A
✅ Private Subnet B
✅ NAT Gateway A
✅ NAT Gateway B
✅ Route Tables

Understanding What AWS Created

Public Subnets

Public Subnets are:

Accessible from the internet
Used for internet-facing resources

Examples include:

Load Balancers
Bastion Hosts
NAT Gateways

Private Subnets

Private Subnets are:

Hidden from the internet
Used for application servers

Examples include:

EC2 Instances
Backend Services
Databases

Step 3: Create Launch Template

Before creating the Auto Scaling Group, we first need a Launch Template.

Why Do We Need a Launch Template?

Think of a Launch Template as a blueprint for EC2 instances.

It tells AWS:

Which operating system (AMI) to use
Which instance type to launch
Which key pair to use
Which Security Group to attach
Which VPC to use

Later, whenever the Auto Scaling Group needs to create new servers, it simply uses this template.

Navigate to Launch Templates

Go to:

AWS Console → EC2 → Launch Templates

Click on Create Launch Template.

Configure the Launch Template

Give your Launch Template a name:

aws-prod-proj

In the description field, enter:

Launch template for application servers running in private subnets

Choose an AMI

For the AMI (Operating System), choose:

The Recently Launched option, or
Any AMI you are comfortable with

Choose the Instance Type

Select:

t3.micro (Free Tier)

Select the Key Pair

Choose your key pair, for example:

test_app.pem

Configure Network Settings

Under Firewall (Security Groups), select:

Create Security Group

Security Group Name

aws-prod-proj

Description

Security Group for private application servers

Configure Inbound Rules

Rule 1

Type	Port	Source
SSH	22	My IP

Why?

Initially, we will keep SSH access simple while building the project.

Later, we will tighten security so that only the Bastion Host can access these servers.

Rule 2

Type	Port	Source
Custom TCP	8000	Anywhere IPv4

Why?

Our Python application will run on Port 8000.

Later, once the Load Balancer is configured, we will improve this rule further.

For now, leave everything else as default.

Click on Create Launch Template.

What Have We Created?

We haven't created EC2 instances yet.

We have only created a blueprint.

Launch Template
        ↓
Auto Scaling Group
        ↓
EC2 Instances

Step 4: Creating Auto Scaling Group

Until now, we have only created the blueprint (Launch Template).

Now we need AWS to actually launch EC2 instances from that blueprint.

Why Do We Need Auto Scaling Groups?

Auto Scaling Groups (ASGs) help:

Automatically create EC2 instances
Replace unhealthy instances
Scale up during high traffic
Scale down during low traffic

Navigate to Auto Scaling Groups

Go to:

AWS Console → EC2 → Auto Scaling Groups

Click on Create Auto Scaling Group.

Configure the Auto Scaling Group

Give your Auto Scaling Group a name, for example:

aws-prod-proj

Select the Launch Template we created earlier:

aws-prod-proj

Click Next.

Choose the Network

Select the VPC we created earlier:

aws-prod-proj

Under Availability Zones and Subnets, choose the two private subnets created during VPC creation:

Private Subnet 1a
Private Subnet 1b

Why Are We Using Private Subnets?

Application servers should not be directly exposed to the internet.

This improves security.

The architecture becomes:

Public Subnets
      ↓
Load Balancer
      ↓
Private EC2 Instances

Click Next.

Leave the remaining settings as default and click Next again.

Configure Group Size

Set the following values:

Desired Capacity

Meaning AWS should maintain 2 EC2 instances.

Minimum Capacity

At least one instance should always remain running.

Maximum Capacity

In the future, AWS can scale up to four servers if required.

Scaling Policies

Choose:

None

Skip the remaining sections and keep the default settings.

Click Next → Create Auto Scaling Group.

Step 5: Verify EC2 Instances

Now navigate to:

EC2 → Instances

Wait for a few minutes.

You should see:

Instance 1 → Running
Instance 2 → Running

Click on any instance ID and inspect its details.

If you look carefully, you will notice:

Public IPv4 Address = None

This is expected.

Why?

Because:

The instances are inside private subnets.
Private subnets should not have public IP addresses.

Current Architecture

At this stage, the architecture looks like this:

                VPC
                  │
      ┌───────────┴───────────┐
      │                       │
Availability Zone A   Availability Zone B
      │                       │
Private Subnet A      Private Subnet B
      │                       │
EC2 Instance 1        EC2 Instance 2

Step 6: Create Bastion Host

Why Do We Need a Bastion Host?

Imagine your company has hundreds of servers running inside private subnets.

Giving public IP addresses to all servers would be dangerous.

Instead, we create one secure entry point called a Bastion Host.

The architecture becomes:

Developer Laptop
        ↓
Bastion Host (Public Subnet)
        ↓
Private EC2 Instances

Create Bastion Host

Go to:

AWS Console → EC2 → Launch Instance

Give your instance a name:

bastion-host

AMI

Choose:

Ubuntu Server

Instance Type

Choose:

t3.micro (Free Tier)

Key Pair

Select the same key pair used earlier:

test_app.pem

Configure Network Settings

Click Edit.

Select the VPC:

aws-prod-proj

IMPORTANT: Choose a Public Subnet

Select either:

Public Subnet A, or
Public Subnet B

Why?

Because the Bastion Host must be reachable from your laptop.

Auto Assign Public IP

Choose:

Enable

Why?

Without a public IP address, you won't be able to SSH into the Bastion Host.

Configure Security Group

Choose:

Create Security Group

Security Group Name:

bastion-sg

Configure Inbound Rules

Instead of:

❌ Anywhere (0.0.0.0/0)

Choose:

✅ My IP

Type	Port	Source
SSH	22	My IP

Why?

This is much safer.

Only your laptop can access the Bastion Host.

Step 7: Verify Bastion Host

After the instance starts, navigate to:

EC2 → Instances

Verify that:

The instance state is Running
A Public IPv4 Address is present

Current architecture:

                Internet
                     │
                     ▼
               Bastion Host
                     │
      ┌──────────────┴──────────────┐
      │                             │
 Private EC2-1                Private EC2-2

Bastion Host Status

✅ Running
✅ Has Public IP
✅ Security Group allows SSH from My IP

Step 8: Improve Security Group Configuration (Production Best Practice)

Right now, when we created the Launch Template earlier, we allowed:

SSH (22) → My IP

for the private EC2 instances.

Although this works, it is not ideal because application servers should only accept SSH connections from the Bastion Host.

Current Situation

Laptop
   ↓
Private EC2

Better Architecture

Laptop
   ↓
Bastion Host
   ↓
Private EC2

Step 8.1: Find the Security Group Attached to Private EC2

Go to:

EC2 → Instances

Open one of your private instances.

Go to the Security tab.

Click on the attached Security Group.

Step 8.2: Remove SSH Access from "My IP"

Inside the Security Group:

Click Edit Inbound Rules.

It should currently have:

Type	Port	Source
SSH	22	My IP
Custom TCP	8000	Anywhere

Delete the SSH rule.

Keep Port 8000 for now.

Click Save Rules.

Step 8.3: Allow SSH Only from Bastion Host

Click Add Rule.

Configure:

Type: SSH
Port: 22
Source: Custom

In the search bar next to Source, select:

bastion-sg

This is the Security Group attached to the Bastion Host.

Click Save Rules.

What We Achieved

Instead of:

My Laptop
      ↓
Private EC2

we now have:

My Laptop
      ↓
Bastion Host
      ↓
Private EC2

Only the Bastion Host can SSH into the private servers.

Step 9: Connect to Bastion Host

Copy the Bastion Host Public IP Address.

On your local machine, run:

ssh -i test_app.pem ubuntu@<BASTION_PUBLIC_IP>

Connection Issue Encountered

When running the above command, I received the following error:

ssh: connect to host <PUBLIC_IP> port 22: Connection timed out

To verify whether the issue was related to the Security Group, I temporarily modified the inbound rule:

From:

Source: My IP

To:

Anywhere IPv4 (0.0.0.0/0)

After saving the rule, I was able to successfully SSH into the Bastion Host.

Note: Allowing SSH from Anywhere IPv4 was done only for troubleshooting purposes. In production environments, it is recommended to restrict SSH access to trusted IP addresses.

Step 10: Enable SSH Agent Forwarding (Best Practice)

Instead of copying the .pem file into the Bastion Host, we'll use SSH Agent Forwarding.

1. Start SSH Agent

On your local machine, run:

eval "$(ssh-agent -s)"

What Does This Do?

It starts a background process called SSH Agent.

Think of SSH Agent as a temporary secure locker that can hold your SSH keys.

After running:

eval "$(ssh-agent -s)"

You should see output similar to:

Agent pid 12345

2. Add the Private Key

Run:

ssh-add test_app.pem

What Does This Do?

This command loads your .pem file into the SSH Agent.

Now the SSH Agent can use this key whenever authentication is required.

3. Verify Loaded Keys

Run:

ssh-add -l

What Does This Do?

This command displays the keys currently loaded inside the SSH Agent.

Example output:

Step 11: Connect to Bastion Using Agent Forwarding

From your laptop, run:

ssh -A -i test_app.pem ubuntu@<BASTION_PUBLIC_IP>

Notice the important option:

-A

Why Are We Using `-A`?

The -A option enables SSH Agent Forwarding.

This securely forwards your local SSH key to the Bastion Host without copying the .pem file to the server.

This is considered a best practice because:

The private key never leaves your laptop.
No sensitive files are stored on the Bastion Host.
Access to private EC2 instances becomes more secure.

Step 12: Find the Private IP of One Application Server

Go to:

EC2 → Instances

Choose one of the private EC2 instances.

Copy its:

Private IPv4 Address

Example:

10.0.131.24

Step 13: SSH From Bastion Host to Private EC2

From inside the Bastion Host, run:

ssh ubuntu@10.0.x.x

Replace 10.0.x.x with the private IP address of your EC2 instance.

The connection should now be successful, and you will be inside the private server.

Current Architecture

Laptop
   ↓
SSH Agent Forwarding
   ↓
Bastion Host
   ↓
Private EC2

Step 14: Prepare the Private EC2 Instance

At this point, you should be logged into the private EC2 instance.

Verify this by running:

hostname

Update Package Information

Run:

sudo apt update

Why?

This updates the package repository information.

It also verifies that the following path is working correctly:

Private EC2
      ↓
NAT Gateway
      ↓
Internet

If the update completes successfully, your NAT Gateway is functioning correctly.

Step 15: Verify Python Installation

Check the installed Python version:

python3 --version

Expected output:

Python 3.x.x

If Python is not installed, run:

sudo apt install python3 -y

Step 16: Create a Simple HTML Page

Create a new file:

vim index.html

Press:

to enter Insert Mode.

Paste the following HTML:

<!DOCTYPE html>
<html>
<head>
    <title>AWS Production Project</title>
</head>
<body>
    <h1>AWS VPC Production Project</h1>
    <p>Application running successfully inside Private Subnet.</p>
</body>
</html>

Save the file:

ESC
:wq!

Step 17: Start Python Web Server

Run:

python3 -m http.server 8000

Expected output:

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Leave this terminal running.

The web server is now serving the application on Port 8000.

Step 18: Verify Security Group for Application

Before creating the Load Balancer, verify the Security Group attached to your application servers.

Go to:

EC2 → Security Groups

Open the private EC2 Security Group created earlier.

Example:

aws-prod-proj

Verify that the following inbound rules exist:

Type	Port	Source
SSH	22	bastion-sg
Custom TCP	8000	Anywhere IPv4

If Port 8000 is missing, add it click Save Rules.

Why Are We Allowing Port 8000?

Because later the traffic flow will be:

Load Balancer
      ↓
Port 8000
      ↓
Application Server

The Load Balancer must be able to reach the application.

We'll improve this later by allowing access only from the Load Balancer Security Group.

Step 19: Verify the Application Is Running

On the private EC2 instance, open another SSH session if needed and run:

curl localhost:8000

Expected output:

<!DOCTYPE html>
<html>
...

If you see the HTML page, your application is running successfully.

Step 20: Create a Target Group

What is a Target Group?

Before creating a Load Balancer, AWS needs to know:

"Which servers should receive the traffic?"

A Target Group is simply a collection of backend servers.

Example:

Load Balancer
      ↓
Target Group
      ↓
├── EC2 Instance 1
└── EC2 Instance 2

Navigate to Target Groups

Go to:

EC2 → Target Groups

Click:

Create Target Group

Basic Configuration

Target Type

Choose:

Instances

Why?

Because we want traffic to be routed directly to EC2 instances.

Target Group Name

Example:

aws-prod-proj

Protocol

Choose:

HTTP

Port

Enter:

Why?

Our Python application is listening on:

python3 -m http.server 8000

VPC

Select:

aws-prod-proj

Health Check Protocol

Keep:

HTTP

Health Check Path

Keep:

This means AWS will periodically check:

http://instance-ip:8000/

to verify that the application is healthy.

Click Next.

Register Targets

You should see your Auto Scaling instances.

Select:

Instance 1
Instance 2

Click:

Include as Pending Below

Then click:

Create Target Group

Step 21: Create Application Load Balancer

Now let's create the public entry point for users.

Navigate to Load Balancers

Go to:

EC2 → Load Balancers

Click:

Create Load Balancer

Choose:

Application Load Balancer

Then click:

Create

Configure the Load Balancer

Name

Example:

aws-prod-proj

Scheme

Select:

Internet-facing

Why?

Users will access the application from the internet.

IP Address Type

Choose:

IPv4

Network Mapping

Select the VPC created earlier:

aws-prod-proj

Availability Zones

Choose:

Public Subnet A
Public Subnet B

Why?

Load Balancers must be deployed inside public subnets.

Security Group

For now, choose:

default

This is the cleaner option.

Listener and Routing

Listener

HTTP

Port

Default Action

Select:

Forward to Target Groups

Choose the Target Group created earlier:

aws-prod-proj

Click:

Create Load Balancer

Wait a few minutes for AWS to provision the Load Balancer.

Step 22: Check Target Health

Go to:

EC2 → Target Groups

Open:

aws-prod-proj

Click:

Targets

Verify that your targets are healthy.

Step 23: Access the Application

Go to:

EC2 → Load Balancers

Open your Application Load Balancer.

Copy the:

DNS Name

Example:

aws-prod-proj-123456.ap-south-1.elb.amazonaws.com

Copy the URL and Open it in your browser.

Troubleshooting

When I initially tried to access the application, the page was not loading.

To troubleshoot the issue, I verified the following.

1. Private EC2 Security Group

Go to:

EC2 → Instances → Private Instance → Security

Open the attached Security Group.

Verify the rules:

Type	Port	Source
SSH	22	bastion-sg
Custom TCP	8000	Anywhere IPv4

2. Load Balancer Security Group

Go to:

EC2 → Load Balancers → Select the Load Balancer

Under Security, open the attached Security Group.

My rules were incorrect, so I updated them to:

Type	Port	Source
HTTP	80	0.0.0.0/0

After saving the changes, the application loaded successfully.

Conclusion

In this project, we built a production-style AWS VPC architecture from scratch and understood how different AWS networking components work together.

We implemented:

Custom VPC
Public and Private Subnets across two Availability Zones
Internet Gateway and Route Tables
NAT Gateways for secure outbound internet access
Auto Scaling Group with EC2 instances in private subnets
Bastion Host for secure administration
Application Load Balancer and Target Group
A sample Python web application running inside private EC2 instances

One of the most important learnings from this project was understanding how traffic flows inside a production environment:

Internet
    ↓
Application Load Balancer
    ↓
Private EC2 Instances

and how administrators securely access private servers using:

Developer Laptop
    ↓
Bastion Host
    ↓
Private EC2 Instances

This project helped me understand how real-world applications are deployed securely and with high availability across multiple Availability Zones.

Let's meet in the next article with a new AWS service 🚀👋

Understanding DNS and AWS Route 53 for Beginners

Vijaya Laxmi Kadham — Tue, 09 Jun 2026 07:16:43 +0000

In the previous articles, we learned about:

VPC
Subnets
Internet Gateway
Route Tables
Security Groups
Network ACLs (NACLs)

These components help us build and secure our AWS infrastructure.

But there is still one question:

How do users actually find our application?

For example, when users open:

www.amazon.com

how does the browser know where the website is running?

This is where DNS and AWS Route 53 come into the picture.

In this article, we will understand:

What DNS is
Why DNS is needed
What AWS Route 53 is
How Route 53 works
Real-world examples
AWS examples

Let's get started.

Why Do We Need DNS?

Imagine you want to call your friend.

Would you remember:

9876543210

for every person in your contacts?

Probably not.

Instead, you save names like:

Mom
Dad
Friend
Office

Your phone automatically maps the name to the phone number.

DNS works exactly the same way.

Instead of remembering IP addresses like:

54.210.100.25

we simply remember:

www.google.com

DNS converts:

Domain Name → IP Address

This makes websites easier for humans to use.

What is DNS?

DNS stands for:

Domain Name System

DNS is like the phonebook of the internet.

Its job is to convert:

www.amazon.com

into something computers understand:

54.xx.xx.xx

Without DNS, we would have to remember IP addresses for every website.

Real-Life Example

Think of a restaurant.

People usually say:

McDonald's

instead of saying:

Building Number 25
Street Number 10
City XYZ

The restaurant name is easier to remember.

Similarly:

www.youtube.com

is easier to remember than:

142.250.182.206

How DNS Works

Suppose a user opens:

www.shopworld.com

The process looks like this:

User
   ↓
DNS Lookup
   ↓
IP Address Found
   ↓
Application Server

DNS finds the IP address associated with the domain name and sends the user to the correct server.

What is AWS Route 53?

AWS Route 53 is Amazon's managed DNS service.

It helps:

Convert domain names into IP addresses
Route users to AWS resources
Improve application availability
Register domain names

Simply put:

Route 53 is AWS's DNS service.

Why is it Called Route 53?

DNS communication uses:

Port 53

That is why AWS named the service:

Route 53

How Route 53 Works

Suppose you have a website:

www.shopworld.com

Your application is running behind a Load Balancer.

When a user enters the domain name, Route 53 finds the correct destination.

Flow:

User
   ↓
www.shopworld.com
   ↓
Route 53
   ↓
Load Balancer
   ↓
Application Server

Route 53 does not host your application.

Its job is only to direct users to the correct resource.

AWS Example

Suppose your architecture looks like this.

Public Subnet

Load Balancer

Private Subnet

Application Server

Users do not know the IP address of your Load Balancer.

Instead, they simply visit:

www.shopworld.com

Route 53 translates the domain name and forwards users to the Load Balancer.

The Load Balancer then sends requests to the application server.

Real-World Example

Imagine an e-commerce company.

Without DNS:

http://44.210.150.20

Customers would need to remember the IP address.

With DNS:

www.shopworld.com

Customers can easily remember and access the website.

DNS makes the internet user-friendly.

Benefits of Route 53

Route 53 provides:

High Availability
Scalability
Managed DNS Service
Domain Registration
Health Checks
Traffic Routing Capabilities

Because AWS manages Route 53, we do not need to maintain DNS servers ourselves.

Summary

DNS converts:

Domain Name → IP Address

AWS Route 53 is Amazon's managed DNS service that helps users access applications using easy-to-remember domain names.

Conclusion

DNS is one of the fundamental building blocks of the internet.

Without DNS, users would have to remember IP addresses for every website.

AWS Route 53 simplifies this process by providing a highly available and scalable DNS service.

Understanding DNS and Route 53 is an important AWS networking concept and is commonly used in real-world cloud architectures.

Additional Resources

If you want to explore Route 53 in more detail, refer to the official AWS documentation:

Note: This article covers Route 53 fundamentals for beginners. The official AWS documentation provides deeper explanations and advanced features.

What's Next?

In the next article, we will build a complete AWS VPC Project that can be added to your resume.

This project is inspired by concepts learned from Abhishek Veeramalla's AWS learning series. I will be implementing the project step by step while explaining the concepts in my own words.

We will create:

Custom VPC
Public and Private Subnets
Internet Gateway
Route Tables
Security Groups
EC2 Instances

and understand how these components work together in a real-world architecture.

🚀 See you in the next article.

Hands-On: Understanding Security Groups and NACLs in AWS

Vijaya Laxmi Kadham — Sun, 07 Jun 2026 11:38:30 +0000

In the previous article, we learned the theory behind:

Security Groups
Network Access Control Lists (NACLs)

Now it is time to see them in action.

In this hands-on lab, we will:

Create a VPC
Launch an EC2 instance
Run a simple Python web server
Allow traffic using Security Groups
Block traffic using NACLs
Understand how both security layers work together

By the end of this lab, you will clearly understand the difference between Security Groups and NACLs.

Let's dive into the hands-on.

Step 1: Create a VPC

Search for:

VPC

Click:

Create VPC

Select:

VPC and More

This automatically creates:

VPC
Public Subnet
Private Subnet
Route Tables
Internet Gateway

Give your VPC a name:

vpc-test

For the IPv4 CIDR block, choose the IP range you want.

Example:

10.0.0.0/16

Click Create VPC.

After creating the VPC, click View VPC and open the Resource Map.

This helps you understand how all networking components are connected.

Step 2: Launch an EC2 Instance

Navigate to:

EC2 → Instances → Launch Instance

Provide:

EC2 Instance Name
Operating System
Key Pair

Under Network Settings:

Select the VPC you created: vpc-test
Select the Public Subnet

Note: In production environments, applications should preferably use private subnets. However, for learning purposes, we will use a public subnet.

Enable:

Auto Assign Public IP

Under Firewall (Security Groups) choose:

Create New Security Group

Click Launch Instance.

Step 3: Connect to the EC2 Instance

Copy the Public IP address of the instance.

Open Terminal and connect using SSH.

Example:

ssh -i test_app.pem ubuntu@<PUBLIC_IP>

Replace:

<PUBLIC_IP>

with your EC2 Public IP.

Step 4: Update Packages

Whenever you launch a Linux server, updating packages is considered a good practice.

Run:

sudo apt update

Step 5: Verify Python Installation

Check whether Python is installed.

Run:

python3

Step 6: Start a Simple Python Web Server

Python provides a built-in HTTP server.

Run:

python3 -m http.server 8000

Your application is now running on:

Port 8000

Step 7: Try Accessing the Application

Open your browser and type:

http://<PUBLIC_IP>:8000

Example:

http://54.xx.xx.xx:8000

You will notice that the application does not open.

Why?

Let's investigate what is blocking the application.

Step 8: Check the NACL

Navigate to:

AWS Console → VPC → Network ACLs

Open the NACL associated with your subnet.

Check the Inbound Rules.

Here you will notice something interesting.

AWS already allows traffic through the NACL.

Example:

Rule 100 → Allow All Traffic

This means the NACL is not blocking us.

So why can't we access the application?

Because there is another security layer:

Security Group

Now, you may have noticed rule number 100, and * in the above screenshot of NACL Rules.

Let's understand what they mean.

Understanding NACL Rule Priority

NACL rules are evaluated in order.

Smaller numbers have higher priority.

Example:

100 → Checked First
200 → Checked Second
300 → Checked Third
...
*   → Checked Last

AWS evaluates rules from top to bottom until a match is found.

Step 9: Allow Port 8000 in Security Group

Navigate to:

EC2 → Instance → Security

Open the attached Security Group.

Click:

Edit Inbound Rules

By default, Security Groups block most incoming traffic and only allow SSH access.

Now add a new rule:

Type: Custom TCP
Port: 8000
Source: Anywhere IPv4

Save the rule.

Step 10: Test Again

Return to your browser and refresh:

http://<PUBLIC_IP>:8000

This time the application loads successfully.

What changed?

The Security Group now allows traffic on Port 8000.

Flow:

Internet
   ↓
NACL (Allowed)
   ↓
Security Group (Allowed)
   ↓
EC2 Instance

Now that we understand how Security Groups and NACLs work together, let's perform one more experiment.

Step 11: Block Traffic Using NACL

Navigate to:

VPC → Network ACLs

Click:

Edit Inbound Rules

Create the following rule:

Rule Number: 100
Type: Custom TCP
Port Range: 8000
Source: 0.0.0.0/0
Action: Deny

Save the changes.

Step 12: Test Again

Refresh:

http://<PUBLIC_IP>:8000

The application is no longer accessible.

Why?

Because traffic is blocked at the subnet level before reaching the Security Group.

Flow:

Internet
   ↓
NACL (Denied)
   ❌
Security Group
   ❌
EC2 Instance

Even though the Security Group allows Port 8000, the NACL blocks the request first.

Step 13: Understanding Rule Priority

Now let's restore access.

Navigate to:

VPC → Network ACLs

Click:

Edit Inbound Rules

Create:

Rule 100

Allow All Traffic

Create another rule:

Rule 200

Type: Custom TCP
Port Range: 8000
Source: 0.0.0.0/0
Action: Deny

Save the changes.

What Happens Now?

Try accessing:

http://<PUBLIC_IP>:8000

The application works successfully.

Why?

Because AWS checks:

Rule 100

first.

Since Rule 100 allows all traffic, AWS never evaluates Rule 200.

Flow:

Rule 100 → Match Found → Allow

Rule 200 → Ignored

This demonstrates one of the most important NACL concepts:

Lower numbered rules have higher priority.

Key Takeaways

Security Groups

Work at Instance Level
Stateful
Allow Traffic

Network ACLs

Work at Subnet Level
Stateless
Allow and Deny Traffic
Use Rule Priority

Request Flow

Internet
   ↓
NACL
   ↓
Security Group
   ↓
EC2 Instance

If either layer blocks the traffic, the request never reaches the server.

Conclusion

In this hands-on lab, we:

Created a VPC
Launched an EC2 instance
Deployed a simple Python web server
Allowed traffic using Security Groups
Blocked traffic using NACLs
Observed how multiple security layers work together

We also learned that:

Security Groups control traffic at the instance level.
NACLs control traffic at the subnet level.
NACL rule priority affects traffic flow.
Multiple security layers improve AWS network security.

Understanding these concepts is essential for AWS networking and cloud security.

Security Groups vs NACLs Explained for Beginners

Vijaya Laxmi Kadham — Sat, 06 Jun 2026 11:06:00 +0000

Security Groups vs NACLs Explained for Beginners

In the previous articles, we learned about:

VPC
Subnets
Internet Gateway
Route Tables

These components help AWS resources communicate with each other and with the internet.

But there is still one important question:

Even if a server is reachable, should everyone be allowed to access it?

The answer is No.

We need security controls that decide:

Who can access our resources
Which traffic is allowed
Which traffic should be blocked

AWS provides two important security layers for this:

Security Groups
Network Access Control Lists (NACLs)

At first, they may seem similar, but they work at different levels and have different purposes.

In this article, we will understand them using simple real-world examples.

Why Do We Need Security Layers?

Imagine you own a house.

Just because a road leads to your house does not mean everyone should be allowed inside.

You still need:

A gate around the property
A lock on the door

AWS networking works in a similar way.

Even if:

A route exists
The internet can reach your subnet

You still need security rules that decide whether traffic should be allowed or blocked.

This is where Security Groups and NACLs come in.

What is a Security Group?

A Security Group is a virtual firewall attached directly to an EC2 instance.

Simply put, Security Groups are created at the instance level.

It controls:

Incoming Traffic (Inbound Rules)
Outgoing Traffic (Outbound Rules)

Think of a Security Group as the security guard standing at the door of your house.

Every request must pass through the guard before reaching the server.

Example

Suppose you have a web server running on an EC2 instance.

The website uses:

Port 80

for HTTP traffic.

You can configure the Security Group to allow traffic on Port 80.

Requests coming on Port 80 are allowed.
Requests coming from other ports are blocked.

Security Group Flow

Internet
   ↓
Security Group
   ↓
EC2 Instance

If traffic matches an allowed rule:

The request reaches the EC2 instance.

Otherwise:

AWS blocks the request.

Security Groups are Stateful

This is one of the most important concepts.

Suppose a user visits your website.

Step 1: User accesses the website

User
  ↓
EC2 Web Server

Step 2: EC2 sends the response back

EC2 Web Server
  ↓
User

When inbound traffic is allowed, AWS automatically allows the response traffic.

You do not need to create separate rules for return traffic.

This behavior is called:

Stateful

Think of it like a phone call.

If you answer a call, you can automatically talk back without opening another connection.

What is a NACL?

NACL stands for:

Network Access Control List

A NACL acts as a firewall at the subnet level.

Instead of protecting a single EC2 instance, it protects the entire subnet.

Think of a NACL as the security gate at the entrance of an apartment complex.

Anyone entering the apartment complex must pass through the gate first.

NACL Flow

Internet
   ↓
NACL
   ↓
Subnet
   ↓
Security Group
   ↓
EC2 Instance

Notice that the NACL checks traffic before it reaches the Security Group.

Example

Suppose your subnet contains:

Web Server
Application Server
Monitoring Server

Instead of configuring rules individually on each server, you can create subnet-level rules using a NACL.

Allow:

Port 80
Port 443

Deny:

Port 22 from the Internet

These rules apply to the entire subnet.

NACLs are Stateless

Unlike Security Groups, NACLs are stateless.

This means AWS does not automatically allow return traffic.

You must explicitly configure:

Inbound Rules
Outbound Rules

Example

If inbound HTTP traffic is allowed:

Internet
   ↓
Subnet

You must also create outbound rules so the response can return:

Subnet
   ↓
Internet

Otherwise, communication fails.

This behavior is called:

Stateless

Security Group vs NACL

Feature	Security Group	NACL
Works At	EC2 Instance Level	Subnet Level
Stateful	Yes	No
Allows Traffic	Yes	Yes
Denies Traffic	No	Yes
Applied To	EC2 Instances	Subnets
Protection Scope	Individual Resource	Entire Subnet

Easy Way to Remember

Think about an apartment building.

Apartment Complex
        ↓
       NACL
        ↓
     Apartment
        ↓
 Security Group

NACL

Security at the apartment gate.

Security Group

Security at the apartment door.

Both work together.

Why Does AWS Use Both?

AWS follows a security principle called:

Defense in Depth

Instead of relying on a single security layer, AWS uses multiple layers of protection.

Layer 1

NACL protects the subnet.

Layer 2

Security Group protects the EC2 instance.

Even if one layer is misconfigured, another layer can still provide protection.

Real-World Example

Imagine an online shopping application.

Public Subnet

Contains:

Load Balancer

Private Subnet

Contains:

Application Server
Database

Security Group Rules

Allow users to access the Load Balancer
Allow the Load Balancer to access the Application Server
Allow the Application Server to access the Database

NACL Rules

Block unwanted traffic at the subnet level
Allow only required ports

This creates multiple layers of security.

Conclusion

Security Groups and NACLs both play an important role in AWS security, but they work at different levels.

Security Groups

Protect individual EC2 instances
Are stateful
Allow traffic

NACLs

Protect entire subnets
Are stateless
Can allow or deny traffic

Understanding the difference between Security Groups and NACLs is an important AWS networking concept.

What's Next?

In the next article, we will perform a hands-on lab where we will:

Create a custom VPC
Launch an EC2 instance
Allow traffic using a Security Group
Block traffic using a NACL
Observe how both security layers work together

🚀 Stay tuned for the hands-on implementation.

AWS Internet Gateway and Route Tables Explained for Beginners

Vijaya Laxmi Kadham — Wed, 03 Jun 2026 07:21:32 +0000

After learning about Public Subnets and Private Subnets, the next question that comes across our mind is:

How does traffic actually move inside AWS?

Creating a subnet alone doesn't make your application accessible.

AWS needs networking concepts to decide:

Where the traffic comes from
Where the traffic should go
Whether internet access is allowed

This is where Internet Gateways (IGW) and Route Tables come into the picture.

Together, they act like roads and traffic signals for your AWS network.

Imagine a Real City

Think of your AWS VPC as a city.

Inside the city, we have:

Buildings = EC2 Instances
Neighborhoods = Subnets
Roads = Routes
City Gate = Internet Gateway

Without roads and a city gate:

Nobody can enter
Nobody can leave

AWS networking works in a similar way.

Real City

City
 ├── Buildings
 ├── Roads
 └── Main Gate

AWS Equivalent

VPC
 ├── EC2 Instances
 ├── Route Tables
 └── Internet Gateway

What is an Internet Gateway?

An Internet Gateway (IGW) is a VPC component that enables communication between:

Your AWS VPC
The Public Internet

It is the official entry and exit point for internet traffic.

Real-World Example

Imagine a shopping mall.

It has:

Shops inside
Customers outside

Customers can only enter through the main entrance gate.

Customers
     ↓
 Main Entrance
     ↓
 Shopping Mall

In AWS we can look the above situation as:

Internet
     ↓
Internet Gateway
     ↓
VPC

The Internet Gateway acts as the main entrance gate.

Without an Internet Gateway

Suppose you launch an EC2 instance. But there is no Internet Gateway attached.

EC2 Instance
    ↓
Public Subnet
    ↓
VPC

Result

❌ Users cannot access the application
❌ EC2 cannot browse the internet
❌ Software updates cannot be downloaded

Even though the EC2 instance exists, it is isolated from the internet.

When an Internet Gateway is Attached

Internet
     ↓
Internet Gateway
     ↓
VPC
     ↓
EC2

The VPC now has a connection to the outside world.

However, there is still one more requirement.

The traffic needs directions.

This is where Route Tables come in.

What is a Route Table?

A Route Table is a set of rules that tells AWS:

"Where should the traffic go?"

Think of it like Google Maps for network traffic.

When traffic arrives, AWS checks the Route Table and decides whether to:

Send traffic to an Internet Gateway
Send traffic to another subnet
Send traffic to another network

Real-World Example

Imagine you're driving a car.

When you reach an intersection, you see:

Go Left  → Airport
Go Right → City Center
Go Straight → Highway

Road signs tell you where to go.

A Route Table does the same thing for network traffic.

Understanding Routes

A route contains:

Destination → Target

Example:

0.0.0.0/0 → Internet Gateway

This means:

Any traffic going anywhere on the internet should be sent to the Internet Gateway.

What Does 0.0.0.0/0 Mean?

This confuses many beginners.

0.0.0.0/0

means:

Every possible IP address on the internet.

So this route means:

All Internet Traffic
          ↓
Internet Gateway

Complete Traffic Flow

Let's see what happens when a user opens a website.

Step 1

User enters:

www.example.com

Step 2

The request reaches AWS.

User
 ↓
Internet

Step 3

Traffic enters through the Internet Gateway.

User
 ↓
Internet
 ↓
Internet Gateway

Step 4

AWS checks the Route Table.

Internet Gateway
        ↓
    Route Table

Step 5

The Route Table sends traffic to the correct subnet.

Route Table
      ↓
Public Subnet

Step 6

Traffic reaches the EC2 instance.

Public Subnet
      ↓
EC2 Instance

Complete Flow

User
  ↓
Internet
  ↓
Internet Gateway
  ↓
Route Table
  ↓
Public Subnet
  ↓
EC2 Instance

Public Route Table Example

A Public Subnet becomes public because its Route Table contains a route to the Internet Gateway.

Destination	Target
VPC CIDR	Local
0.0.0.0/0	Internet Gateway

Diagram:

Public Subnet
       ↓
Route Table
       ↓
0.0.0.0/0
       ↓
Internet Gateway
       ↓
Internet

This allows:

Incoming internet traffic
Outgoing internet traffic

Important Thing to Remember

Many beginners think:

"If an EC2 is launched inside a public subnet, it automatically becomes public."

This is incorrect.

For an EC2 instance to be publicly accessible, it needs:

Requirement 1

The subnet must have a route:

0.0.0.0/0 → IGW

Requirement 2

An Internet Gateway must be attached.

Requirement 3

The EC2 instance must have a Public IP.

Requirement 4

The Security Group must allow access.

Only then can internet users reach the EC2 instance.

Private Subnet Route Table

A Private Subnet usually does not have a route to the Internet Gateway.

Example:

Destination	Target
VPC CIDR	Local

Notice:

0.0.0.0/0 → IGW

does not exist.

Result:

❌ No direct internet access
❌ Internet users cannot reach resources
✅ Better security

Real-World Architecture Example

Let's build a simple e-commerce website.

Public Layer

Load Balancer
Web Server

Private Layer

Database

Architecture:

Internet
    ↓
Internet Gateway
    ↓
Public Subnet
    ↓
Load Balancer
    ↓
Web Server
    ↓
Private Subnet
    ↓
Database

Why Keep the Database in a Private Subnet?

Imagine if the database was directly accessible from the internet.

Anyone could attempt:

Brute-force attacks
Unauthorized access
Data theft

Instead, we design the architecture like this:

Internet
    ↓
Web Server
    ↓
Database

Only the Web Server can communicate with the Database.

Users cannot directly reach it.

This is a core AWS security principle.

Public vs Private Subnet Visualization

                    Internet
                        │
                Internet Gateway
                        │
                 Route Table
                        │
          ┌─────────────┴─────────────┐
          │                           │
          ▼                           ▼

    Public Subnet              Private Subnet

          │                           │
          ▼                           ▼

      Web Server                 Database

Conclusion

Internet Gateway and Route Tables are the foundation of AWS networking.

In this article, we learned:

What an Internet Gateway is
Why it is required
What Route Tables are
How AWS routes traffic
Difference between Public and Private Subnets
Real-world examples of traffic flow
How web applications securely communicate with databases

Once you understand Internet Gateway and Route Tables, AWS networking becomes much easier to visualize.

Key Interview Question

What makes an EC2 instance publicly accessible?

The following four conditions must be met:

0.0.0.0/0 Route
        +
Internet Gateway
        +
Public IP
        +
Security Group Allow Rule
        =
Accessible from Internet

Remembering these four requirements helps answer many AWS networking interview questions.

In the next article, we'll explore:

Security Groups
Network ACLs (NACLs)
How AWS protects resources at the network level

Public vs Private Subnets in AWS Explained for Beginners

Vijaya Laxmi Kadham — Mon, 01 Jun 2026 06:02:26 +0000

When learning AWS networking, one of the most important concepts to understand is the difference between:

Public Subnet
Private Subnet

At first these terms may sound confusing. But once you understand how internet access works inside a VPC, the concept becomes very simple.

In this article, we will understand:

What a subnet is
What public and private subnets are
How internet access works in AWS
What a Load Balancer does
How routing works
Real-world architecture examples

What is a Subnet?

A subnet is a smaller network created inside a VPC.

When we create a VPC, AWS gives us a large IP address range called a CIDR Block.

Example: 192.168.0.0/16

Instead of using the entire IP block, we divide it into smaller sections called Subnets. This helps organize resources properly and improves security.

We mainly have two types of subnets:

Public Subnet
Private Subnet

Why Do We Need Different Subnets?

Think of a company office building:

Office Building
├── Reception Area (Public)
└── Server Room (Private)

Reception Area → Anyone can enter (customers, visitors, delivery people) → Similar to Public Subnet
Server Room → Only authorized employees can enter → Similar to Private Subnet

This is how AWS works. Not every application component should be exposed to the internet.

For example:

Users should access frontend applications
Databases should remain private
Backend services should stay protected

What is a Public Subnet?

A Public Subnet is a subnet that allows internet access.
Resources inside this subnet can communicate directly with the internet.

Examples:

Web Servers
Load Balancers

What is a Load Balancer?

A Load Balancer is a service that distributes user traffic across multiple servers.

Think of it like a traffic manager.

Users
↓
Load Balancer
↓
├── Server 1
├── Server 2
└── Server 3

This improves Performance, Availability, and Reliability.

In AWS, Load Balancers are placed inside a public subnet because users from the internet need to access them.

Real World Example of Public Subnet

Imagine you are hosting a shopping website: www.shopworld.com

Internet Users → Load Balancers → Web Servers

These resources need internet access to receive requests and send responses back to users.

How Public Subnets Get Internet Access?

AWS uses an Internet Gateway to connect resources to the internet.

Think of Internet Gateway as a gate between AWS Network and the Internet.

Flow:
Internet → Internet Gateway → Public Subnet

Understanding Route Tables

A Route Table decides where network traffic should go.

Public Subnet Route Example:

Destination: 0.0.0.0/0
Target: Internet Gateway

This route makes the subnet Public.

What is a Private Subnet?

A Private Subnet does not allow direct internet access. Resources inside it are hidden from the internet.

Examples:

Databases
Backend APIs

Why Private Subnets are Important?

Sensitive data should never be exposed publicly.

Examples: MySQL databases, Banking systems, Payment services.

Keeping them private improves security significantly.

Real World Example of Private Subnet

In a banking application bank.com, customers should never directly access:

Database servers
Account systems
Transaction services

So these are placed in Private Subnets.

Internet User
↓
Website
↓
Backend Application
↓
Database

Private Subnet Routing

Private subnet route tables usually don't contain a Route to internet gateway.

Example: No Route to Internet Gateway

Meaning: Internet access is blocked.

This prevents from direct communication from the internet.

Public vs Private Subnet Comparison

Feature	Public Subnet	Private Subnet
Internet Access	Yes	No
Directly Reachable	Yes	No
Used For	Web Applications, Load Balancers	Databases, Backend Applications
Security Level	Lower	Higher

Complete Real-World AWS Architecture

This is the most common architecture used in real AWS projects. It combines both Public and Private Subnets to create a secure and scalable application.

Conclusion

Public and Private Subnets are fundamental building blocks of secure and scalable AWS architecture.

Public Subnets allow resources to be accessed from the internet (like web servers and load balancers).
Private Subnets keep sensitive resources safe and hidden from the internet (like databases and backend applications).

By properly using Internet Gateway, Route Tables, and separating your resources into public and private subnets, you can build applications that are both highly available and secure.

Key Takeaways:

Always place internet-facing components in Public Subnets.
Keep databases and backend logic in Private Subnets.
Use Load Balancers in public subnets to distribute traffic efficiently.
This 3-Tier Architecture (Web → Application → Database) is one of the most commonly used patterns in real-world AWS projects.

Mastering Public and Private Subnets is a big step toward becoming confident in AWS networking.

In the next articles, we will learn about NAT Gateway (how private subnets can access the internet for updates), Security Groups, and Network ACLs.

What is VPC? Explained for Beginners

Vijaya Laxmi Kadham — Fri, 29 May 2026 04:44:56 +0000

AWS VPC (Virtual Private Cloud)

Introduction

If you are starting your AWS and Cloud journey, one of the most important concepts you will come across is VPC (Virtual Private Cloud).

When I first heard the term VPC, I was confused because AWS networking looked very complicated.

Terms like:

Subnets
CIDR Blocks
Public Networks
Private Networks

all sounded overwhelming.

But once I understood why VPC actually exists, things started making much more sense.

In this article, let us try to understand VPC in the simplest way possible.

Why Does VPC Exist?

Before understanding VPC, let us first understand the problem AWS was trying to solve.

In traditional environments, companies used to host their applications in their own physical data centers.

This required:

Buying Servers
Managing Networking
Handling Security
Maintaining Infrastructure
Monitoring Hardware Failures

This became difficult and expensive, especially when the application started growing.

Then cloud providers like AWS came into the picture and started providing infrastructure over the internet.

AWS built massive data centers across different regions around the world.

Inside these data centers, AWS provides virtual servers (EC2 Instances) to multiple companies to host their applications.

Now imagine:

Company A
Company B
Company C

all running applications on AWS infrastructure.

If everything existed in the same shared network, there would be:

Security Risks
No Isolation
No Proper Control Over Traffic

Companies need:

Their own private network
Controlled communication
Better security
Isolation from other companies

To solve this problem, AWS introduced VPC (Virtual Private Cloud).

What is VPC in AWS?

VPC stands for Virtual Private Cloud.

A VPC is your own isolated private network inside AWS where you can launch and manage your AWS resources securely.

Simple Analogy

Think of it like this:

AWS Cloud = A large apartment city

Your VPC = Your private apartment complex

Inside your apartment complex:

You decide who can enter
You decide how rooms are divided
You control security
You manage networking rules

Similarly in AWS:

VPC gives you control over networking
Isolates your application
Helps secure your infrastructure

Every company can create its own private network inside AWS without interfering with others.

Understanding Isolation in VPC

Let us imagine there are 3 companies using AWS infrastructure.

Without proper isolation:

Company A ➡️ Same Network ⬅️ Company B ⬅️ Company C

If one application gets compromised, there is a risk that others may also get affected.

To solve this problem, AWS creates isolated private networks called VPCs.

Now each company gets its own secure environment.

This isolation is one of the biggest reasons why VPC is important in AWS.

What is CIDR in VPC?

Whenever we create a VPC, we must define an IP address range for it.

This IP range is called a CIDR Block.

Example

192.168.0.0/16

This defines the range of IP addresses available inside the VPC.

Think of CIDR as defining the total land area available for your network.

Inside that range, we can create smaller sections called Subnets.

What are Subnets?

A subnet is a smaller network created inside a VPC.

Instead of putting all applications in one area, we divide the VPC into smaller sections for better organization and security.

Example

VPC
│
├── Subnet A
├── Subnet B
└── Subnet C

Each subnet gets a portion of the VPC IP address range.

This helps:

Organize applications
Separate workloads
Improve security
Control traffic flow

Public vs Private Subnets

Subnets are mainly divided into 2 types:

Public Subnet
Private Subnet

Let us understand both.

Public Subnet

A public subnet is a subnet that can communicate with the internet.

Resources inside public subnet usually include:

Load Balancers
Bastion Hosts
Public-facing applications

Example

Internet
   ⬇️
Internet Gateway
   ⬇️
Public Subnet

Public subnets are connected to the internet through something called an Internet Gateway.

Private Subnet

A private subnet does NOT allow direct internet access.

Resources inside private subnet usually include:

Databases
Internal Applications
Backend Services

Example

Private Subnet
      ⬇️
Database / Application

Private subnets are more secure because they are not directly exposed to the internet.

This is one of the most important security practices in cloud environments.

Here route table controls how the traffic moves between subnets and gateways.

Simple Real World Architecture

Here is a basic flow of how applications are commonly structured inside a VPC:

Internet
   ⬇️
Internet Gateway
   ⬇️
Load Balancer
   ⬇️
Private Subnet
   ⬇️
Application Server / Database

This architecture helps:

Keep applications secure
Control traffic properly
Isolate backend systems from direct internet access

Key Benefits of VPC

Some major benefits of VPC are:

Isolation between companies and applications
Better security
Full control over networking
Ability to create public/private networks
Improved scalability
Better traffic management

Conclusion

VPC is the foundation of AWS networking.

It allows organizations to create their own isolated and secure network inside AWS where they can safely run applications and services.

In this article, we understood:

Why VPC exists
Isolation in AWS
CIDR Blocks
Subnets
Public vs Private Subnet concepts

In the upcoming articles, we will dive deeper into:

Route Tables
Internet Gateway
Security Groups
NAT Gateway
NACLs and understand how networking works inside AWS in more detail. 🙋‍♀️

EC2 Beginner Guide: Launch Your First AWS Instance

Vijaya Laxmi Kadham — Thu, 28 May 2026 03:27:33 +0000

Introduction

In my previous IAM article we learnt basics of IAM and how to create Users, Groups and attach Policies. You can refer here: https://dev.to/kadhamvj23/aws-identity-and-access-management-explained-for-beginners-cn7

After setting up secure access to our AWS account using IAM, the next question we mostly have is where do we actually run our application?

The answer is Amazon EC2 - Elastic Cloud Compute.

EC2 is one of the most widely used AWS services and understanding it well is essential for anyone starting their cloud journey. In this article we will cover what EC2 is, why it exists, the different types of instances, pricing models, Regions and availability Zones and finally hands-on walk through of creating your first EC2 instance.

Breaking Down the Name -EC2

Let us understand what each word in the name actually means:

Elastic --> In AWS you will notice many services have this prefix "Elastic". The reason is simple. Whenever AWS provides a service that can be scaled up or scaled down based on our needs, that service is called Elastic. With EC2 you can increase resources when traffic is high and decrease them when the traffic is low.

So in simple terms EC2 = A virtual server on the cloud that you can resize anytime.

Cloud: EC2 runs on AWS's public cloud infrastructure, meaning the servers are owned and managed by Amazon across the world.

Compute: The word compute means you are asking AWS to provide you CPU, RAM and Disk - basically a virtual machine or server that can run your applications.

How does EC2 actually work?

When you request a Virtual server from AWS, here is what happens behind the scenes:

You request a virtual machine on AWS
                  ⬇️
request goes to a Hypervisor(a software layer 
sitting on top of physical servers that creates and manages VMs)
                  ⬇️
Hypervisor creates your VM
                  ⬇️
You get the access to your EC2 instance

You never touch any physical hardware. AWS manages all of that for you.

Why use EC2?

Imagine your company wants to host an application. The traditional approach would be:

Buy physical servers
Install a hypervisor
Create VMs
Provide access to employees
manage timely upgrades
Handle security patches
Deal with hardware failures

This sounds manageable for 10 servers. But imagine doing this for 1000s of servers. Your entire day as a system admin would be consumed just keeping things running -not building anything new.

AWS EC2 solves this entirely

Instead of managing physical hardware, you simply:

Go to AWS Console
Launch an EC2 instance in minutes
Pay only for what you use - PAYG
Let AWS handle all hardware maintenance, upgrades and security

AWS takes care of the physical infrastructure so you can focus on your actual work.

Key Concepts You must Know Before Creating EC2 Instance

1. AMI - Amazon Machine Image

Before launching an EC2 instance, you will need to choose an AMI. Think of it as the OS template for your server.

Example: Amazon Linux, Ubuntu, Windows, Red hat

2. Key-Pair

When you create an EC2 instance, AWS gives you a key-pair - a set of two keys(public and private) used to securely connect to your instance.

AWS keeps the public key.

You can download and keep the private key(.pem file)

Without this key, you can't SSH into your instance.

Think of this as a digital lock and key - AWS puts the lock on the server and gives you the only key.

3. Security groups:

A Security Group acts as a virtual firewall for your EC2 instance. it controls which traffic is allowed in and out.

We will understand more about this in future articles when we deep dive more into Security Groups and Networking.

4. EBS: Elastic Block Storage

Every EC2 instance needs storage. EBS is the hard disk attached to your EC2 instance where your data, OS files & application files are stored.

Just like EC2, EBS is also elastic in nature, that can increase and decrease the disk size anytime without stopping your instance.

Types of EC2 instances:

AWS offers 5 types of EC2 instances. You can choose based on what your application needs. The following are the types:

1. General Purpose: Best for balanced CPU, RAM and storage like web servers, small apps

2. Compute Optimized: best for High CPU performance like gaming servers

3. Memory Optimized: for large amounts of RAM like Big databases, data analytics

4. Storage Optimized: For High disk rea/write speed like data warehouses, log processing

5. Accelerated Computing: For GPU based tasks like machine learning.

Depending on your application requirement you pick the right instance type. For the learning purpose in this complete blog I will be using the general Purpose EC2 instance.

EC2 Pricing Models

This is very important and often comes up in AWS certifications:

1. On-Demand:

Pay per hour or per second
No commitment
best for: short term or unpredictable workloads
Most expensive per hour but most flexible.

2. Reserved Instances

You commit to using EC2 for 1 or 3 years
Get up to 75% discount compared to On-Demand
Best for steady, predictable workloads

3. Spot Instances

You bid for unused AWS capacity
Can be up to 90% cheaper than On-Demand
But AWS can terminate your instance with 2 mins notice if they need the capacity back.
Best for batch jobs, testing jobs, non critical tasks

4. Savings Plan

flexible pricing model
Commit to a specific amount of usage per hour
Applies across EC2, lambda and other services

Regions and Availability Zones

AWS has data centers spread across the world organized as:

Regions -- A geographical area like Mumbai, US East, Singapore. AWS has multiple regions across the world. You can choose a region closest to your users for low latency.

Availability Zones(AZs) -- Within each region there are multiple Availability zones. Each AZ is essentially a separate data center with its own power, cooling and networking. This means if one AZ goes down your application can still run from another AZ.

EC2 Best practices

Always attach a Security Group - never leave all ports open
Never loose your key pair - you cannot recover it.
Choose region closest to your uses.
Stop instances when not in use - you are charged for running time.

Hands-On: Launching an EC2 Instance and Deploying Jenkins on AWS

Now, let’s move towards the practical implementation by launching an EC2 **instance and **deploying Jenkins on it.

By the end of this lab, you will successfully deploy your first application on AWS EC2.

Step 1: Login to AWS Console

Open your AWS account and log in to the AWS Management Console.
In the search bar at the top, type EC2 and click on the EC2 service.
You will now be redirected to the EC2 Dashboard.

Step 2: Launch a New EC2 Instance

On the left-hand side panel:

Click on Instances
Then click on Launch Instance (top-right corner)
You will now enter the Launch Instance configuration page.

Step 3: Configure the EC2 Instance

1. Give Your Instance a Name: Under the Name and Tags section, provide a name for your instance. Example: My-First-Instance

2. Choose an Operating System: Under Application and OS Images (Amazon Machine Image) select the operating system.

For this practice, I selected: Ubuntu

3. Create a Key Pair: The Key Pair is extremely important because it is used to securely log in to your EC2 instance.

Click on Create new key pair
Give the key pair a name
Download the .pem file

Note: Keep this .pem file safe because it cannot be downloaded again.

And for now, we will not touch the security part and other parts, just keep it as it is and then click on "Launch Instance".

Step 4: Verify the Instance is Running

Once the instance is launched:

Open the instance
Ensure the Instance State is Running
Click on the Instance ID to view complete details.
We will use the Public IPv4 Address to access the server and application. Example: 32.197.45.191

Step 5: Connect to EC2 Instance Using SSH

Open your terminal.

Depending on your operating system, you can use:

Git Bash (Windows)
PuTTY
MobaXterm
Default Terminal (Mac/Linux)

For this practice, I will use Git Bash.

Navigate to the Download Folder: Move to the folder where the .pem file was downloaded like below image.

Connect to the EC2 Instance

Run the following command:

ssh -i test-user1.pem ubuntu@32.197.45.191

Step 6: Fix Permission Error for .pem File

While connecting, you may get an error like: " Permissions for 'test-user1.pem' are too open "

This happens because the .pem file contains sensitive credentials and requires restricted permissions.

Use the following command to change file permissions:

chmod 600

"chmod" command is used to change the permissions of the file.

Now reconnect:

ssh -i test-user1.pem ubuntu@32.197.45.191

You should now successfully log in to the EC2 instance.

Step 7: Verify Current User

To check the current logged-in user, type "whoami in the terminal.
The output will be "ubuntu"

Step 8: Switch to Root User (Optional)

To become the root user type:

sudo su -

Now you will have root access. As shown in below image.

Step 9: Update Packages

Before installing any software, always update the server packages.

If Logged in as Ubuntu User

sudo apt update

If Logged in as Root User, type "apt update"

Once this is done, lets now try to deploy an Jenkins application from here.

Step 10: Install Jenkins

Now let’s deploy an application on the EC2 instance.

We will install Jenkins.

Visit the official Jenkins website

Copy the Ubuntu installation commands from the website and execute them in the terminal.

Step 11: Verify Jenkins Service Status

After installation, check Jenkins status:

systemctl status jenkins

If Jenkins is not active, also if you are getting any error for inactive you can also check the java version, it works best with java 21 version. So if the java isn't in this version try updating the version.
Also restart the service:

systemctl restart jenkins

Then check the status again.

Step 12: Access Jenkins from Browser

Copy the Public IP Address from your EC2 instance.
Open a browser and access Jenkins using:

http://<Public-IP>:8080

Initially, the application may not open because port 8080 is blocked in the Security Group

Step 13: Configure Security Group for Jenkins

To allow access to Jenkins:

Open the EC2 Instance
Scroll down to the Security section
Click on the attached Security Group

Under Inbound Rules:

Click Edit Inbound Rules

Add a new rule with:

Type Port Range Source
Custom TCP 8080 Anywhere IPv4

Then click: Save Rules

Step 14: Open Jenkins Again

Now refresh the browser:

http://<Public-IP>:8080

Step 15: Retrieve Jenkins Initial Password

Run the following command inside the EC2 terminal:

cat /var/lib/jenkins/secrets/initialAdminPassword

Copy the password and paste it into the Jenkins browser page.

You will now enter the Jenkins dashboard.

Congratulations! 🎉🥳

You have successfully:

Launched your first EC2 instance
Connected to it using SSH
Managed secure access using a .pem key
Installed Jenkins
Configured Security Groups
Deployed and accessed your first application on AWS

I hope this article helped you in knowing the basics of EC2 and and also how to deploy an Application in EC2.

Let's meet in next article with another service of AWS!!!

AWS - Identity and Access Management Explained for Beginners

Vijaya Laxmi Kadham — Tue, 26 May 2026 15:32:32 +0000

Introduction

When you start your AWS journey, one of the first important services you will encounter is IAM - Identity and Access Management.

It may sound complex, but by the end of this article, you will understand exactly what IAM is, and why it exists, and how it works using a simple real-world example.

Why do we Need IAM - A Real World Example

Imagine you work at a hospital.

This hospital has many different areas like general ward, ICU, pharmacy, operation theatre and other record rooms where all patient files are stored.

Now not everyone in the hospital can walk into every area:

A receptionist can access front desk but not Operation theatre
A nurse can access ward pharmacy but not record rooms
A doctor can access most areas but still not the hospital's financial vault.
Only the hospital director has access to everything.

This is done for security and safety. If everyone has access to everything, someone could accidentally or intentionally misuse the sensitive information.

AWS **IAM **works exactly the same way but for your cloud resources instead of a hospital.

What is AWS IAM?

IAM stands for Identity and Access Management.

It is a free AWS service that helps you control:

Who can access your AWS account
What they can do inside it

When you first create an AWS account you will get a root user - this is like the hospital director who has access to everything. But giving everyone root access is extremely dangerous.

IAM **allows you to create separate identities with **only the permissions they need - nothing more, nothing less.

The 4 Core Components of IAM

**IAM **is built on 4 main building blocks:

1.Users: A user represents a single person that needs access to your AWS account.

For example: A developer named Ravi who joins your company needs access to AWS. You create an IAM User for Ravi. set a password and he can now login.

2.Policies: Creating a user alone isn't enough. You will also need to define what that user is allowed to do.

This is handled by Policies - they are JSON documents that defines permissions.

For example, you can create a policy that says:

✅ Ravi can read files from S3
❌ Ravi cannot delete EC2 instances
❌ Ravi cannot access billing

You then attach this policy to the user.

Think of policy as the access card rules - It defines which door you can open.

3.Groups:

Now imagine your company is growing fast. Every week new developers. testers and others are joining. Creating individual policies for each person manually is time consuming and error prone.

This is where **Groups **come in.

A Group is a collection of users that share the same permissions.

Here is how it works in reality:

You create a group called "Developers" and attach developer policy to it.
You create group called "QA testers" and attach testing policy to it.
You create a group called "DBAdmins" and attach Database policy to it.

Now whenever a new employee joins, you simply:

Create their IAM user.
Add them to the correct group
They automatically get all the right permissions.

No more manually attaching policies one by one.

4.Roles: Roles are similar to users, but with one key difference - Roles are not assigned to a specific person permanently.

Roles are mostly used for temporary access or giving AWS services permissions to interact with each other.

Example: Your app running on an EC2 instance needs to read files from S3. Instead of creating a user and hardcoding credentials, you can create an IAM Role with S3 read permissions and attach it to the EC2 instance.

Think of Role as a temporary visitor pass - given for a specific purpose and a specific time.

How It all works Together - Real Workflow

Here is how a real company uses IAM when a new employee joins:

New Employee joins the company
              ⬇️
They raise a request mentioning their name and which team they belong to
              ⬇️
DevOps engineer creates an IAM user
              ⬇️
Adds the user to the correct group
              ⬇️
User automatically gets the right policies.
              ⬇️
DevOps engineer share the login credentials with the employee
              ⬇️
Employee logins with only the access they need

This process keeps your AWS environment secure, organized and scalable.

IAM Best Practices

Before we proceed further, here the important best practices every AWS user should follow:

Never use your root account for daily tasks - create an IAM admin user instead.
Enable MFA on for all users especially for root users.
Follow least Privilege - give users only the permissions they absolutely need.
Use Groups instead of attaching policies to individual users.
Review permissions regularly and remove unused access.

Hands On for IAM Service:

Now that we understand the theory, let me walk you through what I actually did in the AWS console step by step.

Step 1: Accessing IAM Dashboard

After logging in to my AWS account with root user credentials, I searched for IAM in the search bar and opened the IAM Dashboard. This is where you can see a full summary of your users, groups, policies and roles.

Step 2: Creating an IAM User

I clicked on IAM Users from the left sidebar and clicked on Create User.

Here I filled in:

Username: I gave a name like "test-user"
Access Type: I selected the console access so the user can login
Password: Set a auto password.

Step 3: Creating a Group, attaching policies

Next I went to IAM User groups -> click on Create Group and created a group called "DevOps" and clicked on create group.

Then I went to IAM user groups and then clicked on the newly created group. Then I clicked on "permissions" and here I attached the policies.

Step 4: Adding user to the Group

Finally I added my newly created user "test-user" into "DevOps" group.

Then I went to IAM user groups and then clicked on the newly created group. Then I clicked on "users" and here I added the user.

As soon as I did this, the user automatically got all the policies attached to that group - without me adding manually.

This was all for IAM service in AWS. Hope the article helped you to understand the concept. Let's meet with another service soon...🥳

What is Cloud Computing and AWS

Vijaya Laxmi Kadham — Sun, 24 May 2026 18:30:00 +0000

I recently started getting interested in cloud technology and wanted to understand how it actually works. I have been working in IT support for about 2.5 years and I want to move into cloud tech side. So I decided to start learning AWS and document everything I learn here. This is Day 1 of this journey.

What is Cloud Computing?

Before cloud came into picture, companies used to buy their own physical servers and store everything in their own office or data center. This was expensive and hard to manage.

Cloud computing means instead of owning a server yourself, you rent computing power, storage and other services over the internet from companies like Amazon, Microsoft, or Google. And here you only pay for what you use( Pay-As-You-Go).

Think of it like electricity - you don't build your own power plant at home, you just use the electricity and pay the bill. Cloud works in the saw way for the technology.

What is AWS?

AWS stands for Amazon Web Services. It is the cloud platform made by Amazon and it currently the biggest cloud provider in the world. It offers more than 200+ services including storage, servers, databases, AI tools and many more services. Many big companies like Netflix, Airbnb uses AWS to run their systems.

Today I created my AWS free account. You can type AWS account creation and it will take you the page. During the sign-up process it asks for debit or credit card but don't worry it will not charge you as long as you stay within the free tier limits.

The free tier gives you access to many services for 6 months without any cost which is great for learning and building projects.

Tomorrow I will start with AWS Cloud course and begin learning about the core services. I will write about everything I learn here for all the future references and also if anyone wants to learn AWS from scratch they can follow along too 🤖