Cloud Cost Optimization: Rightsizing, Reservations and Waste

The bill grows because nothing gets switched off. Every launch, test and experiment adds servers, disks and logs, and most keep running long after anyone needs them. Cloud cost optimization is the habit of finding and fixing that without hurting users.

Picture a common setup. A mobile game studio runs a puzzle game with about 4 lakh (400,000) daily players, busiest from 7 pm to 11 pm. It runs on AWS, though the same ideas apply on any cloud. The setup is made up, but the problem is real.

Eighteen months ago the studio's cloud bill was Rs 6 lakh a month. Today it is Rs 14 lakh, though daily players grew only about 30 percent. Nothing is broken, and players are happy.

The platform team, the engineers who run the servers, is asked to find out why. They start by splitting the bill by what each part of the system does.

The boxes add up to Rs 13.2 lakh. The last Rs 0.8 lakh is data transfer out, the fee for data leaving the cloud, mostly game downloads and updates.

A cloud bill rarely fails loudly. It grows one forgotten server at a time. The team cuts it in a safe order: waste first, then size, then price.

Cloud cost optimization is matching what you pay for in the cloud to what you really need, at the best price available. It is not the same as spending as little as possible.

AWS's Well-Architected Framework is its published guide to building good systems. It says a cost-optimized workload fully uses its resources, reaches its outcome at the lowest price, and meets its functional requirements. A workload here means an app plus the resources it runs on.

That last part matters. If the studio saves Rs 2 lakh but matches lag during the evening rush, players leave. That is a loss, not a saving.

Four words you need first

• On-demand: you pay a fixed price for the time a server runs, with no promise to keep it. The guide for EC2, AWS's virtual server service, says it bills on-demand servers by the second, with a 60-second minimum.
• Utilization: how much of a resource you actually use, as a percentage. A server at 15 percent average CPU utilization sits idle most of the time, but you pay for all of it.
• Commitment: a promise to use, or pay for, a set amount for one or three years. In return the price drops. Reserved instances and savings plans are both commitments.
• Spot capacity: spare servers the provider sells at a big discount. The catch is that the provider can take them back when it needs them, usually with a short warning.

A prepaid mobile recharge has the same three money levers, part for part.

• Data you pay for but never use is waste, like an idle server.
• Picking a smaller daily pack that still covers a heavy day is rightsizing.
• A yearly pack paid upfront at a lower monthly price is a commitment.

Where the picture breaks: an unused data pack expires at midnight and costs nothing more. A forgotten cloud disk keeps billing every month until someone deletes it.

Most waste comes from resources that keep running, or keep being stored, after their job is done. The fix is to find them, confirm nobody needs them, and switch them off or delete them.

The team finds four kinds of waste.

• Test copies running all the time. Six copies of the game run 168 hours a week, but developers use them about 50 hours. A schedule switches them off at night and on weekends.
• Disks attached to nothing. When a server is deleted, its disk can stay behind. AWS says a detached disk keeps billing for its storage until you delete it.
• Old snapshots. A snapshot is a saved copy of a disk. A backup script made one every night for two years and never deleted any.
• Logs kept forever. The match servers write detailed debug logs. AWS CloudWatch Logs keeps log data indefinitely by default, and nobody had set a retention period.

None of these fixes touch the live game. That is why waste comes first: the savings are real, and the risk to players is close to zero.

The team's maths, with the made-up numbers above, goes like this. The test schedule saves about Rs 0.8 lakh a month. Disk and snapshot clean-up saves Rs 0.35 lakh. Keeping debug logs for 30 days saves Rs 0.5 lakh.

That is about Rs 1.65 lakh a month, without changing a line of game code.

Tags tell you who owns what

Waste is hard to find when nobody knows who owns a resource. A tag is a small label you attach to a cloud resource, such as team, game or environment. The bill can then be split by those labels.

The team makes three tags required on every new resource: owner, game and env. Anything untagged lands on a weekly list, and its owner must claim it or it gets switched off.

