Here's the story of how a one-time VPC networking tweak cut a real workload's daily AWS bill by up to 40%, with zero code changes and zero downtime.

The Problem Nobody Notices Until the Bill Arrives

By default, when an EC2 instance or EKS node sitting in a private subnet talks to S3, the traffic doesn't magically float into AWS's internal network. It takes the only path it knows:

Private Subnet → NAT Gateway → Internet Gateway → Amazon S3

That NAT Gateway hop looks harmless. It isn't. AWS charges NAT Gateway data processing fees per GB, in both directions, for every byte that passes through it — including all your S3 uploads, downloads, log shipping, backups, and model/artifact pulls. It's traffic that never needed to leave the AWS network in the first place, and you're paying internet-gateway-style tolls for an internal AWS-to-AWS conversation.

The worst part? It's invisible until someone actually breaks down the Cost Explorer by usage type. It just looks like "NAT Gateway costs are high" with no obvious smoking gun — because the smoking gun is S3 traffic disguised as generic data processing.

The Fix: An S3 Gateway VPC Endpoint

Enter the Amazon S3 Gateway VPC Endpoint — a free, fully AWS-managed endpoint type that lets resources in your VPC reach S3 directly over AWS's private backbone, completely bypassing the NAT Gateway and the public internet.

Private Subnet → S3 Gateway VPC Endpoint → Amazon S3

No NAT hop. No internet routing. No per-GB NAT data processing charge for that traffic. Just a route table entry pointing at an AWS-managed prefix list for S3.

And here's the kicker: Gateway endpoints for S3 and DynamoDB are free. You pay nothing to create or use them — you're only removing a cost, not adding one.

The Real Numbers

This isn't theoretical. Here's what one production workload (EKS nodes + EC2 instances hitting S3 heavily) looked like before and after:

That's roughly $6,500 – $8,600 a year, recovered from a single networking change, on one workload. Scale that across every private-subnet workload in your account talking to S3, and the number gets uncomfortable fast if you haven't done this yet.

How to Set It Up (Takes About 10 Minutes)

Step 1: Create the VPC Endpoint

In the VPC console, go to Endpoints → Create endpoint.

Step 2: Configure it for S3

• Give it a name (e.g. vpc_gateway_endpoint)

• Under Service category, choose AWS services

• Search for and select: com.amazonaws.<your-region>.s3

• Type: Gateway (not Interface — this distinction matters, Gateway is the free, route-table-based option)

Step 3: Network configuration

• Select your VPC

• Select the route tables associated with the private subnets that need S3 access (public route tables too, if relevant)

Step 4: Verify the route

Once the endpoint is created, check the route tables you selected. You should see a new route:

