Setting Up Veeam Cloud Connect v13 for Service Providers: Architecture, Configuration, and Tenant Management

What Cloud Connect Actually Is

Most Veeam content covers Cloud Connect from the tenant side. How to point your VBR at a service provider, set up a backup copy job, and call it a day. That's a five-minute setup for someone who already has a Cloud Connect endpoint to connect to. What doesn't get covered nearly enough is the service provider side: how you actually build the infrastructure that tenants connect to, what the components are, how you size and manage it, and what changed in v13 that affects everyone running it.

That's what this article covers. If you're building a BaaS or DRaaS offering, running Cloud Connect internally for an enterprise with multiple business units, or just trying to understand the full stack before you recommend it to a customer, this is the ground-up walkthrough.

Cloud Connect is a multi-tenant backup and replication platform built into VBR. From the SP side, it lets you expose backup storage capacity and compute resources to tenants who connect over a single encrypted port from wherever they are. Tenants never need to know your internal network topology. They connect to a cloud gateway, authenticate with a tenant account, and their backup jobs run just like they would against any other repository target, except the data is traveling across the WAN to your infrastructure.

Two distinct services live under the Cloud Connect umbrella and understanding the difference matters for how you size and price it:

• Cloud Connect Backup (BaaS): Tenants back up VMs, physical machines, or Veeam Agent workloads to a cloud repository on your infrastructure. Storage capacity is allocated per tenant as a quota. This is the most common use case.
• Cloud Connect Replication (DRaaS): Tenants replicate VMs to a cloud host on your infrastructure. In a disaster scenario they can fail over their workloads to run on your compute. This requires a hardware plan on your side with hypervisor resources allocated to tenants.

You can offer both from the same infrastructure. Most SPs start with BaaS, validate the platform, and add DRaaS capability once they have the hardware and operational model in place.

The Infrastructure Stack: Every Component Explained

Before you touch a wizard, you need to understand what you're building. Cloud Connect has more moving parts than a standard VBR deployment, and the relationship between those parts determines how you design for scale, redundancy, and tenant isolation.

SP Veeam Backup Server

This is your VBR instance running with a Cloud Connect license. It orchestrates everything: gateways, repositories, tenant accounts, and the data flows between them. It runs on Windows Server 2016 or later (available since v13.0.1) or as the pre-hardened Veeam Software Appliance on Linux, which was the initial v13 release form in September 2025. The backup server can be physical or virtual, including on hyperscale cloud like Azure or IBM Cloud if your architecture calls for it. This server is not exposed directly to tenants. Tenants connect to cloud gateways, not the backup server itself.

Cloud Gateway

The cloud gateway is the only component in your infrastructure that tenants talk to directly. It's a Windows machine (physical or VM) that acts as a TLS-secured proxy between the tenant's VBR or Veeam Agent and your internal backup infrastructure. All tenant traffic flows through port 6180 by default. That single port is all a tenant needs open outbound. Behind the gateway, data flows between the gateway, backup proxies, and repositories using your standard internal Veeam ports.

Each cloud gateway needs its own public IPv4 address. You cannot share one IP across multiple gateways for load balancing using a single DNS record. Each gateway gets its own A record. You can give tenants a single public DNS name for your Cloud Connect service and map that to all gateway IPs, but each gateway needs its own DNS record pointing to its own IP address.

The gateway can be deployed in two network modes: direct connection to the internet, or behind a NAT gateway. For most SP deployments, NAT mode is the right call since it keeps the actual gateway machines off your public IP space. The default port, 6180, is configurable if you need to run it on a different port for network policy reasons.

Cloud Gateway Pool

When you have multiple gateways, you organize them into gateway pools. Pools let you assign specific gateways to specific tenants, control which tenants route through which gateways, and provide failover between gateways within a pool if one becomes unavailable. You can also configure a tenant's pool assignment to allow failover to gateways outside the pool if all pool gateways go down.

Cloud Repository

A cloud repository is a standard VBR backup repository, or a Scale-Out Backup Repository, whose storage capacity you expose to tenants as tenant-specific quota. From the tenant's perspective, a cloud repository appears in their VBR as a backup target they can point jobs at. From your side, it's a folder on your repository infrastructure with a quota attached. Multiple tenants share the physical storage pool. Each tenant only sees their own allocation.

