DEV Community: Vlad Z

Everyone touches the cloud bill and nobody owns it

Vlad Z — Sat, 07 Nov 2026 10:32:06 +0000

Cloud costs touch more stakeholders than most engineering projects

And those stakeholders care about very different things

The engineer running the optimization work cares about technical correctness. Is the rightsizing safe? Are the lifecycle policies configured correctly? Will the changes cause any issues?

The engineering manager cares about risk and velocity. Will this break anything? How much time will it take? What else gets delayed while this happens?

The CFO or finance team cares about one thing: when does the bill go down and by how much? They don't understand the technical mechanism. They understand the number and the timeline

The founder or CEO cares about runway. How much longer does this give us? Does this change what we can do next quarter?

The problem with most cost optimization work is that it's communicated in the language of the person doing the work. Technical findings presented to non-technical stakeholders. Savings projections presented without confidence intervals to people who need to make budget decisions

The work gets done. The communication fails. The impact is smaller than it should be because nobody fully understood what happened or why

What actually works is translating the same information into the language of each stakeholder

To engineering: here are the specific changes, the risk level for each, the rollback plan, and the monitoring approach

To the engineering manager: here's the scope, the timeline, the risk to other work, and why it's worth prioritizing now

To finance: here's the current monthly cost, here's the projected cost after changes, here's when the changes will be complete, and here's the confidence level on the projection

To the founder: here's what this does to the runway number and what it makes possible that wasn't possible before

Same work. Four different translations

The teams that get organizational support for cost optimization are the teams that learned to make those translations

The ones that don't are still waiting for someone to understand why their spreadsheet matters

The reliability versus cost trade-off that keeps engineers awake

Vlad Z — Wed, 04 Nov 2026 21:12:46 +0000

The reliability-cost tradeoff is the one that keeps engineers up at night

Because the cost of getting it wrong in one direction is financial. The cost of getting it wrong in the other direction is an outage

And outages are not abstract. They're 2am pages, angry customers, recovery stress, lost revenue, and sometimes lasting reputation damage

So when someone says "we can save $1,200 a month by removing the standby replica" the instinct is to resist. The replica hasn't saved us yet. But it might. And the day it does we'll be glad we paid for it

That instinct is not irrational. It becomes expensive when it applies to everything

Here's the question that cuts through it

What does a failure of this resource actually cost?

Not in the abstract. Specifically. If this instance fails, what breaks? For how long? What is the revenue impact per hour of downtime? What is the customer support cost? What is the engineering time to recover?

For a critical production database in a revenue-generating system: the cost of downtime is high and the cost of the standby replica is probably justified many times over

For a development environment database: what does a failure actually cost? A few hours of one developer's time. Is the standby replica saving you more than that per month? Almost certainly not

Reliability investment should scale with the business impact of failure

Infrastructure that the product's revenue depends on directly: invest in reliability

Infrastructure used by internal teams, test environments, low-traffic services: apply the cost constraint first and add reliability when the business case is clear

The mistake is applying the same reliability standard to everything

That's not engineering rigor. That's a refusal to make the decision

The decision is: what is this worth protecting and what would it cost us if it failed?

Make that calculation. Then design accordingly

Cost and performance are not enemies

Vlad Z — Tue, 03 Nov 2026 09:53:00 +0000

Cost optimization and performance are not always at odds

But sometimes they are. And pretending otherwise leads to bad decisions in both directions

The engineer who refuses to rightsize a database because "it might affect performance" without checking the actual utilization is using performance as an excuse to avoid change. At 12 percent average CPU utilization, the smaller instance will perform identically

That's the false tradeoff. And it's common

The real tradeoff is different

Caches cost money. They also dramatically reduce database load and response times. Removing a cache to reduce costs can save $200 a month and increase your database bill by $800 while also making your product slower. That's not optimization. That's just moving the cost and degrading the experience

