Amazon Elastic Block Store (EBS)

Name: Amazon Elastic Block Store (EBS)
Brand: Amazon Web Services (AWS)
Rating: 4.6 (160 reviews)

Leader

Official Global LinkedIn page for Amazon Web Services (AWS).

Est 2006|Valuation $2560B|9 Ref Customers

LinkedIn 10.9M|Website|Web traffic 1.1M|FTEs 148,001|HQ Seattle, Washington, US

MarketsCloud Infrastructure Providers (IaaS/PaaS)Cloud Infrastructure Providers (IaaS/PaaS)

Amazon Elastic Block Store (EBS) screenshot

Published Sep 23, 2026

01Common complaints

1) Requirement for cross-AZ single-disk semantics - EBS volumes are AZ-scoped; architectures that require a single disk to be attached concurrently across AZs should consider alternatives or application-level replication patterns. 2) Need for a shared file system across many instances/pods - EBS is block storage and is not a multi-writer shared filesystem; managed file systems (EFS, FSx) or other shared storage options are more appropriate. 3) Preference for simple, all-in pricing models - Because gp3 can bill separately for provisioned IOPS/throughput above baseline and snapshots incur separate charges, cost governance can be more complex than some alternatives that include I/O in the base price. 4) Limited operational maturity for Kubernetes storage management - CSI drivers, IAM permissions, and periodic driver upgrades introduce operational tasks that may be burdensome for teams seeking minimal storage operations; managed database or storage services may reduce operational overhead.

Deal disqualifiers (poor fit)

Requirements for multi-node shared filesystem semantics (consider EFS/FSx or other shared storage)
Primary need for object storage semantics and large-scale low-cost durability (consider S3)
Highly cost-sensitive buyers likely to overprovision capacity or performance without strict governance

Architectural limitations (core)

Availability Zone scoping: volumes are created in a specific AZ; this drives design complexity for HA and DR patterns.

Operational limitations often mentioned

Difficulty shrinking allocated volume size is a common operational limitation noted by users.

Kubernetes ecosystem limitations

CSI driver lifecycle and IAM integration can cause attach/mount issues; the driver has an active release cadence and a relatively short supported-versions window.

Reliability considerations

Historical high-profile outages exist; while not necessarily indicative of current operations, they are relevant to risk planning and architecture design.

02Why they buy

Capabilities commonly cited in vendor and customer materials

Snapshot-based backup, restore, and cloning workflows that integrate with AWS tooling
Ability to modify volume size and certain performance attributes without downtime for many workflows
A range of volume types spanning general-purpose to high-end, low-latency tiers (e.g., gp3 to io2 Block Express)

Areas where alternatives may be advantageous

Pricing models that include I/O in the base price (in some competitor offerings) can simplify cost predictability
Some platforms offer storage models or products that more directly address multi-zone replicated disks or shared multi-writer semantics

03Field reports

Review platform summary signals

- Gartner Peer Insights listing shows generally high ratings with positive themes such as snapshot functionality, ability to modify volume size without downtime, and reliability; negative themes include cost (particularly for high-performance tiers), complexity in matching performance to demand, and occasional performance variability. - PeerSpot shows favorable overall assessments and willingness-to-recommend indicators, with recurring concerns about cross-AZ access limitations, cost management, and scaling workflows. - TrustRadius review excerpts reference reliability and availability as strengths while noting latency and automation/connectivity as potential drawbacks.

Representative reviewer comments (paraphrased and balanced)

Positive: reviewers frequently cite snapshot capability and the ability to resize volumes without downtime as useful features that aid backup and maintenance workflows.
Negative: reviewers commonly report concerns about cost for high-performance volumes (e.g., io2), complexity in understanding and controlling provisioned IOPS/throughput billing, and limitations around AZ-scoped volumes for multi-node access patterns.

Why customers select EBS

Common drivers for choosing EBS include:

Integration with EC2 and AWS-native stacks
Familiar attach-a-disk model for VM workloads
Snapshot ecosystem for backup, restore, and cloning
Range of volume types for different performance and cost profiles

Why some customers avoid or leave EBS

Recurring reasons to select alternatives include:

Need for multi-AZ single-disk semantics (EBS is AZ-scoped)
Requirement for shared filesystem semantics (favoring EFS/FSx)
Cost sensitivity for high IOPS workloads
Preference for object storage or managed services to reduce block storage footprint

