DEV Community: Kaustav Dey

if you're reading this, then just like the post , it helps

Kaustav Dey — Wed, 11 Jun 2025 10:29:13 +0000

🚀 Built a Serverless Image Optimizer with AWS Lambda + S3 (Free Tier Safe)

Kaustav Dey ・ Jun 11

🚀 Built a Serverless Image Optimizer with AWS Lambda + S3 (Free Tier Safe)

Kaustav Dey — Wed, 11 Jun 2025 10:12:47 +0000

TL;DR: Upload an image to S3 → Lambda compresses it → Optimized version appears.
Fully serverless, beginner-friendly, and no surprise AWS bills.

👋 Introduction

Image compression is a common but repetitive task — especially for indie developers or small teams deploying images to the cloud. So I decided to build an automated image optimizer using AWS Lambda and S3.

This project runs 100% on the AWS Free Tier, and I’ve included teardown scripts to help you avoid any unwanted charges.

Whether you’re learning AWS, building portfolio projects, or automating real-world workflows — this one’s for you.

⚙️ What I Built

Whenever you upload an image to a specific S3 bucket, it automatically triggers a Lambda function which:

Reads the image
Compresses it using Pillow (Python image library)
Saves an optimized version back to the bucket with the prefix optimized-

This is all done in a serverless fashion — no EC2, no containers, no headache.

🛠️ Tech Stack

AWS Lambda — Python 3.11 function to handle the image compression
Amazon S3 — Triggers Lambda on image uploads
IAM Roles — To grant minimal and secure permissions
Pillow — For optimizing images in Python
Shell Scripts — To deploy and clean up resources easily

📁 Project Structure

serverless-image-optimizer/
├── lambda/
│   └── handler.py             # Main Lambda code
├── deploy/
│   ├── create_resources.sh    # Setup script
│   ├── delete_resources.sh    # Teardown script
│   └── trust-policy.json      # IAM trust policy
├── test-images/               # Sample images
├── requirements.txt           # Pillow dependency
└── README.md

🚀 How It Works

Upload an image (.jpg, .png) to your S3 bucket.
Lambda automatically gets triggered.
It compresses and saves the new image as optimized-filename.jpg.
Simple. Fast. Scalable. Free-tier friendly.

🧯 Avoiding AWS Charges

Cloud costs can creep up if you’re not careful. This project is:

✅ 100% AWS Free Tier compatible
✅ No long-running services (like EC2)
✅ Includes a delete_resources.sh teardown script

Run this when you’re done:

bash deploy/delete_resources.sh

📂 GitHub Repo

👉 View Full Code on GitHub
Includes full setup, teardown, and README documentation.

📈 Who Should Use or Learn from This?

Cloud beginners looking to practice Lambda + S3 triggers
Indie hackers automating small tasks
DevOps learners building their portfolio
Freelancers wanting cost-safe infrastructure automation

🧠 What I Learned

How to securely connect Lambda to S3
Optimizing Lambda deployment with zipped packages
Using IAM roles with least-privilege principle
Keeping projects within the Free Tier to avoid billing issues

💬 Feedback?

Have suggestions? Want to collaborate?
I’m open to feedback, pull requests, or just geeking out over serverless ideas!

📢 Let’s Connect

If you’re a solo developer, early-stage startup, or indie hacker looking to automate your AWS infra, I’m offering free 30-min consultations.
DM me on LinkedIn or leave a comment!

How I Provisioned Scalable AWS Infrastructure with Terraform and Load Balancer

Kaustav Dey — Thu, 15 May 2025 09:22:04 +0000

The Git Repo

As I deepened my understanding of DevOps and cloud fundamentals, I wanted to get hands-on with provisioning infrastructure the right way: using Infrastructure as Code (IaC). In this post, I’ll walk through how I built a reusable Terraform project to provision an EC2 instance, attach a load balancer, configure security groups, and get it all running on AWS.

This project was part of my journey in creating modular and production-oriented DevOps blueprints.

🧰 Tools & Tech

Terraform for IaC
AWS EC2 for compute resources
Application Load Balancer (ALB) for routing
Security Groups for access control
Remote backend support with Terraform state files

📦 Project Structure

I broke the configuration into reusable, modular Terraform components to make the codebase scalable and production-ready. Here's how the structure looked:

