Cloud Integrated Agents

[warnox]

Hi,

I'm surprised this hasn't got more press so thought I'd share it.

As of v12, it is possible to back up cloud servers (Azure VMs and AWS EC2 Instances) using Veeam Agent without Cloud Connect or direct network connectivity (Cloud Integrated Agents). In my testing it works well, the only limitation is having to use object storage local to the server (Azure Blob / Amazon S3), rather than cheaper third-party alternatives (Wasabi etc).

Few configuration guides:
https://helpcenter.veeam.com/docs/backu ... ml?ver=120
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

Might be useful for those smaller environments where you don't have Veeam for Azure/AWS and aren't using a multi-tenanted backup appliance.

[Mildur]

Hi Warnox

Correct, our implementation of our cloud native Agent backup requires object storage from the same platform.
May I ask, is this request for Service Provider environments or a general request to be able to use cloud native agents with different object storage provider?

Have you consider to just install a default Veeam Agent and configure object storage as the target?

Best,
Fabian

[warnox]

Hi Fabian,

I was looking for a solution to back-up cloud VMs without an AWS/Azure appliance and without Cloud Connect, while still reporting back to VBR. The above meets this requirement, the only downside being the object storage limitation but that isn't a biggie.

Cheers.

[Mildur]

Hi Warnox

Thanks. In that case I suggest to use a regular protection group to deploy the agent.
Our Veeam Agent v6 allows you to use any object storage and it can be managed by a VBR server.
Only downside of this solution, you need to have a connection (VPN) between the Agent and the VBR server.

Installing our regular Veeam Agent on a Cloud VM is fully supported and was done by many of our customers before we had Veeam Backup for AWS/Azure.

Your request for additional supported object storage targets for cloud native agents is noted.

Best,
Fabian

PS:
I moved the topic to the Agent managed by VBR subforum.

[jim.lowry]

The biggest drawback I can see by using non-cloud native object solutions is cost. In the VCSP world, we see partners look at using VB for Azure/AWS/Google and IBM that want to target object storage outside of AWS, Azure, IBM, and Google respectively. It works from a technical standpoint, but you will incur large egress costs getting the data out of the hyperscaler cloud environments. It's pretty cost prohibitive.

If you are managing the machines via VCC or VBR, then external repositories can help with moving data around once you have it removed from the hyperscalers, but you'll still have the same cost limitations for egress data. If we do end up adding support for what you are looking to accomplish, protecting Azure/AWS/Google/IBM native machines and storing those backups off-platform to another/cheaper object platform, the egress costs will likely make up for any savings gained by storing the backups on a platform like Wasabi. There are also restore considerations that would need to be in place as well - which means ingress costs going back into the hyperscalers platforms.

In my experience, infrastructure design options for hyperscaler cloud providers like IBM, AWS, Azure, and Google is almost NEVER a technology problem. It is almost ALWAYS a cost problem.