Cloud Knowledge

Your Go-To Hub for Cloud Solutions & Insights

Advertisement
AWS

Amazon EBS explained: types, performance, snapshots, encryption, multi-attach, cost, and scripts to troubleshoot quickly

Shivam Tiwari 0
Amazon EBS explained: types, performance, snapshots, encryption, multi-attach, cost, and scripts to troubleshoot quickly

Amazon EBS (Elastic Block Store): The Definitive Guide to Persistent Block Storage for EC2

Learn Amazon EBS volume types, sizing, performance tuning, snapshots, encryption, Multi-Attach, and end-to-end troubleshooting with PowerShell & AWS CLI.

Amazon EBS (Elastic Block Store) is AWS’s persistent block storage service for Amazon EC2. It delivers low-latency volumes for databases, enterprise applications, and boot devices, with durability features like in-AZ replication, snapshots to Amazon S3, and enterprise-grade encryption. This guide combines architecture, design patterns, cost optimization, and hands-on Troubleshooting Playbooks using AWS CLI and PowerShell.

We’ll also cover EBS Multi-Attach, cross-Region backups, Elastic Volumes for online resizing and performance tuning, and Data Lifecycle Manager (DLM) to automate snapshots. Whether you’re running MySQL, Oracle, SQL Server, or containerized workloads, this article helps you design for performance, availability, and cost efficiency.

Definition: Amazon EBS provides persistent block storage for EC2 instances, enabling data to persist independently of instances through re-attach, snapshots, and cross-account/Region copy.

Key Points

  • Block-level storage with low latency and consistent IOPS/throughput for critical workloads.
  • Data persistence independent of EC2 lifecycle; ideal for boot volumes and databases.
  • Automated in-AZ replication for durability; designed for 99.999% availability.
  • Volume types: gp3/gp2, io2/io1, st1, sc1 to match performance vs cost.
  • Elastic Volumes enable live resize (size/IOPS/throughput) with minimal disruption.
  • Snapshots are incremental and stored in S3; support cross-Region/account copy.
  • End-to-end encryption with AWS KMS; in-transit and at-rest supported.
  • Integrates with AWS Backup, CloudWatch, and CloudFormation.
  • Multi-Attach for io1/io2 supports concurrent attachment to multiple instances (clustered filesystems).
  • Lifecycle automation with DLM; strong fit for DR and compliance.

EBS Volume Types: Choose the Right Performance Profile

EBS offers multiple volume types optimized for different workloads and budgets. Selecting the right type is crucial for balancing performance and cost.

1) General Purpose SSD (gp3, gp2)

gp3 decouples storage size from IOPS/throughput, letting you independently provision performance—a big step forward from gp2, which scales IOPS linearly with size. Use gp3 for boot volumes, general databases, and application servers requiring predictable latency.

  • gp3: baseline IOPS with configurable up to high IOPS and throughput per volume.
  • gp2: legacy option; consider migrating to gp3 for lower cost per GB and flexible performance.

2) Provisioned IOPS SSD (io2, io1)

For mission-critical databases (e.g., Oracle, SAP HANA, SQL Server), choose io2 for sustained, high IOPS with low latency. io2 also supports Multi-Attach and higher durability targets than io1.

3) Throughput Optimized HDD (st1)

Optimized for streaming, large block sequential IO—data lakes, ETL, and big file processing. Not ideal for random IO or small database pages.

4) Cold HDD (sc1)

The lowest-cost HDD option for colder, infrequently accessed datasets where throughput matters more than latency.

Key Points

  • Prefer gp3 for most general workloads; io2 for latency-sensitive databases.
  • st1/sc1 reduce $/GB but trade off random IO performance—avoid for OLTP.
  • Always validate device queue depth and filesystem alignment to realize provisioned IOPS.
  • Use CloudWatch metrics (VolumeReadOps, VolumeWriteOps, VolumeQueueLength).
  • Enable ENA and latest Nitro drivers on EC2 for best storage networking paths.

