The OpsVerse with Apurv

🚀 Terraform Series – Day 8

Gujjar Apurv — Mon, 13 Apr 2026 03:00:00 GMT

Automating AWS EC2 Setup with Terraform and user_data

Welcome back to our Terraform journey. In infrastructure as code, setting up a server is just the beginning. After your EC2 instance is running, you need to set it up, install what it needs, and start your apps. Doing this by hand goes against the idea of automation.

In this post, we will demonstrate how to completely automate your server bootstrapping process using Terraform and the AWS user_data feature.

🎯 Objective

By the end of this guide, you will learn how to automatically install and configure an Nginx web server on a newly provisioned AWS EC2 instance using a Terraform user_data script.

🧩 Step 1: Understanding the Power of `user_data`

The Problem with Manual Configuration

Imagine you just used Terraform to spin up a fresh EC2 instance. Without an automation script, your next steps would look like this:

SSH into the instance.
Manually run package updates.
Install Nginx.
Start the service.
Create a custom HTML page.

This approach is time-consuming, prone to human error, and most importantly, not scalable. If you need to spin up 100 web servers behind a load balancer, logging into each one manually is impossible.

The Solution: Bootstrap Scripts

AWS provides a feature called user_data that allows you to pass a script to your instance at launch.

✔️ Runs automatically the very first time the instance boots.
✔️ Fully automates software installation and configuration.
✔️ Scales infinitely across as many instances as you deploy.

In short: user_data is your EC2 bootstrapping engine.

📄 Step 2: Create the Bootstrapping Script (`nginx.sh`)

First, we need to define the commands we want our server to run on startup. We will create a simple bash script that installs Nginx and creates a custom landing page.

Create a new file named nginx.sh:3

touch nginx.sh

Add the following content to the file:-

#!/bin/bash

# Update package lists
sudo apt-get update

# Install Nginx silently (-y prevents the prompt)
sudo apt-get install nginx -y

# Start the Nginx service
sudo systemctl start nginx

# Enable Nginx to start automatically if the server reboots
sudo systemctl enable nginx

# Create a custom HTML landing page
echo " Terraform testing with scripting " > /var/www/html/index.html

🔗 Step 3: Attach the Script in Terraform

Now, we need to tell Terraform to pass this script to our EC2 instance during creation. We do this by utilizing the file() function within the user_data argument of our aws_instance resource.

Open your ec2.tf file and configure your instance block:-

resource "aws_instance" "my_instance" {
  ami           = var.ec2_ami_id
  instance_type = var.ec2_instance_type

  # Attach your SSH key pair
  key_name = aws_key_pair.my_key.key_name

  # Attach the security group (make sure port 80 is open!)
  vpc_security_group_ids = [aws_security_group.my_groups.id]

  # Inject the bootstrap script here
  user_data = file("nginx.sh")

  # Define root storage
  root_block_device {
    volume_size = var.ec2_root_storage_size
    volume_type = "gp3"
  }

  tags = {
    Name = "terraform-ec2-nginx"
  }
}

💡

Note: Using file("nginx.sh") keeps your Terraform code clean by separating the bash logic from the HCL infrastructure definitions.

⚙️ Step 4: Execute the Pipeline

With the script created and Terraform configured, it's time to deploy. Run the following commands in your terminal:

Bash

terraform init
terraform apply -auto-approve

What happens internally?

Once you hit apply, an elegant automated workflow kicks off:

Infrastructure Provisioned: Terraform calls the AWS API to launch a new EC2 instance.
Script Passed: The contents of nginx.sh are passed to the instance metadata.
Bootstrapping Execution: As the EC2 instance boots up, the OS executes the script as the root user.
App Deployed: Packages are updated, Nginx is installed, the service is started, and your custom HTML page is generated.

Within minutes, you can grab the public IP of your new EC2 instance, paste it into your browser, and see your custom HTML page—zero SSH required.

🧪 Testing: Verify NGINX on EC2 Instance

After provisioning the EC2 instance using Terraform, we need to test whether NGINX is properly installed and running.

🔹 Step 1: Connect to EC2 via SSH

ssh -i "your-key.pem" ubuntu@

✔ Replace:

your-key.pem → your private key
→ instance public IP

🔹 Step 2: Check NGINX Status

sudo systemctl status nginx

✔ Expected Output:

active (running) → ✅ NGINX is working
inactive / failed → ❌ issue needs fixing

🔹 Step 3: Test via Browser

Open your browser and hit:

http://

✔ Expected:

Default NGINX Welcome Page

🔹 Step 5: Test via Curl (CLI Testing)

curl http://localhost

OR from your local system:

curl http://

✔ If HTML response comes → ✅ Server is working

🔹 Step 6: Check Port 80 (Important for DevOps)

sudo netstat -tulpn | grep :80

sudo ss -tulpn | grep :80

✔ Confirms:

NGINX is listening on port 80

💡 Key Takeaways

No More Manual SSH: Bootstrapping completely eliminates the need to manually configure infrastructure after it is provisioned.
Separation of Concerns: By using the file() function, you keep your shell scripts separate from your Terraform code, making both easier to maintain.
Idempotency and Scale: A script guarantees that every server you provision will be configured exactly the same way, every single time.

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

🚀 Terraform Series – Day 7

Gujjar Apurv — Sun, 12 Apr 2026 03:00:00 GMT

Variables & Outputs (Make Your Code Smart 🔥)

In real-world DevOps, writing flexible and reusable code is very important.
Today, we will learn how to use Variables and Outputs in Terraform to make our infrastructure clean, dynamic, and production-ready.

Till now, we were writing Terraform code…
but there was one problem 👇

👉 Everything was hardcoded

And in real DevOps, hardcoding = BIG mistake ❌

So today we fix that 💡

🧩 Step 1: The Real Problem

Imagine this:

instance_type = "t2.micro"

Looks simple… but 👇

❌ Want to upgrade instance? Change everywhere

❌ Want reuse? Not possible

❌ Working in team? Becomes messy

👉 Basically: Not scalable

💡 Step 2: The Smart Solution → Variables

Instead of fixing values in code, we use variables

Think like this:
👉 “Keep values separate, keep code clean”

✔ Why Variables?

Change once → Apply everywhere
Clean & readable code
Reusable infrastructure
Industry-level practice

📌 In short:
Variables = Flexibility + Clean Code + DevOps Standard

📄 Step 3: Create `variables.tf`

variable "ec2_instance_type" {
  default = "t2.micro"
  type    = string
}

variable "ec2_root_storage_size" {
  default = 10
  type    = number
}

variable "ec2_ami_id" {
  default = "ami-0cb91c7de36eed2cb"
  type    = string
}

🧠 Simple Understanding:

variable → variable name
default → default value
type → data type

👉 Values are now separated from the main code ✅

🔗 Step 4: Use Variables in `ec2.tf`

Now the real magic 🔥

# Create Key Pair
resource "aws_key_pair" "my_key" {
  key_name   = "terra-key-aws"
  public_key = file("terra-key-aws.pub")
}


# Default VPC
resource "aws_default_vpc" "default" {}

# Security Group
resource "aws_security_group" "my_groups" {
  name        = "my-group"
  description = "Security group for EC2"
  vpc_id      = aws_default_vpc.default.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow SSH"
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow HTTP"
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow all outbound"
  }

  tags = {
    Name = "automate-sg"
  }
}

# EC2 Instance
resource "aws_instance" "my_instance" {
  ami                    = var.ec2_ami_id
  instance_type          = var.ec2_instance_type
  key_name               = aws_key_pair.my_key.key_name
  vpc_security_group_ids = [aws_security_group.my_groups.id]

  root_block_device {
    volume_size = var.ec2_root_storage_size
    volume_type = "gp3"
  }

  tags = {
    Name = "terra-ec2"
  }
}

⚡ Important Line:

var.

👉 Example:

var.ec2_instance_type

🔄 Step 5: Real Power of Variables

Before:

instance_type = "t2.micro"

After:

default = "t3.micro"

✔ Change in one place

✔ Applied everywhere automatically

🔥 That’s the power

📤 Step 6: Now Let’s Talk About Outputs

Deployment is done… but now 👇

👉 How do you get EC2 Public IP?

😓 Problem

❌ You have to manually check AWS Console

💡 Solution → Outputs

Terraform will show it directly 🔥

📄 Step 7: Create `outputs.tf`

output "ec2_public_ip" {
  value = aws_instance.my_instance.public_ip
}

output "ec2_public_dns" {
  value = aws_instance.my_instance.public_dns
}

🧠 What Happens Now?

When you run:

terraform apply

👉 At the end, Terraform shows:

✔ Public IP

✔ Public DNS

Directly in terminal 🎯

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

🚀 Terraform Series – Day 6

Gujjar Apurv — Sat, 11 Apr 2026 05:00:00 GMT

🎯 Objective

In this hands-on, we will:

Generate SSH key
Create key pair using Terraform
Configure VPC & Security Group
Launch EC2 instance
Connect via SSH
Clean up resources

👉 This is your first real-world Terraform task

🧩 Step 1: Generate SSH Key

ssh-keygen

✔ This creates:

terra-key-aws→ Private key
terra-key-ec2.pub → Public key

👉 We will use this to access EC2

📄 Step 2: Create Terraform File

touch ec2.tf

🧱 Step 3: Add Terraform Code

# Create Key Pair
resource "aws_key_pair" "my_key" {
  key_name   = "terra-key-aws"
  public_key = file("terra-key-aws.pub")
}


# Default VPC
resource "aws_default_vpc" "default" {}

# Security Group
resource "aws_security_group" "my_groups" {
  name        = "my-group"
  description = "Security group for EC2"
  vpc_id      = aws_default_vpc.default.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow SSH"
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow HTTP"
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow all outbound"
  }

  tags = {
    Name = "automate-sg"
  }
}

# EC2 Instance
resource "aws_instance" "my_instance" {
  ami                    = "ami-0cb91c7de36eed2cb"
  instance_type          = "t2.micro"
  key_name               = aws_key_pair.my_key.key_name
  vpc_security_group_ids = [aws_security_group.my_groups.id]

  root_block_device {
    volume_size = 10
    volume_type = "gp3"
  }

  tags = {
    Name = "terra-ec2"
  }
}

⚙️ Step 4: Initialize Terraform

terraform init

✔ Downloads AWS provider

✔ Prepares working directory

✅ Step 5: Validate Configuration

terraform validate

✔ Ensures syntax is correct

📊 Step 6: Plan Execution

terraform plan

✔ Shows resources to be created:

Key Pair
VPC
Security Group
EC2 Instance

🚀 Step 7: Apply (Create Infrastructure)

terraform apply

👉 Type yes to confirm

❌ Common Error: Not Authorized

👉 Reason:

IAM user does not have required permissions

✔ Fix:

Go to AWS IAM → Attach Policy

AdministratorAccess (easy way)

OR
EC2FullAccess
VPCFullAccess

🖥 Step 8: Verify in AWS Console

Go to EC2 Dashboard:

✔ Instance running
✔ Security group attached
✔ Key pair created

🔐 Step 9: Fix Key Permission

chmod 400 terra-key-aws

👉 Required before SSH

🔗 Step 10: Connect to EC2

ssh -i terra-key-aws ubuntu@

👉 Now your server is live 🚀

🧹 Step 11: Destroy Resources (IMPORTANT)

terraform destroy

👉 Prevent unnecessary AWS charges 💸

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

🚀 Terraform Series – Day 5

Gujjar Apurv — Fri, 10 Apr 2026 03:40:00 GMT

Terraform Providers, Resource Types & Naming

In today’s Terraform journey, I explored one of the most fundamental concepts that every DevOps engineer must understand Providers and Resource Naming Structure.

These concepts are the backbone of Terraform because they define how Terraform communicates with real-world infrastructure.

🧠 1. Understanding Terraform Resource Structure

Every infrastructure component in Terraform is defined using a resource block.

📌 Syntax:

resource "_" "" {
  arguments
}

📌 Example:

resource "aws_instance" "my_vm" {
  instance_type = "t2.micro"
}

🔍 Deep Breakdown:

provider (aws)
→ Defines which platform you are using (AWS, GCP, Azure, etc.)
resource_type (instance)
→ Specifies what you want to create (VM, bucket, network, etc.)
name (my_vm)
→ A local identifier inside Terraform (you can name it anything)
arguments
→ Configuration details (size, region, OS, etc.)

⚡ Important Insight:

👉 Terraform does not identify resources by name alone, but by:

provider + resource_type + name

This combination must always be unique.

🌐 2. What is a Provider in Terraform?

A provider is a plugin that allows Terraform to interact with external APIs.

👉 In simple words:

Provider = Bridge between Terraform and Cloud/Service

🔧 Why Providers are Needed?

Without providers:

Terraform cannot talk to AWS, GCP, or any service
No infrastructure can be created

📌 Popular Providers:

AWS (Amazon Web Services)
Google Cloud Platform (GCP)
Azure
Local (for files, local operations)

⚡ Real-Life Analogy:

Think of Terraform as a remote control
and providers as the signal system that connects it to devices.

Without signals → remote is useless ❌

⚙️ 3. Ways to Use Providers in Terraform

Terraform gives flexibility in how you define providers.

🔹 Method 1: Implicit Provider (Automatic Way) ✅

👉 The easiest and most beginner-friendly method.

You don’t explicitly define the provider — Terraform automatically detects it.

📌 Example:


