DEV Community: TechEazy Consulting

Scaling Spring Boot with Auto Scaling Group (ASG) + Elastic Load Balancer (ELB)

TechEazy Consulting — Fri, 03 Oct 2025 06:24:09 +0000

Deploying a Spring Boot app on multiple EC2 instances with an Application Load Balancer (ALB) works great ✅
But what happens when traffic spikes? Or if one EC2 instance crashes?

👉 That’s where Auto Scaling Groups (ASG) step in.

By the end of this guide, you’ll know how to:

Create an AMI of your Spring Boot app
Build a Launch Template
Configure an Auto Scaling Group (ASG)
Integrate it with your Application Load Balancer (ALB)
Auto-scale your application 🚀

👉 Flow: Browser → ELB → ASG → EC2 Instances running Spring Boot

🔑 Pre-requisite

From the previous blog, you should already have:

✅ 2 EC2 instances with Spring Boot JAR deployed on port 8080

✅ Application Load Balancer (ALB) setup with a Target Group

📦 Step 1: Create an AMI (Golden Image)

We’ll use one existing EC2 as a base image (AMI).

Go to EC2 Dashboard → Instances
Select an EC2 instance where your Spring Boot app is running
From Actions → Image and Templates → Create Image
Name it: springboot-ami
Click Create AMI

⏳ Wait 8–10 minutes. This AMI will be the blueprint for new EC2s in the ASG.

📝 Step 2: Create a Launch Template

Launch Template = Recipe to spin up new EC2s.

Go to EC2 → Auto Scaling Groups → Create Auto Scaling Group
Under Launch Template, click Create new launch template
Fill details:

Name: springboot-template
AMI: Select My AMIs → springboot-ami
Instance type: t3.micro
Key Pair: Same as before
Security Group: Must allow 22 (SSH), 80 (HTTP), 8080 (Spring Boot)

Add User Data (to auto-start the app):

#!/bin/bash
cd /home/ubuntu
sudo nohup java -jar app.jar > app.log 2>&1 &

Click Create Launch Template ✅

⚙️ Step 3: Create Auto Scaling Group (ASG)

Back to Auto Scaling Group creation
Name: springboot-asg
Select the Launch Template you just created
Click Next

🌐 Step 4: Configure Network Settings

VPC → Default VPC
Subnets → Select available ones (where ALB exists)
Leave defaults → Next

🔗 Step 5: Integrate with Load Balancer

On Load Balancer settings:

Attach to existing Load Balancer
Select your Spring Boot Target Group (8080)
Enable ALB health checks for reliability

Click Next

📊 Step 6: Set Group Size & Scaling Policy

Define scaling behavior:

Desired capacity → 2 (start with 2 instances)
Minimum capacity → 1
Maximum capacity → 3

Add a scaling policy:

Policy type → Target tracking
Metric → ALB Request Count per Target
Target Group → springboot-tg
Target Value → 50 (scale out if >50 requests per instance)

✅ Step 7: Review & Create

Double-check everything
Click Create Auto Scaling Group

Your ASG is now active 🎉

🔍 Step 8: Verify Setup

Go to EC2 → Instances → You’ll see new instances launched by ASG
Open ELB → Target Group → Targets → Should show healthy instances
Try terminating one instance manually → ASG will auto-recreate it!

🧪 Step 9: Load Test Your Setup

To simulate traffic for 5 mins:

ab -n 1000 -c 50 http://<ALB_DNS_NAME>/api/adapt/welcome

(Using ApacheBench or any load testing tool)

🎯 ASG will launch new EC2s automatically if traffic increases.

🎯 Final Result

You’ve successfully:

✅ Created an AMI for your Spring Boot app

✅ Configured a Launch Template

✅ Built an Auto Scaling Group (ASG)

✅ Integrated ASG with your Load Balancer

✅ Enabled self-healing + scaling 🚀

Now your app can handle failures and traffic surges without manual effort 💪

✅ Next Steps 🚀

Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

Deploy a Spring Boot App on AWS EC2 with Load Balancer (Step-by-Step Guide)

TechEazy Consulting — Sat, 27 Sep 2025 05:10:41 +0000

🌍 Introduction

Deploying your application manually on AWS can be time-consuming and error-prone. You might face:

Traffic distributed unevenly across instances ❌
Manual setup of health checks and failover ❌
Lack of scalability and high availability ❌

👉 That’s where EC2 + ELB (Elastic Load Balancer) deployment shines.

By the end, you’ll understand how to deploy a Spring Boot app on multiple EC2 instances, set up an Application Load Balancer, and route traffic intelligently.

👉 Flow: Browser → ELB → EC2 Instances running Spring Boot

