Elastic Block Store — persistent virtual hard drives for EC2 instances. Complete beginner-friendly guide with real company scenarios.
When you launch an EC2 instance, it needs storage — just like your laptop needs a hard drive. Amazon EBS (Elastic Block Store) provides that storage. It is a network-attached, persistent block storage volume that you attach to EC2 instances.
Persistent means the data survives even if the EC2 instance is stopped or restarted — just like your laptop's hard drive keeps files even when you shut it down.
You plug it into your laptop (EC2) and use it. If you shut down the laptop — the hard drive and its data are safe. You can unplug it and plug it into a different laptop (different EC2 instance). You can make a copy (snapshot) for backup. The key difference: EBS volumes are attached over the network, not a physical cable.
One EBS volume attached to one EC2 at a time (except io1/io2 Multi-Attach for clusters).
EBS volume and EC2 must be in the same AZ. Mumbai AZ-a volume → Mumbai AZ-a EC2 only.
Data survives stop/start. Only deleted when you explicitly delete the volume.
Start with any size. Increase without stopping the EC2 instance — zero downtime.
Flipkart runs its product catalog MySQL database on EC2 instances. Each EC2 has a gp3 EBS volume of 500 GB as the data disk. The database stores millions of product records, prices, and inventory. Because EBS is persistent, even when Flipkart's EC2 is stopped at 3 AM for maintenance, all product data remains safe on the EBS volume. When the EC2 restarts at 6 AM, it re-attaches the same EBS volume with all data intact.
Zerodha (India's largest stockbroker) runs its trading engine on EC2 + io2 EBS. During IPO subscriptions like LIC's ₹21,000 crore IPO, millions of orders hit the system. EBS provides the low-latency, high-IOPS storage the trading database needs to handle 100,000+ orders per second without losing a single transaction.
EC2 instances can have two types of storage. It is critical to know the difference — choosing the wrong one means losing all your data.
| Feature | EBS Volume | Instance Store |
|---|---|---|
| Type | Network-attached block storage | Physically attached to the host hardware |
| Persistence | ✅ Data persists on stop/restart/failure | ❌ Data LOST on stop, terminate, or hardware failure |
| Use for | OS, databases, application data | Temp caches, scratch space, buffers only |
| Snapshot | ✅ Backup to S3 anytime | ❌ No backup support at all |
| Speed | Very fast (gp3: up to 16,000 IOPS) | Fastest (direct physical NVMe) |
| Cost | Billed per GB provisioned | Included in instance price (free) |
| Move to another EC2 | ✅ Detach and attach to another EC2 | ❌ Cannot be moved — tied to one physical host |
A startup in Bangalore (real incident reported on AWS forums) launched a MongoDB database on an EC2 instance and stored all data on the Instance Store (they thought it was faster — which it is). AWS performed scheduled maintenance on the underlying host and stopped the EC2. When the EC2 restarted, the Instance Store was wiped clean. All 3 months of customer data was gone permanently. There was no backup. The startup had to contact customers to re-enter their data.
Lesson: Always use EBS for any data you want to keep. Instance Store = scratch pad only. Use it only for temporary caches, sort operations, or data you can easily recreate.
EBS comes in 6 types — two categories: SSD-backed (low latency, random access) and HDD-backed (high throughput, sequential reads). Key term: IOPS = Input/Output Operations Per Second — how many read/write operations per second the disk can handle.
SSD-Backed Volumes
Latest generation. IOPS and throughput independently configurable. Cheaper than gp2. Default choice for all new volumes.
IOPS tied to size (bigger = more IOPS). Still works but gp3 is cheaper and better. Use gp3 for all new volumes.
Guaranteed, consistent high IOPS. io2 Block Express is the highest performance EBS volume available.
Older version of io2. Supports Multi-Attach (same volume → up to 16 EC2 instances). Use io2 for new deployments.
HDD-Backed Volumes
For big files read sequentially (not random access). Cannot be a boot volume. Optimized for reading large files end-to-end.
Lowest cost per GB. For infrequently accessed large files. Cannot be a boot volume.
Amazon India runs its main e-commerce website on thousands of EC2 instances, each with a gp3 OS disk (running Amazon Linux). For the product database, they use io2 Block Express volumes on RDS instances — during Big Billion Day / Great Indian Festival sale, the database handles millions of queries per second. io2's guaranteed 256,000 IOPS ensures no slowdown even at peak.
Swiggy's data engineering team processes 50 GB of order logs daily using Apache Spark on EC2. They use st1 (Throughput Optimized HDD) for storing raw log files — these are read sequentially (not randomly) by Spark jobs. st1 is 60% cheaper than gp3 for this sequential workload, saving Swiggy ₹2+ lakhs per month in storage costs.
IRCTC stores historical train booking records (7+ years, compliance requirement) on sc1 Cold HDD. These records are almost never accessed — only during rare audits. sc1 is the cheapest EBS option at ₹0.015/GB/month vs gp3 at ₹0.096/GB/month — 85% cheaper for rarely-accessed compliance data.
A Snapshot is a backup of your EBS volume saved to Amazon S3. You can use it to restore a volume, copy data to another region, or create a new volume anywhere in AWS.
Your phone (EC2) keeps working normally. At any time you take a backup (snapshot) of its storage (EBS) to S3. If your phone breaks (EC2 crashes), restore from backup and get everything back. You can also restore onto a different phone (different EC2 in a different region).
Running data
Stored in S3
New EBS volume
Disaster recovery
First snapshot = full backup. Every subsequent snapshot = only changed blocks. Saves cost.
Copy snapshot to any AWS region. If Mumbai region fails, restore in Singapore or US.
Turn snapshot into an AMI (machine image). Launch identical EC2s anywhere in AWS.
Accidentally deleted? AWS keeps it in Recycle Bin for up to 365 days before permanent deletion.
Freshworks (Indian SaaS company, listed on Nasdaq) runs CRM software for global clients. Before every production deployment, their DevOps team takes an EBS snapshot of all production volumes. If the new deployment causes a bug, they restore from the snapshot in under 10 minutes — bringing the system back to its pre-deployment state. This "pre-deploy snapshot → deploy → monitor → rollback if needed" pattern is used by every serious company.
BookMyShow has a disaster recovery strategy using cross-region snapshots. Every night, EBS snapshots of the booking database in Mumbai (ap-south-1) are automatically copied to Singapore (ap-southeast-1). If a natural disaster or prolonged AWS Mumbai outage occurs, BookMyShow can restore their database in Singapore and redirect traffic there — achieving their 4-hour Recovery Time Objective (RTO).
Ola uses the Amazon Data Lifecycle Manager (DLM) to automate EBS snapshots: every day at 2 AM, snapshots are taken automatically for all production volumes. Old snapshots older than 30 days are automatically deleted. This costs them ₹15,000/month for peace of mind on 500+ production volumes — instead of hiring someone to do it manually.
EBS encryption protects your data at rest (stored on disk) and in transit (moving between EBS and EC2). It uses AES-256 encryption and AWS manages the keys automatically via AWS KMS (Key Management Service).
| What Gets Encrypted? | Details |
|---|---|
| Data at rest on the volume | All data written to EBS is encrypted with AES-256 |
| Data in transit | Data moving between EC2 and EBS is encrypted (SSL/TLS) |
| Snapshots of encrypted volumes | Automatically encrypted — no extra steps |
| Volumes from encrypted snapshots | Any new volume created from an encrypted snapshot is automatically encrypted |
Paytm stores KYC data (Aadhaar numbers, PAN cards, bank account details) of 350 million users. RBI regulations mandate encryption of financial customer data. Paytm uses EBS encryption with customer-managed KMS keys — meaning even AWS employees cannot read the data. Encryption keys are rotated every year automatically. This satisfies RBI's data security guidelines without any application-level code changes.
Apollo Pharmacy stores patient prescription history and medical records on encrypted EBS volumes. Healthcare data falls under the PDPB (Personal Data Protection Bill) in India and HIPAA internationally. Using EBS with encryption-by-default means every new volume is automatically encrypted — zero chance of accidentally creating an unencrypted volume with sensitive health data.
One of EBS's most powerful features: increase volume size, change volume type, or adjust IOPS while the EC2 instance is running. No restart needed — zero downtime.
Expand 20 GB → 200 GB while EC2 runs. Then extend the file system (OS command) to use new space.
Switch gp2 → gp3 for better performance and lower cost — live, no downtime required.
Increase IOPS on io2 volumes when DB needs more performance during sale/peak time.
EBS volumes are like USB hard drives — you can attach and detach them from EC2 instances, as long as they stay in the same Availability Zone.
| Operation | Requirement | Notes |
|---|---|---|
| Attach | Same AZ as EC2 | Root volume attached at launch. Data volumes can be attached anytime. |
| Detach | Volume must be unmounted first | Safely detach data volumes. Root volume: must stop EC2 first. |
| Move to another AZ | Snapshot → New volume in new AZ | Direct AZ-to-AZ move is not possible. Use snapshot as intermediary. |
| Move to another Region | Copy snapshot to new region → new volume | Snapshots cross regions; raw volumes cannot. |
Contains OS (Linux/Windows). Created automatically when you launch EC2. Deleted by default when EC2 is terminated — change "Delete on Termination" to No if you want to keep it.
Additional volumes you attach manually. For storing databases, app files, user uploads. NOT deleted on EC2 termination by default. Can be detached and re-attached to any EC2 in the same AZ.
| Concept | AWS EBS | Azure Managed Disk |
|---|---|---|
| Service Name | Elastic Block Store (EBS) | Azure Managed Disks |
| General Purpose SSD | gp3 / gp2 | Standard SSD (E-series) |
| High Performance SSD | io2 / io1 | Premium SSD (P-series) / Ultra Disk |
| HDD Storage | st1 / sc1 | Standard HDD (S-series) |
| Backup Mechanism | EBS Snapshot (stored in S3) | Azure Snapshot / Azure Backup |
| Encryption | AWS KMS, AES-256 | SSE (Server-Side Encryption) — on by default |
| Scope | Single Availability Zone | Single region (ZRS option available) |
| Max volume size | 16 TB (gp3) / 64 TB (io2) | 32 TB |
| Multi-attach | io1/io2 only (up to 16 EC2) | Shared Disk feature (Premium/Ultra) |
| Key Difference | Volume must be in same AZ as EC2 | Disks auto-manage placement |
| Topic | AWS Docs URL |
|---|---|
| EBS Overview | EC2/AmazonEBS.html |
| EBS Volume Types | ebs-volume-types.html |
| EBS Snapshots | EBSSnapshots.html |
| EBS Encryption | EBSEncryption.html |
| Modify EBS Volume | ebs-modify-volume.html |
| Instance Store vs EBS | InstanceStorage.html |