resource "aws_instance" "my_vm" {
  ami           = "ami-0ec10929233384c7f"   # Example Ubuntu AMI (Mumbai)
  instance_type = "t2.micro"

  tags = {
    Name = "Terraform-VM"
  }
}

🔍 What Happens Behind the Scenes?

Terraform sees aws_instance
It understands provider = aws
During initialization, it automatically downloads the provider

▶️ Steps:

terraform init

✔ Provider gets installed automatically

✔ No manual configuration needed

👍 When to Use:

Learning phase
Small projects
Quick testing

🔹 Method 2: Explicit Provider (Declarative Way) ✅

👉 This is the recommended approach for real-world projects.

You explicitly define:

Provider source
Version

📌 Step 1: Define Providers

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

# Configure the AWS Provider
provider "aws" {
  region = "us-east-1"
}

📌 Step 2: Initialize

terraform init

🔍 What Happens:

Terraform downloads exact versions
Ensures consistency across systems
Prevents unexpected breaking changes

👍 When to Use:

Production environments
Team projects
Version-controlled infrastructure

⚡ 4. Implicit vs Explicit (Quick Understanding)

Implicit:

Automatic
Less control
Beginner-friendly

Explicit:

Manual definition
Full control
Production-ready

🚀 5. Pro Tips (Important for DevOps)

✔ Always use explicit providers in real projects
✔ Lock provider versions to avoid errors
✔ Run terraform init after any provider change
✔ Keep provider configuration in a separate file (best practice)

📌 Final Summary

Terraform uses providers to connect with cloud/services
Resource naming follows:
```
_
```
Providers can be:
- Automatically detected (Implicit)
- Manually defined (Explicit)
terraform init is required to install providers

🔥 Conclusion

Understanding providers is a game-changer in Terraform.

Once you master this concept, you unlock the ability to:

Work with multiple cloud platforms
Write scalable infrastructure code
Build real-world DevOps projects

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

🚀 Terraform Series – Day 4

Gujjar Apurv — Fri, 10 Apr 2026 03:30:00 GMT

Terraform Workflow: init, validate, plan, apply & destroy

🧠 Before Starting (AWS Setup)

Before using Terraform with AWS, we first need to configure AWS access on our local machine.

👉 Steps:

Install AWS CLI

Configure AWS using:

aws configure

👉 It will ask for:

AWS Access Key
Secret Key
Region
Output format

✅ After this setup, Terraform can interact with your AWS account.

🎯 Objective

Understand Terraform workflow
Learn core commands
Perform hands-on execution

🧱 Step 0: Create Terraform Configuration File

👉 Create a file:

main.tf

👉 This file contains your Terraform infrastructure code

⚙️ Step 1: Initialize Terraform

🔹 Command:

terraform init

🔹 Purpose:

Initializes working directory
Downloads required providers
Prepares environment

✅ Step 2: Validate Configuration

🔹 Command:

terraform validate

🔹 Purpose:

Checks syntax of .tf files
Ensures configuration is valid

👉 “Check if your code is correct”

📊 Step 3: Review Execution Plan

🔹 Command:

terraform plan

🔹 Purpose:

Shows what Terraform will do
Lists resources to create/change/destroy
Works as a dry run

👉 “Preview before execution”

🚀 Step 4: Apply Configuration

🔹 Command:

terraform apply

🔹 Purpose:

Executes the plan
Creates real infrastructure

👉 Type yes to confirm

🧨 Step 5: Destroy Infrastructure

🔹 Command:

terraform destroy

🔹 Purpose:

Deletes all resources
Avoids unnecessary cloud cost

⚡ Auto-Approve Option

terraform apply -auto-approve
terraform destroy -auto-approve

👉 Skips confirmation

👉 Useful in automation (CI/CD)

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

🚀 Terraform Series – Day 3

Gujjar Apurv — Fri, 10 Apr 2026 03:20:00 GMT

Terraform Blocks, Labels, and Arguments

In Day 2, we installed Terraform.
Now, before writing real infrastructure code, we must understand how Terraform actually reads and executes configurations.

👉 Every Terraform file is built using 3 core concepts:

Blocks
Labels
Arguments

🔹 1. What is a Block?

👉 A block is the main building unit in Terraform used to define infrastructure or configuration.

📌 Example:

resource "aws_instance" "my_vm" {
}

👉 Meaning:

Block tells Terraform what you want to create

📌 Common blocks:

resource
provider
variable
output

🔹 2. What are Labels?

👉 Labels are identifiers of a block that define resource type and name.

📌 Example:

resource "aws_instance" "my_vm" {
}

👉 Meaning:

aws_instance → resource type
my_vm → resource name

👉 Used to uniquely identify resources

🔹 3. What are Arguments?

👉 Arguments are key-value pairs inside a block used to configure the resource.

📌 Example:

instance_type = "t2.micro"

👉 Meaning:

Defines how the resource should be created
Controls behavior and properties

🔗 Combined Example

resource "aws_instance" "my_vm" {
  instance_type = "t2.micro"
}

👉 Breakdown:

Block → resource
Labels → aws_instance, my_vm
Argument → instance_type

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

🚀 Terraform Series – Day 2

Gujjar Apurv — Fri, 10 Apr 2026 03:10:00 GMT

Terraform Setup on AWS EC2 & Local (Ubuntu , window )

In Day 1, we understood the fundamentals of Terraform and Infrastructure as Code (IaC).
Now, in Day 2, we will set up Terraform in real environments.

This guide covers installation on:

AWS EC2 (Ubuntu)
Local Ubuntu Machine
Windows (using Chocolatey)

🎯 Objective

Install Terraform in different environments
Follow secure installation practices
Verify installation properly

☁️ Part 1: Setup on AWS EC2 (Ubuntu)

🧱 Step 1: Create EC2 Instance

Go to AWS EC2 Dashboard
Click Launch Instance
Select:
- OS → Ubuntu
- Instance Type → t2.micro (Free Tier)
Create key pair
Launch instance

🔐 Step 2: Connect via SSH

ssh -i your-key.pem ubuntu@your-ec2-public-ip

📦 Step 3: Update System

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common

🔑 Step 4: Add HashiCorp GPG Key

wget -O- https://apt.releases.hashicorp.com/gpg | \
gpg --dearmor | \
sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null

✅ Step 5: Verify GPG Key

gpg --no-default-keyring \
--keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg \
--fingerprint

👉 Ensures authenticity and security

📁 Step 6: Add Repository

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/hashicorp.list

🔄 Step 7: Update Packages

sudo apt-get update

⚙️ Step 8: Install Terraform

sudo apt-get install terraform

🔍 Step 9: Verify Installation

terraform --version

💻 Part 2: Local Installation (Ubuntu)

👉 Follow the same steps as EC2

No changes required — works exactly the same.

🪟 Part 3: Terraform Installation on Windows

📦 Step 1: Install using Chocolatey

choco install terraform

👉 Make sure Chocolatey is installed on your system

🔍 Step 2: Verify Installation

Open a new terminal (CMD/PowerShell):

terraform -help

Expected output:

Usage: terraform [global options]  [args]

👉 Shows all available Terraform commands

⚡ Enable Autocomplete (Optional but Recommended)

🐧 Bash

touch ~/.bashrc
terraform -install-autocomplete

🐚 Zsh

touch ~/.zshrc
terraform -install-autocomplete

👉 Restart terminal after this step

📘 Alternative Installation Method

You can also install Terraform using the official HashiCorp documentation depending on your OS and requirements.

Terraform official Documentation

👨‍💻 About the Author

“This Kubernetes series focuses on building a strong foundation by understanding real Kubernetes concepts step by step.”

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

🚀 Terraform Series – Day 1

Gujjar Apurv — Fri, 10 Apr 2026 03:00:00 GMT

Introduction to Terraform & Infrastructure as Code (IaC)

In modern DevOps practices, managing infrastructure manually is no longer scalable or efficient. Organizations are rapidly shifting towards automation and Infrastructure as Code (IaC) to ensure consistency, speed, and reliability.

This is where Terraform plays a crucial role.

📌 What is Terraform?

Terraform is an Infrastructure as Code (IaC) tool developed by HashiCorp that enables you to define, provision, and manage infrastructure using code.

Uses HCL (HashiCorp Configuration Language)
Follows a declarative approach
Automates infrastructure lifecycle

👉 Instead of manually creating resources, you define them in code and Terraform handles the execution.

🏢 About HashiCorp

HashiCorp is a technology company focused on building tools for:

Infrastructure automation
Security management
Application deployment

👉 Founded in 2014
👉 By Mitchell Hashimoto and Armon Dadgar

Some popular tools by HashiCorp:

Terraform
Vault
Consul
Nomad

⚡ Why Terraform Matters in DevOps

In real-world environments, infrastructure needs to be:

Consistent across environments
Scalable based on demand
Repeatable without errors
Automated to reduce manual effort

Terraform enables all of this by:

Eliminating manual provisioning
Enforcing infrastructure consistency
Supporting version control (Git-based workflows)
Enabling multi-cloud deployments

🌍 Real-World DevOps Scenario

Consider a company managing multiple environments:

Development
Testing
Production

Each environment requires:

Virtual Machines
Networking setup
Load balancing

❌ Without Terraform

Manual configuration
Time-consuming process
High probability of human errors
Difficult to maintain consistency

✅ With Terraform

Define infrastructure once
Reuse configurations across environments
Deploy with a single command
Modify using variables and version control

👉 Result: Faster, reliable, and scalable infrastructure management

⚔️ Terraform vs Other Tools

🔹 Terraform vs Ansible

Terraform

Focus: Infrastructure provisioning
Creates resources such as:
- Virtual Machines
- Networks
- Load Balancers

Ansible

Focus: Configuration management
Handles:
- Software installation
- System updates
- Application setup

👉 In practice:
Terraform → Creates infrastructure
Ansible → Configures infrastructure

🔹 Terraform vs AWS CloudFormation

Terraform

Supports multiple cloud providers:
- AWS
- Azure
- GCP
Enables multi-cloud strategy

AWS CloudFormation

Limited to AWS ecosystem only

👉 Terraform provides flexibility, while CloudFormation is AWS-specific

🧠 Key Takeaways

Terraform is a core DevOps tool for Infrastructure as Code
It replaces manual infrastructure setup with automated workflows
Supports multi-cloud environments
Ensures consistency, scalability, and efficiency

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

“My DevOps Interview Experience & Questions (2025)”

Gujjar Apurv — Sun, 21 Dec 2025 14:41:18 GMT

DevOps is one of the fastest-growing and most in-demand skills in the IT world 🌍, especially for beginners and cloud engineers 🚀. After learning DevOps tools ⚙️ and working on practical projects 💡, I recently attended two DevOps job interviews 🎯. In this blog, I’m excited to share my real interview experience 📘, including the questions asked ❓, the topics covered 📌, and the key areas interviewers focused on 👀. My goal is to help beginners understand the real interview environment 💼, build confidence 💪, and get a clear idea of what companies truly expect from DevOps candidates 🌟.

📝 Note:

ERPNext Setup on Ubuntu 22.04 – From Zero to Hero!

Gujjar Apurv — Fri, 22 Aug 2025 04:25:15 GMT

📑 Table of Contents

🌟 Introduction: Why ERPNext?
🎯 Aim of this Blog
🛠️ Prerequisites Before You Begin
⚙️ Step 1: Server Setup – Preparing Ubuntu for ERPNext
📦 Step 2: Install Required Packages
🗄️ Step 3: Configure MySQL Server
🔧 Step 4: Install CURL, Node.js, NPM, and Yarn
🏗️ Step 5: Install Frappe Bench Framework
🚀 Step 6: Install ERPNext and Other Applications
✅ Final Verification and Testing Your Setup
📌 Conclusion: Running ERPNext Smoothly

🌟 Introduction : Why ERPNext?

Running a business requires managing multiple operations finance, sales, HR, payroll, CRM, projects, and more. Instead of juggling multiple tools, wouldn’t it be better to have one platform for everything? That’s exactly what ERPNext delivers.

ERPNext is an open-source ERP solution designed to simplify and automate business processes. From startups to enterprises, it’s trusted worldwide for being cost-effective, flexible, and scalable. Unlike other ERP tools that demand heavy licensing costs, ERPNext offers a free and community-driven platform that anyone can install and use.This blog is your complete, beginner-friendly guide to installing ERPNext on Ubuntu 22.04 LTS.

🎯 Aim of this Blog

The main objective of this guide is to help you:

✅ Understand ERPNext installation requirements.
✅ Learn server setup and dependency installation.
✅ Configure and install ERPNext with Frappe framework.
✅ Explore add-on modules like HR, Payroll, Sales, and CRM.

By the end, you’ll have a fully functional ERPNext system running on your local machine.

🛠️ Prerequisites Before You Begin

Before we start the installation, make sure your system meets the minimum requirements:

🔹 Operating System

Ubuntu 22.04 LTS (64-bit)

🔹 Minimum Hardware Requirements

CPU: 2 cores
RAM: 2 GB
Storage: 15 GB free disk space

(Tip: For smoother performance, 4 GB RAM and 2+ CPUs are recommended.)

🔹 Setup Environment

Perform the installation on a local machine for practice/testing.
Ensure you have basic Linux command knowledge (updating system, installing packages, using terminal).

⚙️ Step 1: Server Setup – Preparing Ubuntu

Before we start installing ERPNext, let’s make sure our Ubuntu 22.04 server is ready.

