Amazon EBS Pricing: Why Deleted EC2 Doesn't Stop Your Bill

Here's a scenario I see all the time on AWS re:Post: someone provisions an EC2 instance for a project, the project wraps up, they terminate the instance - and three months later they're still paying for EBS volumes they don't recognize.

The reason isn't a bug. It's how Amazon EBS pricing works by design. EBS charges you for the storage capacity you provision, from the moment you create a volume until you delete it - whether or not that volume is attached to a running instance, and whether or not you're actually using the storage. That one distinction explains the majority of unexpected EBS charges.

If you're here because you're planning a new workload and want to know what EBS will cost, this guide has the current 2026 pricing for all six volume types and a worked monthly cost example. If you're here because your bill came in higher than expected and you see "EC2-Other" charges you can't explain, the hidden costs section is where you want to go. You can also use our EBS pricing calculator to estimate costs for your specific configuration.

All prices shown are for US East (N. Virginia). EBS pricing varies by region - use the AWS EBS pricing page with your region selected to get exact figures for your workload.

What is Amazon EBS (and Why It Bills Differently Than You Expect)

Amazon Elastic Block Store (EBS) is block storage for EC2. Think of it like a physical hard drive attached to a server - it behaves the same way at the OS level, but it exists independently of the compute instance.

Two properties drive most billing surprises:

Volumes are AZ-scoped. An EBS volume lives in a specific Availability Zone and can only attach to EC2 instances in that same AZ. This matters for cost because you can't move a volume across AZs without snapshotting it - you create a new volume in the destination AZ, which starts its own billing clock.

Volumes persist independently of the EC2 instance. By default, when you terminate an EC2 instance, the root volume is deleted (DeleteOnTermination=true) but any additional volumes you attached remain. They sit there in "available" state, accruing charges at full provisioned rate, until someone deliberately deletes them.

This is the key difference from EC2 instance store, which is temporary storage local to the physical host. Instance store disappears when you stop or terminate an instance - and unlike EBS, it doesn't cost anything separately. If you've been billing your team for "server storage" and were thinking about instance store, you were thinking about the wrong thing.

EBS also supports Elastic Volumes, which lets you modify a volume's size, type, IOPS, and throughput on live instances without downtime. That's relevant for cost optimization because you can right-size without scheduling maintenance windows.

How EBS Pricing Works

Most AWS services charge for what you use. EBS charges for what you provision. That's the model. Once you internalize it, the bill makes sense - the confusion is that the mental model most people carry over from S3 and other consumption-based services doesn't apply here.

Provisioned vs. Used: The Core Billing Concept

AWS charges for the storage capacity you allocate, not the data you actually store. A 500 GB volume with 10 GB of files costs exactly the same as a 500 GB volume with 490 GB of files. It's closer to renting commercial space than buying a storage subscription - you pay for the square footage you reserve, whether or not you fill it.

This is the single most common confusion point on re:Post ("what does 'provisioned' mean for EBS pricing"). The quote from the AWS docs is direct: "Volume storage is charged by GB provisioned per month, from the time the volume is created until it is deleted."

Per-Second Billing and the 60-Second Minimum

EBS charges accrue in per-second increments, not per hour or per day. If you provision a volume for exactly one hour, you pay for 3,600 seconds out of 2,592,000 seconds in a 30-day month.

The billing formula is:

cost = (GB × $/GB-month) × (seconds_provisioned / 2,592,000)

From the official pricing page: a 2,000 GB gp3 volume running for 12 hours (43,200 seconds) costs $0.08 × 2,000 × (43,200 / 2,592,000) = $2.667 for storage alone.

One catch: there's a 60-second minimum. Create a volume and delete it immediately, and you're still billed for 60 seconds. This mostly shows up in CI/CD pipelines or test scripts that spin up and tear down volumes rapidly.

What the "EC2-Other" Line Item Actually Contains

Here's something that trips up nearly every team the first time they dig into Cost Explorer: EBS charges don't appear as a separate "EBS" line item. They show up under "EC2-Other."

EC2-Other includes:

