Cloudbursting

Written by Scott Leerssen and Aaron Bawcom

Bursting to the Cloud

Most would agree that cloud computing provides practically limitless capacity and unparalleled high availability and fault tolerance. However, making the move to 100% cloud may have its challenges.

What are some of the key barriers to moving to the cloud?

• Capital depreciation that has yet to complete for the current environment
• Understanding and comfort level of your organization regarding data security in public cloud
• Your organization’s current skill level in cloud computing

These and many other factors might make you hesitant to embrace cloud computing. There are many methods of on-boarding your organization to the cloud that mitigate these objections and provide a clear path to moving workloads into the cloud. One of these approaches is cloudbursting. As you implement cloudbursting you’ll also be introduced to key concepts and practices that you’ll need to understand as you move into the cloud.

Cloudbursting is on-demand scaling into the cloud during heavy load on local datacenter services. This allows nominal operation of on-premise resources during typical load periods, while utilizing the elasticity of the cloud to scale horizontally during peak demand. Since these cloud resources are ephemeral and only exist when needed, it also reduces cost, which is another major benefit of cloud computing. If your organization is looking to move to the cloud for the first time or looking to bolster capacity, cloudbursting could be your answer.

Cloudbursting Architecture

The concepts and approach presented here utilize Amazon Web Services for horizontal scaling of local datacenter web services using cloud resources which include:

• A Virtual Private Cloud (VPC) to contain the subnets and cloud resources.
• An Application Load Balancer (ALB) to distribute load between the on-premise resources and the on-demand Elastic Cloud Computing (EC2) instances.
• An EC2 Auto Scaling Group (ASG) to scale up EC2 instances when needed and down as load diminishes.
• An ASG to maintain a collection of high availability proxy EC2 instances to direct traffic to on-premise resources.
• A Direct Connect secure, high speed connection between the local datacenter and the VPC.
• Route 53 to resolve the web presence (e.g. https://www.mydomain.com) and tie it all together.

A number of other associated AWS features will be used as well, but these are the main components. The following image illustrates these resources and how they connect to the local datacenter to serve traffic for the web service.

Each of the AWS services will be explained in more detail based on a logical sequence of services needed to complete the cloud bursting capabilities. Let’s begin with the networking piece.

Virtual Private Cloud (VPC)

The Amazon Virtual Private Cloud (VPC) enables you to launch AWS resources into a virtual private network. This network is similar to a traditional network that you’d operate in your own data center. The added benefit is the unlimited scalable infrastructure of AWS. Think about that… Unlimited compute, data, and infrastructure resources at your fingertips.

The VPC in this architecture will have at minimum two subnets: public and private. The public subnet will be attached to the Internet via an Internet Gateway and provide the ingress point to which our Application Load Balancer will be attached. The private subnet will isolate traffic to our on-demand instances that provide cloudbursting capacity, as well as the proxies that send steady state traffic to the datacenter. Both the public and private subnets have their own routing tables; the public subnet is limited to only the ingress via the internet and the private subnet can only communicate with the resources within that subnet such as the connection to the datacenter. However, services inside the public and private subnets may communicate with each other as long as allowed by the security groups attached to any given resource, allowing public internet facing endpoints to connect to their associated private service endpoints.

Application Load Balancer (ALB)

Within AWS services, the Application Load Balancer (ALB) is a service that distributes incoming application traffic to multiple targets (i.e., EC2 instances or IP addresses) in one or more target groups across multiple Availability Zones.

In our cloudbursting model, we have our ALB configured to serve TLS for our web application and forward the traffic to a single target group that hosts two types of targets. The first is our proxy target, which will forward HTTP traffic to the datacenter. The second is an on-demand instance of the web application, that starts when the load through the proxy targets exceeds a configured per-target threshold. Each target type is in its own auto-scaling group, described in the next section.

AWS Certificate Manager (ACM) provides the TLS certificate for the ALB. ACM is simple to use and fully integrated with other AWS services, making it simple to centrally manage and audit the use of each certificate. Additionally, AWS Certificate Manager makes it easy to import certificates issued by other CAs and deploy them with the ALB.

Auto Scaling Groups (ASGs)

AWS Auto Scaling is a simple, yet powerful tool which monitors load and automatically adjusts capacity as needed. It also provides a number of options to help control cost, including the use of spot instances, which are EC2 instances priced at a discount and are perfect for loads that can be ephemeral. Be sure to check out spot best practices for tips on getting the most out of spot instances.

ASGs make use of a Launch Configuration or Launch Template to define what to run as a target instance. Although they accomplish roughly the same purpose, the Launch Template provides more features and flexibility and is the preferred method for autoscaling. Our cloudbursting model uses two ASGs with Launch Templates tailored to our proxy and on-demand application targets.

The proxy and web application launch templates each use their own Amazon Machine Image (AMI) tailored to the specific functionality. An AMI can be thought of as a template of a base image that is used to create a fully functional server. Creating a custom AMI can be as simple as starting up one of Amazon’s existing base images, updating and testing the desired end state, and then creating a new AMI from the result. There are also a number of infrastructure as code (IaC) methods such as Packer that allow one to script the installation of applications, tools and configuration on a base Amazon image to generate a custom AMI. Lastly, if the AMI route just seems a bit overkill for the task at hand, the launch template user data may be used to install software and add configuration to an instance at boot time before the server is ready for service in the target group.

As mentioned in the load balancer section, both of the ASGs will use the same target group, which provides the ability to monitor all of the existing targets across both scaling groups and react accordingly based on the per-target load.

Proxy ASG Targets

The proxy autoscaling group contains the HTTP proxies that send load directly to the datacenter. Although, as the name implies, the autoscaling group can scale up and down to meet demand, it can also be used to ensure that a minimum number of proxies is available at all times across multiple availability zones, providing high availability and fault tolerance. Thus, for the proxy ASG, our configuration across two availability zones will be set to a static count of 2. If, for some reason an instance or availability zone becomes unavailable, the ASG will bring up another copy of the proxy to take over for the loss of the instance.

One important feature of the ALB should be noted here. Although it is possible for it to balance load to IP addresses instead of target instances as configured here, when forwarding traffic to an instance, the ALB retains the client IP address so that the web application will see the identity of the issuing endpoint and not the load balancer itself. This is often required by web services to maintain session information. For our proxy solution, we can retain the originating client IP in an “X-forwarded-for” header, and even re-establish TLS to the datacenter if so desired while retaining the original caller identity.

Web Application ASG Targets

As with the proxy ASG, the web application uses a custom AMI in its launch template, however it’s scaling policy is what provides the cloudbursting functionality. With an initial target minimum set to 0 and a per-target connection rate set to a reasonable threshold where the datacenter performance might soon degrade, the web application scaling group will start new instances until the per-target connection rate is below the threshold. As load drops, instances will be removed from the ASG until there are none remaining, and all traffic is once again handled by the datacenter via the proxies.

Connecting to the Data Center

AWS Direct Connect can be thought of as a virtual ethernet cable between the datacenter and the VPC. There are varying connectivity and throughput options available which are best discovered by checking out the AWS documentation. The process of acquiring a fully functional Direct Connect takes some coordination with Amazon, a local AWS Direct Connect provider as well as the local datacenter IT staff. The setup may take some work, but the high availability and throughput when compared to other solutions such as VPN are worth the effort.

Note: In the cloud model, security is a shared responsibility between AWS and the organization procuring the services. Amazon secures the physical facility, computing hardware (i.e., servers, storage, networking), virtual machines, software infrastructure, and the API layer. The organization is responsible for the application software and configuration, as well at the operating system (potentially.) Keep this in mind as you setup your cloudbursting infrastructure.

Tying it all Together with Route 53

AWS Route 53 is a highly available and scalable cloud Domain Name System (DNS) web service. Although not strictly necessary for this approach, it does offer a few advantages over traditional DNS provided by the domain registrar or local DNS. First and foremost, it provides simple integration with other AWS cloud services such as application load balancer and certificate manager. It can also be used to resolve addresses inside and outside of AWS, taking advantage of the global scale Route 53 provides. Other features such as latency and geo-proximity based resolving can be used to provide better performance as cloud services expand. Whether using Route 53 or retaining the existing DNS solution, cutover to the cloudbursting VPC is as simple as updating DNS to point to the ALB.

Cloudbursting in Action

Most of this architecture can be easily configured to illustrate the cloudbursting capabilities of the dual-ASG solution presented. First, a really simple web application, created via userdata in the launch template of the web application ASG. This little bit of shell script is enough to turn a vanilla AWS Linux AMI into something we can talk to:

So, nothing earth-shattering here… just a service that will tell us that we are connected to a web application burst instance. We can get fancy and use the same approach to set up nginx or envoy for the proxy ASG, but demonstrating the capabilities of the dual-purposed target group can be done by simply using the same userdata and using “Hello World From Our Datacenter!”

With our two ASGs configured with their respective launch templates, and the proxy count set to 2, we can create some load on the “proxies” and watch it scale out the web application instances.

Initially, a curl to our endpoint yields what we’d expect:

However, after a few minutes of load we will see our request count per target spike;

This load is well beyond the 10 per target configured for the test here, and the web application ASG responds by bringing up two instances (the current max) to assist with the load.

The curl output indicates we have some new help:

If we now look at our request count per target, it should be roughly half of where it peaked:

Of course, increasing the max number of instances in the web application ASG will bring this down even further.

So, lets see what happens when we stop the heavy load. By default, once the load per target is below the threshold of 10 for 7 minutes in a 15 minute interval, the autoscaler will begin to remove the new instances, and keep removing them until the load is managed by the proxies.

After the configured cooling off period, the autoscaler removes as many instances as needed to get us back to where we started, with all traffic directed to the proxies.

When all of the cloudbursting instances are gone, our curl command shows us that all traffic is once again directed through our proxies:

Conclusion

Investing in cloud capabilities can be overwhelming for any organization. Particularly, ones that have deep roots in traditional IT where core business processes are inside of the firewall. Cloudbursting is a great way to get started today in cloud computing with very little risk and manageable cost. Whether your organization is considering moving to the cloud for the first time or is using this strategy to bolster current capacity, cloudbursting could provide the answer.

What is it? Cloudbursting is an application hosting model which combines existing corporate infrastructure with new, cloud-based infrastructure to create a powerful, highly scalable application hosting environment.

What does it cost? The cost varies based on your requirements, but keep this in mind. You can use https://calculator.aws to create an estimate. Cloud expenses are an Opex expenditure. It is a lease versus a buy. Not having to spend large amounts of capital upfront can have distinct advantages. The other point to keep in mind is that when most AWS services are idle there is no usage cost, unlike the on-prem cost of maintaining a data center.

What’s in it for me? If your organization is looking to test the waters in some form of cloud computing, this approach could be a great way to go. It’s a gateway to understanding cloud computing. Also, if you are searching for a way to handle very heavy load with minimal on-premise resources, utilizing the scalability and elasticity of the cloud is a cost-effective method of temporarily expanding your datacenter.

Best of luck with your journey to the cloud!