🔹 Update & Upgrade Packages

Keep the system up to date:

sudo apt update && sudo apt upgrade -y

🔹 Set Timezone

Correct timezone ensures accuracy in reports, HR, and payroll:

sudo timedatectl set-timezone Asia/Kolkata

🔹 Install Basic Tools

Essential utilities for smooth installation:

sudo apt install git curl wget htop nano unzip -y

✅ That’s it! Your server is now ready to proceed with ERPNext installation.

📦 Step 2: Install Required Packages

In this step, we install the essential tools for Python, create swap memory for smooth performance, and set up MariaDB (MySQL alternative) for database support.

🐍 Install Python + Build Tools

sudo apt -y install python3 python3-pip python3-venv python3-dev build-essential libffi-dev libssl-dev

🔎 Explanation:

python3 → Installs the Python 3 interpreter.
python3-pip → Python package manager (used to install libraries).
python3-venv → For creating isolated virtual environments.
python3-dev → Development headers required for compiling Python extensions.
build-essential → Provides compiler tools like gcc and make.
libffi-dev & libssl-dev → Required for cryptography and secure connections.

👉 These dependencies are necessary for ERPNext/Bench to work properly.

🧠 Create & Enable Swap Memory

sudo fallocate -l 2G /swapfile    # Create a 2GB swap file
sudo chmod 600 /swapfile          # Set correct permissions
sudo mkswap /swapfile             # Format the swap file
sudo swapon /swapfile             # Enable swap
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab   # Make swap permanent after reboot

🔎 Explanation:

Swap memory acts as virtual RAM using disk space.
If the system runs out of physical RAM, swap ensures processes don’t crash.
Here, we created a 2GB swap file to handle heavy package installations and Python compilations smoothly.

🗄️ Install MariaDB (MySQL Server)

sudo apt -y install mariadb-server mariadb-client

🔎 Explanation:

mariadb-server → Installs the database engine (where ERPNext stores data).
mariadb-client → Provides tools to interact with the database.

👉 MariaDB is a drop-in replacement for MySQL — it uses the same commands but is faster and open-source.

🗄️ Step 3: Configure MySQL Server

Now, let’s secure the MariaDB server.

sudo mysql_secure_installation

🔎 Explanation:
This is an interactive script that asks security-related questions:

Set root password → Protects the database root user with a password.
Remove anonymous users → Deletes default anonymous accounts.
Disallow remote root login → Ensures root can only log in from localhost.
Remove test database → Deletes the unnecessary test DB.

👉 These steps make MariaDB secure and production-ready.

🔑 Understanding the `bind-address` in MariaDB for ERPNext

When setting up ERPNext on Ubuntu with MariaDB, one important configuration line you might have noticed in the erpnext.cnf file is:

bind-address = 127.0.0.1

But what does this mean, and why do we use it? 🤔

🌐 What is `bind-address`?

The bind-address tells MariaDB which network interface (IP address) it should listen to for incoming connections.

127.0.0.1 → This is the loopback address (localhost). It means MariaDB will only accept connections from the same machine where it is installed.
Any other IP (like 0.0.0.0 or server’s public IP) → MariaDB would listen to requests from outside machines too.

🔒 Why use `127.0.0.1` for ERPNext?

For most ERPNext installations:
✅ ERPNext and MariaDB run on the same server.
✅ We don’t need external machines to connect directly to MariaDB.
✅ It provides better security, as no one from outside the server can attempt to connect to the database.

This is why:

bind-address = 127.0.0.1

is the safest choice for local or single-server ERPNext setups.

⚡ Step 4: Install Redis, Node.js, Yarn & Frappe Bench

In this step, we will install all the required tools to run ERPNext efficiently.

🛠️ 4.1 Install Redis & wkhtmltopdf

1️⃣ Install Redis & wkhtmltopdf:

sudo apt -y install redis-server wkhtmltopdf

👉 redis-server: Used for caching and background task queues.
👉 wkhtmltopdf: Helps ERPNext generate PDF reports (Invoices, Quotations, etc.).

2️⃣ Enable Redis to start on boot:

sudo systemctl enable redis-server

👉 Makes sure Redis automatically starts when the server reboots.

3️⃣ Start Redis immediately:

sudo systemctl start redis-server

👉 Runs Redis service right now without waiting for reboot.\

4️⃣ Test Redis is working:

redis-cli ping

👉 If Redis is active, you will see PONG ✅.

⚙️ 4.2 Install Node.js

1️⃣ Add Node.js 18.x repository:

curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -

👉 Downloads & configures Node.js LTS (18.x) setup for Ubuntu.

2️⃣ Install Node.js:

sudo apt -y install nodejs

👉 Installs both Node.js (runtime) and npm (package manager).

📦 4.3 Install Yarn

1️⃣ Install Yarn globally:

sudo npm install -g yarn

👉 Yarn is a faster package manager used by ERPNext frontend for handling JavaScript libraries.

2️⃣ Check Yarn version:

yarn -v

👉 Confirms Yarn is installed successfully.

3️⃣ Check Node.js version:

node -v

👉 Confirms Node.js installed properly.

4️⃣ Check npm version:

npm -v

👉 Confirms npm (Node package manager) is working.

🚀 4.4 Install Frappe Bench

1️⃣ Install pipx (required for managing Python apps safely):

sudo apt -y install pipx

👉 Installs pipx, which isolates Python-based applications.

2️⃣ Add pipx to system PATH:

pipx ensurepath

👉 Ensures pipx commands can run globally from terminal.

3️⃣ Install Frappe Bench:

pipx install frappe-bench

👉 Installs the bench tool, used to create and manage ERPNext projects/sites.

4️⃣ Verify Bench installation:

bench --version

👉 Confirms that Bench is installed correctly.

✨ ✅ At this point, Redis, Node.js, Yarn, and Frappe Bench are all set up!

🏗️ Step 5: Installing Frappe Bench Framework

The Frappe Bench is the backbone of ERPNext. It helps you create, manage, and run multiple ERPNext sites with ease 🚀. Let’s set it up!

⚡ 1. Create a Frappe Directory

mkdir -p ~/frappe && cd ~/frappe

🔹 mkdir -p ~/frappe → Creates a new folder called frappe inside your home directory.
🔹 cd ~/frappe → Immediately moves you inside that folder.

👉 This ensures we have a clean space where all ERPNext files will be stored 📂.

⚡ 2. Initialize Bench with Frappe v15

bench init --frappe-branch version-15 frappe-bench

🔹 bench init → Starts the setup of a new Bench environment.
🔹 --frappe-branch version-15 → Installs the latest stable Frappe v15.
🔹 frappe-bench → Name of the folder where the new Bench environment will be created.

👉 After this, a new directory frappe-bench is created which contains all necessary files ⚙️.

⚡ 3. Move into Bench Directory

cd frappe-bench

🔹 Switches into the frappe-bench folder created in the previous step.
👉 From here, you can start creating ERPNext sites and apps 🎯.

✨ Step 6: Installing ERPNext and Applications

Once your Frappe Framework is ready, the next move is to bring ERPNext into action. This step will set up ERPNext inside your local environment 🚀.

🖥️ 1. Create a New Site

bench new-site site1.local

🔹 Creates a fresh site named site1.local.
🔹 It will ask for:

MySQL root password 🔑
Administrator password (used later for ERPNext login)

👉 Think of this as preparing an empty house 🏠 where ERPNext will live.

📥 2. Download ERPNext App

bench get-app erpnext --branch version-15

🔹 Fetches ERPNext source code from GitHub.
🔹 --branch version-15 ensures you install the latest stable ERPNext (v15).

👉 Like bringing ERPNext package 📦 into your system.

🔗 3. Install ERPNext on Your Site

bench --site site1.local install-app erpnext

🔹 Installs ERPNext inside your site.
🔹 Now, site1.local is fully powered by ERPNext.

👉 Imagine you just plugged ERPNext’s engine 🚂 into your site.

🎨 4. Build ERPNext Assets

bench build --app erpnext

🔹 Compiles JS, CSS, and frontend files.
🔹 Without this, your ERPNext dashboard may look broken.

👉 This step decorates the house 🏡✨, making ERPNext’s UI ready.

⚡ 5. Install Honcho (Process Manager)

pip install honcho
honcho --version

🔹 Honcho helps run multiple services (Frappe, Redis, Workers) together.
🔹 First command installs it, second confirms the version.

👉 Think of Honcho as your site manager 👷, keeping everything running smoothly.

✅ Final Verification and Testing Your Setup

▶️ Start ERPNext and Access on Localhost

Once ERPNext is installed, it’s time to bring it to life! 🚀

🔹 Step 1: Go to your bench folder

cd ~/frappe-bench

🔹 Step 2: Start ERPNext services

bench start

This command will launch the web server, scheduler, workers, and all background services required for ERPNext.

🔹 Step 3: Open ERPNext in your browser

Now visit:

http://site1.local:8000