• EBS volume storage (EBS:VolumeUsage)
• EBS snapshot storage (EBS:SnapshotUsage)
• EBS IOPS charges (EBS:VolumeP-IOPS.piops)
• EBS throughput charges
• Fast Snapshot Restore charges
• EBS data transfer

When teams see "EC2-Other has doubled this month," the culprit is almost always somewhere in that list. Drilling into Cost Explorer by "Usage Type" dimension shows the breakdown. Without that step, it's genuinely hard to pinpoint which component is growing.

EBS Volume Types and Pricing (2026)

There are six active EBS volume types across two categories: SSD and HDD. For most workloads, you'll pick from the SSD options. HDD volumes are for specific sequential-access scenarios.

Here's the full pricing picture before going deeper on each type:

All prices are us-east-1. Check the official EBS pricing page for your region - prices can be substantially higher in other regions.

General Purpose SSD: gp3 (Current Default)

gp3 is the right default for the vast majority of workloads. It's the cheapest SSD option at $0.08/GB-month, and it decouples IOPS and throughput from storage size - which is the key improvement over gp2.

What you get in the base price: 3,000 IOPS and 125 MiB/s throughput, both sustained (not burst). If your workload stays within those limits, you pay only for storage.

Additional charges kick in when you provision beyond the baseline:

• Additional IOPS: $0.005 per provisioned IOPS-month above 3,000
• Additional throughput: $0.06 per provisioned MiB/s-month above 125 MiB/s

Note: there's a discrepancy between the general-purpose product page ($0.04/MiB/s) and the pricing page example ($0.06/MiB/s). Treat the EBS pricing page as authoritative for your region - that's where billing is calculated from.

gp3 sustains provisioned performance indefinitely. No burst model, no I/O credit bucket to manage. For predictable-cost workloads, that's a meaningful operational simplification. Max 80,000 IOPS (requires a Nitro-based instance; non-Nitro caps at 32,000 IOPS). Size range: 1 GiB to 64 TiB.

General Purpose SSD: gp2 (Previous Generation)

gp2 charges $0.10/GB-month with I/O included - no separate IOPS charges. Simple pricing, but it has a structural problem that makes it expensive for a lot of workloads.

gp2 IOPS scales at 3 IOPS per GiB of provisioned storage, up to a maximum of 16,000 IOPS at 5,334 GiB. Smaller volumes get a burst to 3,000 IOPS via an I/O credit bucket, but sustained performance above 3,000 IOPS requires a large volume.

The cost trap: teams often provision large gp2 volumes not because they need the storage, but to get higher IOPS. A workload that needs 6,000 sustained IOPS on gp2 requires provisioning at least 2,000 GB - that's $200/month even if actual data fits in 100 GB. On gp3, the same performance costs $8 for 100 GB of storage plus $15 for 6,000 IOPS = $23/month. We'll work through the exact math in the cost calculation section.

AWS still supports gp2 and has no announced deprecation date, but recommends migrating to gp3. The console now defaults to gp3 for new volumes.

Provisioned IOPS SSD: io2 Block Express (Updated April 2025)

io2 Block Express is for workloads that genuinely need sub-millisecond latency, very high IOPS (beyond what gp3 can deliver at reasonable cost), or five-nines durability. Think Oracle, SAP HANA, SQL Server in production, IBM DB2. If that's not your workload, gp3 is almost certainly the right call.

Storage: $0.125/GB-month. IOPS charges are tiered per volume:

• Tier 1 (1-32,000 IOPS): $0.065/IOPS-month
• Tier 2 (32,001-64,000 IOPS): $0.046/IOPS-month
• Tier 3 (>64,000 IOPS, io2 Block Express only): lower rate (check the official pricing page - the exact Tier 3 rate was not enumerated in the documentation reviewed for this post)

Important: IOPS tiering is per-volume, not aggregated across your account. If you have 10 volumes at 1,000 IOPS each, each volume pays Tier 1 rates independently. There's no cross-volume discount.

A few details worth knowing:

