DEV Community: Avinash wagh

🚀 Day 10 of My Cloud Journey: Setting Up Kubernetes with Kind & kubectl on AWS EC2

Avinash wagh — Mon, 30 Mar 2026 03:45:16 +0000

After getting hands-on with Docker, the next natural step in my journey was Kubernetes — the backbone of modern container orchestration.

Today, I took my first step into Kubernetes by setting up a cluster using Kind and kubectl on an AWS EC2 instance ☁️

🧩 Why Kubernetes?

While Docker helps us run containers, managing multiple containers across environments becomes complex.

👉 That’s where Kubernetes comes in:

Automates deployment and scaling
Ensures high availability
Manages container lifecycle efficiently

This is exactly what real-world systems use in production.

⚙️ My Setup (AWS EC2)

Instead of using local machine, I chose AWS EC2 to simulate a real-world environment.

🔹 Why EC2?

Closer to production setup
Better for remote access and testing
Helps understand cloud infrastructure

🛠️ Tools I Installed

1. kubectl (Kubernetes CLI)

kubectl is the command-line tool used to interact with Kubernetes clusters.

🔹 Install latest version:

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

🔹 Verify:

kubectl version --client

2. Kind (Kubernetes in Docker)

Kind allows us to run Kubernetes clusters inside Docker containers.

🔹 Install stable version:

curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.31.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

🔹 Verify:

kind --version

🚀 Creating My First Kubernetes Cluster

Once both tools were installed, I created my first cluster:

kind create cluster

⏳ It took a couple of minutes to set up everything automatically.

✅ Verifying the Cluster

kubectl get nodes

Output:

kind-control-plane   Ready   control-plane

✔️ My Kubernetes cluster is now up and running!

🔥 First Deployment (Nginx)

To test everything, I deployed a simple Nginx application:

kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --type=NodePort --port=80

Check resources:

kubectl get pods
kubectl get svc

🌐 Accessing the Application

Since I'm using EC2, I used port forwarding:

kubectl port-forward service/nginx 8080:80

Now accessible via:
👉 http://:8080

💡 Key Takeaways

kubectl is used to interact with Kubernetes
Kind makes it easy to run local clusters using Docker
Kubernetes abstracts infrastructure and manages containers efficiently
Setting up on EC2 gives a more real-world experience

🔄 My Learning Reflection

Today’s learning shifted my mindset from:

👉 “Running containers with Docker”
to
👉 “Orchestrating containers using Kubernetes”

This feels like a big step toward becoming a Cloud/DevOps Engineer 🚀

📘 Learning in Public

I’m documenting my journey as I transition from .NET Developer to Cloud Engineer.

🔗 LinkedIn → https://www.linkedin.com/in/avinashwagh-
🔗 GitHub → https://github.com/Avinash8600

💬 Let’s Connect

If you're learning Kubernetes, DevOps, or Cloud — let’s grow together 🙌

Would love feedback, suggestions, or tips from the community!

🚀 Day 9 of My Cloud Journey: Mastering Docker Volumes, Compose & Registry

Avinash wagh — Tue, 24 Mar 2026 04:44:12 +0000

When I started learning Docker, running containers felt exciting. But very quickly, I ran into a practical question:

👉 What happens to my data when a container stops or gets deleted?

That’s when I realized — containers are ephemeral by design, and real-world applications need persistent storage, multi-service orchestration, and efficient image management.

So today, I explored three critical Docker concepts:
Volumes, Docker Compose, and Docker Registry 🐳

🧩 Why This Matters

In modern cloud applications, we rarely run a single container. Instead, we deal with:

Databases that must retain data
Backend and frontend services running together
Applications deployed across environments

Handling all this manually is not scalable. Docker provides powerful solutions to simplify these challenges.

📦 1. Understanding Docker Volumes (Persistent Storage)

Containers are temporary, but data should not be.

Docker Volumes solve this problem by storing data outside the container lifecycle.

🔹 What I Learned

Volumes persist data even if containers are removed
They are managed by Docker and are more reliable than container storage
Ideal for databases like MySQL, PostgreSQL, etc.

🔹 Hands-on

docker volume create my-volume

docker run -d \
  --name mysql-db \
  -v my-volume:/var/lib/mysql \
  mysql

✔️ Even after removing the container, the data remains safe

⚙️ 2. Docker Compose (Managing Multi-Container Apps)

Running multiple containers manually can quickly become messy.

Docker Compose allows us to define and manage multi-container applications using a single YAML file.

🔹 What I Learned

Define services, networks, and volumes in one place
Start all services with a single command
Makes development and testing much easier

🔹 Sample `docker-compose.yml`

version: '3'
services:
  db:
    image: mysql
    container_name: mysql-db
    environment:
      MYSQL_ROOT_PASSWORD: root
    volumes:
      - db-data:/var/lib/mysql

  app:
    image: flask-app
    container_name: flask-app
    ports:
      - "5000:5000"
    depends_on:
      - db

volumes:
  db-data:

▶️ Run everything

docker compose up -d

✔️ Multiple services running together with one command

🌐 3. Docker Registry (Image Management)

Once applications are built, they need to be shared and deployed.

Docker Registry helps store and distribute images across environments.

🔹 What I Learned