Multi-AZ database deployments cost twice as much as single-AZ. They also mean automatic failover in under 60 seconds when the primary instance has a hardware failure. The cost of going single-AZ to save money is the cost of a database outage happening at the worst possible time. That's a real tradeoff and it depends on how much that outage costs you

CDNs cost money. They also reduce egress costs from origin and make your product faster for users outside your primary region. Removing the CDN to save money often costs more in egress than it saves in CDN fees. The math matters

Here's how I think about the performance-cost tradeoff

What does this resource actually do for the product?

If it has a clear, measurable contribution to performance or reliability that the product depends on: understand the tradeoff before reducing it. Quantify what you'd lose

If the contribution is theoretical or unmeasured: measure first. Don't protect something valuable. Don't destroy something valuable by assuming it isn't

Performance concerns that can't be measured are usually fears, not facts

Fears are expensive to hold. Get your data. Measure them first

Then make educated decisions based on past information rather than guesswork

The checklist I run on every cloud account

Vlad Z — Mon, 02 Nov 2026 14:24:30 +0000

Every account I review, I go through the same checklist

Not because I need the checklist. Because the checklist makes sure I don't skip things when I'm moving fast or when something interesting distracts me early

Here it is

Billing and visibility
Are budget alerts configured at meaningful thresholds?
Is billing export set up for deep analysis?
What percentage of resources have cost allocation tags?
What is the tag coverage gap and what does it make invisible?

Compute
What is the average CPU utilization across EC2 or Compute Engine instances over the last 30 days?
What is the average memory utilization?
Are there instances with consistent utilization under 20 percent?
Are there instances that could run on spot or preemptible capacity?
Is autoscaling configured where the workload allows it?

Storage
What storage class is the majority of object storage using?
When were the objects last accessed?
Are there snapshots or backups older than the recovery requirement?
Are there volumes or disks not attached to any compute resource?

Databases
What is the RDS or Cloud SQL utilization compared to provisioned capacity?
Are automated backup retention policies aligned with actual recovery requirements?
Are read replicas being used and is their utilization justified?

Networking
What is the data transfer cost broken down by type?
Is there traffic crossing regional or AZ boundaries that doesn't need to?
Are there NAT gateways or load balancers with no traffic?

Forgotten resources
Are there resources in regions not being actively used?
Are there services that were provisioned for testing and never decommissioned?
Are there reserved instances that expired and weren't renewed?

Spending commitments
What percentage of steady-state compute is covered by savings plans or reserved instances?
Are the commitments sized based on rightsized utilization or on historical on-demand usage?

This list is not complete. Every account adds something new

But accounts that are clean on this list are accounts that have their costs under control

The tools I actually use for a cloud cost audit

Vlad Z — Sun, 01 Nov 2026 18:35:14 +0000

People ask me what tools I actually use

Not the tools I recommend in theory. The ones I actually open when I get access to a new account

AWS Cost Explorer: first stop. Not for the totals. For the service breakdown and the month-over-month deltas. I'm looking for anomalies and concentration - where does the spend cluster and what changed recently

AWS Compute Optimizer: I turn this on immediately if it isn't already on. Let it run for a couple of weeks minimum. The EC2 and RDS recommendations are genuinely useful when the utilization data is mature enough

CloudWatch Container Insights and Application Insights: for accounts running EKS or ECS, this is where I look for over-provisioned workloads and underutilized nodes. Pod resource requests versus actual usage is almost always worth examining

AWS Cost and Usage Report exported to Athena: for deep analysis. When the Cost Explorer view isn't granular enough, CUR gives you the full breakdown. I write queries against it to find specific patterns - resources with no tags, services with unexpected cost spikes, cross-region data transfer by source and destination

For GCP: billing export to BigQuery is the equivalent. It's the only way to get the full granularity. The billing console is good for overview. BigQuery queries are how you find the specific things

INFORMATION_SCHEMA.JOBS in BigQuery: for any account with significant BigQuery spend, this is mandatory. Shows you exactly which queries are processing the most data. The top 10 by bytes processed is always revealing

