DEV Community: Nikola Roganovic

How to Reduce Your AWS Bill by 50%

Nikola Roganovic — Tue, 27 Jan 2026 17:33:04 +0000

Cutting your AWS bill by 50% sounds unrealistic.

It isn’t.

In most growing AWS environments, a 30–50% reduction is achievable without rewriting applications, migrating providers, or slowing down production. These savings don’t come from a secret trick. They come from achieving visibility and correcting accumulated problems no one wanted to touch.

Let’s break down those problems.

Do you know what is running ?

Are you looking at your architecture diagram instead of your actual resources?

Your diagram is not your infrastructure. The real cost lives in what is currently running across regions and accounts, including resources nobody remembers.

The biggest savings usually appear in: Idle or underutilized EC2 instances, Overprovisioned RDS databases, Orphaned EBS volumes, Old snapshots with no retention policy, Unused load balancers, Forgotten Elastic IPs.

These are not edge cases. They are standard in mature AWS accounts.

Before you even start thinking about Savings Plans or Reserved Instances, stop and ask yourself one simple question: if you had to build this from scratch today, would you actually launch all of this again?

If the answer is no, that’s where the 50% reduction begins.

Overprovisioning

Most teams provision infrastructure for peak traffic that happens a few times per month or even a year, and then pay maximum pricing 24/7.

EC2 instances are larger than necessary. RDS instances are provisioned for theoretical growth. EKS clusters run with excess capacity “just in case.”

Right-sizing alone usually reduces costs by 20–30%.

And you think this is risky? No, it’s not. It’s simply measuring real utilization and provisioning your infrastructure with actual demand.

Increasing capacity is easy. Reducing it takes effort.

If you have not reviewed CPU, memory, and storage utilization in the last quarter, you are almost certainly overpaying for it.

Data Transfer Is Expensive

Many teams focus only on compute while ignoring network costs.

Cross-AZ. Cross-region. NAT Gateway. Public data transfer.

As your system grows, these costs grow with it, and no one really questions them because they don’t belong to anyone.

Sometimes a small change in how your services are connected, reducing cross-AZ traffic, cutting down on NAT usage, or cleaning up outbound traffic is enough to lower your monthly bill without touching the application itself.

If someone asks you about your data transfer costs and you can’t explain them, that’s a problem.

Storage

Storage feels inexpensive at first.

Over time, it becomes a silent cost accumulator: Snapshots without lifecycle rules, S3 buckets without retention policies, Logs stored indefinitely, EBS volumes attached to terminated instances.

Individually, these charges look harmless. Together, they often end up on my CostlyFY audit list.

Lifecycle policies and retention standards are not optional tasks. They are cost controls.

If your organization doesn't enforce storage rulles, your bill will grow even if compute stays flat.

Discounts Without Discipline

Savings Plans and Reserved Instances are powerful tools when applied correctly.

They are not a solution to a large AWS bill.

Locking in long term commitments on top of inefficient usage optimization simply guarantees long term inefficiency at a slightly discounted rate.

The correct sequence is: Eliminate waste, Right-size infrastructure, Stabilize usage patterns, Then apply commitments strategically.

If you do it in the wrong order, you’re locking in your problems for the long term.

Lack of Ownership

Big AWS bills are rarely caused by complex architecture. They’re usually caused by missing ownership.

If no one is responsible for: Reviewing monthly bill, Investigating anomalies, Enforcing tagging, Shutting down unused resources.

Then costs increase by default.

Cloud pricing is usage based. Usage expands when nobody feels accountable for it.

Reducing your AWS bill by 50% is not a technical miracle. It is an operational decision.

What 50% Actually Means

In most environments, the savings do not come from a single dramatic change.

They come from: Removing unused infrastructure, Correcting oversizing, Cleaning up storage, Optimizing network, Applying commitments intelligently.

Individually, each adjustment looks incremental. Together, they compound.

That is how meaningful reductions happen without disrupting production.

The Practical Reality

All of this requires time, data analysis, and a willingness to challenge existing beliefs.

Most teams know they’re spending more than they should. They just don’t have the time to dig into it properly.

If you want a clear view of where your AWS bill can actually be reduced without making blind changes or taking unnecessary risks, a structured cost audit helps you see it quickly.

That’s exactly what I do at CostlyFY: detailed AWS cost reviews focused on identifying real savings opportunities while preserving system stability.

Because reducing your AWS bill by 50% is rarely about doing something extreme.

It’s about finally looking at the numbers without avoiding what they show.

ChatGPT Ads Are Coming: What It Means for Users

Nikola Roganovic — Tue, 20 Jan 2026 10:00:27 +0000

The illusion

Since the popularization of AI up to today, every AI company has been trying to build a certain set of features and tools aimed at keeping people glued to that magical chat window for as long as possible. Not necessarily because of subscriptions and direct monthly revenue, but because of creating the illusion of a perfect personal assistant that is always there to help you.

