Source: Dev.to

If you’ve ever spent hours debugging slow EC2 workloads or getting sticker shock from unexpected EBS IOPS charges, you’ve probably wondered if there’s a better storage option for temporary, high-performance data. AWS EC2 Instance Storage (also called Instance Store) is one of the most underutilized but powerful tools in the EC2 ecosystem—if you know how to use it correctly. This guide breaks down everything you need to know: core concepts, performance optimizations, use cases, limitations, and how it stacks up against EBS. By the end, you’ll be able to cut storage costs, boost workload performance, and avoid costly data loss mistakes. What Exactly Is AWS EC2 Instance Storage? Core Concepts of EC2 Instance Store Key Features That Make Instance Store Stand Out Which EC2 Instance Types Support Instance Store? Deep Dive: NVMe SSD Instance Store Volumes SSD Instance Store Performance Best Practices EC2 Instance Store vs EBS: Head-to-Head Comparison Top Real-World Use Cases for EC2 Instance Store Critical Limitations to Avoid Costly Mistakes Production-Grade Best Practices for Instance Store Root Volume Options: EBS-Backed vs Instance Store-Backed Instances EC2 Instance Store Pricing: No Hidden Costs Conclusion References EC2 Instance Store is temporary block-level storage that is physically attached to the host server running your EC2 instance. Unlike standalone storage services like EBS, EFS, or S3, it is part of the EC2 service itself, with no network overhead between your instance and the storage disks. Its defining trait is its ephemeral nature: data stored on Instance Store only persists for the lifetime of the associated instance. If you stop, hibernate, or terminate your instance, all data on Instance Store volumes is permanently deleted. Before you start using Instance Store, make sure you understand these foundational rules: Device naming: Instance Store volumes are exposed as block devices with virtual names from ephemeral0 to ephemeral23. Modern NVMe volumes appear as /dev/nvme1n1, /dev/nvme2n1, etc. on Linux. Capacity tied to instance type: The number, size, and type of Instance Store volumes you get are determined entirely by your EC2 instance type and size. For example, an r5d.large includes 1 x 75 GB NVMe SSD, while an i4i.16xlarge includes 8 x 3.8 TB NVMe SSDs. No universal support: Not all EC2 instance types include Instance Store volumes. Persistence rules: Data persists during instance reboots, but is permanently deleted if the instance is stopped, hibernated, terminated, or if the underlying host experiences hardware failure. No extra cost: Instance Store volumes are included in the hourly price of your EC2 instance, with no separate storage or IOPS charges. Since storage is physically attached to the same host as your instance, you get extremely low latency and IOPS performance far exceeding EBS, EFS, or S3. Top-tier instance types can deliver millions of random read IOPS, compared to the 350,000 IOPS maximum for EBS io2 Block Express volumes. All Instance Store capacity is included in your instance price, making it one of the most cost-effective storage options for eligible workloads. All modern NVMe Instance Store volumes are encrypted at rest using the XTS-AES-256 block cipher, implemented in dedicated hardware modules. Encryption keys are unique to each device, and are permanently destroyed when the instance is stopped or terminated, with no way to recover them. You do not need to configure any encryption settings for this protection. Eligible instance types support TRIM commands, which notify the SSD controller when data is no longer needed, reducing write amplification and maintaining consistent performance over time. Access to Instance Store volumes is controlled via the same IAM policies and instance access controls as your EC2 instance, so you don’t need to manage separate storage permissions. If you create an AMI from an EC2 instance using Instance Store, none of the data on the Instance Store volumes is included in the AMI. Only data on attached EBS volumes is preserved. Instance Store is only available on specific instance families: Quick tip: Instance types without a “d” suffix (e.g., C5, M5, R5) almost never include Instance Store. Always check the “Instance Storage” column on the EC2 pricing page before launching an instance to confirm capacity. Modern Instance Store volumes use the NVMe 1.0e specification for maximum performance. Here’s what you need to know to use them: NVMe Instance Store works with all modern operating systems: Amazon Linux 2, AL2023 Ubuntu 14.04+ RHEL 7.4+, CentOS 7.4+ SLES 12 SP2+, FreeBSD 11.1+, Debian 9+ Bottlerocket First, install the nvme-cli tool to manage NVMe devices:

For Amazon Linux/RHEL/CentOS

sudo yum install -y nvme-cli

For Ubuntu/Debian

sudo apt install -y nvme-cli

List all available NVMe Instance Store volumes: sudo nvme list

Sample output: Node SN Model Namespace Usage Format FW Rev

---

/dev/nvme0n1 vol0123456789abcdef Amazon Elastic Block Store 1 21.48 GB / 21.48 GB 512 B + 0 B 1.0 /dev/nvme1n1 AWS000123456789abcde Amazon EC2 NVMe Instance Storage 1 75.16 GB / 75.16 GB 512 B + 0 B 0

Format and mount the volume:

Format with ext4 filesystem (skip discard to avoid initial performance hit)

sudo mkfs.ext4 -E nodiscard /dev/nvme1n1

Create mount directory

sudo mkdir -p /mnt/ephemeral

Mount the volume

sudo mount /dev/nvme1n1 /mnt/ephemeral

Give permissions to ec2-user

sudo chown ec2-user:ec2-user /mnt/ephemeral

Add to /etc/fstab to persist across reboots

