VMC for Disaster Recovery

A common use case for VMware Cloud on AWS is to leverage for Disaster Recovery. Many of my customers either don’t have a Disaster Recovery strategy or simply struggle to justify running a ‘ghost’ DC, just in case a disaster were to happen.

The way Disaster Recovery is offered today within VMware Cloud on AWS is through an add-on (VMware Site Recovery) that leverages vSphere Replication and VMware Site Recovery Manager.

Architecture

In this scenario, we assume an ‘application failure’ and not a whole ‘DC failure’. We assume that the application is internal only (not accessed over the Internet) and that the IP address must be maintained during the failure.

In this case, we would recommend the NSX L2VPN to stretch the network between the two sites. During the failover, the application would automatically be restarted on VMC and the VMs would boot on the ‘extended L2’ network and boot up with the same IP addresses.

Be aware – the default gateway on a network stretched by the NSX L2VPN (or with HCX L2VPN) remains on-prem. In the event of the DR, it means that the default gateway will remain on-prem until we change the network from ‘stretched’ to ‘routed’ (in other words – local to VMC).

After the failover, unstretch the network to make it local to VMware Cloud on AWS and its default gateway will be located on VMware Cloud.

I explained in a different post the ‘network types’ (routed or extended) in the following post.