• Durability: 99.999% (1 volume failure per 100,000 running volumes per year). The only EBS type at this tier.
• Supports Multi-Attach: one volume attached to up to 16 Nitro instances simultaneously in the same AZ. No additional charge.
• As of April 30, 2025, all existing io2 volumes automatically upgraded to io2 Block Express. No action was required, but the pricing model (tiered IOPS) now applies to all of them.
• Average latency under 500 microseconds for 16 KiB I/O on Nitro instances.

Provisioned IOPS SSD: io1

io1 is the previous generation at $0.125/GB-month storage and $0.065/IOPS-month flat (no tiers). Max 64,000 IOPS at a 50:1 IOPS:GiB ratio.

For new provisioning, io2 Block Express is the better option at equivalent cost - you get higher max IOPS (256,000 vs 64,000), better durability (99.999% vs 99.8%), and tiered IOPS pricing that can be cheaper at high provisioning. io1 remains available but there's no pricing advantage to choosing it.

HDD Volumes: st1 and sc1

Both HDD types include I/O in the per-GB price - no separate IOPS or throughput charges. They cannot be used as boot volumes and require a minimum size of 125 GiB.

st1 at $0.045/GB-month is for large sequential workloads accessed frequently: EMR clusters, ETL pipelines, log processing, data warehouses. Max 500 MiB/s throughput via a burst model similar to gp2. If your access pattern is large sequential reads and writes rather than random I/O, st1 delivers meaningful throughput at less than half the gp3 storage cost.

sc1 at $0.015/GB-month is the cheapest EBS option available. It's designed for infrequently accessed large sequential data - cold archives, compliance backups that need block storage rather than S3, anything where minimizing storage cost is the priority and you can tolerate lower throughput (max 250 MiB/s).

sc1 is cheaper than S3 Standard ($0.023/GB) per GB on paper, but they serve fundamentally different access patterns. If S3 works architecturally for your use case, it's almost always the right choice. sc1 is the cost floor when block storage is a requirement.

EBS Snapshot Pricing

Snapshots are how EBS does backups: point-in-time copies stored in S3, billed separately from your volumes. The pricing model has some nuance worth understanding before you set up a retention policy.

Snapshots are incremental. The first snapshot of a volume is a full copy. Every subsequent snapshot stores only the blocks that changed since the previous one. This means your snapshot storage bill reflects actual changed data, not provisioned volume size - a 500 GB volume with 20 GB of changed data costs $1/month in snapshots, not $25/month.

One thing that catches people: deleting a snapshot doesn't necessarily reduce costs. If a later snapshot references blocks from the deleted snapshot, those blocks are retained. The storage isn't freed until no remaining snapshot references those blocks.

Standard Snapshot Tier ($0.05/GB-month)

Standard tier is the default. $0.05/GB-month on actual data stored, replicated across multiple AZs automatically. Snapshots from another account shared with you don't incur charges until you copy them to your own account.

Cross-region snapshot copy incurs EC2 data transfer charges for the data moved between regions, plus standard snapshot storage charges in the destination region.

Snapshots are not deleted when you delete their parent volume, and they are not deleted when you terminate their EC2 instance. This is the most common source of silent snapshot accumulation. Without a lifecycle policy, every snapshot you've ever created is still there, billing at $0.05/GB-month. We'll cover AWS Data Lifecycle Manager in the optimization section - it's free and eliminates this problem.

For teams managing snapshots at scale, AWS Backup is an alternative to DLM that provides a centralized policy framework across multiple services.

Snapshot Archive Tier ($0.0125/GB-month) - When It Makes Sense

The archive tier stores a full (non-incremental) copy of the snapshot at 75% lower cost than standard. The trade-off: retrieval isn't instant.

• Archive storage: $0.0125/GB-month
• Retrieval fee: $0.03/GB (one-time when restoring from archive to standard)
• Minimum retention: 90 days. Delete or permanently restore before 90 days and you're charged for the remaining days.

Temporary restore leaves the snapshot in archive and bills for both tiers during the restore window. When it expires, billing reverts to archive only. That's useful for occasional access without the early deletion penalty.

