Burst Up to the Cloud with a Preconfigured IP Address and VPN

From an IT-Ops, Dev-Ops or Security Architect standpoint, knowing and securing your infrastructure’s logical layout is a vital goal. As the technology world evolves, this basic requirement has constantly demanded that we learn new techniques to keep our business secure. The current push to the “cloud” has added a new challenge to the equation – random infrastructure! In this post, we’ll discuss how we can use Windows Azure to supplement our OnPrem infrastructure on an as-needed basis without exposing ourselves to additional 1) risk, 2) cost or 3) complication. But first… a little history to help us understand why this need exists.

A Brief History of Infrastructure Volunurability

If you think of the progression of computer systems in phases, you can see how this issue has grown more fierce … much like a mutating virus!

Phase 1 – Line-of-Business Application on a Single Computer

For a long time, businesses had LOB apps copied on each of their employees computers. No external connectivity was involved, no central database to hack, etc. An example of this is a newspaper company that I used to work for. They had a slew of sales personnel that managed their sales attempts, clients and billing directly on their local computers. Then they would print this information to paper forms that needed to be handed in to another department to actually fulfill the requests.

Basically, the fact that there was a lock on the front door was all that the IT department needed to do to “secure” their LOB applications :)

Phase 2 – LOB App on a Central Server

Technology advances and things get a little trickier! Clearly we have advanced to a better world – but the point of this article is not to discuss the benefits of each phase, but rather the complications of security.

So, the solution here is pretty simple… the central server would be on an internal network. Therefore, the locked front door and Mr. Security Guard still gets the job done.

Phase 3 – Multiple Locations Over the Public Internet

Now things get scary for the IT folks! At this point, someone has to actually do some thinking. Some would simply expose the application to the internet – perhaps as a Web App or a SaaS. However, since our application is still really a private utility and specific to our company… and since the only complication that was added since “Phase 2″ is physical distance and the need to span a public network… the solution that IT Ops would likely choose is a site-to-site VPN. This is especially true if there are many resources that are used, and not just a single application. For example, if there are multiple web apps, SQL databases, shared folders, etc.

So far, things have been pretty straight forward for the IT department. In all cases above, we know exactly what machines need to access what resources. Even in the more complicated scenario of needing to link two locations together via a VPN, both sites would probably have one or more dedicated IP addresses, so there is no dynamic complications to iron out.

What about in the “cloud”! Well, this is where things can get a bit tricky. A lot of people throw around the word “cloud”, and they simply mean that they have a managed data center that is off-site. And it’s true that you can purchase and maintain a 24/7 “cloud” presence, keeping your virtual machines running all the time… but at that point, you’ve just stepped backwards. That’s like putting wheels on a hover-car.

So, how do we utilize the cloud as a dynamically allocated resource that is still as secure as a remote site with a VPN?

Phase 4 – Dynamically Allocated Cloud Resources

To fully appreciate the complications and potential expense of this option, let’s consider the following scenario. Let’s suppose that we have a LOB application that consists of a Web Application (aka “Web Role” in Windows Azure) as the UI layer, a Windows Service (aka “Worker Role”) that processes long-running tasks, and a database server. Each layer of the application works together privately, however the database server needs to be addressable to your on-prem reporting server. The complete logical layout could look like this:

Now, let’s say your on-premises data center can handle the work load for the majority of the year. But a few weeks out of the year, you want to “burst up” to the cloud because you receive a tremendous amount of traffic. This is a pattern typical of companies who have cycles of business, such as those who revolve around annual taxes, “Black Friday”, holidays, seasonal usage, etc.

As the sample graphic above indicates, you can deploy your entire setup into Azure, and then hook it up to your on-prem site via a VPN. And while the VPN covers the “risk” factor, it can leave you stuck with excessive cost, or extra complication. How so?

Many Temporary VPNs – Cost and Complication

Let’s address the remaining issues on our list.

  1. Why is this complicated?
  2. Why is there a concern about cost?

Firstly, setting up a site-to-site VPN is a bit of a process. It takes time to get your local devices configured, deciding on IP ranges and subnets, etc. There is a lot you can do with PowerShell to dynamically create VPN configurations in Azure… but to download the configuration settings, discover the random IP addresses handed to you from Azure and then programatically configuring your on-prem network devices would take a monster of a program to build. No, this is not the task that should be scripted. It requires people to think and set up.

So the complication is, not that you need a Network Engineer to do the work… but rather, if you want to burst up at random times of the day as a response to increased traffic - that would be ridiculous to demand of personnel.

An alternative approach that allows you burst up would be to deploy a number of these LOB applications into Azure, but keep a small VM size and a low number of instances. This would allow you to crank up the size of the VMs and the number of instances in order to respond to random demand on your servers… but it has a cost of “keeping the car running” the whole time (including keeping the VPN connected).

So what is the solution? How do we burst up to the cloud, keep VPN connectivity and have a zero-cost solution when you don’t need the extra compute horsepower?

Preconfigure, Then Scale Up in Azure!

It’s quite likely that while reading this post, you’ve already figured out the solution. And if you haven’t up until this point, then the sub heading just above should be a huge clue :)

With Windows Azure, you pay by the hour for usage of the services, and not for configuration of the services. Meaning, you can create and configure your Virtual Networks/VPNs without paying a dime. In fact, you can create all of the PaaS and IaaS cloud services that you would need… and as long as you didn’t have any instances deployed, you’re not charged.

This of course will take all the same manual work from that Network Engineer – but at least it’s only one time. From there, you can use a PowerShell script (or the Azure REST API, etc) to dynamically “connect” and then deploy instances of your LOB application to the cloud. This way, the meter only starts when you are actually using Azure.

Once you no longer need the extra machines in the cloud, then spin down the instances to “0″, disconnect the VPN gateways and you’re done! You’ll keep all of your configuration settings. You’ll keep the VIP’s that were randomly generated when you created the Cloud Services, and you won’t be racking up a huge bill.

By the way, this solution also works if you don’t use a VPN, but rather simply punch a whole in your firewall to allow traffic from the VIP given you by Azure.