Modifying Autoscaling Volumes

Modifying the size of autoscaling volumes is supported from agent version 1.36.0. Modifying IOPS and throughput is supported from agent version 1.40.0.

Modifying an Autoscaling Volume

You can modify an autoscaling volume's size, IOPS, and throughput. There are two options:

1. On EC2 - Use the Datafy modify API instead of the AWS modify API

2. In Kubernetes - Edit the PVC that the volume is associated with, or apply a VolumeAttributesClass to it

Do not modify autoscaling volumes directly through the AWS console or API. This can cause unexpected behaviors in your volumes and is not supported.

After autoscaling has been deactivated for a volume, you can use the AWS ModifyVolume API directly. As always, a reboot is recommended after deactivation in order to ensure expected behavior, especially if also uninstalling AutoScaler.

Volumes Attached to EC2 Instances

Call the Datafy modify endpoint with the volume ID of the original volume managed by Datafy (as it appears in the Datafy app). You should call the Datafy API wherever you currently call the AWS ModifyVolume API.

Pass any combination of volumeSizeGb, volumeIops, and volumeThroughput - at least one is required. Datafy applies the requested changes and leaves the other parameters unchanged.

When the request changes the size of the volume, provide your application with access to the new size by expanding the filesystem as well:

1. Manually - after the modification completes, resize the filesystem like you would any volume.

2. Automatically - for autoscaling volumes not currently undergoing activation or deactivation, pass expandFilesystem=true in your modify request and the AutoScaler agent will expand the filesystem for you.

expandFilesystem applies only to a size change, so it requires volumeSizeGb. Changing IOPS or throughput never affects the filesystem.

A success response means the request was accepted and the modify is in progress. Check the size of the volume or use the volume details endpoint to confirm the modify has completed.

PVCs in Kubernetes

Datafy integrates directly with the Kubernetes CSI volume expansion flow and modifications via a VolumeAttributesClass. Modifying the PVC works in the same way as for any other EBS-backed PVC - edit the relevant attribute and the CSI driver applies the change. For autoscaling volumes, Datafy's CSI integration intercepts and handles the request.

• Size - Edit the PVC's spec.resources.requests.storage to change its size.

  No additional configuration is required beyond the standard Kubernetes prerequisites for PVC expansion (allowVolumeExpansion: true on the StorageClass).

  For consistent results, use Gi units when defining volume sizes

• IOPS and throughput - Apply a VolumeAttributesClass to the PVC. Datafy's CSI integration accepts the iops and throughput parameters, for example:

  apiVersion: storage.k8s.io/v1beta1
  kind: VolumeAttributesClass
  metadata:
    name: datafy-fast
  driverName: ebs.csi.aws.com
  parameters:
    iops: "6000"
    throughput: "250"

  Reference it from the PVC's spec.volumeAttributesClassName to apply it. To change the values later, create a new VolumeAttributesClass and point the PVC at it - the parameters of an existing class are immutable.

  Only iops and throughput can be modified this way. Any other parameter in the class is rejected. Setting IOPS or throughput through the PVC annotations used by volume-modifier-for-k8s is not supported for autoscaling volumes.

Editing the PVC's size and its VolumeAttributesClass together applies both changes in a single modification.

Kubernetes retries failed expansion and modification requests indefinitely until they succeed or the PVC is edited back. While a change is in progress, the PVC reports it as in progress and Kubernetes keeps retrying - this is expected. Errors from individual attempts are available in the CSI controller pod logs.

Modifying autoscaling volumes works only on attached volumes. If a PVC resize or performance modification is issued while the underlying volume is detached - for example, during pod rescheduling - the request will fail. The request will be retried by Kubernetes and applied once the volume is reattached.

What Happens When a Volume Is Modified

When Size Is Modified

Modifying the size of an autoscaling volume will increase its Original Size - the size the volume would be without Datafy, as shown in the Datafy app. The Current Size will change depending on the state of the volume:

• If the volume's current size is smaller than its Original Size - Only the Original Size updates. The autoscaling logic will use the new Original Size as the maximum size when growing the volume as usage increases. In this state, no cooldown limitations apply, and you can modify the volume size at any time.

• If the volume has already grown to its full size - The Original Size updates, and the current size increases to keep the volume at full size. This involves modifying the underlying Datafy volumes, so the AWS cooldown applies. A subsequent modify at full size will only succeed once the cooldown has elapsed, or after a shrink action (when the underlying volumes are replaced).

When IOPS or Throughput Is Modified

The IOPS and throughput of each of the underlying Datafy Volumes will be modified to provide the new values that were requested.

Because the underlying Datafy Volumes are always modified, the AWS cooldown always applies to an IOPS or throughput change - unlike a size change below the volume's Original Size. A subsequent modify will only succeed once the cooldown has elapsed, or after a shrink action (when the underlying volumes are replaced).

Supported values for autoscaling volumes:

Parameter	Range
IOPS	3,000 - 16,000
Throughput	125 - 1,000 MB/s

While the underlying Datafy Volumes are optimizing, the volume delivers somewhere between its original and its new IOPS and throughput, exactly as AWS specifies for any modified volume. Optimizing can take time, so allow for it before you expect the new values in full.

Interaction with Ongoing Actions

A modify request interrupts any ongoing autoscaling activation, deactivation, or shrink, so your change is applied right away: AutoScaler stops the action mid-flight, then applies the modify. To resume the action after the modify completes:

• Autoscaling Activation - the volume will return to a non-autoscaling state. Re-enable autoscaling by turning the AutoScale toggle on for the volume, or by clearing the exception from autoscaling rules if they apply to the volume.

• Autoscaling Deactivation - the volume is still autoscaling. Deactivate autoscaling again with the AutoScale toggle or API.

• Shrink - the volume stays at its pre-shrink Current Size. No action is needed, shrink will begin again automatically if conditions match.

To check whether a volume has an ongoing action before you modify it, use the Optimization Actions table in the Reports page or in the volume's details page, or use the volume details endpoint.

Ongoing grow actions will be completed before the modify takes place.