This assistant evolves (through new models), adapts, and over time becomes better and better at executing its tasks, and lately it has even become cheaper than ever. With the introduction of the new GO plan, for just $8 you get an unquestioning assistant that will always help you (until you hit the limit, of course, and then you pay a bit more for an even better one) in solving complex tasks, automating boring work, writing code, fixing bugs, and all the things you don’t want to actively deal with, creating a bigger and bigger habit and dependence on using it for less and less money, or even through “generous” free tiers.

What makes this illusion so effective is how few obstacles exist between the user and the system. You open a chat window, you ask for help, and the help arrives. Over time, that simplicity reshapes expectations. Assistance starts to feel less like a product and more like something that simply exists in the space around you.

Good Intentions Don’t Pay for Infrastructure

Running large-scale AI systems is not just a question of models and innovation, but of infrastrucutre, cost, and viability. Subscriptions help, but they were never designed to carry the full weight of a product that millions of people use daily, often intensively, and often without paying anything at all. A monthly fee captures commitment from a small group of users, but it leaves the majority of usage unresolved. When a system becomes this central in everyday workflows, relying solely on subscriptions stops being a smart strategy and it starts being a losing battle. At that point, the question is no longer whether another revenue model will appear, but which one can realistically support the scale that has already been created. And the answer, is ads.

Shift in how people already use ChatGPT

It is no secret that AI systems like ChatGPT are being used for an ever expanding range of tasks, and that no two people use them in exactly the same way. What has changed more noticeably, however, is not the technology itself, but the expectations we bring to it.

With all the new capabilities and advantages, we have become lazier than ever before. We don’t want to wait 30 seconds for ChatGPT to display “thinking..”, we don’t want incorrect answers, we want a finished solution, business ideas, and we want it immediately, and delivered with the phrase “make no mistakes.”

This shift is especially visible outside of purely technical work. We no longer want to think about where to go for dinner. We want the top five restaurants. We do not want to browse, compare, or explore. We want the best clothing, the best hotels, the best options, filtered and ranked without additional context.

We are not opposed to influence. We are opposed to recognizing it. We want advertising, as long as it does not announce itself as such. We want it as a generic AI answer, helpful, and indistinguishable from everything else the AI already provides.

That shift did not begin with ads.
It began with how we chose to use the tool.

Ads Won’t Look Like Ads

According to OpenAI’s own description, ads in ChatGPT aren't designed to merge into the model’s responses. Ads will not alter, shape, or influence what the AI say and the generated answer remains independent.

Instead, ads are meant to appear as separated elements, displayed outside of the model’s response itself. They will be visually distinct, explicitly labeled, and positioned in a way that makes it clear what comes from the AI and what is sponsored. This means ads will appear below an answer, not inside it, and only when there is a relevant commercial context tied to the conversation.

From a technical standpoint, this separation is critical. It preserves the integrity of the model’s output while allowing monetization to exist alongside it. OpenAI has been explicit that advertisers do not influence answers, do not gain access to conversations, and do not receive user prompts or responses.
And we know that will never happen. For sure.

This isn’t about trust.

It is tempting to frame the current state of AI around trust. We ask whether OpenAI will keep its promises, whether they respect user privacy, or whether the line between a helpful answer and a paid advertisement will remain intact.

When a company’s way of survival depends on satisfying massive capital investments, optimization follows the money, not the truth. If the revenue model shifts toward advertising, the AI won't be your assistant. It will become a salesman designed to manipulate your decision.

This isn't an accidental "drift." It is the inevitable result of a business model that views the user not as a customer to be served, but as a resource to be harvested. Every "reasonable" decision to prioritize sponsored content would be a dangerous path for a product.

The mistake most users make is trusting the system as it exists today. They enjoy the current feature set while ignoring everyting else.

What Changes

When ads arrive, the interface may look almost the same, with only a subtle addition such as an ad banner at the bottom. What changes first is not the output, but the relationship. The system is no longer optimized solely around usefulness. It now operates within an additional constraint: revenue. Even when ads are technically separated from answers, their presence alters what the system exists to maximize. Attention becomes measurable. Time spent inside the interaction starts to matter in ways it did not before.

Conclusion

The introduction of ads into systems like ChatGPT is not a betrayal, nor is it an unexpected twist. It is a familiar stage in the lifecycle of products that need to sustain themselves financially as they grow.

For users, the challenge is not to reject these systems, but to understand them more clearly. Advertising does not automatically erase value, nor does it immediately compromise usefulness. What it does is change the set of incentives the system operates under, and that change deserves attention.

Follow CostlyFY and stay up to date with the latest news from the tech world!

You’re Running EC2 Instances That Do Nothing

Nikola Roganovic — Sun, 11 Jan 2026 14:24:58 +0000

Somewhere in your account, EC2 instances are running with no traffic, no purpose, and no owner.
They exist only because nobody had the audacity to delete them.

They Were Never Meant to Survive

These instances were born from lies.

They were launched for a “temporary test.”
They survived three reorgs.
They outlived the engineer who created them.

Now they sit there.
Running.
Billing.
Judging you silently.

Who approved them?
Who needs them?
Who even knows they exist?

AWS charges you for your ignorance.

Idle Does Not Mean Free

You tell yourself idle instances aren’t that expensive.
That is a lie you repeat to sleep better.

CPU at 1%.
Disk doing nothing.
Network flatlined.