FAQs (Volume Types)

  1. When should I pick gp3 vs io2? gp3 for general workloads; io2 for consistent low latency & high IOPS databases.
  2. Is gp2 still okay? Yes, but gp3 offers better price/perf and independent IOPS/throughput control.
  3. Can I switch types live? Yes, use Elastic Volumes to modify type with minimal impact.
  4. Are HDD types good for DBs? Usually no—HDDs struggle with random IO; prefer SSD types.
  5. Do st1/sc1 support boot volumes? No—use SSDs (gp3/gp2) for root devices.
  6. Is Multi-Attach supported on gp3? No—Multi-Attach is for specific io1/io2 volumes.
  7. How to estimate IOPS? Start from workload telemetry (IO size, queue depth) and benchmark with FIO.
  8. What’s the maximum throughput? Depends on type and size; validate per-volume limits and EC2 instance caps.
  9. Do IOPS scale with size on gp3? No—gp3 decouples performance from capacity.
  10. Is io2 Block Express required? For ultra-high IOPS/throughput; confirm instance compatibility.

Persistence, Replication, and Availability

EBS volumes are persistent and survive instance stop/start. Data remains until the volume is deleted. Within an AZ, EBS automatically replicates data across multiple hardware components for durability. For multi-AZ or cross-Region strategies, rely on snapshots, AWS Backup, or application-level replication.

Key Points

  • In-AZ replication provides hardware fault tolerance—not multi-AZ quorum.
  • For HA databases, use engine-native replication or Multi-AZ services (e.g., RDS Multi-AZ).
  • Snapshots are incremental; restore as new volumes in any Region/account for DR.
  • Tag volumes and snapshots for governance and cost showback.
  • Use DLM or AWS Backup to enforce retention (e.g., 35 days, monthly, yearly).

FAQs (Persistence & HA)

  1. Does EBS replicate across AZs? No—replication is within a single AZ.
  2. How do I do cross-AZ protection? Use snapshots or application replication.
  3. Can I auto-copy snapshots to another Region? Yes—use AWS Backup or custom snapshot copy jobs.
  4. Are snapshots crash-consistent? Yes at volume level; for app-consistent, quiesce the application first.
  5. What about consistency for striped RAID sets? Use Multi-volume snapshots or shut down IO.
  6. How quickly can I recover? Fast—volumes become available immediately while data is lazy-loaded.
  7. Can I restore to bigger volumes? Yes—expand size and filesystem afterward.
  8. Can I attach the same volume to two instances? Only with Multi-Attach on io1/io2 and a cluster-aware filesystem.
  9. How do I avoid data loss on terminate? Disable “DeleteOnTermination” for critical volumes.
  10. Is 99.999% availability guaranteed? EBS is designed for high availability; architect app-level HA too.

Elastic Volumes, IOPS, and Throughput Tuning

Elastic Volumes lets you adjust size, IOPS, and throughput for supported volume types (gp3, io1/io2) on the fly. Combine with OS-level steps (partition resize, filesystem grow) to scale capacity without downtime.

Linux quick steps (example):
  1. Modify volume (size/IOPS/throughput) using AWS CLI or Console.
  2. Run lsblk to confirm device; then sudo growpart /dev/nvme0n1 1 (if partitioned with GPT).
  3. Run sudo resize2fs /dev/nvme0n1p1 (ext4) or xfs_growfs / for XFS to grow filesystem.

PowerShell (AWS Tools) – Modify EBS Volume (Elastic Volumes)

# Requires AWS.Tools.EC2
# Install-Module AWS.Tools.EC2 -Scope CurrentUser
$VolumeId = "vol-0123456789abcdef0"
# Example: switch to gp3, 6000 IOPS, 500 MiB/s throughput, 1024 GiB size
Edit-EC2Volume -VolumeId $VolumeId -VolumeType "gp3" -Iops 6000 -Throughput 500 -Size 1024

# Track modification progress
Get-EC2VolumeModification -VolumeId $VolumeId | Format-List

AWS CLI – Modify EBS Volume

VOL="vol-0123456789abcdef0"
aws ec2 modify-volume \
  --volume-id $VOL \
  --volume-type gp3 \
  --iops 6000 \
  --throughput 500 \
  --size 1024

aws ec2 describe-volumes-modifications --volume-id $VOL

