Veeam backup for AWS design for multiple accounts

[sumeet]

Hello all,

I need to design the backup for AWS workloads (few EC2 instances and few RDS), that are spread across 20+ AWS accounts in difference regions.

What is the best way to have this designed for Veeam backup for AWS. This is my first time and hence some assistance with who have got this deployed will be helpful.

My plan is to have Veeam backup for AWS deployed in a account with its own VPC (using an existing VPC has not worked for me in my testing). Then from this account, setup IAM roles/policies to run backup from each of the production accounts.

Question 1: Can a worker running in this account which has backup appliance take backups of workloads in other accounts? The reason I ask is because during creating EC2 backup policy, while setting target settings (https://helpcenter.veeam.com/archive/vb ... ckups.html), there is an option to enable "Deploy workers in production account". If I do not enable this, does it mean that worker from my backup account connects to the EC2 instance in production account? If yes, then what is the difference between these two approaches of not deploying the worker from deploying the working in production account? Which is most cost effective? How about backup data traffic and the cost when it is across regions?

This is very confusing to me on how to get the worker configured when workloads is spread across multiple accounts and regions. The more the details, that much helpful it is for me, from both best performance and cost effective.

Question 2: Based on the documentation of adding worker configuration (https://helpcenter.veeam.com/archive/vb ... ackup.html) the need to have public IPv4 addressing attribute enabled, means that all the data traffic will travse through public IP. Does this mean that there is additional cost when backup data is sent across to the S3 repository?

Question 3: What is the best network connectivity approach when getting data to on-premise VBR repository? Is connectivity through internet the best option or having AWS direct connect? I understand this depends on the total backup data size and the daily change rate, but what is the best way to get this calculation done?

Question 4: In case of private subnet, the documentation says to configure private endpoints to let Veeam use private IPv4 addresses. So in this case, how is the backup data traffic traversed? What is the cost involved?

Question 5: The ports required to connect Veeam backup for AWS with VBR? This doco for AWS does not list the port https://helpcenter.veeam.com/archive/vb ... ports.html
The ports listed in VBR integration documentation https://helpcenter.veeam.com/archive/vb ... ports.html
only lists the VBR to AWS appliance ports, but not the AWS appliance to VBR port.
Also the first port 443, 80 says VBR server to AWS appliance and AWS services, I'm confused to what AWS service does VBR require access too?


In case of GCP and Azure, I had to setup network connection peering, which was easy, but looks like AWS does not have such an option.

Please will appreciate as much details as you can share.

Thanks,
-Sumeet.

[nielsengelen]

Hi,

1. Both are supported. For costs, it doesn't really matter that much as we deploy a worker in the region where the data resides. Costs only become bigger if you are going out of region for everything.

By default, we will create a snapshot and mount it to the worker to store it in S3 in a compressed format. If you run the workers in the backup account, that snapshot is shared. If they run in the production account, the snapshot is just mounted to a worker which runs there.

There are 2 reasons why deploying in the production account helps.
- Billing (if you need to assure that workers costs are run in the production account)
- Backing up EC2 instances that use the default EBS encryption key - for this it is a must as these type of snapshots cannot be shared to the backup account (AWS limitation)

2 and 4. By default, yes this is required however you can use private endpoints without the need for private IPv4 address as well (see the following appendix. There is no impact on transfer costs here.

3. There is no best option as far as I'm aware. From a security point of view, I would opt to look at AWS direct connect.

5. The listed ports are all that is needed. The integration just allows you to have an overview and communication between VBR and VB for AWS is done over port 6172 (as listed here). If you want to restore from VBR to AWS/Azure/GCP, these are listed here.

[sumeet]

Hi Niels,

Appreciate your quick reply. Helpful.

Please provide more details for Question 2. So when the worker is in the production account and the S3 is in a different account, both in the same region, then does the backup traffic traverse the public IP address and then to the S3 in different account? Would this incur cost of the data traversing the public IP address (I see AWS has listed 4.2 cents for each GB)? Or this is not applicable if in the same region. The reason I ask this is because of the need to enable public IPv4 addressing.
I'm pretty sure to receive questions from my client around the need of enabling public IPv4 addressing and if the backup data is going out in public address, before storing it in S3 backup repository.

You also mentioned that cost only becomes bigger if going out of region for everything. So if the workload are spread across multiple regions, what is the best design? Should I deploy Veeam backup for AWS appliance for each region or should I create S3 (Backup) repository for each region or does both apply or is this not correct? Please provide additional details.

I feel, providing few of such examples of high level designs in your documentation will be helpful.

Thanks,
-Sumeet.

[nielsengelen]

Our cost calculator will probably be the best to give you insight in the costs by playing around with it. Any change you make in a policy (more snapshots, backups, specific repositories,...) is automatically calculated. All of the mathematics are in there. We don't have this somewhere in full depth due to the fact that every region has specific pricing. I'm not sure where you got the 4.2 cents price (as there are many prices out there).

On the topic of design, 1 VB for AWS can be used to manage multiple regions. It would be recommended to then back up the EC2 instances within the same region to an S3 repository as the first backup. For long-term archiving, you could use Glacier within or out of the region (out of the region adds some extra costs but in the end, it depends on the request from the client). It looks to me that this is mostly a question you'll have to discuss/ask your customers about what they prefer.

We have best practices around scaling and sizing available in our guide.

[sumeet]

Hi Niels,

Thanks for your reply.

Thanks for the sizing guide.
But my questions are still not answered. Does the backup data traffic traverse out of Public IPv4 address in case of different account across different regions?

What happens in case if I have just one VB for AWS for multiple regions. But storage repositories each for a region. In such cases, when I get the data to my on-prem VBR cloud connect, does it the VBR CC connect to each S3 repository to get the data out, or does all S3 repositories transfer the data to VB for AWS and then from here it goes out to on-prem cloud connect. This is required as the number of hops the data does, that much would be the cost of data transfer.

Thanks,
-Sumeet.

[nielsengelen]

Within AWS, the data is passed via internal APIs and services, but yes, you pay to transfer data from snapshots to S3 between regions.

When transferring data to on-prem, regular egress costs will apply to it as data goes from the repository region to the on-prem repository.