.
├── main.tf           # Orchestrator: may call modules or glue everything together
├── variables.tf      # All variable declarations with types and descriptions
├── outputs.tf        # Output values (e.g., IPs, DNS names, ARNs)
├── vpc.tf            # VPC, subnets, internet gateway, etc.
├── ec2.tf            # EC2 instance(s), AMIs, key pairs, EBS volumes
├── alb.tf            # Application Load Balancer, listeners, target groups
├── security.tf       # Security groups, network ACLs, firewall rules
├── README.md         # Project documentation
├── .gitignore        # Files to exclude from Git (e.g., `.terraform`, `*.tfstate`)

Each module encapsulates a piece of the infrastructure (e.g., EC2, security group), keeping things clean and reusable.

🏗️ What It Provisions

When executed, the Terraform code provisions:

A public subnet in a selected region
An EC2 instance with user data for bootstrapping
A Security Group that allows inbound traffic on ports 22 and 80
An Application Load Balancer (ALB) that distributes HTTP traffic
Target group + listener configuration for the EC2 instance

🧪 How to Use It

Clone the repo and run the following inside the root directory:

terraform init
terraform plan
terraform apply

Make sure your AWS credentials are set in your environment or shared credentials file.

Once applied, the EC2 instance and ALB will be up and running. You’ll get the public DNS of the load balancer in the Terraform output.

✅ Outcome

With a single command, I spun up a complete production-grade architecture using Terraform. It’s scalable, reusable, and can easily be extended to include databases, autoscaling, and monitoring.

The architecture diagram is:

📌 Key Learnings

Writing modular Terraform code is essential for maintainability
ALBs are ideal for HTTP/HTTPS workloads with flexible routing
Outputs and variables improve reusability and flexibility
Infrastructure automation saves time and reduces errors

🧠 Next Steps

I’m planning to:

Add support for private subnets and NAT gateways
Integrate with RDS or DynamoDB
Add Terraform Cloud remote backend
Extend this into a full production deployment pipeline

🔗 Resources

GitHub Repo: Terraform AWS EC2 Load Balancer Deployment

☎️ Let's Connect

If you're building something cloud-native or want help setting up secure AWS infrastructure, I’d love to chat.

Email: deykaustav357@gmail.com
LinkedIn: https://www.linkedin.com/in/kaustav-dey-107593244
Portfolio: Kaustav Dey DevOps & Cloud Specialist | AWS • Docker • Terraform • CI/CD

How I Deployed a Dockerized App to AWS Using Terraform and GitHub Actions

Kaustav Dey — Thu, 15 May 2025 08:55:36 +0000

The Git Repo

As a DevOps and cloud enthusiast, I wanted to go beyond theoretical knowledge and create something real. In this post, I’ll walk through how I provisioned infrastructure on AWS using Terraform and deployed a Dockerized app using GitHub Actions CI/CD. This project helped me apply core DevOps practices and build a production-ready pipeline from scratch.

🛠️ Stack Overview

Terraform for infrastructure provisioning
EC2 for hosting the app
Docker to containerize the application
GitHub Actions for CI/CD
SCP + SSH for deployment automation

1️⃣ Infrastructure as Code with Terraform

I started by defining all infrastructure in Terraform to make deployments consistent and version-controlled. The configuration included:

An EC2 instance with a public IP
A security group allowing SSH (22), HTTP (80), and app port (4000)
Optional Elastic Load Balancer for scalability

With reusable modules, I was able to spin up the entire environment with:

terraform init
terraform apply

2️⃣ Dockerizing the App

I deployed a simple Node.js app and containerized it using the following Dockerfile:

FROM node:18-alpine
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 4000
CMD ["node", "app.js"]

Containerization ensured consistent behavior across dev and prod.

3️⃣ CI/CD with GitHub Actions

To automate deployment, I set up a GitHub Actions pipeline triggered on every push to main. It:

SSHs into the EC2 instance
Sends code using scp
Builds and runs a Docker container remotely

Here’s a simplified snippet of the deploy.yml workflow:

name: Deploy to EC2

on:
  push:
    branches: [main]

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

      - name: Set up SSH
        run: |
          echo "${{ secrets.EC2_SSH_KEY }}" > key.pem
          chmod 600 key.pem

      - name: Deploy App
        run: |
          scp -i key.pem -r . ubuntu@${{ secrets.EC2_HOST }}:/home/ubuntu/app
          ssh -i key.pem ubuntu@${{ secrets.EC2_HOST }} '
            cd app &&
            docker build -t myapp . &&
            docker stop myapp || true &&
            docker rm myapp || true &&
            docker run -d -p 4000:4000 --name myapp myapp