You're still being charged.

Compute.
Storage.
Attached volumes.
Elastic IPs you forgot about.

Idle infrastructure resources are not free.
They are active waste.

You don’t get a discount for ignorance.
AWS bills uptime, not intention.

How many instances would vanish if “no traffic” was a deletion rule?

If the answer scares you, good.

Fear Is Cheaper Than Discipline

Nobody logs into them.
Nobody updates them.
Nobody monitors them.

But nobody deletes them either.

Because deleting the wrong instance is dangerous.
Because breaking something is problematic.
Because wasting money is quiet.

So you choose fear over discipline.
You choose silence over ownership.

If you can’t explain what breaks when it’s terminated, you already lost control.

This Is Not Technical Debt. It’s Financial Carelessness.

You wouldn’t keep routing traffic to unhealthy instances.
You wouldn’t run production with broken readiness checks.
You wouldn’t ignore failing health checks.

But you ignore idle EC2 because the damage arrives monthly, not instantly.

That doesn’t make it harmless.
It makes it dangerous.

You are not “scaling responsibly.”
You are leaking money because nobody owns cleanup.

So here’s the uncomfortable truth:

If you’re afraid to delete EC2 instances, you don’t understand your own system.
If you don’t review EC2 costs monthly, you are guessing.
If you accept idle infrastructure, you are choosing waste.

Now decide.

Keep paying for servers nobody needs.
Or admit the mess and clean it up.

For more stories like this, check out CostlyFY.

10 Proven Ways to Cut Your AWS Bill

Nikola Roganovic — Sat, 10 Jan 2026 17:50:17 +0000

1. Right-size your EC2 instances

One of the most common reasons for high AWS bills is overprovisioned EC2 instances. Many systems don’t use a fraction of their capacity and are usually just sitting there doing nothing. By regularly monitoring CPU, memory, and other metrics, you can right-size instances to match real usage. This single change often results in savings of 20 to 40 percent without affecting performance.

2. Use Auto Scaling instead of static resources

Static servers cost money even when no one is using them. Auto Scaling allows your infrastructure to grow and shrink based on actual demand. This is especially useful for applications with daily traffic spikes or seasonal usage patterns. You only pay for what you need at any given moment.

3. Use Reserved Instances or Savings Plans for stable workloads

If a service runs continuously and has predictable usage, on-demand pricing is usually the most expensive option. Reserved Instances and Savings Plans offer significant discounts in exchange for long-term commitment. They work best for databases, core backend services, and internal systems. A small amount of planning can lead to substantial monthly savings. But be careful, if you buy them ahead of time and don’t use them, you’re still going to pay for them.

4. Use Spot Instances for batch and non-critical workloads

Spot Instances take advantage of unused AWS capacity and are therefore much cheaper than standard instances. They are ideal for batch jobs, CI pipelines, and data processing tasks. While interruptions are possible, most of these workloads can handle restarts. When designed correctly, the cost savings can be dramatic.

Don't use them for stable production workloads

5. Shut down idle resources

This one seems obvious, but many, many people forget about idle instances, or sometimes they don’t even know about them until it’s too late.

Idle resources are silent budget killers. EC2 instances, RDS databases, and load balancers often remain running without serving any real purpose. Automating shutdowns outside of working hours is simple and highly effective. This is often the fastest way to see immediate cost reductions.

6. Move cold data to S3 Intelligent-Tiering or Glacier

Not all data needs to be instantly accessible. Data that is rarely accessed should not live in expensive storage tiers. S3 Intelligent-Tiering automatically optimizes storage costs without manual intervention. Glacier is a great option for archives and long-term backups.

7. Minimize data transfer costs

Data transfer is one of the most underestimated AWS expenses. Cross AZ traffic and outbound data can add up quickly. Keeping services within the same availability zone where possible can significantly reduce costs.

8. Use serverless where it makes sense

Serverless pricing is based on execution time rather than uptime. For event driven systems and low or unpredictable traffic workloads, this model is often far more cost effective. It also reduces operational overhead. Fewer servers mean less maintenance and fewer hidden costs.

9. Set up AWS Budgets and Cost Anomaly Detection

You cannot control what you cannot see. AWS Budgets let you define spending limits and receive alerts before costs become a problem. Cost Anomaly Detection automatically identifies unusual spikes in usage. These tools are essential for teams running production workloads.

10. Delete unused snapshots, AMIs, and EBS volumes

Storage resources tend to accumulate over time. Old snapshots, AMIs, and unused EBS volumes often provide no real value but continue to generate costs. Regular cleanup and automation can lead to consistent long-term savings. This is a small habit with a big financial impact.

Once, while doing an audit report for a company, I found around ten 2 TB snapshots lying around, scattered across random regions that no one knew about.

Conclusion

Optimizing AWS costs is not a one time task but an ongoing process. Most savings come from discipline, visibility, and smart architectural decisions. When these cost hacks are applied consistently, cloud spending becomes predictable and significantly lower, without sacrificing performance or reliability.

If you enjoyed this article, feel free to check out costlyfy for more practical posts about AWS, cloud infrastructure, and cost optimization.