Images can be pushed to repositories like Docker Hub
Enables easy deployment across teams and servers
Versioning helps manage application updates

🔹 Basic Workflow

docker tag my-app username/my-app
docker push username/my-app
docker pull username/my-app

✔️ Simplifies deployment and collaboration

💡 Key Takeaways

Volumes ensure data persistence
Docker Compose simplifies multi-container orchestration
Registry enables image sharing and deployment
These concepts are essential for real-world DevOps and cloud environments

🔄 My Learning Reflection

Today’s learning shifted my mindset from:
👉 “Running containers”
to
👉 “Designing real-world, scalable applications using Docker”

I’m starting to see how these concepts connect to tools like Kubernetes and cloud platforms like AWS.

📘 Learning in Public

I’m documenting my journey as I transition from .NET Developer to Cloud Engineer.

LinkedIn → https://www.linkedin.com/in/avinashwagh-
GitHub → https://github.com/Avinash8600

💬 Let’s Connect

If you're learning Docker, DevOps, or Cloud — I’d love to connect, learn, and grow together.

Feedback and suggestions are always welcome 🙌

🚀Deployed a Containerized Flask Message App on AWS EC2 using Docker

Avinash wagh — Wed, 18 Mar 2026 04:21:32 +0000

In this article, I’ll walk through how I built and deployed a containerized Message Board Web Application using Python Flask and MySQL on AWS EC2. This project helped me gain hands-on experience with Docker, cloud deployment, and backend development.

📌 Project Overview

The application is a simple message board where users can:

Add messages
Delete messages
Store data in a MySQL database

Both the application and database are containerized using Docker and communicate over a shared network.

🛠️ Tech Stack

Python
Flask
MySQL
Docker
AWS EC2
Linux

🏗️ Architecture

The project consists of two main containers:

Flask Application Container
MySQL Database Container

These containers are connected via a custom Docker network:

message-network

The Flask app connects to MySQL using the container name (mysql-db) as the hostname.

⚙️ Step-by-Step Implementation

1️⃣ Create Docker Network

docker network create message-network

2️⃣ Run MySQL Container

docker run -d \
--name mysql-db \
--network message-network \
-e MYSQL_ROOT_PASSWORD=root \
-e MYSQL_DATABASE=messagedb \
mysql:8

3️⃣ Build Flask App Image

docker build -t flask-message-app .

4️⃣ Run Flask Container

docker run -d \
-p 5001:5001 \
--network message-network \
--name flask-app \
flask-message-app

🌐 Deployment on AWS EC2

I deployed this project on an AWS EC2 instance by:

Launching a Linux-based EC2 instance
Installing Docker
Running both containers inside the instance
Configuring the Security Group to allow inbound traffic on port 5001

🔗 Live Demo

🌐 http://13.235.243.101:5001

📷 Screenshots

Web Application UI

Mobile View

Running Docker Containers

MySQL Database Table

📚 Key Learnings

Understanding Docker containerization
Managing multi-container applications
Setting up Docker networks for communication
Deploying applications on AWS EC2
Troubleshooting real-world issues

🚀 Future Improvements

Add message timestamps
Implement edit functionality
Use Docker Compose
Add Nginx reverse proxy
Set up CI/CD pipeline

🔗 GitHub Repository

👉 https://github.com/Avinash8600/containerized-flask-message-app

👨‍💻 About Me

I’m a Software Engineer with a focus on Cloud and DevOps, passionate about building and deploying scalable applications.

💬 Conclusion

This project was a great hands-on experience in combining backend development with cloud and containerization technologies. It helped me understand how real-world applications are deployed and managed.

If you have any feedback or suggestions, feel free to share!

Day 7 of My Cloud Journey: Getting Started with Docker & Containerization

Avinash wagh — Sat, 14 Mar 2026 04:50:48 +0000

Over the past few days of my cloud learning journey, I explored different parts of AWS infrastructure.

From deploying applications to designing secure cloud networks, each day has helped me understand how modern cloud systems are built.

Quick recap of the previous learning days:

Day 3 – Deployed a web application on a Linux server using Amazon EC2 and Nginx
Day 4 – Hosted a static website using Amazon S3
Day 5 – Explored backend services with Amazon RDS, DynamoDB, and AWS Lambda
Day 6 – Built secure cloud networks using AWS VPC, VPC Peering, and Billing Alerts

After learning about infrastructure and networking, the next logical step in my journey was:

Containerization with Docker.

Docker is one of the most important tools used in modern DevOps and Cloud Engineering workflows.

🚀 Objective of Day 7
The goal today was to understand:

• What Docker is
• Why containers are used in modern application development
• How to run containers using Docker
• Basic Docker commands and container lifecycle

🐳 Step 1: Understanding Docker
Docker is a platform that allows developers to package applications and their dependencies into containers.

A container ensures that an application runs the same way in every environment.

For example:

A developer might build an application on their local machine, but it could fail when deployed to a server because of missing dependencies or different system configurations.

Docker solves this problem by packaging:

Application code
Runtime
Libraries
Dependencies
System tools

All inside a single container image.

This makes applications portable, consistent, and easy to deploy.

🧩 Step 2: Installing Docker
To start working with containers, I installed Docker and verified the installation.

Docker provides a command-line interface to manage containers and images.

To test the installation, I ran the famous hello-world container.

Example command:

docker run hello-world
This command downloads the image from Docker Hub and runs it inside a container.

Seeing the successful output confirmed that Docker was installed and working correctly.

⚙️ Step 3: Running Basic Containers
Next, I experimented with simple containers using lightweight images.

For example, running an Alpine Linux container:

docker run alpine
This allowed me to understand how containers start, execute commands, and stop after completion.

I also explored commands like:

docker ps
docker ps -a
docker stop
These commands help manage running and stopped containers.

📦 Step 4: Understanding Docker Images
Another key concept is Docker Images.

An image is a template used to create containers.

Images can be downloaded from Docker Hub, which is a public registry containing thousands of ready-to-use images.

Examples include:

Nginx
Node.js
Python
MySQL
Redis

Using images, developers can quickly deploy applications without manually installing dependencies.

🧠 Key Technical Takeaways
Today’s learning introduced several important DevOps concepts:

• Containers package applications with their dependencies
• Docker ensures applications run consistently across environments
• Docker images act as templates for containers
• Containers are lightweight and start very quickly
• Docker commands help manage container lifecycle

Understanding Docker is a fundamental skill for Cloud Engineers and DevOps Engineers.

🎯 Reflection
Over the past few days, my learning journey has expanded from cloud infrastructure to containerization.

Day 3
Application deployment on EC2 with Nginx

Day 4
Static website hosting using S3

Day 5
Backend systems using RDS, DynamoDB, and Lambda

Day 6
Cloud networking with VPC and billing alerts

Day 7
Introduction to Docker and containerization

Each step is helping me understand how modern cloud-native applications are built and deployed.

The next step in this journey will be exploring:

Dockerfiles
Building custom images
Running applications inside containers
Deploying containers in the cloud

This is just the beginning of my Docker and containerization journey.

More learning ahead. 🚀

Day 6 of My Cloud Journey: Building Secure AWS Networks with VPC, VPC Peering & Billing Alerts

Avinash wagh — Thu, 12 Mar 2026 04:37:07 +0000

When I first started learning cloud computing, I mostly focused on launching servers and deploying applications.

But as I continued exploring AWS services, I realized something important:

Infrastructure is not just about servers — it’s also about networking, security, and cost management.

On previous days of my learning journey:

Day 3 – Deployed a web application on a Linux server using Amazon EC2 and Nginx
Day 4 – Hosted a static website using Amazon S3
Day 5 – Explored backend architecture with Amazon RDS, DynamoDB, and AWS Lambda

Today’s learning focused on an essential part of cloud architecture:

Cloud networking and cost monitoring.

I explored three key AWS concepts:

AWS Virtual Private Cloud (VPC)
VPC Peering
Billing Alerts using CloudWatch These services helped me understand how cloud environments are structured securely and how engineers monitor cloud costs effectively.

🚀 Objective of Day 6

The goal today was to understand how cloud networks are designed and how organizations control spending in cloud environments.

The main learning areas were:

Understanding private cloud networking
Creating and configuring a Virtual Private Cloud
Connecting two VPC networks using VPC Peering
Setting up billing alerts to monitor cloud spending

These topics are critical for Cloud Engineers, DevOps Engineers, and Solutions Architects.

🌐 Step 1: Understanding AWS VPC

The first concept I explored was AWS Virtual Private Cloud (VPC).

A VPC allows you to create a logically isolated network inside AWS, where you can securely launch resources like:

EC2 instances
Databases
Load balancers
Containers

It works very similarly to a traditional data center network, but everything is managed in the cloud.

Inside a VPC, we can define:

IP address ranges (CIDR blocks)
Subnets
Route tables
Internet gateways
Security groups
Network ACLs

This gives engineers full control over** how resources communicate with each other and with the internet**.

Example architecture:

VPC
├── Public Subnet
│ └── EC2 Web Server
│
└── Private Subnet
└── Database Server

This type of architecture is widely used in production environments.

🧩 Step 2: Creating a VPC

Using the AWS Management Console, I created a custom VPC.

Configuration included:

CIDR block: 10.0.0.0/16
Public subnet
Internet Gateway
Route table association

This allowed resources in the public subnet to communicate with the internet, while still remaining inside a secure private network.

Understanding VPC structure helped me see how cloud networks are designed similarly to enterprise networking systems.

🔗 Step 3: Learning VPC Peering

Next, I explored VPC Peering, which allows two VPCs to communicate with each other privately.

Normally, VPCs are isolated networks.

But sometimes applications are distributed across multiple VPCs, for example:

One VPC for application servers
Another VPC for databases
Separate VPCs for different environments (Dev, Test, Production)

VPC Peering creates a private connection between them.

Example:

VPC A (10.0.0.0/16)
│
│ VPC Peering Connection
│
VPC B (192.168.0.0/16)

Key points about VPC Peering:

Traffic stays inside the AWS network
No internet gateway is required
Low latency and secure communication

To enable communication, route tables must be updated to allow traffic between the VPC CIDR blocks.

This concept is very important in large-scale microservice architectures.

💰 Step 4: Monitoring Costs with Billing Alerts

