DEV Community: Simran Rajoriya

AMI vs EBS Snapshot: Which One Should We Use for EC2 Recovery?

Simran Rajoriya — Sun, 11 Oct 2026 15:58:18 +0000

I have learned about AMIs and EBS snapshots. If I need to launch a replacement EC2 instance after a failure, when should I use an AMI, and when is an EBS snapshot enough?

What Happens If an AWS EC2 Instance Suddenly Fails?

Simran Rajoriya — Sun, 11 Oct 2026 15:54:55 +0000

If an EC2 instance hosting a website suddenly fails, how would you restore the application with minimum downtime? Would you use an AMI, Auto Scaling, or both?
Tags: aws cloud devops

Why Is AWS Classic Load Balancer (CLB) Used Less Today? CLB vs ALB vs NLB

Simran Rajoriya — Sun, 11 Oct 2026 15:50:20 +0000

While learning AWS, I explored the Classic Load Balancer (CLB) and discovered why modern applications often use Application Load Balancer (ALB) or Network Load Balancer (NLB) instead.

Let's understand the differences! 🚀

What Is a Classic Load Balancer (CLB)?

Classic Load Balancer is an older-generation AWS load balancing service that distributes incoming traffic across registered EC2 instances.

For example, when multiple users access a website, CLB distributes their requests across available backend instances instead of sending all traffic to a single server.

Traffic Flow:

Clients → Internet → CLB → EC2 Instances → Response to Clients

This helps improve application availability and traffic distribution.

Why Is CLB Used Less Today?

CLB is still available in AWS, but it has fewer advanced capabilities than newer load balancers.

Here are the main reasons:

Limited routing features: CLB does not offer the advanced host-based and path-based routing available with ALB.

Modern application requirements: ALB provides features suitable for web applications, APIs, and microservices.

Layer 4 traffic needs: NLB is designed for TCP, UDP, and TLS traffic use cases.

Architecture flexibility: ALB and NLB provide different capabilities that can better match modern application requirements.

CLB vs ALB vs NLB

Classic Load Balancer (CLB)

Older-generation load balancer.

Supports basic load balancing for applications using HTTP/HTTPS and TCP/SSL.

Useful for certain existing legacy applications.

Application Load Balancer (ALB)

Operates at Layer 7 of the OSI model.

Supports HTTP/HTTPS traffic.

Supports path-based and host-based routing.

Suitable for web applications, APIs, and microservices.

Network Load Balancer (NLB)

Operates primarily at Layer 4.

Supports TCP, UDP, and TLS traffic use cases.

Supports static IP addresses.

Suitable for applications that require high performance and low-latency network traffic handling.

Real-World Example

Imagine an e-commerce website with three services:

/products → Product service

/payments → Payment service

/users → User service

With ALB, we can configure path-based routing to forward requests to the appropriate target groups.

For example:

Client → ALB → /products → Product EC2 instances

Client → ALB → /payments → Payment EC2 instances

This helps organize traffic routing for applications with multiple services.

Which Load Balancer Should We Choose?

Choose ALB for HTTP/HTTPS applications that need advanced routing.

Choose NLB for suitable Layer 4 workloads that require TCP/UDP support or static IP addresses.

Consider CLB when maintaining an existing legacy application that already meets its requirements.

For new applications, AWS generally recommends considering ALB or NLB according to the workload.

What I Learned

This exploration helped me understand that load balancing is not just about distributing requests. It is also about choosing the right architecture based on application requirements, traffic patterns, routing, and scalability.

I'm continuing to learn AWS through hands-on practice and exploring how EC2, load balancers, and Auto Scaling work together to build highly available applications.

What would you choose for a new AWS web application: ALB or NLB? Share your thoughts in the comments!

AWS #CloudComputing #AmazonEC2 #LoadBalancing #CLB #ALB #NLB #DevOps #CloudEngineering #LearningInPublic

Understanding Classic Load Balancer (CLB) in AWS 🚀

Simran Rajoriya — Sun, 11 Oct 2026 15:47:30 +0000