(If site1.local doesn’t work, try http://localhost:8000)

✨ And boom 💥 — your ERPNext dashboard will appear, ready for you to explore modules like HR, Sales, CRM, Accounting, Inventory, and more! 🎯

🎉 After installing ERPNext, complete the Setup Wizard by creating your admin account and entering your company details. Once done, you’ll be redirected straight to the ERPNext dashboard, ready to explore all modules. 🚀

⚠️ Notice
If you don’t see modules like HR, Sales, CRM, Accounting, or Tools on your ERPNext dashboard after installation, don’t worry!

👉 Simply use the Search Bar (Ctrl + G) at the top and type the module name (e.g., HR or Sales). Once opened, you can pin or add them to your sidebar/dashboard.

This happens because ERPNext hides some modules by default — but they are all available and just one search away. ✅

✅ Conclusion
You’ve now completed the full journey from setting up the server to launching ERPNext on your browser. 🎯 With modules like HR, Sales, CRM, Accounting, and Inventory, your business is ready to streamline operations on a modern open-source ERP system. This is just the beginning explore, customize, and make ERPNext truly yours! 🚀

👨‍💻 About the Author

This project is a deep dive into the ERPNext ecosystem, designed to strengthen my foundation in enterprise resource planning, business automation, and modular integration using open-source technology.

This series isn’t just about installing ERPNext; it’s about mastering the core modules that power modern business management from HR and Sales to Accounting, Inventory, and CRM. 🚀

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

✨ Final Note
This blog is a reflection of my personal journey and learning efforts. I have written and shaped it with my own understanding and dedication. Still, perfection is a continuous process so if you find any mistakes, missing points, or areas of improvement, feel free to share your suggestions in the comments. Your feedback will not only help me improve this work but will also add more value to everyone who reads it. 🚀

Thank you for taking the time to read! 🙌

☁️ Seamless Cloud Backup & Restore using Rclone: Pcloud ➡️ AWS S3 Automation

Gujjar Apurv — Fri, 15 Aug 2025 04:36:59 GMT

Aim 🎯

The aim of this task is to securely backup and restore data from another cloud (Pcloud) to AWS S3. 💾🔒
To achieve this, I performed the entire task using Rclone, created an automated Bash script, and scheduled Cron jobs to ensure continuous, safe, and hassle-free data synchronization. 🌐✅

Introduction 📖

Data is the most valuable asset 💻💾, and keeping it safe and accessible is crucial. In this task, I used Rclone with sync to securely backup and restore data from Pcloud to AWS S3 ☁️➡️☁️. With a Bash script 🖥️ and Cron jobs ⏰, the process is fully automated, secure, and hassle-free ✅.

📁 Agenda

🛠️ Prerequisites Setup
🖥️ EC2 Instance Configuration
👤 IAM User & S3 Bucket Creation
📦 Rclone Installation & Remote Configuration
💻 Backup & Restore Script Development
⏱️ Cron Automation Setup
🧪 Testing & Verification
🏁 Conclusion

🛠️ Prerequisites

✅ AWS Account with EC2 access
✅ PCloud account(any other cloud) with data to backup
✅ Basic Linux command knowledge
✅ SSH access to Ubuntu server

🖥️ Step 1: EC2 Instance Setup

Launch Ubuntu EC2 Instance

# Instance Type: t3.micro (Free tier eligible)
# AMI: Ubuntu Server 22.04 LTS
# Security Group: Allow SSH (Port 22)
# Key Pair: Create or use existing

Connect to Instance

👤 Step 2: IAM User & S3 Bucket Creation

🔏Create IAM User

Go to AWS IAM Console
Create new user: rclone-backup-user
Attach policy: AmazonS3FullAccess
Generate Access Keys (save securely)

🪣Create S3 Bucket

📦 Step 3: Rclone Installation & Configuration

Install Rclone

sudo apt update
sudo apt install -y rclone
rclone version

Configure PCloud Remote

# Choose: n (New remote)
# Name: pcloud
# Storage: pcloud
# Follow OAuth authentication process
# Add your pcloud token

Use the command below to generate a token for pCloud and download it locally:

rclone authorize "pcloud"

Configure AWS S3 Remote

rclone config
# Choose: n (New remote)  
# Name: s3
# Storage: s3
# Provider: AWS
# Access Key ID: [Your IAM Access Key]
# Secret Access Key: [Your IAM Secret Key]
# Region: us-east-1
# Endpoint: [Leave blank]
# Location constraint: [Leave blank]

Verify Remotes

rclone listremotes

💻 Step 4: Create Backup & Restore Script

Create Script Directory

Create backup_restore.sh

vim backup_restore.sh

Script Content

#!/bin/bash

# Remotes
PCLOUD_REMOTE="pcloud:"
S3_REMOTE="aws_s3:mybucket1-apurv"

# Log files
BACKUP_LOG="/var/log/pcloud_to_s3_backup.log"
RESTORE_LOG="/var/log/s3_to_pcloud_restore.log"

# ----------------------------
# 1. Backup: pCloud → S3
# ----------------------------
echo "Starting backup from pCloud to S3..."
rclone sync $PCLOUD_REMOTE $S3_REMOTE --log-level=ERROR >> $BACKUP_LOG 2>&1
echo "Backup completed. Log: $BACKUP_LOG"

# ----------------------------
# 2. Restore: S3 → pCloud
# ----------------------------
echo "Starting restore from S3 to pCloud..."
rclone sync $S3_REMOTE $PCLOUD_REMOTE --log-level=ERROR >> $RESTORE_LOG 2>&1
echo "Restore completed. Log: $RESTORE_LOG"

- Remotes:
  
  * $PCLOUD_REMOTE → pCloud account remote.
  
  * $S3_REMOTE → AWS S3 bucket remote.
  
  * Log files:
  
  * $BACKUP_LOG → stores backup errors/output.
  
  * $RESTORE_LOG → stores restore errors/output.
  - *Backup (pCloud → S3) – rclone sync copies data from pCloud to S3 and logs errors.
  - *Restore (S3 → pCloud) – rclone sync restores data back from S3 to pCloud with logging.
    
    * --log-level=ERROR >> $RESTORE_LOG 2>&1 → logs errors only.
    
    * Echo messages: Show start and completion of backup/restore in terminal.

Make Script Executable

chmod +x backup_restore.sh

🔄 Step 5: Manual Testing

Test Backup

./backup_restore.sh

⏱️ Step 6: Automate with Cron

Open Crontab

crontab -e

Add Cron Job (Every 1 minute)

*/1 * * * * /home/ubuntu/backup_restore.sh >> /var/log/backup_restore_cron.log 2>&1

A. List Files in `/home/ubuntu/` Directory

ls -l /home/ubuntu/

Displays a detailed list of all files and directories inside /home/ubuntu/.

B. Create a Folder Named `myfiles`

mkdir -p /home/ubuntu/myfiles

Creates a folder called myfiles inside /home/ubuntu/. The -p option ensures the command won’t give an error if the folder already exists.

C. Create `test1.txt` with Sample Content

echo "Test file" > /home/ubuntu/myfiles/test1.txt

Creates a file named test1.txt inside myfiles and writes Test file into it.

D. Create `test2.txt` with Sample Content

echo "Another file" > /home/ubuntu/myfiles/test2.txt

Creates a file named test2.txt inside myfiles and writes Another file into it.

E. Copy Files to AWS S3 (Dry Run)

rclone copy /home/ubuntu/myfiles aws_s3:mybucket1-apurv --dry-run --log-level=ERROR

Uses rclone to copy all files from /home/ubuntu/myfiles to the AWS S3 bucket named mybucket1-apurv.
The --dry-run option simulates the copy process without actually transferring the files.

F. Sync Files from pCloud to AWS S3

rclone sync pcloud: aws_s3:mybucket1-apurv --log-level=ERROR

Uses rclone to sync files from the pCloud storage to the AWS S3 bucket mybucket1-apurv.
--log-level=ERROR shows only error messages during execution.

🧪 Step 7: Testing & Verification

Case Study 1: Existing Files

✅ All existing PCloud files synced to S3
✅ Directory structure maintained
✅ File integrity preserved

Case Study 2: New File Addition

Add new file to PCloud
Wait 1 minute
Check S3 bucket → File automatically appears
Verify in logs

I uploaded ad.jpg to pCloud, remove text file , the cron job automatically synced it to the S3 bucket within a minute. Screenshot of the automatic sync is attached below.

⚠️ Challenges & ✅ Success in Automating Secure Backup from pCloud to AWS S3

Task Overview & Challenges:

⏳ Faced major difficulties over 2 days while setting up backup and restore between pCloud and S3.
💾 Backup worked, but restore had issues initially.

Steps Taken & Solutions:

📤 Uploaded data to pCloud, but cron job was not picking up latest changes immediately.
❌ Initially, latest files were missing in backup due to timing issues.
🔄 Switched to using rclone sync, which automatically updates S3 whenever any change happens in pCloud.
⏱️ Cron job now syncs every minute, ensuring real-time backup.
✅ Tested with rclone copy to verify that the remote connection and permissions were correct.

Results:

🛠️ After solving all errors, backup is now working perfectly.
🔒 All data is synced securely and automatically from pCloud → AWS S3.
📸 Screenshots attached show successful backup and automation in action.

Conclusion for Challenges :

🤖 Automated backup with cron + rclone ensures highly secure, real-time sync.
✨ Reduces manual effort and guarantees up-to-date cloud storage.

conclusion:

✅ Learned how to automate secure cloud backup using pCloud, AWS S3, cron, and Rclone.
💡 Gained hands-on experience in troubleshooting errors, syncing data, and ensuring real-time updates.
🏆 Successfully set up a fully automated, secure, and reliable backup system.

👨‍💻 About the Author

This series isn't just about using AWS; it's about mastering the core services that power modern cloud infrastructure.

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

🚀Automated Backup & Restore to AWS S3 using AWS CLI & Cron Jobs

Gujjar Apurv — Sun, 10 Aug 2025 10:24:52 GMT

📌 Introduction

Data loss can be costly whether due to accidental deletion, hardware failure, or system crashes . In this blog, we will set up an automated backup and restore system using AWS S3, AWS CLI, and cron jobs, starting completely from scratch.

You will learn:

How to configure AWS CLI for S3
How to create a shell script for backup & restore
How to automate backups using cron
How to verify backups in real-world scenarios

🗂 Agenda

🛠 Prerequisites
📥 Install AWS CLI
👤 Create IAM User & Configure CLI
📦 Create S3 Bucket
📂 Prepare Local Folder
🖥 Create Backup & Restore Script
🔄 Backup & Restore (Manual)
⏱ Automate with Cron
🧪 Case Studies (Existing Data + New File)
🏁 Conclusion

🛠 Step 1 – Prerequisites

You need:

AWS Account
Ubuntu server / EC2 instance
AWS CLI installed
IAM User with S3 access
Basic Linux command knowledge

📥 Step 2 – Install AWS CLI

sudo apt update
sudo apt install -y unzip tar gzip
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws --version

👤 Step 3 – Create IAM User & Configure CLI

Go to AWS Console → IAM
Create a user backup-user with Programmatic access
Attach policy AmazonS3FullAccess (testing)
Save Access Key & Secret Key

On Ubuntu, run:

aws configure

Fill in:

Access Key
Secret Key
Region ()

📦 Step 4 – Create S3 Bucket

📂 Step 5 – Prepare Local Folder

ls
cd aws
mkdir mybackup

Add your files (HTML, CSS, JS, etc.) here.

🖥 Step 6 – Create Backup & Restore Script

vim backup-to-s3.sh

#!/bin/bash

FOLDER_PATH="/home/ubuntu/mybackup"
BUCKET_NAME="s3-bucket-apurv-data"
LOG_FILE="/home/ubuntu/backup-log.txt"
DATE=$(date +"%Y-%m-%d %H:%M:%S")

if [ "$1" == "backup" ]; then
    echo "[$DATE] Backup started..." | tee -a "$LOG_FILE"
    aws s3 sync "$FOLDER_PATH" "s3://$BUCKET_NAME/" --exact-timestamps --sse AES256 >> "$LOG_FILE" 2>&1
    echo "[$DATE] Backup completed." | tee -a "$LOG_FILE"

elif [ "$1" == "restore" ]; then
    echo "[$DATE] Restore started..." | tee -a "$LOG_FILE"
    aws s3 sync "s3://$BUCKET_NAME/" "$FOLDER_PATH" --exact-timestamps >> "$LOG_FILE" 2>&1
    echo "[$DATE] Restore completed." | tee -a "$LOG_FILE"

else
    echo "Usage: $0 backup|restore"
fi

Step 7 – Manual Backup & Restore

# Make the script executable
chmod +x backup-to-s3.sh    # make it executable

# Take a backup
./backup-to-s3.sh backup    # to take backup

# Restore from backup
./backup-to-s3.sh restore   # to restore

⏱ Step 8 – Automate with Cron

crontab -e

Add:

*/2 * * * * /home/ubuntu/aws/backup-to-s3.sh backup

This cron job will automatically run the backup script every 2 minutes.

🧪 Step 9 – Case Studies

📌 Case 1 – Existing Data in Bucket

When the bucket was created, it already contained:

index.html
style.css
script.js

Backup script compared timestamps:

Same files → Skipped
Updated files → Uploaded again

📌 Case 2 – Adding a New File

We added:

echo "This is a test file" > /home/ubuntu/mybackup/test.txt

✅Check Total files and folders :-

ls

Backup run:

/home/ubuntu/aws/backup-to-s3.sh backup

Verification:

aws s3 ls s3://s3-bucket-apurv-data/ --recursive --human-readable --summarize

Now test.txt appears in the bucket.

💡

Notice :-The DIVP PROJECT/ folder contained code files (HTML, CSS, Java).

🏁 Conclusion

We successfully built an automated backup & restore system with:

AWS S3
AWS CLI
Cron automation
Logging & encryption

With this setup, your data is secure, versioned, and restorable anytime.

👨‍💻 About the Author

This series isn't just about using AWS; it's about mastering the core services that power modern cloud infrastructure.

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

“🌐🌟Beginner’s Guide to Load Balancing on AWS Using NGINX and ALB”

Gujjar Apurv — Mon, 04 Aug 2025 10:53:17 GMT

🔰 Introduction

In this guide, I’ll walk you through how I deployed a basic NGINX web server setup using AWS services like EC2, ALB, Subnets, and VPC. Each server displays a simple custom message and the traffic is distributed using an Application Load Balancer. This small project helped me and you understand how load balancing works in AWS and how to connect multiple EC2 instances behind an ALB.

📑 Index / Table of Contents

Introduction
– Brief about the project and objective
Architecture Overview
– Visual diagram
– Basic AWS services used
VPC and Subnet Setup
– Create custom VPC
– Create 3 public subnets (in 3 AZs)
– Enable auto-assign public IP
Internet Gateway and Routing
– Create and attach IGW
– Route Table setup and association with subnets
Security Groups Configuration
– ALB Security Group
– EC2 Security Group
Launching EC2 Instances
– 3 Ubuntu instances
– Subnet & AZ mapping
– Key pair and public IPs
Installing NGINX on EC2
– Commands to install & start NGINX
– Enable on boot
Customizing Web Content
– Unique message per server (Server 1, Server 2, Server 3)
Creating Application Load Balancer (ALB)
– ALB across all 3 subnets
– Target group (port 80)
– Health checks & registration
Testing the Setup
– Access via ALB DNS
– Load balancing behavior
Conclusion

🧩 1. Introduction

In this small project, I worked on deploying a simple web server setup using NGINX on EC2 instances behind an Application Load Balancer (ALB) in AWS. The goal was to understand how to:

Launch EC2 instances across multiple subnets
Install and configure NGINX on Ubuntu servers
Set up an ALB to distribute incoming traffic
Serve custom responses from each EC2 to test load balancing

Each server was placed in a different Availability Zone and returned a different message like “Server 1”, “Server 2”, and “Server 3” to help visualize ALB routing.

This project is ideal for beginners who want hands-on experience with core AWS services like EC2, VPC, Subnets, IGW, Security Groups, and ALB.

🗺️ 2. Architecture Overview

This project is built using basic yet important AWS services that work together to host a simple web application and distribute traffic across multiple servers.

🧱 Main AWS Services Used:

VPC – Custom Virtual Private Cloud to isolate the network
Subnets – 3 public subnets across different Availability Zones (AZs)
Internet Gateway (IGW) – Allows internet access to instances
Route Table – Connects subnets to the IGW for public access
EC2 Instances (Ubuntu) – Hosts NGINX and serves static content
Security Groups – Control inbound/outbound traffic to ALB and EC2
Application Load Balancer (ALB) – Distributes HTTP traffic to EC2s
Target Group – Links ALB to backend EC2 instances

🖼️ Architecture Diagram:

This setup ensures that any request to the ALB is routed to one of the EC2 instances in a round-robin fashion. You can test this by hitting the ALB DNS in a browser and seeing different responses.

🌐 3. VPC and Subnet Setup

The first step in deploying any AWS infrastructure is creating a VPC (Virtual Private Cloud), which acts like your private network in the cloud.

In this setup, we create one VPC and divide it into 3 public subnets, each in a different Availability Zone (AZ) for better availability and distribution.

🧱 3.1 Create Custom VPC

Go to the VPC Dashboard in AWS.
Click “Create VPC” and choose VPC only.
Enter:
- Name: server-vpc
- IPv4 CIDR block: 10.0.0.0/16
- Leave IPv6 and other options as default.
Click Create VPC.

🌍 3.2 Create 3 Public Subnets

Now create three subnets in different AZs:

Subnet Name	AZ	CIDR Block
Subnet-1	ap-south-1a	`10.0.1.0/24`
Subnet-2	ap-south-1b	`10.0.2.0/24`
Subnet-3	ap-south-1c	`10.0.3.0/24`

For each subnet:

Go to Subnets → Create subnet
Select the VPC you created.
Assign AZ, name, and CIDR.
✅ Enable Auto-assign public IPv4 for each subnet (important for public access).

🌐 4. Internet Gateway and Routing

To allow EC2 instances in public subnets to connect to the internet (for updates, package installs, etc.), we need two things:

An Internet Gateway (IGW)
A Route Table that connects subnets to the IGW

🔌 4.1 Create and Attach Internet Gateway (IGW)

Go to VPC Dashboard → Internet Gateways
Click Create Internet Gateway
- Name: server-igw
Once created, click Actions → Attach to VPC
- Select your VPC (server-vpc)
- Click Attach

🧭 4.2 Create Route Table for Public Access

Go to Route Tables → Create route table
- Name: Public-RT
- Select your VPC (My-VPC)
Click Create

➕ 4.3 Add Route to IGW

Open Public-RT → Go to Routes → Edit routes
Click Add route
- Destination: 0.0.0.0/0
- Target: Select your Internet Gateway (My-IGW)
Click Save changes

🔗 4.4 Associate Route Table to Public Subnets

Open Public-RT → Go to Subnet Associations
Click Edit subnet associations
Select all 3 public subnets:
- Subnet-1 (10.0.1.0/24)
- Subnet-2 (10.0.2.0/24)
- Subnet-3 (10.0.3.0/24)
Save

🔐 5. Security Groups Configuration

Security Groups (SGs) in AWS act like virtual firewalls that control inbound and outbound traffic to your EC2 instances and Load Balancer.
We’ll create two separate SGs — one for the ALB and one for the EC2 instances.

🛡️ 5.1 Create ALB Security Group

This SG allows the ALB to accept incoming HTTP requests from the internet.

Go to EC2 → Security Groups → Create Security Group
Name: ALB-SG
Description: Allows HTTP access from anywhere
VPC: Select server-vpc
Add Inbound Rule:
- Type: HTTP
- Port: 80
- Source: Anywhere (0.0.0.0/0)
Leave outbound as default
Click Create Security Group

🖥️ 5.2 Create EC2 Security Group

This SG allows EC2 instances to accept traffic only from the ALB, not directly from the internet.

Create another SG: EC2-SG
Description: Allows HTTP from ALB only
VPC: Select My-VPC
Add Inbound Rule:
- Type: HTTP
- Port: 80
- Source: Custom
- Select ALB-SG as source (it will show in the dropdown)
Click Create Security Group

🔄 Attach SGs to Resources

While creating the ALB, attach ALB-SG
While launching each EC2 instance, attach EC2-SG

💻 6. Launching EC2 Instances

Now that our networking and security are in place, it's time to launch 3 EC2 instances one in each public subnet — to host our NGINX web servers.

We’ll use Ubuntu 22.04 as the OS for simplicity and compatibility.

🔸 6.1 Launch EC2 Instances (Repeat 3 Times)

Go to EC2 → Instances → Launch Instance
Enter:
- Name: Server-1 (change to Server-2 and Server-3 for others)
- AMI: Ubuntu Server 22.04 LTS (64-bit)
- Instance type: t2.micro (free tier eligible)
Key Pair: Select an existing one or create a new one
(Make sure to download and keep the .pem file safe)

📍 6.2 Network Settings per Instance

For each instance:

Server Name	Subnet	Availability Zone
Server-1	`Subnet-1`	`ap-south-1a`
Server-2	`Subnet-2`	`ap-south-1b`
Server-3	`Subnet-3`	`ap-south-1c`

Auto-assign Public IP: Enabled ✅
Security Group: Attach the EC2-SG you created earlier

🟢 6.3 Launch All Instances

Launch each instance with its respective subnet
Wait for running status
Copy the public IP of each instance (we’ll use them to SSH and install NGINX)

🔧 7. Installing NGINX on EC2

After your EC2 instances are running, SSH into each one and install NGINX:

# Update and install NGINX
sudo apt update -y
sudo apt install nginx -y

# Start NGINX and enable on boot
sudo systemctl start nginx
sudo systemctl enable nginx

Repeat the above steps on all 3 EC2 instances.

🎨 8. Customizing Web Content

We want each EC2 instance to return a unique message (e.g., Server 1, Server 2, etc.) so we can test the ALB behavior.

On Server 1:

echo "Server 1" | sudo tee /var/www/html/index.nginx-debian.html

On Server 2:

echo "Server 2" | sudo tee /var/www/html/index.nginx-debian.html

On Server 3:

echo "Server 3" | sudo tee /var/www/html/index.nginx-debian.html

⚙️ 9. Creating Application Load Balancer (ALB)

Now we create an Application Load Balancer that will distribute incoming traffic across the 3 servers.

🔹 ALB Setup:

Go to EC2 → Load Balancers → Create Load Balancer
Choose Application Load Balancer
Enter:
- Name: server-alb
- Scheme: Internet-facing
- Listeners: HTTP (Port 80)
Availability Zones: Select your VPC and the 3 subnets:
- Subnet-1 (ap-south-1a)
- Subnet-2 (ap-south-1b)
- Subnet-3 (ap-south-1c)
Attach ALB-SG as the security group.

🔸 Target Group Setup:

Create a new Target Group
- Target type: Instances
- Protocol: HTTP
- Port: 80
Register all 3 EC2 instances
Keep health checks as default (or use /)

Once done, the ALB will start running and routing traffic.

🔍 10. Testing the Setup

After your ALB status is active:

Go to Load Balancers → Select your ALB
Copy the DNS name (e.g., my-alb-123456789.ap-south-1.elb.amazonaws.com)
Open it in your browser:

http://-alb-dns>

🌀 Refresh multiple times — you should see:

Server 1
Server 2
Server 3

This confirms round-robin load balancing is working across your EC2 instances

✅ Conclusion

In this hands-on project, we successfully created a load-balanced web server architecture on AWS using core services like VPC, EC2, Subnets, Security Groups, and an Application Load Balancer (ALB).

Each EC2 instance ran NGINX, hosted a unique web page, and was deployed in a separate Availability Zone, ensuring high availability and better traffic distribution. The ALB handled incoming traffic and distributed it across the servers in a round-robin fashion — a basic yet powerful demonstration of load balancing on AWS.

This project gave me a practical understanding of:

How networking works in AWS (VPC, Subnets, IGW, Routing)
How to configure EC2 and secure them with Security Groups
How to use ALB to manage and balance web traffic
How to test and validate a real cloud setup end-to-end

👨‍💻 About the Author

This series isn't just about using AWS; it's about mastering the core services that power modern cloud infrastructure.

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

🚀 Seamless Data Transfer via Rsync Between 2 Different EC2 Instances Mounted with EBS Volumes

Gujjar Apurv — Mon, 21 Jul 2025 16:52:00 GMT

🎯 Aim:

To securely transfer files from one EC2 instance to another using the rsync utility, where data resides on an attached and mounted EBS volume, while preserving permissions and ensuring efficiency.

📌 Overview:

In this task, we used two EC2 instances, each with its own EBS volume mounted at /mydata. Our goal was to transfer the contents from EC2 Instance 1 to EC2 Instance 2 using rsync, excluding system files like lost+found.

We ensured:

🔐 Secure SSH key-based connection
🚫 Proper exclusion of unnecessary system folders
✅ Verified and successful file transfer
🛠️ Fixed permission issues

🧱 Infrastructure Setup:

Component	Details
EC2 Instance 1	Source, with EBS mounted at `/mydata1`
EC2 Instance 2	Destination, with EBS mounted at `/mydata2`
SSH Key	`your key.pem`
File Transferred	`ebs-test.txt`
Tool Used	`rsync`

🔧 Step-by-Step Execution

Step 1️⃣: Create EC2 Instances

Launch two EC2 instances (Source & Target) in the same VPC/Subnet for easier SSH connection.
Use the Ubuntu AMI and make sure both have access to the same key pair (e.g., xyz.pem).

Step 2️⃣: Create and Attach EBS Volume to Source EC2

Go to Elastic Block Store > Volumes
Create a new 2 EBS volume (e.g., 1 GB, same AZ as Source EC2)
Select the volume → Actions > Attach volume → Choose your Source EC2
Device name will be something like /dev/xvdh

Step 3️⃣: Mount EBS Volume in Source & Destination Both EC2

✅ it's not mandatory that both source and destination have EBS volumes attached.

SSH into Source & Destination EC2 and run:

lsblk      # Check if /dev/xvdf is visible
sudo mkfs -t ext4 /dev/xvdh    # Format the volume
sudo mkdir /mydata           # Create a mount point
sudo mount /dev/xvdh /mydata # Mount the volume

✅ Now the volume is ready to store data.

Step 4️⃣: Create Sample Data

Write a test file to check transfer:

cd /mydata
echo "This is task for EBS-Task performed by Apurv Gujjar" > ebs-test.txt

🔄 Step 5️⃣: Change Ownership of Mounted EBS Volume 👑

After mounting your EBS volume (e.g., at /mydata), by default it's owned by the root user. This can block the ubuntu user from accessing or writing files — especially important for tools like rsync.

🎯 Aim:

Grant full ownership of the mounted volume to the ubuntu user so it can use the directory without permission issues.

🛠️ Command:

sudo chown -R ubuntu:ubuntu /mydata

🔹 -R: Applies changes recursively
🔹 ubuntu:ubuntu: Sets user and group ownership
🔹 /mydata: Path to your mounted volume (adjust if different)

✅ Why it’s Important:

Without changing ownership, you may get Permission Denied errors during file transfers. This step ensures smooth read/write access for the EC2 instance’s main user.

🔐 Step 6️⃣: Add Private Key to Source EC2 for Remote Access via Rsync

To allow the source EC2 instance to securely connect to the destination EC2 instance using rsync, you need to place the destination EC2's .pem file inside the source EC2.

🎯 Why This Is Needed?

The source initiates the rsync connection over SSH to the destination. Therefore, the source EC2 needs the destination's private key to authenticate and establish the secure connection.

🛠️ Step-by-Step:

Create a new file to store your destination’s private key:
```
 vim [your-key-name.pem]
```
Paste your destination EC2’s private key (from the .pem file you downloaded while creating destination EC2).
Save and exit (Esc + :wq in vim).
Secure the key by updating its permissions:
```
 chmod 400 [your-key-name.pem]
```

✅ Now, your source EC2 can securely connect to the destination EC2 using this key enabling rsync to transfer files smoothly.

⚙️ Step 7️⃣: Rsync Command Execution from EC2-1 (Source)

📍 On EC2-1, run the following command to transfer the file to EC2-2 using rsync over SSH:

 rsync -avz --exclude 'lost+found' -e "ssh -i /home/ubuntu/corextech.pem" /mydata/ ubuntu@172.31.0.110:/mydata/

🧠 Command Breakdown :

- rsync
  → The main utility used to synchronize files and directories between two locations.
  - -a (archive mode)
    → Preserves permissions, symbolic links, file ownership, and timestamps. Ideal for full backups.
  - -v (verbose)
    → Displays detailed output of the transfer process.
  - -z (compress)
    → Compresses data during transfer to reduce network load and increase speed.
  - --exclude 'lost+found'
    → Skips the lost+found directory (often present in ext file systems) to avoid unnecessary syncing.
  - -e "ssh -i /home/ubuntu/corextech.pem"
    → Uses SSH for secure data transfer with a specific private key (corextech.pem) for authentication.
  - /mydata/
    → Source directory on EC2-1 (local instance) to be synced.
  - ubuntu@172.31.0.110:/mydata/
    → Destination path on EC2-2 (remote instance) where the data will be copied.

🔐 This command securely:

Connects to EC2-2 using SSH (-e "ssh -i corextech.pem")
Transfers /mydata/ebs-test.txt from EC2-1 to /mydata directory on EC2-2
Maintains file permissions, timestamps, and compression during transfer

📤 After running, you’ll see output like:

Step 8️⃣: Rsync Transfer Completed Successfully

After running the rsync command from EC2-1, we accessed EC2-2 to confirm the file transfer was successful.

We verified it using the following commands in EC2-2:

ls -l /mydata

This listed the contents of /mydata, showing that the file ebs-test.txt was present.

cat /mydata/ebs-test.txt

✅ Success! We have now securely and efficiently transferred a file between two EC2 instances using rsync over SSH.

✅ Conclusion

By following the above steps, we successfully transferred a file from one EC2 instance to another using rsync over SSH. This method is secure, efficient, and ideal for syncing files between servers with minimal overhead. It's a must-have skill for any DevOps or Cloud Engineer working with AWS infrastructure.

👨‍💻 About the Author

This series isn't just about using AWS; it's about mastering the core services that power modern cloud infrastructure.

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

🚀 Automating Nginx & Custom Scripts with Cronjobs on EC2 Ubuntu

Gujjar Apurv — Sun, 20 Jul 2025 11:44:37 GMT

Modern server management in the cloud demands repeatability and automation. As part of my DevOps skill development, I successfully set up an AWS EC2 instance, deployed an Nginx web server, automated server maintenance using cronjobs, and built custom shell scripts for scheduled tasks. This blog details my hands-on journey, professional approach, and practical learnings

🟢 . Cron Time Format Explanation

# ┌───────────── minute (0 - 59)
# │ ┌───────────── hour (0 - 23)
# │ │ ┌───────────── day of month (1 - 31)
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of week (0 - 6) (Sunday=0 or 7)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *

🔧 Useful Crontab Commands for Linux Automation

Command	Description
`crontab -e`	Edit the current user’s crontab file to schedule tasks
`crontab -l`	List/show all scheduled cron jobs for the current user
`crontab -r`	Remove the current user’s crontab (all jobs)
`crontab -u -l`	View cron jobs of a specific user (run as root)
`sudo service cron status`	Check the status of the cron service
`sudo service cron start`	Start the cron service (if stopped)
`sudo service cron stop`	Stop the cron service
`sudo service cron restart`	Restart the cron service

📝 Task Objective

Goal:

Deploy and manage an AWS EC2 (Ubuntu) instance
Automate Nginx server installation and daily management
Schedule Nginx “restart” at 7 AM daily
Run a custom shell script every day at 2 AM using cronjobs
Achieve all objectives with pure automation—no manual intervention

1️⃣ Launching an EC2 Ubuntu Instance

OS: Ubuntu 22.04 LTS
Instance Type: t2.micro (Free Tier eligible)
Key Pair: Secure EC2 access using .pem SSH key
Security Group:
- Allow port 22 (SSH) for terminal access
- Allow port 80 (HTTP) for web access (Nginx)

Connect to your instance:

ssh -i "your-key.pem" ubuntu@your-ec2-public-ip

🧩 Step 2: Manually Installing and Verifying Nginx Web Server on EC2

After launching the EC2 instance, the next step was to manually install the Nginx web server. This helps in quickly testing server availability and basic connectivity.

⚙️ Commands Used for Nginx Installation

Below are the individual commands I executed one by one:

# Step 1: Update package list
sudo apt update

# Step 2: Install Nginx
sudo apt install nginx -y

# Step 3: Enable Nginx to start on boot
sudo systemctl enable nginx

# Step 4: Start Nginx service
sudo systemctl start nginx

# Step 5: Check Nginx service status
sudo systemctl status nginx

✅ How I Verified the Installation

Once the installation was successful:

I copied the public IPv4 address of the EC2 instance.
Opened it in a web browser like this:

http://

If everything is set up correctly, the default Nginx welcome page appears with the message:

🚀 Step 3: Creating the Shell Script (`myscript.sh`)

After setting up Nginx, the next part of the task was to create a shell script that performs a simple operation appending a timestamped log to a file every time it runs.

🔧 1. Open a new script file using Vim

First, I created a new shell script using the Vim editor by running the following command:

vim myscript.sh

This opened the Vim editor where I could write my script.

📝 2. Script Content

Inside the myscript.sh file, I added the following lines of code:

#!/bin/bash
echo "Script ran at $(date)" >> /home/ubuntu/myscript.log

📌 This script appends the current date and time to a log file named myscript.log located in the /home/ubuntu/ directory. Every time the script runs, a new entry is added to the log, which is useful for tracking execution.

💾 3. Save and Exit the File

To save and exit in Vim:

Press Esc
Then type :wq and hit Enter

This saves the script and brings you back to the terminal.

✅ 4. Make the Script Executable

Before we can run the script manually or via a cron job, we need to give it executable permissions. I used the following command:

chmod +x myscript.sh

Now the script is ready to be run manually or scheduled using cron in the next step.

Fixing Permission Error (optional step)

When I tried to run myscript.sh, I got a "Permission denied" error because the log file /home/ubuntu/myscript.log was owned by the root user. This prevented the script from writing to the file.

To fix this issue, I followed these steps:

Noticed the permission error related to myscript.log.
Checked the file ownership it was owned by root.
Changed the ownership from root to the ubuntu user using chown.
After that, the script executed successfully and started logging entries as expected.

🕓 Step 4: Automating Tasks Using Cron Jobs

One of the most powerful aspects of Linux-based systems is automation — and Cron Jobs are the go-to solution for scheduling repetitive system-level tasks. In this step, I utilized cron to automate essential backend processes on my EC2 instance.

✅ Automation Goals for This Project

As per the task requirements, I needed to automate the following:

🔁 Restart the Nginx service daily at 7:00 AM
📜 Run a custom shell script daily at 2:00 AM
🧪 (Optional) Test cron functionality by logging timestamps every minute

🛠️ Editing the Crontab

To configure these cron jobs, I used the crontab utility:

crontab -e

📝 On first run, it prompts to choose an editor — I went with vim, since I’m already comfortable using it.

📄 Cron Job Entries I Added

# Restart Nginx at 7 AM daily
0 7 * * * /bin/systemctl restart nginx

# Run your script at 2 AM daily
0 2 * * * /home/ubuntu/myscript.sh

# Test Cron (runs every minute) - for debugging only
* * * * * echo "Cron Working ✅ $(date)" >> /home/ubuntu/testcron.log

📌 What Each Cron Job Does

Time	Task Description	Command Executed
`0 7 * * *`	Daily at 7:00 AM	Restarts the Nginx service via `systemctl`
`0 2 * * *`	Daily at 2:00 AM	Executes the custom script `myscript.sh`
`* * * * *`	Every minute (for testing/debug only)	Appends a timestamp to `/home/ubuntu/testcron.log`

🔍 Verifying If Cron Jobs Are Working

To check the test cron job, I opened the log file:

cat /home/ubuntu/testcron.log

If successful, you’ll see output like this — a new line for every minute passed:

🔍 Viewing Scheduled Cron Jobs Using `crontab -l`

When working with automated scripts or scheduled tasks in Linux, cron jobs become your best friend. But what if you want to check which cron jobs are already scheduled? That’s where the simple yet powerful command comes in

✅ Command:

crontab -l

📌 What it does:

This command lists all the cron jobs currently scheduled for the logged-in user.

📊 Confirming Cron Daemon Status

To ensure that the cron service is running correctly, I checked its status using:

sudo systemctl status cron

✅ The output showed:

Status: Active (running)
Logs confirming each cron job run

✅ Conclusion:-

In this task, I demonstrated how to automate tasks using cron jobs on an Ubuntu server. Starting from manually installing Nginx, writing a shell script using vim, assigning it to crontab, and verifying the scheduled jobs ,this step-by-step guide helps streamline repetitive processes efficiently. Crontab is a powerful Linux utility to schedule scripts, system maintenance, backups, and more ultimately enhancing productivity and automation.

👨‍💻 About the Author

This series isn't just about using AWS; it's about mastering the core services that power modern cloud infrastructure.

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

"Building a Scalable AWS Network Architecture with Transit Gateway"

Gujjar Apurv — Thu, 17 Jul 2025 14:30:55 GMT

🚀 In this blog, we’ll walk through how to connect multiple Amazon VPCs using AWS Transit Gateway, allowing EC2 instances in different VPCs to communicate with each other. This is useful in scenarios where you need scalable, centralized connectivity across multiple VPCs.

📌 Task Breakdown

Here's what we are going to do:

Create 3 different VPCs in the same region
Launch 1 EC2 instance in each VPC
Create a Transit Gateway
Attach all 3 VPCs to the Transit Gateway
Update route tables and security groups
Test connectivity between EC2 instances

🛠️ Step 1: Create 3 VPCs in the Same Region

We’ll create 3 VPCs with non-overlapping CIDR ranges.

Actions:

Go to VPC Dashboard > Create VPC
Select VPC only option
Create VPCs with following CIDRs:
- VPC-1: 10.1.0.0/16
- VPC-2: 10.2.0.0/16
- VPC-3: 10.3.0.0/16
Enable DNS Hostnames

Repeat the above step for all 3 VPCs.

🧱 Step 2 : - Create Subnets for Each VPC

🔹 Subnet Creation for VPC-1

Go to: VPC Dashboard > Subnets > Create Subnet
Fill the details:
- Name tag: Sub1
- VPC: Select VPC-1
- Availability Zone: e.g., ap-south-1a
- IPv4 CIDR block: 10.1.0.0/24
Click Create Subnet

Repeat same for:

🔹 VPC-2:

Name tag: Sub2
VPC: VPC-2
AZ: ap-south-1a
CIDR: 10.1.2.0/24

🔹 VPC-3:

Name tag: Sub3
VPC: VPC-3
AZ: ap-south-1a
CIDR: 0.1.3.0/24

🚀 Step 3: Launch EC2 Instances and Configure Subnets

In this step, I launched three EC2 instances and mapped them according to the subnets we created earlier.

🔹 Instance Configuration Summary:

Instance	Subnet Type	Public IP Auto-Assign	Purpose
EC2-1	Public Subnet	Enabled	Acts as Public Server
EC2-2	Private Subnet 1	Disabled	Backend/Private
EC2-3	Private Subnet 2	Disabled	Backend/Private

🚏 Step 4: Create and Attach Transit Gateway

To enable communication between multiple VPCs, I created a Transit Gateway (TGW) and attached it to all three VPCs.

🔧 Steps Performed:

Created a Transit Gateway from the VPC Dashboard.
Attached the Transit Gateway to the following VPCs:
- VPC-1 (contains the public EC2 instance)
- VPC-2 (contains private EC2 instance)
- VPC-3 (contains another private EC2 instance)
This setup allows centralized routing and enables communication between all EC2 instances across VPCs via the Transit Gateway.

I used this method to avoid the complexity of VPC Peering and simplify inter-VPC networking.

🌐 Step 5: Making VPC-1 Public using Internet Gateway

To allow internet access for the EC2 instance in VPC-1, I made one of its subnets public by attaching an Internet Gateway (IGW).

🔧 Steps Performed:

Created an Internet Gateway (IGW).
Attached the IGW to VPC-1.
In the route table of VPC-1, associated only Subnet-1 (which contains the public EC2 instance).
Added a route in the route table with:
- Destination: 0.0.0.0/0
- Target: Internet Gateway

With this setup, only Subnet-11 has internet access, keeping other subnets private.

🔁 Step 6: Configuring Route Tables for Inter-VPC Communication via Transit Gateway

To enable communication between the three VPCs using the Transit Gateway (TGW), I updated each VPC’s route table as follows:

🛣️ VPC-1 Route Table:

Destination: CIDR of VPC-2 → Target: Transit Gateway
Destination: CIDR of VPC-3 → Target: Transit Gateway

🛣️ VPC-2 Route Table:

Destination: CIDR of VPC-1 → Target: Transit Gateway
Destination: CIDR of VPC-3 → Target: Transit Gateway

🛣️ VPC-3 Route Table:

Destination: CIDR of VPC-1 → Target: Transit Gateway
Destination: CIDR of VPC-2 → Target: Transit Gateway

📌 Note: I used each VPC’s CIDR block (e.g., 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16) as the destination in the respective route tables.

🔒 Step 7: Updating Security Groups to Allow All Traffic (For Testing Only)

To ensure temporary connectivity between EC2 instances across VPC-1, VPC-2, and VPC-3 during Transit Gateway testing, I updated the Security Groups (SGs) as follows:

Inbound Rules:
- Type: All Traffic
- Protocol: All
- Port Range: All
- Source: 0.0.0.0/0 or respective VPC CIDR blocks
Outbound Rules:
- Type: All Traffic
- Protocol: All
- Port Range: All
- Destination: 0.0.0.0/0 or respective VPC CIDR blocks

⚠️ Note:
Allowing All Traffic (0.0.0.0/0) is not recommended for production environments.
This is done here only for understanding and testing purposes.
In real-world setups, always apply principle of least privilege for better security.

✅ Final Step: Ping Test for Verification

Finally, I logged into EC2-1 (Public Server in VPC-1) and pinged the private IPs of EC2-2 (Private Server in VPC-2) and EC2-3 (Private Server in VPC-3).
The ping was successful, which confirms that communication between all VPCs is properly set up through the Transit Gateway.

🔒 Note:
Allowing All Traffic in the Security Group was done only for testing and learning purposes.
This is not a recommended practice in production. Always apply least privilege security rules.

✅ Final Wrap-Up: Transit Gateway Task

In this quick networking task, I configured 3 separate VPCs and successfully connected them using a single Transit Gateway.
Key highlights:

VPC-1 was made public via an Internet Gateway and a public subnet.
Proper route tables were updated in all VPCs to route traffic through the Transit Gateway.
Security Groups were temporarily set to allow all traffic for testing (⚠️ Not recommended for production).
Finally, from the public EC2 in VPC-1, I was able to ping the private EC2 instances in VPC-2 and VPC-3.

✔️ Result: Smooth inter-VPC communication confirmed via Transit Gateway setup.

👨‍💻 About the Author

This series isn't just about using AWS; it's about mastering the core services that power modern cloud infrastructure.

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

🌐 Deploying a 3-Tier Web Application Architecture on AWS using VPC

Gujjar Apurv — Thu, 17 Jul 2025 07:23:51 GMT

In this project, I have designed and deployed a 3-Tier Web Application architecture within a custom Virtual Private Cloud (VPC) using AWS services. This architecture follows industry best practices for security, scalability, and separation of concerns

🔒 Secure | ⚙️ Modular | ☁️ AWS-Powered

In this blog, I’ll demonstrate how I deployed a 3-tier application on AWS using custom VPC. This architecture includes:

Nginx as a Reverse Proxy (Web Layer)
Apache Tomcat as the Application Server
MySQL as the Database Server

🧱 What is 3-Tier Architecture?

A 3-tier architecture separates the app into:

Web Tier (Nginx) – Handles incoming HTTP requests
App Tier (Tomcat) – Runs backend application logic
DB Tier (MySQL) – Stores application data

🔧 Tech Stack & AWS Services Used

Layer	Component	AWS Service
Web	Nginx	EC2 in Public Subnet
App	Tomcat	EC2 in Private Subnet
DB	MySQL	EC2 in Private Subnet
Network	VPC, Subnets, Route Tables	AWS VPC
Others	NAT Gateway, IGW, SGs	AWS Infra

🗺️ High-Level Architecture Diagram

This setup includes:

1 Public Subnet for Nginx
2 Private Subnets: App Tier (Tomcat) and DB Tier (MySQL)
Security Groups with limited, directional access
NAT Gateway for outbound internet access from private subnets

🪜 Step-by-Step Implementation

✅ Step 1: Create VPC

CIDR Block: 10.1.0.0/16

✅ Step 2: Create Subnets

10.1.1.0/24 – Public (Web: Nginx)
10.1.2.0/24 – Private (App: Tomcat)
10.1.3.0/24 – Private (DB: MySQL)

✅ Step 3: Setup Internet Gateway + NAT

IGW for public subnet (Nginx)
NAT Gateway for public subnets (Web)

✅ Step 4: Configure Route Tables

Public Route Table: 0.0.0.0/0 → IGW
Private Route Table: 0.0.0.0/0 → NAT

✅ A. Public Route Table Configuration

I created a Route Table named web-rt.
I associated the public subnet (used for Nginx) with this web-rt.
Then, I edited the route in web-rt:
- Destination: 0.0.0.0/0 (this allows internet traffic)
- Target: Internet Gateway (attached to the VPC)
This allows public instances like Nginx server to access the internet directly.

🔒 B. Private Route Table Configuration

I created another Route Table named private-rt.
I associated both private subnets (one for Tomcat app and one for MySQL DB) with this private-rt.
Then, I edited the route in private-rt:
- Destination: 0.0.0.0/0
- Target: NAT Gateway (deployed in the public subnet)
This setup allows private instances to access the internet only for updates (e.g., apt install), without being exposed to incoming public traffic.

✅ Step 5: Launch EC2 Instances

🌍 Web Tier (Nginx)

EC2 in public subnet
Installed Nginx
Acts as Reverse Proxy forwarding to Tomcat
SG allows ports: 80 (HTTP) and 8080 (proxy)

🛡 Bastion Host

EC2 in public subnet for SSH access to private EC2s
SG allows port: 22

⚙ App Tier (Tomcat)

EC2 in private subnet
Installed Apache Tomcat
SG allows traffic only from Nginx EC2 (Web SG)

💾 DB Tier (MySQL)

EC2 in private subnet
Installed MySQL, secured
SG allows port 3306 only from App Server

🔐 Step 3: Private Server Access via Public EC2 (Jump Server Method)

Since App and DB servers are in private subnets, I used the Web Server (Public EC2) as a jump host to access them.

Steps Followed:

SSH into Public Web Server using .pem file:
```
 ssh -i "my-key.pem" ubuntu@
```
Created a new file using:
```
 vim jump.pem
```
Pasted the private key of the internal servers (App/DB) in jump.pem.
Changed permission:
```
 chmod 400 jump.pem
```

Then, from the public server, logged in to private server:

 ssh -i jump.pem ubuntu@10.1.2.97  # App Server
 ssh -i jump.pem ubuntu@10.1.3.105 # DB Server

✅ This way, I securely accessed private servers using the public EC2 as a jump point.

🌐 Nginx Installation on Web EC2 Instance (Public Subnet)

After launching the Web EC2 instance (in the public subnet), I connected to it using SSH with the default Ubuntu user. Then I installed and configured Nginx as follows:

🔧 Steps Performed:

SSH into EC2 Instance:
```
 ssh -i "keypair.pem" ubuntu@-IP>
```
Update the System Packages:
```
 sudo apt update -y
```
Install Nginx Web Server:
```
 sudo apt install nginx -y
```
Start the Nginx Service:
```
 sudo systemctl start nginx
```
Enable Nginx to Start on Boot:
```
 sudo systemctl enable nginx
```

🚀 Tomcat Installation on App EC2 Instance (Private Subnet)

On the App Server EC2 instance (launched in the private subnet), I installed and started Apache Tomcat to host Java-based web applications.

Since Tomcat requires Java, I installed JDK first, then downloaded and configured Tomcat.

🔧 Steps Performed:

Update System Packages:
```
 sudo apt update -y
```
Install Java Development Kit (Required for Tomcat):
```
 sudo apt install default-jdk -y
```

Download the Latest Tomcat (Version 11.0.9):

 wget https://downloads.apache.org/tomcat/tomcat-11/v11.0.9/bin/apache-tomcat-11.0.9.tar.gz.asc

Extract the Downloaded Archive:
```
 tar -xvzf apache-tomcat-11.0.9.tar.gz
```

Start the Tomcat Server:

 ls
 cd apache-tomcat-11.0.9.tar.gz
 ls
 cd bin
 ./startup.sh

🛢️ MySQL Installation on DB EC2 Instance (Private Subnet)

On the Database Server EC2 instance (placed in the private subnet), I installed MySQL Server to manage the backend database of the application securely.

🔧 Steps Performed:

Update System Packages:
```
 sudo apt update -y
```
Install MySQL Server:
```
 sudo apt install mysql-server -y
```

Start and Enable MySQL Service:

 sudo systemctl start mysql
 sudo systemctl enable mysql

⚙️ MySQL Configuration on DB EC2 (Private Subnet)

After installing MySQL on the DB Server (private subnet), I performed additional configuration to allow internal app server access by setting the bind-address to the server’s private IP.

To securely access MySQL, I logged in using the root user:

sudo mysql -u root -p

(You’ll be prompted to enter the root password set during secure installation.)

🛠️ Step 2: Edit MySQL Configuration File

I modified the MySQL bind-address to allow access from the app server (within the VPC):

sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf

Inside this file, I located the following line:

bind-address = 127.0.0.1

And changed it to my DB EC2’s private IP, for example:

bind-address = 10.0.2.15

✅ This step ensures MySQL accepts connections only from internal sources (e.g., the app server), not from the public internet — keeping the database secure.

🔄 Step 3: Restart MySQL to Apply Changes

sudo systemctl restart mysql

🔗 Network Connectivity Testing (Ping & Telnet)

To ensure all the instances in my 3-tier architecture (Web, App, and DB) are properly connected and communicating within the VPC, I performed two essential network checks:

✅ 1. Ping Test (Initial Connectivity Verification)

Before running any application-level commands, I verified the basic connectivity between all EC2 instances using ping.

From Web (10.1.1.44):
- Ping to App server (10.1.2.97)
- Ping to DB server (10.1.3.105)
From App (10.1.2.97):
- Ping to Web server (10.1.1.44)
- Ping to DB server (10.1.3.105)
From DB (10.1.3.105):
- Ping to Web server (10.1.1.44)
- Ping to App server (10.1.2.97)

📝 All ping tests were successful, confirming that the subnet routing and security group rules were correctly configured for basic communication.

✅ Verifying Internal Connectivity using Telnet in 3-Tier Architecture

To ensure all components in the 3-Tier Architecture (Web, App, and DB) can communicate with each other, we use the telnet command to test port-level connectivity.

Below is how each instance should verify connection with others using Telnet:

🔹 From Web Server (Public Subnet - IP: `10.1.1.44`)

Check connectivity to App Server (Tomcat):
```
  telnet 10.1.2.97 8080
```
Check connectivity to Database Server (MySQL):
```
  telnet 10.1.3.105 3306
```

🔹 From App Server (Private Subnet - IP: `10.1.2.97`)

Check connectivity to Web Server:
```
  telnet 10.1.1.44 22
```
Check connectivity to Database Server:
```
  telnet 10.1.3.105 3306
```

🔹 From DB Server (Private Subnet - IP: `10.1.3.105`)

Check connectivity to Web Server:
```
  telnet 10.1.1.44 22
```
Check connectivity to App Server:
```
  telnet 10.1.2.97 8080
```

✅ If Telnet successfully connects (i.e., blank screen or "Connected"), it confirms that the port is open and reachable from that instance.

❌ If Telnet fails (i.e., "Connection refused" or "Unable to connect"), check Security Groups, NACLs, and Routing Tables.

📝 Conclusion

This project demonstrates a successful deployment of a secure and scalable 3-tier architecture on AWS using Nginx (Web), Tomcat (App), and MySQL (DB).
It follows best practices for network isolation, access control, and modular application deployment in a cloud environment.

👨‍💻 About the Author

This project is a deep dive into the AWS ecosystem designed to strengthen my foundation in cloud-native architecture, automation, and service integration using only AWS services.

This series isn't just about using AWS; it's about mastering the core services that power modern cloud infrastructure.

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

💡 If you found this project useful, or have any suggestions or feedback, feel free to reach out or drop a comment I’d love to connect and improve.
This is just the beginning many more builds, deployments, and learnings ahead.

"Mastering AWS EC2 and EBS: Attach, Mount, Snapshot & Access Data Across Availability Zones"

Gujjar Apurv — Sat, 12 Jul 2025 02:30:28 GMT

🔰 Introduction

This blog is a practical guide to using Amazon EC2 and EBS together. You'll learn how to attach an extra EBS volume to an EC2 instance, mount and store data, and create a snapshot to access that data from another Availability Zone. It's a complete hands-on tutorial for real-world AWS scenarios like data backup, high availability, and cross-AZ storage access perfect for beginners and DevOps learners.

🧠 What You'll Do

Launch an EC2 instance
Attach an EBS volume
Format and mount it
Add sample data
Create a snapshot
Create a volume in another AZ using that snapshot
Attach to a new EC2 instance
Access the same data cross-AZ

🟢 Step 1: Launch EC2 Instance

Go to AWS Console > EC2 > Launch Instance
Set:
- Name: ebs-task-instance
- AMI: Amazon Linux 2
- Instance Type: t2.micro
- Key Pair: Create or choose existing
- Subnet: e.g., us-east-1c
- Auto-assign Public IP: Enabled
- Security Group: Allow SSH (22), HTTP (80) optional
Keep default 8 GiB EBS
Click Launch
After instance is running, connect via:

ssh -i "aws-key.pem" ec2-user@-ip>

🟢 Step 2: Create and Attach EBS Volume

Go to EC2 > Volumes > Create Volume
Set:
- Size: 10 GiB
- Type: gp3
- AZ: us-east-1c (same as EC2)
Create Volume
Select volume → Actions > Attach Volume
Attach to instance as: /dev/sdf

🟢 Step 3: Format and Mount EBS Volume

Inside EC2:

lsblk                          # Check volume as /dev/xvdf
sudo mkfs -t ext4 /dev/xvdf   # Format volume
sudo mkdir /mnt/myvolume      # Create mount point
sudo mount /dev/xvdf /mnt/myvolume  # Mount volume

sudo mkfs -t ext4 /dev/xvdf
🔹 Formats the volume /dev/xvdf with the ext4 filesystem.
sudo mkdir /mnt/myvolume
🔹 Creates a directory to serve as a mount point for the volume.
sudo mount /dev/xvdf /mnt/myvolume
🔹 Mounts the formatted volume to the mount point directory /mnt/myvolume.

🟢 Step 4: Add Sample Data

echo "Hello from Apurv's AWS Volume!" | sudo tee /mnt/myvolume/data.txt
cat /mnt/myvolume/data.txt     # Verify file

🟢 Step 5: Create Snapshot of Volume

Go to EC2 > Volumes
Select volume → Actions > Create Snapshot
Set:
- Name: data-snapshot
- Description: Snapshot for cross-AZ access
Click Create Snapshot

🟢 Step 6: Create Volume in Another AZ from Snapshot

Go to EC2 > Snapshots
Select snapshot → Actions > Create Volume
Set:
- AZ: us-east-1a (different from original)
- Size: 10 GiB
Create volume

🟢 Step 7: Launch Second EC2 in Target AZ

Launch another EC2 instance
Subnet: us-east-1a
Use same settings as Step 1

🟢 Step 8: Attach Snapshot-Based Volume

Go to EC2 > Volumes
Select new volume → Actions > Attach Volume
Attach to second EC2 as: /dev/sdf

🟢 Step 9: Mount and Access Data in 2nd EC2

Inside second EC2:

lsblk
sudo mkdir /mnt/myvolume
sudo mount /dev/xvdf /mnt/myvolume
cat /mnt/myvolume/data.txt    # You'll see the same data!

✅ Conclusion

In this blog, we covered a complete hands-on process of managing storage in AWS using EC2 and EBS. Starting from launching an EC2 instance, attaching a new EBS volume, formatting and mounting it, to writing custom data each step mirrors real-world AWS workflows.

We then created a snapshot of that volume, and used it to create a new volume in a different Availability Zone, proving that:

You can easily access your data from any Availability Zone in AWS by creating volumes from snapshots and attaching them to instances in the target AZ.

This process is not only useful for cross-AZ data access, but also essential for:

Disaster recovery
High availability setups
Data backups and migration

Whether you're preparing for AWS certification or building scalable cloud systems, mastering these EBS and EC2 operations is a foundational skill every cloud or DevOps engineer should have.

👨‍💻 About the Author

This project is a deep dive into the AWS ecosystem designed to strengthen my foundation in cloud-native architecture, automation, and service integration using only AWS services.

From launching EC2 instances, managing storage with S3 and EBS, configuring IAM for secure access, setting up VPCs and subnets, to automating infrastructure with CloudFormation each service I used brought real-world relevance and clarity to cloud concepts.

This series isn't just about using AWS; it's about mastering the core services that power modern cloud infrastructure.

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

💡 If you found this project useful, or have any suggestions or feedback, feel free to reach out or drop a comment I’d love to connect and improve.
This is just the beginning many more builds, deployments, and learnings ahead.

The Ultimate AWS EBS Workflow: EC2 Integration

Gujjar Apurv — Thu, 10 Jul 2025 04:27:08 GMT

📝 Abstract

In this guide, I demonstrate the complete lifecycle of working with AWS EC2 and EBS volumes starting from launching an EC2 instance and attaching a new EBS volume, to preserving data by disabling delete-on-termination.

You’ll also learn how to:

Recover EBS data after EC2 termination
Migrate EBS volumes across Availability Zones using snapshots
Copy snapshots across AWS Regions to restore data remotely

This end-to-end workflow ensures data durability, flexibility, and disaster recovery readiness for modern cloud infrastructure setups.

✅ Step 1: Launch an EC2 Instance

To begin, launch a new EC2 instance:

Go to the EC2 Dashboard in AWS Management Console.
Click on “Launch Instance”.
Select an appropriate AMI (Amazon Machine Image), such as Ubuntu or Amazon Linux.
Choose an instance type (e.g., t2.micro for testing or t3.medium for production).
In the network section, you can keep the default VPC and Subnet settings — AWS will automatically manage networking unless you have a custom setup.
Continue with key pair, storage, and security group settings.

Once launched, the EC2 instance will automatically have a root EBS volume attached.

🔒 Understanding the “Delete on Termination” Setting in EC2

When launching an EC2 instance, AWS automatically attaches a root EBS volume to store the operating system and configuration files. By default, this root volume is deleted when the instance is terminated — but you can control this behavior.

📌 Why it's important to uncheck “Delete on Termination”:

🔐 Preserve critical data: Prevents the root EBS volume from being deleted, even if the EC2 instance is terminated.
🔄 Easily recover configuration: Retain OS setup, logs, and installed packages for later use or migration.
💼 Safe for production use: Especially helpful in staging or production environments where instance termination is temporary or planned.
☁️ Avoid accidental data loss: Ensures your volume (and its data) remains available in the EBS → Volumes section after termination.
🔧 Attach to a new EC2: The preserved volume can be re-attached to any EC2 instance in the same Availability Zone for instant recovery.

As shown below, AWS automatically creates and attaches a root EBS volume when you launch an EC2 instance.

✅ Step 2: Create and Attach a New EBS Volume to Your EC2 Instance

After launching your EC2 instance, you may need extra storage. For that, you can create a new EBS volume and attach it.

🔧 Steps to Create:

Go to EC2 → Elastic Block Store → Volumes → Create Volume
Select Volume Type, Size, and most importantly, choose the same Availability Zone as your EC2 instance

📌 EBS volumes can only be attached to EC2 instances in the same Availability Zone

🔗 Steps to Attach:

After creation, select the volume → Click Actions → Attach Volume
Choose your EC2 instance and confirm the device name (e.g., /dev/xvdf)
Click Attach — your volume is now connected to the instance

✅ You’ll now need to format and mount the volume inside the EC2, which we’ll do in the next step.

✅ Our new EBS volume has been successfully created and is now ready to be attached to the EC2 instance.

📌 Go to Actions → Attach Volume, then select your EC2 instance to attach the volume.

✅ Step 3: Connect to EC2 and Mount the Attached EBS Volume

Once your EBS volume is attached, you need to connect to your EC2 instance and prepare the volume for use.

💻 Steps to Check and Mount:

SSH into your EC2 instance using terminal or any SSH client
(e.g., using .pem key file)
Run the following to verify attached volumes:
```
 lsblk
```

🧩 Step 4: Format the EBS Volume with ext4 File System

sudo mkfs -t ext4 /dev/xvdd

mkfs: Stands for “make file system” — used to format the disk.
-t ext4: Specifies the ext4 file system type (widely used in Linux).
/dev/xvdd: The name of the newly attached EBS volume.

📌 This command prepares the volume for storing files by formatting it.

📁 Step 5: Create a Mount Point

sudo mkdir /mydata

mkdir: Command to make a new directory.
/mydata: This directory will act as the mount point for the EBS volume.

📌 This is where your EBS volume will be accessible from.

🔗 Step 6: Mount the Volume

sudo mount /dev/xvdd /mydata

mount: Command to attach the volume to a directory.
/dev/xvdd: The formatted EBS volume.
/mydata: The directory where the volume will be mounted.

📌 This makes the volume usable like a local disk through /mydata.

📊 Step 7: Verify the Mount Status

df -h

df: Disk free — shows storage usage.
-h: Human-readable format (GB/MB).

📌 This helps confirm whether the EBS volume is mounted and shows its usage.

📝 Step 8: Write Data into the Mounted Volume

echo "This is task for EBS performed by Apurv Gujjar" | sudo tee /mydata/ebs-test.txt

echo: Prints the given message.
| sudo tee: Pipes the message into a file with root permissions.
/mydata/ebs-test.txt: The file to create inside the mounted volume.

📌 This command creates a test file in the EBS volume to validate it's writable.

🔍 Step 9: Check Stored Data

ls /mydata

ls: Lists all files and folders in the directory.
/mydata: The mount point where the volume is attached.

cat /mydata/ebs-test.txt

📌 Helps you verify that the file (ebs-test.txt) exists.

cat: Used to display file content in terminal.
/mydata/ebs-test.txt: The test file we just created.

📌 Confirms the file contains the correct data you wrote earlier.

👨‍💻 About the Author

This project is a deep dive into the AWS ecosystem designed to strengthen my foundation in cloud-native architecture, automation, and service integration using only AWS services.

From launching EC2 instances, managing storage with S3 and EBS, configuring IAM for secure access, setting up VPCs and subnets, to automating infrastructure with CloudFormation each service I used brought real-world relevance and clarity to cloud concepts.

This series isn't just about using AWS; it's about mastering the core services that power modern cloud infrastructure.

📬 Let's Stay Connected

📧 Email: gujjarapurv181@gmail.com
🐙 GitHub: github.com/ApurvGujjar07
💼 LinkedIn: linkedin.com/in/apurv-gujjar

💡 If you found this project useful, or have any suggestions or feedback, feel free to reach out or drop a comment I’d love to connect and improve.
This is just the beginning many more builds, deployments, and learnings ahead.

"Two-Tier Web App with Docker: Flask Frontend + MySQL Backend"

Gujjar Apurv — Tue, 08 Jul 2025 04:09:11 GMT

📘 Introduction

In this blog, I’ll walk you through how I deployed a two-tier Flask web application with a MySQL database using Docker containers on an AWS EC2 instance. This setup ensures container isolation, environment consistency, and real-time communication between the app and database via Docker networking.

By the end of this guide, your application will be accessible over the internet with just a public IP and a browser!

💡

🚀🚀 Check out the full project on my GitHub Repository

☁️ 1. Launching AWS EC2 Instance (Ubuntu)

Go to AWS EC2 Console.
Launch a new instance with the following:
- AMI: Ubuntu 20.04 or 22.04 LTS
- Instance Type: t2.micro (Free Tier)
- Storage: 8 GB or more
- Security Group Rules:
  - SSH (Port 22) – for terminal access
  - HTTP (Port 80) – optional
  - Custom TCP (Port 5000) – to access Flask App
Key pair: Create or use an existing one (e.g., my-key.pem)

✅ Connect to the instance:

ssh -i my-key.pem ubuntu@your-public-ip

🐳 2. Installing Docker and Git on Ubuntu

sudo apt update
sudo apt install -y docker.io 
sudo usermod -aG docker $USER && newgrp docker

1. sudo apt update
Updates the package list to fetch the latest versions available from repositories.

2. sudo apt install -y docker.io
Installs Docker Engine from Ubuntu’s default repository without asking for confirmation.

3. sudo usermod -aG docker $USER && newgrp docker
Adds your user to the Docker group so you can run Docker without sudo.

🔧 3. Cloning the Flask Project

clone https://github.com/ApurvGujjar07/Two-Tier-Flask-App-.git
cd two-tier-flask-app
ls

You’ll see files like app.py, Dockerfile, etc.

📦 4. Build Flask App Docker Image

docker build -t two-tier-backend .

This command packages the app into a Docker image named two-tier-backend.

🌐 5. Create Docker Network

docker network create mynetwork

This allows containers to communicate internally by name (DNS-style linking).

🐬 6. Run MySQL Container

docker run -d --name mysql --network mynetwork \
-e MYSQL_ROOT_PASSWORD=root \
-e MYSQL_DATABASE=devops \
mysql

✅ MySQL now runs and is ready for connection on the Docker network.

🚀 7. Run Flask App Container

docker run -d -p 5000:5000 --network mynetwork \
-e MYSQL_HOST=mysql \
-e MYSQL_USER=root \
-e MYSQL_PASSWORD=root \
-e MYSQL_DB=devops \
two-tier-backend:latest

Your Flask app is now running and mapped to port 5000 of your EC2 instance.

🔍 8. Verify Everything is Working

Check running containers

🌐 9. Access App in Browser

Go to AWS Console → Security Groups
Add inbound rule:
- Type: Custom TCP
- Port: 5000
- Source: Anywhere (0.0.0.0/0)

Then visit:
🌍 http://:5000

✅ You should see the live Flask web app now!

Connect to MySQL and verify DB:

docker exec -it mysql mysql -u root -p
# Enter: root

Then run:

SHOW DATABASES;
USE devops;
SHOW TABLES;
SELECT * FROM messages;

🧠 Conclusion

In this blog, I demonstrated how to:

Launch an EC2 instance
Install and configure Docker
Deploy a two-tier Flask + MySQL app
Connect containers via Docker network
Expose the app publicly via port 5000

This is a solid DevOps practice project showing real-world containerization, networking, and deployment skills.

👨‍💻 About the Author

Hi, I'm Apurv Gujjar, a passionate and aspiring DevOps Engineer.
"This project marks the beginning of my journey into the world of DevOps, containerization, and cloud-native application deployment."

The OpsVerse with Apurv

🚀 Terraform Series – Day 8

🎯 Objective

🧩 Step 1: Understanding the Power of user_data

The Solution: Bootstrap Scripts

📄 Step 2: Create the Bootstrapping Script (nginx.sh)

Terraform testing with scripting

🔗 Step 3: Attach the Script in Terraform

⚙️ Step 4: Execute the Pipeline

What happens internally?

🧪 Testing: Verify NGINX on EC2 Instance

🔹 Step 1: Connect to EC2 via SSH

🔹 Step 2: Check NGINX Status

🔹 Step 3: Test via Browser

🔹 Step 5: Test via Curl (CLI Testing)

🔹 Step 6: Check Port 80 (Important for DevOps)

💡 Key Takeaways

👨‍💻 About the Author

📬 Let's Stay Connected

🚀 Terraform Series – Day 7

🧩 Step 1: The Real Problem

💡 Step 2: The Smart Solution → Variables

✔ Why Variables?

📄 Step 3: Create variables.tf

🔗 Step 4: Use Variables in ec2.tf

🔄 Step 5: Real Power of Variables

📤 Step 6: Now Let’s Talk About Outputs

😓 Problem

💡 Solution → Outputs

📄 Step 7: Create outputs.tf

🧠 What Happens Now?

👨‍💻 About the Author

📬 Let's Stay Connected

🚀 Terraform Series – Day 6

🎯 Objective

🧩 Step 1: Generate SSH Key

📄 Step 2: Create Terraform File

⚙️ Step 4: Initialize Terraform

✅ Step 5: Validate Configuration

📊 Step 6: Plan Execution

🚀 Step 7: Apply (Create Infrastructure)

❌ Common Error: Not Authorized

🖥 Step 8: Verify in AWS Console

🔐 Step 9: Fix Key Permission

🔗 Step 10: Connect to EC2

🧹 Step 11: Destroy Resources (IMPORTANT)

👨‍💻 About the Author

📬 Let's Stay Connected

🚀 Terraform Series – Day 5

Terraform Providers, Resource Types & Naming

🧠 1. Understanding Terraform Resource Structure

📌 Example:

🔍 Deep Breakdown:

⚡ Important Insight:

🌐 2. What is a Provider in Terraform?

🔧 Why Providers are Needed?

📌 Popular Providers:

⚡ Real-Life Analogy:

⚙️ 3. Ways to Use Providers in Terraform

🔹 Method 1: Implicit Provider (Automatic Way) ✅

🔍 What Happens Behind the Scenes?

▶️ Steps:

👍 When to Use:

🔹 Method 2: Explicit Provider (Declarative Way) ✅

📌 Step 2: Initialize

🔍 What Happens:

👍 When to Use:

⚡ 4. Implicit vs Explicit (Quick Understanding)

Implicit:

Explicit:

🚀 5. Pro Tips (Important for DevOps)

📌 Final Summary

🔥 Conclusion

👨‍💻 About the Author

📬 Let's Stay Connected

🚀 Terraform Series – Day 4

Terraform Workflow: init, validate, plan, apply & destroy

🧠 Before Starting (AWS Setup)

🎯 Objective

🧱 Step 0: Create Terraform Configuration File

🧩 Step 1: Understanding the Power of `user_data`

📄 Step 2: Create the Bootstrapping Script (`nginx.sh`)

📄 Step 3: Create `variables.tf`

🔗 Step 4: Use Variables in `ec2.tf`

📄 Step 7: Create `outputs.tf`

🔑 Understanding the `bind-address` in MariaDB for ERPNext