Key Points

  • Always baseline with iostat/perfmon/CloudWatch to avoid blind over-provisioning.
  • Validate EC2 instance EBS bandwidth caps; storage-optimized instances can raise ceilings.
  • Tune IO size (e.g., 16–256 KiB) to match workload; leverage multiple queues (NVMe).
  • Use RAID 0 across multiple EBS volumes to scale throughput for sequential workloads; snapshot as a multi-volume set.
  • Ensure up-to-date NVMe and ENA drivers for Nitro-based instances.

FAQs (Performance & Elastic Volumes)

  1. Will modifying a volume cause downtime? Typically no; filesystem grow is online for most modern FS.
  2. How do I know if I’m IO-bound? High queue length & IO wait; compare to instance EBS bandwidth limits.
  3. What impacts latency most? Volume type, instance family, queue depth, IO size, and kernel/drivers.
  4. Should I use RAID 0? Yes for throughput; but add snapshot discipline and app-level HA.
  5. Is burst credit still a thing? For some types; watch CloudWatch burst balance (gp2).
  6. How fast do changes apply? Seconds to minutes; verify with DescribeVolumesModifications.
  7. Can I shrink a volume? Not directly—create a smaller snapshot/volume and migrate data.
  8. Do I need to stop the instance? Not for most Elastic Volume changes; check OS requirements.
  9. Are there filesystem limits? Yes—XFS/ext4/NTFS have max size; plan partition layout accordingly.
  10. Can I script everything? Yes—use AWS CLI, CloudFormation, or Terraform.

Snapshots, Cross-Region Copy, and Fast Restore

EBS snapshots are incremental point-in-time backups stored in S3. They enable quick restore to a new volume, cross-Region protection, and cross-account sharing for multi-tenant patterns.

PowerShell – Create, Tag, and Copy Snapshots

# Create a snapshot and tag it
$VolId = "vol-0123456789abcdef0"
$snap = New-EC2Snapshot -VolumeId $VolId -Description "Nightly backup"
New-EC2Tag -Resource $snap.SnapshotId -Tag @{ Key="Purpose"; Value="NightlyBackup" }

# Copy to another Region (example: from ap-south-1 to eu-west-1)
Copy-EC2Snapshot -SourceRegion "ap-south-1" -SourceSnapshotId $snap.SnapshotId -Description "DR copy" -DestinationRegion "eu-west-1"

AWS CLI – Snapshot Lifecycle

VOL="vol-0123456789abcdef0"
SNAP=$(aws ec2 create-snapshot --volume-id $VOL --description "Nightly backup" --query SnapshotId --output text)
aws ec2 create-tags --resources $SNAP --tags Key=Purpose,Value=NightlyBackup

# Cross-Region copy
aws ec2 copy-snapshot --source-region ap-south-1 --source-snapshot-id $SNAP --description "DR copy" --destination-region eu-west-1

# Restore to a new volume
aws ec2 create-volume --availability-zone ap-south-1a --snapshot-id $SNAP --volume-type gp3

Key Points

  • Snapshots are space-efficient; only changed blocks are stored after the first full.
  • Use Fast Snapshot Restore (FSR) for production RTO; pre-warm restored volumes.
  • Encrypt snapshots; copies retain or re-encrypt with a different KMS key as needed.
  • Use DLM or AWS Backup for policy-based automation.
  • Share snapshots with other accounts via permissions, then create a volume there.

FAQs (Snapshots)

  1. Are snapshots application-consistent? Crash-consistent by default; use pre-freeze scripts for app consistency.
  2. Can I schedule snapshots? Yes—via DLM or AWS Backup with retention policies.
  3. Do I pay twice for encrypted snapshots? You pay for snapshot storage; KMS usage billed separately.
  4. Can I copy encrypted snapshots to other accounts? Yes, with the right KMS key policy & grants.
  5. How to reduce snapshot costs? Enforce retention, prune or consolidate using DLM.
  6. Is restore instant? Usable immediately; data lazily loads—enable FSR for consistent low latency.
  7. Can I restore to bigger types? Yes—choose new type/size on create-volume from snapshot.
  8. How do I verify restore integrity? Mount read-only, run checksums, and application validation tests.
  9. What about multi-volume apps? Use multi-volume snapshots for consistency across striped sets.
  10. Do snapshots impact live IO? Minimal; still schedule off-peak for busy volumes.

Security & Encryption: At Rest and In Transit