GCP Recommender: useful for Compute Engine rightsizing and idle resource detection. Not as mature as AWS Compute Optimizer but getting better

For both platforms: a simple spreadsheet

Every finding goes in with resource ID, current cost, projected cost after fix, effort required, risk level, and owner. This is not fancy. It's just organized. And organized information is what turns a list of findings into an executable remediation plan

The tools find the opportunities. The spreadsheet determines the order

The same account after cleanup: $9,800 a month

Vlad Z — Thu, 29 Oct 2026 22:00:47 +0000

Here's what the same account looks like after

Consistent naming. Every resource follows a pattern: service-environment-region-purpose. You can read a resource name and know immediately what it does, where it lives, and what environment it belongs to

Tags on everything. Team. Service. Environment. Cost center. Created date. Owner. The billing dashboard shows spend by team, by service, by environment. When something spikes, you know immediately what it is and who to talk to

Active regions: two. Us-east-1 for production and us-west-2 as a failover target. Everything else cleaned up. The experiments in other regions: deleted. The total active resource count: reduced by 40 percent from when we started, with the same workload running

Orphaned resources: gone. A quarterly cleanup process now runs through the account looking for unattached volumes, unused IPs, load balancers with no targets, security groups associated with nothing. Takes two hours. Catches things before they accumulate

Log retention policies set on every log group. Application logs: 30 days. Infrastructure logs: 90 days. Audit logs: 365 days. Log levels in production: info, not debug. The CloudWatch bill reduced by 75 percent

RDS instances sized for actual utilization. Automated backup retention set to match the actual recovery requirement, not the AWS default. Old manual snapshots deleted after confirming they're not needed

Reserved instances and Savings Plans purchased for the stable baseline workload. On-demand only for variable capacity

Monthly spend: $9,800

From $24,000 to $9,800. Same product. Same users. Same capabilities

The difference is not technical sophistication. Both states have technically sound infrastructure

The difference is attention. The first state is what happens when nobody is watching. The second state is what happens when someone is

That's the whole story

What a neglected cloud account looks like: $24,000 a month

Vlad Z — Wed, 28 Oct 2026 23:55:19 +0000

Here's what a neglected cloud account actually looks like when you open it

No consistent naming convention. Resources called things like "test-new-2", "db-final-v3", "loadbalancer-dont-delete". The names tell you nothing about purpose, environment, or owner

Tags: either completely absent or present on 30 percent of resources with no consistent schema. Some resources tagged with "env:prod". Others with "environment:production". Others with nothing

Multiple regions active with no clear reason. The main workload runs in us-east-1. There are resources in eu-west-1, ap-southeast-2, and us-west-2. Some of them might be for users in those regions. Most of them are from experiments that ran in those regions because someone had a reason at the time and the resources never got cleaned up

Orphaned resources everywhere. EBS volumes not attached to any instance. Elastic IPs not associated with any resource. Load balancers with no healthy targets. Security groups referenced by nothing

Log groups without retention policies, ingesting data at rates that don't match the traffic the services should be generating

RDS instances with automated backups retained for 35 days when the company's recovery requirement is 7 days. Multiple database snapshots taken manually for reasons nobody remembers. The oldest ones: from two years ago

Reserved instances that expired and weren't renewed, leaving workloads back on on-demand pricing without anyone noticing for four months

The total monthly spend: $24,000

The team's honest estimate of what it should cost: $10,000 to $12,000

The $12,000 to $14,000 gap is not from bad engineering decisions

It's from the accumulated weight of good engineers moving fast and never having the mandate, the time, or the tools to look back

This is what the starting point looks like. The good news is that starting points are just starting points

Built for a scale that never came

Vlad Z — Tue, 27 Oct 2026 10:23:51 +0000

The second most expensive mistake I see is infrastructure built for a scale that never came

A startup spends three months building a multi-region, highly available, auto-scaling architecture. Kafka for event streaming. Separate read replicas for every database. Cross-region failover. The works

