Did you know that some AWS EC2 Instances come with blazing fast NVMe SSDs that we can use as file systems or as swap space?
Well, they do! Over the course of the next few articles, we’ll take a look at how we can mount a filesystem onto the local NVMe SSD of an AWS EC2 Instance, then use the SSD as swap.
Resource: List of AWS EC2 Instance Types and Offerings
In this article, we’ll learn about NVMe SSDs and how they differ from AWS EBS volumes. The NVMe drives are Direct Attached Storage, while EBS volumes are Network Attached Storage. By putting in the extra work to enable the NVMe SSD, we can enable faster data transfer for our applications than using a typical EBS volume.
Then, we’ll take a further look at why NVMe SSDs may prove to be particularly useful to us, especially as swap space. This is effectively cheap secondary RAM.
Resource: Prices of AWS EC2 Instance Types
This is a Multi Part Article Series
In a future article, we’ll see how we can use EC2 Launch Templates in order to deploy an Amazon Machine Image (AMI) that configures the local NVMe SSD as swap on launch of an AWS EC2 instance. This can be used when deploying machines for general usage.
Then, we’ll learn how to configure Kubernetes so that our EC2 Instances deployed with EKS will be able to use swap space!
What is a NVMe SSD?
NVMe SSD stands for Non-Volatile Memory Express Solid State Drive.
It is a type of storage disk that uses a high-speed interface and a non-volatile NAND-based flash memory to store data.
NVMe SSDs offer much faster data transfer rates and lower latency compared to traditional hard drives and SATA-based SSDs. This is because they use a direct, high-speed connection between the storage and the CPU via the PCIe bus.
NVMe SSDs are typically used in high-performance computing applications, such as gaming, video editing, and server applications.
NVMe SSD Seem Like a Winner
My thoughts: NVMe SSDs seem like a real winner when compared to normal SATA-based SSDs.
Since AWS gives us NVMe SSDs for free (as they are included with quite a few EC2 instances), we should definitely take advantage of them.
Block Storage (EBS) vs NVMe SSDs (EC2 Instance Store)
How are these different than AWS EBS volumes?
The TLDR is that the NVMe SSDs that come with the EC2 Instance are mounted on the actual instance themselves and thus should always be faster than EBS volumes, which are connected to an EC2 Instance via the network.
More specificlly, EBS volumes are apart of a class of storage devices called Network Attached Storage, while local NVMe SSDs are Direct Attached Storage. These two storage classes both have there pros and cons.
EBS Volumes are Network Attached Storage (NAS)
EBS volumes are apart of a class of storage devices called Network Attached Storage (NAS). This means that they are connected to our AWS instances in the cloud via the network.
This is an important distinction as NAS’s come with their own benefits and drawbacks.
Simply put:
- Advantage - Multiple users can read and write to a NAS by simply connecting to it.
- Advantage - A NAT can continue to persist even after an EC2 instance disconnects from it.
- Disadvantage - Read/write is limited by network speeds and bandwidth.
NVMes are Direct Attached Storage (DAS)
Compare this to Direct Attached Storage, where the disk is connected directly to the EC2 machine. This is similar to your computer that you’re using to read this article. So this should be a familiar concept.
We can imagine we won’t see the same drawbacks as NAS in this case. So, some advantages and disadvantages of DAS are the following:
- Advantage - Fast read/write speeds as the disk is directly connected to the EC2 instance and does not require to travel across the network.
- Disadvantage - Data only persists as long as the EC2 instance is in use.
- Disadvange/Advantage - Data is less accessible. Data is only accessible to the machine that the storage is connected to.
- In terms of security, this may be a safer option. This is why I label this as both a disadvantage and an advantage.
What Kind of AWS Storage should I use?
The usage of EBS volumes and local NVMe SSDs depend on our application. So… the answer is: it depends.
Use EBS for Persistant Storage
With that said, EBS volumes should be used for use cases where data persistance is a requirement.
We can attach them easily to our EC2 machines without any extra steps, since the AWS Launch Instance UI let’s us attach and mount an EBS easily enough.
Resource: How to Attach an EBS Volume to An EC2 Instance
Use NVMe SSDs for Fast Temporary Storage
The local NVMe SSD option is always better when our application calls for fast read/write operations.
Therefore, for usage as swap space, we’ll certainly want to use local NVMe SSDs so that we can get closer to the performance that dedicated RAM offers us.
Although, to be clear, nothing beats the performance of dedicated RAM.
Assuming we’re all on the same page about local NVMe SSDs and how they’re superior to EBS volumes in terms of performance — let’s learn more about swap space and why it may be useful to us.
What is Swap Space?
In high level terms, swap space is essentially just secondary RAM, albeit it’s slower than typical RAM on a machine.
Usually, when more RAM is needed to support all the applications that are requesting it, the OS may “swap” memory allocated in RAM to disk — which ultimately frees up RAM to be used for other applications.
Therefore, we can allocate disk space as swap space as a way to soft increase memory limits of an EC2 Machine.
Swap Space is Slow
One drawback to using swap is that it is much slower than using dedicated RAM. If your application requires constant access to high amounts of RAM, it may just be better to use an EC2 machine that can meet the resource demands of the application.
However, if your application is prone to spikes of RAM usage, using swap space may be a viable option.
Why Not Deploy A Larger EC2 Machine Instance?
Let’s assume that we have an EC2 machine of instance type g4dn.xlarge which will cost us per hour (On-Demand) $0.526. The g4dn.xlarge
is advertised as having 4vCPU and 16Gb of RAM.
If every now and then, our application demanded 32Gb of memory, we would be out of luck unless we either increase the size of our machine to the next class g4dn.2xlarge
which is advertised as having 32Gb of memory. This would increase our hourly costs to $0.752.
Here’s a summary of what we know so far:
g4dn.xlarge | g4dn.2xlarge |
|
---|---|---|
RAM |
16Gb | 32Gb |
$ / hour |
$0.526 | $0.752 |
$ / 30 days | $378.72 | $541.44 |
$ / 365 days | $4607.76 | $6587.52 |
As we can see, the 30 day cost of running a g4dn.xlarge
is $378.72, while we are strapped to pay $541.44 for a g4dn.2xlarge
machine.
The difference is $162.72 a month, and this difference balloons to $1,979.76 if we consider it at the annual level.
For a large corporation with buckets of cash on-hand, this may seem like a drop in the bucket… but can we enable extra RAM at a cheaper cost?
Using an NVMe SSD as Swap Space is Cheaper
If we use an AWS EC2 instance that comes with a NVMe SSD, the cost of swap space is vritually free.
As I mentioned previously, using swap space does not beat the performance of using dedicated RAM. Therefore, depending on your use-case, paying for the extra RAM may be worth it.
Next time
We’ll dive into configuring EC2 Launch Templates to see how we can deploy an EC2 machine with an included NVMe SSD enabled as swap!