Link Search Menu Expand Document
Elastio Docs

VPC Configurations for Cloud Connector deployment

Table of Contents

Choosing a VPC and Subnets

When you deploy the Elastio Cloud Connector into an AWS region, the Elastio tenant will prompt you to choose a VPC to deploy into, as well as one or more subnets within that VPC, in which Elastio will run all of its compute tasks. You can create a dedicated VPC for this purpose, use the default VPC in the region, or re-use an existing VPC that you already have created. However, you must ensure that all of the subnets that you choose are properly configured to be compatible with Elastio.

VPC Configuration Options

Most customers will deploy Elastio into private subnets in a VPC to ensure no aspects of the Elastio solution are exposed to the Internet. However deployment into public subnets are also supported, and can be useful for customers that want to use the elastio CLI to ingest data from outside of AWS, or to mount Elastio recovery points from a workstation or a server outside of Amazon. The configuration considerations are similar not identical.

Note that you can deploy Elastio into private subnets, or public subnets, but you should not deploy into a mix of public and private.

Common Requirements

Elastio relies on EC2 Spot to provide compute power much cheaper than regular on-demand pricing. For best results, this requires running in multiple availability zones. Thus, Elastio recommends that you deploy to at least two subnets in two different availability zones, with three subnets and availability zones being ideal. You can deploy into a single subnet and AZ, but this may result in reduced performance and higher cost.

In all cases Elastio requires that every subnet allow Elastio’s resources to communicate with Amazon API endpoints, as well as the CDN which Elastio uses to host malware and ransomware definitions. How this is achieved varies between public and private subnets.

Private Subnet Requirements

Fundamentally, private subnets must have a route to a NAT gateway which in turn has a route to the Internet.

Furthermore, you must enable the S3 gateway endpoint in your VPC. This isn’t necessary for public subnets, but with private subnets routing traffic through a NAT gateway, it’s critical that you enable the S3 gateway endpoint, otherwise Elastio’s bulk data movement into and out of S3 will transit the NAT gateway, which is very expensive. Note that when you create a VPC using the AWS Console UI, the default behavior is to enable the S3 gateway endpoint, however if the VPC was created with the command line, CloudFormation, or another infrastructure-as-code tool you should verify that S3 gateway endpoint is enabled before deploying Elastio.

Finally, ensure that auto-assign public IPv4 addresses is disabled. This should be the default, however if this is enabled it will interfere with Elastio jobs that expect to communicate over private IP addresses.

Public Subnet Requirements

Public subnets simply require that auto-assign public IPv4 is enabled, that there is a route to the Internet via an Internet Gateway, and that outgoing HTTP traffic is not blocked somehow.

The instructions on how to configure a private subnet with a NAT gateway are here.

Choosing your VPC Configuration

Whether you should use public subnet(s) with an IGW or private subnet(s) with NAT depends on whether you need to access the Elastio vault from outside of the VPC, such as from a development workstation, a CI/CD pipeline, an on-prem server, etc.

Deploying the vault entirely in public subnets will allow the vault to be accessible over the Internet. So, performing backups, restores and mounts from outside of AWS (either from other clouds or from on-prem workstations) will become available. This is the most flexible configuration, but it might not be permitted or desirable depending upon each organization’s security policies.

If the vault is deployed in private subnets, it will be accessed only from within the private subnets. Performing backups and mounts from systems outside of the subnets will be possible only after setting up a VPN tunnel into the VPC with a network path from the VPN tunnel to the private subnets, where the vault is running.

Testing your VPC Configuration

Before you deploy Elastio Cloud Connector, you may wish to verify that the subnets you intend to deploy Elastio into are compatible. Elastio provides an easy-to-use script, the Elastio VPC Reachability Analyzer, which you can run either in AWS CloudShell or in any properly configured Linux or macOS shell. Follow the link to the GitHub repo with instructions on how to run this script. It will analyze a VPC and tell you which subnets allow access to the Internet.

Transparent Proxies or URL Filters

If your AWS environment does not permit direct Internet access and instead routes traffic through a transparent proxy or some other filter appliance that blocks traffic by default, you will need to add rules to allow Elastio’s network traffic. See the troubleshooting section for information about what URLs in particular must be whitelisted.