Forem: sanjay yadav

Stop Overpaying for GP2: GP3 Cost & Performance Explained

sanjay yadav — Sat, 09 May 2026 04:20:02 +0000

Most people still use GP2 as the default EBS volume type in launch templates and infrastructure modules.

Not because it is still the best option today — but because it has existed in infrastructure templates for years.

In most production audits I review, oversized GP2 volumes are still one of the easiest cost optimizations left untouched.

The real issue is that GP2 ties storage capacity directly to performance. Under sustained workloads, that coupling starts becoming operationally expensive very quickly.

GP3 changes this model entirely.

Instead of scaling performance through storage size, GP3 separates performance from capacity and gives much more predictable behavior under real workloads.

To understand why this matters operationally, it helps to look at how both architectures actually behave.

How GP2 Was Designed

GP2 follows a size-based performance model:

IOPS = 3 × Volume Size (GB)

Key characteristics:

Minimum 100 IOPS
Burst up to 3,000 IOPS
Maximum 16,000 IOPS
Credit-based burst model
Throughput indirectly tied to volume size

The original design made sense at the time.

As storage scaled, performance scaled with it.

But modern workloads are more sustained and much less tolerant of performance variability.

The Credit-Based Burst Problem

GP2 relies on a token bucket credit system.

When workloads exceed baseline performance:

Burst credits are consumed
IOPS temporarily increases
Credits eventually deplete
Performance drops back to baseline

This is where production instability starts showing up.

Short benchmarks often look fine.

But under sustained write-heavy workloads, latency starts increasing once credits are exhausted.

In CloudWatch, this usually appears as:

Rising VolumeQueueLength
Increasing VolumeWriteLatency
Variability in VolumeIdleTime

The problem is not peak performance.

The problem is maintaining predictable performance under continuous pressure.

GP3 Changes the Architecture Completely

GP3 removes the dependency between storage size and performance.

Every GP3 volume includes:

3,000 IOPS baseline
125 MB/s throughput baseline

And you can provision independently:

Up to 16,000 IOPS
Up to 1,000 MB/s throughput
Up to 64 TiB storage

There is no burst-credit behavior.

Performance becomes deterministic instead of temporary.

Why This Matters Operationally

GP2 scales performance indirectly through storage size.

GP3 scales performance directly based on workload requirements.

That difference becomes extremely important for:

production databases
sustained write-heavy workloads
indexing systems
search clusters
high-transaction services

In many cases, teams are effectively paying for extra storage capacity only to achieve the IOPS they need.

Real Cost Comparison

Requirement

6,000 sustained IOPS
500 GB usable storage

GP2

To achieve 6,000 baseline IOPS:

6000 ÷ 3 = 2000 GB

Approximate monthly cost:

2 TB × ~$0.10/GB ≈ ~$200/month

Most of that storage capacity exists only to unlock performance.

GP3

Provision directly:

500 GB storage
6,000 IOPS

Approximate monthly cost:

Storage: ~$40
Additional IOPS: ~$15
Throughput adjustment: ~$5–10

Estimated total:

~$60–65/month

Once this scales across multiple workloads and environments, the savings become very noticeable.

Migration Is Surprisingly Simple

In most environments, moving from GP2 to GP3 is operationally straightforward:

aws ec2 modify-volume \
  --volume-id vol-xxxxxxxx \
  --volume-type gp3

In many cases:

no downtime required
no IAM changes required
monitoring stays identical

Operationally, the migration is small.

From a performance predictability perspective, the impact is significant.

When GP3 Should Be the Default

GP3 makes more sense for:

Production databases
Search systems
Sustained workloads
Write-heavy applications
Cost optimization initiatives

GP2 mainly survives today because older infrastructure templates still default to it.

Final Thoughts

GP2 ties performance to storage size and depends heavily on burst behavior.

GP3 separates capacity from performance and delivers much more predictable sustained I/O.

For most modern production workloads, GP3 should probably be the default starting point — not the upgrade path.

T3 vs T2 EC2: Save Costs and Avoid CPU Throttling in AWS

sanjay yadav — Fri, 08 May 2026 04:20:50 +0000

**Why This Comparison Still Matters

****In many AWS accounts we still see T2 instances running production workloads. Most of the time, this isn’t by choice. It’s usually inheritance — old templates, old AMIs, or “this is what we launched years ago”.

The issue here is: you are likely paying more money for worse performance.---

**How Burstable EC2 Instances Originally Worked

**
When AWS introduced T2 instances, burstable compute was a solid idea.

You received:
A low baseline CPU
CPU credits earned during idle time
The ability to burst when needed
For small, spiky workloads, this model worked well enough at the time. T2 became the default for running applications on top of ec2 instances.---

**Where T2 Starts to Fall Apart

**
Over time, several issues became obvious.
In real environments:
Baseline CPU performance is low
CPU credits accumulate slowly
Unlimited bursting costs extra
Performance becomes unpredictable under sustained load
In most teams, this shows up as mysterious CPU throttling, even though the instance size “should” be enough.---

**What Changed With T3

**
T3 instances are not just a pricing refresh.
They are built on AWS Nitro, which fundamentally improves how compute is delivered.
The result is:
Higher baseline CPU
Faster CPU credit earning
More consistent performance
Lower cost for equivalent instance sizes
This is why AWS positions T3 as the replacement for T2.---

**How CPU Credits Differ Internally

**
CPU Credit Behavior (High Level)

The key difference is not just bursting — it’s how quickly credits are earned and how predictable performance is once credits are spent.

Practical Cost Reality

For the same workload:
T2 often ends up more expensive
T3 delivers better throughput
Unlimited bursting on T2 adds surprise costs
Once sustained CPU usage enters the picture, T2 stops being economical very quickly.---

