Tags Archives: efs

AWS EBS & EFS Elastic Block Storage & Elastic File System

EBS is a network drive you can attach to ONLY ONE INSTANCE at any one time



important: EBS is not a network file system!

is bound to an AZ


think of it like a network USB stick


30GB per month free of type SSD or magnetic GP2 or GP3 volume


EBS can have some latency on the AWS network


can be detached from one EC2 and attached to another, eg for failovers, big advantage!


but cannot be moved to other AZs, unless you do a snapshot and then move.


have to provision in advance and the level of IOPS you want


you pay according to this after the first 30GB.



BUT you can have 2 EBS volumes attached to an EC2 – that is not limited.


however they are bound to an AZ


they can be attached on demand, do not have to be actively attached.



EBS Delete on Termination attribute – is enabled by default for EBS root volume


but not for other EBS volumes as it is disabled for the latter by default


you can change this…
advantage: to preserve root volume when EC2 instance is terminated.


You can transfer an EBS volume to another region or az by means of using snapshots.


You can move snapshots to archive which is much cheaper.


Snapshots are usually gone once deleted, but if you have recycle bin enabled then you can retrieve them for a limited time period according to retention rule you set.



EBS Volume Types


6 types:


gp2 /gp3 SSD general purpose balances price/performance


io1/io2 SSD high performance for mission critical low latency/high throughput workloads


st1 HDD low cost HDD for frequently accessed throughput intensive workloads


sc1 HDD lowest cost HDD for less frequently accessed workloads


EBS volumes are by size, throughput, iops


NOTE: only gp2/gp3 and io1/op2 can be used as boot volumes



General Purpose SSD


cost-effective storage


system boot vols, virtual desktops, dev and test env


1GiB – 16TiB




3000 iops and 125 miB/s


can go up to 16k iops and 1000 MiB/s




small vols can do burst iops to 3000


size of volume and iops are linked max iops is 16k


3 iops per GB means at 5,334 GB we have max iops



Provisioned iops ssd


for critical biz apps with sustained iops performance

or apps that need more than 16k iops


good for db workloads


io1/io2 4GiB – 16TiB


max piops 64k for nitro ec2 and 32k for others


can increase piops indep of storage size


io2 gives more durability and more iops per gib


io2 block express 4gib – 64tib


very low latency
max piops 256k



with hdd:


cannot be a boot vol

125 mib to 16tib


throughput optimized hdd st1:


big data, data warehousing and log processing


max througput is 500 mib/s max iops 500


cold hdd sc1


for infreq accessed data
where low cost is important
max throughput is 250 mib/s max iops 250




you *dont* need to know these details for the exam, but be aware of the main difference in the variations




EBS Multi-Attach – for io1/io2 family


attaches same ebs volume to multiple instances in same az at same time


each instance has full r/w permissions to the vol


use case:


for high app availability in clustered linux apps eg teradata


apps must be able to manage concurrent write ops


only thus for very specific workloads,


you must use a cluster aware file system ie NOT ext4 xfs etc.



EFS Elastic File System


is a managed NFS-type system that can be mounted on multiple EC2s in multiple AZs.


highly available, scalable, but expensive, you pay per usage per gigabyte


use cases:


content management,


web and data sharing, wordpress


uses nfs4.1


uses security groups to control access



compatible only with linuxbased ami’s and not windows!


can enable enctryption at rest using kms


is a posix linux system with standard file api


scales automatically by itself!


exam question:


efs performance and storage classes:


efs scaling:


can support 1000s of concurrent nfs clients 10gb throughput


can grow to petabyle size automatically


performance mode


– set at efs creation time
general purpose default – latency sensive use cases such as webserver, cms etc


to maximum i/o — gives higher latency, highly paralleluse for this io1 : this is best for big data applications, eg media processing etc


throughput mode
— bursting 1tb = 50mib/s and up to 100 mib/s


provisioned: set your throughput regardless of storage size eg 1 1gib/s per 1tb storage



EFS Storage Classes


you can set up storage tiers for lifecycle management


eg move to another tier after N days…




– standard tier – used for frequently accessed files
– infrequent access tier (IA) -efs-ia: costs to retrieve files


but lower price to store, enable efs-ia by means of a lifecycle policy



Availability and Durability of EFS


2 options:


standard: can set up EFS to be multi AZ
one-zone: you use one AZ only, backups are default enabled, compatible with IA


90% cost saving

exam will ask you which tier /storage class you should use for which use case, and you need to be aware of the cost implications!




Differences Between EBS & EFS


must know for exam!




can only be attached to only one instance at a time
are locked into an AZ


gp2. io increases if disk size increase
io1: can increase the io independently.


to migrate an EBS across AZs


– take a snapshot
– restore the snapshot to the other desired AZ


note that ebs backups use up io and so you should not run them when your app has heavy traffic overhead


also, root ebs volumes get terminated by default if or when the ec2 instance gets terminated! very important to be aware of this
– but you can disable this



EFS by comparison:


can mount on 100
s of instances across AZs!


it is multi-AZ, multi-client/instance


can be used to share data


only available for linux posix, not windows!



efs more expensive than EBS but can use efs-ia to reduce costs



so: efs is more for multi instances


ebs is more for one instance





Instance Store


instance store: is an ephemeral local instance drive just for an instance – you lose it with the instance when the instance is deleted.





Continue Reading