So, you’re a Windows administrator looking for a better way to run some of your servers. You’re not looking for an all-or-nothing solution. You’ve got no plans to migrate everything anywhere. Why would you? You’re already running a perfectly good datacenter.
You do, however, appreciate the cloud for what it is: A location for possibly hosting some of your server infrastructure, when doing so makes sense. And you’ve just woken up this morning realizing exactly what makes sense.
You’re moving your DMZ.
Why the DMZ?
The IT buzz phrase of recent years has been "virtualization candidacy" – which servers would offer the best return spent on spent virtualization dollars. Now, there's a lot of talk about "cloud candidacy" as Windows pros determine which servers work best when they're hosted outside the datacenter.
One group of servers that makes particular cloud sense is the set that constitutes your DMZ. Unlike all others in your Windows infrastructure, the network for these servers has been already segregated from your internal LAN. The users of these servers are often themselves outside the LAN. This hardware may be servicing end customers, or it may be facilitating outside services for inside users. In either case, DMZ servers’ existing network segregation in combination with the protections already in place – firewalls, network ACLs, service isolation, and so on – makes this group a perfect fit for your first foray into the cloud.
This article focuses on Amazon’s EC2 infrastructure, but depending on your specific needs, budget, and the features you require, your implementation could easily replace EC2 with Hosting.com, Rackspace, Bluelock, VM Racks, or any of the array of steadily-growing regional providers. While the exact steps each provider requires to migrate servers to the cloud will be different, the end result is the same: Your servers migrate off your infrastructure and onto someone else’s.
1. Figure out what collection of instances your servers require.
Amazon refers to its virtual machines as instances, and provides an array of hardware sizes with prices to match. Instances can be provisioned with a range of operating systems, including Microsoft’s Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2.
A common confusion in selecting the right EC2 instance centers around its three available types. Most Windows servers will be provisioned as either an On-Demand Instance or a Reserved Instance. The single difference here is that On-Demand Instances are priced by the hour, whereas Reserved Instances require a one-time payment up front that locks in a lower price over a longer term. In short, if these Windows servers are very short-term in nature (think days of time), then select an On-Demand Instance; if they’re long-term in nature (think years of time), then pay the up-front charge to lock in the lower rate.
The third type, a Spot Instance, is usually reserved for special cases where applications are coded to scale across multiple servers when they’re available. For now, if you’re just getting started, you can safely ignore Spot Instances for the time being.
2. Provision shared storage (if necessary).
Each instance size comes with a preconfigured quantity of local disk space. Some DMZ workloads, however, require access to shared storage, such as what you would provide from a SAN. For these servers, your next step will be to provision one or more Elastic Block Stores, EC2’s parlance for what is essentially a SAN LUN. EBSs can be attached to any server or servers that share an Availability Zone, which is a configurable set of servers you’ve decided will access that storage.
3. Create a private network.
The DMZ in many environments is often more than just a single subnet exposed to the Internet. In many cases, “the DMZ” is in fact a collection of subnets with rules, access control lists, and other connectivity features tied together to create a cohesive whole for its services. Some areas of that DMZ may have access back into your internal LAN, while others are typically walled off to Internet access only.
The next step in moving Windows to EC2 requires recreating those subnets, connections, and LAN integrations. You’ll accomplish this with an EC2 Virtual Private Cloud. Powerful in its configuration capability but simple in concept, creating all these logical connections with EC2’s management console is remarkably intuitive. You’ll find yourself creating the subnets you need with the IP addressing scheme your VMs require. You’ll then wall them off logically per the same network rules you’ve already got in your local implementation. Connections back to your internal LAN are facilitated and secured through the same VPN protocols your users use today to access LAN resources while on the road.
4. Migrate your Windows servers from DMZ into the new EC2 environment.
This process in many cases requires running a series of commands via EC2’s command-line toolset. If your DMZ machines are virtualized atop the vSphere platform, you can download a different and much simpler “import connector” that arrives as a vCenter Virtual Appliance. With either, you’ll find yourself preparing servers, uploading them, and verifying their settings with relative ease.
Moving Windows. When it Makes Sense.
Moving Windows into the cloud becomes a more concrete activity once you start considering which Windows servers you might move. The cost model is there, if you target your network’s low-hanging fruit first. As is the security model, particularly when considering the servers in your DMZ. Now even the tools are ready to simplify this task.