Scalability concepts

The two types of scalability, vertical and horizontal.

Vertical scalability is where you increase the size of the instance in order to handle more requests e.g. you may add a larger processor or more ram to an ec2 instance in order to handle more requests.

Horizontal scalability is where you add more instances in order to handle the increased number of requests e.g. you may have one small server and then in order to handle more requests you add two more servers.

Vertical scalability is very common for non distributed systems such as a database whereas horizontal scalability is common for web applications.

High availability is the premise where if one server fails another server can carry on running your application or system. 

The main goal of high availability is to survive a data center loss and high availability usually goes hand in hand horizontal scaling.

The best way to provide high availability via AWS to place your ec2 instances in separate availability zones.

EFS versus EBS

The difference between EBS and EFS.

EBS volumes are only available in one Availability Zone and can be attached to only one ec2 instance at any one time.

Remember when taking a backup of your EBS volume that you should not perform a backup while your ec2 instance is handling traffic.

By default the EBS root volume will be terminated when the ec2 instance gets terminated although you’re able to override this setting via the management console.

EFS Elastic File System is able to be mounted across hundreds of ec2 instances across multiple Availability Zones and can be used to share files across multiple ec2 instances.

EFS is only available for Linux ec2 instances and is about three times more expensive than an EBS volume.

EFS supports storage tiers meaning you have the ability to move files to a different storage tier after a specified number of days which will enable some cost savings.

With EBS you have to provision the size of the volume when it is created where as for EFS you are only billed for what you use. 

In summary EFS is a file system which is able to be used across many ec2 instances and across many Availability Zones where as an EBS is only available in one Availability Zone and attached to one ec2 instance 

AWS EFS – Elastic File System

EFS is an acronym for elastic file system. AWS EFS is a network file system which is managed and is able to be mounted on more than one ec2 instance

Elastic file system is available to many ec2 instances in one or more Availability Zones and therefore allows multiple EC2 instances to share data.

AWS EFS is scalable, highly available but more expensive than EBS and you pay for what you use.

EFS has a security group attached to it and then the EFS will then be able to be attached to ec2 instances across multiple Availability Zones.

Is important to note EFS is only compatible with Linux AMI as it leverages the Linux POSIX file system and not Windows AMI.

The use cases for EFS are for web servers, contact management, data sharing and online blogs.

EFS uses NFSv4.1 protocol and requires a security group to control access to the EFS.

Encryption is provided using AWS-KMS and the file system is able to scale automatically so you do not have to reserve capacity 

EFS performance and storage.

EFS is able to scale to use thousands of NFS clients and can grow to petabyte-scale automatically.

EFS is available in two modes:

Performance mode is set when you create the EFS.

There are two types of performance modes:

General Purpose which is more geared towards general purpose such as web servers, content management systems etc. 
Maximum IO is available if you are trying to perform a Big Data workload on EFS. This mode comes at a cost of high latency but it does provide high throughput and is used in scenarios such as big data and media processing.

Throughput mode

There are two types of Throughput modes:

Bursting which is set at 1 Terabyte = 50 Megabyte with a burst of up to 100 Megabytes per second

Provisioned is where you specify the throughput regardless of the storage size. As an example, where an EC2 instance has a very small filesystem and requires a very high throughput then use Provisioned Mode for EFS.

EFS supports storage tiers which is essentially a lifecycle management feature where you’re able to move files to a different tier after a set amount of days.

There are two modes of storage tiers:

  • Standard which is used for frequently accessed files
  • Infrequent access (EFS-IA) for files which are not accessed frequently. It will cost money to retrieve files but is much cost effective to store the files

EC2 Instance Store

Whilst EB2 network drives offer good but limited performance, there is another type of volume store called EC2 Instance Store.

An EC2 instance store is a high performance hardware disk which offers better I/O performance than an EB2 volume.
However, be aware that an EC2 Instance Store will lose all their information once they are stopped and are therefore ephemeral.

The use case for an EC2 Instance Store is for caching, storage of temporary information, scratch data etc, essentially any temporary information you can afford to lose.

The backup and replication of EC2 Instance Stores is the responsibility of the AWS user and EC2 Instance Stores run the risk of data loss in the event of hardware failure.