echo “/dev/nvme1n1 /mnt/ephemeral ext4 defaults 0 0” | sudo tee -a /etc/fstab

You can automate this entire process with EC2 User Data when launching instances, so volumes are ready to use immediately on boot. SSD performance degrades over time if not configured correctly. Follow these tips to maintain maximum throughput and IOPS: Over-provision by 10%: Leave 10% of your Instance Store volume unpartitioned. This gives the SSD controller extra space for garbage collection, reducing write amplification and boosting sustained write performance. For a 100 GB volume, only partition 90 GB for use. Run TRIM commands regularly: Use the fstrim command on Linux to notify the SSD controller of unused data blocks:

sudo fstrim /mnt/ephemeral

Add this to your weekly crontab to automate it. Align writes to 4KB boundaries: Most modern filesystems use 4KB block sizes by default, but double-check your formatting settings. Writes that are not aligned to 4KB boundaries cause significant write amplification and performance loss. Avoid filling volumes to 100%: As SSDs fill up, garbage collection becomes less efficient, leading to lower write IOPS. Aim to keep usage below 90% for consistent performance. The most common question developers ask is when to use Instance Store vs EBS. This table breaks down the key differences: Instance Store is ideal for any workload where data is temporary, can be regenerated quickly, or is replicated across multiple instances: Big data processing: Intermediate shuffle data for Spark, Hadoop, and ETL jobs. No need to pay for EBS storage for data that is deleted after the job completes. Application caching: Redis, Memcached, and CDN edge caches, where data is replicated across multiple nodes. If one instance fails, the data is still available on other nodes, and you get lower latency than EBS. Distributed databases: Cassandra, HBase, and HDFS data nodes, where data is replicated across 3+ instances. Instance Store delivers higher performance than EBS at a lower cost. Scratch space: Temporary build artifacts, compilation outputs, and render files for CI/CD pipelines and media processing jobs. Machine learning training: Local storage for training datasets and intermediate checkpoints. You can copy datasets from S3 to Instance Store for faster access during training, and save final model artifacts back to S3. HPC workloads: Scientific computing and simulation jobs that process large temporary datasets. Load-balanced web servers: Temporary session data and static assets that are replicated across a fleet of instances. Instance Store is not suitable for all workloads. These are the most common pitfalls to avoid: Ephemeral data risk: Never store critical, irreplaceable data on Instance Store. If your instance stops, the underlying host fails, or you accidentally terminate the instance, all data is permanently lost with no recovery option. No post-launch provisioning: You must specify Instance Store volumes when launching your instance. You cannot add them later without terminating and relaunching the instance. No snapshot support: There is no built-in backup feature for Instance Store volumes. You must implement your own replication to S3/EBS if you need to preserve data. Tied to instance lifecycle: You cannot detach Instance Store volumes from one instance and attach them to another. AMI backups do not include Instance Store data: Any data stored on Instance Store will not be preserved when you create an AMI from your instance. Follow these rules to use Instance Store safely and efficiently in production: Always replicate critical data: Any data you can’t afford to lose should be replicated to S3, EBS, or another persistent storage layer on a regular schedule. Design stateless applications: Build your workloads so that if an instance fails, Auto Scaling can launch a new instance, pull code/config from S3/ECR, and be operational within minutes. Use tiered storage: Use Instance Store as a high-performance cache tier, with EBS or S3 as the persistent source of truth. Monitor instance health: Use CloudWatch EC2 status checks and AWS Health Dashboard alerts to detect host hardware failures early. Proactively replace instances with scheduled maintenance events. Test failure scenarios: Simulate instance terminations and host failures in staging to confirm your application can recover without data loss. Avoid instance store-backed root volumes: Use EBS-backed root volumes for all instances unless you have a very specific use case for ephemeral root storage. EC2 instances can use one of two root volume types: EBS-backed instances (default): The root volume is an EBS volume. You can stop and restart the instance without losing root volume data. This is the recommended option for almost all use cases. Instance Store-backed instances: The root volume is an Instance Store volume. All root volume data is lost when the instance is stopped or terminated. This is only supported on older legacy instance types, and only for Linux operating systems. Instance Store volumes are 100% included in the hourly price of your EC2 instance, with no separate charges: No per-GB storage fees No IOPS or throughput fees No data transfer fees between the instance and Instance Store volumes For example, a c6gd.large instance costs $0.08 per hour, and includes 1 x 118 GB NVMe SSD Instance Store with no extra cost. A comparable 118 GB gp3 EBS volume would cost ~$0.94 per month plus additional IOPS charges, making Instance Store 30-70% cheaper for eligible workloads. AWS EC2 Instance Storage is a powerful, cost-effective tool for high-performance temporary workloads, but it requires careful planning to avoid data loss. The key takeaways are: Use Instance Store for temporary, replicable, or regenerable data to get maximum performance at no extra cost. Never store critical or irreplaceable data on Instance Store. Optimize SSD performance with over-provisioning and regular TRIM commands. Always pair Instance Store with a persistent storage layer (EBS/S3) and stateless application design. When used correctly, Instance Store can cut your cloud storage costs by 50% or more while delivering significantly better performance than EBS for eligible workloads. AWS Documentation: Storage options for your Amazon EC2 instances AWS Documentation: Instance store temporary block storage AWS Documentation: SSD instance store volumes