All secrets like the SSH key and host IP are stored securely in GitHub.

✅ Results

Once deployed, the app was accessible at:

http://<EC2_PUBLIC_IP>:4000

Each push to GitHub automatically redeploys the latest code, saving time and ensuring consistency.

💡 Lessons Learned

Terraform makes infra reproducible and scalable
Docker simplifies app deployment
GitHub Actions is powerful and integrates directly with your codebase
Keeping sensitive values in .env and .env.example is best practice

🔭 What's Next?

I’m planning to explore:

Monitoring with CloudWatch
Auto-scaling groups
Using ECS or Fargate for container orchestration

🔗 Resources

GitHub Repo: ci-cd-pipeline-aws
Live Demo: http://<your-ec2-ip>:4000

☎️ Let's Connect

If you're a solo dev or early-stage founder looking to deploy to AWS with CI/CD and infrastructure automation, I can help.

Email: deykaustav357@gmail.com
LinkedIn: https://www.linkedin.com/in/kaustav-dey-107593244
Portfolio Website: Kaustav Dey DevOps & Cloud Specialist | AWS • Docker • Terraform • CI/CDm

🖥️ No IDE? No Problem: How I Started an EC2 Instance Using AWS CloudShell and SSH’d in From the Terminal

Kaustav Dey — Mon, 05 May 2025 07:00:49 +0000

There’s something empowering about spinning up your own virtual machine in the cloud — especially when you do it entirely from the command line.

No clicking through tabs. No IDE. No download-this, install-that.

Just pure terminal.

Just you and the cloud.

🌩️ Why I Tried AWS CloudShell

As a cloud enthusiast (and someone who occasionally breaks things on my own machine), I decided to explore AWS CloudShell — a browser-based terminal environment that runs right inside the AWS Management Console. No need to install the AWS CLI or generate SSH keys on my laptop. It’s preloaded, persistent, and honestly, kind of amazing.

I’d previously used EC2 through the UI, but this time, I challenged myself:

“Can I launch and connect to an EC2 instance without ever leaving the terminal?”

Spoiler: Yes. And here’s how I did it.

⚙️ Step 1: Opened CloudShell

From the AWS Console, I clicked on the little terminal icon in the top-right — that’s CloudShell.

Within seconds, I had a shell prompt, running in a pre-configured Amazon Linux environment, with full AWS CLI access.

🔐 Step 2: Created a Key Pair

To connect via SSH later, I needed a key pair. From CloudShell, I ran:

aws ec2 create-key-pair
  --key-name my-key 
  --query 'KeyMaterial' 
  --output text > my-key.pem

Then I set the right permissions:

chmod 400 my-key.pem

✅ This generated a private key and saved it locally in CloudShell. No downloading needed.

🚀 Step 3: Launched the EC2 Instance

I picked a simple Amazon Linux AMI and started a t2.micro instance like this:

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \  # Replace with a valid AMI ID in your region
  --count 1 \
  --instance-type t2.micro \
  --key-name my-key \
  --security-groups default

Want a specific region? Add --region us-east-1 or whatever suits your setup.

I noted the returned _InstanceId _because I’d need it soon.

🔍 Step 4: Waited for the Instance and Got the Public IP

Once the instance was running, I fetched its public IP:

aws ec2 describe-instances
  --filters "Name=instance-state-name,Values=running" 
  --query "Reservations[*].Instances[*].PublicIpAddress" 
  --output text

This gave me something like:

3.145.78.123

That’s my gateway into the cloud machine.

🔗 Step 5: SSH’d Into My Instance

Now came the satisfying part — actually connecting. Still in CloudShell, I ran:

ssh -i my-key.pem ec2-user@3.145.78.123

And boom 💥 — I was in.

A full-blown Linux VM, all mine, running in the cloud, controlled 100% from the browser-based terminal. No local setup. No downloads. Just me and my instance.

🧼 Bonus: Cleaning Up

When I was done experimenting, I cleaned up to avoid extra costs:

aws ec2 terminate-instances --instance-ids i-0abcd1234efgh5678

And optionally deleted the key:

aws ec2 delete-key-pair --key-name my-key
rm my-key.pem

🧠 What I Learned