The math for a 200 GB snapshot at 12 months retention: archive costs $30/year versus $120/year standard. If you restore once, add $6. Still $84 ahead. Break-even is clear for anything you're required to retain but are unlikely to ever need.

Archive is the wrong choice for snapshots you restore regularly. The retrieval fee adds up fast if you're pulling them monthly.

Fast Snapshot Restore: What It Costs and When to Enable It

By default, creating a volume from a snapshot involves lazy-loading blocks from S3. The volume is immediately available, but I/O latency is higher than normal until all blocks are fetched locally. For most single-volume restores, this initialization period is acceptable.

Fast Snapshot Restore (FSR) pre-warms volumes so they're fully performant the moment they're created. The charge: $0.75/DSU-hour, billed per minute with a one-hour minimum. One DSU = one snapshot in one Availability Zone.

The cost trap: FSR charges from the moment you enable it, regardless of whether you create any volumes from that snapshot. Enable FSR on 3 snapshots across 2 AZs and you're paying $4.50/hour continuously until you disable it.

Example: 1 snapshot in 3 AZs, enabled for 90 minutes = 1 × 3 × 1.5 DSU-hours × $0.75 = $3.375.

Check whether FSR is active in your account:

aws ec2 describe-fast-snapshot-restores

Enable FSR for DR scenarios or pre-production environments where you need volumes to be immediately performant at scale. For typical single-volume restores, the initialization period is cheaper than ongoing FSR charges.

Cross-Region Snapshot Copy Charges

Copying a snapshot to another region: EC2 data transfer charges for the data moved, plus standard snapshot storage in the destination region. Time-based Snapshot Copy adds a premium for guaranteed completion within a specified window: $0.016/GB for 1-hour, $0.014/GB for 3-hour, $0.010/GB for 8-hour completion. Use this when your DR plan requires a specific RTO for snapshot availability in another region.

Advanced Data Services Pricing

Beyond volumes and snapshots, EBS has a set of data services with their own pricing models. Most teams won't encounter these unless they're running automated backup tooling, Kubernetes workloads, or specific DR configurations - but they're worth knowing because charges can accumulate if these features are enabled and forgotten.

All prices below are us-east-1.

Volume Clones (New - GA October 2025)

Volume Clones is the most recent addition to EBS, reaching general availability in October 2025. It creates an instant point-in-time copy of an EBS volume within the same AZ - the copied volume is available within seconds.

The charge model is a one-time fee: $0.00080 per GB of written blocks on the source volume at clone creation. Written blocks, not provisioned size - so a 1,000 GB volume with 600 GB of actual data costs $0.48 to clone. After that, the clone incurs standard EBS volume charges until you delete it.

During background copy completion, the clone's performance is limited to the lower of: the source's provisioned performance, the clone's provisioned performance, or 3,000 IOPS / 125 MiB/s baseline.

Volume Clones are accessible via Console, CLI, SDKs, CloudFormation, and the EBS CSI driver for Kubernetes workloads. They work with all EBS volume types.

One distinction worth making: Volume Clones don't replace snapshots. Snapshots are S3-backed incremental backups with 11 nines of durability. Clones have EBS volume-level durability. Use clones for test environments, CI/CD pipelines, and fast pre-production environment setup. Use snapshots for backup and recovery.

EBS Direct APIs for Snapshots

The EBS Direct APIs let backup software and migration tools read and write EBS snapshot data at the block level, without mounting a volume. Most teams won't interact with these directly, but if your backup vendor uses them (many do), the charges appear in your bill.

• ListChangedBlocks and ListSnapshotBlocks: $0.0006 per 1,000 requests
• GetSnapshotBlock: $0.003 per 1,000 SnapshotAPIUnits (1 unit = 1 API call for a 512 KiB block)
• PutSnapshotBlock: $0.006 per 1,000 SnapshotAPIUnits

Cross-region data transfers add EC2 transfer charges on top.

Time-Based Snapshot Copy

Standard snapshot copy has no guaranteed completion time. Time-based Snapshot Copy guarantees completion within a specified window, at a premium:

