This may be a silly question, excuse my ignorance.

I have an instance running like this: AWs Console

Does Root Device : EBS mean my entire system is on EBS?

I've configured apache and a perl app here, all my config and files will not go away right?

How do I know what is running on ephemeral storage and what is running on EBS? If I click the instance in the management console and look at the details in the bottom it says : EBS Optimized: false What exactly does this mean?

Here is what my storage looks like :

[ec2-user@<MY_IP> ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  1.7G  6.2G  22% /
tmpfs                 298M     0  298M   0% /dev/shm

[ec2-user@<MY_IP> ~]$ mount
/dev/xvda1 on / type ext4 (rw,noatime)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
  • 2
    t1.micro instance don't have any ephemeral storage, only m1.small or above has.
    – number5
    Jan 21 '13 at 10:35
  • Ah nice. Didn't know that. No wonder I don't see any options.
    – gideon
    Jan 21 '13 at 11:26

Root device is your '/'. In this case it's /dev/xvda1 and it's EBS drive.

Ephemeral devices are (as I know):

  • sdb(xvdb)
  • sdc(xvdc)
  • sdd(xvdd)
  • sde(xvde)

You can always check which devices are EBS drives, using AWS UI: EC2 -> Instances -> [choose yours] -> Block Devices

  • Awesome. Thanks :) Whats all the sysfs1, devpt and what not.
    – gideon
    Jan 20 '13 at 10:37
  • 1
    tmpfs is similar to ramfs and allow to keep files in fast RAM. devpts and sysfs are "virtual" linux filesystems, that provide access to some kernel data. You can check more on google - there are plenty of articles about them. Jan 20 '13 at 10:41
  • xvda1 Xvdd xvdc xvdb These are EBS volumes. How can you say these are ephemeral?
    – user225956
    Jun 12 '14 at 10:33
  • 3
    The answer above is not correct and should not be checked as 'the answer'
    – Andrew S
    Jun 22 '16 at 1:42
  • This is wrong!! Nov 19 '19 at 22:36

Ephemeral and ebs devices can take just about any lettered device file name, so do not solely rely on the device name. The device name is important to making a determination if it is ephemeral or not, however, as I will outline below. Relying on a mount point name with the words 'ephemeral' or 'ebs' is likewise not reliable.

Though some of this can be done through the EC2 GUI, a few commands would still need to be run on the server itself, so here, I just give you an 'all command-line' method. I will give you examples from a m3.medium CentOS minimal 6.5 instance store (i.e. ephemeral) backed AMI.

1) Install the wget utility with yum install -y wget

2) Run wget -q -O -

In this example instance store backed AMI - the output to command #2 above is:

ami ephemeral0

For comparison purposes, below is example output from an EBS backed CentOS server with EBS volumes only (no ephemeral drives):

ami ebs2 ebs3

I will return to the EBS backed instance with EBS volumes later. For now, let's continue with the original instance store backed AMI example that shows us an ephemeral drive.

To find out which device file is mapped to your ephemeral drive, run wget again, this time adding the name of the ephemeral drive as discovered in #2 above to the url:

3) wget -q -O -

and, in this example the output is/was:


This underscores my point above that you cannot assume /dev/sdb through /dev/sde are ebs devices. It might be true that /dev/xvdb through /dev/xvde are ebs - but my systems always start with /dev/xvde1, so existence of those device letters likely depend on the OS, region, AMI, etc, you are using. As an aside, you can run #3 against 'ebs' names, if any (e.g. ebs2), and will yield similar output.

4) Next, run lsblk

In this case, the output looks like so:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvde1 202:65 0 8G 0 disk / xvdf 202:80 0 4G 0 disk

This underscores my point from above that you cannot rely on a mount point to tell you whether a device is ephemeral, or not.

You'll also notice that the mapping between EC2 device volume letters and the OS's mapping letters do not match. A small sliver of good news here is that the drive letters will increment in the same order, even if the letters themselves do not match. So, let's get the 'other' drive letter from our device mappings meta-data. As you saw above, there were two device mappings, one called ami and the other called ephemeral0. We already examined ephemeral0, so let's examine ami:

5) wget -q -O -

The output is/was as follows:


We can confidently conclude the lowest letter in the OS mapping is the lowest letter of the EC2 block device mapping, and we can increment upwards from there. Thus:

/dev/sda1 = /dev/xvde1 and /dev/sdb = /dev/xvdf

Last but not least - you will notice that the block device mapping ami does not immediately lend itself to whether it is EBS backed or Instance Store backed. We have one more command to run.

6) wget -q -O -

I am certain that EBS backed AMI's do not have a manifest path because only instance store volumes have a manifest (the manifest lists the names and path of the bundle segments of the AMI in S3). In cases I have checked, the result of #6 above when run against and instance store ami is something similar to:


whereas, when #6 is run against an EBS backed AMI you get:



sudo lsblk should give you some hints. I.E.

[ec2-user@ec2-host ~]$ sudo lsblk
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /
xvdb    202:16   0   4G  0 disk /media/ephemeral0

There are three ways to know if EC2 Storage is ephemeral.

1) According to Understand the Instance Store and EBS article which discuss why there are instance that lost its data if stopped/terminated.

You have to run the lsblk linux command. Sample output will be:

[ec2-user:ip-] ~]$ lsblk
xvda    202:0    0  50G  0 disk 
└─xvda1 202:1    0  50G  0 part /
xvdb    202:16   0   8G  0 disk /media/ephemeral0

If you see ephemeral0 keyword. anything stored on the ephemeral drive will lose data when you stop and restart the instance.

2) You can check your instance type. If you see that the storage of your instance type is EBS only, the data will retain when stopped or restarted.

enter image description here

3) Query the metadata server using:

curl -O -

EBS Storage

[ec2-user:ip-] ~]$ curl -O -

With Ephemeral Storage

[ec2-user:ip-] ~]$ curl -O -

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.