AWS CloudShell is perfect for CLI-based workflows, even on a Chromebook or borrowed laptop.
You don’t need a full IDE or even a configured local environment to manage cloud infrastructure.
The AWS CLI is incredibly powerful (and feels like a cheat code once you get comfortable).

🎯 Final Thoughts

Starting an EC2 instance from the terminal might seem intimidating — but it’s actually elegant. Clean. Fast. And it gives you a deeper sense of control than the AWS GUI ever could.

If you’ve been hesitant to touch the CLI, I highly recommend giving CloudShell a try. It’s like training wheels for power users.

And once you SSH into your first cloud machine using nothing but the terminal?
You’ll never forget that feeling.

🚀 From S3 to Speed: How I Supercharged My Static Website with AWS CloudFront

Kaustav Dey — Sun, 04 May 2025 10:14:15 +0000

In one of my previous posts, I walked you through how I hosted a basic static website on Amazon S3 using just two humble files: an index.html and an image. It was simple, effective, and honestly kind of magical seeing my HTML come to life on the web.
But as with most things in tech, I got curious - what if I could make it faster? More secure? Professional-grade?
That curiosity led me to CloudFront, AWS's content delivery network (CDN). And in this post, I'll show you how I transformed that basic site into a globally distributed, supercharged web experience - and learned a ton in the process.

🧠 What Is CloudFront Anyway?

CloudFront is like a worldwide relay race for your content. Instead of loading your site from one location (like S3 in a specific region), CloudFront caches it across edge locations around the world.
So when someone visits your site, they're served content from the nearest AWS data center - not halfway across the globe. The result? Faster load times and a more responsive experience.

💡 Why I Switched from Just S3 to CloudFront

When I first hosted my site on S3, I was thrilled to get it live. But I noticed:

It was a bit slow to load when I shared it with friends abroad.
There was no HTTPS support out-of-the-box for the S3 static site URL.
I wanted my site to feel more real - like a proper website with a custom domain and secure connection.

CloudFront fixed all of that.

🛠️ How I Did It - Step-by-Step

1.Uploaded My Site to S3
If you missed my first post - I had a simple static website with:

index.html: a clean landing page.
output.png: just a single image for now. I uploaded both files to an S3 bucket and made them publicly readable.

2. Created a CloudFront Distribution
Now for the fun part.
I went to the CloudFront console, clicked "Create Distribution," and selected Web as the delivery method.

Here's how I set it up:

