In discussing network design with my clients, I talk about how routers, firewalls and other network gear can be interconnected to provide a scalable and redundant IP network. These foundations of network design apply to networks composed of tangible components or the virtualized infrastructure that extends corporate data centers to the cloud. I find that the networking aspects of cloud computing are frequently overlooked or addressed as an afterthought. In this article, I'll share my thoughts and experiences on data center/cloud integration and discuss the network ramifications of some services to the cloud.
There's much hype associated with the cloud. Until late last year, I found the non-stop talk about the cloud a bit off-putting, especially when mentions of the cloud began showing up in TV ads. What changed for me? Two things. First, I started to deploy services in on Amazon Web Services (AWS), including my company's website. I started to see the value of the cloud, not just for the big cloud consumers such as Netflix and Foursquare, but also for enterprises and Web-based services providers.
Second, companies began approaching me about integrating their data centers into the cloud. This customer interest made me realize that the network design services I provide have a new application in constructing data center extensions to the cloud.
Why are companies moving services to the cloud, and why would you want to consider moving your critical business applications from your data centers to the cloud? I see three primary drivers of this shift: cost, speedy introduction of new applications/services and availability. The large cloud providers realize economies of scale in operating virtualized platforms that few enterprises can replicate.
These providers offer GUIs and APIs that allow users to spin up new virtual machines (VMs) and services in minutes. Even if you already use virtualization in your data center, you'd have to invest a lot of money in systems and tools to match the flexibility of the cloud.
The last driver is availability. You probably have redundancy in your data center design to keep applications available to the user base. Imagine if you could host applications from many different geographic locations and have the infrastructure managed by the world's leading experts of high availability services.
In the infrastructure-as-a-service (IaaS) model, the tenants of the cloud provider can select VM characteristics such as CPU, memory and storage. Administrators have complete control over the VMs; they choose the operating systems and applications. Some IaaS providers allow administrators to control networking resources. This control of the network positions users to integrate their corporate network with the cloud in a way that is largely invisible to the end users.
The largest and most capable IaaS provider is AWS, which I will be focusing on in this article. AWS' competitors can't match its networking features at the time of this writing. No other provider offers the networking flexibility of AWS' service. Tying your business to one vendor is obviously not ideal. Let's hope that the competition improves so that multiple IaaS vendors that can offer rich networking features. Ideally, IaaS providers will adopt open standards so that enterprises can avoid vendor lock-in and proprietary technology. If cloud standards are adopted, businesses will be able to easily migrate services between different providers' clouds.
AWS offers two cloud environments--Amazon Elastic Compute Cloud (EC2) and Virtual Private Cloud (VPC). EC2 is intended for delivering services to Internet users without data center integration. Web servers offering content is one example. VPC is better suited for integrating with your corporate network and users. By default, the VPC has no connectivity to the Internet unless explicitly configured.
Amazon makes data center integration possible by letting IT:
- Create subnets using private addresses in the RFC1918 space
- Establish custom route tables
- Deploy network access lists (ACLs) that provide protection at the subnet level
- Pass configuration information to VMs using DHCP option sets
- Connect securely to your data center using IPsec over the Internet or dedicated connections from AWS data centers to your data center
VPC has limitations that administrators should understand. The VPC supports only RFC1918 space within the VPC. If this presents problems for your network, you can use NAT in your data center to make the VPC appear to be numbered from another address space. AWS built the VPC to scale to massive size. To accomplish this feat, the engineers chose a Layer 3 (that is, IP) foundation for networking. A ramification of this decision is that VPC does not support broadcast and VLANs. Traffic separation must be done at the subnet level. Since enterprise networks rely heavily on VLANs for separations, this is a significant problem if you expect to port VLAN-centric designs to the cloud.
Let's turn to an example. You want to provision a set of VMs in the cloud to run your Web-based expense reporting system. Only users on your corporate network need to access the application. You need two Web servers and one database server. Data between your data center and your VPC will be encrypted using the IPSec protocol.
AWS's VPC Creation Wizard makes the configuration of this set-up simple. You'll need one unused subnet from the address space that you use on your corporate network. Since the 10.0.0.0/8 is often used, we'll go with the 10.10.50.0/24 subnet. The wizard will automatically create the VPC router, which is a virtual router. While you can't log in to this router as you would a physical router, you can make routing tables changes that affect how this router does its work. In this example, no routing table changes are needed; the wizard sets up routing automatically.
Next, you'll create the VPC gateway and IPSec tunnel to your data center. In your data center, you must have a router that supports IPSec and the Border Gateway Protocol (BGP). AWS has tested Cisco and Juniper routers. While other routers will probably work, I recommend using one of these vendors for at least the initial turn-up. I've seen several organizations spend days trying to get IPSec to the VPC working with other vendors' equipment. You probably have a Cisco or Juniper router lying around somewhere. Use it. AWS provides the IPSec and BGP configuration for these routers. You can attempt to use another router once you've confirmed that the tunnel is working.
Now your data center has been extended to the cloud. Your users will access the expense reporting application no differently than they would applications hosted in your data center. You can use the VPC for much more involved setups that include multiple subnets for public and private use. The VPC can be configured to allow users on the Internet to reach the subnets you specify. This is useful for deploying e-commerce and other customer-facing services.
