VDI Storage Optimization: What Autoscaling Doesn’t Fix

Summary

• Autoscaling right-sizes compute, but the image and storage layer keeps billing and keeps demanding management effort after your scaling policy is in place.
• On Oracle Cloud Infrastructure (OCI), every desktop boots from a boot volume billed on provisioned GB. Stopping an instance stops the compute meter on standard shapes, but the boot volume keeps billing until it is deleted.
• Image sprawl is a management cost as well as a storage cost. One image per user persona, with the applications that vary between users published as Remote Apps from separate hosts, keeps the image estate small.
• Profiles and user data belong on an SMB file share for FSLogix, not on each desktop’s boot volume, so the desktops can stay small and stateless.
• OCI has no ephemeral OS disk. The storage levers are smaller boot volumes, fewer running instances, and destroying the instances you no longer need, which releases their disks.

How do you optimize VDI images and storage? Keep one lean image per user persona and publish the applications that vary between users as Remote Apps instead of installing them in every image. Move profiles and user data to an SMB file share for FSLogix, keep boot volumes as small as the OS and agents allow, and destroy instances you no longer need instead of leaving them stopped, because a stopped instance still pays for its boot volume.

Why does VDI storage optimization matter after you’ve already added autoscaling?

VDI storage optimization is the discipline of controlling the cost and management effort of the image and storage layer of a virtual desktop estate, separate from the compute layer that autoscaling already handles. If you have deployed cloud VDI and turned on autoscaling, you have solved the most visible half of the cost problem: your instances scale out under load and scale in when users log off, so you stop paying for idle CPU and RAM. What autoscaling does not touch is the layer underneath the desktop: the images you maintain, the boot volumes each instance carries, and the file storage where profiles and data live. That layer keeps costing money and keeps demanding attention. This article covers the three parts of that layer you can act on independently of scaling: image management and lifecycle, storage tiering, and non-persistent desktops. It uses OCI as the primary reference because block and boot volume behavior there makes the cost mechanics concrete, and notes the equivalent AWS and Azure patterns where they differ. Scheduling, right-sizing, and session autoscaling are covered in a separate article, linked near the end. The reason this matters is simple accounting. On standard OCI shapes, the compute meter stops when an instance stops; Dense I/O, HPC, and most GPU shapes keep billing while stopped. Storage meters do not stop: provisioned capacity is billed whether the desktop is running or not. Multiply a boot volume by hundreds or thousands of desktops, add duplicated images and orphaned backups, and the residual bill after autoscaling can be a meaningful line item that nobody is watching.

What is a golden image, and how do you keep it from sprawling?

A golden image is a master template of a fully configured desktop (operating system, agents, settings, and baseline applications) that you clone to provision consistent, repeatable VDI instances. On OCI, this template is a custom image: an image created from an instance’s boot volume and used to launch new instances that all start from the same known-good state. Custom images are usually built from Oracle’s platform images, the vendor-maintained base OS images. Thinfinity Cloud Manager provisions desktops directly on OCI’s native compute service, so there is no traditional hypervisor tier to license or patch underneath them; its desktop models reference the custom image directly. The trouble is that images multiply. Every team, every application variant, and every one-off project build tends to become its own image. That sprawl is a storage cost, because stored custom images are billed and each region needs its own copy. It is also a management cost, because every image is one more thing to patch.

One image per persona, not per application

The most effective control is to reduce the number of images you maintain to one per user persona (for example, one for task workers, one for engineers, one for the finance team) rather than one per application combination. The applications that vary between users are the ones you should not install in the image. Thinfinity Workspace delivers full desktops and published Windows applications. Applications that vary between users can run on separate hosts and be published as Remote Apps, so users work with them next to their desktop without the applications being installed in every desktop image. A single lean persona image can then serve users who would otherwise each need a bespoke build. Fewer images means fewer things to patch, lower stored-image charges, and fewer configurations to troubleshoot when something breaks. If your estate still runs separate tools for full desktops and published apps, consolidating VDI and app virtualization on one platform removes duplicate image pipelines at the platform level, a separate step from the per-image optimization covered here.

Mind the OCI custom-image caveats

OCI custom images carry constraints that shape an image lifecycle:

• No cross-region replication. OCI does not replicate custom images across regions automatically. You export the image to Object Storage and import it in each region, so a multi-region estate multiplies its image count and stored-image charges by the number of regions (OCI Custom Images).
• Import and export are capped at 1 TB per image.
• Stored images are billed. Every custom image you keep is charged as stored image storage, so retired images are waste until you delete them.
• Capturing an image from a running instance shuts it down for several minutes, so image capture is a scheduled maintenance task, not something to run against live desktops.
• End-of-support operating systems. OCI will launch an image whose OS vendor no longer supports it, but OCI’s help is limited to getting the instance running, so tracking the OS lifecycle is your responsibility (Bring Your Own Image).

Set a patch-and-rebuild cadence: patch the persona image on a fixed schedule, capture a new custom image, and roll it out. In Thinfinity Cloud Manager, the desktop model references the image, and model versions let you test the new image in a Testing or Staging version before promoting it to Production. Instances already running keep the configuration they were provisioned with; new instances use the new image. Then delete the superseded image and its expired backups so the estate does not accumulate them.