• 1-hour completion: $0.016/GB
• 3-hour completion: $0.014/GB
• 8-hour completion: $0.010/GB

Cross-region data transfer charges apply on top of these. Use this when your DR plan has a specific RTO requirement for snapshot availability in a second region.

Real-World EBS Cost Calculation

Let's put the numbers together into something you can use as a sanity check against your own bill. Two scenarios: a typical web application setup, and a gp2-vs-gp3 comparison that shows exactly how much the migration saves.

Sample Scenario: Web Application with Boot Volume, Data Volume, and Snapshots

Setup: one 50 GB gp3 boot volume, one 500 GB gp3 data volume (no additional IOPS or throughput provisioned - staying within the 3,000 IOPS and 125 MiB/s baseline), daily snapshots retaining 200 GB total after deduplication. Full 30-day month in us-east-1.

The snapshot line is worth calling out. $10/month on a $44/month storage base is 22% overhead. Teams routinely budget for the volume storage and forget snapshots entirely, then wonder why the actual bill is higher than the estimate.

gp2 vs gp3 at 1 TB: The Migration Savings in Dollars

A 1 TB volume running continuously for a full month. Three configurations:

gp3 at the same 1 TB size saves $20/month, $240/year. Better performance (sustained vs burst), lower cost.

The more interesting comparison is the third row. A workload that needs 6,000 sustained IOPS on gp2 has to provision a 2,000 GB volume (because gp2 scales at 3 IOPS/GiB, so 6,000 IOPS requires 2,000 GB). That's $200/month even if actual data fits in 100 GB. On gp3, you provision 1 TB of storage at $80 plus 6,000 IOPS at $15 = $95/month - $105/month cheaper for identical performance. The gp3 vs gp2 cost gap widens even further if your data actually fits in 100 GB: $8 storage + $15 IOPS = $23/month versus $200/month on gp2 for the same 6,000 IOPS.

Migrating is a live operation - no downtime required, thanks to Elastic Volumes:

aws ec2 modify-volume \
  --volume-id vol-xxxxxxxxxxxxxxxxx \
  --volume-type gp3 \
  --iops 3000 \
  --throughput 125

Set --iops and --throughput to match your workload's actual requirements. If you're unsure, check CloudWatch metrics (VolumeReadOps, VolumeWriteOps) before migrating. The AWS Well-Architected Framework rates not performing this migration as a medium-risk finding.

Hidden EBS Costs That Inflate Your Bill

This section covers the five patterns I see most often in accounts where the EBS bill is higher than the team expects. None of these are bugs - they're how EBS works. The goal is to make the behavior visible so you can make deliberate choices.

EBS Volumes Keep Billing When Your EC2 Instance Is Stopped

Stopping an EC2 instance stops the per-hour compute charge. It does not stop the EBS volume charges. Every attached volume continues to accrue charges at the full provisioned rate.

This catches teams that stop instances overnight or on weekends to save on compute costs. The EC2 line item drops, but the EBS line item in EC2-Other continues unchanged.

The only way to stop EBS billing is to delete the volume. If you need to preserve the data, take a snapshot first (one-time cost, ongoing $0.05/GB-month) and delete the volume. Restoring from a snapshot when you need the instance again takes a few minutes.

To find volumes attached to stopped instances:

aws ec2 describe-volumes \
  --filters Name=status,Values=in-use \
  --query 'Volumes[?Attachments[?State==`attached`]].{ID:VolumeId,Size:Size,Instance:Attachments[0].InstanceId}'

Snapshots Are Not Deleted When You Terminate an Instance

When you terminate an EC2 instance, the root volume is deleted by default. Non-root volumes are not. And snapshots - regardless of which volume they came from - are never automatically deleted. They accumulate indefinitely.

In practice this means: an account that's been running for two years and has been creating daily snapshots without a lifecycle policy has potentially years of snapshots accruing at $0.05/GB-month each. I've seen accounts where snapshot storage costs exceeded volume storage costs by 3x.

Check your snapshot inventory:

aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[*].{ID:SnapshotId,Size:VolumeSize,Started:StartTime,Desc:Description}' \
  --output table

Sort by start time and look for anything older than your intended retention window.

Orphaned Volumes from Auto Scaling Group Scale-Ins

When an Auto Scaling group terminates an instance during scale-in, the default behavior for non-root volumes is to leave them behind. Over time, especially in environments with aggressive scaling, this creates a pool of unattached volumes billing at full rate with no instance to justify them.

Find unattached volumes (status "available" = detached and billing):

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType,Created:CreateTime}'

Fix this going forward by setting DeleteOnTermination=true in your launch templates for all volumes, not just the root:

aws ec2 modify-instance-attribute \
  --instance-id i-xxxxxxxxxxxxxxxxx \
  --block-device-mappings '[{"DeviceName":"/dev/sdf","Ebs":{"DeleteOnTermination":true}}]'

The 60-Second Minimum Charge and Per-Second Billing Gotcha

Any volume that exists for less than 60 seconds is still billed for 60 seconds. This matters most for automated workflows - CI/CD pipelines, test infrastructure scripts, or anything that creates and deletes volumes programmatically.

It also applies to IOPS modifications: if you modify a volume's IOPS provisioning and revert within 60 seconds, both configurations incur their minimum charge. Don't spin up io2 volumes with 10,000 IOPS to test something and immediately drop them back.

Fast Snapshot Restore Accrues Charges Even With No Volume Creation

FSR charges start the moment you enable it on a snapshot/AZ combination. If your team enabled FSR for a DR drill and didn't disable it afterward, those charges are running continuously.

Check for active FSR configurations:

aws ec2 describe-fast-snapshot-restores \
  --query 'FastSnapshotRestores[?State==`enabled`].{Snapshot:SnapshotId,AZ:AvailabilityZone}'

Disable any FSR configuration you don't have an active operational need for:

aws ec2 disable-fast-snapshot-restores \
  --availability-zones us-east-1a \
  --source-snapshot-ids snap-xxxxxxxxxxxxxxxxx

How to Reduce Your EBS Bill

These are the four highest-ROI EBS cost optimization levers, listed roughly by implementation effort.

Migrate gp2 Volumes to gp3

This is the highest-ROI action for most accounts. The math is already in the cost calculation section - minimum 20% savings per GB with zero application changes and no downtime. The only reason to delay is if you have gp2 volumes sized specifically for their IOPS characteristics and haven't verified the equivalent gp3 configuration will meet your workload's needs.

Start by inventorying your gp2 volumes:

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,State:State,IOPS:Iops}'

Before migrating production volumes, check CloudWatch metrics for VolumeReadOps and VolumeWriteOps to understand actual IOPS demand. Then migrate:

aws ec2 modify-volume \
  --volume-id vol-xxxxxxxxxxxxxxxxx \
  --volume-type gp3 \
  --iops 3000 \
  --throughput 125

AWS provides a gp2-to-gp3 migration cost savings calculator (Excel download) for quantifying savings across your entire fleet before committing. The AWS Well-Architected Framework rates skipping this migration as medium risk.

Archive or Delete Unused Snapshots with AWS Data Lifecycle Manager

AWS Data Lifecycle Manager (DLM) automates snapshot creation, retention, and lifecycle transitions. It's free. If you don't have a DLM policy in place, set one up before your next billing cycle.

For snapshots that need to be retained for compliance but are unlikely to be restored, move them to archive tier at $0.0125/GB-month (75% cheaper than standard). The 90-day minimum retention requirement makes this a good fit for anything with a quarterly or longer retention window.

Tag snapshots at creation with owner, environment, and expiry date. Without tags, lifecycle decisions at scale become a manual exercise. With tags, DLM can apply rules automatically.

Find and Delete Unattached Volumes

Every unattached volume is dead weight. Run the describe-volumes --filters Name=status,Values=available command from the hidden costs section, review the list, take a final snapshot of anything you're not sure about, then delete.

