Public cloud at a reasonable price: what the bill is made of and where the budget leaks

WebDisk Blog · category: Cloud · reading time: ~8 minutes

In short:- A cloud bill is not a single line item but several independent meters: compute, capacity, transfer, IP addresses and backups. Surprises almost always come from the last three.- Costs called "hidden" usually are not hidden – they are simply outside the calculator: outbound transfer, object operations, minimum storage duration, restoring from archive classes.- The bill is brought down by boring habits, not by negotiations: rightsizing, a schedule for test environments, matching the storage medium to the data, cleaning up orphaned resources.

Public cloud starts with delight: a machine comes up in a few minutes, storage grows by itself, nobody waits for a server to be delivered. The delight lasts roughly until the third bill – that is when the question comes: where does this amount come from, if we changed nothing?

Usually nothing changed in the machines – what changed is everything around them: data piled up, an integration started pulling files every minute, someone left a test environment running after a demo, and snapshots from six months ago still take up space. A bill rarely grows for one reason; it grows for five at once, a little from each.

This article takes such a bill apart: what it consists of, which items surprise people most often, when an in-house server room really does come out cheaper – and what to do in order not to overpay. We write it from the perspective of a small cloud provider, so a warning up front: we have a stake in this. In exchange, we try to show the mechanics, which you can check at any provider – ours included.

What does a public cloud bill consist of?

Regardless of the provider, the cost of infrastructure as a service (IaaS – renting raw resources: machines, disks, networking; the differences between IaaS, PaaS and SaaS are described in the article Cloud as a Service) breaks down into a few components:

• Compute – the vCPU and RAM of virtual machines. Usually the most predictable item, because it follows directly from decisions made in the panel.
• Capacity – machine disks and object storage. It grows quietly: nobody notices a few percent a month, but after a year it adds up to a clear difference.
• Transfer – network traffic, above all outbound (egress). The item most sensitive to changes you do not control: a traffic spike on the website, a new API client, a badly written sync client.
• IP addresses – at many providers a public IPv4 address is billed separately, sometimes even when it is reserved but unused. It is worth checking how many you really need and whether part of the traffic could be moved to public IPv6 addressing. With us, the basic public cloud plans include one public IPv4 address in the price – further ones are a separate item.
• Backups and snapshots – the most frequently underestimated item, because you pay not for one copy but for the whole history: the full base plus the increments from every restore point, for the entire retention period. The longer the retention and the more the data changes, the bigger the difference between "500 GB of data" and "500 GB in backup".

The practical conclusion: the bill has to be broken down into these components and compared month to month. The total amount tells you nothing – only the breakdown shows that it was capacity that grew, not compute.

Which cloud costs can you not see in the calculator?

A separate category covers the items that do exist in extensive price lists, but do not show up in the simple estimate of "how much does a machine cost":

Outbound transfer. The most common cause of billing surprises: you upload data for free, and you pay for every gigabyte that leaves. The side effect is strategic – the more data you have, the more expensive moving out becomes. This is the classic provider dependency mechanism, described more broadly in the article on vendor lock-in. The EU Data Act, applicable since 12 September 2025, caps the fees for switching providers itself at the costs actually incurred, and from 12 January 2027 removes them entirely. It does not, however, cover ordinary outbound traffic during normal use of the service – that can still be charged.

Object operations. In S3 storage you pay not only for the space occupied, but also for the number of requests: writes, reads, listings. An application querying the storage in a loop can generate an item comparable to the cost of storage – even with a small amount of data.

Minimum storage duration and restore cost. Cheap archive classes have two catches: a file deleted before the minimum period expires is billed until the end of that period anyway, and restoring the data can be charged separately. Such a class is cheap for exactly as long as you do not use it.

All the other odds and ends. Operating hours of load balancers and NAT gateways, traffic between availability zones, licenses billed on top of the machine hour, paid support plans. Each item on its own looks innocent; the problem is how many of them there are. This is not an accusation – that is what billing a very complex offering looks like. It is worth knowing, though, that the complexity of a price list is itself a cost: to avoid losing money on it, you need someone who understands it.

Is an in-house server room cheaper than the cloud? TCO is what counts

After the first big bill the idea comes back: "we will buy servers, it will be cheaper". Sometimes it really is – with a stable workload and no seasonal peaks. There is one condition: calculate the total cost of ownership (TCO), not just the price of the hardware. The calculation includes:

• colocation or your own room: floor space, power (including backup power), cooling, access control;
• internet links – preferably from two operators, if the service is meant to be available;
• virtualization and operating system licenses, renewed every year;
• spare parts and servicing, because a disk will fail on a Friday evening;
• people: not just a full-time administrator, but also on-call duty and holiday cover – the expertise has to exist in duplicate;
• somewhere to keep the copies outside that server room, because a copy next to the server is not a copy (cloud backup);
• a hardware refresh every few years and the spare capacity bought "for the peak", standing idle for the rest of the year.

