Veeam's Native Cloud Backup Products: Architecture, Workloads, and How They Connect to VBR

There's a version of this conversation that goes: "We need to back up our AWS workloads, what does Veeam have?" And the answer people expect is a VBR job type or a checkbox somewhere in the console. That's not what you get. What Veeam actually ships for cloud-native workload protection is three separate products -- one for AWS, one for Azure, one for Google Cloud -- each of which is a standalone Linux appliance that deploys inside your cloud account and manages its own backup infrastructure. They connect to VBR for centralized management, but they run independently when they need to. Understanding that architecture distinction is what this article is about.

The Shared Architecture All Three Products Use

Before splitting into per-cloud specifics, it's worth calling out what all three products have in common, because the pattern is consistent across AWS, Azure, and GCP.

Every product deploys a backup appliance -- a Linux VM that runs inside your cloud account. This appliance owns the control plane: it holds the configuration database, runs backup policies, coordinates snapshot operations, and hosts the product's own web UI. You manage it directly or through VBR if you've connected it to your existing Veeam infrastructure.

For operations that move data -- backups to object storage, restores from repositories -- the appliance spins up worker instances. These are temporary Linux VMs, one per protected resource per job, that run Veeam Data Mover and handle the actual data path. They exist only for the duration of the operation and are torn down immediately after.

All three store image-level backups in the native cloud object storage service for that provider: S3 for AWS, Azure Blob Storage for Azure, Google Cloud Storage for GCP. Cloud-native snapshots stay in the native snapshot mechanism of each platform. All three connect to VBR via a cloud-specific plug-in for centralized management and backup copy jobs.

What Each Product Actually Protects

This is where the products diverge significantly. Workload coverage is not symmetrical across the three, and several features require VBR-managed mode -- they're not available on a standalone appliance. I've called those out explicitly because they're an easy thing to miss during planning.

Cloud-Native Snapshots vs. Image-Level Backups

All three products support both protection modes, and the distinction matters for how you design your retention, your recovery options, and your storage costs.

Cloud-native snapshots use the snapshot API built into each cloud platform -- EBS snapshots for EC2, managed disk snapshots for Azure VMs, persistent disk snapshots for GCE. They're fast to create, support tight RPOs, and enable near-instant restore because there's no data to move. The downside: they stay in the same cloud account, often the same region, and they get expensive if you retain many of them.

Image-level backups work differently. The appliance triggers a snapshot, spins up a worker instance that mounts that snapshot, reads the data, deduplicates and compresses it, and writes it to your object storage repository in Veeam's native format. What you're left with is a portable backup file that Veeam can restore to any supported target -- including a different cloud or back to an on-premises hypervisor. That portability is the primary reason to use image-level backups for anything beyond short-term local protection.

Repository Design: Getting the Storage Tiers Right

AWS -- S3 Storage Classes and Object Lock

Image-level backups land in S3. The supported storage classes for Veeam repositories are S3 Standard, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive. S3 Standard-IA, S3 One Zone-IA, and S3 Glacier Instant Retrieval are not supported. This trips people up because Intelligent-Tiering seems like an obvious fit -- it's not a supported repository target. Use Standard for active backups and Glacier Flexible Retrieval or Deep Archive as your archive repository tier.

Object Lock is supported for immutability. Configure the bucket with Object Lock in Compliance or Governance mode before adding it as a repository, then enable immutability in the repository settings. You can't retrofit Object Lock onto an existing bucket.

Azure -- Blob Storage Constraints

Azure Blob Storage is the repository backend. Storage accounts with hierarchical namespace (ADLS Gen2) are not supported. Blob soft delete and container soft delete conflict with Veeam's retention management and must be disabled. Cold access tier is not supported -- use Hot or Cool. Worker instances need enough free IPs in their subnet to accommodate one worker per concurrent workload -- on a policy protecting 50 workloads, you need 50 available IPs in the worker subnet at job runtime.

GCP -- Cloud Storage and HMAC Keys

GCP repositories use Cloud Storage buckets accessed via an HMAC key tied to the service account. Use Standard storage class for active backups. Archive storage class is supported for long-term retention as a separate archive repository tier. The HMAC key provides a separate authentication path from the service account's direct IAM identity, which is worth keeping in mind if you rotate service accounts.

IAM and Identity: How Each Product Authenticates

AWS -- IAM Instance Profiles and Cross-Account Roles

Veeam Backup for AWS uses IAM roles attached as instance profiles -- no static credentials. For cross-account protection, you create a trust relationship between a role in the target account and the appliance's instance profile. Veeam ships a CloudFormation template that creates the required role and policy in the target account. If Service Control Policies in your AWS organization restrict IAM role creation, pre-create the worker IAM role and reference it in the appliance config before your first backup run.

Azure -- Managed Identity and RBAC

The Azure appliance uses a system-assigned managed identity. The managed identity needs Contributor rights on the subscription or resource groups being protected, plus explicit rights on storage accounts used as repositories. For cross-subscription protection, the managed identity needs role assignments in each subscription. Workers communicate with the appliance via Azure Queue Storage -- your NSGs need outbound HTTPS from the worker subnet to Azure Storage service endpoints.

GCP -- Service Accounts and Project Scope

Veeam Backup for Google Cloud uses a GCP service account attached to the appliance VM. One important constraint: the product is scoped to a single GCP project per appliance. Cross-project protection requires deploying additional appliances. Veeam provides Deployment Manager or Terraform templates to create the service account and bind the required roles. Cloud SQL and Cloud Spanner protection requires VBR-managed mode and is scoped to projects and folders within the policy settings.

Standalone Appliance vs. VBR-Managed Mode

Standalone mode is the right call for a single cloud account with a simple protection scope and no existing Veeam infrastructure. It's also where every deployment starts -- you can always connect to VBR later.

VBR-managed mode connects the appliance to a VBR server via the cloud plug-in. You get a unified view across all connected appliances, backup copy jobs to on-premises or Cloud Connect targets, access to workload types only available in managed mode (DynamoDB, Cosmos DB, Azure SQL, Cloud Spanner, Azure Files, and network configuration backups), and cross-platform restore. If you already run VBR, connecting your cloud appliances is almost always the right move.

Cross-Cloud and Cross-Platform Restore

This is where image-level backups (rather than snapshot-only protection) pay off. Because all three products write to Veeam's native backup format, backup files in S3, Azure Blob, or GCS can be restored to targets outside the originating cloud -- provided VBR is the coordinator.

EC2 instances can be restored to Azure, GCP, or Nutanix AHV. Azure VMs can be restored to AWS, GCP, or Nutanix AHV. GCE instances can be restored to AWS, Azure, or Nutanix AHV. Instant Recovery to VMware vSphere, Hyper-V, and Nutanix AHV is supported from all three platforms via VBR. All of these require VBR-managed mode -- you can't drive a cross-platform restore from the standalone appliance UI.

Choosing the Right Starting Point

Side-by-Side Architecture Comparison