Cloud backup costs are easy to estimate on day one and hard to predict by year three. The first invoice reflects a known quantity of data at a published price per gigabyte. Later invoices reflect retention that has accumulated, storage classes chosen for savings that carry conditions, and charges for requests and retrieval that did not appear in the original calculation. None of this is hidden. It is spread across several line items that each grow for their own reason.
This post goes through where cloud storage bills for backup grow, so the total can be forecast instead of discovered.
| Line item | What drives it | How it grows |
|---|---|---|
| Capacity | Gigabytes stored per month | With retention, change rate and data growth |
| Requests | Number of write, list and read operations | With job frequency and object count |
| Retrieval | Gigabytes read from colder storage classes | With every restore and health check |
| Minimum storage duration | Objects deleted or changed before the class minimum | With short retention or frequent merges |
| Egress | Gigabytes transferred out of the cloud | With large restores and migrations |
| Immutability overhead | Locked objects kept beyond logical retention | With the lock period and block generation settings |
The capacity line is the largest, and it rises even when production data is flat. Each backup adds changed blocks, and those blocks stay until their retention expires. Extending retention from 30 days to a year, or adding monthly and yearly restore points, increases stored volume without any change in what is being protected. Immutability adds to this. Objects under a lock cannot be removed until the lock expires, and backup software commonly extends locks in blocks of several days, so the stored volume runs ahead of the logical retention. Immutable retention and deleted jobs describes how locked data stays on the bill after the job that created it is gone.
Backup software writes data to object storage as many objects, often around a megabyte each. A repository of tens of terabytes contains tens of millions of them. Every write, every listing and every read is a billable request. The unit price is tiny, but synthetic operations, health checks and retention processing touch large numbers of objects on a schedule. On some tiers, requests become a visible share of the monthly total.
Lower-cost storage classes reduce the capacity line in exchange for retrieval fees and minimum storage durations, typically 30, 90 or 180 days. Backup data that is merged, moved or deleted before the minimum is billed as if it had stayed. A restore from a cold class incurs a per-gigabyte retrieval charge and, on archive tiers, a delay of hours before the data is readable. These classes suit long-term copies that are rarely touched. They suit active backup chains much less well.
Data transfer out of the cloud is charged per gigabyte by most large providers. In normal operation the amount is small, limited to occasional file restores. During a full-site recovery it is the entire protected data set, at the moment the organization has the least room for surprises. Estimating egress for a full-site restore shows how to put a number on that scenario in advance. The same charge applies when leaving a provider, which makes it a factor in any future migration.
A useful forecast models each line item separately. Capacity is projected from the daily change rate, the retention schedule and expected data growth. Requests are estimated from object counts and job schedules. Retrieval and egress are priced for two scenarios: a routine month and a full recovery. Minimum-duration charges are checked against how the backup software actually ages data out. The result is a range, and the upper end is the figure to budget against.
The comparison with on-premises storage should use the same scenarios. Pricing the recovery scenario for cloud and on-premises backup sets the two side by side.
None of this argues against cloud storage for backup in general. A small estate, a workload that already runs in the cloud or a third copy kept for geographic separation can be good fits. The cost profile works against it when the data set is large, retention is long and restores are expected to be fast and frequent, because each of those raises a different line of the bill.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. It provides the same S3 interface and Object Lock immutability that backup software uses with cloud storage, on hardware in the customer's own site. There are no per-request, retrieval or egress charges on data read back from it.
ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB and is used as a target for Veeam and other backup software. Some organizations use it as the primary backup target and keep a smaller cloud copy for off-site separation.
A practical first step is to take the last three cloud invoices and sort the backup-related charges into the six lines above. The split shows which driver is growing fastest, and that is usually enough to decide whether a setting needs changing, a storage class needs reviewing or the placement of the data deserves a wider look.