I took many courses and searched online extensively but nevertheless I couldn’t find a definitive answer on the type of storage that EBS belong to. It is a block storage type not file or object so I get it but what about the network communication protocol that it uses when it is attached/mounted to EC2 instance? Typically block type of storage has to be either DAS or SAN. In this case DAS is ruled out because it cannot be directly attached like instance store. This will leave it only to be a SAN type. If it is SAN then does it use iSCSI protocol or a sort of Fiber Channel protocol?
In one of the white papers (Storage options) it says that EBS is a network-attached storage (NAS)! But that statement confused me more than anything else! Because my understanding that EFS is a NAS type and uses the NFS protocol while EBS is block type of storage and therefore cannot be NFS because NFS support the file interface not block.
15 Answers
Hi there,
Are you looking for how have they actually implemented the service or what purpose does it serve to your EC2 instance?
The latter is that it would be the equivalent of a hard drive physically connected to your server. You can only have an EBS volume attached to a single server.
The former is what you have found, they used NAS to connect these drives over the network to your EC2 instance.
As far as EFS, that is the AWS offering for when you need a shared drive. This will allow you to attach the drive to multiple EC2 instances.
Would that knowledge further your AWS enlightenment?
Is it relevant to your decision making regarding AWS service implementation?
No.
Physically, yeah, EBS is NAS storage that the EBS service restricts to only a single EC2 instance at a time. Nice to know, but irrelevant to actually using EBS. What protocol is it using? Don’t care. Don’t need to. AWS probably wouldn’t really want me to. My EC2 servers see it as locally attached block storage that can be formatted with a file system of my choosing.
What needs to be understood is the scope of EBS as a service – when and why to use EBS vs other forms of EC2 accessible storage, the various options and limits of EBS, the various means of automating EBS volume management, knowing how to best utilize EBS storage in conjunction with other AWS services to implement an AWS infrastructure in keeping with the pillars of the Well Architected Framework. We don’t need to worry about the hardware. That’s what we pay AWS to do.
"Would that knowledge further your AWS enlightenment?" … Yes! As you are aware of that disk I/O and throughput is different from one storage type to another. NFS, iSCSI, FC are completely different implementation. Last, why would Amazon keep the storage protocol implementation as a secret?! We already know that EFS using NFSv4 and we already know that Storage Gateway using iSCSI so what is so special about EBS to hide its detailed implementation. Knowledge is always Gold!
I agree that it must be some sort of SAN, but I would not really one we know from traditional data centres. The hypervisor may talk to some special entities residing on host which may have different ways to talk storage – either local DAS or one connected through various means. Yes, it is interesting to me as well and I wonder if Amazon anywhere lifts the curtain (they certainly need to do that for external auditing parties), but at the end these are specs and SLAs which matter. I wonder how differently various cloud providers approach it. Probably there are some common patterns. So maybe let’s look at OpenStack Cinder?
I agree. Knowledge is Gold. Knowing the underlying implementation and that it could change, may not be needed either for exam or to use it but it will help to further your knowledge or to come up with a better solution.
Absolutely agree. Knowledge is gold and nobody should mock you for wanting to know more about.
Now back to the question itself, I think SAN over FC sounds too legacy for AWS’ liking. NAS via iSCSI seems a reasonable bet.
"We don’t need to worry about the hardware. That’s what we pay AWS to do." Distancing our selves from the underlying hardware is not a good idea. Understanding the physical is critical to understanding whats virtual. One of the reason why many are confused by terms like "serverless" and "cloud", its because it is sometimes hard to make a connection to the the physical or whats real. It is always nice to know what lies behind the curtain.
Interesting question. I am a former storage admin and have never really thought about it. Steven’s answer is partially correct and partially opinion. As a person with traditional infrastructure background I am interested in how AWS does what they do. But to my customers it really makes no difference. EBS is presented to the host as block storage, so its volumes can be put into groups, striped, and various types of file systems can be created on them. I/O should be able to handle applications that would use traditional block storage, whether SAN or local.
We are talking about two things – connectivity (SAN or NAS) and type (Block or Object). so connectivity can be NAS or SAN and type can be block or object. EBS is a block but can be connected through NAS and not necessarily to use SAN and how AWS is doing behind the scene – its not important as long as purpose is clear
EBS is on a SAN. Its not a NAS.
Its on a Storage Array that gives you a higher throughput, and practically should be within the primary physical infra where your instance is running. (Should be). When you want to mount it on an Instance, you can mount it on an instance within that AZ only for the same reason.
You don’t get replication / synchronization etc that you might see on a EFS.
[EFS is a NAS, but again under the hood on an Storage Array , managed with sync, replication, scalability etc.]
most of the different commercial NAS filers provide the means to mount block devices over ip, that is usually iscsi, I am with Steve, as the internals could change and that is part of the abstractions that AWS provides us as customers. these block devices are replicated across multiple locations in a single AZ to guarantee performance and reliability.
I find this AWS re:Invent 2018 repeat video session from previous years useful on what is required from us to be aware of :
[REPEAT 1] Deep Dive on Amazon Elastic Block Storage (Amazon EBS) (STG310-R1)
I have managed many traditional on-prem type setups. I see this as Large Volumes presented to the Hypervisor Hosts Directly via iSCSI or FC for example. (Not saying it IS, Just how I look at it) Our Hypervisor, Either Xen or KMV (Nitro) we use in EC2 are most certainly in clusters and they can present large amounts of storage directly to those hypervisors and our VM’s running on those don’t see it or know about it. They just use the EBS. And even if it is iSCSI at 10G its plenty fast. I try not to wonder "Why" too much in AWS, just need to make sure and know things like EBS is only in ONE AZ. Likely because that SAN or storage array is in that one data center, And I need to know the level of redundancy and performance of the service (more important). And I also know they have 100G NIC cards by now, and at those speeds it probably doesn’t matter as my trivial needs are easy to meet.
@Mohamad Elmardini- Regarding "EFS using NFSv4 and we already know that Storage Gateway using iSCSI" – these services are accessible from outside so the protocol has to be known/published;
Unlike EBS that can only be accessible from inside and only by EC2- we really don’t care about the protocol- as long as it works.
It is a SAN. Even if you check in the TCO to compare what you could "save" you will see the option for SAN correlates with the superscribed value proposition of AWS resource in this case the target EBS. I hope this clears things up for you!
Is this relevant from an exam standpoint ?
EBS is a SAN and not a NAS. It ticks all the features of a SAN.
Just covering this over for everyone, this knowledge is not required for the exam, the discussion is purely part of technical speculation about some really powerful technology
SAN
EBS is a SAN storage
It’s neither.
It’s not a SAN, not a NAS, per se.
It’s an abstraction layer on top of SAN / network block storage which can be attached to the VMs as a SCSI device. If it is a SAN drive, you will not be able to attach to your VM directly.
As to the hardware, you can refer to this product https://buy.hpe.com/us/en/storage/disk-storage-systems/msa-storage/msa-storage/hpe-msa-2050-san-storage/hpe-msa-2050-sas-dual-controller-sff-storage/p/Q1J29A
Thank you. I was looking for the former which how it was implemented not the purpose which I am well familiar with.
I just found it strange for a block storage to be implemented as a NAS instead of SAN. NAS is for file interface not block and for sharing files across multiple hosts which is again not what EBS provide. EBS is both block based storage and attached for a single host so it should have been a typical SAN implementation use case in my book. I am sure AWS has their reasons for implementing it differently.