They have 200 users

Not 200,000. 200

The infrastructure can handle 50,000 concurrent users without breaking a sweat. 200 users use about 4 percent of its capacity. The other 96 percent runs continuously, full price, waiting for traffic that may or may not ever arrive

This is a real thing I've seen. Not once

The motivation is always good. Engineers want to build things right. They've read about the companies that got caught unprepared when they went viral. They don't want to be the team that had to rewrite everything under load. They build for the future to avoid the pain of not being ready

The problem is that the future is uncertain and the infrastructure bill is not

Every month you run infrastructure at 4 percent utilization is a month of runway spent on capacity you don't have the users to justify yet

The right question is not "can this architecture handle our growth?" but "what's the cheapest architecture that handles our current load and can be upgraded when we actually need to upgrade it?"

The answer at 200 users is almost always simpler than what teams build

One region. One availability zone, maybe two. A single appropriately sized database. An application server that can be vertical scaled or replicated when needed. Basic monitoring. That's it

You build the complex architecture when the growth makes it necessary, not when the ambition makes it appealing

The companies that write those viral "how we scaled to X users" blog posts almost never built that architecture at 200 users

They built it when they needed it. Because they still had runway to get there

The most expensive phrase in cloud: we'll clean it up later

Vlad Z — Sun, 25 Oct 2026 23:16:01 +0000

The most expensive phrase in cloud infrastructure is "we'll clean it up later"

I've heard it in every account I've worked with

A dev environment gets created for a sprint. We'll clean it up later

A service gets deployed with debug logging enabled. We'll turn that down later

A database gets provisioned at a size that's too large for current needs because the cost of under-provisioning feels riskier than the cost of over-provisioning. We'll rightsize it later

Later never comes. Not because the team is irresponsible. Because later becomes now and now is always full

The sprint ends and the next sprint starts. The debug logging produces useful information once and now removing it feels risky. The database has been running for three months and suddenly changing it requires coordination and a maintenance window and it's never the right week

The resource just keeps running

I've found dev environments running for 18 months that were created for a feature that shipped in week two

The cost isn't just the money. It's the compounding weight of things you meant to do that you didn't do. Every resource you know should be removed but haven't removed adds cognitive overhead. Every time someone looks at the account they have to decide again whether this thing is safe to touch. That decision cost happens over and over

The pattern that actually works is not doing the cleanup later

It's building cleanup into the creation

When you spin up a dev environment, set a termination date in the tags. Schedule a reminder. Make the cleanup part of the task, not an afterthought

When you enable verbose logging, create a ticket immediately to reduce log level before the service goes to production. That ticket sits in the backlog as a concrete reminder instead of a vague intention

When you provision infrastructure you might need to rightsize, set a calendar reminder for 30 days later to check utilization

The discipline is not the cleanup

The discipline is treating the cleanup as part of the work when the work happens

Later is a cost you pay monthly until you do

Day two of the audit: CloudWatch went from $2,400 to $380

Vlad Z — Sat, 24 Oct 2026 10:09:34 +0000

Continuing from where we left off with the B2B SaaS account

Day three: we started making changes. We had the map. We had the findings. We had write access. We had a rollback plan for each change and a monitoring window defined in advance

First change: delete the unused OpenSearch cluster

Confirmed with the CTO that nobody was using it and nobody planned to use it. Deleted. Immediate: $800 a month gone

Second change: set retention policies on CloudWatch log groups

43 log groups. Most had no retention policy. We set 30 days on application logs, 90 days on infrastructure logs, 365 days on audit logs. Deleted three log groups receiving data from services that no longer existed. Reduced the data volume on two log groups by changing log levels from debug to info

CloudWatch went from $2,400 to $380 a month

Third change: RDS rightsizing

Two of the three RDS instances were running at under 20 percent CPU and under 30 percent memory. We moved both from db.r5.2xlarge to db.r5.large. Scheduled maintenance windows, ran the resize, monitored for 48 hours each