Hardware Plan (DRaaS only)

Hardware plans define the compute resources you expose to tenants for replication. A hardware plan points at a specific hypervisor host or cluster on your side, a datastore for replica VM disks, and a network for replicated VMs to land on. Tenants assigned a hardware plan can replicate VMs to your infrastructure and, in a declared disaster, fail those replicas over to run on your compute. You configure one hardware plan per compute allocation. Different tenants can use the same hardware plan, but each tenant's replica VMs are isolated within that plan.

Network Extension Appliance (DRaaS only)

For partial site failover scenarios where tenants need to maintain IP addresses after failing over to your cloud host, the Network Extension Appliance (NEA) handles the Layer 2 extension and routing. It's a lightweight VM that gets deployed on both the tenant side and the SP side. Not required for all DRaaS scenarios, but needed any time a tenant wants their replicated VMs to retain original IP addresses during failover.

Backup Proxies

Standard VBR backup proxies on the SP side handle data movement between gateways and repositories. For high-throughput SP deployments, you'll want dedicated proxies separate from the backup server. Proxy sizing depends on your expected concurrent tenant load and throughput requirements.

WAN Accelerators (Optional)

If you're offering WAN acceleration to tenants, you deploy a target WAN accelerator on the SP side and tenants deploy a source WAN accelerator on their side. WAN acceleration reduces bandwidth consumption for backup copy jobs significantly, especially for high-change-rate environments. It requires a WAN accelerator license and is configured per-tenant, not per-gateway.

What Changed in v13 That You Need to Know

v13 is explicitly described as a breaking release for Cloud Connect. Several changes affect every SP running it, and one of them will block the upgrade wizard from proceeding at all if you haven't addressed it first.

Active Directory-based authentication for new tenants is gone. In v12 and earlier, you could create tenant accounts backed by AD users or groups. In v13, new tenants must use local Veeam accounts. Existing AD-backed tenants continue to work in upgraded environments for now, but Veeam has confirmed this will be fully removed in v14. If you have AD-authenticated tenants, plan that migration before v14 lands.

The single-storage backup format is no longer available for new repositories or jobs. Per-machine backup chains are now the only option when creating new repositories. Existing single-chain repositories continue to work in upgraded environments, but no new jobs or repos can use that format. This will also be fully removed in v14.

The Veeam Cloud Connect Portal is a hard upgrade blocker. This is the one that will stop your upgrade cold if you haven't dealt with it. If the Cloud Connect Portal (the tenant-facing self-service restore portal accessed through Veeam Backup Enterprise Manager) is present and configured in your environment, the v13 upgrade wizard will refuse to proceed until it is removed. You must disable and remove the Portal before you can upgrade. Once upgraded, it is gone entirely and cannot be re-enabled. If your tenants were relying on the Portal for self-service restore initiation, they need an alternative workflow before you start the upgrade. VSPC is the recommended replacement for any SP-managed self-service capability. Direct restore through the tenant's own VBR console is the other path.

v13 is backwards compatible only with specific tenant versions. Once you upgrade your Cloud Connect infrastructure to v13, tenants running older versions of VBR or Veeam Agents will lose connectivity. The minimum supported tenant versions are: VBR 12.3.2 (build 12.3.2.3617 or later), Veeam Agent for Windows 6.3.2 or later, Veeam Agent for Linux 6.3.2 or later, Veeam Agent for Mac 2.3.1 or later. Tenants on anything older than these versions will fail immediately after your upgrade. Audit your tenant versions before you schedule the upgrade window.

Before You Start: Licensing and Prerequisites

Cloud Connect uses a separate license from standard VBR. You install the Cloud Connect license on the SP backup server alongside (or instead of) the standard VBR license. The license is per protected workload on the tenant side, reported as rental points per unit (PPU) through VCSP Pulse. Veeam Service Provider Console (VSPC) is the recommended tool for automated license usage reporting. Connecting your Cloud Connect server to VSPC also gives you centralized tenant management, billing reporting, and alarm monitoring across your entire service delivery platform.

Step 1: Deploy the SP Backup Server and Install the License

Install VBR v13.0.1 on your backup server. During installation, you'll be prompted for a license file. Install the Cloud Connect license here. If you're also using this server for standard VBR protection of your own infrastructure, you can have both a standard VBR license and a Cloud Connect license installed simultaneously.

