DEV Community: Nikola Roganovic

Design a rate limiter, from fixed window to token bucket

Nikola Roganovic — Wed, 07 Oct 2026 21:03:55 +0000

I first published this on my blog, where you can pause and play with every animation: https://techinpencil.com/rate-limiter/

A fixed window limiter set to 100 requests per minute

The limiter in the picture above is set to 100 requests per minute, and it just let 200 through in under two seconds. It isn't broken. It's the simplest rate limiter there is, and a lot of real code works exactly like it: count requests per clock minute, wipe the count when the minute changes. A client that sends right before the change and right after it gets twice the limit through.

This is also a classic interview question. You're asked to design a rate limiter, you sketch a counter, and the interviewer asks what happens at 0:59. I'll follow that conversation here. Each section starts with the next question.

A counter and a clock

The interviewer asks: “Design a rate limiter for our public API. 100 requests per minute per API key.”

The first answer most people give is a good place to start. Keep one counter per API key per minute. When a request comes in, look up the counter for the current minute. If it's under the limit, add one and let the request through. If it's at the limit, answer with HTTP 429 Too Many Requests [1].

function allow(key, now) {
  const minute = Math.floor(now / 60_000);
  const count = counters.get(`${key}:${minute}`) ?? 0;
  if (count >= LIMIT) return false;
  counters.set(`${key}:${minute}`, count + 1);
  return true;
}

That's a fixed window. You need one integer per client, and old counters just expire. The picture below uses a limit of 10 per minute so you can count the slips.

Fixed window, limit 10 per minute

Watch the yellow band. With steady traffic it never goes above 10. With traffic bunched around the boundary it shows 20: ten just before 1:00 and ten just after. Figma's engineering blog shows the same thing with a limit of 5 per minute [2]. Five requests at 11:00:59, five more at 11:01:00, and all ten go through.

How bad that is depends on what the limit protects. A 2x spike for a second or two is fine if you just want to stop a script from hammering you all day. It's a real problem if the thing behind the limiter can't take more than 100 a minute.

Remember every request

The interviewer asks: “OK, the boundary leaks. Can you make it exact?”

Stop thinking in clock minutes. Instead of “requests this minute”, count “requests in the last 60 seconds”, measured back from right now. For that you need the time of every request you let through. That list is the sliding log.

function allow(key, now) {
  const log = logs.get(key) ?? [];
  while (log.length && log[0] <= now - 60_000) log.shift();
  if (log.length >= LIMIT) return false;
  log.push(now);
  logs.set(key, log);
  return true;
}

The next picture gets the same bunched traffic. The bracket is the last 60 seconds, and a timestamp gets crossed off when it falls out of it.

Sliding log, limit 10 per minute

It never lets more than 10 through in any 60 seconds. What it costs you is memory: each client now needs a timestamp for every allowed request instead of one integer. At 100 per minute that's up to 100 timestamps per client, 8 bytes each (a 64-bit timestamp in milliseconds), so a million active clients need 800 MB just for timestamps. Figma did this math for a limit of 500 requests a day and got 5 million stored values for 10,000 users [2].

Two counters and a guess

The interviewer asks: “Can you get close to that without storing every timestamp?”

Keep the per-minute counters from the first version, but when a request arrives, look at two of them: this minute's and last minute's. Then pretend last minute's requests were spread evenly across it. If we're 15 seconds into this minute, the last 60 seconds still include the final 45 seconds of the previous one, so you count 75% of it.

const elapsed = now % 60_000;
const estimate = previous * (60_000 - elapsed) / 60_000 + current;
if (estimate + 1 > LIMIT) return false;

Cloudflare described this in 2017 with a worked example [3]: a limit of 50 per minute, 42 requests in the previous minute and 18 so far in the current one, 15 seconds in: 42 × 0.75 + 18 = 49.5. Figma wrote about something similar the same year [2]. For an hourly limit they keep 60 one-minute counters and add them up, which means more counters to store but less guessing.

The dashed slips under the line are what the estimate assumes, and the solid ones are what happened.

Sliding window counter, limit 10 per minute

If minute 1's traffic came early, the guess still counts requests that are already older than 60 seconds, so it's too strict. If it came late, the guess spreads them out, counts too few, and lets a few extra through. So you store two integers per client instead of a whole log, and the count is sometimes a bit off.

Cloudflare measured how far off on real traffic: 400 million requests from 270,000 sources. The estimate missed the real rate by 6% on average, but that only changes the answer for clients sitting close to the limit, so just 0.003% of requests were wrongly allowed or wrongly limited [3]. Their counters lived in a Memcached fork with simple commands like GET, SET and INCR, and that's all this approach needs.

A bucket of tokens

The interviewer asks: “Some clients send bursts. A page load fires 20 API calls at once. Can you allow that without raising the average rate?”

Every limiter so far counts the requests from the last minute. A token bucket doesn't count requests at all. Each client gets a bucket that holds up to N tokens, and tokens drip in at a fixed rate. A request takes one token, and if there's none left it gets a 429. A full bucket lets a burst of N through at once, and after that the client gets exactly the refill rate.

The drip doesn't need a timer or a background job. You store two numbers per client, the token count and the time you last looked, and top the bucket up when the next request shows up:

function allow(b, now) {
  const refill = (now - b.last) / 1000 * RATE;
  b.tokens = Math.min(CAPACITY, b.tokens + refill);
  b.last = now;
  if (b.tokens < 1) return false;
  b.tokens -= 1;
  return true;
}

In the picture, the coin forming under the tap is that top-up.

Token bucket