Practical Example

If you are running:
APIs
Background workers
Small application servers
Internal tooling
T3 will almost always behave better under real traffic patterns.
In practice, many teams switch to T3 and immediately notice fewer CPU-related alerts without changing instance size.---

**Operational Considerations

**
There is no special configuration required to use T3.
From an operations perspective:
IAM remains unchanged
Monitoring stays the same
Autoscaling behavior improves due to more stable CPU usage

This makes T3 a low-risk upgrade in most environments.

Migration Guidance

Migrating from T2 to T3 is usually straightforward:

Ensure your AMI supports Nitro-based instances
Launch a T3 instance of the same size
Observe CPU credit behavior and latency
Roll out gradually if the workload is critical

The biggest blocker is often legacy AMIs, not application behavior.

When to Use T3 vs When Not To

Use T3 When:
Launching new workloads
Running general-purpose services
Cost efficiency matters
You want predictable burst behavior
Use T2 Only When:
You are stuck with legacy AMIs
Nitro is not supported
Migration is temporarily impossible
Even then, T2 should be treated as a short-term compromise.
**

FAQ

Is T3 cheaper than T2 in AWS EC2? In most real-world scenarios, T3 instances are more cost-efficient than T2. They offer improved baseline performance and flexible CPU credit usage, which helps reduce unexpected costs.
What are CPU credits in T2 and T3 instances? CPU credits allow burstable instances to handle temporary spikes in usage. T2 instances have stricter credit limits, while T3 provides more flexible credit options, making it better for variable workloads.
When should I choose T3 over T2? You should choose T3 when your workload requires consistent performance or occasional bursts. T3 is generally better for modern applications due to its cost-performance balance.

**Read More on KubeBlogs

**
If you're exploring DevOps, Kubernetes, and cloud infrastructure, these guides will help you go deeper:

How Kubernetes Routes Pod Traffic with a Single Egress IP
GP3 vs GP2 EBS Volumes: Performance and Cost Comparison
How to Set Up a Self-Hosted GitHub Actions Runner
These articles cover Kubernetes networking, AWS storage optimization, and CI/CD infrastructure — useful when scaling beyond local development environments.

**Conclusion

**
T2 instances are effectively legacy at this point.
T3 instances are cheaper, faster, and operationally simpler.

For anything new, T3 should be the default.
T2 should exist only where history forces it to.

That single decision can quietly reduce cost and eliminate an entire class of performance issues.

A Lot of AWS Users Still Manage SSH Keys the Hard Way

sanjay yadav — Thu, 07 May 2026 04:48:27 +0000

I still come across a lot of EC2 setups where a brand-new SSH key pair gets created every time a new instance is launched.

It works, but over time it also becomes difficult to manage — especially across multiple environments, engineers, or temporary workloads.

What’s easy to miss is that AWS already lets you import an existing public SSH key directly as an EC2 key pair.

That means you can keep using the same SSH workflow you already manage locally instead of constantly juggling separate keys for different instances.

It’s a simple improvement, but it makes SSH access much easier to keep consistent.

I found this breakdown useful because it explains the process clearly without overcomplicating it:

https://www.kubeblogs.com/how-to-import-an-existing-ssh-key-to-aws-as-a-key-pair/

Worth keeping in mind if you're trying to simplify SSH access management across AWS environments.

EC2 vs Fargate Isn’t Really About Cost

sanjay yadav — Wed, 06 May 2026 05:06:24 +0000

Most comparisons between EC2 and Fargate usually come down to pricing and operational overhead.

Which one is cheaper.
Which one scales better.
Which one reduces infrastructure management.

But I came across an interesting point recently — the bigger tradeoff is often about control.

With EC2, you manage the underlying infrastructure yourself. That gives you deeper visibility, more customization, and flexibility around how workloads are configured and operated.

Fargate changes that model quite a bit.

You stop worrying about nodes, patching, or capacity management, which simplifies operations significantly. At the same time, you also give up some control over the environment underneath the workload.

That shift impacts more than infrastructure management alone. It changes how teams think about deployments, observability, scaling, and day-to-day operations.

What I liked about this breakdown is that it doesn’t try to position one as universally better. It explains where EC2 still makes sense, where Fargate fits better, and why the decision depends heavily on workload and team priorities.

Worth reading if you’re currently evaluating container infrastructure on AWS:

https://www.kubeblogs.com/ec2-or-fargate/

Curious what others are seeing in practice — are teams moving more toward managed infrastructure now, or still preferring the control that comes with EC2?

AWS Cost Isn’t Just Finance — It’s an Engineering Problem

sanjay yadav — Tue, 05 May 2026 04:24:00 +0000

Most teams treat cloud cost as a finance problem.

But the root cause is usually engineering.

Bills spike, dashboards grow, alerts fire — but the underlying issue rarely gets fixed.

That idea stood out to me while reading about an approach where AWS cost was handled like an SRE problem — using the same mindset applied to reliability and performance.

Instead of asking “why is the bill high?”, the focus shifts to:

Where does unnecessary spend originate in the system?
What patterns keep repeating in cost spikes?
Which design decisions are driving ongoing waste?

What stands out is how closely this aligns with SRE thinking:

Treat cost as a measurable signal
Focus on root causes, not symptoms
Continuously optimize instead of reacting

It changes the conversation from cost-cutting to system design.

This article breaks it down clearly with real examples:
https://www.kubeblogs.com/we-treated-aws-cost-like-an-sre-problem-heres-the-result/

Do you treat cloud cost as a finance metric, or as an engineering problem?

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 👍