EBS Best Practices with a chessboard and person playing
Cloud Management AWS EBS

EBS best Practices: 5 Secrets of Successful EBS Users

By Uri Naiman
Senior Sales Engineer
Read More >

The simple truth is setting up your EBS volumes to maximize both performance and savings is no easy task.

As part of launching Amazon Elastic Compute Cloud (EC2) instances, most of the time, you will provision one or more Amazon Elastic Block Store (EBS) volumes as their disk storage layer.

Although EBS volumes are very easy to create and configure, costs can get out of hand if you fail to monitor them carefully. In this article, we will talk about five best practices you can adopt to help optimize EBS performance and savings.

Tip 1: Choose volume types based on data stored

We strongly recommend using individual EBS volumes for storing different application components in the EC2 instance. The choice of EBS volume types will depend on their performance requirements, overall cost optimization, and availability needs. Keep the following in mind:
  1. Ephemeral data (discarded when the EC2 instance is shut down or restarted) should not be kept on the same EBS volumes that long-term application and data files are kept. Most of the time, gp2 or gp3 disks are the best choice for ephemeral volumes; HDD might also be a possibility for servers that don’t require high performance.
  2. For swap space or Page File, consider using Instance Store instead of an EBS volume. Otherwise, using a smaller volume such as gp2 or gp3 type for swap space or the Page File might be your best option.
  3. Provision one gp2 or gp3 volume for log files, traces and dumps. Like the swap volume, the general purpose SSD ensures a cost-effective but speedy write capability.
  4. Consider creating a smaller HDD volume for application binaries, patches, and updates. That’s because these items do not require high speed access.
  5. For application data, consider using io1/io2 volume types if general types (gp2/gp3) don’t offer the desired performance.
  6. For large and diverse data storage needs you can break down where each type of data goes, such as:
    1. Provisioned io1 volumes for static, low-traffic, or lookup tables
    2. Provisioned io2 or io2 block express volumes for large, transactional tables or data.

Separation of volumes for different components not only allows “mixing-and-matching” for optimal performance and cost, it also ensures the volumes persist even if the EC2 instance crashes or if there’s a need to forensically analyze the data. It also allows encrypting individual volumes.

Also, when creating an EC2 instance, the block device mapping configuration will specify the EBS volumes to automatically create and attach to the instance when it’s launched. Block device mappings ensure that all disks required to boot an operational system are ready and available. If this is not overridden, the launched EC2 instance will use the pre-defined AMI block device mapping.

Tip 2: Define backup and restore strategies

While ephemeral EBS volumes typically don’t need backups, application and data EBS volumes do. This way, data can be restored when needed. Here’s a list of things to keep in mind when defining your backup and restore strategy:

  1. Configure EBS snapshot for all application and data volumes across all EC2 instances.
  2. Use synchronized EBS snapshots for all volumes related to the same application, platform, or process workflow. For EBS volumes attached to the same EC2 instance, this can be achieved with EBS multi-volume snapshots.
  3. Implement automated, periodic restore and mounting of EBS volumes from snapshots and check their data consistency.
  4. During EBS volume restores in important environments, use FSR to achieve performance benefits after the volume is created.
  5. Devise an automated snapshot deletion process in line with your data retention policy. You can use the Amazon Data Lifecycle Manager for this.
  6. Implement automated alerting for the failed EBS snapshot jobs.

Note that EBS snapshots are saved in S3 in a compressed format. The first snapshot contains all the content of the volume and subsequent snapshots only contain the content of the changed block. This can mean that keeping snapshots for longer might not be as expensive as you’d expect.

Tip 3: Enable security features in all EBS volumes

Enabling encryption-at-rest is commonplace with EBS volumes, and should be done for each and every EBS volume (including ephemeral ones):

  1. Enable encryption for existing EBS volumes with AWS-managed or customer-managed KMS keys.
  2. Ensure EBS volumes are configured for encryption by default.
  3. Implement automatic EBS encryption key rotation

Tip 4: Monitor performance of low-latency, high-throughput volumes

When using advanced volume types with provisioned IOPS and throughput, make sure it’s being used adequately and not being bottlenecked by other parts of the system:

  1. Use EBS-optimized EC2 instances (or EC2 instances with 10 GB networking) for high-performance volumes.
  2. Use current generation EBS-optimized EC2 instance types.
  3. Create EBS performance monitoring dashboards in CloudWatch and regularly check volume metrics to ensure:
    1. Disks aren’t overprovisioned.
    2. Volumes aren’t experiencing throttling
  4. Ensure the throughput capacity of the EC2 instance closely matches the throughput capacity of its attached EBS volumes.
  5. Choose an appropriate block size for the intended workload when formatting the volume with a file system. For example, Oracle databases have a default block size of 8 KB. If your EBS volume hosts Oracle DBF files, it’s worthwhile to use an 8 KB block size.
  6. Use automated monitoring and alerting for impaired EBS volumes.

Tip 5: Maintain EBS costs within budget

When using EC2 instances, EBS costs can be a significant chunk of the billing. It’s important to be able to optimize EBS costs with the following best practices:

  1. Create an automated process to identify and delete detached EBS volumes.
  2. Ensure all ephemeral EBS volumes have the DeleteOnTermination property set to True.
  3. Use a consistent tagging mechanism for all EBS volumes and snapshots, associating them with a cost center or team that owns those resources. These tags will be available in AWS Cost Explorer.
  4. Identify and remove already-attached EBS volumes that are not hosting any data, application, or swap space.
  5. For SSD volumes, use General Purpose instead of Provisioned IOPS unless application performance requires otherwise.

Conclusion

Using EBS volumes effectively requires careful architecting, following established processes, and some automation. However, investing in this initiative will result in better security, availability and reduced costs.

Leaning toward EBS? Learn more about our solution for managing EBS costs.

You can also contact one of our cloud optimization experts to learn how you can minimize EBS costs and maximize savings with Zesty.

blogbanner1_320x480_ZD

Related Articles

Tags

Cloud ManagementAWSEBS
blogbanner1_320x480_ZD