When you build a golden image in Atlas AVD, the last step asks a question that's easy to click past: Replication Mode: Standard (Full) or Shallow? It looks like a minor setting. It isn't. It decides how long you wait before the image is usable, what you pay to store it, and, most importantly, how well it holds up when a host pool needs a lot of new session hosts at once.
This article explains what each mode does under the hood, the pros and cons of each, and a simple rule for picking.
The short version: use Shallow for test builds, quick validation and very large images you rarely deploy. Use Full for any image that production host pools are built from, especially pools that scale out or span regions.
What "replication" means here
Atlas publishes your captured image as an image version in an Azure Compute Gallery. Each image version has a source region (where the captured VM lived) and a list of target regions (the regions you tick in the Image wizard, which always include the source region).
The replication mode tells Azure what to do with the image data once the version is created:
- Full copies the image into each target region and keeps a replica there that new VMs are built from.
- Shallow skips the copy. The version points back at the original source data instead of holding its own replicas.
Azure sets the mode when the version is created and it cannot be changed afterwards. If you publish Shallow and later want Full, you publish a new version.
Full replication
Full is Azure's standard behaviour, and it's what Atlas labels Standard (Full).
Pros
- Built for scale. Each target region holds its own replica, so Azure can build many session hosts from the image at the same time. This is what you want when a scaling plan adds a batch of hosts on Monday morning, or when you rebuild a whole pool onto a new image.
- Regional independence. A host pool in West Europe is built from a copy in West Europe. It doesn't depend on the region the image was captured in.
- The right fit for production and recovery. If you're keeping images in a second region so you can rebuild after an outage, those copies need to actually exist there. Only Full puts them there.
Cons
- It takes time. Azure has to copy the whole disk to every target region. Atlas sees roughly 33 GB per minute per region on production runs, so a 128 GB image going to three regions is in the ballpark of ten to fifteen minutes, and large or cross-continent copies can take considerably longer. Atlas publishes every target region in a single request, so Azure copies to all of them at once rather than one after another, which keeps a multi-region build from stacking those waits end to end.
- It costs storage in every region. Each replica is billed as gallery storage (Standard LRS by default). A 128 GB image in three regions is about 384 GB of replica storage for as long as you keep that version.
- Image size is capped. Fully replicated images must be under 2 TB.
Shallow replication
Shallow tells Azure to skip the copy entirely. The version is registered in the gallery and is usable almost immediately.
Pros
- Ready in about a minute. There's no data to copy, so you don't wait on replication before you can test the image.
- No replica storage. You aren't paying to store a copy per region.
- Very large images. Because nothing is copied, Shallow supports images up to 32 TB, well past the 2 TB limit for Full.
Cons
- Not for deploying many VMs at once. Microsoft is explicit that you can't deploy a large number of VMs from a shallow version, or deploy many concurrently. There's no per-region replica fan-out to spread the load. A big scale-out or a full pool rebuild is exactly the workload it isn't designed for.
- Positioned for dev and test. Microsoft describes Shallow as a mode for development and test, behaving much like the older managed images did.
- No regional copies. Since nothing is copied, Shallow gives you no independent replica in another region to fall back on.
- It can't be upgraded in place. To promote a shallow image to production you publish a new, fully replicated version.
Side by side
| Standard (Full) | Shallow | |
|---|---|---|
| Time until the version is usable | Minutes to an hour or more, depending on size and regions | About a minute |
| Extra storage cost | One replica per target region | None |
| Building many hosts at once | Yes, designed for it | No |
| Independent copy in each region | Yes | No |
| Maximum image size | Under 2 TB | Up to 32 TB |
| Microsoft's intended use | Production | Development and test |
| Can be changed after publishing | No | No |
Which should you pick?
Pick Shallow when:
- You're testing a change to the image (a new app, a registry tweak, a Windows update) and want to spin up one or two hosts to check it.
- You build images often and only a handful ever reach production, so replicating every test build would waste time and storage.
- The image is very large and is deployed rarely, a few VMs at a time.
Pick Full when:
- A production host pool is built from the image.
- The pool uses autoscale, or you expect to add or rebuild many hosts at once.
- You run host pools in more than one region, or keep images in a second region for recovery.
A pattern that works well: build and validate with Shallow, then publish the version you're happy with as Full and point your production pools at that one. You get fast iteration without putting a test-grade image under a production pool.
Where you set it in Atlas AVD
- Per image: the Replication Regions step of the Image wizard has the Full / Shallow choice, right above the region picker. The Replication Estimate card underneath shows the storage and time a Full copy will cost for the regions you've ticked. Shallow finishes far faster than that estimate shows, because nothing is copied.
- As a default: on the Imaging page, open an image definition's Replication tab, pick the mode and select Save as Defaults. New image versions then start with that mode, so your team doesn't have to choose on every build, and the wizard still lets you override it per image.
If you're unsure, choose Full. It costs a little more storage and a few more minutes per build, and in return the image behaves the way a production host pool expects, no matter how many hosts it needs at once.
Replication is one step in a longer lifecycle. The AVD golden image management guide covers the rest: what belongs in the image, versioning, rolling a new version onto a host pool without forcing users off, and a monthly image checklist.
Shallow replication limits are taken from Microsoft's Azure Compute Gallery documentation as of October 2026. Replication times are Atlas averages, not a guarantee; actual times and storage prices vary by region and subscription.