🔒 Step 1: Prepare Your Spring Boot App

Before we touch AWS, package your Spring Boot project into a runnable .jar file:

mvn clean package

You’ll get something like app.jar in the target/ directory.

✅ We assume the app runs on port 8080
✅ Requires Java and Maven installed locally
✅ Target is .jar deployment, not Docker

We used the adaptive-ai-qms Spring Boot app as an example. But you can replace it with any web application and port according to app.

⚡ Step 2: Launch EC2 Instances

Let’s spin up two EC2 instances for our Spring Boot app:

Go to AWS Console → EC2 → Launch Instance
OS: Ubuntu Server 24.04 LTS (Free Tier eligible)
Instance type: t2.micro
Key Pair: Create/choose one (for SSH access)
Configure Security Group:

SSH (22) → Your IP
HTTP (80) → Anywhere
Custom TCP (8080) → Anywhere (for Spring Boot)

🎯 Launch two EC2 instances with the same configuration.

📜 Step 3: Install Java & Deploy Spring Boot App

SSH into both instances:

ssh -i your-key.pem ubuntu@<EC2_PUBLIC_IP>

Install Java:

sudo apt update
sudo apt install openjdk-21-jdk -y

Upload your app using scp:

scp -i your-key.pem app.jar ubuntu@<EC2_PUBLIC_IP>:/home/ubuntu/

Run the app in the background:

sudo nohup java -jar app.jar > app.log 2>&1 &

Breakdown:

nohup: Keeps process running after logout
java -jar: Runs your Spring Boot app
> app.log 2>&1 &: Logs output and runs in background

✅ Now access your app via:

http://<EC2_PUBLIC_IP>:8080/api/adapt/welcome

Repeat for the second EC2 instance.

🌐 Step 4: Create an Elastic Load Balancer (ALB)

Now we’ll route traffic to both EC2 instances via a Load Balancer.

Go to EC2 → Load Balancers
Click Create Load Balancer → Application Load Balancer
Name: springboot-alb
Scheme: Internet-facing
VPC: Use default VPC
Select AZs: Pick where your EC2s are running
Security Group:

Create a new one: springboot-sg
Inbound Rules: Allow HTTP (80) and SSH (22)

Listener Setup

Protocol: HTTP
Port: 80

Create Target Group

Type: Instances
Name: springboot-tg
Protocol: HTTP
Port: 8080
Health check path: /actuator/health/readiness

✅ Register your two EC2 instances
✅ Attach this Target Group to the Load Balancer
✅ Click Create Load Balancer

Your ALB is now live and routing traffic.

🧪 Step 5: Test Your Setup

🎯 Go to Load Balancer → Description tab
📄 Copy the DNS name (e.g., springboot-alb-123456.ap-south-1.elb.amazonaws.com)

Visit:

http://<DNS_NAME>/api/adapt/welcome

Expected Output:

Welcome to Adaptation Controller - Techeazy

✅ Confirms ELB is routing to healthy EC2 instances
✅ Confirms Spring Boot app is working across both instances

🛠 You can now explore:

Manual deployment
Creating AMIs
Using Launch Templates with Auto Scaling

🎯 Conclusion

You’ve successfully:

✅ Deployed a Spring Boot app on EC2
✅ Set up a Load Balancer to route traffic
✅ Configured health checks to ensure uptime
✅ Created a production-ready architecture for web-scale apps

👉 Next, pair this setup with Auto Scaling Groups for true elasticity and high availability.

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!
💡 YouTube won’t get you a job. Real projects + real internship certificate will.
🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.
⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!
🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

AWS Auto Scaling Groups (ASG) – Beginner’s Guide

TechEazy Consulting — Fri, 12 Sep 2025 06:16:10 +0000

🌍 Introduction

When you run an application on AWS, manual server management can be painful:

Sudden traffic spikes → servers run out of capacity ❌
Low traffic hours → paying for unused servers ❌

👉 That’s where AWS Auto Scaling Groups (ASG) come in.

ASG automatically adjusts the number of EC2 instances to match demand. This ensures:

✅ Cost efficiency

✅ High availability

✅ Scalability

By the end, you’ll understand:
👉 Browser → ELB → Auto Scaling Group (dynamic scaling + health checks) → Healthy EC2 Instances

🔒 Step 1: Understand Auto Scaling Group

An Auto Scaling Group (ASG) is a collection of EC2 instances that:

Scale out (add instances) when demand increases
Scale in (remove instances) when demand drops
Replace unhealthy instances automatically

This gives you a self-healing, cost-optimized infrastructure.

⚡ Step 2: Learn Key ASG Terminologies

