DEV Community: Deep Datta

Deploying Nginx on AWS EC2 Using Terraform — Automating Infrastructure

Deep Datta — Thu, 09 Jul 2026 07:40:21 +0000

Been meaning to do a proper Terraform project for a while. This weekend I finally did it.

The goal was simple: use Terraform to provision AWS infrastructure from scratch and have a running Nginx server at the end of it.

What I Built

Here's the architecture at a glance:

A browser hits an Internet Gateway, which routes traffic into a VPC containing a public subnet. Inside that subnet lives an EC2 instance running Nginx in a Docker container, exposed on port 8080.

Project Structure

.
├── main.tf
├── terraform.tfvars
└── entrypoint.sh

Step 1: Variables

Instead of hardcoding values, I declared variables and supplied them via terraform.tfvars. This keeps things reusable and environment-aware.

terraform.tfvars

vpc_cidr_block      = "10.0.0.0/16"
subnet_1_cidr_block = "10.0.10.0/24"
env_prefix          = "dev"
avail_zone          = "ap-south-1a"
my_ip               = "YOUR_IP/32"   # replaced with my actual IP
instance_type       = "t2.micro"

⚠️ Never commit your real IP or credentials to a public repo. Add terraform.tfvars to .gitignore.

Step 2: Provider

provider "aws" {
  region = "ap-south-1"
}

This tells Terraform to use AWS and deploy everything into the Mumbai region (ap-south-1).

Step 3: Networking

VPC

resource "aws_vpc" "myapp-vpc" {
  cidr_block = var.vpc_cidr_block
  tags = {
    Name = "${var.env_prefix}-vpc"
  }
}

This creates an isolated virtual network with the CIDR 10.0.0.0/16, providing me 65,536 private IP addresses to work with.

Subnet

resource "aws_subnet" "myapp-subnet-1" {
  vpc_id            = aws_vpc.myapp-vpc.id
  cidr_block        = var.subnet_1_cidr_block
  availability_zone = var.avail_zone
  tags = {
    Name = "${var.env_prefix}-subnet-1"
  }
}

This carves out a /24 subnet (10.0.10.0/24) — 256 addresses — inside the VPC, pinned to ap-south-1a.

Internet Gateway

resource "aws_internet_gateway" "myapp-igw" {
  vpc_id = aws_vpc.myapp-vpc.id
  tags = {
    Name = "${var.env_prefix}-internet-gateway"
  }
}

By default, a VPC is completely isolated. The Internet Gateway is what allows it to communicate with the outside world.

Route Table

resource "aws_default_route_table" "main-rtb" {
  default_route_table_id = aws_vpc.myapp-vpc.default_route_table_id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.myapp-igw.id
  }
  tags = {
    Name = "${var.env_prefix}-main-rtb"
  }
}

Rather than creating a new route table and manually associating it with the subnet, I modified the default route table that AWS automatically creates with the VPC. The 0.0.0.0/0 route sends all outbound traffic through the Internet Gateway.

Note: I initially wrote a custom aws_route_table resource, but switched to aws_default_route_table to keep things simpler — it's automatically associated with all subnets that don't have an explicit association.

Step 4: Security Group

resource "aws_default_security_group" "default-sg" {
  vpc_id = aws_vpc.myapp-vpc.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = [var.my_ip]   # SSH only from your machine
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # HTTP open to the world
  }

  egress {
    from_port       = 0
    to_port         = 0
    protocol        = "-1"
    cidr_blocks     = ["0.0.0.0/0"]
    prefix_list_ids = []
  }

  tags = {
    Name = "${var.env_prefix}-default-sg"
  }
}

Two ingress rules:

Port 22 (SSH) — locked down to your IP only. No random internet scanners getting in.
Port 80 (HTTP) — open to everyone so the web server is publicly accessible. All outbound traffic is allowed (protocol = "-1" means all protocols).

Step 5: Fetching the Latest Ubuntu AMI Dynamically

data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

output "ami_id" {
  value = data.aws_ami.ubuntu.id
}