AMI is an acronym for Amazon Machine Image and represents an EC2 instance which has been customised (Think of an AMI as a template).

There are three ways to instantiate an EC2 instance from an AMI:

  • From the library of available Amazon AMI images; an example is when we create a new t2 micro image via the AWS management console
  • From a library of commercially available AMI images via the AWM Marketplace AMI
  • By creating your own AMI template based on your own software, configuration

Note that AMI are built for a specific region and the use case is when you wish to have faster EC2 configuration and start times as the software is already pre-installed on the EC2 image

The process for creating an AMI is as follows:

  • Create a base EC2 instance and then customise the instance with the required configuration and software
  • Stop the instance to ensure data integrity (i.e. Nothing is being written to the instance whilst an AMI is being created from it)
  • Create the AMI; doing so will also create the necessary EBS volume snapshots

The AMI is now complete and available for other EC2 instances to be launched from it

AWS EBS Snapshots

Think of an EBS Snapshot as a way of backing up an EBS volume at a certain point in time.

Recommended best practice for creating a backup of an EBS volume is to detach the EBS volume from the EC2 instance (Not necessary but recommended) and then create the snapshot.

Once a snapshot of an EBS volume has been created then it is possible to copy the snapshot of the EBS volume to a different Availability Zone/ Region and attach the EBS volume to an EC2 instance in the new Availability Zone / Region.

AWS EBS Encryption

Creation of an encrypted EBS volume results in the following:

  • Data at rest is encrypted by default
  • All EBS Volume snapshots are encrypted and therefore all volumes created from the snapshot will also be encrypted
  • Data moving between the EBS volume and EC2 instance is also encrypted
  • AWS handles all the encryption and decryption transparently and therefore there is no maintenance needed on behalf of the AWS user
  • EBS encryption uses AWS Key Management Service (KMS) specifically AES-256 encryption

From a latency point of view AWS Encryption has minimal impact and it is possible to encrypt an un-encrypted snapshot by copying it, enabling encryption and then attaching the encrypted volume to the EC2 instance.

AWS EBS Multi-Attach

EBS multi-attach is available for specific EBS Volumes (Only for Io1 and Io2 family) and provides a way to attach a single EBS volume to multiple EC2 instances in the same Availability Zone.

Each EC2 instance needs to be able to have full read and write permissions to the attached EBS volume.

The use case for EBS Multi-Attach is very specific such as providing higher availability within a clustered Linux application such as Teradata.

The application must be able to write concurrently into the same EBS volume so the file system must be cluster aware.

AWS EBS Volume Types

General Purpose SSD – Low latency, cost effective storage good for Development, Test Environments, Virtual Machines (Desktops), Boot Volumes etc. Size between 1 Gigabyte and 16 Terabytes

Provisioned IOPS – Used for mission critical business applications which require sustained IOPS performance (Think Databases) or where the application needs more than 16 000 IOPS. Size between 4 Gigabyte and 16 Terabytes. Supports multi-attach of EBS volumes

Hard Disk Drives – Size from 125 Megabyte to 16 Terabytes and cannot be used for a boot volume. They come in two types of volumes:

1) Throughput Optimised HDD – Used for Data Warehousing, Big Data, Log Processing etc
2) Cold HDD – Used for data that is infrequently accessed such as archived information and where you need the lowest possible cost

AWS EBS Volume

EBS is an acronym for Elastic Block Storage and is a network storage volume which is attached to an EC2 Instance.

EBS Storage allows EC2 instances to save information even after the associated EC2 instance is terminated and are bound to a single Availability Zone.

Because EBS volumes are a network drive they are able to be detached from one EC2 instance and then re-attached to another EC2 instance extremely quickly which is good for fail over.

It is feasible to attach more than one EBS volume to any EC2 instance at any one time and likewise it is possible to detach and EBS volume and not re-attach it to another EC2 instance.

When creating an EBS volume the size of the volume and the number of IOPS must be specified in advance although it is possible to increase the capacity at a later date.

Also, when creating an EBS volume there is a “Delete on Termination” attribute which when set will mean that the EBS volume will be deleted when the EC2 instance is terminated.