Search for a command to run...
Hi! I'm Guille Ojeda, Cloud Architecture Consultant To put it simply, I create simple solutions for complex technical problems.
My focus is on designing scalable, secure, and cost-effective cloud solutions that startups, scaleups and SMBs can lean on to grow.
I lean on years of experience in cloud architecture and consulting to deliver solutions that are easy to understand and manage.
No comments yet. Be the first to comment.
What Are Agentic AI Architectures? I won't waste your time with a long, fluffy introduction about how AI is changing the world. Let's get straight to the point: agentic AI architectures are fundamentally different from the prompt-response pattern you...
Building distributed systems requires putting a lot of attention on communication between components. These components often need to exchange information asynchronously, and that's where message queues and pub/sub systems are the go-to solution. AWS ...
Database failures are inevitable. Even with the most reliable hardware and software, something will eventually break. AWS RDS Multi-AZ deployments promise to handle these failures gracefully, automatically failing over to a standby database when prob...
There are two managed relational database services in AWS: Amazon Relational Database Service (RDS) and Amazon Aurora. Both provide the benefits of a fully managed database solution, but they have distinct features and use cases. In this article, we'...
Containers offer a lightweight, portable, and scalable solution for running software consistently across different environments. But as the number of containers grows, managing them becomes increasingly complex. That's where container orchestration c...
Elastic Block Store (EBS for short) is a block-level storage service for EC2 instances. Essentially it's a virtual SSD or HDD that you attach to EC2 instances, so they can have persistent storage. Honestly, EBS is pretty boring to talk about, but if you're storing a ton of data, knowing the fine details can save you a lot of money. Let's start with the basics.
An EBS volume is a virtual block-level storage device that can be used by EC2 instances to store persistent data. An EBS volume acts like a HDD or SSD, but behind the scenes they're actually an array of physical discs in a RAID configuration, in the same datacenter but physically distanced from each other to minimize the probability of simultaneous failures (e.g. due to fires).
When you create an EBS volume you can define the size, the performance (only for some volume types), and the volume type, which is explained in the next section. Size and performance can be changed later, but not volume type.
EBS volumes exist separate from EC2 instances, and can be detached to one instance and attached to another one. When you create an EC2 instance, an EBS volume is created and attached as a root volume, and the default behavior is to delete it when the instance is terminated (this can be changed). But it's important to understand that they are actually a separate service from EC2.
As is often the case in AWS, there's different types of resources to serve different use cases and needs. These are the types of volumes you can create in EBS. Remember that you set this on creation and cannot change it later.
This is the general-purpose volume type, which you should use for most stuff, and default to when in doubt. Size and performance (IOPS) can be configured separately (unlike the previous generation, GP2). Here are some details:
Volume Size: 1 GB to 16 TB
Durability: 99.8% to 99.9%
Max IOPS/Volume: 16,000 (operations of 16K)
Max Throughput/Volume: 1000 MB/s
Latency: single digit milliseconds
Price:
$0.08/GB-month
$0.005/provisioned IOPS-month over 3,000 (the first 3,000 are free)
GP3 is great for most use cases, but if you need more performance, you go with IO2. If you're running a database on an EC2 instance, this is the one to pick. Size and performance (IOPS) can be configured separately, and the limits are higher than for GP3. Details:
Volume Size: 4 GB to 16 TB
Durability: 99.999%
Max IOPS/Volume: 64,000 (operations of 16K). 256,000 IOPS with io2 Block Express.
Max Throughput/Volume: 1,000 MB/s. 4,000 MB/s with io2 Block Express.
Latency: single digit millisecond
Price:
$0.125/GB-month
$0.065/provisioned IOPS-month up to 32,000 IOPS (no free IOPS)
$0.046/provisioned IOPS-month from 32,001 to 64,000 IOPS
This one is actually an HDD (virtual, but backed by real HDDs). Spinning disks! The use case is sequential access to data that sits contiguously in the physical disks. In general, that means data that is written as a long stream, and then read as a long stream, instead of having different parts accessed at random. It offers pretty good performance for that compared to GP3, at almost half the price. Here are the specs:
Volume Size: 125 GB to 16 TB
Durability: 99.8% to 99.9% durability
Max IOPS/Volume: 500 (operations of 1 MB, not 16K)
Max Throughput/Volume: 500 MB/s
Price: $0.045/GB-month
Maximum performance varies per size, at 40 MB/s per TB. Additionally, ST1 Volumes use a burst credits system to accumulate credits while usage is below peak throughput, and consume them to achieve for a period of time a higher throughput than the soft limit. In short, a 12.5 TB volume always performs at max 500 MB/s, and any volume below that has a lower soft limit, but can reach 500 MB/s for a short period of time. This is better explained here.
Certification Exam tip: ST1 volumes can't be root volumes.
Stop copying cloud solutions, start understanding them. Join over 45,000 devs, tech leads, and experts learning how to architect cloud solutions, not pass exams, with the Simple AWS newsletter.
SC1 volumes are also HDDs, aimed at offering the lowest price per GB of all block storage options. They're recommended for infrequently accessed data that needs to be accessed from block storage (the C in SC1 stand for Cold). If you don't strictly need block storage access, S3 Infrequent Access or Glacier are also viable options.
Volume Size: 125 GB to 16 TB
Durability: 99.8% to 99.9% durability ← Much less than S3!
Max IOPS/Volume: 250 (operations of 1 MB, not 16K)
Max Throughput/Volume: 250 MB/s
Price: $0.015/GB-month ← Slightly higher than S3 Infrequent Access, but with EBS SC1 you're not billed for reads and writes
SC1 volumes use the same burst credit system as ST1, though their performance is lower.
Certification Exam tip: SC1 volumes can't be root volumes.
IO1 (predecessor of IO2) and GP2 (predecessor of GP3) were the norm a few years ago, and you'll most likely find some still in production. IO1 works just like IO2, but with less durability, and a higher price at high IOPS. GP2 has the same use cases than GP3, but performance was tied to volume size and it used a burst credits system, like ST1. It's also 25% more expensive than GP3.
Cost-savings tip: Migrate GP2 volumes to GP3.
An EC2 instance comes with an EBS volume associated with it, called the root volume. This volume contains the OS, some libraries and programs, and some configurations. This is where the EC2 instance boots from when starting up.
You can attach up to 128 EBS volumes to an instance (depending on instance type), so long as they're in the same Availability Zone as the EC2 instance. Once a volume is attached, you'll see it in the OS just like if you were physically attaching a disk, and you can mount it on the OS or file system.
You can detach an EBS volume from an instance and attach it to another instance as many times as you want, so long as both instances are in the same Availability Zone as the EC2 instance.
Volumes of any type other than IO1 or IO2 can only be attached to once instance at a time. IO1 and IO2 volumes can be attached to multiple instances at the same time, in read-write mode.
EBS volumes are zonal resources. They exist in a single Availability Zone, so they are not highly available. This is also true for IO2 volumes, which offer durability of 99.999%.
EBS volumes are redundant within that Availability Zone, so data loss is significantly less likely than with a single disk. They're backed by an array of physical disks in a RAID configuration.
It's important to understand that the lifecycle of an EBS volume is separate from that of the EC2 instance. You can create them, attach them, detach them and delete them on their own. You can also configure them to be deleted when the EC2 instance they're attached to is terminated, which is the default for the root volume.
EBS volumes can be encrypted using KMS, in a way that's entirely transparent to you. You don't need to manage or use any encryption keys, the EBS service automatically fetches them and decrypts the data when you initiate a read operation.
You can enable Encryption by Default on your AWS account, which means every new EBS volume you create will be encrypted unless you explicitly configure it not to. This is a highly recommended best practice for AWS security.
EBS snapshots are point-in-time copies of EBS volumes, used to back up and restore data. They're incremental, which means they only capture the data that has changed since the last snapshot. This makes EBS snapshots more efficient and cost-effective than full-volume backups. The size of an EBS snapshot is calculated based on the amount of data stored in the volume at the time the snapshot was taken.
Snapshots are regional resources, meaning you can use them to hold a copy of an EBS volume and, if the volume's Availability Zone fails, restore it from the snapshot in a different Availability Zone. They can also be shared across regions and AWS accounts. Here's where you can read more about automating EBS snapshots for Disaster Recovery.
You should default to GP3 volumes, and only use the other volume types if you have a specific use case, or you know you need more performance. Here's a guide to benchmark EBS volumes.
EC2 Instance families have a limit on performance with EBS volumes, which is independent of the EBS volume itself. If you need high performance, it may not be enough to just use a better EBS volume such as IO2. You'll also need to look into whether your EC2 instances support that level of performance, and possibly use EC2 instances that are Storage Optimized.
EBS performance is also limited by instance size. You can use the EBSIOBalance% and EBSByteBalance% metrics in CloudWatch to help you determine whether your instances are sized correctly. Instances with a consistently low balance percentage should be increased in size, and instances where the balance percentage never drops below 100% should be reduced in size.
If you need extreme performance, you'll need to use EC2 Instance Store. It's ephemeral (that means non-permanent) block storage with a much higher performance than EBS. The main disadvantages are the pricing (you need an EC2 instance of a special family, which isn't cheap) and the fact that data is lost if the instance is stopped or terminated.
This comes at no cost and no performance hit to you, so it should be a no brainer. First, you should enable Encryption by Default, so all future EBS volumes are created with encryption. Then you should encrypt existing EBS volumes by creating a snapshot of them, encrypting that snapshot and creating a new volume from the encrypted snapshot.
GP3 volumes can do anything that GP2 volumes can, and they're 20% cheaper. Here's a guide to migrate your existing GP2 volumes to GP3.
Remember that EBS volumes are zonal resources, meaning that if an Availability Zone goes offline you won't be able to access them. Furthermore, most EBS volume types offer 99.8% durability, making data loss or corruption entirely possible. To guard against that, create Snapshots of your EBS volumes.
Snapshots are regional, so you're good if an AZ goes down. But if you want to do cross-region disaster recovery, you'll need to export the snapshots to another AWS region. If you're exporting encrypted snapshots, use a multi-region KMS key.
You can use Data Lifecycle Manager to automate creating and exporting EBS snapshots.
Accessing a block for the first time on an EBS volume created from a snapshot has huge latency, because the data is lazy loaded from S3. To avoid this, you can initialize (pre-warm) the volume before putting the volume in production, by accessing each block once. You can do this on Linux by attaching the volume to an EC2 instance, installing the fio utility, and running the following program (example for a volume called xvdf)
sudo fio --filename=/dev/xvdf --rw=read --bs=1M --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize
Another option is to enable EBS fast snapshot restore on the snapshot. This will ensure AWS does the initialization for you, and is much faster. However, it costs $540/month per snapshot (regardless of size), so I prefer the manual option.
Stop copying cloud solutions, start understanding them. Join over 45,000 devs, tech leads, and experts learning how to architect cloud solutions, not pass exams, with the Simple AWS newsletter.
Real scenarios and solutions
The why behind the solutions
Best practices to improve them
If you'd like to know more about me, you can find me on LinkedIn or at www.guilleojeda.com