While learning AWS and cloud computing, I explored how a Classic Load Balancer (CLB) distributes incoming traffic across multiple EC2 instances.

🔹 What is a Classic Load Balancer?

A Classic Load Balancer (CLB) is an AWS load balancing service that distributes incoming requests from multiple clients across registered EC2 instances.

When clients send requests over the internet, the load balancer forwards those requests to healthy backend servers and returns the responses to the clients.

🔹 How Does It Work?

The traffic flow looks like this:

Clients → Internet → Classic Load Balancer → EC2 Instances → Response to Clients

For example, imagine an application running on two EC2 instances:

EC2 Instance 1: Handles some incoming requests.

EC2 Instance 2: Handles other incoming requests.

Classic Load Balancer: Distributes traffic across registered instances and avoids routing requests to instances identified as unhealthy.

This helps improve application availability, fault tolerance, and traffic distribution.

🔹 Benefits of Load Balancing

✅ Distributes incoming traffic across multiple servers.

✅ Improves application availability.

✅ Supports fault tolerance by routing traffic to healthy instances.

✅ Helps applications handle multiple client requests.

🔹 CLB vs ALB vs NLB

CLB is the older generation of AWS load balancers. For new applications, AWS generally recommends choosing a load balancer based on the application's requirements:

Classic Load Balancer (CLB): Older-generation load balancer.

Application Load Balancer (ALB): Best suited for HTTP/HTTPS applications and Layer 7 routing.

Network Load Balancer (NLB): Best suited for Layer 4 TCP/UDP/TLS traffic and applications requiring high performance.

🔹 What I Learned

I learned how a load balancer acts as an entry point for incoming application traffic and distributes requests across multiple backend servers instead of relying on a single EC2 instance.

This is an important concept for building highly available and scalable applications on AWS.

I'm continuing to explore AWS services and strengthen my cloud computing skills through hands-on learning.

AWS #CloudComputing #AmazonEC2 #LoadBalancing #CLB #ALB #NLB #CloudEngineering #LearningInPublic

Can Multiple EC2 Instances Use the Same EBS Volume? 🤔

Simran Rajoriya — Sun, 04 Oct 2026 04:19:35 +0000

While learning AWS, I came across an interesting question:

Can one EBS volume be attached to multiple EC2 instances at the same time?

The short answer is:

Normally, one EBS volume is attached to one EC2 instance. But AWS provides EBS Multi-Attach for specific use cases.

🔹 Normal EBS Attachment

In the standard setup, an EBS volume is attached to a single EC2 instance:

    EBS Volume
         |
         |
      EC2-1

For example, if I create an EBS volume and attach it to EC2-1, that volume is being used by that instance.

I cannot simply attach the same volume to EC2-2 and start using it simultaneously.

🔹 What about Multiple EC2 Instances?

AWS provides a feature called EBS Multi-Attach.

With Multi-Attach, a supported EBS volume can be attached to multiple EC2 instances simultaneously.

          EBS Volume
              |
    ┌─────────┼─────────┐
    |         |         |
  EC2-1     EC2-2     EC2-3

This can be useful for applications that are specifically designed to handle shared block storage.

Important conditions

EBS Multi-Attach has some limitations:

It is available only for supported EBS volume types.

The EC2 instances must be in the same Availability Zone.

The application/filesystem must be designed to safely handle concurrent access.

Simply mounting the same normal filesystem from multiple EC2 instances can result in data corruption.

🔹 What if EC2 Instances Are in Different AZs?

This is an important AWS concept.

An EBS volume is tied to a specific Availability Zone.

For example:

Availability Zone 1a

EBS Volume
|
EC2-1

Availability Zone 1b

  EC2-2

The EBS volume from 1a cannot directly be attached to an EC2 instance in 1b.

If I need shared storage across multiple Availability Zones, I would generally consider services such as Amazon EFS instead of trying to share a single EBS volume.

🔹 EBS vs EFS

This helped me understand the difference:

Requirement

Better Choice

Block storage for one EC2

EBS

Shared file storage

EFS