After cleanup, prevent future accumulation by setting up an AWS Config rule or EventBridge trigger on volume detachment events to alert your team. Manual audits drift. Automated alerts don't.

Right-Size io1 and io2 Volumes

io1 and io2 volumes charge per provisioned IOPS regardless of how many you actually use. If you provisioned for peak traffic that happens 5% of the time, you're paying for peak IOPS 100% of the time.

Use CloudWatch metric VolumeConsumedReadWriteOps to measure actual P99 IOPS over at least two weeks. If provisioned IOPS consistently exceed actual usage by more than 50%, reduce the provisioning using Elastic Volumes (up to four modifications per 24-hour rolling period):

aws ec2 modify-volume \
  --volume-id vol-xxxxxxxxxxxxxxxxx \
  --iops 5000

One caveat: EBS volume size cannot be decreased - only increased. Plan initial sizing conservatively and grow as needed. The right-sizing opportunity is on IOPS provisioning, not storage size.

AWS Free Tier for EBS (2026)

The legacy Free Tier for EBS includes 30 GB of storage, 2 million I/Os, and 1 GB of snapshot storage per month for the first 12 months after account creation.

Starting July 15, 2025, new AWS customers also receive up to $200 in Free Tier credits applicable to eligible AWS charges (including EBS). The free plan is available for the first 6 months after account creation; the $200 credits are valid for 12 months.

If you're evaluating AWS for the first time or setting up a new account for a development environment, the $200 credits provide meaningful runway before real EBS snapshot cost and volume charges start.

EBS vs EFS vs S3: Which Is Actually Cheapest?

The price gap between these services is real, but they're not substitutable. The right comparison is access pattern first, price second.

On raw price per GB, S3 is cheapest and EFS is most expensive. But EFS charges for actual data stored (not provisioned), scales automatically, and can be mounted by multiple EC2 instances across AZs simultaneously. For shared file storage, EFS is the right tool. For single-instance block storage with random I/O, EBS is the right tool.

S3 is object storage. You cannot mount it as a filesystem or use it as a boot volume. It's cheaper per GB for large datasets you access via API, not for the block storage role that EBS fills.

The question isn't which service is cheapest - it's which service fits your access pattern. For detailed pricing on the other services, see our Amazon EFS pricing guide and Amazon S3 pricing guide.

Frequently Asked Questions

Conclusion

A few things worth keeping in mind before you close this tab:

EBS bills for provisioned storage from creation to deletion, not for the data you actually store. That distinction explains most surprise bills. A 500 GB volume with 5 GB of data costs the same as a 500 GB volume that's full.

gp3 is the right default for most workloads. If you have gp2 volumes running, migration is a zero-downtime operation with guaranteed savings - minimum 20% per GB, often much more for volumes that were sized for IOPS rather than storage.

Snapshots don't go away on their own. Without a DLM lifecycle policy, snapshot storage compounds indefinitely. The fix is a one-time setup that costs nothing.

The hidden cost patterns (stopped-instance volumes, orphaned ASG volumes, forgotten FSR configurations) account for the bulk of unexplained EC2-Other charges. They're not edge cases - they're standard AWS behavior that most teams don't fully account for.

Volume Clones (GA October 2025) and the Snapshot Archive tier are capabilities worth evaluating if your team manages test environments or long-term snapshot retention. Clones at $0.00080/GB of written blocks replace the old snapshot-and-restore workflow for test data. Archive at $0.0125/GB-month cuts retention costs by 75%.

The two commands worth running in your account today:

# Find unattached volumes that are billing with no active purpose
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType,Created:CreateTime}'

# Find gp2 volumes ready to migrate
aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 --query 'Volumes[*].{ID:VolumeId,Size:Size,State:State}'

Those two queries will show you the immediate cost reduction opportunities in your current EBS footprint. For a full Amazon EBS pricing estimate tailored to your workload, try our EBS pricing calculator. For context on the full EC2 EBS pricing picture, see our Amazon EC2 pricing guide.

If you're seeing EBS charges you can't explain - especially in the EC2-Other line item - drop a question in the comments. I've likely seen the pattern before.