Vendor/official performance & cost comparison (gp3 vs io2 Block Express)

Vendor-published benchmarks indicate that io2 Block Express offers substantially higher maximum IOPS and throughput, lower latency targets, and higher claimed durability compared with gp3. Vendor examples also show that io2 Block Express can be materially more expensive per the vendor's chosen benchmark scenario. Critical evaluation: - Vendor benchmarks are informative for relative capabilities but are not independent. Results depend on workload shape, instance selection, IO size, queue depth, and tuning. Independent benchmarking is recommended for procurement decisions.

Historical reliability incident (multi-day outage, 2011)

Independent reporting documents a multi-day disruption that affected EBS/EC2/RDS in April 2011, with a small fraction of volumes impacted by inconsistent restoration.

Critical evaluation:

The incident is historical; AWS has since updated architecture and controls. Nonetheless, the event remains relevant as a risk-management lesson: designs should not assume single-AZ or single-region storage suffices for critical availability requirements.

04Best fit

Company sizes

Applicable to startups through large enterprises that operate on AWS.
Practical fit: organizations standardized on EC2/EKS that require predictable block storage semantics.

Industries / verticals

Reviewers and users frequently come from IT services, financial services, and general enterprise IT workloads.

Roles and personas

Cloud engineers, DevOps, SREs
Infrastructure/platform teams
Database administrators managing self-hosted databases on EC2

Pain points addressed

Persistent disk requirements for VMs
Snapshot-based backup and restore workflows
Incremental right-sizing of storage and performance over time (elastic volume modifications)

Qualification criteria (appropriate fit)

Organizations that run stateful workloads on EC2 (databases, message queues, applications requiring POSIX filesystem semantics on a block device)
Organizations that require snapshot-based backup/DR patterns
Organizations capable of designing HA across AZs rather than relying on a single-AZ volume

05The pitch

What the product does (core value proposition)

Amazon Elastic Block Store (Amazon EBS) is AWS’s managed network-attached block storage designed primarily for Amazon EC2 instances. It provides attachable volumes that behave like raw block devices (similar to a virtual hard disk), plus point-in-time snapshots for backup/restore and cloning workflows. Documentation describes EBS as suitable for low-latency storage needs such as filesystems and databases, with multiple volume types to trade off cost, throughput, latency, and durability. Key constructs: - EBS Volumes: persistent block devices attached to EC2 instances. - EBS Snapshots: point-in-time backups stored independently of volumes (used for DR, copying across regions/accounts, etc.).

Target market and market positioning

Target users: teams operating workloads on EC2/EKS (and services that depend on EBS under the hood, e.g., some database and compute stacks).
Positioning: the standard AWS block storage option commonly used for general-purpose VM storage, with higher-end tiers (io2 / io2 Block Express) available for latency- and IOPS-sensitive databases.

Get a comprehensive analysis of Amazon Elastic Block Store (EBS) including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

Published Sep 23, 2026

01Common complaints

Requirement for cross-AZ single-disk semantics

EBS volumes are AZ-scoped; architectures that require a single disk to be attached concurrently across AZs should consider alternatives or application-level replication patterns.

Need for a shared file system across many instances/pods

EBS is block storage and is not a multi-writer shared filesystem; managed file systems (EFS, FSx) or other shared storage options are more appropriate.

Preference for simple, all-in pricing models

Because gp3 can bill separately for provisioned IOPS/throughput above baseline and snapshots incur separate charges, cost governance can be more complex than some alternatives that include I/O in the base price.

Limited operational maturity for Kubernetes storage management

CSI drivers, IAM permissions, and periodic driver upgrades introduce operational tasks that may be burdensome for teams seeking minimal storage operations; managed database or storage services may reduce operational overhead.

Deal disqualifiers (poor fit)

Requirements for multi-node shared filesystem semantics (consider EFS/FSx or other shared storage)
Primary need for object storage semantics and large-scale low-cost durability (consider S3)
Highly cost-sensitive buyers likely to overprovision capacity or performance without strict governance

Architectural limitations (core)

Availability Zone scoping: volumes are created in a specific AZ; this drives design complexity for HA and DR patterns.

Operational limitations often mentioned

Difficulty shrinking allocated volume size is a common operational limitation noted by users.

Kubernetes ecosystem limitations

CSI driver lifecycle and IAM integration can cause attach/mount issues; the driver has an active release cadence and a relatively short supported-versions window.

Reliability considerations