EBS supports encryption at rest using AWS KMS CMKs and encryption in transit between EC2 and EBS. You can enforce encryption by default at the Region level.

PowerShell – Create Encrypted Volume and Encrypted Snapshot Copy

$Az = "ap-south-1a"
$KmsKey = "arn:aws:kms:ap-south-1:111122223333:key/abcd-1234-efgh-5678"
New-EC2Volume -AvailabilityZone $Az -Size 200 -VolumeType "gp3" -Encrypted $true -KmsKeyId $KmsKey

# Re-encrypt a snapshot copy with a new CMK
$SrcSnap = "snap-0123456789abcdef0"
Copy-EC2Snapshot -SourceRegion "ap-south-1" -SourceSnapshotId $SrcSnap -Encrypted $true -KmsKeyId $KmsKey -DestinationRegion "eu-west-1"

Key Points

  • Turn on “Encrypt new EBS volumes by default” at Region level.
  • Use separate CMKs per environment (Prod/Non-Prod) and least-privilege IAM policies.
  • Rotation and key policy hygiene are essential for compliance.
  • Copying an encrypted snapshot can re-encrypt with a different CMK for cross-account sharing.
  • Monitor KMS errors and throttling; they can affect volume attach/creation.

FAQs (Security & Encryption)

  1. Does encryption impact performance? Minimal on Nitro instances; generally negligible for most workloads.
  2. Can I encrypt an unencrypted volume? Create encrypted snapshot, then restore to encrypted volume.
  3. Do I need to manage keys? Yes—CMK policies, grants, and rotation must be maintained.
  4. Is in-transit encryption automatic? Yes between EC2 and EBS on supported platforms.
  5. Can I enforce encryption by default? Yes—enable per-Region setting.
  6. What about cross-account encrypted restores? Ensure KMS sharing and IAM permissions.
  7. Are snapshots encrypted when volumes are? Yes—encryption status propagates.
  8. Can I use different keys per app? Yes—for isolation and blast radius reduction.
  9. How do I audit encryption? Use CloudTrail for KMS operations and periodic config compliance checks.
  10. What if a key is disabled? Volume/snapshot operations using that key will fail—monitor proactively.

EBS Multi-Attach for io1/io2: Cluster-Aware Filesystems Only

Multi-Attach allows a single io1/io2 volume to be attached to multiple instances in the same AZ. Use only with cluster-aware filesystems (e.g., OCFS2, clustered XFS configurations, or proprietary cluster FS in apps). Do not mount the same block device read-write on two hosts with standard ext4/NTFS—risk of corruption is high.

PowerShell – Create and Attach Multi-Attach Volume

# Create io2 volume that supports Multi-Attach (ensure size/IOPS meet requirements)
$Az = "ap-south-1a"
$vol = New-EC2Volume -AvailabilityZone $Az -Size 1000 -VolumeType "io2" -Iops 16000 -MultiAttachEnabled $true

# Attach to two instances (example)
$VolumeId = $vol.VolumeId
$InstanceA = "i-0aaa111bbb222ccc3"
$InstanceB = "i-0ddd444eee555fff6"
Add-EC2Volume -VolumeId $VolumeId -InstanceId $InstanceA -Device "/dev/sdf"
Add-EC2Volume -VolumeId $VolumeId -InstanceId $InstanceB -Device "/dev/sdf"

Key Points

  • Same AZ requirement for all attachments.
  • Use a cluster-aware filesystem or application volume manager.
  • Design for fencing and split-brain prevention.
  • Test failover and recovery regularly.
  • Monitor VolumeAttachmentState and app-level locks.

FAQs (Multi-Attach)

  1. Can I use ext4 with Multi-Attach? Not safely in RW mode; use cluster-aware FS.
  2. Does Multi-Attach support Windows? Only with cluster-aware storage stacks.
  3. Is performance shared? Yes—IOPS/throughput are shared across attachments.
  4. Cross-AZ Multi-Attach? No—same AZ only.
  5. Can I mix instance types? Yes, but match ENA/NVMe capabilities and drivers.
  6. How to avoid corruption? Use DLM fencing, quorum, and proper FS/cluster drivers.
  7. Can I snapshot a Multi-Attach volume? Yes—ensure app quiescence across nodes first.
  8. Does EBS lock the device? EBS doesn’t provide FS locks; that’s the cluster’s job.
  9. How to monitor? CloudWatch metrics, CloudTrail for API calls, and cluster health dashboards.
  10. Is Multi-Attach on gp3? No—io1/io2 only.

