How To Change Your EBS Volume Sizes To Control Costs
By: Date: Categories: AWS Cloud


Amazon Elastic Block Store (Amazon EBS) provides persistent block-level storage volumes for use with Amazon EC2 instances. EBS volumes deliver low latency through SSD technology and consistent I/O performance scaled to the needs of your application. Backup and retention of EBS Volumes are managed by taking point-in-time snapshots of your Amazon EBS volumes.

Having the best possible configuration of EBS types and sizes is important for optimising the cost efficiency of your AWS Volumes. Changing the type and size of an EBS volume on the fly can be a slow process. In this post, you’ll learn how to change your EBS volume configuration to optimise your running costs from the AWS Console, as well as a quicker way to manage all of your Volumes using the Volume Manager.

The performance and correspondingly, the cost of running transactional workloads on AWS, such as databases and boot volumes, depends primarily on IOPS (Input/Output Operations Per Second).

How To Change Your EBS Volume Sizes To Control Costs

For gp2 Volumes, the IOPS rate is tied to Volume size, which determines the baseline performance level and how quickly it accumulates I/O credits; larger volumes have higher baseline performance levels and accumulate I/O credits faster. I/O credits represent the available bandwidth that your gp2 volume can use to burst large amounts of I/O when more than the baseline performance is needed.

For io1 Volumes, instead of using a credit model to calculate performance, performance can be set to maintain a consistent IOPS rate when created. The io1 is the highest performance SSD volume designed for latency-sensitive transactional workloads. While still powerful and reliable thanks to SSD, the gp2 balances price with performance for a wide variety of transactional workloads. While ideal for the most demanding I/O intensive workloads io1 does come at a higher price than dictates a requirement for more careful cost management practices.

A Typical Performance Use Case

A large e-commerce business, with generally stable transactional workloads, experiences significant but predictable peaks of demand on its resources such as Black Friday.

Following these peak-demand events, there is a need to efficiently resize EBS Volumes to prevent incurring unnecessary costs.

>>>Ask us for a review of how you’re managing your EBS Volumes<<<


1. From the Instances page of the Amazon EC2 Console, shut down the Instance to which the relevant Volume is attached.

2. Once the Instance is stopped, navigate to the Volumes page and unattach the Volume.

3. Take a Snapshot of the Volume

4. Navigate to the Snapshots page and create a new Volume from the Snapshot with the new configuration settings you require. You can configure the size and type of the Volume.

5. When the new Volume is ready, delete the old Volume from the Volumes page.

6. Attach the new Volume to the Instance (in the same location)

7. Restart the Instance

IMPORTANT: The process of changing the EBS volume type using the AWS Console results in the new Volume having a different volumeID to the old Volume and will not preserve any tags that you had assigned to the original Volume. If using the AWS Console, ensure you copy the tags associated with the Volume being copied at the time of creation.


1. From the Servers page, navigate to the Manage Volumes page.

2. To edit a Volume configuration, click .

3. Edit the volume size to reflect your desired size in GB, then click ✓ to confirm.

NOTE: If changing the Volume size and/or volume type, you may experience some delays while the change processes. CloudMGR will preserve any tags assigned to the original Volume and duplicate them to the new Volume, however, the volumeId will change.

Using the Volume Manager is a convenient way to centrally view and manage all of your attached and unattached Volumes from a single location, as well as quickly make configuration changes on the fly.

Request a Demo to see how the Volume Manager can help you automate your AWS environment.

Leave a Reply

Your email address will not be published. Required fields are marked *