AWS

VPC and subnets

When performing a recovery, you need to provide the target network to which the recovered EC2 instance will be launched, this network is the VPC and subnet configuration.

Although it is possible to use the CDRS-VPC and its public subnet, it is recommended to have at least one public VPC and a public subnet configured on your AWS account before starting the recovery. 
The public subnet should be connected to an AWS Internet gateway in order to allow connectivity from the Internet. You may have more than one public subnet in your VPC.

It is also recommended to set the subnet to automatically assign public IP to new instances connected to the subnet, this way, you will not need to manually create and assign an elastic IP for every recovered instance.

If you are using or planning to use a VPN, make sure to have a pre-configured VPC and a private subnet for recovery that are connected to your VPN.

An example of configuration of a public subnet with auto-assign public IPv4 enabled:

Security groups

When recovering a virtual machine, in the advanced options of the VM recovery page, you can choose the security groups you want to attach to the instance. If you do not change the security groups in the advanced options, the default security group of the VPC will be attached to the instance and it will most likely not allow any inbound connections, so editing the default security group will be required, or attaching other security groups after the instance will be recovered.

It is recommended to have a pre-configured security group that allows inbound connections from trusted IP addresses to the instances and selecting it from the advanced options. If you are not sure what are the IP addresses of your organization that you want to access your recovered instance, make sure to set the source to 0.0.0.0/0 that allows access to all IP addresses.

Note: Setting the source to 0.0.0.0/0 is very unsecure and will allow others the ability to connect to your instances. If you set 0.0.0.0/0 as the source range, in order to reduce the risk of unauthorized users accessing your instances, it is recommended to change it to a list of IP addresses that you want to have access to the instances as soon as possible.

A recommended security group will include SSH, RDP, and HTTPS protocols in its inbound rules. Make sure that the security group is created in the same VPC that you plan to recover to.

If you are editing the default security group, add the described protocols with the limits of IP range. You may also have other protocols configured for other needs, but it is recommended to use a dedicated security group for recovered instances.

Proxy

When working with a CDRA (starting 19.5) or PowerProtect Data Manager (starting 19.6), you can configure that the outbound traffic that is sent to the cloud will use a proxy server running on-premises. All other internal traffic (Avamar, PowerProtect DD, vCenter) will not be routed through the proxy server.

When working with Azure, you will need to keep the username and password authentication to the proxy blank (this is an Azure limitation), and when working with AWS you can either use blanks as well or set a username and a password to the proxy server.

To configure the proxy server, use the CDRA UI, under the additional network settings on the first tab. Or when using PowerProtect Data Manager, you can configure the proxy settings using the Cloud Disaster Recovery tab in the Storage page in the Infrastructure menu.

Azure

Vnet and subnet

When recovering you will need to select the target network (Vnet and subnet). It is recommended to create a dedicated Vnet and a public subnet for recovery. When creating a new Vnet in Azure, you need to select a resource group to contain it, it is recommended to create a dedicated resource group for that.

Security groups

It is recommended to create a network security group for recovery that will allow inbound traffic to your recovered VMs for the protocols of SSH, RDP, and HTTPS for the IP addresses range of your organization. It is also recommended to create the security group(s) in the same recovery-dedicated resource group.