No issues. RDS went from $3,100 to $1,400 a month

Fourth change: S3 lifecycle policies

Set up policies across 11 buckets. Objects over 90 days old move to Standard-IA. Objects over 365 days old move to Glacier Instant Retrieval. Two buckets containing data that hadn't been accessed in two years moved entirely to Glacier Deep Archive

S3 went from $1,100 to $420 a month

End of week one. No EC2 changes yet. No data transfer work yet

Already saved: $5,100 a month from four changes

The CTO was quiet for a moment when I showed him the numbers. Then he said: why has nobody looked at this before?

I didn't have a good answer. It's the same account I see everywhere. Not neglect. Not incompetence. Just nobody whose job it was to look

A 12 person company, a $19,200 AWS bill, and a CTO who was right

Vlad Z — Fri, 23 Oct 2026 20:41:08 +0000

I want to walk through a full engagement from start to finish

Not a highlight reel. The whole thing, including the parts that were slower and messier than I expected

B2B SaaS company. 12 employees. AWS account. Monthly spend when I started: $19,200

Their CTO had looked at the bill and estimated it should be around $8,000 to $10,000 for their workload. He was right. That instinct was correct. But he didn't know where the extra $9,000 was coming from and didn't have time to find it

Day one: I asked for read-only access to the account and access to their CloudWatch metrics. No write access at this stage. I wanted to understand the whole picture before touching anything

Day one findings: six areas worth investigating. CloudWatch Logs retention policies not set. RDS over-provisioned. EC2 instances with CPU utilization under 15 percent consistently. S3 Standard storage on objects not accessed in over a year. Data transfer between regions. One completely unknown service generating $800 a month that nobody could explain immediately

I documented each finding with the resource identifiers, current cost, and initial hypothesis for what was wrong

Day two: I started with the unknown service. Always start with the unknown. It turned out to be an ElasticSearch cluster (their term - AWS OpenSearch) that had been provisioned during a performance investigation, determined to not be needed, and never decommissioned. $800 a month for eight months: $6,400 total spent on something they'd decided not to use before it even launched

That discovery set the tone for the rest of the engagement. It told me this account had multiple things running that weren't being actively used. Which meant the real savings were larger than the obvious inefficiencies

We hadn't made a single change yet. We had a map

The map made everything that followed faster and more confident

GCP project sprawl is quietly a cost problem

Vlad Z — Wed, 21 Oct 2026 20:19:56 +0000

Project sprawl is a GCP-specific problem with real cost implications

It starts innocently. Someone needs a sandbox. Someone else needs a separate environment for a new service. A contractor spins up a project for a proof of concept. A team creates a project for each major feature because that seemed like clean separation at the time

Two years later there are 30 projects. Eight of them have no clear owner. Five of them haven't had active resources for six months but still have a few things running that nobody is confident removing

The cost of the abandoned resources is real. The cost of the confusion is also real, just harder to measure

Managing 30 projects requires 30 sets of billing alerts, 30 sets of IAM reviews, 30 sets of security posture checks. Teams with good hygiene do this. Most teams don't, which means the 30 projects are effectively unmonitored

Project sprawl also creates a discovery problem. When something is wrong, which project is it in? When you need to understand your architecture, how do you get a coherent picture across 30 projects with inconsistent naming and labeling?

The consolidation work is genuinely hard. GCP doesn't make it easy to merge projects or move most resources between them. But there are approaches

Identify projects with no active resources by billing data: zero spend for 90 days is a reasonable threshold for a deletion candidate. Notify the listed owner. Wait 30 days. If no objection, delete

For projects with active resources that should be consolidated: document the migration required to move workloads to the target project. Treat it as a migration project with a deadline

For future projects: establish a project creation process. Require an owner, a purpose, and a planned retirement date. Review quarterly

The sprawl didn't happen in a day. It won't be fixed in a day

But each project you consolidate or delete reduces the surface area of the problem for every future optimization effort