Evolution of the Custom Cloud: Part 1 "Architecting the Cloud"
Last year Metal Toad launched its Custom Cloud Service. Since then, our Custom Cloud Architecture has evolved to handle the increased complexity and security requirements of our clients.
It all started September 2013 when we quickly moved the Emmys to AWS in time for their Prime Time event. The setup was as basic as it could be; With Lots of EC2 instances, RDS, and an Elastic Load balancer. It was secure and it was stable, but it wasn’t elegant.
From the outset, we knew the best setup would involve the use of AWS VPCs but for the Emmy’s we didn’t have the time to build one out and develop the tools for managing it.
Then in Spring 2014, Metal Toad was asked to host a new Client in AWS, Cliqa. It wasn’t going to be as large as the Emmy’s but I was going to build their Cloud better. I read through several official documents and blogs on setting up VPCs; and eventually arrived at the architecture below.
You can see we setup a VPC that had two subnets across multiple Availability Zones. The stack was more secure and better organized. However, we did discover a few design problems. First, if servers wanted to get access to the internet to download patches or to contact our Puppet master each Server needed an ElasticIP. Second, even with security groups, I didn’t want to leave so many servers with direct access to the internet.
After discovering these problems, I went back to the drawing board. I found documentation for two options: building VPC with a public and private network and documentation on building a multi Area Zone VPC for availability. But I was greedy and wanted both.
Below is the architecture I came up with.
As you can see, we now have two subnets in each Availability Zone. We use the Routes in VPC to direct traffic from the private subnets to the NAT instance, then to the internet. The NAT instance also serves as a gateway server to restrict access for services like SSH to a single point in the VPC.
All web traffic still flows through the Elastic Load Balancers and does not use the NAT instance.
This architecture provides us with a framework for building our Custom Clouds. It grants better control of security, while reducing the amount of resources that we use from AWS.
In part two: Evolution of a Custom Cloud: "Building the Cloud” I’ll go over instructions for building this architecture in AWS.