• Destination: the AWS-managed prefix list for S3 (see AWS's prefix list docs)

• Target: your new VPC endpoint

That's it. No application changes, no redeploys, no DNS changes required — S3 requests from resources in those subnets now silently route over the AWS backbone instead of through NAT.

Why This Matters Beyond the Dollar Amount

• Security: traffic never touches the public internet path, reducing your exposure surface.

• Reliability: one less hop, one less dependency on NAT Gateway throughput/bandwidth limits.

• Scalability: as your S3 traffic grows (logs, backups, model artifacts, data lake reads), your NAT bill stops growing with it — because that traffic isn't hitting NAT anymore.

The Takeaway

If you've got EKS nodes, EC2 instances, Lambda-in-VPC, or literally anything in a private subnet reading/writing S3 — and you haven't set up a Gateway VPC Endpoint — you are almost certainly paying NAT Gateway tolls on traffic that could be free and faster.

Go check your route tables. It's a 10-minute fix that could quietly hand you back hundreds of dollars a month.

Have you found other "hidden" AWS cost traps like this one? Drop them in the comments — I'd love to compare notes.

🚀 How I Deployed a MERN App on GKE with ArgoCD & Kubernetes Dashboard (Beginner Friendly Guide)

If you’ve ever tried deploying a MERN app (MongoDB + Express + React + Node) to the cloud, you know the pain. 😵‍💫
But I wanted production-level scalability + GitOps magic, so I challenged myself:

👉 Deploy my project BidStream (a MERN-based bidding app) on Google Kubernetes Engine (GKE) with:

• Terraform (infra as code)

• Docker + Kubernetes manifests

• NGINX Ingress + SSL via Let’s Encrypt

• GitOps with ArgoCD

• A shiny Kubernetes Dashboard exposed securely

…and yes, it worked 🎉

Here’s the exact step-by-step journey (newbie-friendly). Let’s go 👇

🏗️ Step 1: Setting up GKE Cluster

• I spun up a GCP Standard GKE Cluster via Terraform.

• Think of it as: one command → entire Kubernetes infra ready (nodes, networking, RBAC).

• If you don’t know Terraform, you can just use gcloud container clusters create.

💡 Screenshot of my cluster (flexing moment 😎):

🐳 Step 2: Dockerizing Backend + Frontend

Both my backend (Express API) and frontend (React/Vite app) had their own Dockerfile.

Example backend build:

cd backend
cp .env.docker .env
docker build -t gcr.io/YOUR_PROJECT_ID/backend:latest .
docker push gcr.io/YOUR_PROJECT_ID/backend:latest

Same for frontend.
✅ Images pushed to Google Container Registry (GCR).

🌐 Step 3: NGINX Ingress + Domain Setup

Installed Ingress Controller with Helm:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm upgrade --install ingress-nginx ingress-nginx \
  --namespace ingress-nginx --create-namespace \
  --set controller.service.type=LoadBalancer

Then pointed my domain piyush-web-app.co.in → LoadBalancer IP with DNS A record.
Boom 💥 My app had a domain!

🔒 Step 4: TLS SSL with Let’s Encrypt

I added a ClusterIssuer for SSL:

kubectl apply -f k8s/cluster-issuer.yaml

Then updated ingress.yaml to include:

annotations:
  cert-manager.io/cluster-issuer: letsencrypt-prod

Result → Auto HTTPS with Let’s Encrypt 🔐

🚀 Step 5: Deploying MERN App on Kubernetes

Applied backend + frontend deployments:

kubectl apply -f k8s/backend-deployment.yaml
kubectl apply -f k8s/frontend-deployment.yaml
kubectl apply -f k8s/ingress.yaml

🎉 The app was LIVE at https://piyush-web-app.co.in.

🤖 Step 6: GitOps with ArgoCD (My Fav Part ❤️)

Instead of kubectl apply every time → I wanted automated sync from GitHub.

Install ArgoCD

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Expose service as LoadBalancer:

kubectl patch svc argocd-server -n argocd \
  -p '{"spec": {"type": "LoadBalancer"}}'

Login to ArgoCD

Get initial password:

kubectl get secret argocd-initial-admin-secret -n argocd \
  -o jsonpath="{.data.password}" | base64 -d

Access via:
https://<ARGOCD-LB-IP> → login with admin + password.

Create Application (BidStream)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: bidstream
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/YOUR_USERNAME/YOUR_REPO.git'
    targetRevision: main
    path: k8s
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Apply it → ArgoCD pulls manifests from k8s/ dir in GitHub → auto deploys.
🔥 GitOps in action!

📊 Step 7: Kubernetes Dashboard

Deployed dashboard + exposed it with LoadBalancer:

kubectl patch svc kubernetes-dashboard -n kubernetes-dashboard \
  -p '{"spec": {"type": "LoadBalancer"}}'

Created admin-user + token → logged in 🎉

UI screenshot:

🎯 Final Result

• Frontend → https://piyush-web-app.co.in

• Backend → /api behind ingress

• K8s Dashboard → LB endpoint with token login

• ArgoCD → Auto-syncing my repo with cluster

💡 Key Learnings

• ArgoCD is a game-changer → no more manual kubectl apply.

• Ingress + Let’s Encrypt = painless SSL setup.

• Terraform + GKE = infra you can recreate anywhere.

🔥 Why Share This?

Because when I started, Kubernetes + GitOps felt overwhelming.
But trust me → if I can do it with a MERN app, so can you. 🙌

If you found this useful, drop a ❤️ and share it with your DevOps buddies.
Let’s make GitOps + Kubernetes less scary for newbies 🚀

👉 Full repo with manifests: GitHub - BidStream ( Head here for more refined Instruction for deployment )