One of the most important lessons when learning cloud platforms is:

Always monitor your cloud spending.

AWS provides a powerful way to track costs using** billing alerts and CloudWatch alarms**.

I created a billing alert to notify me if my AWS usage crosses a certain amount.

Configuration included:

Enable AWS billing alerts
Create a CloudWatch alarm
Set threshold (example: $5)
Add email notification

Workflow:

AWS Usage
↓
Billing Metric
↓
CloudWatch Alarm
↓
Email Notification

This ensures engineers get immediate alerts when costs increase unexpectedly.

Cost monitoring is a critical skill in real-world cloud engineering.

🧠 Key Technical Takeaways

Today’s learning introduced some very important infrastructure concepts:

How AWS VPC creates isolated cloud networks
How subnets divide public and private resources
How VPC Peering connects separate cloud networks
How route tables control network communication
How CloudWatch billing alerts help monitor cloud costs

One key realization stood out:

Cloud engineering is not only about deploying applications — it's also about designing secure networks and managing infrastructure costs effectively.

🎯 Reflection

Over the past few days, my cloud learning journey has covered multiple aspects of AWS infrastructure.

Day 3
Application deployment on EC2 with Nginx

Day 4
Static website hosting using S3

Day 5
Backend systems using RDS, DynamoDB, and Lambda

Day 6
Cloud networking with VPC and monitoring costs using billing alerts

Each day is helping me understand how modern cloud architectures are built step by step.

The more I learn, the more I realize how powerful cloud platforms are for building scalable and secure systems.

And this is just the beginning.

Day 6 of my Cloud Engineering journey — more learning ahead. 🚀

From Static Storage to Managed Databases: Learning Amazon RDS, DynamoDB & AWS Lambda (Day 5)

Avinash wagh — Mon, 09 Mar 2026 04:23:52 +0000

When I started learning cloud engineering, I believed infrastructure was mostly about launching servers and hosting applications.

In the past few days, that perspective has changed significantly.

On Day 3, I deployed a web application on a Linux server using Amazon EC2 and Nginx.

On Day 4, I hosted a static website using Amazon S3 without running a server at all.

Today’s learning introduced another important part of cloud architecture:

Databases and serverless computing.

I explored how applications store and process data using:

- Amazon RDS
- Amazon DynamoDB
- AWS Lambda

These services showed me how AWS enables developers to build scalable backend systems without managing infrastructure manually.

🚀 The Objective

Today’s goal was to understand how cloud applications manage and process data.

The focus areas were:

Deploying a managed relational database
Connecting an application server to the database
Learning NoSQL database architecture
Executing backend logic using serverless functions

This meant working with three important AWS services:

Amazon RDS
Amazon DynamoDB
AWS Lambda

🗄️ Step 1: Understanding Amazon RDS

The first service I explored was Amazon RDS (Relational Database Service).

RDS is a managed database service that allows developers to run relational databases without handling server management tasks like:

OS patching
Backups
High availability configuration
Scaling

AWS takes care of the infrastructure while developers focus on applications.

Supported database engines include:

- MySQL
- PostgreSQL
- MariaDB
- Oracle Database
- Microsoft SQL Server

For practice, I created a MySQL RDS instance.

⚙️ Step 2: Launching an RDS Database

I created my first managed database instance using the AWS console.

Configuration included:

Engine: MySQL
Instance type: db.t3.micro (Free Tier eligible)
Storage: 20 GB
Region: Mumbai
Public accessibility: enabled for testing

After the instance was created, AWS automatically provided a database endpoint.

This endpoint acts like the database address that applications use to connect.

Example structure:

mydb.xxxxxx.ap-south-1.rds.amazonaws.com

Instead of installing MySQL manually on a server, AWS handled the entire database infrastructure.

🔗 Step 3: Connecting EC2 to RDS

Next, I connected my Amazon EC2 instance to the RDS database.

The connection required proper network and security configuration.

Steps included:

Allowing inbound database access in security groups
Using the RDS endpoint
Connecting via MySQL client from the EC2 server

Once connected, I was able to:

Create databases
Create tables
Insert and retrieve data

This demonstrated how application servers interact with managed databases in real-world cloud architectures.

🧩 Step 4: Understanding DynamoDB (NoSQL)

After working with relational databases, I explored Amazon DynamoDB.

DynamoDB is a fully managed NoSQL database designed for high scalability and low latency.

Unlike relational databases, DynamoDB stores data in:

- Tables
- Items
- Attributes

Example structure:

Users Table
├── UserID
├── Name
├── Email
└── CreatedDate

Key advantages of DynamoDB include:

Automatic scaling
Millisecond latency
Serverless architecture
Fully managed infrastructure

This makes DynamoDB ideal for modern cloud applications such as:

mobile apps
gaming backends
real-time analytics
serverless architectures

⚡ Step 5: Running Serverless Code with AWS Lambda

Next, I explored AWS Lambda.

Lambda allows developers to run code without managing servers.

Instead of deploying applications on EC2, Lambda executes code only when triggered.

Common triggers include:

API requests
file uploads
database events
scheduled tasks

For practice, I created a Lambda function that interacted with DynamoDB.

The workflow looked like this:

Client Request
↓
AWS Lambda Function
↓
DynamoDB Table
↓
Response Returned