Multiple EC2 instances across AZs

EFS

Specific multi-instance block-storage use case

EBS Multi-Attach

💡 My Key Learning

The important thing I learned is that EBS is not the same as shared storage by default.

A normal EBS volume is designed to be attached to one EC2 instance, while EBS Multi-Attach provides a specialized way to attach supported volumes to multiple instances in the same Availability Zone.

For highly available architectures, choosing the correct storage service is just as important as choosing the correct compute service.

Architecture Thinking

Instead of asking:

"How can I attach one EBS to multiple EC2 instances?"

It's better to ask:

"Do my EC2 instances actually need shared block storage, or do I need a shared file-storage service?"

That mindset helps in designing better AWS architectures. 🚀

AWS #CloudComputing #EC2 #EBS #EFS #AWSSolutionsArchitect #DevOps #CloudEngineer #LearningAWS #100DaysOfCloud

Understanding Elastic IP in AWS EC2

Simran Rajoriya — Sun, 04 Oct 2026 03:51:24 +0000

While working with Amazon EC2, I noticed something interesting about public IP addresses.

I launched an EC2 instance and checked its public IP:

Public IP: 13.x.x.x

Then I stopped the instance and started it again.

After restarting, I noticed that the public IP had changed:

Old IP: 13.x.x.x
New IP: 54.x.x.x

This made me understand an important AWS concept:

The default public IPv4 address of an EC2 instance is not persistent.

🔹 So, how can we keep the same public IP?

AWS provides Elastic IP, which is a static public IPv4 address.

I allocated an Elastic IP and associated it with my running EC2 instance.

After that, I stopped the instance and started it again.

This time:

Before Stop: 3.x.x.x
After Start: 3.x.x.x ✅

The IP remained the same.

Architecture

         AWS
          |
    Elastic IP
      3.x.x.x
          |
          ▼
    EC2 Instance
   ┌─────────────┐
   │ Web Server  │
   └─────────────┘

🔹 What did I learn?

The key difference is:

Default Public IP

Automatically assigned by AWS

Can change when an EC2 instance is stopped and started

Not suitable when a fixed public IP is required

Elastic IP

Static public IPv4 address

Can be associated with an EC2 instance

Remains the same even after stop/start

Can also be disassociated and associated with another resource when required

🔹 How is it used in real-world environments?

Elastic IPs are useful when a service needs a predictable public IP.

For example:

IP whitelisting for external APIs

Bastion/Jump hosts

NAT Gateway for fixed outbound IP

Applications where a fixed public IP is specifically required

However, in a production architecture using Application Load Balancer + Auto Scaling, we generally don't assign an Elastic IP to every EC2 instance.

Instead:

         Internet
             |
             ▼
    Application Load Balancer
             |
      ┌──────┴──────┐
      ▼             ▼
    EC2-1         EC2-2
      │             │
      └──────┬──────┘
             ▼
      Auto Scaling

The Load Balancer provides the stable entry point, while EC2 instances can scale in and out behind it.

💡 My Key Takeaway

This hands-on experiment helped me understand why AWS provides different types of IP addressing and when a static public IP is actually required.

Need a fixed public IP → Elastic IP
Need scalable public access → Load Balancer
Need fixed outbound IP for private resources → NAT Gateway + Elastic IP

Learning AWS concepts becomes much clearer when you actually test them instead of only reading about them.

AWS #AWSCloud #EC2 #ElasticIP #CloudComputing #DevOps #CloudEngineer #LearningAWS #100DaysOfCloud

Automating Docker Installation on an AWS EC2 Instance Using User Data

Simran Rajoriya — Sun, 04 Oct 2026 03:02:22 +0000

Automating Docker Installation on an AWS EC2 Instance Using User Data 🚀

While working with AWS EC2, I wanted to automate the Docker installation process instead of connecting to the instance and installing Docker manually.

The goal was simple:

Launch EC2 → Run User Data → Install Docker → Start Nginx Container → Access it using Public IP

🔹 The Challenge

Initially, I used this User Data script:


bash
#!/bin/bash