Here are the basic terms you’ll see when setting up ASG:

Term	Meaning
Launch Template/Config	Blueprint defining AMI, instance type, key pairs, security groups
Desired Capacity	Number of instances you want running normally
Minimum Capacity	Lowest number of instances allowed
Maximum Capacity	Highest number of instances allowed
Scaling Policy	Rules to scale in/out (CPU > 70%, requests/sec, schedule-based)
Health Check	Ensures only healthy instances remain in service
Termination Policy	Decides which instance to remove first when scaling in
Warm Pools	Pre-initialized instances for faster scaling
Elastic Load Balancer	Commonly paired with ASG to distribute traffic among instances

📜 Step 3: How ASG Works

User visits your app → request hits ELB
ELB forwards traffic to instances in an Auto Scaling Group
ASG monitors metrics (CPU, requests, custom metrics) via CloudWatch
When demand increases → ASG launches new instances
When demand decreases → ASG terminates extra instances
If an instance becomes unhealthy → ASG replaces it automatically

👉 Flow: Browser → ELB → Auto Scaling Group → Healthy EC2 Instances

🌐 Step 4: Benefits of ASG

✅ Scalability – Adjusts capacity based on traffic automatically

✅ High Availability – Distributes instances across multiple AZs

✅ Cost Efficiency – Pay only for the resources you actually need

✅ Self-Healing – Replaces unhealthy instances automatically

✅ Flexible Policies – Scale by schedule, metrics, or custom triggers

🧪 Step 5: Real-World Example

Imagine an E-commerce website:

You set min=2, desired=3, max=6 EC2 instances
Traffic spikes during a festival sale → ASG launches 3 more instances (total 6)
At midnight, traffic drops → ASG scales back to 3 instances
If one instance crashes → ASG replaces it automatically 🎉

This means your app stays responsive + cost-efficient at all times.

🎯 Conclusion

With ASG, you get:

✅ Right number of instances at the right time

✅ Lower costs during low demand

✅ High availability with automatic healing

✅ Seamless scaling with ELB integration

👉 For web apps – Combine ASG with ALB for best results

👉 For scheduled workloads – Use scheduled scaling

👉 For unpredictable workloads – Use dynamic scaling policies

This is the recommended AWS setup for building cost-efficient, highly available, production-grade applications 🚀

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

Originally published at https://blog.techeazyconsulting.com on September 12, 2025.

AWS Elastic Load Balancer (ELB) – Beginner’s Guide

TechEazy Consulting — Mon, 08 Sep 2025 06:44:44 +0000

🌍 Introduction

When you run an application on AWS, having just one server (EC2 instance) is risky:

If that server fails → your app goes down ❌
If too many users visit → server may crash ❌

👉 That’s where Elastic Load Balancer (ELB) comes in.

AWS ELB automatically distributes traffic across multiple servers (EC2, containers, Lambda). This ensures:
✅ High availability
✅ Scalability
✅ Fault tolerance

By the end, you’ll understand:
👉 Browser → ELB (smart routing + health checks) → Healthy Servers (EC2, ECS, Lambda)

🔒 Step 1: Understand ELB Types

AWS provides different types of load balancers for different use cases:

1️⃣ Application Load Balancer (ALB)