This architecture is known as serverless backend architecture.

The biggest advantage is that AWS automatically handles:

infrastructure
scaling
execution environment

Developers only focus on writing code.

🧠 Key Technical Takeaways

Today’s learning introduced important backend architecture concepts:

How Amazon RDS provides managed relational databases
How EC2 applications communicate with RDS
The difference between SQL and NoSQL databases
How Amazon DynamoDB handles high-scale workloads
How AWS Lambda runs backend code without servers
How serverless architecture simplifies infrastructure management

One key realization stood out:

Cloud platforms allow developers to choose between multiple architectures depending on the application’s needs.

🎯 Reflection

In just a few days of learning cloud engineering, I’ve experienced several different deployment models:

Day 3
Application deployed on Amazon EC2 using Nginx

Day 4
Static website hosted using Amazon S3

Day 5
Backend architecture using Amazon RDS, Amazon DynamoDB, and AWS Lambda

Each approach solves a different type of problem.

Traditional servers provide full control.

Object storage enables lightweight hosting.

Serverless services enable scalable backend architectures.

Understanding when to use each of these approaches is what makes cloud engineering powerful.

This is Day 5 of my cloud learning journey, and every day the architecture possibilities are becoming clearer.

More exploration ahead. 🚀

From EC2 Servers to Serverless Hosting: Learning Amazon S3, IAM & AWS CLI (Day 4)

Avinash wagh — Fri, 06 Mar 2026 04:34:11 +0000

When I started learning cloud engineering, I initially thought cloud deployment meant launching servers.

In my previous article, I deployed a web application on a Linux server using Amazon EC2 and Nginx.

That was a huge milestone.

But today I learned something even more powerful.

In the cloud, sometimes you don’t need a server at all.

Instead, you can host applications using object storage.

Today’s focus was learning Amazon S3, understanding Identity and Access Management, and interacting with AWS services using the command line.

And it completely changed how I see infrastructure.

🚀 The Objective

Today’s goal was simple but important:

Understand how cloud storage works
Learn user and permission management
Deploy a static website without a server
Interact with AWS using the CLI

This meant working with three important AWS components:

- Amazon S3
- AWS Identity and Access Management
- AWS Command Line Interface

📦 Step 1: Understanding Amazon S3

First, I learned about Amazon S3 (Simple Storage Service).

It is an object storage service used to store files in the cloud.

Instead of folders and files like a normal system, S3 stores data as:

- Buckets → Containers for storage
- Objects → Files inside buckets

So the structure looks like:

Bucket
├── index.html
├── error.html
├── images/
└── css/

Buckets are globally unique and act like storage containers for applications, backups, media files, and static websites.

🪣 Step 2: Creating and Managing an S3 Bucket

After understanding the concept, I created my own S3 bucket.

Steps I followed:

Opened the AWS Console
Navigated to Amazon S3
Created a new bucket
Selected the Mumbai region
Configured permissions
Enabled Static Website Hosting

Inside the bucket, I uploaded:

index.html
error.html
project assets

Once the files were uploaded, I enabled static website hosting and AWS generated a public website endpoint.

My website was now running directly from S3 storage.

No server required.

🌐 Step 3: Hosting a Static Website using S3

Unlike my EC2 deployment, this approach had a big difference:

There was no Linux server, no Nginx, and no SSH.

Instead:

The files live inside S3
AWS automatically serves them over HTTP
The bucket behaves like a web server

This showed me a very important cloud concept:

Not every application requires a virtual machine.

Sometimes storage + HTTP delivery is enough.

🔐 Step 4: Learning IAM – Identity & Access Management

Next, I explored AWS Identity and Access Management.

IAM controls who can access AWS resources and what actions they can perform.

Instead of sharing the root account, best practice is to create IAM users with limited permissions.

Key IAM components I learned:

Users

Individual identities created for developers or services.

Groups

A collection of users sharing the same permissions.

Example:

Developers Group
├── avinash-dev
├── sagar-dev

Roles

Temporary access permissions used by services like EC2.

Policies

JSON documents that define permissions.

Example policy action:

s3:PutObject
s3:GetObject
s3:ListBucket

Identity Providers

Used for federated access like Google login or corporate SSO.

This structure makes AWS secure and scalable for teams.

💻 Step 5: Installing and Configuring AWS CLI

Today I also started working with the AWS Command Line Interface.

Instead of using the AWS console, CLI allows interaction with AWS services directly from the terminal.

First I installed the AWS CLI and configured credentials:

aws configure

It required:

Access Key
Secret Key
Region
Output format

After configuration, my terminal could interact with AWS services.

📂 Step 6: Managing S3 Using AWS CLI

Using the CLI, I practiced several commands.

List buckets
aws s3 ls

Upload a file

aws s3 cp index.html s3://cloudcanvas-editor-h-bucket/

Upload error page

aws s3 cp error.html s3://cloudcanvas-editor-h-bucket/

These commands allowed me to manage cloud storage directly from my terminal.

It felt similar to using Linux commands, but now I was interacting with cloud infrastructure.

🧠 Key Technical Takeaways

Today’s learning helped me understand several important cloud concepts:

How Amazon S3 stores objects instead of traditional filesystems
Difference between server-based hosting and serverless hosting
Why IAM is critical for security
How policies control resource permissions
How the AWS Command Line Interface enables automation
How to upload and manage files in S3 from the terminal

Most importantly, I realized something powerful:

Cloud engineering is not only about servers.

It is about choosing the right service for the right problem.

🎯 Reflection

Just two days ago, my applications were running on localhost.

In my previous article, I deployed one on Amazon EC2 using Nginx.

Today, I hosted one without any server using Amazon S3.

That contrast helped me understand something important about cloud architecture:

Infrastructure choices matter.

Sometimes you scale with servers.

Sometimes you scale without them.

And understanding both approaches is what makes cloud engineering powerful.

This is Day 4 of my cloud journey.

More learning ahead 🚀

Deploying a Web Application on AWS EC2: From Localhost to Public Access (Day 3)

Avinash wagh — Sun, 01 Mar 2026 04:25:12 +0000

When I started my transition from .NET development to Cloud Engineering, I knew one thing:

Reading documentation wouldn’t be enough.

I had to deploy something real.

Today, I successfully deployed my web application to a live cloud server using a Linux EC2 instance and Nginx — and accessed it publicly from both my laptop and mobile device using a public IP address.

This was the moment my application left localhost.

🚀 The Objective

Deploy a static web application on a cloud-based Linux server and make it accessible over the internet.

No managed platforms.
No deployment shortcuts.
Just core infrastructure.

🏗 Step 1: Provisioning the Cloud Server

I launched a t3.micro Linux instance using
Amazon Elastic Compute Cloud
on
Amazon Web Services

Configured:

Key Pair for secure SSH access
Security Group allowing HTTP (Port 80)
Default EBS storage

At this point, I had a virtual machine running in the Mumbai region — ready to host my application.

🔐 Step 2: Secure Remote Access

Using SSH and key-based authentication, I connected to the instance from my terminal.

This was the first mindset shift.

This wasn’t localhost anymore.
This was a remote server running inside AWS infrastructure.

⚙ Step 3: Installing and Configuring Nginx

I installed
Nginx
to act as the web server.

After verifying the service was running, I:

Removed the default Nginx welcome page
Copied my application files into /var/www/html/
Restarted the Nginx service

Then I opened the public IP in my browser.

And it worked.

🌍 The First Real Test – Laptop Browser

Below is my application successfully running via EC2 Public IP in a desktop browser:

📸 Screenshot 1 – Application Running on Laptop

Application deployed on EC2 and accessible publicly via Public IP address.

At this moment, the deployment was successful.

But I wanted one more confirmation.

📱 The Real Validation – Mobile Access

To ensure it wasn’t dependent on my system:

I disconnected my laptop.
Switched to mobile internet.
Entered the Public IP in my phone browser.

And it loaded instantly.

📸 Screenshot 2 – Application Running on Mobile

Application accessible globally via mobile browser — independent of local system.

That’s when it truly clicked.

The server runs independently of my laptop.
The application lives in the cloud.

🧠 Key Technical Takeaways

This hands-on deployment reinforced several important cloud fundamentals:

Difference between localhost and public IP
How Security Groups act as firewalls
Why opening Port 80 is necessary
How Nginx serves static content
Understanding instance lifecycle and cost awareness
Importance of Elastic IP for production stability

Most importantly, I started thinking in terms of infrastructure — not just application logic.

💰 Cost Awareness

Using a t3.micro under AWS Free Tier:

750 hours per month available
Suitable for continuous hands-on learning
Encourages cost-conscious cloud usage

Cloud engineering is not only about scalability.
It’s about efficiency and responsible architecture.

🎯 Reflection

As a developer transitioning into cloud engineering, today felt like a milestone.

Writing code is powerful.

But deploying that code to a live cloud server — configuring compute, networking, and services — builds a completely different level of understanding.

This wasn’t just hosting a webpage.

It was building a small, real-world infrastructure setup from scratch.

And this is only Day 3.

On to the next challenge 🚀

From .NET to Cloud – AWS Engineer Journey (Day 2: Deep Dive into EC2)

Avinash wagh — Thu, 26 Feb 2026 04:30:31 +0000

As part of my structured transition from .NET development to Cloud Engineering, I recently explored Amazon EC2 (Elastic Compute Cloud) — one of the core compute services in Amazon Web Services.

Understanding EC2 is a major step toward designing scalable and production-ready cloud systems.

🚀 What is Amazon EC2?

Amazon EC2 provides resizable virtual servers in the cloud.
It allows engineers to provision compute capacity on-demand without managing physical hardware.

This is where applications actually run in AWS infrastructure.

🔹 Key Learnings from My Hands-on Practice
1️⃣ Launching Virtual Servers

Created EC2 instances using different AMIs:
Amazon Linux
Ubuntu
Understood the full launch workflow: AMI → Instance Type → Key Pair → Security Group → Storage → Launch.

2️⃣ Instance Types & Sizing Strategy

Explored instance families:

General Purpose
Compute Optimized
Memory Optimized

Learned how selecting the right instance type impacts performance and cost optimization.

3️⃣ Secure Access & Networking