After installation, open the VBR console. You'll notice a Cloud Connect view in the left navigation that doesn't exist in a standard VBR deployment. Everything SP-side happens from this view.

Step 2: Configure TLS Certificates

Before you add any gateways, sort out your TLS certificate situation. This is the most commonly botched step in Cloud Connect deployments and it causes tenant onboarding headaches that are entirely avoidable.

Your options are a self-signed certificate generated by VBR, or a CA-signed certificate you import. Self-signed works for testing and small environments where you directly manage the tenant VBR installations and can push the thumbprint out of band. For any production environment where tenants are doing their own VBR setups, a CA-signed certificate is the right answer. Tenants connecting to a CA-signed certificate don't need to do any thumbprint verification. They see a trusted cert, click through, and they're done.

If you use a CA-signed certificate, it needs to cover the DNS names of all cloud gateways. A wildcard certificate covering your Cloud Connect subdomain is a clean way to handle this. All gateways must also be configured in "Located behind NAT or uses external DNS name" mode when using a CA-signed cert so their external DNS names are included in the TLS handshake properly.

In the VBR console, go to Cloud Connect > Manage Certificates. From here you can generate a self-signed certificate or import a PFX file containing your CA-signed certificate and private key. Set the certificate before adding gateways, not after. Changing the certificate after gateways are running requires a brief service interruption.

Step 3: Add Cloud Gateways

With your certificate in place, add your cloud gateways. In the Cloud Connect view, go to Cloud Gateways and click Add Gateway.

Step 4: Configure Cloud Repositories

Under Cloud Connect > Repositories, add the repositories you'll expose as cloud storage to tenants. Any VBR-supported repository type works here. In production SP environments, Scale-Out Backup Repositories are the common choice because they let you pair performance-tier storage with a capacity tier backed by object storage, giving you the flexibility to tier older tenant data to cheaper storage automatically.

A few things to think through before you stand up your cloud repositories:

Per-machine backup chains are mandatory in v13. When you create a new repository, per-machine backup chains are now the only format available. There's no option to choose otherwise. Plan your storage layout knowing that each protected VM generates its own set of backup files rather than a single chain per job.

Quota is allocated per tenant, not per repository. The repository is the shared physical pool. Individual tenant quotas are set when you create the tenant account. A tenant's quota defines how much of that pool they can consume. Tenant data is stored in separate subdirectories. Tenants can't see each other's data.

Insider Protection is configured per tenant, not per repository. The recycle bin mechanism lives at the repository level physically, but you toggle it per tenant account. Covered in detail in a dedicated section below.

Step 5: Create Tenant Accounts

This is where the SP-side work translates into something a tenant can actually use. Under Cloud Connect > Tenants, click New Tenant.

Step 6: Hardware Plans for DRaaS (Optional)

If you're building a DRaaS offering, this is where the compute side gets configured. Under Cloud Connect > Hardware Plans, click New Hardware Plan.

The hardware plan wizard walks you through pointing it at a hypervisor host or cluster on your side, selecting the datastore where tenant replica VM disks will land, and defining the network the replica VMs will attach to when they power on during failover. Name hardware plans clearly so you know what compute pool each one represents. Assign plans to tenants at the tenant account level during or after tenant creation.

For partial site failover where tenants need to retain original IP addresses, configure the Network Extension Appliance credentials under Cloud Connect > Network Extension Appliance Credentials before assigning the hardware plan to tenants. The NEA credentials are used when VBR deploys the appliance on both the tenant and SP side to establish the Layer 2 extension tunnel.

Insider Protection: The Feature You Should Always Enable

Insider Protection is one of those features where the name undersells it. It's not just about malicious insiders. It protects against any scenario where backups get deleted from the cloud repository, whether that's a ransomware attack on the tenant's VBR console, an administrator mistake, or a malicious deletion. Without Insider Protection, a delete operation removes backup files immediately. With it enabled, deleted backup files are moved to a _RecycleBin folder on the SP repository and kept there for the number of days you specify. They're still gone from the tenant's perspective; they can't restore from them directly and they don't count against the tenant's quota. But you can recover them if needed.