Instead of hardcoding an AMI ID (which is region-specific and goes stale), I used a data source to dynamically fetch the most recent Ubuntu HVM AMI. The output block prints the resolved AMI ID after terraform apply, which is handy for debugging.

Step 6: EC2 Instance

resource "aws_instance" "myapp-instance" {
  ami                    = data.aws_ami.ubuntu.id
  instance_type          = var.instance_type
  subnet_id              = aws_subnet.myapp-subnet-1.id
  vpc_security_group_ids = [aws_default_security_group.default-sg.id]
  availability_zone      = var.avail_zone

  user_data = file("entrypoint.sh")

  tags = {
    Name = "${var.env_prefix}-server"
  }
}

The instance is a t2.micro (free-tier eligible), placed in my subnet with the security group I defined. The user_data field passes entrypoint.sh as a bootstrap script that runs once on first boot.

Step 7: The Bootstrap Script

entrypoint.sh

#!/bin/bash
sudo apt update -y
sudo apt install docker.io -y
sudo systemctl start docker
sudo usermod -aG docker ubuntu
sudo systemctl restart docker
sudo docker run -d -p 8080:80 nginx

This script:

Updates the package index
Installs Docker
Starts the Docker daemon
Adds the ubuntu user to the docker group
Pulls and runs the official Nginx image, mapping host port 8080 → container port 80

Deploying

# Initialize — downloads the AWS provider plugin
terraform init

# Preview what will be created
terraform plan

# Apply — this actually creates the resources
terraform apply

Then visit http://<public-ip>:8080 in your browser — you should see the Nginx welcome page.

All the code for this project is available on github

dxdprojects / aws-ec2-nginx-terraform

Building a Production-Ready 3-Tier Application with Kubernetes Blue-Green Deployment

Deep Datta — Tue, 30 Jun 2026 12:23:02 +0000

Introduction

I took a basic 3-tier Node.js and MySQL application and transformed it into a production-ready system using DevOps practices. The goal was to implement a zero-downtime deployment strategy using Kubernetes' blue-green deployment pattern, containerize the application, automate the CI/CD pipeline with Jenkins, and provision infrastructure with Terraform.

Understanding the Architecture

The 3-Tier Application

The application consists of three layers:

Frontend (React): A user management interface.
Backend (Node.js/Express): An API server handling CRUD operations.
Database (MySQL): Persistent data storage.

Step 1: Containerizing with Docker

I used a multi-stage Dockerfile to keep the final image lightweight and efficient.

FROM node:14-alpine

WORKDIR /usr/src/app/client
COPY client/package*.json ./
RUN npm install
COPY client/ ./
RUN npm run build