Configured Key Pairs for SSH authentication
Set up Security Groups (firewall rules)
Practiced SSH connectivity via terminal
Understood inbound vs outbound traffic rules

Security and networking fundamentals became much clearer during this process.

4️⃣ Storage with EBS

Studied EBS volume types
Attached & detached volumes
Understood root volume vs additional storage
Learned persistence behavior after instance stop/terminate

Storage design directly affects durability and performance.

5️⃣ Elastic IP & Monitoring

Explored Elastic IP for static public addressing
Understood basic monitoring concepts
Learned about auto-recovery mechanisms

These concepts connect directly to high availability and reliability engineering.

🧠 Technical Insight Gained

Coming from an application development background, EC2 helped me see infrastructure from a system-level perspective:

Applications run on compute (EC2)
Storage persists in EBS
Access is controlled via IAM
Traffic flows through VPC and Security Groups
Availability requires monitoring and recovery planning

Cloud engineering is not just deployment — it’s architecture thinking.

💡 Reflection

The more I learn AWS, the more I realize:

Strong cloud engineers don’t just write code.
They design systems that are scalable, secure, and resilient by default.

Step by step, building foundations.

Consistency is the real superpower 💪🐧

From .NET to Cloud – AWS Engineer Journey (Day 1: Foundations)

Avinash wagh — Fri, 20 Feb 2026 15:05:42 +0000

As a Software Engineer with a background in .NET and enterprise application systems, I’ve started my structured transition into Cloud & DevOps engineering.

Instead of jumping directly into advanced tools and automation, I chose to begin where every strong cloud engineer begins — the fundamentals.

Because scalable systems are never built on weak foundations.

☁️ Understanding Cloud Computing

Cloud computing is the delivery of computing services — servers, storage, databases, networking, and software — over the internet on a pay-as-you-go model.

What makes it powerful:

On-demand resource provisioning
Elastic scalability
High availability
Cost efficiency
No physical infrastructure management

Leading cloud providers include:

Amazon Web Services
Microsoft Azure
Google Cloud Platform

This shifts the mindset from simply deploying applications to designing systems that are scalable and resilient by architecture.

🏗 Cloud Service Models – Understanding Responsibility

One of the most important concepts I reinforced today was who manages what in cloud environments.

🔹 IaaS (Infrastructure as a Service)

Example: Amazon EC2

User manages: OS, middleware, applications
Provider manages: hardware & virtualization

🔹 PaaS (Platform as a Service)

Example: Azure App Service

User manages: Application code
Provider manages: OS, runtime, infrastructure

🔹 SaaS (Software as a Service)

Example: Google Docs

Fully managed by provider
Delivered over the internet
No infrastructure management required

Understanding these models is critical for designing the right architecture.

🌍 Cloud Deployment Models

I also revisited deployment strategies:

Public Cloud – Shared infrastructure (e.g., Amazon Web Services)
Private Cloud – Dedicated infrastructure for one organization
Hybrid Cloud – Combination of public and private environments

These models directly impact security, compliance, and scalability decisions.

☁️ Core AWS Services Reviewed

To build clarity, I focused on foundational services of Amazon Web Services:

🔹 EC2 – Compute

Amazon EC2 provides resizable virtual servers to run applications.

🔹 S3 – Storage

Amazon S3 offers highly durable object storage for files, backups, and logs.

🔹 IAM – Security

AWS Identity and Access Management controls users, roles, and permissions.

Principle reinforced:
Always follow least privilege. Never use root for daily operations.

🔹 VPC – Networking

Amazon VPC enables logically isolated networking with subnets, route tables, and security groups.

This connects cloud infrastructure directly with networking fundamentals.

🖥 Virtualization – The Backbone of Cloud

Cloud environments operate using virtualization technology. Solutions like those from VMware allow multiple virtual machines to run on a single physical server using hypervisors.

This enables efficient resource utilization, isolation, and scalability at scale.

🔍 Key Reflection from Day 1

As someone transitioning from application development to cloud engineering, I’m beginning to see how everything connects:

Applications run on compute
Data resides in storage
Access is controlled through identity policies
Infrastructure lives inside secure networks

Cloud engineering is not separate from development — it strengthens it.

Consistency remains the real superpower 💪🐧

🚀 Transitioning from .NET Development to Cloud & DevOps (AWS Journey)

Avinash wagh — Wed, 11 Feb 2026 13:22:49 +0000

As a Software Engineer with a background in .NET and enterprise application systems, I’ve started aligning my development experience with cloud infrastructure practices.

After strengthening Linux fundamentals, I’m now working hands-on with AWS core services such as EC2, S3, IAM, and VPC — focusing on secure networking, scalable architecture design, monitoring, and deployment workflows.

My goal is to bridge application development with cloud infrastructure to better understand how scalable, production-ready systems are built and maintained.

I’ll be sharing practical implementations and architecture learnings as I continue this transition into Cloud & DevOps engineering.

Linux Learning Journey – Day 19: Text Processing & Data Manipulation with grep, awk & sed 📝🔍

Avinash wagh — Sun, 08 Feb 2026 07:10:50 +0000

After mastering network routing, security, and API debugging on Day 18, Day 19 of my Linux learning journey focused on text processing and data manipulation — an essential skillset for any Linux administrator, DevOps engineer, or Cloud practitioner.

