5 Steps to Focus Your Cloud Optimization Efforts

Rackspace Best Practices for AWS

Let me know if this sounds familiar:

You’re tasked with optimizing your cloud infrastructure. Cost savings are needed. You focus your attention on your largest monthly expense — a fleet of EC2 instances. You look at metrics and scour logs.

The signs are clear. Instances are underutilized. You give the order and instances are resized, EC2 instances costs instantly drop. Life and budget are good.

And then, the reports start coming in. Slowly at first, a few mentions on social media, a couple of customers call the help desk. They’re having problems connecting to your site.

Then, metrics start breaching thresholds, alarms are triggered. Shopping carts are being abandoned and orders drop! Revenue is slipping!

Your phone rings, it’s your boss.

This scenario is more common than you might think. For many, cloud optimization starts and finishes with right-sizing AWS EC2 instances.

This can yield acceptable optimization results, particularly for small, basic workloads (e.g. your web server fleet). But for many, especially those with more complex and varied workloads, this simple approach falls short and results in underutilized resources and cost inefficiencies.

Right-sizing instances, while an important and necessary step in almost every cloud optimization effort, is only part of the picture. It may get you in the right ballpark, but to get the best seat, there’s more work to be done.

Here are five actionable steps you can take to help focus your cloud optimization goals and ensure your right-sizing efforts stay on the right track.

1. Ask yourself if right-sizing is the correct optimization technique

Could you make more efficient use of time and budget by refactoring or replacing the resource instead?

A fitting example of this is when you’re tasked with right-sizing a self-managed database cluster like MySQL or PostresSQL running on EC2 instances. How much mileage will you get out of right-sizing? Or, would it make more sense to replace the EC2 cluster with the Amazon Relational Database Service equivalent and let AWS manage the details?

Using the Relational Database Service allows you to offload day-to-day administrative tasks such as patching and backups to AWS, and use the time you’d normally spend on these activities working on the functional requirements of your application. You’d still need to right-size the Relational Database Service instance of course, but then you’d no longer have to deal with managing the database itself.

The same benefit can be achieved with other managed services such as Amazon ElastiCache (for in-memory stores like Redis and Memcached) and AWS Directory Service. When you consider the Total Cost of Ownership associated with their self-managed equivalent, optimization by replacement can be an attractive alternative.

Making these types of optimizations can yield significant dividends over the life of your cloud infrastructure.

2. Find out when and how your end-users use your application

When do they (actual users or other software or services) use your system? What patterns do they follow?

Right-sizing in the absence of this usage information will be for naught if it leaves you unprepared for unscheduled changes in demand.

If usage patterns follow a typical diurnal pattern, with gradual ebbs and flows of demand, you can rely on AWS auto-scaling to adjust capacity to meet demand. But, if those daily patterns include sudden, short spikes in demand (like most do), auto-scaling may not be able to compensate quickly enough. Slight over-provisioning to add sufficient capacity to handle short spikes in demand might prove to be optimal.

What if you have a marketing or sales event that you expect will generate a sudden, extreme increase in demand on your application? You can pre-stage resources to ensure sufficient capacity is available for those events, and then tear them down when they’re no longer needed.

Understanding your application’s usage patterns ensures you have capacity when needed. If not, no amount of right-sizing will save you.

3. Understand your application’s architecture

Use the knowledge of your application’s architecture to guide your cloud optimization efforts. The design and architecture of your helps determines what optimization techniques are available to you and how effective your right-sizing efforts will be.

For example, the right-sizing approach you take to optimize a stateful application is much different than the approach you’d use for a stateless application. Decoupled and distributed applications have more options than their monolithic equivalents. (If you don’t know what these terms mean, now would be a wonderful time to learn).

Your application’s architecture ultimately determines how it scales, and how your application scales influences your right-sizing strategy.

Applications that scale vertically (stateful apps like databases, etc.) generally require a more traditional, non-cloudy, approach to right-sizing. Instead of being able to leverage the elasticity and scalability of the AWS cloud to compensate for changes in demand, vertically scalable apps require you to predict and provision for future capacity needs.

Right-sizing vertically scalable applications requires over-provisioning capacity to compensate for short-term demand increases. The amount of additional capacity depends on the expected rate of demand growth and when you’ll be right-sizing again. The more you over-provision, the longer you can wait to right-size again, but you end up with more idle capacity until then.

Right-sizing horizontally scalable applications is usually easier and more flexible than right-sizing vertically scalable applications. Auto-scaling, horizontally scalable applications can easily compensate for right-sizing errors or drifts in baseline. This is what you want.

You may find the best optimization method is to rearchitect your application so it can leverage additional AWS services and features.

4. Use AWS billing options to your advantage

AWS pioneered the on-demand, pay-as-you-go billing model for cloud infrastructure, providing you with unprecedented flexibility and freedom when selecting resources in the AWS cloud.

On-demand billing allows you to make decisions just-in-time, and then only pay for what you use when you use it. This is the most common option, but there are also more economical options to consider if cost optimization is a priority.

Reserved instances differ form on-demand in that they allow you to commit to your resources requirements long-term (one or three years). In return for your commitment, AWS offers steep discounts, in some cases, up to 75 percent off.

But, be careful when considering reserved instances. Depending on the type purchased, these instances are specific to an EC2 instance type and size, AWS region and Availability Zone. Remember that the commitments you make today may limit your future options and flexibility.

Resist the urge to purchase reserved instances on day one, simply to save money. Defer the decision to a later date when traffic and performance metrics can be reviewed carefully to support the decision. Afterwards, review those decisions periodically and adjust as needed.

Bottom line — do your homework before committing to reserved instances. If you don’t, it’s a bit like putting the cart before the horse.

5. Finally, you get to right-size your EC2 instances, right?

Almost! Before you do, you should really get to know your application and how it operates.

How efficiently does it use CPU and memory? What disk IO requirements does it have? How many requests per second can it handle? What are its strengths and weaknesses?

These questions (and the work you do in the steps above) will guide you towards a specific EC2 instance type and size. Knowing this information is critical to ensuring that you can make the most efficient and optimal use of the selected EC2 instance type and available system resources.

Right-sizing can be difficult, but if you have a solid understanding of your application, your customers and your options, you can be sure you’re moving in the right direction.

Still have questions? Visit Rackspace to find out more about the ways our AWS experts are helping customers find the right EC2 instances for their businesses and applications.

Jerry Hargrove is a Senior Solutions Architect on the Fanatical Support for AWS team at Rackspace. He works with Rackspace customers, helping them architect and implement super scalable and highly available solutions in the AWS cloud. Prior to joining Rackspace, Jerry worked as a Solutions Architect at Amazon Web Services and as a software architect and developer. Jerry brings more than 20 years of software architecture and development experience to the Rackspace team and has worked in a broad cross-section of the software industry in a variety of settings. When not at work, he enjoys spending time with his family and is an avid hiker, climber and back-country skier.



Please enter your comment!
Please enter your name here