Understanding EBS Multi-Attach and the EC2 Instances That Support It

During my previous post on EBS storage i saw a checkbox on multi attach but could not figure why most instance could not allow such so i did extensive research on the instance that could and its implication.
Amazon Elastic Block Store (EBS) is an essential service in AWS that provides block-level storage for EC2 instances. While most of us use EBS volumes in a one-to-one fashion (one volume per instance), EBS Multi-Attach changes the game by allowing a single EBS volume to be attached to multiple instances simultaneously.

In this post, we'll explore:

• What EBS Multi-Attach is
• What volume types support it
• Which EC2 instance types can use it
• Real-world use cases What Is EBS Multi-Attach? EBS Multi-Attach allows an io1 or io2 EBS volume to be simultaneously attached to multiple EC2 instances within the same Availability Zone. Each instance can read and write to the volume at the same time. But exercising caution: You must use a cluster-aware file system (like GFS2 or OCFS2) to avoid data corruption. EBS Volume Types That Support Multi-Attach Only specific EBS volume types support Multi-Attach:

1. io1 : Yes, Provisioned IOPS SSD
2. io2 : Yes, Better durability than io1
3. gp2 : No, General Purpose SSD
4. gp3 : No, More configurable GP SSD
5. sc1/st1: No, Throughput Optimized & Cold HDD To enable Multi-Attach, the volume must be created with the --multi-attach-enabled flag

EC2 Instance Types That Support EBS Multi-Attach
Only selected Nitro-based EC2 instances support Multi-Attach.
_ Nitro-based instance families include those optimized for general purpose, compute, memory, storage, and accelerated computing workloads._
Here are the following key families that support it:

• m5, m5d, m5n Yes General purpose
• c5, c5d, c5n Yes Compute optimized
• r5, r5d, r5n Yes Memory optimized
• m6i, c6i, r6i Yes Latest Intel-powered Nitro families
• z1d Yes High CPU with memory balance
• u-6tb1.metal Yes Bare metal (SAP HANA use case)

While many EC2 instances like T3, T4g, and A1 technically support EBS Multi-Attach due to their Nitro-based architecture, they are not ideal for production use. This is mainly due to limitations such as burstable CPU performance, low network and storage throughput, and limited scalability. For real-world clustered applications or shared-volume setups, AWS recommends using larger Nitro-based instances like C5, M5, or R5 families, which provide consistent CPU power, enhanced networking, and higher EBS bandwidth.

Instance Types That Do Not Support Multi-Attach

• t2, t3, t3a, t4g (burstable instances)
• i3, i4, d2 (use instance store)

• a1, g4, inf1, mac* (specialized instances)
  Real-World Use Cases

• High Availability Clustering: Run clustered apps like Oracle RAC or SAP HANA that need shared block storage.

• Distributed Filesystems: Attach the same volume to multiple nodes running a clustered filesystem.

• Failover Systems: If one EC2 instance fails, another can instantly access the same volume.

for this tutorial we would be working with t3 micro because it is on free trial but if you want if you want try out other instance it works the same way,
step 1:
lets create our volume: if you are confused on it check my other post on EBS storage creation, then once you are done, make your way to EC2 instance and create two t3 micro instances, if you don't know how to create instance check my previous post on how to create ec2 instance for EBS storage, make sure that the instances are in the same availability zone

now we have both the volume and the instances, the next thing is for us to attach the volume to the two instances

step 2:
if you new to my post check my previous post on how to connect to EBS storage, connect to the instances in your cmd, then when you are in type in

lsblk

as you can see from the above the two instance connect to the volume

i would show a example whereby i write a to a file to the volume in one instance then would show it in the other instance, but it can either corrupt the file data written by one and won't reliably show up on the other and during my research i also noticed amazon Linux doesn't support GFS2 or OCFS2
Amazon Linux is based on a minimal Fedora/CentOS core, It doesn't include the gfs2-utils package.
but using other Linux packages like Rocky Linux, CentOS, or RHEL

it work in this situation as i am doing them concurrently but if i were to echo and cat in one instance then stop the instance and try to read it in another instance it would be
In most cases:

• The file /data/notepad.txt will not appear on Instance B.
• Or it might show incomplete content, or
• You’ll see I/O errors or corruption messages in /var/log/messages.

but some reason why it was able to work was

• When you write a file, the OS caches that data in memory.
• It doesn't flush changes to the disk immediately — especially without a forced sync.
• So Instance B may not see updates unless the data is flushed and reloaded. please do take not as not to use it in real life application as it can fail and it not reliable this is just a test demo

Just because it “works” now doesn’t mean it’s safe.
EBS Multi-Attach + ext4 is like:
Driving on the wrong side of the highway during a quiet night.
You might not crash now, but eventually, you will.