Origin Domain: I selected my S3 bucket (make sure it's the static website hosting endpoint, not just the bucket URL).

Viewer Protocol Policy: I set it to Redirect HTTP to HTTPS to ensure secure access.
Default Root Object: I entered index.html - this tells CloudFront what to load by default.

(Optional) Set Up a Custom Domain and SSL
If you want your site to feel real, you can buy a domain and configure it with Route 53, AWS's DNS service.
Using AWS Certificate Manager (ACM) you can request an SSL certificate for your domain and then attache it to any CloudFront distribution so that your would load over HTTPS with a shiny padlock 🔒.I didnt have a domain so I skipped this step.
Waited for Propagation (and Grabbed Coffee)
CloudFront takes a few minutes to deploy a distribution - in my case, about 10 minutes. I used the time to check my GitHub stars and pretend I wasn't hitting refresh every 30 seconds.

🌐 The Moment of Truth

Once deployed, I visited my CloudFront URL (or my custom domain), and there it was - my static site, loading faster than ever, over HTTPS, looking legit.

It felt like leveling up. No longer just a student experiment or weekend project - it looked like something real companies use.

🧼 Bonus: Invalidation & Updates

One thing I learned the hard way: CloudFront caches everything. So when I updated my HTML or image file, the changes didn't appear instantly.
To fix that, I used Invalidations:

I went to the distribution, clicked Invalidations, and added /* to clear the cache.
Next time I made updates, I used versioning (e.g., img-v2.png) to avoid repeated invalidations.

💸 Important Note

The first 1,000 invalidation paths per month are free. After that, AWS charges per invalidation request - so don't overuse /* unless necessary.
A smarter approach is to version your files (e.g., app-v2.js, style-v3.css) so you don't need to invalidate older files.

🤓 What I Learned

HTTPS is essential for modern web apps (and CloudFront makes it easy).
AWS has a learning curve, but once you get through the weeds, it's super powerful.

🎯 Final Thoughts

**
What started as a tiny index.html and an image has evolved into a full-blown global delivery setup with HTTPS and blazing performance. And honestly? It felt empowering.

Whether you're building a personal site, a portfolio, or just experimenting - I highly recommend giving CloudFront a shot. You'll learn, improve your site's UX, and start thinking like a real-world web architect.

And if I could figure it out with a two-file website… so can you.

🚀 How I Launched My First EC2 Instance on AWS (A Beginner's Guide)

Kaustav Dey — Sun, 04 May 2025 10:03:19 +0000

Cloud computing can feel intimidating at first - all the talk of regions, instances, VPCs, and security groups might seem like another language. But launching an EC2 instance on AWS? Surprisingly simple.
In this post, I'll walk you through how I created a basic EC2 instance, what I learned along the way, and how you can do it too - even if you're using Windows with PuTTY to connect.

🧠 What is an EC2 Instance?

Amazon EC2 (Elastic Compute Cloud) is a virtual server in Amazon's cloud. You can use it to host websites, run code, experiment with server setups, or even train ML models.
Think of it like renting a computer in the cloud - you control everything about it.

🛠️ Step-by-Step: How I Did It

**
1. Logged into AWS Console
First, I signed in to the AWS Management Console. If you don't have an account, sign up at aws.amazon.com.
2. Navigated to EC2 Dashboard
From the AWS Services menu, I selected EC2. This took me to the EC2 Dashboard, where I could manage instances, volumes, security groups, and more.
3. Clicked "Launch Instance"
On the dashboard, there's a big blue button: Launch Instance. That's where it begins.
4. Configured the Instance

Here's what I chose:

Name: my-first-ec2
Amazon Machine Image (AMI): Amazon Linux 2 (free-tier eligible)

Instance Type: t2.micro (1 vCPU, 1GB RAM – perfect for starters)
Key Pair: I created a new key pair and downloaded the .pem file for SSH access.
Network Settings: I allowed SSH (port 22) so I could log in remotely.

5. Launched It
Clicked "Launch Instance" and waited ~30 seconds. Boom - my first cloud server was live!

🔒 Setting Up Security Groups (Allowing Inbound Traffic)

One of the most important steps was configuring inbound traffic via a security group. A security group acts like a virtual firewall, controlling traffic to and from your instance.

For inbound rules, I allowed SSH (port 22) from my IP address only so I could connect to the instance securely via PuTTY. I also enabled HTTP (port 80) and HTTPS (port 443) from anywhere (0.0.0.0/0) to allow future web traffic to reach the server, in case I want to host a website or run a web app. This setup ensures I can access the server securely while also keeping the door open for standard web traffic.

💡 Why These?
SSH lets me connect to the instance remotely.
HTTP & HTTPS are needed if I plan to host any kind of web content or server.

⚠️ Tip: Restrict SSH access to your IP for security._ Never leave port 22 open to the world unless absolutely necessary.

_

🚪 Launched the Instance
Once the security group was configured, I clicked Launch Instance and within 30 seconds, I had my cloud server running.

🔐 Connecting to the EC2 Instance on Windows using PuTTY

Since I was using a Windows system, I connected to my instance using PuTTY, a free SSH client.

Here's what I did:

Converted the .pem file to .ppk:
Downloaded and opened PuTTYgen.
Clicked Load, selected the .pem file.
Clicked Save private key and saved the file as my-key.ppk.

Opened PuTTY and entered connection details:

Host Name (or IP address): ec2-user@
In the left menu, under Connection > SSH > Auth, I browsed to the my-key.ppk file.

Connected:

Clicked Open and accepted the SSH security prompt.
I was now logged into my EC2 instance via the command line!

🧼 Cleaning Up (IMPORTANT!)
After testing, I stopped and terminated the instance to avoid unexpected charges. Always shut down resources you're not using.

💡 What I Learned

Cloud isn't as scary as it seems.
AWS gives you a lot of control - which means you must manage it responsibly.
On Windows, PuTTY and PuTTYgen are your best friends for connecting via SSH.
Always save your private key file - and never share it.

5.

🧭 What's Next?

Hosting a static website using EC2.(Wair, alreday did that , check it out :https://medium.com/@deykaustav357/how-i-made-my-first-static-website-using-amazon-s3-as-an-aws-beginner-476a9232f360 )
Attaching an EBS volume for persistent storage.
Learning about AMIs and how to create custom images.

🎯 Final Thoughts
Launching an EC2 instance is like a rite of passage in the cloud world. It's the gateway to a huge universe of cloud computing possibilities.
If you've been hesitant, just try it - AWS's free tier gives you 750 hours/month of t2.micro usage. Play, break things, and learn.

If I can do it, so can you.

I Made My First AWS Lambda Function (And It Did… Absolutely Nothing)

Kaustav Dey — Sun, 04 May 2025 10:02:57 +0000

If you're anything like me, you've probably seen those buzzwords floating around: "serverless," "Lambda functions," "event-driven computing." It sounds futuristic - like programming without writing code, or spinning up logic that just exists in the cloud.
So naturally, I wanted in.
A few days ago, I set out to make my first AWS Lambda function. I wasn't trying to build anything crazy. I just wanted to see if I could wire something together and watch it work. Spoiler: I did. My Lambda didn't do much, but I saw it work - and that made all the difference.
Here's how it went.

The Plan: Trigger a Lambda From an S3 Upload
I came up with the most basic idea possible:

Upload a file to S3 → have that action trigger a Lambda function

I wasn't worried about the function doing anything useful. I just wanted to see the gears turn: trigger → function → log.
You could say it was a science experiment. The goal wasn't utility. It was proof.🤯

Step 1: Creating the Lambda Function (AKA Blank Canvas Mode)
I opened the AWS Lambda console and clicked "Create Function." I chose the "Author from scratch" option because I like pain, apparently.
Name: demoLambda
Runtime: Python 3.12 (I don't even know Python that well, but it looked friendly)
Permissions: I let AWS create a new role with basic Lambda permissions. Default everything

Inside the function editor, AWS gave me a basic "Hello from Lambda" handler. I could've edited it, but I decided: Nope, let's leave it untouched. I wasn't here to code. I was here to observe.

Step 2: Setting Up the S3 Bucket (My Cloud Storage Playground)
Next, I created a new S3 bucket:
Name: demobucket357 (because AWS hates duplicate names)
Region: Same as the Lambda function, which matters more than I expected

I left all other settings default. Again, this wasn't about security best practices or storage classes. I just wanted something I could drop files into.

Step 3: Connecting the Trigger (Where Things Got Real)
Back in my Lambda function settings, I added a trigger:
Trigger type: S3
Bucket: My newly created bucket
Event type: PUT (aka when an object is uploaded)

I also checked the box that acknowledged AWS might need to grant permissions for this to work. Clicked save. No errors. So far, so good.

Step 4: Uploading a File (And Waiting for Magic)
With everything wired up, I uploaded a random .txt file into my S3 bucket. No fancy automation. Just a manual upload from my desktop.
Then I opened CloudWatch Logs like I was checking a mailbox for a letter from a pen pal.
Boom. There it was.
A new log stream had appeared. Inside it? A sweet, sweet log that said something like:

START RequestId: ...
Hello from Lambda
END RequestId: ...
REPORT RequestId: ...

I didn't write any custom code. I didn't even print anything. But that log was enough to tell me: it worked.
I had created a real-life serverless event. I had connected cloud services and watched one respond to the other. It was kind of beautiful.

What I Learned (Besides Patience)

1. - Triggers are powerful. Even without doing anything inside Lambda, you can still observe and verify behavior through logs.
2. - Permissions matter. AWS handles a lot, but I started reading more about IAM roles and policies afterward - just so I don't blindly click checkboxes forever.
3. - CloudWatch is your friend. Seeing logs appear felt like watching a heartbeat monitor for your cloud app.
4. - You don't need to do much to learn a lot. The actual function was a placeholder. The real learning came from connecting the dots.

Final Thoughts
This wasn't a groundbreaking project. I didn't save data, transform files, or build an API. But I started. I connected services. I watched logs come in. I got curious about what I could do next.
That's the thing about learning cloud: you don't always have to aim for big, shiny results. Sometimes it's about getting your hands dirty and proving that, yes, you can make the cloud respond to you.
And honestly? That's more addictive than it should be.

Thanks for reading. If you're tinkering with Lambda or S3, I'd love to hear what you're building - or breaking. Either way, you're learning.

How I Built My First VPC with 6 Subnets (And Only Mildly Panicked)

Kaustav Dey — Sun, 04 May 2025 08:01:33 +0000

Real talk: When I first started poking around in AWS, I wasn’t trying to build anything fancy. I just wanted to run a small app and maybe learn a thing or two along the way. But as I clicked through the endless maze of services, acronyms, and dropdown menus, one word kept showing up: VPC.

At first, I ignored it. It sounded complicated. Scary, even. Then I ran into issues — couldn’t access my instance, secure my database, or figure out where my traffic was going. That’s when I realized: I needed to understand how the networking stuff works.

So I decided to build my own Virtual Private Cloud — fully from scratch, with six subnets (yep, six), even though I had no clue what I was doing at the start. If you’re new to AWS and feeling overwhelmed, trust me: I’ve been there. Here’s exactly how I figured it out — and what I wish someone had told me before I started.

Why Even Build a Custom VPC?
Like a lot of folks, I started with AWS’s default VPC. It was fine — until it wasn’t. I thought of a setup with more structure:

Public subnets for web-facing services
Private subnets for databases and internal logic
Multiple Availability Zones for high availability
So I said screw it — time to build a custom VPC with 6 subnets: 3 public, 3 private, spread across 3 Availability Zones (AZs).

Step 1: VPC Basics (Without Falling Asleep)

I created a new VPC with the CIDR block 10.0.0.0/16—plenty of room for subnets. The plan:

Subnet Type CIDR Block AZ Public A 10.0.1.0/24 us-east-1a Public B 10.0.2.0/24 us-east-1b Public C 10.0.3.0/24 us-east-1c Private A 10.0.101.0/24 us-east-1a Private B 10.0.102.0/24 us-east-1b Private C 10.0.103.0/24 us-east-1c

I wanted each pair of public/private subnets to live in its own AZ, so if one zone went down, things would still hum along elsewhere.

Step 2: Routing Headaches
Once I had the subnets created, the real fun began: route tables.

Public Route Table (1): Shared across all public subnets. It included a route to the Internet Gateway (IGW).
Private Route Table (1): Shared across all private subnets.

Lessons From the Trenches
This build took me longer than I’d care to admit. But here’s what I took away:

🧠 Networking is not black magic.
It feels that way at first, but once you understand how IGWs, NATs, and route tables work together, it clicks.(though I didnt use any)

📉 Simplicity is your friend.
Start with 1 public and 1 private subnet before scaling to 6. Trust me.

📄 Draw it out.
Seriously. Use a napkin, whiteboard, or Lucidchart. Visualizing the subnets and routes made everything way easier.

Final Thoughts
Was this overkill for a side project? Maybe. But building my own 6-subnet VPC taught me more about cloud networking than any course ever did. And now, spinning up secure, redundant infrastructure doesn’t feel intimidating — it feels empowering.

If you’re on the fence about ditching the default VPC: do it. Break things. Rebuild them. Learn. It’s worth it.

Got a VPC horror story or proud moment? I’d love to hear it. Let’s trade tales in the comments. 👇

How I Made My First Static Website Using Amazon S3 (As an AWS Beginner)

Kaustav Dey — Wed, 23 Apr 2025 12:29:28 +0000

Not too long ago, I decided to start learning AWS. It seemed like one of those things everyone in tech was talking about — but also kind of intimidating. There’s a ton of services, acronyms flying around, and a whole dashboard that feels like a cockpit. So I thought: Why not start small? Let’s just get a simple website live using one AWS service.

That’s how I ended up making my very first static website using Amazon S3. If you’re also just getting into AWS, this post is for you.

🧠 Why Amazon S3?
Amazon S3 (Simple Storage Service) is basically cloud storage — you can upload files and access them from anywhere. But what I didn’t know at first is that you can actually host a static website with it. That means if your site is just HTML, CSS, and maybe some JavaScript — no backend stuff — you can host it on S3 without spinning up a server.

It sounded perfect for a beginner like me. No DevOps. No EC2. No headaches.

💻 Step 1: Building a Simple Website
I kept it super minimal. No frameworks, just plain HTML and CSS. Here’s what I used:

index.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>My First AWS Site</title>
</head>
<body>
  <h1>Hello, AWS!</h1>
  <p>This is my first static site hosted on S3.</p>
  <img src="output.jpg">
</body>
</html>

output.jpg

That’s it. Two files. Just enough to test the process.

☁️ Step 2: Creating the S3 Bucket
Here’s where the AWS part begins:

Logged into the AWS Management Console.
Searched for S3 and clicked Create bucket.
Gave it a unique name (S3 bucket names are globally unique).
Unchecked “Block all public access” (important! Otherwise, no one can view your site).
Then I added a policy to only ensure my s3 object could read the stuff stored in it.
Created the bucket.
The policy I used is below. Just place the unique name of your bucket in ‘Bucket-Name’

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

At this point, I had cloud storage ready to go.

🌐 Step 3: Enabling Static Website Hosting
Inside the S3 bucket:

I clicked on the Properties tab.
Scrolled down to Static website hosting.
Enabled it and set index.html as the index document.
AWS gave me a URL. This would be the live address of my site.
But first, I had to upload the files and make sure they were public.

📤 Step 4: Uploading and Making Files Public
Went to the Objects tab.
Uploaded both index.html and style.css.
After uploading, I selected each file, clicked Actions > Make public.
(Note: You can set a bucket policy to make everything public automatically, butif you want you can stick with manual for now — it felt safer while learning.)

🔗 Step 5: Visiting My Site
With everything uploaded and public, I went back to the static hosting section in Properties and copied the Endpoint URL.

I pasted it into my browser, and boom — it worked. My little website was online. No servers, no deployment tools. Just files in a bucket.

🔍 What I Learned
AWS can feel like a lot, but starting with one service (like S3) makes it manageable.
Hosting a static site doesn’t need to be complicated.
Public access settings are a key part of getting S3 hosting to work.
The feeling of getting a website live — even a basic one — is honestly really satisfying.
✅ Final Thoughts
This was my first actual hands-on experience with AWS, and it went smoother than I expected. Sure, I had to Google a few things (especially around permissions), but I came away feeling a little more confident in navigating the AWS ecosystem.

If you’re new to AWS and wondering where to begin — host a static website on S3. It’s simple, useful, and gives you a nice win early on.

Next up for me? Maybe setting up a custom domain, adding HTTPS with CloudFront, or playing with Lambda. But for now, I’m just happy that I took the first step.

Diving into the World of AWS: My Excitement and Journey Ahead

Kaustav Dey — Wed, 23 Apr 2025 11:32:17 +0000

Given the rate and speed with which technology is evolving it is important to keep it in perspective. The area which has particularly interested me is the one of cloud computing, more specifically, the one known as Amazon Web Services. There’s so much about this vast world of AWS that I am thrilled to explore. This is how I feel and this is what I hope to accomplish.

#### The AWS Ecosystem

AWS is a dominant force with a wide range of services that address almost every facet of cloud computing. The range and capabilities of the offerings, which range from databases and storage to machine learning and analytics, are remarkable. I can see how becoming proficient with AWS could greatly improve my abilities and lead to exciting career opportunities in the tech sector.

The practical use of AWS services is what most excites me. For instance, knowing how to use Amazon S3 for effective storage solutions or AWS Lambda to deploy scalable apps could revolutionise my approach to projects. Working with strong tools like AWS CloudFormation and AWS EC2 is exciting because these services offer flexibility and automation that can improve any tech project.
**

Learning and Growth**

Starting this AWS adventure also entails starting a journey of ongoing education. The abundance of resources, ranging from AWS’s documentation to online tutorials and courses, offers an excellent place to start. I’ve already enrolled in a couple of introductory classes, and I’m eager to get my hands dirty in labs that mimic actual cloud problems.

I’m especially excited to get my hands dirty with AWS certification courses. Obtaining these credentials would increase my confidence in addition to validating my knowledge. Since it appears to cover a wide range of fundamental knowledge that I can build upon, the AWS Certified Solutions Architect — Associate is the first test I have my sights set on.

#### The Community

The lively community that surrounds AWS is one of the things that excites me about learning more about it. Professionals and other students can provide invaluable support. I’m excited to participate in forums, go to meetups, and have conversations on sites like Stack Overflow and Reddit. There is so much to learn and share, and as I become more knowledgeable, I can’t wait to add my perspectives.

#### Practical Application

I intend to work on personal projects that will enable me to put what I’ve learnt about AWS into practice as I gain more knowledge about it. I’m excited to see how these services can make ideas a reality, whether it’s using Amazon RDS to manage a database for a project or EC2 to host a personal website. One of the primary reasons I’m so committed to this journey is the opportunity to innovate and create with AWS.

#### Conclusion

In conclusion, I am excited to explore the world of AWS because of the numerous opportunities it offers for education, development, and real-world application. Since the tech sector is always changing, I think becoming proficient in AWS will improve my skill set and put me in a position to take advantage of new opportunities. I’m prepared to welcome the difficulties and rejoice in the upcoming achievements as I set out on this adventure. Cheers to the beginning of an exciting journey!