If you’re managing backups stored in the cloud, you’ve probably wrestled with infrastructure headaches, cost control, and security. Enter Veeam Data Cloud Vault (VDC Vault)—Veeam’s fully-managed, secure cloud storage solution built on Azure Blob Storage. VDC Vault isn’t just another bucket in the cloud; it’s a hands-off, immutable, designed to keep your data out of harm’s way and out of your own infrastructure.
So why choose VDC Vault? You get Azure’s scale and security, but with Veeam’s management, automation, and immutability baked in. It’s separated from your own environment, making it ideal for ransomware recovery, long-term retention, and compliance. You don’t need to DIY your own BLOB storage or worry about setting it up correctly—Veeam handles all that for you. It’s a simple subscription service: add Vault as a repository in Veeam Backup & Replication (VBR), set up your jobs, and you’re off.
Many organisations are moving to VDC Vault but, as with all migrations, there are caveats and best practices. Here’s what we’ve learned.
Key Migration Points & Findings
Encryption – Double Encryption
For backups to land directly in VDC Vault, job-level encryption is required. If you’re using SOBR (Scale-Out Backup Repository), you can choose to only encrypt at the capacity tier (not the job level) which avoids double encryption if desired. Avoiding double encryption is not necessarily a best practice; however, it’s an important consideration given performance extents such as ExaGrid, DataDomain and StoreOnce deduplication appliances will perform better if backups stored on them are not encrypted.
Meaning you could land backups locally on an ExaGrid without Veeam encryption, then offload backups to capacity tier (VDC Vault) which is encrypted.
Egress Cost Minimisation
Data transfer costs in Azure can add up if not carefully managed. As of 2024, Microsoft has updated its pricing so that data transfer between availability zones within the same Azure region is no longer charged (see Azure update). This means that whether your AzureVM (configured as the Veeam Gateway) and your VDC Vault (Blob Storage) are in the same or different availability zones, as long as they are within the same region, you should not be charged for data transfer between them—even if a public endpoint is used.
Of course, to be safe, and because it’s not possible to confirm which availability zone the VDC Vault resides in, it’s always best to configure a service endpoint for VDC Vault.
- Keep both your gateway VM and VDC Vault in the same Azure region; intra-region traffic (even when between different availability zones) is free.
- Egress charges should only apply if data leaves the Azure region, such as to the internet or on-premises.
- To optimise routing and maintain security, it’s still recommended to configure a service endpoint for VDC Vault (Microsoft.Storage.Global).
- Use AzureVMs as gateway servers to ensure data flow remains within Azure and not to on-premises, which would incur egress costs.
- If the source capacity tier extent is configured with an on-premises gateway server, this should also be updated to use the new gateway located in the appropriate hyperscaler (Azure/AWS). If no gateway is set — i.e. direct mode — you don’t need to set one, as the target should also pull direct. However, setting a gateway is recommended to guarantee it’s used for all traffic transfers.
Gateway Server & Data Flow
- In “Direct Mode,” your mount server acts as the gateway. If it’s on-prem, expect egress when traffic is read from your source BLOB back to on-premises then pushed back out to VDC vault.
- Best practice: deploy a temporary Azure VM as your gateway server to keep transfers internal within Azure and fast.
Networking – Service Endpoints are Key
Azure VMs configured as a Veeam Gateway or Proxy reach Azure Storage through the storage account’s public endpoint. If the VM has no explicit outbound method — a NAT Gateway, Azure Firewall, or its own public IP — Azure falls back to default outbound access, routing traffic through a Microsoft-owned public IP. When the VM and storage account share a region, this traffic is free regardless of outbound method; egress charges only apply when the storage account is in a different region, with rates varying by region pair and direction. That’s the real lever on cost here: which region VDC Vault lands in relative to your gateway, not which routing method you pick.
That leaves three ways to control how this traffic is routed:
Private endpoints keep traffic from the Gateway/Proxy inside your private network at all times, but at a cost — both in Private Link pricing and in the DNS/routing overhead to maintain.
Service endpoints are the cheaper, simpler option. Configure one at the vNet layer and every VM in the vNet uses it automatically — match the tag to whether your gateway and Vault share a region (see below).
When you enable a service endpoint — Microsoft.Storage or Microsoft.Storage.Global — on a subnet, Azure adds a system route for that service’s address ranges. Because this route is more specific than a blanket 0.0.0.0/0 UDR, longest-prefix-match logic means the system route wins: traffic to that service goes direct over the Azure backbone instead of following the UDR’s next hop (firewall, NVA, VPN gateway, etc.).
The choice between the two tags comes down to region:
Microsoft.Storagereaches storage accounts in the same region as the vNet (or its paired region).Microsoft.Storage.Globalreaches storage accounts in any region, same or different.
Worth being clear on what the Global tag actually buys you: it doesn’t reduce the egress bill. If your gateway and VDC Vault land in different regions, that inter-region charge applies whether the traffic takes the backbone or hairpins through your firewall — the rate is set by the region pair, full stop. What Global gets you is routing and security: traffic skips your NVA/firewall hop entirely, taking load off it and avoiding an extra latency hop, and you can scope exactly which storage traffic gets that bypass via service endpoint policies rather than opening a blanket internet route. It’s also the only way for a VM with no outbound internet path at all — no NAT Gateway, firewall, or public IP — to reach a cross-region storage account.
VDC Vault’s region is fixed at setup — you choose it, and can confirm it in the console — so the real question is whether your gateway VM sits in that same region. If it does, Microsoft.Storage covers you. Reach for Microsoft.Storage.Global when the gateway and Vault are (or might end up) in different regions, or when you’d rather the endpoint config keep working unattended if that alignment ever changes. One catch: to add it, your subscription needs the AllowGlobalTagsForStorage feature registered — without it, Azure won’t let you add the endpoint.
ExpressRoute is the other option: use Microsoft Peering for public Azure services. Private Peering requires the ExpressRoute gateway to live in Azure or the use of private endpoints — see Veeam KB4745 for details.
The actual lowest-cost path, then, is placing your gateway in the same Azure region as VDC Vault whenever you can control it — the service/private endpoint choice is a routing and security decision layered on top, not a way to dodge the region-to-region rate.
Availability Zones
Confirm which availability zone(s) your backups reside in. This helps optimise gateway placement and performance.
Migration Steps
- Register and add VDC Vault to VBR.
- Add Vault to SOBR.
- Put old Blob capacity tier in maintenance, evacuate backups.
- Remove old capacity tier after migration.
While the old (source) capacity tier extent is in maintenance mode, Veeam will not run any offload jobs to any capacity tier in the SOBR. This means new backups will not be offloaded or copied to any capacity tier while the migration is running, this may impact your ability to copy backups offsite (achieve 3-2-1). For this reason, it is important to size the gateway server appropriately to ensure the migration can be completed within an acceptable timeframe.
Performance Tuning
Decryption and re-encryption hit CPU hard. Recommend the following sizing.
- 4 GB RAM per concurrent migration task
- 1 vCPU per 2 concurrent tasks
- Example: 58 concurrent tasks (to move 500 TB in 48 hours) = 232 GB RAM, 29 vCPU
- Most start with 4–16 tasks, perform basic migration test first and tune as needed
Immutability
- Orphaned backups keep the longest of their original immutability or job retention period.
- Manual cleanup needed for orphaned backups after retention ends.
- New repository settings take over post-migration—immutability defaults to 30 days on VDC Vault.
Gateway Server Placement
Keep the gateway server in Azure, in the right region, to avoid egress and maximize speed.
Miscellaneous Tips
- Going cross-region doesn’t make service endpoints pointless — you still pay the inter-region rate either way, but the endpoint keeps that traffic on the Azure backbone instead of hairpinning through your firewall/NVA, which matters for performance and security even when it can’t save you money.
- Public endpoints can be enabled at the same time as private endpoints.
- Private endpoint DNS: Remove DNS server from Azure VM if you want to avoid resolving private endpoints.
- Host table entries may be needed for VBR resolution.
- For public access, restrict to the vNet/subnet used by your Azure VM.
- BCJ Vault-to-Vault avoids egress if all components are in the same region.
- Routing through on-prem firewalls? Expect extra egress/network charges.
AVS (Azure VMware Solution) Nuances
- You’ll likely need a gateway in Azure IaaS, not AVS, with a service endpoint.
- AVS connects via ExpressRoute, acting like on-prem.
- For restores/reads from Vault: Data uses Microsoft’s backbone if the gateway is in your Azure tenant, connected via ExpressRoute/private peering.
Final Thoughts
VDC Vault is a leap forward for cloud backup security and simplicity, but migrating isn’t a “click and forget” affair. Get your encryption, networking, endpoints and gateway placement right, and you’ll dodge surprises on cost and performance.