Calculating Cloud Costs Accurately: What Does an Application Really Cost?

TL;DR

The price of a virtual machine is not the cost of running a production application. A meaningful cloud comparison must include compute, storage, data transfer, backups, networking, observability, availability and actual operational effort. Together these determine total cost of ownership (TCO). This article presents a practical calculation method, a transparent worked example and a checklist for your next infrastructure decision.

Introduction

“The new cloud costs just €300 a month.” That sounds attractive—until the first database backup is configured, outbound traffic grows and an administrator spends the weekend repairing a failed deployment.

Many cloud comparisons pit unlike services against one another: a low infrastructure-only price on one side and a managed service that already includes updates, monitoring and support on the other. Comparing only the server bills hides costs incurred elsewhere.

So the key question is not How much does a server cost? but What does it cost to operate the application reliably, securely and with reasonable effort?

1. Seven cost categories every calculation must cover

A realistic breakdown distinguishes at least seven categories:

1. Compute: virtual machines, dedicated hosts, CPU and RAM, including spare capacity for demand peaks.
2. Storage and databases: block and object storage, IOPS, snapshots, database instances and replicas where needed.
3. Networking and data transfer: load balancers, public IPs, DNS, incoming and outgoing traffic, and transfers between regions or providers.
4. Backup and recovery: storage, retention, geographically separate copies and regular restoration tests.
5. Security and observability: logging, metrics, tracing, vulnerability scanning, secrets management and protective services.
6. Operations and personnel: patching, Kubernetes upgrades, incident response, on-call duty, capacity planning and troubleshooting.
7. Downtime and switching costs: expected consequences of unavailability as well as one-time migration, integration and exit costs.

Providers do not necessarily bill each item separately. Some services are included, while others require third-party tools or your own staff. A fair comparison must still account for the same scope on both sides.

2. Worked example: a medium-sized SaaS application

Consider a fictional SaaS product with a web frontend, an API, PostgreSQL, regular backups and approximately 2 TB of outbound traffic per month. The business expects availability outside office hours and needs dependable updates and incident management.

The following figures are explicitly hypothetical, rounded monthly estimates. They are neither ayedo prices nor verified market quotations. Service scope also differs by provider.

In this model, the managed platform is €370 cheaper per month despite higher compute costs. The main driver is reduced internal operational effort. This is not a universal result: an experienced team with mature automation may have a different cost structure, and expensive add-on services may make a managed platform significantly more costly.

The lesson: the lowest infrastructure price does not automatically produce the lowest total cost.

How should personnel costs be calculated?

A simple approximation is:

Monthly operations cost = hours per month × fully loaded internal hourly rate

“Fully loaded” includes more than gross wages—for example, employer contributions, equipment and allocated overhead. At an assumed €75 per hour, the €900 in the example corresponds to twelve hours of work each month. For the managed option, approximately 4.7 hours were assumed. Validate these hours against your own tickets, time records and incident history.

Importantly, time freed up does not automatically translate into cash savings. It has a financial effect only when it replaces capacity, avoids additional hiring or can be redirected to valuable work.

3. The four most common mistakes in cloud cost estimates

Comparing list prices alone

A VM price often omits operating system patches, backups, alerting and on-call coverage. Conversely, you must not charge the full cost of those activities again to a managed platform if they are already included in its service.

Underestimating data transfer

Applications regularly move data out of the cloud through API responses, downloads, container images, media or replication. Even small per-GB price differences add up as volume grows. Check whether transfers between availability zones, regions and providers incur separate charges.

Confusing downtime costs with infrastructure costs

A second region does not simply double a single-region bill: it may require extra data replication, routing, testing and operations. Even so, it may be economically justified. The decision depends on how much downtime the business can actually tolerate.

Ignoring migration costs

A new platform may require changes to CI/CD, authentication, networking and databases. These one-time costs belong in the business case and should be allocated across an explicit evaluation horizon.

4. Turning a price list into a robust TCO model

We recommend three scenarios: normal operations, peak demand and an incident.

For normal operations, record recurring costs at typical utilization. Peak demand covers additional capacity, autoscaling and traffic. An incident scenario accounts for recovery, on-call staffing, replacement capacity and potential business impact. Not every scenario occurs every month, so one-off events and expected recurring expenses should not be added without explanation.

A practical formula is:

36-month TCO = 36 × monthly recurring costs + one-time migration and setup costs + expected variable additional costs.

For example, assuming €1,300 a month for the managed scenario and €6,000 in one-time migration costs, the 36-month figure is initially €52,800, before any additional variable expenses. The VM scenario, at €1,670 a month and with no assumed migration cost, totals €60,120. Both numbers remain hypothetical, and service scope and risk profiles must be genuinely comparable.

You can extend the model to include outage risk if probabilities and financial impact can be plausibly substantiated. Inventing an arbitrary “outage allowance” merely creates false precision.

5. Useful operational metrics

To manage costs over time, look beyond the total bill:

• Cost per customer or tenant: how does infrastructure spending change as the user base grows?
• Cost per 1,000 API requests: which services are disproportionately expensive?
• Cost per deployment or environment: what do preview, staging and test environments cost?
• Resource utilization: how much reserved CPU, RAM and storage capacity is actually consumed?
• Operations hours per application: how much work is spent on maintenance, failures and manual approvals?

The last two in particular reveal when a technically inexpensive platform becomes organizationally expensive.

6. Checklist before your next cloud decision

When requesting proposals or planning a migration, ask for written answers to these questions:

• What compute and storage capacity is included, and how much headroom is required?
• How are outbound traffic, cross-region transfers and load balancers billed?
• Are backups included, and is tested recovery part of the offering?
• Who handles operating system, cluster and security updates?
• Which monitoring, logging and alerting capabilities are included?
• What are the support hours, response channels and responsibilities?
• What availability targets are agreed, and which architecture supports them?
• How easily can data and workloads be exported when switching providers?
• Which one-time expenses and contractual terms apply to migration and exit?
• How do total costs change if demand doubles or another region is added?

7. What does this mean when choosing a cloud platform?

The right platform is not necessarily the one with the most features. It is the one whose technology and operating model fit the application's requirements—and whose lifetime costs remain understandable.

At ayedo, we therefore do not treat infrastructure as an isolated list of CPU, RAM and storage prices. What matters is the overall architecture: repeatable provisioning, clear responsibilities, an open technology stack and an operating model suited to the application. Whether VMs, Kubernetes or a managed service make sense can only be determined from the actual workload.

FAQ

Is managed hosting always cheaper than self-hosting?

No. Managed hosting reduces certain operational tasks but can carry higher service fees. Staff effort, existing automation, availability requirements and included services determine the outcome.

What time horizon is appropriate for comparing cloud costs?

Thirty-six months is often a useful planning horizon. For fast-changing products, revisit the model annually or quarterly because usage patterns and prices can change.

Should downtime costs be part of TCO?

Yes, when they can be modelled as substantiated expected risks. Show them separately rather than mixing them with certain monthly infrastructure expenses.

Which costs are most often forgotten?

Internal operations hours, outbound traffic, restore tests, additional environments, and the one-time costs of migration and exit.

Conclusion

Cloud costs become manageable not through a low server price but through transparency across the entire operation. Assessing compute, storage, networking, backups, security, staffing and migration together makes offers comparable and helps prevent later surprises.

The most important metric is not the price per VM but the cost of operating an application reliably.