The practical scenario that makes this real: a tenant gets ransomware, the attacker gains access to the VBR console, and deletes all backups from the cloud repository before you're called. Without Insider Protection, those backup files are gone. With it enabled and a 14-day retention set, you have a window to pull the tenant's data back from the recycle bin and hand them their restores. That conversation is very different from telling them the backups are gone.

Enable it per tenant in the tenant account settings. The storage overhead is the deleted files sitting in the recycle bin for the retention period. For most environments this is modest. Set a minimum of 14 days. Longer is better if your storage capacity allows it.

Bandwidth and Concurrency Controls

Getting bandwidth and concurrency settings right is the operational work that separates a Cloud Connect environment that performs predictably from one that degrades under load. Two mechanisms work in parallel:

Default bandwidth sharing: By default, available bandwidth is split equally across all tenants running tasks simultaneously. If two tenants are active at the same time, each gets 50%. Within each tenant's 50%, bandwidth is split equally across their concurrent tasks. This works well for environments with light to moderate concurrent load and tenants with similar workload sizes. It requires no configuration and automatically balances resources.

Per-tenant bandwidth limits: When you need to guarantee a specific tenant won't consume more than a defined throughput, enable the bandwidth limit on their account. This cap applies independently of what other tenants are doing. Useful for tenants with large, noisy workloads that could otherwise starve smaller tenants during peak hours. It's also how you structure a tiered service offering where premium tenants get guaranteed throughput and standard tenants get best-effort.

The concurrent task limit per tenant is the other lever. Setting this too high for tenants with many VMs can cause gateway and proxy overload during backup windows. Setting it too low means a tenant's jobs take longer to complete. Start conservatively, monitor proxy and gateway CPU and I/O during tenant backup windows in the first few weeks, and tune from there.

Tenant Version Management and the v13 Breaking Change

The most operationally significant thing about running a Cloud Connect environment is managing the version compatibility between your infrastructure and your tenants. This matters most at major version upgrades. With v13 being a breaking release, the version compatibility window is narrower than it used to be.

Your v13 Cloud Connect infrastructure supports these minimum tenant versions: VBR 12.3.2 (build 12.3.2.3617 or later), Veeam Agent for Windows 6.3.2 or later, Veeam Agent for Linux 6.3.2 or later, Veeam Agent for Mac 2.3.1 or later. Any tenant below these versions will fail to connect after you upgrade.

The VBR upgrade checklist in v13 actually shows you your tenant list and flags incompatible versions during the pre-upgrade configuration check. Pay attention to this list. The check is there for a reason. If you proceed with the upgrade knowing tenants are on incompatible versions, their jobs will start failing immediately and you'll be fielding support calls while also managing an upgrade.

Build tenant version auditing into your regular operations, not just at upgrade time. Know what version every tenant is running. Know when they last communicated. Know who to call when you need them to upgrade. This is the unglamorous operational work that keeps a Cloud Connect service running smoothly.

Maintenance Mode

Maintenance mode is how you take Cloud Connect down cleanly. When you put the Cloud Connect infrastructure into maintenance mode, any in-flight backup or backup copy sessions are allowed to complete. Once those finish, no new tenant sessions can start. Tenants attempting to start jobs see a clear maintenance message instead of a connection error.

Use maintenance mode every time you need to make changes that require a service interruption: upgrading the backup server, updating gateway components, changing the TLS certificate, or performing storage maintenance on your repositories. Going into maintenance mode first instead of just stopping services protects in-flight backup data from being written as incomplete restore points.

Enable it under Cloud Connect > Manage Cloud Connect Service. The toggle is straightforward. Set it, wait for active sessions to drain, make your changes, and disable it when you're done.

Closing Thoughts

Cloud Connect is genuinely one of the more sophisticated things in the Veeam stack to stand up correctly. Not because any individual step is hard, but because the interactions between the components, and the operational discipline required to manage tenant versions, bandwidth allocation, and storage capacity over time, are things that most documentation glosses over entirely. The Veeam docs cover the mechanics. They don't tell you to use VSPC from day one, or that Insider Protection deserves a non-negotiable policy, or what the tenant version audit should look like before you schedule a major upgrade.

The architecture itself is sound. A single port outbound for tenants, TLS encryption on all data in transit, per-tenant quota isolation, bandwidth controls, and a recycle bin that can save your relationship with a tenant after a ransomware event. If you're building a BaaS or DRaaS offering, this is a platform worth doing right. The operational work pays off at scale.