Hello and welcome to this course where I want to discuss a feature of the Amazon Elastic Block Store service called Multi-Attach.  I will be explaining what it is, its operational features, and its restrictions.

Before we start I’d like to introduce myself, my name is Stuart Scott and I’m the AWS Content & Security lead here at Cloud Academy, feel free to reach out to me using the details on the screen if you have any questions.

This course already assumes you have familiarity with the fundamentals of the EBS and EC2 services.  If these services are new to you, then please review our existing courses found here.

Elastic Block Store: https://cloudacademy.com/course/introduction-to-amazon-elastic-block-store-ebs-1060/

EC2: https://cloudacademy.com/course/compute-fundamentals-for-aws/ec2-elastic-compute-cloud/

If you have any feedback on this course, positive or negative, it would be greatly appreciated if you can contact support@cloudacademy.com.

Ok, so let’s get into it.  As we know, the Amazon Elastic Block store is used to provide persistent block level storage for your EC2 instances which can be detached and reattached to another instance running in the same availability zone.  For most volume types it’s only possible to have each EBS volume attached to a single EC2 instance at any one time, however, with EBS Multi-Attach you can allow multiple instances to access the same volume.  

However, this feature is very dependent on the type of volume and also the type of instance.  So let’s take a look at the circumstances in which you can use the Multi-Attach features.  

Firstly, let’s focus on the volume type.  At the time of writing this course, it’s only possible to use Multi-Attach with 2 different volumes, these being:

1. Provisioned IOPS SSD (io1)
2. Provisioned IOPS SSD (io2) 

Before we carry on, let’s take a closer look at these volume types.  Provisioned IOPS SSD volumes are typically used for scenarios that require high performance with low latency or high throughput, so they are more of a specialized volume type designed to help you deliver those missions critical workloads in your business.

This table shown here gives a breakdown of the performance characteristics of these volumes, including their durability 

It’s important to point out that these maximum performance ratings can only be performed on EC2 instances that are based on the Nitro system.  

When it comes to performance then be aware that the aggregate performance of each of the connected instances can’t exceed the maximum IOPS for the shared volume.  So if you set your Max IOPS of the volume at 32,000, and your instances could reach a max of 30,000 IOPS, then an individual instance could utilize its own maximum allowance, however, if 2 instances were trying to perform operations at the same time they would have to share the total available IOPS of the volume and would not be able to exceed 32,000.

After your volumes have been created there are some operational differences between each of them in regards to their management as this table shows.

As you can see, the io2 volume provides additional management support over that of the io1 volume type, but neither allows you to modify the size of the volume once it has been created.

Now, I want to circle back to a comment I made a minute ago about the use of Nitro instances maximizing the power of your volumes.  In fact, using Nitro instances is a requirement of using Multi-Attach, and so it’s only available for instances that are Nitro-based.  For those unaware of Nitro, it basically refers to the underlying virtualization platform of the EC2 instance.  It’s designed to be faster, cheaper and offers additional benefits such as enhanced security features.  The Nitro system also allows the introduction of bare metal instances which means you can run an EC2 instance without any hypervisor, or we as the customer, can use our own hypervisors.  If you would like to understand more about the Nitro system, then please visit the AWS service page found here: https://aws.amazon.com/ec2/nitro/

The supported list of Nitro instances is changing all of the time, so if you are looking to use the Multi-Attach feature of EBS then check the following resource to ensure the instance type you intend to use is supported: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances

So we have looked at the supported hardware requirements of Multi-Attach, let’s now look at some of the operational components.

When you create a new volume using one of the supported volume types you are given an option to make it a multi-attach volume as seen here.

You should be aware that when you enable multi-attach volumes they do not support I/O fencing, and in fact, a message will appear to alert you of this fact when you tick the box as seen here.

Also, you must create your volume in the same availability zone as the instance you want to attach it to, as much like normal EBS volumes you can only attach them to resources that exist in the same availability zone.

When connecting the volume to your Linux instances then you have a limit of 16 Nitro instances being attached to the same volume, and this rule applies for both io1 and io2 volumes.  If you are running window instances then Multi-Attach enabled volumes can be associated with the instance, however, the Windows OS will not recognize that it is a shared volume being accessed by multiple instances.  As a result, this can mean data inconsistencies and so it should be avoided and used for Linux instances instead.

When it comes to the file system that you should run on your volumes then AWS does not recommend using standard file systems like XFS or EXT4 as it can lead to data loss as these file systems are not designed to be accessed by multiple instances at once.  Instead, you are recommended to use a clustered file system.  An example of this could be GFS2 which will safely manage multi-instance access to the shared storage volume.

You can also enjoy many of the normal EBS features that you are probably familiar with, such as encryption, the way in which you attach a volume to an instance remains the same, and also you still have the delete on termination option available with your EC2 instances.  

If we look at the ‘delete on termination’ setting, what would happen if each of the instances accessing the shared volume had different settings? Well, the settings would be applied based on the last EC2 instance that was connected to the volume.  Let’s look at an example.  

Let’s say you had 5 instances attached to a Provisioned IOPS SSD (io1) volume, and each of those instances had their ‘delete on termination’ settings configured as shown.

If the last instance accessing the volume was instance A, B, or C, then the EBS volume would be deleted when that last instance was terminated, however, if the last remaining EC2 instance was D or E, then the EBS volume would remain persistent after the instance was terminated.

That brings me to the end of this topic on EBS Multi-Attach, you should now have a good understanding of how and when you could use this feature within your own environment.

If you have any feedback, positive or negative, please send an e-mail to support@cloudacademy.com, your feedback is greatly appreciated.

Thank you for your time and good luck with your continued learning of cloud computing. 

Thank you.