Introduction
V12 is launching (register here) on Valentine's day and one of the most anticipated feature is the ability to backup directly to object.
As my Valentine's gift to you, I wanted to highlight what's required to get your first V12 backup Direct to AWS S3 going.
What do we need?
An S3 bucket, an IAM user with the proper policy and a VPC for the helper appliance.
A quick note about the V12 direct to object "helper" appliance
In the context of direct backups to AWS S3, the helper Appliance is a temporary EC2 instance that Veeam leverages to perform backup file health-checks.
The benefit is to avoid having to "pull-down" any of the backup data on-premises to perform that maintenance operation.
You configure the helper appliance settings at the Mount Server step of declaring your Object Repository.
Giving the proper permissions in your policy, Veeam gives you the option to auto-create the required VPC, Subnet, Security Group and Route table.
I personally would rather set all of this up-front. Wouldn't you?
Setting up the VPC for the helper appliance
Those of you that are familiar with setting up an AWS S3 Glacier archive tier in the V11 Scale Out Backup Repository, will remember that Veeam leverages a temporary proxy appliance to optimize object sizes before archiving. I blogged about this a few months back.
Why do I bring this up? Simply because the VPC requirements are pretty much the same.
Let's dive into it!
Below is a screenshot of my VPC's resource map.
This VPC has a private subnet with 3 routes:
- Internet bound traffic flow through the Internet Gateway
- S3 traffic flows through the S3 Gateway Endpoint
- Local traffic stays inside that VPC
The subnet does not allow for public IP auto-assignment.
The network ACLs are very permissive, but we restrict the inbound traffic to TCP22 and TCP443 in a security group as you can see below.
And that is all there is to it!
Next, we just need an IAM user with the proper policy.
Setting up the IAM user policy
Note:
- For the sake of simplicity the policy discussed below applies to non-immutable S3 repositories only.
- We'll assume that the IAM user and it's access/secret keys are already in place.
We should aim to make that policy as air-tight as possible.
We'll apply some of the security guidelines I discussed in a previous post.
Let's break down the policy:
Note: The S3 bucket I use in this example is "awsprotekt21"
Declaring the AWS S3 repository
You should now be able to declare your AWS S3 repository and pick the proper VPC configuration.
Congratulations, you can now create you first direct to object backup job.
Validate that the helper appliance works
Are you certain that the helper appliance will be able to start? Let's double-check.
Simply edit your backup job and adjust the health-check start time a few minutes past the Veeam Backup and Replication clock.
If all goes well, you should observe a successful health-check in your history log.
Further securing access
While our S3 bucket denies public access, we can further restrict and control its access with a bucket policy.
Let's get our user ID. For this we need to use the aws cli.
- Use
aws configureand specify the access and secret key of the IAM user you leveraged when declaring your S3 repository. - Get that IAM user's identity details with
aws sts get-caller-identity
- Add an inline bucket policy to
- Deny anyone access to your bucket
- Except the user identified by its user ID.
Summary
This concludes our Valentine's day treat and I hope you will find this post useful.
In this article I discussed the VPC requirements for the AWS EC2 helper appliance while making everything a little bit more secure.
I am looking forward to your comments.
Thank you so much for reading and now you still have time to get some flowers for your better half!
Happy Valentine's day!