Historical high-profile outages exist; while not necessarily indicative of current operations, they are relevant to risk planning and architecture design.

02Why they buy

Capabilities commonly cited in vendor and customer materials

Snapshot-based backup, restore, and cloning workflows that integrate with AWS tooling
Ability to modify volume size and certain performance attributes without downtime for many workflows
A range of volume types spanning general-purpose to high-end, low-latency tiers (e.g., gp3 to io2 Block Express)

Areas where alternatives may be advantageous

Pricing models that include I/O in the base price (in some competitor offerings) can simplify cost predictability
Some platforms offer storage models or products that more directly address multi-zone replicated disks or shared multi-writer semantics

03Field reports

Review platform summary signals

Gartner Peer Insights listing shows generally high ratings with positive themes such as snapshot functionality, ability to modify volume size without downtime, and reliability; negative themes include cost (particularly for high-performance tiers), complexity in matching performance to demand, and occasional performance variability.
PeerSpot shows favorable overall assessments and willingness-to-recommend indicators, with recurring concerns about cross-AZ access limitations, cost management, and scaling workflows.
TrustRadius review excerpts reference reliability and availability as strengths while noting latency and automation/connectivity as potential drawbacks.

Representative reviewer comments (paraphrased and balanced)

Positive: reviewers frequently cite snapshot capability and the ability to resize volumes without downtime as useful features that aid backup and maintenance workflows.
Negative: reviewers commonly report concerns about cost for high-performance volumes (e.g., io2), complexity in understanding and controlling provisioned IOPS/throughput billing, and limitations around AZ-scoped volumes for multi-node access patterns.

Why customers select EBS

Common drivers for choosing EBS include:

Integration with EC2 and AWS-native stacks
Familiar attach-a-disk model for VM workloads
Snapshot ecosystem for backup, restore, and cloning
Range of volume types for different performance and cost profiles

Why some customers avoid or leave EBS

Recurring reasons to select alternatives include:

Need for multi-AZ single-disk semantics (EBS is AZ-scoped)
Requirement for shared filesystem semantics (favoring EFS/FSx)
Cost sensitivity for high IOPS workloads
Preference for object storage or managed services to reduce block storage footprint

Vendor/official performance & cost comparison (gp3 vs io2 Block Express)

Critical evaluation:

Vendor benchmarks are informative for relative capabilities but are not independent. Results depend on workload shape, instance selection, IO size, queue depth, and tuning. Independent benchmarking is recommended for procurement decisions.

Historical reliability incident (multi-day outage, 2011)

Independent reporting documents a multi-day disruption that affected EBS/EC2/RDS in April 2011, with a small fraction of volumes impacted by inconsistent restoration.

Critical evaluation:

The incident is historical; AWS has since updated architecture and controls. Nonetheless, the event remains relevant as a risk-management lesson: designs should not assume single-AZ or single-region storage suffices for critical availability requirements.

04Best fit

Company sizes

Applicable to startups through large enterprises that operate on AWS.
Practical fit: organizations standardized on EC2/EKS that require predictable block storage semantics.

Industries / verticals

Reviewers and users frequently come from IT services, financial services, and general enterprise IT workloads.

Roles and personas

Cloud engineers, DevOps, SREs
Infrastructure/platform teams
Database administrators managing self-hosted databases on EC2

Pain points addressed

Persistent disk requirements for VMs
Snapshot-based backup and restore workflows
Incremental right-sizing of storage and performance over time (elastic volume modifications)

Qualification criteria (appropriate fit)

Organizations that run stateful workloads on EC2 (databases, message queues, applications requiring POSIX filesystem semantics on a block device)
Organizations that require snapshot-based backup/DR patterns
Organizations capable of designing HA across AZs rather than relying on a single-AZ volume

05The pitch

What the product does (core value proposition)

Key constructs:

EBS Volumes: persistent block devices attached to EC2 instances.
EBS Snapshots: point-in-time backups stored independently of volumes (used for DR, copying across regions/accounts, etc.).

Target market and market positioning

Target users: teams operating workloads on EC2/EKS (and services that depend on EBS under the hood, e.g., some database and compute stacks).
Positioning: the standard AWS block storage option commonly used for general-purpose VM storage, with higher-end tiers (io2 / io2 Block Express) available for latency- and IOPS-sensitive databases.

Get a comprehensive analysis of Amazon Elastic Block Store (EBS) including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →