Kit Wai Chan - Fotolia
There was a time when using a virtual private cloud was reserved for restrictive security designs and certain verticals such as financial services or others with highly secure data. Now it's difficult to justify not placing production systems inside a virtual private cloud. Amazon VPC isolates resources from the other tenants of the AWS multi-tenant cloud, allowing enterprises to improve security, and enables hybrid cloud connections with the data center.
Amazon VPC isn't without issues, however. One major hurdle is setup and maintenance. But if IT teams understand their business and security requirements, as well as the enterprise's need for automation, they can build these factors into the design from the beginning and simplify maintenance down the road.
Designing your AWS VPC
With greater control over network and security comes greater responsibility for design and setup. From reserving enough IP addressing capacity to specifying external and internal-only subnets and elastic load balancers (ELBs), cloud architects must carefully plan designs before implementing them.
Design with growth in mind: Once you allocate an IP address, you cannot expand without tearing down the VPC and rebuilding it. Using a VPC makes remote access via Secure Shell (SSH) and Remote Desktop Protocol (RDP) more difficult, but not insurmountable. For security purposes, don't open SSH or RDP to a wide range of public Internet addresses. Instead, set up a bastion host jump server and allow remote access only from this server's IP address.
The actual process of configuring a VPC is quite easy and can be done using a setup wizard. But the devil is in the details.
Discuss with business units to determine what problems you need to solve and what your SLA requirements are. If your business allows windows for downtimes or generous outages, you won't need to automate the setup and upgrade maintenance as much. But most shops don't have these luxuries, so automate the VPC setup as much as possible to fit within change-management windows.
When using an Amazon VPC, you must explicitly set the network, security, server, operating system and application configurations to create a functioning system. All of these configuration settings should be ironed out before you try to use any automation.
Corporate culture will dictate the readiness to use automation tools; startups with a large group of programmers are often eager to use application programming interface (API) calls and bypass the AWS management console as much as possible. It's difficult to go from whiteboard plans straight to writing Chef, Puppet or JSON scripts to automatically set up a VPC, but it can be done.
On the contrary, enterprise data center engineers may want to use the AWS management console, but this console-only approach won't scale up to a production setup. An effective AWS VPC design team should rely on enterprise data center engineers for change management and operational ownership best practices as well as programmers for coding and automation capabilities to automate setup and maintenance.
Amazon VPC and availability zones
Consider using separate VPCs -- and sometimes different availability zones (AZs) -- for development, quality assurance (QA) and production workloads. For example, if you are in the U.S., use US West 2 and US EAST 1 AZs, because they are the least expensive zones with the most available functions.
Use the whiteboard for design, the AWS management console for development and automation for production workloads. If you have the benefit of putting QA on the Amazon VPC, then you can use this to work out any automation bugs using Chef, Puppet or CloudFormation.
Designing infrastructure tiers -- logical groups of functions in your VPC such as the firewall, Web, applications and the database -- can help to modularize your configuration, which can pay dividends when it's time to manage the setup. If you are using dual availability zones for redundancy, these tiers will have a separate subnet for each AZ. Each tier could be comprised of the two subnets, single ELB, AutoScaling group, security groups and the instances running in that tier.
You can upgrade a Web tier independent of the database tier; and you can create a Web tier CloudFormation template that spins up all the components required for that tier and run it in parallel with the older version of that same tier. By using the ELB endpoint address, you can point API calls to the new endpoint address to transition them from other tiers and test new versions of a whole tier.
About the author:
With a background in managing one of the largest global financial networks, Mark Szynaka brings his network monitoring, security and ITIL best practices to the cloud. He helps enterprise IT investigate and implement cloud computing architectures -- public, private and hybrid -- using Amazon Web Services, Terremark/Verizon and Rackspace technologies.