dnf update -y
dnf install -y docker

systemctl start docker
systemctl enable docker

usermod -aG docker ec2-user

systemctl restart docker

But my EC2 instance was running Ubuntu.
So Docker was not installed because dnf is used with distributions such as Amazon Linux, while Ubuntu uses apt.
When I tried checking Docker, I got:
docker: command not found

🔹 The Solution
I created a new Ubuntu EC2 instance and used the correct User Data script:
#!/bin/bash

apt update -y
apt install -y docker.io

systemctl start docker
systemctl enable docker

usermod -aG docker ubuntu

docker run -d -p 80:80 nginx

What does this script do?
- apt update → Updates package information
- apt install docker.io → Installs Docker
- systemctl start docker → Starts Docker
- systemctl enable docker → Starts Docker automatically after reboot
- usermod -aG docker ubuntu → Adds the Ubuntu user to the Docker group
- docker run -d -p 80:80 nginx → Starts an Nginx container and maps port 80
🔹 Security Group Configuration
I also allowed HTTP traffic through port 80:
Type: HTTP
Protocol: TCP
Port: 80
Source: 0.0.0.0/0

🔹 Testing
After launching the instance, I copied the Public IPv4 address and opened it in a new browser tab:
http://<EC2-Public-IP>

And finally, I got:
Welcome to nginx! 🎉
This confirmed that the complete flow was working:
AWS EC2
   ↓
User Data
   ↓
Docker Installation
   ↓
Nginx Container
   ↓
Port 80
   ↓
Security Group
   ↓
Public IP
   ↓
Nginx Welcome Page

🔹 What I Learned
This small hands-on task helped me understand an important AWS concept:
User Data can automate the initial configuration of an EC2 instance during launch.
I also learned that the User Data script must match the operating system.
For example:
Amazon Linux → dnf
Ubuntu → apt
The biggest learning for me was that a small difference in the operating system can make an automation script fail.
Instead of manually installing Docker every time, User Data allows the setup to happen automatically when the instance starts.
![ ](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/2ods8hbb1yrljqyzp5j1.png)

AWS Question That Made Me Think About Cloud Architecture

Simran Rajoriya — Fri, 02 Oct 2026 17:59:38 +0000

While learning AWS, I had an interesting question:

Suppose in the Mumbai Region (ap-south-1), there are three Availability Zones:

ap-south-1a

ap-south-1b

ap-south-1c

If I create many EC2 instances and they are launched in ap-south-1a, and many other users also launch instances in the same AZ, then:

❓ Why doesn't AWS automatically move instances to other AZs?
❓ What is the purpose of multiple Availability Zones?

My Understanding

AWS does not automatically shift existing EC2 instances from one AZ to another because the Availability Zone is part of the infrastructure design chosen by the user.

An EC2 instance is launched inside a specific subnet, and that subnet belongs to a specific AZ.

The AWS Solution

For High Availability and Fault Tolerance, AWS provides:

✅ Multiple Subnets across different AZs
✅ Application Load Balancer (ALB)
✅ Auto Scaling Groups (ASG)

Example architecture:

Internet → ALB → Auto Scaling Group → EC2 Instances in AZ-1a, AZ-1b, and AZ-1c

This ensures:

High Availability

Fault Tolerance

Better Traffic Distribution

Automatic Scaling

Key Learning

AWS does not automatically redesign our architecture. As cloud engineers, we must design applications across multiple Availability Zones for reliability and scalability.

Internet
|
↓
ALB
/ | \
1a 1b 1c
| | |
EC2 EC2 EC2

AWS #CloudComputing #EC2 #AutoScaling #LoadBalancer #CloudArchitecture #DevOps #LearningInPublic

AWS IAM: What I Learned About Identity and Access Management

Simran Rajoriya — Fri, 02 Oct 2026 16:28:18 +0000

While learning AWS, I recently started exploring IAM (Identity and Access Management).

At first, IAM sounded like another complicated AWS service. But after understanding the basic concept, I realized that it's actually about one simple question:

Who can access my AWS resources, and what are they allowed to do?