Tags also allow showback: showing each team what its own resources cost, even when one central budget pays. When the level design team sees its test copy's cost, it starts switching things off.

Rightsizing means moving a server, database or container to the smallest size that still handles its real load with room to spare. You choose the size from measured usage, not from launch-day guesses.

The match servers were sized for launch week, when the team feared a crash. Each has 8 vCPUs (virtual CPUs, shares of a physical processor) and 32 GiB of memory. Nobody has looked at that choice since.

Use the 95th percentile, not the average

An average hides peaks. A server can average 9 percent CPU and still run at twice that every evening. Size for the average, and the evening rush breaks the game.

So the team uses the 95th percentile, written p95. It is the value that 95 percent of samples stay under. They collect 14 days of one-minute samples, so weekends and any tournament are included. On AWS, one-minute EC2 metrics need detailed monitoring, charged per metric; free basic monitoring gives five-minute data, as of 19 October 2026.

Here is their script, with made-up samples so you can run it. It needs Python 3.8 or later, and we ran it on Python 3.13.16. For real use, replace the generated lists with your exported metrics.

import random
from statistics import mean, quantiles

# Sizes in one server family, smallest first: name, vCPUs, GiB of memory
SIZES = [("large", 2, 8), ("xlarge", 4, 16), ("2xlarge", 8, 32)]
LINE = 40  # shrink only if p95 CPU and p95 memory are both under 40%


def p95(samples):
    return quantiles(samples, n=20, method="inclusive")[-1]


def suggest(size, cpu, mem):
    names = [s[0] for s in SIZES]
    i = names.index(size)
    c, m = p95(cpu), p95(mem)
    if i > 0 and c < LINE and m < LINE:
        return f"{size} -> {names[i - 1]}: p95 CPU {c:.0f}%, memory {m:.0f}%"
    return f"keep {size}: p95 CPU {c:.0f}%, memory {m:.0f}%"