WORKDIR /usr/src/app/server
COPY server/package*.json ./
RUN npm install
COPY server/ ./
RUN mkdir -p ./public && cp -R /usr/src/app/client/dist/* ./public/

EXPOSE 5000
CMD ["npm", "start"]

Step 2: Orchestrating with Kubernetes

Key Resources

I created two identical deployments—blue and green. The selector field allows us to switch traffic.

apiVersion: v1
kind: Service
metadata:
  name: app
spec:
  ports:
  - port: 80
    targetPort: 5000
  selector:
    app: app
    version: blue  # Points to the active environment
  type: LoadBalancer

Step 3: Blue-Green Deployment Strategy

The Jenkinsfile contains the logic for switching traffic by patching the service:

stage('Switch Traffic') {
    when { expression { return params.SWITCH_TRAFFIC } }
    steps {
        script {
            def newEnv = params.DEPLOY_ENV
            withKubeConfig(...) {
                sh "kubectl patch service app -p '{\"spec\":{\"selector\":{\"version\":\"${newEnv}\"}}}' --type merge -n ${KUBE_NAMESPACE}"
            }
        }
    }
}

Troubleshooting: Real Issues I Encountered

To keep this guide readable, I've categorized the hurdles I faced. Click to expand each issue.

Issue 1: Docker Build Failures (Node Cache)
Problem: The build stage would fail intermittently with npm dependency resolution errors.
Solution: Added explicit cache busting using --no-cache and a .dockerignore file.

Issue 2: Application Pod Can't Connect to MySQL
Problem: App pod crashed because MySQL wasn't ready.
Solution: Added a retry loop in the Node.js connection logic and used a Kubernetes Headless Service for stable DNS.

Here are some screenshots from the Jenkins build pipeline

The application is deployed in the blue environment (above image)

The application is now deployed in the green environment (above 2 images)

dxdprojects / 3-Tier-NodeJS-MySql

User Management App

This is a full-stack application for managing users with a front-end built using HTML, CSS, and JavaScript, and a back-end powered by Node.js, Express, and MySQL.

Features

Add new users with a name, email, and role (User/Admin).
View a list of all users.
Edit user details.
Delete users.
Responsive and user-friendly UI.
Smooth animations and minimalistic design.

Prerequisites

Before setting up this project, ensure you have the following installed on your machine:

Node.js (version 12.x or higher)
MySQL (version 5.7 or higher)

Setup Instructions

1. Setting Up MySQL Server

First, you need to set up a MySQL server on your local machine.

Update the package index:
```
sudo apt update
```
Install the MySQL server:
```
sudo apt install mysql-server
```
Log in to the…

View on GitHub

Taking an Existing App and Deploying It with Docker, Kubernetes, and Terraform

Deep Datta — Mon, 29 Jun 2026 12:06:50 +0000

I found a simple banking application on GitHub and used it as the base for my learning project. I did not build the application itself, but I did take it through the DevOps journey — containerizing it, deploying it on Kubernetes, and setting up infrastructure on AWS with Terraform.

I wanted to improve my understanding of how an application moves from a local project to a real environment where it can actually run and be used.

Why I Chose This Project

I wanted a project that would help me understand DevOps in a practical way. A banking app was a good choice because it already had a clear purpose and some important features like login, dashboard, deposits, withdrawals, and transactions.

The interesting part for me was not just the app itself. It was the journey of taking that app and making it ready for deployment. Instead of building a small demo app from zero, I focused on:

Packaging the app with Docker
Deploying it with Kubernetes
Managing the database
Provisioning infrastructure using Terraform

The First Step: Understanding the Application

Before doing anything with Docker or Kubernetes, I took time to understand the project structure. The app was built using Java and Spring Boot, and it used MySQL for data storage.

That was already enough for me to understand that this project could become a good example of a multi-tier application. Since the original README wasn't very detailed, I cloned the repository and created a detailed README from scratch to document my process.

Dockerizing the Application

Once I understood the app, the next step was to containerize it. I wrote a Dockerfile to package the environment and the application, created a Docker image, and pushed it to my Docker Hub registry. This made the application portable and ready for any environment.

Moving to Kubernetes

After Docker, the next step was Kubernetes. Honestly, this part felt a little intimidating at first.

I used Kubernetes to deploy both the application and the MySQL database. This was a very important experience because it showed me that deployment is not just about “running an app.” It is also about:

Ensuring the app can connect to the database.
Persisting data so it isn't lost when a container restarts.
Keeping the service available to users.

I learned that databases need more careful planning than stateless applications. You need to think about storage, persistence, and configuration.

Terraform and AWS: The Infrastructure Part

After Docker and Kubernetes, I wanted to learn how infrastructure could be created using code (IaC). That is where Terraform came in.

I used Terraform to provision the AWS resources for the project, including:

VPC & Subnets: For networking logic.
Internet Gateway: To allow traffic.
EKS Cluster: To run our Kubernetes nodes.
IAM Roles & Security Groups: To manage permissions and security.

This part taught me that DevOps is just as much about the environment as it is about the application.

What I Learned From This Project

1. You do not need to start from zero

One of the best things about this project was that I did not need to build the whole application myself. By using an existing app, I could focus 100% on the deployment and infrastructure side.

2. Troubleshooting is normal

There were many times when things did not work—database connection errors or service exposure issues. These frustrations were actually where the most learning happened.

3. Security matters

I gained a basic understanding of why secrets, permissions, and access control are vital in real-world cloud environments.

Final Thoughts

If you are a beginner in DevOps, I think this kind of project is a great place to start. You do not need to build everything yourself. You can take an existing project and focus on improving the deployment and infrastructure side of it.

dxdprojects / Multi-Tier-Bank-Application-on-Kubernetes

Multi-Tier Bank Application on Kubernetes

A full-stack banking application deployed using modern DevOps practices. This project demonstrates how to build a Spring Boot web app, containerize it with Docker, deploy it on Kubernetes, and provision an AWS EKS environment with Terraform.

Project Overview

This repository contains a simple multi-tier banking web application with:

a Spring Boot backend
a MySQL database
Docker-based containerization
Kubernetes manifests for deployment
Terraform infrastructure as code for AWS EKS
RBAC setup guidance for CI/CD automation

The goal of this project is to showcase a practical end-to-end DevOps workflow from application development to cloud deployment.

What the Application Does

Users can:

register an account
log in securely
view their dashboard
deposit funds
withdraw funds
transfer money to another user
view transaction history

The application is built with Spring Boot, Spring Security, Thymeleaf, and MySQL.

Architecture

The project follows a multi-tier architecture:

Frontend: Thymeleaf-based web UI
Backend: Spring…

View on GitHub

Building DevOps Projects from scratch to enterprise-grade

Deep Datta — Sat, 27 Jun 2026 11:39:25 +0000

Hey everyone,

I’ve decided to push myself out of my comfort zone. For the next 45 days, I am committing to building and documenting DevOps projects every single day—ranging from small-scale to enterprise-grade architectures.

Every single day, I’ll be deploying a project and writing a detailed breakdown right here on DEV.

The Framework

I won't just be dropping lines of code or a random GitHub link. For every single project, I’m going to deep-dive into:

The What: What exactly am I building?
The Why: Why does this architecture matter? What real-world problem does it solve?
The Tech Stack: Exactly why I chose specific tools instead of just picking things at random.

What to Expect

I’m starting small to lock in the fundamentals, but the complexity is going to ramp up fast. You can expect to see projects covering:

Local development environments and containerization
CI/CD pipelines that actually mimic production workflows
Infrastructure as Code (IaC) with modular, reusable setups
Observability, monitoring, and alerting dashboards
Cloud-native Kubernetes deployments and GitOps workflows

Whether you are also on your DevOps journey, a seasoned engineer looking to critique my architecture, or a hiring manager looking for someone who loves to build and document out in the open—I’d love to have you follow along.

Day 1 drops tomorrow. Let’s build.

dxdprojects (Deep Datta) · GitHub

dxdprojects has 5 repositories available. Follow their code on GitHub.

github.com

DEV Community: Deep Datta

Deploying Nginx on AWS EC2 Using Terraform — Automating Infrastructure

What I Built

Project Structure

Step 1: Variables

Step 2: Provider

Step 3: Networking

VPC

Subnet

Internet Gateway

Route Table

Step 4: Security Group

Step 5: Fetching the Latest Ubuntu AMI Dynamically

Step 6: EC2 Instance

Step 7: The Bootstrap Script

Deploying

dxdprojects / aws-ec2-nginx-terraform

Building a Production-Ready 3-Tier Application with Kubernetes Blue-Green Deployment

Introduction

Understanding the Architecture

The 3-Tier Application

Step 1: Containerizing with Docker

Step 2: Orchestrating with Kubernetes

Key Resources

Step 3: Blue-Green Deployment Strategy

Troubleshooting: Real Issues I Encountered

dxdprojects / 3-Tier-NodeJS-MySql

User Management App

Table of Contents

Features

Prerequisites

Setup Instructions

1. Setting Up MySQL Server

Taking an Existing App and Deploying It with Docker, Kubernetes, and Terraform

Why I Chose This Project

The First Step: Understanding the Application

Dockerizing the Application

Moving to Kubernetes

Terraform and AWS: The Infrastructure Part

What I Learned From This Project

1. You do not need to start from zero

2. Troubleshooting is normal

3. Security matters

Final Thoughts

dxdprojects / Multi-Tier-Bank-Application-on-Kubernetes

Multi-Tier Bank Application on Kubernetes

Project Overview

What the Application Does

Architecture

Building DevOps Projects from scratch to enterprise-grade

The Framework

What to Expect

dxdprojects (Deep Datta) · GitHub