Works at Layer 7 (Application Layer)
Best for HTTP/HTTPS traffic
Supports content-based routing (host, path, headers)
Example: /api/* → API servers, /images/* → image servers

2️⃣ Network Load Balancer (NLB)

Works at Layer 4 (Transport Layer)
Handles TCP/UDP/TLS traffic
Extremely fast + scalable (millions of requests/sec)
Provides static IPs
Example: gaming, IoT, high-performance apps

3️⃣ Gateway Load Balancer (GWLB)

Works at Layer 3 (Network Layer)
For 3rd-party appliances (firewalls, intrusion detection)

4️⃣ Classic Load Balancer (CLB)

Legacy version
Works at Layer 4 & 7 (limited features)
⚠️ AWS recommends using ALB or NLB instead

⚡ Step 2: Learn Key ELB Terminologies

Here are the basic terms you’ll see when setting up ELB:

Term	Meaning
Target	Resource receiving traffic (EC2, Lambda, IP)
Target Group	A pool of targets (with health checks)
Listener	Process that checks for connections (protocol + port)
Listener Rule	Routing conditions (e.g., `/api/*` → API group)
Health Check	ELB test to ensure only healthy servers get traffic
AZ (Availability Zone)	AWS data centers where servers run
Cross-Zone LB	Distribute traffic across all AZs
Sticky Sessions	Keep same user on the same server
Security Groups	Firewall for ELB
Idle Timeout	Time before idle connections close
SSL/TLS Cert	Enables HTTPS (via AWS ACM)

📜 Step 3: How ELB Works

User visits your app (e.g., myapp.com)
Request goes to ELB Listener (port 80 or 443)
ELB checks Listener Rules
ELB forwards request to the correct Target Group
Health Check ensures only healthy servers receive traffic
Response goes back → ELB → user

👉 Flow: Browser → ELB → Healthy Server → ELB → Browser

🌐 Step 4: Benefits of ELB

✅ Scalability – Auto-scales with traffic
✅ High Availability – Multi-AZ support
✅ Security – SSL/TLS, WAF integration
✅ Monitoring – CloudWatch metrics, access logs
✅ Cost Efficient – Pay-as-you-go pricing

🧪 Step 5: Real-World Example

Imagine an E-commerce website:

You run 3 EC2 instances in different AZs
Deploy an Application Load Balancer in front
A user goes to www.shop.com → ELB receives request
ELB checks which server is healthy + least busy
Routes request → Server responds → User gets page
If one server crashes → traffic reroutes to healthy ones 🎉

🎯 Conclusion

With ELB, you get:

✅ Better performance
✅ Zero downtime (if a server fails)
✅ Intelligent routing
✅ Secure connections

👉 For websites → ALB
👉 For high-performance TCP apps → NLB
👉 For firewalls/security → GWLB

This is the recommended AWS setup for building highly available, production-grade applications 🚀

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

Securely Host Website with AWS CloudFront + Private S3 + Route 53 (Custom Domain + HTTPS)

TechEazy Consulting — Tue, 02 Sep 2025 13:28:00 +0000

🌍 Introduction

If you directly host a static site on AWS S3 (public), your files are exposed to the internet. This is fine for simple hosting, but not secure for production.

The best practice is:

Keep your S3 bucket private
Serve content via CloudFront (with caching + HTTPS)
Map domain using Route 53

This way, CloudFront acts as a secure CDN, while S3 only accepts requests from CloudFront ✅

By the end, you’ll have this flow:
👉 Browser → Route 53 (DNS) → CloudFront (HTTPS + caching + SSL) → S3 (private)

🔒 Step 1: Keep Your S3 Bucket Private

Block Public Access = ON ✅ (default)
Disable Static Website Hosting
Remove any public bucket policy

👉 Your bucket should have no public access.

⚡ Step 2: Create a CloudFront Distribution

Go to CloudFront → Distributions → Create Distribution
Custom Domain: Enter your domain name (myapp.com)
If no SSL → Request a free SSL certificate from ACM and attach it
Specify Origin:
- Origin type → S3
- Origin → Select your bucket
- Origin Path → /index.html (if required)
- Enable OAC (Origin Access Control) → Allows CloudFront to access your private S3 bucket
Leave other settings as default
(Optional) WAF → Not needed for now
Save distribution

📜 Step 3: Update S3 Bucket Policy

After CloudFront is created → it will suggest a bucket policy (under Settings → Origins → Edit)
Copy that policy and paste it into your S3 bucket policy section
✅ This ensures that only CloudFront can read from your S3 bucket

🌐 Step 4: Update Route 53 DNS

Go to your Hosted Zone (example: myapp.com)
Create a Record:
- Name → myapp.com
- Type → A (Alias)
- Alias → Yes
- Target → Select your CloudFront distribution
(Optional) Create another record for www.myapp.com → CloudFront

🧪 Step 5: Test Setup

Wait 5–15 minutes for CloudFront distribution to deploy
Open:

  https://myapp.com

Flow is now: Browser → Route 53 → CloudFront → S3 (private) 🎉

🎯 Conclusion

With this setup, you get a secure and production-ready website hosting on AWS:

✅ Private S3 bucket (no public exposure)
✅ CloudFront with HTTPS + caching
✅ Custom domain via Route 53
✅ Free SSL from ACM

This is the recommended AWS architecture for static site hosting in production 🚀

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

Deploy Static HTML/CSS Website to AWS S3 with CI/CD (GitHub Actions)

TechEazy Consulting — Mon, 01 Sep 2025 23:21:00 +0000

🌍 Introduction

If you’re tired of manually uploading files to AWS S3 for hosting your static site, then CI/CD with GitHub Actions is the perfect solution.

In this guide, we’ll set up:

An S3 bucket for static hosting
IAM user with permissions
GitHub secrets for secure credentials
GitHub Actions workflow for auto-deployment

By the end, every time you push code to GitHub → your site updates automatically 🚀

🛠 Step 1️ : Prepare Your Files

Make sure you have your index.html, style.css, images, etc. ready in a folder.
Push your project to a GitHub repository.

🪣 Step 2 : Create an S3 Bucket

Go to AWS Management Console → S3.
Click Create bucket.
Enter a unique bucket name (e.g., portfolio-website).
Uncheck Block all public access if you want the site to be public.
Click Create bucket.

⚙️ Step 3 : Configure Bucket for Static Website Hosting

Open created bucket.
Go to the Properties tab of your bucket.
Scroll to Static website hosting → Edit.
Enable it and set:
- Index document: index.html
- Error document: (optional, e.g., 404.html)
Save changes.

🔓 Step 4 : Public Access Setup

Open the Permissions tab and set a bucket policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
    }
  ]
}

Save changes.
Now the website can be accessed publicly.

👤 Step 5 : Create an IAM User for CI/CD (AWS Console of Your Account)

Click on Users in the left menu.
Click the Add users button.
Enter a username. Click Next.

🔑 Step 6: Set Permissions

Select Attach policies directly → Create policy → JSON option.
For deploying a project to S3, use the following policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::YOUR_BUCKET_NAME",
        "arn:aws:s3:::YOUR_BUCKET_NAME/*"
      ]
    }
  ]
}

Click Next, enter a policy name, and create the policy.
Select created policy for user.

✅ Step 7: Review and Create User

Click Next until you reach the Review page.
Verify the details and click Create user.

🔐 Step 8: Assign Programmatic Access to the User

Click on the newly created user.
Go to the Security credentials tab.
In the Access keys section, click on Create access key.
Follow the steps to create the access key.
Copy the Access Key ID and Secret Access Key.
Download or save them — you won’t be able to see the secret again.
The user is now created and has the assigned permissions.

🔒 Step 9 : Add Secrets in GitHub

Go to your GitHub repo → Settings → Secrets and variables → Actions → New repository secret.
Add these secrets:
- AWS_ACCESS_KEY_ID → your IAM user key
- AWS_SECRET_ACCESS_KEY → your IAM user secret
- AWS_REGION → region of your bucket (e.g., ap-south-1)
- S3_BUCKET_NAME → your bucket name

⚡ Step 10 : Create GitHub Actions Workflow

In your project, create folder/file:

.github/workflows/deploy.yml

name: Deploy Website to S3

on:
  push:
    branches:
      - master

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Sync files to S3
        run: aws s3 sync . s3://${{ secrets.S3_BUCKET_NAME }} --delete

🚀 Step 11 : Deploy Automatically

Commit and push your code to main branch.
GitHub Actions will run → upload files to S3 → your website updates automatically 🎉

🌐 Step 12 : Access Your App

Go to S3 → Properties → Static website hosting.
Copy the Bucket website endpoint URL.
Open it in your browser — your HTML + CSS site is live and auto-deployed 🚀

🎯 Conclusion

With this setup, you now have a CI/CD pipeline that deploys your static site to AWS S3 automatically whenever you push changes to GitHub.

✅ No more manual uploads.
✅ Faster deployments.
✅ Professional workflow like modern DevOps teams.

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

Connect Custom Domain to AWS S3 Website using Route 53

TechEazy Consulting — Mon, 01 Sep 2025 18:30:00 +0000

🚀 Introduction

Hosting your static website on AWS S3 is simple, but by default you get a long AWS URL like:

http://myapp.com.s3-website-us-east-1.amazonaws.com

To make your site look professional, you need a custom domain (like myapp.com).
In this guide, you’ll learn how to:

Buy/register a domain (Route 53 or third-party like GoDaddy/BigRock)
Create a hosted zone in Route 53
Configure S3 for website hosting
Point your domain to S3 using Route 53 records

By the end, you’ll have your app live on http://myapp.com 🚀

🪪 Step 1: Buy / Register a Domain

You can buy from Route 53 or another registrar like GoDaddy or BigRock.
In this example, we’ll use a domain from BigRock:

  myapp.com

🗂 Step 2: Create a Hosted Zone in Route 53

Go to AWS Console → Route 53 → Hosted Zones → Create Hosted Zone.
Enter your domain name:

  myapp.com

Choose Public Hosted Zone → Click Create Hosted Zone.
Route 53 will give you 4 NS (Name Server) records.
Copy these NS records → Go to your domain registrar (BigRock, GoDaddy, etc.) → Update your domain’s Nameserver settings with these 4 values.

🪣 Step 3: Configure S3 for Website Hosting

Create an S3 bucket with the exact name of your domain:

  myapp.com

(If you want a subdomain, bucket name must be: www.myapp.com)
Enable Static Website Hosting in bucket properties.
Disable Block All Public Access.
Add a read-only bucket policy (same as in previous blog).
After saving, you’ll get a website endpoint like:

http://myapp.com.s3-website-us-east-1.amazonaws.com

🌍 Step 4: Create a Record in Route 53

Go to your Hosted Zone in Route 53.
Click Create Record.
Name: myapp.com (or www.myapp.com for subdomain).
Record Type: A – Route traffic to IPv4 & AWS resources.
Alias: Yes.
Route traffic to: S3 website endpoint.
Select the correct region.
Save the record.

✅ Done! Now your domain points to your S3 bucket.
Visiting http://myapp.com will show your hosted website 🎉

🎯 Conclusion

You’ve successfully connected your custom domain to an AWS S3 hosted site using Route 53.

This setup gives you:

A professional domain name
Easy DNS management inside AWS
A scalable static website hosting solution

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

How to Host a Static Website on AWS S3 (Step-by-Step Guide)

TechEazy Consulting — Mon, 01 Sep 2025 16:16:00 +0000

🚀 Introduction

If you’ve built a static website using HTML, CSS, and images, the next step is getting it online. One of the simplest and most cost-effective ways is to use Amazon S3 (Simple Storage Service).

With just a few clicks, you can deploy your static site and make it accessible to the world — no servers required!

Let’s go step by step.

🛠 Step 1: Prepare Your Files

Make sure your project folder contains all necessary files, such as:

index.html
style.css
Any images or assets

👉 Keep them organized in a single folder before uploading.

🧩 Step 2: Create an S3 Bucket

Log in to AWS Management Console → S3
Click Create bucket
Enter a unique bucket name (example: portfolio-website)
Uncheck Block all public access if you want your site to be public
Click Create bucket

⚙️ Step 3: Configure Bucket for Static Website Hosting

Open your newly created bucket
Go to the Properties tab
Scroll to Static website hosting → Edit
Enable it and set:

Index document → index.html
Error document → 404.html (optional)
1. Save changes

🔓 Step 4: Make Files Public

There are two ways to allow public access:

Option 1: Manually

Select all objects → Click Actions → Make public

Option 2: Bucket Policy (Recommended)

Go to Permissions → Bucket Policy
Paste the following JSON (replace YOUR_BUCKET_NAME):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
    }
  ]
}

Save changes

📤 Step 5: Upload Your Files

Go to the Objects tab
Click Upload → Add files
Select all your project files (index.html, style.css, images, etc.)
Click Upload

🌍 Step 6: Access Your App

Open the Properties tab of your bucket
Scroll to Static website hosting
Copy the Bucket website endpoint URL
Paste it into your browser — your site is live 🎉

🎯 Conclusion

Hosting a static website on AWS S3 is one of the fastest ways to make your portfolio, landing page, or small project available online.

It’s cost-efficient, secure, and scalable — making it perfect for developers of all levels.

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

GitHub Branch Protection Rules: Why and How to Use Them

TechEazy Consulting — Mon, 01 Sep 2025 15:17:00 +0000

🚀 Introduction

When working on projects with multiple developers, maintaining code quality and stability becomes critical.
That’s where branch protection rules come in.

Branch protection rules in GitHub allow repository admins to enforce certain workflows, such as requiring pull requests before merging, enforcing code reviews, or restricting who can push changes.

In this blog, we’ll explore:

What branch protection rules are
Why they matter
Common rules you can set up
Best practices for teams

🧑‍🏫 What Are Branch Protection Rules?

Branch protection rules are settings in GitHub that apply restrictions to a branch — typically the main or master branch.

They prevent developers from making direct changes that could break the codebase. Instead, rules encourage safer collaboration through pull requests and reviews.

👉 Think of them as guardrails to protect your project’s most important branches.

🌟 Why Use Branch Protection Rules?

Here’s why teams (and even solo developers) benefit from them:

Code Stability → Protects the main branch from accidental or unstable changes.
Collaboration → Ensures features go through peer reviews before merging.
Security → Restricts who can merge changes or force-push branches.
Quality Control → Allows automated checks (like CI/CD tests) before merging.

In short, branch protection rules increase reliability and reduce risks.

🛠️ Common Branch Protection Settings

When creating rules in GitHub, you’ll find several options. The most commonly used are:

Require Pull Requests Before Merging

Ensures all changes are reviewed before being merged.
You can even set the number of reviewers required.

Require Status Checks to Pass Before Merging

Integrates with CI/CD pipelines (like GitHub Actions).
Ensures code passes tests before merging.

Require Signed Commits

Adds a layer of security by verifying commit authorship.

Restrict Who Can Push to the Branch

Limits push permissions to specific people or teams.

Require Conversation Resolution

Prevents merging until all review comments are resolved.

🧩 How to Set Up Branch Protection Rules

Go to your GitHub repository.
Click on Settings.
Under Branches, click Add Rule.
Enter the branch name pattern (e.g., main).
Select the rules you want to apply (pull request reviews, status checks, etc.).
Save the changes.

👉 From now on, those rules will apply whenever someone tries to modify that branch.

💡 Best Practices for Branch Protection

Always protect your main branch (or master if used).
Require at least one pull request review before merging.
Enable status checks if you have automated tests.
Restrict force pushes to avoid history corruption.
Communicate the rules clearly with your team.

🎯 Conclusion

Branch protection rules are an essential feature for any project — whether you’re a solo developer or part of a large team.

They safeguard your main branch, enforce reviews, and keep your project stable. By using them wisely, you ensure that collaboration leads to better, safer, and more reliable code.

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

Repositories, Branches, and Pull Requests

TechEazy Consulting — Mon, 01 Sep 2025 13:12:00 +0000

🚀 Introduction

GitHub is an essential tool for developers, providing a powerful platform for version control, collaboration, and code management.

In this guide, we’ll cover the core concepts of working with GitHub, including:

Creating repositories
Working with branches
Managing pull requests (PRs)
Cloning existing repositories

Whether you’re completely new to GitHub or looking to improve your workflow, this blog will give you the confidence to manage projects effectively.

🧑‍🏫 1. Creating a GitHub Repository

One of the first steps in using GitHub is creating a new repository — a centralized location where your project files and history are stored.

You can initialize a repository locally and then link it to GitHub.

# Initialize a new repository
git init

# Stage all files for commit
git add .

# Commit changes locally
git commit -m "Initial commit"

# Set the branch to main
git branch -M main

# Link the local repo to GitHub
git remote add origin https://github.com/<username>/<repo>

# Push the code to the main branch
git push -u origin main

👉 This process sets up your project and pushes it to a remote repository on GitHub.

🧑‍🏫 2. Working with Branches

Branches allow you to work on new features or bug fixes without disturbing the main branch. They are one of GitHub’s most powerful features for collaboration.

# Create and switch to a new branch
git checkout -b feature-branch

# Push the new branch to GitHub
git push -u origin feature-branch

👉 Branches keep your workflow organized, especially in team projects, and make it easier to merge code once it’s ready.

🧑‍🏫 3. Managing Pull Requests (PRs)

A pull request is how developers propose changes to a repository. It enables discussion, code review, and collaboration before merging changes.

The typical PR workflow:

Create a PR → Open a pull request once your branch is ready.
Code Review → Teammates review, comment, and suggest changes.
Merge → After approval, the branch is merged into the main branch.

👉 Pull requests are the backbone of collaboration in open-source and team projects.
For more details, check GitHub’s documentation on PRs here.

🧑‍🏫 4. Cloning an Existing Repository

Instead of starting from scratch, you can clone an existing repository to your local machine.

# Clone a repository to your local machine
git clone https://github.com/techeazy-consulting/demorepo.git

👉 This downloads the entire repository (including history), so you can work on it locally.

🎯 Conclusion

GitHub makes it easier than ever to manage code, collaborate with others, and contribute to open-source projects.

Repositories keep your work organized.
Branches let you experiment safely.
Pull requests encourage collaboration and quality checks.
Cloning helps you get started with existing projects.

Mastering these fundamentals is a big step toward becoming a confident developer in team environments.

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!
💡 YouTube won’t get you a job. Real projects + real internship certificate will.
🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.
🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.
⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!
🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

Connecting Git to GitHub (with PAT Token)

TechEazy Consulting — Mon, 01 Sep 2025 11:44:00 +0000

🚀 Introduction

So far, you’ve learned the basics of Git and GitHub. But how do you actually connect your local project to GitHub?
That’s where Personal Access Tokens (PATs) come in.

GitHub has deprecated password authentication for Git operations, and now recommends using PAT tokens for secure access. In this blog, we’ll walk through the entire process of pushing a new project from your computer to GitHub — step by step.

🧑‍🏫 Step 1: Configure Git (only once per computer)

Before pushing anything, you need to tell Git who you are. Run these commands in your terminal:

git config --global user.name "Your Name"
git config --global user.email "your_email@example.com"
git config --global credential.helper store

👉 This sets up your identity and ensures Git can store credentials for future use.

🧑‍🏫 Step 2: Create a Spring Boot project

For this example, let’s create a demo project using Spring Initializr:

Go to 👉 https://start.spring.io/
Select:

Project: Maven
Language: Java
Spring Boot: latest stable
Group: com.example
Artifact: demo
(Optional) Add Spring Web dependency
1. Click Generate Project → a .zip file will download.
2. Extract the project and open it in your IDE (IntelliJ IDEA or VS Code).

🧑‍🏫 Step 3: Create an empty GitHub repository

Next, let’s set up a remote repository on GitHub:

Log in to 👉 https://github.com.
Click New Repository.
Enter repo name → spring-demo.
⚠️ Keep the repository empty (don’t add README, .gitignore, or license).
Click Create Repository.

🧑‍🏫 Step 4: Generate a PAT (Personal Access Token)

Now we need a PAT to authenticate securely:

Go to 👉 GitHub Settings → Developer Settings → Personal access tokens.
Click Tokens (classic) → Generate new token (classic).
Fill in details:

Name: spring-project-token
Expiration: 30 days (or as needed)
Permissions: ✅ repo
1. Click Generate token.
2. Copy the token (e.g., ghp_abc123XYZ...) and save it somewhere safe.

🧑‍🏫 Step 5: Connect local project to GitHub

Open your terminal inside the Spring project folder and run:

git init
git remote add origin https://github.com/your-username/spring-demo.git
git add .
git commit -m "Initial Spring Boot project"
git branch -M main
git push -u origin main

🧑‍🏫 Step 6: Authenticate with GitHub

When you run the push command:

Git will ask for username → enter your GitHub username.
Git will ask for password → paste your PAT token.

🎉 Step 7: Verify on GitHub

Finally, go to your repository on GitHub.
You should now see your Spring Boot project uploaded successfully 🚀

🎯 Conclusion

That’s it! You’ve just connected your local Git project to GitHub using a Personal Access Token.

Git is now configured on your machine.
Your project is securely stored in GitHub.
You’re ready to collaborate with others.

This process is a one-time setup per project — once done, future pushes will be much simpler.

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

Introduction to Git and GitHub: A Beginner’s Guide

TechEazy Consulting — Mon, 01 Sep 2025 11:10:00 +0000

🚀 Introduction

If you’ve just started your journey into software development, you’ve probably heard people talking about Git and GitHub. They might sound similar, but they serve different purposes — and together, they’re two of the most powerful tools every developer should know.

This blog is a beginner-friendly explanation of Git and GitHub, how they differ, and why they are essential for modern software development. No code, just theory made simple.

📝 What is Git?

Git is a version control system (VCS).

Think of it as a time machine for your code. It lets you:

Save snapshots of your project as you work.
Go back to previous versions if something breaks.
Experiment with new ideas without losing your original work.

Created by Linus Torvalds in 2005 (yes, the same person behind Linux 🐧), Git has become the most widely used version control system in the world.

Why Developers Use Git

Track Changes → Know exactly what changed and when.
Collaboration → Multiple people can work on the same project without stepping on each other’s toes.
Backup → Even if your local computer fails, your history of changes is safe once you push it to a remote repository.

🌐 What is GitHub?

If Git is the engine, GitHub is the garage where you store and showcase your projects.

GitHub is a cloud-based hosting platform for Git repositories. It adds a social layer to software development, allowing developers to share, collaborate, and contribute to each other’s work.

Key Features of GitHub

Remote Repository Hosting → Store your code safely in the cloud.
Collaboration Tools → Pull requests, issues, and project boards make teamwork organized.
Open Source Contributions → Millions of projects are open source, meaning anyone can learn from or contribute to them.
Community → Developers connect, follow, and learn from each other.

🔑 Git vs GitHub: What’s the Difference?

Many beginners confuse Git and GitHub, but here’s the simple distinction:

Git → A tool installed on your computer to track changes in your code.
GitHub → An online platform that hosts Git repositories and helps developers collaborate.

👉 You can use Git without GitHub, but you cannot use GitHub effectively without Git.

🌟 Why Should You Learn Git and GitHub?

Whether you’re a student, hobbyist, or professional developer, learning Git and GitHub opens the door to:

Better productivity: You’ll never lose track of your work.
Teamwork skills: Almost all companies expect developers to know Git.
Open-source contributions: You can give back to the developer community.
Portfolio building: GitHub profiles often serve as a living resume for developers.

🎯 Conclusion

Git and GitHub might seem intimidating at first, but they are simply tools designed to make your development journey smoother.

Git helps you manage and track your project history.
GitHub provides a collaborative platform to share and improve your projects.

If you’re starting out, don’t worry about mastering everything at once. Understanding the theory is the first step — and you’ve just taken it! 🚀

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting