- Newest
- Most votes
- Most comments
I don't know how large the 13 volumes are, but if the snapshots were previously stored with the same retention rules and amounted to 900 GB in your billing data, and then suddenly grew to 4300 GB without an apparent reason, then it sounds very much like there's constant churn on the disks.
EBS snapshots store the contents of the disk in blocks of 512 kiB, starting at the beginning of the disk, so changing just one byte in a block causes the whole 512-kiB block to be included in the next incremental snapshot. For example, if Ubuntu's swap file has started to get written to more actively than it used to be, either because of a change in behaviour in a newer Ubuntu version or due to increased use of physical memory by your applications, the maximum of 42 copies of the relatively small number of blocks constantly getting overwritten by the swap file could easily account for a massive increase in the amount of data stored in snapshots.
For incremental snapshots, you can see the amount of data included in incremental snapshots per day in your raw billing data (CUR, the Cost and Usage Report), or you can query the block data directly with the ListChangedBlocks EBS direct API: https://docs.aws.amazon.com/ebs/latest/userguide/readsnapshots.html#list-different-blocks. Note that using the EBS direct APIs is charged separately: https://docs.aws.amazon.com/ebs/latest/userguide/ebsapi-pricing.html.
For general cost tracking purposes, you might want to activate the "Name" tag for cost allocation in your AWS billing settings: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html, assign a "Name" tag on each of your EBS volumes, and make sure it gets propagated to the EBS snapshots. For example, AWS Backup supports propagating tags from volumes to snapshots and AMIs natively. For costs incurred after the tag is activated, you'll be able to use the standard Cost Explorer tool to track the EBS snapshot costs split by the Name tag, making it easy to see which volumes are contributing to the massively increased accumulation of changed snapshot blocks.
The issue you're experiencing with unexpectedly large "Full Snapshot Size" and rapidly escalating costs is likely related to a recent change in how Amazon EBS reports snapshot sizes. In February 2025, AWS introduced a new feature that displays the full snapshot size for EBS Snapshots in both the Console and API.
This new "Full snapshot size" field shows the total size of all blocks that make up a snapshot, including both the blocks stored directly in that snapshot and all blocks referenced from previous snapshots. This is different from the incremental snapshot size, which only refers to the size of newly changed blocks stored in that specific snapshot.
For example, if you have a 100 GB volume with 50 GB of data, the 'full snapshot size' would show 50 GB regardless of whether it's the first snapshot or a subsequent one. This explains why you're seeing sizes nearly equal to the full volume size, even for relatively new servers.
The sudden increase in your bill starting from November 2024 suggests that this change might have been gradually rolled out before the official announcement in February 2025. It's important to note that this change in reporting doesn't necessarily mean you're being charged more for storage; rather, it's providing a more comprehensive view of your snapshot sizes.
To troubleshoot and potentially reduce costs:
-
Use the DescribeSnapshots API with the new 'full-snapshot-size-in-bytes' field to get a detailed view of your snapshot sizes.
-
Review your snapshot retention policy. Keeping 42 snapshots per volume (24 hourly, 6 daily, and 12 weekly) might be more than necessary and could be contributing to higher costs.
-
Consider using Amazon EBS direct APIs to manage your snapshots more efficiently.
-
Use the AWS Cost Explorer to analyze your EBS snapshot costs over time and identify any unusual patterns.
-
If you're not actively using all the data on your volumes, consider reducing the volume sizes or cleaning up unnecessary data to reduce snapshot sizes.
-
Contact AWS Support for a detailed explanation of the charges and guidance on optimizing your snapshot strategy.
Remember, EBS snapshots are incremental backups, so subsequent snapshots only store the changed blocks. However, the "Full snapshot size" now shows the total size of all blocks that make up the snapshot, which can appear larger than expected.
Sources
Amazon Elastic Block Store (EBS) now adds full snapshot size information in Console and API - AWS
How Amazon EBS snapshots work - Amazon EBS
AWS Snapshot Billing Issue ? | AWS re:Post
This AI generated answer is poor and irrelevant. It explains why the implementation of the "Full Snapshot Size" column wouldn't affect cost while at the same time suggesting that it is the cause. It also points out that "if you have a 100 GB volume with 50 GB of data, the 'full snapshot size' would show 50 GB regardless of whether it's the first snapshot or a subsequent one" but in my case if I have a 100GB volume with 50GB of data, the Full Snapshot Size is reporting a value very close to 100GB, which should be impossible. I realize that I can't calculate billing from the Full Snapshot Size and I only mention the Full Snapshot Size because it seems to be a clue about the real problem which is that my costs have EXPLODED without any significant change in usage.
Relevant content
- asked 3 months ago
- asked a year ago
- asked 3 years ago
AWS OFFICIALUpdated 7 months ago
I don't think this explains why the "Full Snapshot Size" is close to the volume size on all volumes, as I understand that value is supposed to indicate the amount of data stored on the volume at the time the snapshot was taken, but you've provided excellent suggestions to continue to isolate the problem. It's possible the "Full Snapshot Size" was a red herring and churn is the issue. Thank you!
You're correct about that I didn't attempt to explain the value of the full snapshot size property, but it can be related to the churn on the disk. For example, if Ubuntu was previously configured to use a dedicated swap partition, the churn related to swapping would have been limited to the disk blocks allocated to the partition, regardless of how much swapping might have occurred. That would explain why most of the disk blocks were never used before. If Ubuntu was lated switched to using a swap file located on the /home partition, for example, the same amount of churn might have started to spread out across nearly all the blocks on the disk, depending on which disk blocks the file system happened to favour for allocating to the swap file. That would have caused the total number of different blocks on the disk to increase, quantified by the full snapshot size property. It's also possible that the churn has nothing to do with swapping at all, but that it might be temporary files used by an application, log files, or something entirely different that are causing the contents of data blocks to change all over the disk, despite not having done so previously.