So, what exactly is IAM?

IAM is an AWS service that helps us manage users and control access to AWS resources.

For example, imagine you're working on a project with a team. You probably wouldn't give everyone access to everything.

One person might need to work with EC2, another might need access to S3, while an administrator may need access to almost everything.

That's where IAM comes in.

The 4 important IAM concepts I learned

IAM User 👤

An IAM user represents a person or identity that needs access to AWS.

For example:

Simran → Developer

Instead of giving every user complete access, we can give them only the permissions they need.

IAM Group 👥

A group is simply a way to organize users who need similar permissions.

For example:

Developers
├── Simran
├── Saif
└── Priya

If all developers need similar permissions, we can manage those permissions through the group.

IAM Policy 📜

This is where we define what an identity is allowed or not allowed to do.

For example, a policy could allow a user to start and stop EC2 instances.

So basically:

Policy = Rules that define permissions.

IAM Role 🔑

This was one of the concepts I found especially useful.

An IAM role allows AWS services to access other AWS resources securely.

For example, suppose an EC2 instance needs to read files from an S3 bucket.

Instead of putting AWS access keys directly on the EC2 instance, we can use:

EC2
↓
IAM Role
↓
IAM Policy
↓
S3

This provides a much better way to manage permissions.

🔐 One important concept: Least Privilege

Another thing I learned is the Principle of Least Privilege.

It simply means:

Give a user or service only the permissions they actually need.

For example, if someone only needs to start and stop EC2 instances, there's no reason to give them full administrator access.

What I'm taking away from IAM

Before learning IAM, I mostly thought about AWS services like EC2, S3 and VPC as separate services.

Now I'm starting to understand that security and permissions are equally important when building anything on AWS.

I'm currently learning AWS step by step and trying to understand these concepts through hands-on practice rather than just memorizing definitions.

One concept at a time. 🚀

AWS #IAM #CloudComputing #DevOps #AWSCloud #CloudSecurity #LearningInPublic

cloudcomputing

Simran Rajoriya — Sun, 27 Sep 2026 06:06:08 +0000

If you're just starting your journey into AWS and DevOps, understanding a few core concepts first will make everything else — EC2, S3, VPC — click into place much faster. Here's a breakdown of the fundamentals every beginner should know.

What Is Cloud Computing, Really?

At its core, cloud computing means using computing resources — servers, storage, databases, networking — over the internet, instead of owning and maintaining your own physical hardware.

Think of it like electricity. You don't build your own power plant to light your house; you plug in and pay for what you use. Cloud computing works the same way: you "plug into" AWS's infrastructure and pay only for what you consume.

Traditional setup: Buy servers, build a data center, hire a team to maintain it — expensive and slow to scale.
Cloud setup: Rent what you need from a provider like AWS — fast, flexible, and billed on a pay-as-you-go basis.

Understanding IaaS, PaaS, and SaaS

Cloud services come in three main flavors, based on how much you manage versus how much the provider handles for you:

Model What You Get Example Who Manages What
IaaS (Infrastructure as a Service) Raw building blocks — VMs, storage, networking AWS EC2, S3 You manage the OS, runtime, and apps; AWS manages the hardware
PaaS (Platform as a Service) A ready platform to deploy your code on AWS Elastic Beanstalk, Heroku You just deploy code; the provider handles the rest
SaaS (Software as a Service) A fully built, ready-to-use application Gmail, Dropbox, Salesforce You just use it — nothing to manage

A simple way to remember it: IaaS hands you bricks to build a house, PaaS gives you a house frame ready for furnishing, and SaaS hands you a fully furnished apartment.

Public, Private, and Hybrid Cloud

These describe where your cloud infrastructure lives:

Public Cloud — Shared infrastructure run by providers like AWS, Azure, or GCP. Cost-effective and scalable; most companies run here.
Private Cloud — Dedicated infrastructure for a single organization, offering more control and security, but at a higher cost.
Hybrid Cloud — A mix of both. Sensitive data stays in a private environment, while scalable workloads run on the public cloud. Banks and healthcare companies often use this model.
AWS Global Infrastructure

