Cloud Services

Considerations for Connecting to Your Recovered Workloads

While most of the talk around cloud-based disaster recovery is on how you protect your workloads, a number of people are starting to look at this from a different angle. How do you connect to those workloads once they have failed over and are running in the cloud? You have literally moved all your applications and services to another datacenter, potentially in a different state or even country. “Great,” says the IT admin, “all our applications are running as expected, we don’t have any data loss.” “Fantastic job,” says the CIO, “now why can’t I open up our CRM tool? What’s this ‘not connecting’ error?”

Let’s think about this. Even though all your apps and services are running, your users have no idea how to connect to them. In the worst-case scenario your datacenter is dead. What is the best way to get users to connect to the workloads? We have a number of options that can help us here:

  1. Public-facing applications
  2. Point-to-Site SSL VPN
  3. Cloud-based Desktop-as-a-Service

In the interests of this article, we will focus on options 1 and 2. For Cloud-Based Desktop-as-a-Service, I would recommend reading here:

First, let’s focus on public-facing applications, and what this term actually means.

Public-facing applications are typically E-Commerce or web service applications. Anything with a front-end web server that is being served to the public. Typically, any company website or online store.

When we look at these applications and services, they have a front-end web server that is providing the content to the end user. This is normally accessed over ports 80 or 443 (http or https), and provides traditional Internet pages. When you fail over these workloads to a disaster recovery offering, whether being another data center you own and manage, or a cloud-based disaster recovery offering, you will still need to access these workloads via port 80 or 443.

A user simply enters the same domain name into the web browser and it takes them to the website. However, from an admin perspective, when we failover our webservers to VMware vCloud® Air™ we need to make sure the DNS is pointing to the correct location. We would need to change the DNS settings to point to the external IP address of the vCloud Air Edge Gateway. This can be found on the gateways tab in vCloud Air.

Screenshot 2015-10-06 10.55.29

Once we change the DNS settings and failover everything is accessible in the same way as it was for our end users.

Lets take a graphical look at this to make it easier to understand:


Nothing really changes from a perspective of publishing web content out to the Internet. However, most companies do not publish the majority of the applications they protect with disaster recovery on the Internet. So how do end users connect to critical applications in the event of a disaster?

Point-to-Site SSL VPN

Let’s take a step back, and think about what the end goal is. Our datacenter is on fire; we have failovered all the workloads over to vCloud Air. Accounting, finance, customer service, R&D are all back up and running. We are a pretty pleased bunch of admins as all our VMs are powered on, running and can talk to each other. Awesome! Now what about the end users? They are now all at home trying to connect to the services, how do they do that? By leveraging a Point-to-Site SSL VPN, the end users can then securely connect into the vCloud Air environments and work from any location. No different than how we provide capabilities when failing over to a physical datacenter.


What we do in this scenario is deploy a VPN end point appliance into a VMware vCloud® Air™ Virtual Private Cloud OnDemand.  This gives us the capabilities to provide end users with SSL VPN connections.  We also have a cloud-to-cloud VPN configured between the VPC OnDemand and DR VDC, giving us connectivity from the VPC to the DR VDC.  Once an end user initiates a VPN connection, they simply route all the traffic from the VPN appliance over the cloud-to-cloud VPN and into the DR VDC onto the Recovery Network.  This gives us the connectivity capabilities we need to provide secure connections to our end users in the event of a failover.

This becomes even simpler when Advanced Networking Services is generally available as the vCloud Air Edge Gateways will be able to provide SSL VPN connectivity directly without the need to install a VPN appliance as a Pilot Light Virtual Machine.

I hope this gives you a high level overview of how to connect to workloads in the event of a failure, and gives some food for thought when designing the network connectivity for such scenarios.

If you’re ready to get started with the hybrid cloud, visit

Be sure to check out the vCloud Air Community, where you can join or start a discussion, watch our latest vTech Talk video, enter for a change to win swag in our monthly giveaways and more. Get started here!

For future updates, follow us on Twitter and Facebook at @vCloud and


One comment has been added so far

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.