How should you tier cloud-native storage for VDI?

The second lever is storage tiering: deciding what lives on the boot volume and what lives on shared storage, and understanding what each tier bills for. A boot volume is the block-storage volume an instance boots from. It holds the OS and system files, and on OCI it is managed by the Block Volume service. Per the OCI Block Volumes FAQ, boot volumes are billed at Block Volume pricing in addition to compute, and block and boot volumes are metered on provisioned capacity (from 50 GB up to 32 TB), not on how full they are or how busy the instance is. Boot volumes persist independently of the instance: stopping an instance stops the compute meter on standard shapes, but the boot volume keeps billing on its provisioned GB. Terminating an instance preserves its boot volume by default unless you choose to delete it at the same time. Volume backups are stored in Object Storage and billed separately: policy-based backups expire on schedule, while manual backups persist until you remove them.

After a VM is deleted, you will continue to pay for unattached disks.

learn.microsoft.com

Keep the OS disk small; move everything else to shared storage

Because you pay for provisioned boot-volume GB per desktop, the boot volume should be as small as the OS and agents allow. User profiles, home directories, and working data belong on shared storage rather than on each desktop’s boot volume, where they inflate provisioned capacity across the entire fleet. For Windows desktops, profiles are usually stored as FSLogix profile containers, which require an SMB file share. On OCI, the Thinfinity high-availability reference architecture uses a Windows Server file cluster for this, because OCI File Storage supports NFS only. On other clouds, Amazon FSx for Windows File Server and Azure Files provide managed SMB shares. Profiles follow the user to whichever desktop they land on, so the desktop itself can stay stateless and small while the user’s data lives on storage that is sized and scaled independently of the desktop fleet.

FSLogix profile containers store a complete user profile in a single container and are designed to roam profiles in non-persistent remote computing environments like Azure Virtual Desktop.

learn.microsoft.com

Once that tiering is in place, teams still need to manage and audit these pooled desktops across clouds day to day, keeping the storage and profile layout consistent as the fleet grows and shrinks. For estates that use FSLogix, the configuration itself (VHDX layout, Cloud Cache, and profile exclusions) is covered in our FSLogix configuration deep dive; this article covers where profiles live and what they cost.

Pricing and metering behavior as documented by each vendor in October 2026.

What is non-persistent VDI, and where does the “ephemeral disk” pattern fit?

Non-persistent VDI is a model in which no user-specific state is kept on the desktop between sessions: what a user changes on the VM is not carried into their next session. It is the natural partner to the tiering above: if profiles and data already live on shared storage, the desktop has nothing worth keeping. In Thinfinity Cloud Manager, non-persistent desktops are session-based pools. Instances are shared, several sessions run on each instance up to a configured limit, and no user state is stored on the VM between sessions, while profiles live in FSLogix. Dedicated 1:1 desktops are the persistent alternative, for users whose applications or data must stay on their own VM. Non-persistent does not make the storage bill disappear. Cloud Manager reduces the number of running instances in two ways: Depth First pooling fills each instance before using the next, and Staged Power On/Off powers off instances that stay empty. On OCI, a powered-off instance still pays for its boot volume. Destroying an instance is what releases its storage: when Cloud Manager destroys an instance, it releases its disk, network interface, and IP, so no orphaned boot volumes are left behind. Cloud Manager can destroy a model’s instances on a scheduled date, which you can use to retire a deployment after rolling out a new image version. The ephemeral OS disk is often presented as the answer to the storage bill, but it is not a universal cloud feature. OCI does not offer an ephemeral boot disk: every OCI instance boots from a block-volume boot volume. The concept comes from other clouds:

• Azure offers ephemeral OS disks, where the OS disk lives on the VM’s local storage and is not persisted to Azure Storage. VMs with ephemeral OS disks cannot be stopped and deallocated; they are reimaged or deleted instead.
• AWS instances usually boot from an EBS root volume, which by default is deleted when the instance terminates. Instance store volumes are temporary block storage on the host, used mostly for data rather than as the boot disk.

On OCI you get the same result by design: provision from the custom image, keep profiles on shared storage, and delete the boot volume together with the instance when you no longer need it.

Behavior as documented by each vendor in October 2026.

Where does compute optimization pick up?

Everything above is the image and storage layer. The compute layer (session autoscaling, pool consolidation, instance right-sizing, and start/stop scheduling) is a separate discipline. For that layer, see Thinfinity Cloud Manager’s autoscaling engine, which covers scale sets, deploy and destroy modes, and schedule-based power on and off for the compute fleet. The two are meant to be read together: if you are chasing residual cost, scale compute elastically and optimize the storage layer so that what remains after scaling is not billing in the background. For the strategy behind elastic capacity on Oracle Cloud, see our guide to elastic VDI on OCI. For the whole-estate financial picture (compute, GPU, licensing, and storage together), see the CFO’s five-step VDI cost plan. For a cost comparison across providers, see our analysis of banking VDI cost on OCI vs Azure and AWS, and for the platform view, native OCI VDI for enterprises.