AWS's physical footprint spans the globe, organized into three layers:

Regions — A geographic area (e.g., Mumbai = ap-south-1, N. Virginia = us-east-1). Each region operates independently, and data typically stays within the region it's stored in — important for compliance and latency.
Availability Zones (AZs) — Each region contains multiple AZs — physically separate data centers with their own power, cooling, and networking. If one AZ fails, others keep running, which is the foundation of high availability.
Edge Locations — Smaller sites, even more numerous than regions, positioned close to end-users. These power services like CloudFront (CDN), delivering content faster by caching it closer to users.

The hierarchy: Region (broad geographic area) → Availability Zone (data centers within a region) → Edge Location (closest point to the user).

The Shared Responsibility Model

This is one of the most important — and most tested — AWS concepts. It defines where AWS's security responsibilities end and yours begin.

AWS handles "Security OF the Cloud": physical data centers, hardware, networking infrastructure, and virtualization.
You handle "Security IN the Cloud": OS patching, firewall/security group configuration, data encryption, IAM permissions, and your application's own security.

Example: If you launch an EC2 instance, AWS ensures the physical server is safe and always available — but if you leave a weak password or misconfigure a security group, that's on you.

The split shifts depending on the service: with IaaS (like EC2), you carry more responsibility; with SaaS, AWS carries more.

Cloud Computing Fundamentals — Access the World Without Buying Hardware

Simran Rajoriya — Sun, 27 Sep 2026 05:47:42 +0000

When I first heard the term "cloud computing," I honestly thought it meant your data gets stored somewhere literally in the clouds. Turns out, the reality is a bit more boring but way more powerful.

In simple words — cloud computing means using resources like servers, storage, and databases over the internet, without buying your own hardware. Companies like AWS or Azure basically "rent" out these resources to you. And the best part? You only pay for what you actually use — just like your electricity bill. Didn't run the AC all month? Lower bill. Cloud works the exact same way.

Think about how things used to work traditionally: if a company wanted to launch an app, they'd first have to buy physical servers, build an entire data center, and then hire a separate team just to maintain it. It was expensive and slow — need to scale? Order new servers, wait for delivery, install them.

Cloud got rid of this entire problem. Now, even a startup can sit in their bedroom, create an AWS account, and spin up a server in minutes. Traffic spikes? Scale up with one click. Traffic drops? Scale down and save money.

When I started my DevOps roadmap, this was the first concept I made sure to get clear — because AWS, Docker, Kubernetes, all of it is built on this foundation. If the basic "why cloud" doesn't make sense, everything else just feels like a bunch of tools with no real purpose behind them.

Launching an EC2 Instance

Simran Rajoriya — Sat, 14 Mar 2026 02:49:06 +0000

What is Amazon EC2?
Amazon EC2 stands for Elastic Compute Cloud.It is a service provided by AWS that allows users to create virtual servers in the cloud.

Steps to Launch an EC2 Instance
Step 1: Login to AWS Console

First, login to the AWS Management Console.
After login, go to the search bar and type EC2.
Click on EC2 service to open the dashboard.

Step 2: Launch Instance

1.Inside the EC2 dashboard, click on Launch Instance.
2.This will start the process of creating a new virtual

server.

Step 3: Choose Instance Type

1.Next step is selecting the instance type.
2.t2.micro or t3.micro
(These are free-tier eligible instances.)

Step 4: Configure Key Pair

1.Now you need to create a key pair.
2.This key pair is used to securely connect to your EC2 instance.
(Download the key pair file and keep it safe.)

Step 5: Configure Security Group

In this step, you allow network access.
1.SSH (port 22) for connecting to server
2.HTTP (port 80) if you want to host a website

Step 6: Launch the Instance

Now click on Launch Instance.
(After a few seconds your EC2 instance will start running.)

Step 7: Connect to the Instance

Go to the EC2 dashboard and select your instance.
Click Connect and follow the instructions to connect using SSH.

Now your cloud server is ready to use.