Text processing is at the heart of Linux-based automation, log analysis, and monitoring. The commands I explored today — grep, awk, and sed — are the Swiss Army knives of the command line, transforming raw text and logs into actionable insights.

🔹 grep – Pattern Searching & Filtering

grep is a command-line utility for searching text using patterns or regular expressions.

Example:

- grep "error" /var/log/syslog

✔️ Key Learnings:

Filters lines containing specific patterns
Supports regular expressions for advanced searches
Can search recursively in directories

Use Cases:

Quickly identify errors or warnings in logs
Extract specific information from configuration files
Debug application outputs

🔹 awk – Data Extraction & Reporting

awk is a versatile tool for text parsing, data extraction, and reporting. It treats text as structured fields and allows advanced operations like calculations and conditionals.

Example:

- awk '{print $1, $3}' /etc/passwd

✔️ What it Does:

Splits text into fields
Performs operations on specific columns
Can be combined with patterns for selective processing

Use Cases:

Extract usernames, IPs, or other structured data from logs
Summarize reports from CSV or tab-delimited files
Automate repetitive data processing tasks

🔹 sed – Stream Editing & Text Transformation

sed (stream editor) is used to modify text in streams or files without opening them in a text editor.

Example:

- sed 's/error/ERROR/g' /var/log/syslog

✔️ Key Learnings:

Perform search-and-replace operations
Delete, insert, or transform lines
Can be used in pipelines for automated processing

Use Cases:

Modify configuration files in automation scripts
Clean and transform log outputs
Batch edit text across multiple files

🔹 Why These Commands Matter in Real-World Systems

Text processing commands are not just academic exercises — they are production essentials:

Logs and configuration files contain valuable system insights
Automation scripts often rely on grep, awk, and sed to parse and act on data
Data manipulation enables faster troubleshooting and reporting
Combined, these tools reduce manual effort and make Linux systems more observable and manageable

🚀 Day 19 Takeaway

Today’s journey significantly strengthened my understanding of:

Searching and filtering text efficiently
Extracting and summarizing structured data
Automating text transformations for system and application logs
Integrating text processing tools into real-world DevOps and Cloud workflows

Linux is gradually shifting from “just a terminal” to a powerful data-processing environment. With tools like grep, awk, and sed, handling complex logs, automation pipelines, and system monitoring becomes not only feasible but efficient.

Consistency and curiosity remain the real superpowers 🔑💪. Step by step, the Linux command line is becoming less intimidating and more empowering.

DEV Community: Avinash wagh

🚀 Day 10 of My Cloud Journey: Setting Up Kubernetes with Kind & kubectl on AWS EC2

🧩 Why Kubernetes?

⚙️ My Setup (AWS EC2)

🛠️ Tools I Installed

1. kubectl (Kubernetes CLI)

2. Kind (Kubernetes in Docker)

🚀 Creating My First Kubernetes Cluster

✅ Verifying the Cluster

🔥 First Deployment (Nginx)

🌐 Accessing the Application

💡 Key Takeaways

🔄 My Learning Reflection

📘 Learning in Public

💬 Let’s Connect

🚀 Day 9 of My Cloud Journey: Mastering Docker Volumes, Compose & Registry

🧩 Why This Matters

📦 1. Understanding Docker Volumes (Persistent Storage)

🔹 What I Learned

🔹 Hands-on

⚙️ 2. Docker Compose (Managing Multi-Container Apps)

🔹 What I Learned

🔹 Sample docker-compose.yml

▶️ Run everything

🌐 3. Docker Registry (Image Management)

🔹 What I Learned

🔹 Basic Workflow

💡 Key Takeaways

🔄 My Learning Reflection

📘 Learning in Public

💬 Let’s Connect

🚀Deployed a Containerized Flask Message App on AWS EC2 using Docker

📌 Project Overview

🛠️ Tech Stack

🏗️ Architecture

⚙️ Step-by-Step Implementation

1️⃣ Create Docker Network

2️⃣ Run MySQL Container

3️⃣ Build Flask App Image

4️⃣ Run Flask Container

🌐 Deployment on AWS EC2

🔗 Live Demo

📷 Screenshots

📚 Key Learnings

🚀 Future Improvements

🔗 GitHub Repository

👨‍💻 About Me

💬 Conclusion

Day 7 of My Cloud Journey: Getting Started with Docker & Containerization

Day 6 of My Cloud Journey: Building Secure AWS Networks with VPC, VPC Peering & Billing Alerts

From Static Storage to Managed Databases: Learning Amazon RDS, DynamoDB & AWS Lambda (Day 5)

From EC2 Servers to Serverless Hosting: Learning Amazon S3, IAM & AWS CLI (Day 4)

Deploying a Web Application on AWS EC2: From Localhost to Public Access (Day 3)

From .NET to Cloud – AWS Engineer Journey (Day 2: Deep Dive into EC2)

From .NET to Cloud – AWS Engineer Journey (Day 1: Foundations)

🚀 Transitioning from .NET Development to Cloud & DevOps (AWS Journey)

Linux Learning Journey – Day 19: Text Processing & Data Manipulation with grep, awk & sed 📝🔍

🔹 Sample `docker-compose.yml`