Skip to main content
  • EN

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 configure and 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!

Great post. Always like to see the big cloud vendors and how things are configured.

Awesome! Thank you for sharing

Nice post with rich information and details, thanks @olivier.rossi!

How about data transfer out during retentions merging in S3 Bucket ? (In case forever incremental)

Can Helper Appliance do this inside AWS ?

Nice post!

Hi Olivier, thank you for this Valentine’s day gift :-)  Thanks to your article I was able to finish that part of the Helper appliance.  Already got the S3 rights so it was the EC2 policies that I just needed assistance with.

Even the regular Veeam documentation did not have your notes. So thank you for providing them :-)

Hello, 

 

This post is probably not that old but I’m getting troubles configuring the EC2 helper. I have followed all this post and set all the necessary permission but I’m getting permissions issue  

 

 

this is my account policy as described above

{
    "Version": "2012-10-17",
    "Statement":
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": <
                "arn:aws:s3:::******veeam-backups",
                "arn:aws:s3:::******veeam-backups/*"
            ]
        },
        {
            "Effect": "Deny",
            "NotAction": "s3:*",
            "NotResource": ,
                "arn:aws:s3:::******veeam-backups",
                "arn:aws:s3:::******veeam-backups/*"
            ]
        },
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Action":  
                "s3:ListAllMyBuckets"
            ],
            "Resource": o
                "*"
            ]
        },
        {
            "Sid": "EC2Permissions",
            "Effect": "Allow",
            "Action":
                "ec2:DescribeInstances",
                "ec2:DescribeKeyPairs",
                "ec2:DescribeVpcAttribute",
                "ec2:DescribeSubnets",
                "ec2:DescribeImages",
                "ec2:DescribeVpcs",
                "ec2:RunInstances",
                "ec2:TerminateInstances",
                "ec2:CreateTags",
                "ec2:CreateKeyPair",
                "ec2:DeleteKeyPair"
            ],
            "Resource":
                "*"
            ]
        }
    ]
}
 

 

anyone have thoughts?

Appreciate your support

@Boubchmo Thanks for reviewing this post.

Your policy is a bit different than the one I suggested.

"Statement": :

        {

            "Effect": "Allow",

            "Action": "s3:*",

            "Resource": Â

                "arn:aws:s3:::******veeam-backups",

                "arn:aws:s3:::******veeam-backups/*"

            ]

        },

S3:* is a bit too permissive but it should work.

 

 {

            "Effect": "Deny",

            "NotAction": "s3:*",

            "NotResource":  

                "arn:aws:s3:::******veeam-backups",

                "arn:aws:s3:::******veeam-backups/*"

            ]

        },

I have never used NotResource concurrently with Resource so I cannot comment on how it is supposed to behave.

I believe either you only allow a set of actions on a resource and thus everything else is denied - OR - you deny a set of actions on a resource and thus everything else is allowed.

 

{

            "Sid": "Statement1",

            "Effect": "Allow",

            "Action":

                "s3:ListAllMyBuckets"

            ],

            "Resource": "

                "*"

            ]

        },

You are missing the s3:ListBucket action.

 

There is a really good section in the Veeam User Guide that covers multiple scenario.

This one should get you started.

 

I hope this provides some additional information.

Thank you again for reading this post.

 

That’s a such useful post. thank you!

Comment


Terms & Conditions