So there are two settings instead of one: the bucket size decides how big a burst you accept, and the rate decides the average. Stripe wrote in 2017 that they use a token bucket for their API, with the limiters backed by Redis [4]. AWS API Gateway documents its throttling the same way: the rate is tokens added per second, and the burst is the size of the bucket [5].

It doesn't fix 0:59 on its own, though. A bucket of 100 that refills at 100 per minute can still let about 200 through in 60 seconds: the 100 it saved up, plus 100 more dripping in. If a hard ceiling per minute matters, keep the bucket small compared to the rate.

A bucket with a hole

The interviewer asks: “The payment provider behind this API accepts 2 calls per second. Bursts or not. Now what?”

The leaky bucket is the other famous bucket, and the name gets used for two different things. In the first one, the requests themselves go into the bucket and leak out of a hole at the bottom at a steady rate. The bucket is a queue. A burst doesn't get rejected, it waits its turn, and you only answer 429 when the queue is full.

The picture below sends the same bursts through both, with the same size and rate: the token bucket on top, the queue below.

Token bucket and leaky bucket, same size and rate

The token bucket passes the burst straight to the server. The queue turns it into an even drip, but requests have to wait: here the last one in each burst waits almost 3 seconds. That's what you want in front of something that really can't take a burst, like that payment provider. NGINX's limit_req works this way when you set burst and leave out nodelay: extra requests are delayed and only rejected once they go past the burst size [6]. It answers with 503 by default, so if you want a 429 you have to set limit_req_status.

The second meaning counts instead of queueing. Shopify's API docs describe it with marbles: every request drops a marble into the bucket, the bucket leaks at a fixed rate, and a full bucket means 429 [7]. Nothing waits in this one. Turn it upside down and you have a token bucket, because marbles in the bucket are just tokens missing from it. For the same size and rate, the two make the same decision on every request.

Many servers, one limit

The interviewer asks: “You have 20 API servers behind a load balancer. Where does the counter live?”

A counter in each server's memory doesn't work. A client whose requests get spread over 20 servers can get up to 20 times the limit, so 2,000 a minute instead of 100. The counter has to move to a shared store, often Redis, and that opens a new way to get it wrong. Here it is step by step:

Two servers, one counter

Read, decide, write is three steps, and another server can slip in between any two of them. With thousands of requests per second on the same key, it will. The fix is to let the store read and write in one operation. For a counter that's INCR, which adds one and returns the new value, and you decide based on what it returns [8]. For a token bucket, where the update is more than adding one, the usual answer is a small Lua script. Redis runs a script from start to finish without running anything else in between [9].

Even the Redis docs point out a race in one of their own rate limiter examples: a client that crashes between INCR and EXPIRE leaves a counter with no expiry, which the docs call a leak. Their fix is a Lua script too [8].

Saying no politely

The interviewer asks: “What do you send back when you say no?”

Status 429 Too Many Requests, from RFC 6585 [1]. The same section says the response may include a Retry-After header, which tells the client how long to wait, and RFC 9110 defines it as a whole number of seconds or an HTTP date [10]. A client that respects it stops hammering you. RFC 6585 also says caches must not store a 429.

GitHub goes further and tells you where you stand on every response, not only when you're blocked [11]. Authenticated users get 5,000 requests an hour, and the headers say how many are left and when the count resets, in UTC epoch seconds:

HTTP/1.1 200 OK
x-ratelimit-limit: 5000
x-ratelimit-remaining: 4987
x-ratelimit-used: 13
x-ratelimit-reset: 1790001200

There's an IETF draft to standardize this with two headers, RateLimit and RateLimit-Policy [12]. It's still a draft, version 11 as of May 2026. Plenty of blog posts show the older RateLimit-Limit and RateLimit-Remaining names, which were replaced in 2023.

Side by side

Algorithm	Per client	Bursts	Exact?	Who wrote about it
Fixed window	1 counter	up to 2x the limit at the boundary	per clock minute	Redis docs, INCR pattern
Sliding log	1 timestamp per request	never over the limit	yes	Figma (2017), considered it
Sliding window counter	2 counters	close to the limit	estimate	Cloudflare (2017)
Token bucket	2 numbers	up to the bucket size, on purpose	the average, not every 60 s	Stripe (2017), AWS API Gateway
Leaky bucket, queue	the waiting requests	smoothed, requests wait	yes, on the way out	NGINX limit_req with burst
Leaky bucket, meter	2 numbers	same as token bucket	the average, not every 60 s	Shopify

If I had to pick one without knowing more, I'd take the token bucket with a small bucket. It stores two numbers per client, and you decide up front how big a burst is OK.

Sources

Nottingham, M. and R. Fielding, Additional HTTP Status Codes, RFC 6585, April 2012. Section 4.
Mahdi, N., An alternative approach to rate limiting, Figma blog, April 2017.
Desgats, J., How we built rate limiting capable of scaling to millions of domains, Cloudflare blog, June 2017.
Tarjan, P., Scaling your API with rate limiters, Stripe blog, March 2017.
Amazon Web Services, Throttle requests to your REST APIs, Amazon API Gateway Developer Guide.
NGINX, Module ngx_http_limit_req_module, nginx.org documentation.
Shopify, Shopify API limits, Shopify developer documentation.
Redis, INCR, command documentation. See the rate limiter patterns.
Redis, Scripting with Lua, Redis documentation.
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., HTTP Semantics, STD 97, RFC 9110, June 2022. Section 10.2.3.
GitHub, Rate limits for the REST API, GitHub Docs.
IETF HTTPAPI Working Group, RateLimit header fields for HTTP, Internet-Draft draft-ietf-httpapi-ratelimit-headers-11, May 2026.

Every animation, interactive: https://techinpencil.com/rate-limiter/

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.