Forem: sanjay yadav

Most AWS Security Setups Ignore This One Outbound Risk

sanjay yadav — Mon, 04 May 2026 05:43:41 +0000

Most AWS security setups focus heavily on inbound traffic.

But outbound is often left open.

Security Groups. NACLs. Maybe WAF.
That’s usually where the effort goes.

But outbound traffic often gets far less attention — and that’s where problems begin.

Every outbound request starts with a DNS query.

Before your application connects anywhere, it first resolves a domain name. That step is easy to ignore, but it’s where a lot of risk begins.

If something inside your VPC reaches a malicious domain, the communication already starts at the DNS level.

This is where DNS-level control starts to matter.

Route 53 DNS Firewall gives you control before traffic even reaches an IP.

You can:

Allow trusted domains
Block known malicious domains
Monitor suspicious queries

What’s often overlooked is where this control actually sits.

It operates within the VPC resolver path, separate from Security Groups and NACLs.
So it doesn’t replace them — it fills a gap they don’t cover.

It’s a small addition, but it changes how you think about egress security.

Instead of reacting later, you control traffic at the first step.

This article explains the setup and real use cases clearly:
https://www.kubeblogs.com/route-53-dns-firewall-aws-egress-security/

How are you handling egress security today — only with Security Groups, or adding DNS-level controls as well?

Run Multiple AI Agents Locally Without Docker (Using Git Worktrees)

sanjay yadav — Fri, 01 May 2026 05:54:21 +0000

Running multiple AI agents locally sounds simple — until you actually try to manage them.

Each agent needs its own context, its own branch, and often its own environment. The obvious approach is to duplicate repositories or constantly switch branches, but that quickly becomes difficult to manage.

I ran into this while experimenting with parallel workflows, and the setup started breaking down faster than expected.

The approach that worked well for me was using Git worktrees.

Instead of cloning the same repository multiple times, worktrees allow you to create separate working directories from a single repository. Each one can operate independently with its own branch, which makes it much easier to run parallel processes.

In practice, this helps with:

Running multiple agents at the same time without conflicts
Keeping environments isolated without duplicating repos
Switching between contexts without disrupting ongoing work

It’s a simple idea, but it makes a noticeable difference when working with parallel AI workflows locally.

I’ve put together a step-by-step setup with commands and a working example here:
https://www.kubeblogs.com/run-parallel-ai-agents-git-worktrees-local-setup/

How are you currently managing multiple AI workflows locally?

Why GCP Prometheus Doesn’t Work with Grafana (And How to Fix It)

sanjay yadav — Thu, 30 Apr 2026 04:46:10 +0000

I thought connecting Grafana to GCP Managed Prometheus would take 10 minutes.

It didn’t.

With a normal Prometheus setup, you just point Grafana to an endpoint and start querying metrics. But GCP Managed Prometheus works differently, and that’s where things get confusing.

Grafana was connected, but no metrics were showing — which made debugging frustrating.

Instead of a direct connection, you’re dealing with Google Cloud APIs, IAM permissions, and authentication layers. Small misconfigurations can break everything.

After digging into it, I realized most issues come down to authentication and endpoint configuration.

To simplify things, I set up Grafana using Docker Compose and worked through it step by step.

This approach helped me:

Run Grafana in a controlled environment
Fix authentication issues step by step
Confirm whether metrics were actually being returned

Once everything was aligned, the setup worked as expected.

If you’re working with GKE, Kubernetes monitoring, or managed observability on GCP, this is something you’ll likely run into.

I documented the full setup with a working example and exact configuration here:
https://www.kubeblogs.com/how-to-connect-google-cloud-managed-prometheus-to-grafana-using-docker-compose-2025-setup-guide/

What part took you the most time — authentication, configuration, or getting metrics to show up?

AWS Storage Performance Costs More Than You Think (A Real Comparison with Civo)

sanjay yadav — Wed, 29 Apr 2026 09:34:29 +0000

I didn’t expect storage performance to be the most expensive part of my AWS bill.

But it was.

When people talk about cloud costs, they usually focus on compute.
But in many real-world workloads, storage performance is where costs quietly increase.

And the surprising part?
You don’t just pay for storage in AWS — you pay for how fast it is.

What’s happening in AWS
You choose an EBS volume type (gp3, io1, io2, etc.)
Then you pay separately for IOPS and throughput

This means:
The faster your storage needs to be, the more you pay.

In some cases, storage performance can cost more than the compute itself.

How Civo approaches it
NVMe-based storage included by default
No separate performance charges
Consistent disk speed
A simple way to think about it