# 14 days of one-minute samples for one match server (made up)
random.seed(7)
cpu, mem = [], []
for minute in range(14 * 24 * 60):
    hour = (minute // 60) % 24
    evening = 19 <= hour < 23
    cpu.append(random.uniform(14, 20) if evening else random.uniform(4, 12))
    mem.append(random.uniform(26, 32) if evening else random.uniform(20, 26))

print(f"samples: {len(cpu)}, average CPU {mean(cpu):.0f}%, max CPU {max(cpu):.0f}%")
print(suggest("2xlarge", cpu, mem))

Run it with python3 rightsize.py. You should see exactly this, because the random seed is fixed:

samples: 20160, average CPU 9%, max CPU 20%
2xlarge -> xlarge: p95 CPU 18%, memory 30%

What just happened? quantiles with n=20 cuts the samples into 20 equal groups, so the last cut is the 95th percentile. The if line needs both CPU and memory under the line, because a server short of memory can crash even with idle CPU.

The line sits at 40 percent, which is the team's own choice. In AWS's general-purpose m5 family, going from 2xlarge to xlarge halves both vCPUs and memory, from 8 vCPUs and 32 GiB to 4 and 16. A p95 of 40 percent would then become roughly 80 percent, as tight as the team wants.

Change one size at a time

Rightsizing changes production, so treat it like a release. Follow the flow from the top.

The team moves the match servers from 8 vCPUs and 32 GiB to 4 vCPUs and 16 GiB. A week later, match lag is unchanged. The next check shows p95 CPU at 36 percent but memory at 60 percent, so they stop there.

The match servers now cost about Rs 2.8 lakh a month instead of Rs 5.6 lakh. The launch-week guess was costing Rs 2.8 lakh every month.

Both give a lower price in return for a one-year or three-year commitment. On AWS, a reserved instance is priced for one server type, region, operating system and tenancy (shared or dedicated hardware). A savings plan commits to a set spend per hour instead.

A reserved instance is not a server you own. AWS calls it a billing discount applied to matching on-demand usage in your account. You pay for the whole term, whether or not anything matching runs.

AWS describes savings plans as savings beyond on-demand rates in exchange for committing to a set amount of compute, measured per hour, for one or three years. The rates stay the same through the term.

The details below are from AWS documentation as of 19 October 2026.

• You can pay all upfront, partial upfront or no upfront.
• Compute Savings Plans cover EC2 servers of any family, size, operating system or region, plus Fargate and Lambda, AWS services that run containers and functions without you managing servers. They save up to 66 percent off on-demand.
• EC2 Instance Savings Plans save up to 72 percent, but only for one server family in one region, such as m5 in Virginia.
• AWS's EC2 guide recommends savings plans over reserved instances.

Other big clouds sell the same idea. Google Cloud calls them committed use discounts, usually on one- or three-year terms. As of 19 October 2026, some resource-based ones for Compute Engine, Google's virtual server service, can run up to six years. Azure sells a savings plan for compute on one- or three-year terms, and also sells reservations.

Commit to the floor, not the peak

The key question is how much to commit. Commit only to your baseline, the usage that never goes away, even at 4 am. Everything above it stays on-demand, so you can scale it down freely.

The team looks at the rightsized match servers hour by hour. Even in the quietest hour, 12 servers run. In the evening rush, autoscaling takes the count up to 40.

So they commit to the hourly spend of 12 rightsized servers, not 40. In the diagram, follow each kind of load to the way the studio pays for it.

The team picks one year, not three. The studio may move the game to a new engine next year. A three-year deal is cheaper per hour, but only if the load really lasts three years.

With the made-up numbers, the commitment on the baseline servers saves about Rs 0.6 lakh a month. A one-year reservation for the player database, which runs all day, saves about Rs 0.8 lakh more.

Use spot instances for work that can stop and restart without harm, such as batch jobs, data processing and test runs. Do not run work that must stay up, like a live match, on spot alone.

On AWS, spot instances are spare server capacity at up to 90 percent off on-demand prices, as of 19 October 2026. AWS sends a two-minute warning, on a best-effort basis, before it stops or terminates one. If you choose hibernation instead, it starts at once, with no two-minute warning.

Other clouds can give less time. Azure says it evicts its spot VMs (virtual machines) with 30 seconds' notice. A VM hears about it only if you opt in to Azure's Scheduled Events feed, and delivery is best effort. Design for the shortest warning you might get, or none.

The studio's nightly analytics jobs are a good fit. They read the day's game events and build reports for the design team. If a server disappears, the job restarts from its last saved checkpoint.

• Make every job save its progress often, so an interruption loses minutes of work, not hours.
• Allow several server types and sizes, so the job can still find spare capacity when one type runs short.
• Set a deadline, and fall back to on-demand servers if spot capacity is not available in time.

Spot and savings plans do not stack. AWS says a savings plan adds no discount on top of spot, and spot spend does not count toward your commitment. So the team keeps them apart.

Moving analytics to spot, with an on-demand fallback, cuts that line from Rs 2.1 lakh to about Rs 0.9 lakh a month.

Reduce cloud costs in this order: see where the money goes, remove waste, rightsize what remains, then buy commitments and use spot. Each step makes the next one more accurate.

FinOps is the practice of engineering, finance and business teams working together on technology spending. The FinOps Foundation describes three phases that repeat: Inform, Optimize and Operate.

Inform means examining cost and usage data. Optimize means finding ways to improve. Operate means putting those changes into practice, then looping back. Here is the order the team follows.

1. 1

   See the bill clearly

   Split the bill by service, team and environment using tags. Find the five biggest lines, because small lines rarely matter much.

2. 2

   Remove waste

   Schedule test environments, delete detached disks and old snapshots, and shorten log retention. These changes do not touch players.

3. 3

   Rightsize

   Use 14 days of p95 metrics for both CPU and memory, and check p99 for short spikes. Move one size down, watch for a week, then repeat.

4. 4

   Commit to the baseline

   Buy a one-year commitment for usage that never goes away. Leave the peaks on on-demand.

5. 5

   Move interruptible work to spot

   Add checkpoints to batch jobs, allow several server types, and keep an on-demand fallback.

6. 6

   Watch and repeat

   Set a budget alert, review the bill each month, and run the rightsizing check every quarter.

Here are the results side by side. Notice that the biggest saving is not the safest one.

The bill drops to about Rs 6.95 lakh a month. Each change was measured before and after, and the game did not get slower.

Cost per player, not just the total

A total bill can rise for good reasons, like more players. So the team also tracks a unit cost: cloud spend divided by daily active players. Before the work it was Rs 3.50 per player a month. Now it is about Rs 1.75.

Unit cost tells the studio whether growth is healthy. If players double and the bill doubles, unit cost stays flat. If the bill grows faster than players, waste is creeping back.

p95 ignores the busiest 5 percent of samples. Over 14 days of one-minute samples, that is 1,008 minutes, or 72 minutes a day on average. A daily peak shorter than that can vanish from the number.

# Does p95 see a 30-minute nightly spike? One-minute samples over 14 days (made up).
from statistics import quantiles
cpu = []
for minute in range(14 * 24 * 60):
    m = minute % (24 * 60)
    cpu.append(90 if 21 * 60 <= m < 21 * 60 + 30 else 10)
q = quantiles(cpu, n=100, method="inclusive")
print(f"p95 {q[94]:.0f}%  p99 {q[98]:.0f}%  max {max(cpu)}%  busy share {cpu.count(90)/len(cpu):.1%}")
print("minutes per day above p95:", round(0.05 * 24 * 60))

Running it on Python 3.13.16 prints this:

p95 10%  p99 90%  max 90%  busy share 2.1%
minutes per day above p95: 72

What just happened? The busy half hour is only 2.1 percent of the samples, so p95 reports 10 percent. p99 and the maximum both show 90 percent. Before shrinking a server, look at p99 and the maximum too, and ask when they happen.

One more Python trap. statistics.quantiles defaults to the exclusive method, which assumes real values can lie beyond your samples. On short series it can report a p95 above your highest sample.

For the samples 10, 20, 30, 40 and 50, the default gives a p95 of 57, while method set to inclusive gives 48. Python's docs suggest inclusive when your samples include the extremes, which monitoring data usually does.

Rightsizing tools see only the metrics they are given. AWS Compute Optimizer, AWS's rightsizing advisor, analyses the last 14 days of CloudWatch metrics by default, as of 19 October 2026.

You can raise that look-back to 32 days at no extra cost, enough to catch a monthly batch run. A paid option, enhanced infrastructure metrics, extends it to 93 days, for patterns that repeat every quarter.

Memory is the bigger gap. Compute Optimizer analyses memory use of EC2 servers only when the CloudWatch agent runs on them, or when one of four supported monitoring products sends it. Without that, it cannot see memory at all.

That is why the team's script checks memory as well as CPU. A server at 18 percent CPU can still be one memory spike away from a crash.

On Kubernetes, rightsize the resource requests, not just the servers. Kubernetes runs containers across many machines, called nodes. Each container states a request: the CPU and memory it asks to have set aside.

The scheduler is the part that picks a node for each pod, a group of containers that run together. It places a pod only where the sum of requests fits the node's capacity. The docs say it refuses even when actual usage there is very low.

So an inflated request wastes money even if the container uses little. Nodes fill up on paper, so you run, and pay for, more machines than the real usage needs. Here is the fix for the studio's leaderboard service.

# Part of the leaderboard Deployment, under spec.template.spec
containers:
  - name: leaderboard
    image: example/leaderboard:2.4
    resources:
      requests:
        cpu: "500m"      # was "2"; p95 use is about 0.35 CPU
        memory: "768Mi"  # was "4Gi"; p95 use is about 520Mi
      limits:
        memory: "1Gi"    # above this the container may be killed

The value 500m means 500 millicores, half of one CPU. Both requests now sit above the p95 use, which leaves room for peaks.

CPU and memory limits behave differently. A container that reaches its CPU limit is throttled, meaning the kernel makes it wait. A container that uses more than its memory limit may be killed, though only when the kernel sees memory pressure.

The team sets a memory limit as a safety net and leaves out a CPU limit, so evening spikes can use spare CPU on the node. When containers compete for CPU, the request typically acts as a weighting.

To check a node, run kubectl describe nodes NODE_NAME. Its Allocated resources section shows total requests as a share of the node, such as 680m (34%) of CPU.

On AWS, commitments are counted hour by hour, so an hour you do not use is lost. That is why the team committed to the quietest hour, not the average one.

On AWS, reserved instances are billed for every clock-hour of the term, whether or not a matching server runs. Each one covers at most 3,600 seconds of matching usage per clock-hour.

AWS's own example: one m4.xlarge reservation and four m4.xlarge servers running for 15 minutes each in the same hour. That is one hour in total, so all of it gets the reserved rate.

Savings plans work in the same hourly way. AWS says each hour's commitment can only be used within that hour and cannot be carried over. Usage beyond the commitment is charged at on-demand rates.

Discounts also apply in a fixed order. Reserved instances apply first, then EC2 Instance Savings Plans, then Compute Savings Plans. Savings plans go to the usage with the highest savings percentage first.

Start with two read-only AWS CLI commands. They list disks attached to nothing and log groups that never expire, the two leaks from the scenario.

# Disks attached to nothing (state "available")
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query "Volumes[].[VolumeId,Size,CreateTime]" --output table

# Log groups with no retention period (kept forever)
aws logs describe-log-groups \
  --query "logGroups[?retentionInDays==null].logGroupName" --output text

Expect a table with one row per detached disk, showing its ID, its size in GiB and when it was created. The second command prints the names of log groups with no retention period. Both run per region, so repeat them for each region you use.

We ran both with AWS CLI 1.46.1 against moto 5.2.4, a local mock of AWS. The one detached 100 GiB disk and the one log group without retention came back, as expected.

Why deleting old snapshots may save little

EBS snapshots, AWS's disk snapshots, are incremental: each one saves only the blocks changed since the one before. Deleting a snapshot removes only data that no other snapshot uses.

So deleting two years of nightly snapshots may save far less than their sizes add up to. Check the saving on the next bill, not on the snapshot list.

Why new tags do not show up on the bill

On AWS, a cost allocation tag must be activated in the billing console before it appears in Cost Explorer or cost reports. AWS says tags can take up to 24 hours to appear in the billing console.

Cost cutting goes wrong when it trades away reliability, speed or safety without anyone noticing. Most mistakes come from cutting too far, committing too much, or deleting the wrong thing.

• Cutting too far. A server sized exactly to its p95 has no room for a festival spike. Leave spare room, and test during a busy week.
• Removing redundancy. Running one database copy instead of two saves money until that one copy fails. Never count backups or spare copies as waste.
• Committing too much. A three-year deal for a game that might shut down next year can cost more than it saves.
• Deleting data you needed. Logs and snapshots can be needed for a security check or a player dispute. Agree on how long to keep each kind first.
• Saving once, then stopping. Without tags, alerts and a monthly review, waste creeps back as new features add resources.

Explain it as matching capacity and payment to the real load, while protecting reliability. Show that you measure first, cut in a safe order, and keep watching after the change.

1. 1

   Ask about the load

   Ask how traffic changes over a day and a week, and which work can wait. The answers decide everything else.

2. 2

   Estimate the big lines

   Do rough maths out loud: number of servers, cost per hour, hours per month. Find the one or two parts that dominate.

3. 3

   Name the waste

   Mention idle test environments, detached disks, old snapshots and long log retention. These are quick, safe wins.

4. 4

   Rightsize with data

   Say you would size from p95 usage over a couple of weeks, change one size at a time, and roll back if users notice.

5. 5

   Pick a payment for each load

   Commit for the steady baseline, use on-demand with autoscaling for peaks, and spot with checkpoints for batch work.

6. 6

   Close with guard rails

   Mention tags, budget alerts and a unit cost metric, such as cost per active user, reviewed every month.