Server Storage: EBS, AMI and EFS

In the previous parts we launched servers, but where does their data live? What happens to it if we delete the server? And how do you share data between several servers?

This part answers those questions and completes the servers section. You have three kinds of storage, each with its place:

EBS disks #

EBS (Elastic Block Store) is a network disk you attach to a server. It behaves like a regular disk but is independent of the server, so its data survives even if you delete the server. It's usually the disk your server boots from.

The key points:

• Tied to one Availability Zone. A volume in eu-central-1a can't attach directly to a server in eu-central-1b.
• One server at a time, normally, though one server can have several disks. The exception is Multi-Attach on io1 and io2 volumes, within one Availability Zone, and it needs a file system that understands it.
• Deleted with the server? The system disk is deleted with the server by default; extra disks stay. You can change this with the Delete on Termination setting.
• You pay for the space you reserve, not the space you use.

Volume types #

IOPS is read and write operations per second, which matters to databases. Throughput is the amount of data moved per second, which matters for large files. Hard disks (st1 and sc1) can't be boot disks.

Snapshots #

A snapshot is a point-in-time backup of a disk. After the first one, it stores only the changes, which keeps cost down. From a snapshot you can create a new disk in any Availability Zone, or copy it to another Region, so this is the right way to move a disk between Availability Zones.

Two useful features: Recycle Bin protects you from deleting a snapshot by mistake, and Archive lowers the cost of snapshots you rarely go back to.

Encryption #

Turn on EBS encryption: the data on the disk, the traffic between it and the server, and its snapshots are all encrypted with KMS keys, with no change to your application and little effect on performance. You can enable it by default for all new volumes in a Region from the EC2 settings.

Encrypting an existing unencrypted disk takes a few steps: snapshot it, copy the snapshot with encryption turned on, create a new encrypted disk from the copy, and attach it in place of the old one.

System images (AMI) #

An AMI is a ready-made image a server boots from: the operating system, software and settings. There are three sources: AWS's images, ready-made images from other companies on AWS Marketplace, and your own.

The idea that changes things: rather than having each new server install everything through User Data, prepare a server once and take an image of it:

aws ec2 create-image \
  --instance-id i-0123456789abcdef0 \
  --name "web-nginx-v1"

Now any server booting from this image is ready in seconds rather than minutes, which matters a great deal for auto scaling. Note that an image belongs to one Region, and you can copy it to others.

A common pattern: an image holding the heavy, stable parts, and a light User Data script for settings that differ per server.

Local storage (instance store) #

Some instance types have a physical disk inside the machine itself. This instance store is much faster than EBS, but it's temporary: its data is gone if you stop or terminate the server or the hardware fails. It survives only an ordinary reboot.

It suits caches, temporary files, and data with copies elsewhere. Don't put anything on it you can't afford to lose.

Shared file system (EFS) #

EFS (Elastic File System) is a network file system that mounts on dozens or hundreds of servers at once, across different Availability Zones. It grows and shrinks automatically, and you pay for what you actually use.

It suits content every server must see, such as user uploads on a site running on several servers. Two conditions: it works with Linux only, and it costs more per gigabyte than EBS. To save money, turn on a lifecycle policy so unused files move to a cheaper class automatically.

Mounting it on a server:

sudo dnf install -y amazon-efs-utils
sudo mkdir -p /mnt/shared
sudo mount -t efs fs-0123456789abcdef0:/ /mnt/shared

Which one to choose? #

Hands-on: add a disk and snapshot it #

Launch a server in a known Availability Zone, then run this from CloudShell:

# A 10 GB encrypted disk in the server's Availability Zone
aws ec2 create-volume \
  --availability-zone eu-central-1a \
  --size 10 --volume-type gp3 --encrypted

# Attach it to the server (replace the IDs with your own)
aws ec2 attach-volume \
  --volume-id vol-0123456789abcdef0 \
  --instance-id i-0123456789abcdef0 \
  --device /dev/sdf

On the server, prepare it and use it:

# Find the new disk's name, usually nvme1n1
lsblk

# Formatting wipes the disk, so only do this on a new one
sudo mkfs -t xfs /dev/nvme1n1

sudo mkdir /data
sudo mount /dev/nvme1n1 /data
echo "hello from ebs" | sudo tee /data/test.txt

Finally, take a snapshot from CloudShell:

aws ec2 create-snapshot \
  --volume-id vol-0123456789abcdef0 \
  --description "data volume before upgrade"

Summary #

• EBS is a durable disk tied to one Availability Zone, and gp3 is the default choice.
• Snapshots are backups, and the way to move a disk between Availability Zones and Regions.
• An AMI brings a server up ready in seconds, the basis of fast scaling.
• Instance store is the fastest, but its data is lost when you stop the server.
• EFS is for files shared between many servers, on Linux.

Test yourself #

Before you move on, try these questions to check you've got this part. Each one is a practical scenario, and the explanation appears once you answer.

That completes the servers section. In part six we start the high availability section: how to spread visitors across several servers with a load balancer, so your site stays up if one of them fails.