Can you shrink an Azure managed disk?

A managed disk is billed on the size you provision, not on the data it holds. Premium SSD and Standard SSD are billed by size tier, so a 512 GiB Premium SSD costs the same whether it holds 500 GiB or 5 GiB. Premium SSD v2 is billed for the GiB you provision, plus any IOPS and throughput above its included 3,000 IOPS and 125 MB/s.

Disks grow for good reasons: a migration, a bulk import, a log spike, a busy season. Growing is easy. Azure can expand many data disks without stopping the VM, and you then grow the partition and the filesystem. When the data shrinks again, the space stays, and so does the charge.

The worked example on the Amoeba page shows the effect: a Linux VM with four 512 GiB Premium SSD data disks, 2,048 GiB in all, holding 1,000 GiB of data. More than half of what is billed is empty.

A disk is a block device, and the filesystem on it can place data in any block, including the last ones. Cutting the end off the device would cut through that data. Shrinking safely means the filesystem first moves its data away from the end, and Azure can’t do that from outside your VM. Some filesystems can’t shrink at all: XFS can only grow.

For a data disk on a Linux VM, the usual route is a copy:

1. Create a managed disk at the size you want and attach it to the VM.

2. Partition it, create a filesystem and mount it at a temporary path.

3. Copy the data with rsync while the application keeps running.

4. Stop every service that writes to the old mount.

5. Run rsync again to copy what changed since the first pass.

6. Point /etc/fstab at the new disk’s UUID and mount it at the old path.

7. Start the services and check them.

8. Snapshot the old disk, detach it, and delete it when you no longer need it.

What it costs you:

• Downtime from step 4 to step 7, for every service on that mount.
• Risk: a mistake in /etc/fstab can stop the VM from booting, so add the nofail option and test a reboot.
• Both disks on the bill while you work.
• A new fixed size. When the data grows, you expand again. When it shrinks, you copy again.

This covers data disks. Shrinking an OS disk is a harder job, and Amoeba works on data disks only.

Amoeba turns the copy into a one-time move, then resizes online from there.

• The pool. Amoeba installs its agent through Azure Run Command and builds one pool beside your disks, sized to the data on the VM’s data mounts plus 20%, and at least 50 GiB larger than the data. The pool is one btrfs filesystem across several managed disks, and each data mount keeps its path.
• The copy. The agent copies each data mount onto the pool inside the VM, then copies what changed until the pool has caught up. The copy slows down or waits when the VM’s disks are busy.
• The switch. The agent stops the systemd services that hold the data mounts open, checks that nothing is left to copy, backs up /etc/fstab and mounts the pool at the same paths. Then it starts the services again. That restart is the service interruption. It happens again only if you go back or Amoeba retries a failed switch.
• The soak. For 48 hours Amoeba watches the pool, and “Go back” returns the VM to its source disks. After the soak, each source disk is snapshotted, then deleted once its snapshot is complete. The snapshot is kept for 7 days.
• After the move. When data grows, Amoeba adds a disk to the pool, or grows one in place, without unmounting. When data shrinks, it moves one disk’s data onto the others, checks it, removes the disk from the filesystem, then detaches and deletes it, which stops its billing. A disk leaves the pool only when it is empty.

On Linux, Amoeba needs systemd, kernel 5.14 or later, btrfs, and a VM size with at least 8 data-disk slots. VMs in the Red Hat family are not moved.

The same rule holds on AWS. Elastic Volumes let you increase an EBS volume’s size, change its type or adjust its performance while it stays attached, but not decrease its size. The manual route above works the same way.

Amoeba does the same job on AWS. It pools the non-root EBS data volumes of running EC2 instances onto gp3 volumes in the instance’s Availability Zone, installs its agent through AWS Systems Manager, and takes an EBS snapshot of each source volume before deleting it.