An honest conclusion: your own hardware can be cheaper in unit cost and more expensive in total – and the difference reveals itself at the first failure or the administrator's first holiday. It also works the other way round: with a flat workload, paying for elasticity makes no sense. A mixed model – a stable base in-house, peaks and backups in the cloud – turns out to be optimal more often than either extreme.

How not to overpay for the cloud? Four habits instead of one negotiation

1. Rightsizing. Measure the actual vCPU and RAM usage for two to four weeks before you settle on the machine size. Most environments are oversized, because the size was chosen "by eye" at launch and nobody ever came back to it.
2. A schedule for non-production environments. Dev and test are needed during working hours, yet they are paid for around the clock, seven days a week. A shutdown schedule outside working hours is usually the cheapest saving in non-production environments – on two conditions: somebody maintains that schedule, and you know exactly what stops being billed. A stopped machine releases the processor and memory, but its disk still takes up space – check this with your provider.
3. Matching the storage medium to the data. An archive does not need the same performance as production data – before you order capacity, check with the provider which storage classes it offers and how they differ in price. How object storage works and what you pay for in it is described in the article on Object Storage in WebDisk.
4. Cleaning up orphans. Once a quarter: disks without machines, snapshots older than the retention policy, reserved and unused IP addresses, old object versions, environments left over from finished projects. It is the most boring hour of the quarter and usually the best paid one.

Two billing models at WebDisk

A fair share of these surprises is solved by a billing model matched to the nature of the workload – which is why we have two, described on the pricing page:

• The business model – you buy a pool of resources (vCPU, RAM, capacity) and settle by invoice on a monthly cycle; the amount does not change with the current usage of that pool. For organizations for which cost predictability replaces billing down to the hour.
• The general model – hourly billing for the resources actually consumed, prepaid or postpaid. For variable workloads, tests and projects whose scale is not known in advance.

The two models run in separate panels and cannot see each other's resources – if you need to connect them, it is done with a site-to-site VPN tunnel. This is worth taking into account when choosing. You will find the terms and rates on the pricing, public cloud and Object Storage pages – we deliberately do not quote amounts in the article, because a blog ages faster than a price list.

The foundation of our cloud is open source software – Apache CloudStack and Ceph – so the mechanisms the service stands on are publicly documented, and you build integrations with a standard API: s3cmd, awscli, boto3 or any S3-compatible client. This has a bearing on costs: a standard interface makes migrating elsewhere a technical project rather than a strategic decision. The legal context is described in the article on European cloud computing.

An honest balance: what a cheaper cloud will not fix

• A lower price will not replace design. A badly designed architecture is expensive at every provider – at a cheaper one it simply takes longer to show.
• A smaller provider means a narrower service catalog. You will not find several hundred managed services with us. If an application is built on a service specific to a single hyperscaler, moving it will not be free – calculate that on both sides.
• Saving requires hygiene. Rightsizing, schedules and clean-ups work everywhere, but somebody has to do them. If there is nobody – include it in the budget as support.
• Cheap does not mean "free". Transfer, capacity and backups cost money at every provider; what differs is the model and the transparency of the billing.
• We count transfer too – in one of the models. In the hourly model, bandwidth is an item billed like vCPU or capacity, and in Object Storage the plan includes 1 TB of transfer per month, with a surcharge for anything above that. The rates are on the service page; we do not hide this item behind a "no transfer fees" slogan.

Frequently asked questions

Is it worth keeping everything with one provider? There is no single answer, but it is worth knowing where the data sits and how much moving it out would cost. How much it costs to leave is just as important a criterion as how much it costs to get in.

Does the Data Act remove the fees for transferring data out of the cloud? Only partly. The regulation, applicable since 12 September 2025, caps the fees for switching providers itself at the costs actually incurred, and from 12 January 2027 removes them entirely. It does not, however, cover ordinary outbound transfer during normal use of the service – that can still be charged.

Can the bill be predicted before the services are launched? In the hourly model you estimate the cost from the sum of the resources ordered and the hourly rates from the pricing page; the most reliable forecast is the resources and capacity you have counted up, plus a reserve for transfer and backups. In the resource pool model you know the bill in advance.

How can you lower your cloud bill? Four habits deliver the most: rightsizing based on measured usage, a shutdown schedule for non-production environments outside working hours, matching the storage class to the nature of the data, and a quarterly clean-up of orphaned resources – disks without machines, old snapshots, unused IP addresses. They work at every provider, but somebody has to do them.

We have our own servers – will moving pay off? That depends on the shape of the workload and on what your current TCO covers. If it does not include the cost of people, spare capacity and hardware refresh, the comparison will not be a fair one.

Summary

A "reasonable price" in the cloud does not come from one negotiation or one switch. It comes from understanding exactly what you are paying for – compute, capacity, transfer, addresses, copies – and from a few habits that keep those meters in check. The rest is choosing the billing model that fits your workload: a predictable pool or hourly billing.

Do you want to calculate this on your own data? Check the terms on the pricing page or write to us – we will help you price your scenario against our rates and tell you plainly whether moving makes sense.