AWS: Storage is cheap, performance is not
Civo: Performance comes built-in

Why this matters

If you're running Kubernetes, databases, or anything disk-heavy,
this is where your cloud bill silently grows.

Full breakdown

I broke this down with a real comparison here:

https://www.kubeblogs.com/aws-charges-extra-for-storage-performance-that-civo-ships-by-default/

Have you ever been surprised by AWS billing, especially due to storage or IOPS?

Why Your GKE Load Balancer Fails After 30 Seconds (Real Fix)

sanjay yadav — Tue, 28 Apr 2026 10:12:08 +0000

Still getting 504 errors in GKE even when everything looks fine?

We faced the same issue. Pods were healthy, APIs were responding, and there were no errors in logs.

The real problem wasn’t the application. It was a 30-second timeout.

We spent hours debugging this.

Everything looked normal:

Pods were running fine
APIs were responding
No crashes or error logs

But still, requests kept failing.

We were seeing random 503 and 504 errors.

The Confusing Part

Short requests worked perfectly
Logs showed no issues
System appeared healthy

But anything taking more than around 30 seconds failed every time.

What We Thought Initially

At first, we assumed:

Application bug
Database latency
Resource limits

We checked everything. Nothing was wrong.

The Real Cause

After digging deeper, we found the actual issue:

GKE Load Balancer has a default timeout of 30 seconds.

This means:

Your backend may still be processing
But the load balancer stops waiting

Result: 504 Gateway Timeout.

The Fix: BackendConfig

We fixed it using BackendConfig.

It allows you to:

Increase timeout
Customize health checks
Control load balancer behavior

What We Changed

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backend-config
spec:
  timeoutSec: 60

This change increased the timeout from 30 seconds to 60 seconds.

After applying it, the issue was resolved.

Attach It to Your Service

annotations:
  cloud.google.com/backend-config: '{"ports": {"8003":"my-backend-config"}}'

Apply the configuration and redeploy your service.

Important Note

If you don’t configure BackendConfig:

Default timeout remains 30 seconds
Long-running requests will fail
You have limited control over behavior

Bonus Tip

If your application regularly takes longer to respond:

Avoid increasing timeout too much
Consider using asynchronous processing (queues or background jobs)

Final Thought

This was not a complex bug.

It was a default setting that we were not aware of.

Sometimes the real issue is not in your code, but in infrastructure defaults.

Full step-by-step guide

If you work with GKE, this can save you a lot of time.

Stop Using T2 Instances — They Cost More Than You Think (T2 vs T3)

sanjay yadav — Tue, 28 Apr 2026 09:43:27 +0000

Stop Using T2 Instances — They’re Quietly Increasing Your AWS Bill

I used to think T2 instances were the cheapest option on AWS.

They look affordable, they’re everywhere in tutorials, and honestly — most of us just start with them.

But after checking a few AWS bills closely, I realized something wasn’t adding up.

🤔 What’s Actually Going On with T2?

T2 instances run on a CPU credit system.

In simple terms:

When your app is idle → you earn credits
When CPU usage increases → you spend credits

At first, this seems like a smart system.

But here’s the part most people miss 👇

Where the Extra Cost Comes From

If your instance runs out of CPU credits, AWS doesn’t just slow things down.

If unlimited mode is enabled (which it often is by default), you start getting charged for extra CPU usage.

No clear warning. No obvious alert.

Just a slightly higher bill at the end of the month.

That’s exactly what happened to me.

Why I Switched to T3

T3 instances are basically the improved version of T2.

After switching, I noticed:

More consistent performance
Fewer surprises in billing
Better overall value

They use newer hardware and handle CPU usage more efficiently.

T2 vs T3 (Simple View)

Feature	T2	T3
CPU Handling	Credit-based	Smarter credits
Performance	Can drop	More stable
Pricing	Can spike	More predictable
Generation	Older	Newer

When You Should Avoid T2

From experience, avoid T2 if:

Your app has traffic spikes
You're running anything close to production
You don’t want unpredictable costs

Quick Tip

If you're currently using T2, check this:

Go to your billing dashboard → look for CPU credit charges

You might already be paying more than expected.

Final Thought

T2 isn’t “bad” — it’s just outdated for most real use cases.

T3 is usually the safer and smarter choice now.

🔗 Full article: [https://www.kubeblogs.com/why-t3-is-better-than-t2-for-most-aws-ec2-workloads/]
If you're into simple, practical DevOps tips, follow along 👍