Veeam v13: Direct Backup to AWS

Veeam v13 Series | Component: VBR v13, AWS S3 | Audience: Enterprise Architects, Hands-on Sysadmins

Direct backup from VBR to AWS S3 is one of the most common capacity tier deployments in the series, and it's also one of the most common sources of surprise AWS bills. S3 costs have enough moving parts (storage class, request volume, data retrieval, egress) that what looks like a straightforward configuration produces unexpected charges if you don't model the cost before writing the first byte. This article covers the VBR configuration for direct S3 backup, object storage repository setup, immutability with Object Lock, EC2 restore workflows, the cross account setup for additional immutability isolation, and the cost model you need to work through before choosing your storage class.

1. IAM Setup: The Least Privilege Approach

VBR needs an IAM user or role with permissions to read, write, and delete objects in the target S3 bucket, plus the ability to read bucket location and versioning status. Don't hand VBR your root credentials or an admin user. Create a dedicated IAM user for VBR with only the permissions it needs.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VeeamS3Access",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketLocation",
        "s3:GetBucketVersioning",
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:ListBucket",
        "s3:ListBucketVersions",
        "s3:PutObject",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts",
        "s3:ListBucketMultipartUploads"
      ],
      "Resource": [
        "arn:aws:s3:::your-veeam-backup-bucket",
        "arn:aws:s3:::your-veeam-backup-bucket/*"
      ]
    },
    {
      "Sid": "VeeamImmutabilityAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObjectRetention",
        "s3:PutObjectRetention",
        "s3:GetObjectLegalHold",
        "s3:PutObjectLegalHold",
        "s3:GetBucketObjectLockConfiguration"
      ],
      "Resource": [
        "arn:aws:s3:::your-veeam-backup-bucket",
        "arn:aws:s3:::your-veeam-backup-bucket/*"
      ]
    }
  ]
}

2. Configuring the S3 Object Storage Repository in VBR

1. In VBR, go to Backup Infrastructure, then Object Storage Repositories, and click Add New. Select Amazon S3.
2. Enter the IAM access key and secret key. Select the AWS region where your bucket lives.
3. Select the bucket and folder. The folder is the prefix within the bucket where VBR writes its data. You can share one bucket across multiple VBR deployments by using different folder prefixes.
4. Select the storage class. S3 Standard is the default. S3 Standard-IA (Infrequent Access) reduces storage cost for data accessed less than monthly but adds a per gigabyte retrieval fee and a 30-day minimum storage duration. S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive are available for archive tier use. More on storage class selection in Section 5.
5. Enable immutability if required. See Section 3. You must enable versioning and Object Lock on the bucket before this option works.
6. Set the concurrent task count. It controls how many simultaneous upload streams VBR opens to S3. The default is reasonable for most internet connections. For high bandwidth direct connect or VPN connections, increase this to improve throughput.

3. Immutability with S3 Object Lock

S3 Object Lock prevents objects from being deleted or overwritten for the duration of the Object Lock retention period. When VBR writes a backup file to a bucket with Object Lock enabled, it sets a retention period on each object based on the backup job's retention settings. Even if an attacker compromises the VBR server and the AWS credentials, they can't delete the locked objects during the retention window. The root AWS account itself can't bypass compliance mode Object Lock.

Bucket Prerequisites

• Enable S3 Versioning on the bucket before enabling Object Lock. Object Lock requires versioning.
• Enable S3 Object Lock on the bucket at creation time. Object Lock can't be enabled on an existing bucket that wasn't created with it. If you have an existing bucket, you need a new bucket for immutability.
• Do not configure a default retention period in the Object Lock settings. VBR sets the retention period per object based on your backup job retention. A default retention in the bucket settings conflicts with VBR's per object retention management.

VBR uses Object Lock in Compliance mode. In Compliance mode, no user including the AWS root account can delete or modify an object before its retention period expires. That's the right mode for regulatory compliance. Governance mode allows privileged users to bypass the lock, which undermines the purpose for backup immutability against ransomware scenarios.

4. Cross Account Immutability for Additional Isolation

Storing backups in the same AWS account as your production workloads has an obvious risk: if the production account is compromised, the backup bucket credentials are compromised too. Cross account backup places the S3 bucket in a separate AWS account with its own root credentials, IAM users, and billing. The VBR server writes to the cross account bucket using an IAM role that allows cross account access. Compromising the production account doesn't give an attacker access to the backup account's root credentials.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowVeeamCrossAccountAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:user/veeam-backup-user"
      },
      "Action": [
        "s3:GetBucketLocation",
        "s3:GetBucketVersioning",
        "s3:GetBucketObjectLockConfiguration",
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:GetObjectRetention",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:ListBucket",
        "s3:ListBucketVersions",
        "s3:PutObject",
        "s3:PutObjectRetention",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts",
        "s3:ListBucketMultipartUploads"
      ],
      "Resource": [
        "arn:aws:s3:::veeam-backup-isolated-bucket",
        "arn:aws:s3:::veeam-backup-isolated-bucket/*"
      ]
    }
  ]
}

5. Storage Class Selection and Cost Modeling

This is exactly where surprise AWS bills come from. S3 pricing has four cost dimensions: storage per GB per month, PUT/GET request costs, data retrieval costs (for IA and Glacier classes), and data egress costs when you restore. You need to model all four for your expected data volumes and restore frequency before choosing a storage class.

The minimum storage duration matters. If you delete an object in S3 Standard-IA before 30 days, you're charged for 30 days regardless. For backup chains where Veeam might clean up old restore points frequently, objects deleted before the minimum duration add hidden cost. This is particularly relevant for short retention jobs writing to IA or Glacier storage classes where retention is shorter than the minimum duration.

6. EC2 Restore Workflows

Restoring from an S3-backed repository to EC2 instances requires Veeam Backup for AWS or the VBR restore workflows that use the stored backup data. The two paths available from VBR:

• Instant Recovery to EC2: VBR uses its vPower NFS equivalent for object storage to mount the backup file directly and register the VM in EC2. This requires an EC2-based gateway or a VBR instance running in AWS. The restore starts quickly but runs from the backup repository, so sustained performance depends on S3 read throughput.
• Full restore to EC2: VBR reads the backup data from S3, converts it to an EC2-compatible format, and creates the EC2 instance in the target region. This is slower to start but the EC2 instance runs from EBS volumes when complete and has full production performance.

For restoring from Glacier storage classes, add the retrieval time to your RTO calculation. Glacier Flexible Retrieval standard (free tier) takes 3 to 5 hours before the data is available for VBR to read. Expedited retrieval ($0.03/GB) is available but gets throttled during high demand events unless you've purchased provisioned retrieval capacity. Model your Glacier RTO honestly before deploying Glacier as a restore tier for anything with a defined RTO.