Cost Optimization: Provisioning, Rightsizing, and Data Lifecycle

With EBS you pay for provisioned capacity (GB-months) and performance (IOPS with io1/io2, throughput for gp3). Optimize by choosing the right type, rightsizing, and enforcing lifecycle policies.

  • Migrate gp2 → gp3 to lower $/GB and dial performance independently.
  • Use DLM or AWS Backup to expire snapshots you no longer need.
  • Tag everything (CostCenter, Owner, Environment, Retention).
  • Turn off DeleteOnTermination=false only for volumes that must outlive instances.
  • Aggressively monitor idle volumes and orphaned snapshots.

PowerShell – Find Idle or Underutilized Volumes

# Simple heuristic: list available volumes with no attachments
Get-EC2Volume | Where-Object { $_.Attachments.Count -eq 0 } | 
  Select-Object VolumeId, Size, VolumeType, State, Encrypted

AWS CLI – List Orphaned Snapshots (Owned by Me)

aws ec2 describe-snapshots --owner-ids self \
  --query "Snapshots[?StartTime<='`date -u -d \"30 days ago\" +%Y-%m-%dT%H:%M:%SZ`'].{Id:SnapshotId,Start:StartTime,Size:VolumeSize,Desc:Description}" \
  --output table

Key Points

  • Enable cost allocation tags and export to CUR for showback/chargeback.
  • Automate clean-up of unattached volumes and aged snapshots.
  • Migrate legacy gp2 to gp3; review performance after migration.
  • Consider RAID 0 across smaller gp3 volumes for cheaper throughput scaling.
  • Use storage-optimized instances if throttled by instance EBS bandwidth.

FAQs (Cost)

  1. Do I pay for unattached volumes? Yes—until deleted.
  2. Are snapshots cheaper than volumes? Yes—pay only for changed blocks.
  3. Does gp3 always win on cost? Usually; verify workload performance first.
  4. Are IOPS billed on gp3? gp3 includes baseline; extra provisioned IOPS/throughput may cost.
  5. Can I compress at filesystem level? Yes—can reduce used space and change IO patterns.
  6. CUR reports for EBS? Yes—enable and use Athena/QuickSight.
  7. What about snapshot archival tiers? Evaluate snapshot tiers for long-term retention if available.
  8. Chargeback by tag? Yes—ensure consistent tag keys across org.
  9. Rightsize frequency? Quarterly at minimum; monthly for dynamic estates.
  10. Can I buy RIs/Savings Plans for EBS? Not directly; focus on EC2 and optimize storage separately.

Monitoring & Troubleshooting: Scripts, Checks, and Playbooks

Use CloudWatch metrics, OS counters, and scripting to diagnose latency, throttling, or throughput caps. Below are ready-to-use playbooks.

Playbook A: Volume Not Attaching

  1. Confirm same AZ between EC2 and volume.
  2. Check KMS permissions if encrypted.
  3. Validate VolumeInUse state isn’t stuck—detach stale attachments.
  4. Check IAM policy for ec2:AttachVolume.

PowerShell – Force Detach & Re-Attach

$Vol="vol-0123456789abcdef0"; $Instance="i-0123456789abcdef0"
(Get-EC2Volume -VolumeId $Vol).Attachments | ForEach-Object {
  Dismount-EC2Volume -VolumeId $Vol -InstanceId $_.InstanceId -Force
}
Add-EC2Volume -VolumeId $Vol -InstanceId $Instance -Device "/dev/sdf"

Playbook B: High Latency / Low IOPS

  1. Check instance EBS bandwidth cap; consider storage-optimized instance.
  2. Upgrade to gp3 or io2 with higher IOPS/throughput.
  3. Increase queue depth; verify NVMe driver and kernel version.
  4. For sequential throughput, stripe across multiple volumes (RAID 0).

AWS CLI – Quick Perf Telemetry

VOL="vol-0123456789abcdef0"
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLengt
Related Story

Leave a Reply

Your email address will not be published. Required fields are marked *