A Guide to Cost
Optimisation in AWS

How Can We Optimise AWS Costs?

Our high-level process for achieving cost optimisation is shown in Figure 2. The solution below focuses on addressing the cost inefficiency challenges 1 – 4 which account for 70%+ of the cost optimisation opportunities in the cloud.

Identify Over-Supply & Software Inefficiency

The first step is a diagnostic to identify two symptoms of high cost: over-supply and software inefficiency.

Over-supply is when the capacity provisioned exceeds demand over the IT service’s demand cycle. The concept of over-supply may be applied to any AWS component.

For example, in the case of EC2 instances we would employ standard measures of CPU, memory and disk. For serverless components, such as Lambda, we would use time as a measure of resource consumption; this isn’t a precise measure of efficiency but can be a useful proxy.

Once over-supply is identified, we need to qualify that capacity can be reduced safely. When capacity is reduced, the performance of the application should not degrade and there should definitely be no service incidents. In order to make this assessment, we model the expected performance, post down-sizing using our Seven Pillars of Software Performance (below).

This enables us to quantify the performance risk associated with reducing supply capacity and thus prioritise which systems should be addressed.

Software efficiency is defined as the amount of compute resource required to process an application request or transaction, where compute resource includes processor, memory, disk space or I/O (network and disk). How do we decide whether software is efficient or inefficient? The business-function of the software will determine its compute requirements. For example we would expect e-commerce software to have a lower processing footprint (per request) than encryption software.

A big-data analytics platform will have a larger memory footprint (per request) than a document management service, and so on. As enterprise cloud environments typically have tens or hundreds of thousands of servers and components, we use automated software to harvest the following data:

• Cloud configuration
• Supply and utilisation data
• Demand data
• Cost data
  
  

Capacitas uses a library of software efficiency benchmarks, built up over hundreds of customer engagements, and dimensioned by software type, to assess whether the measured compute cost is efficient or not. This is likely to be more difficult for non-specialists whose experience of measuring efficiency Is limited to handful of systems.

In order to get around that your organisation needs to build its own library of efficiency benchmarks; over a number of years it will become clearer what good looks like (Figure 3). Just remember to keep the older benchmarks up to date as technology changes.

Cloud cost monitoring tools such as Cloudability and Cloudyn provide great information on where there is over supply in the estate. However, they cannot identify software inefficiency as a driver of cloud capacity consumption.

As an output from this phase we will have a list of the candidate systems which could be downsized and the potential cost reduction opportunity.

Identify Optimisations and Associated Risk & Cost

The next stage is to quantify how much optimisation we can realistically achieve, given the constraints. What should our $ cost optimisation target be?

The goals of this phase are:

1. Define what right-sizing is required
2. Define architectural optimisations
3. Define what software efficiency improvements are required
4. Define what configuration change is required to increase application elasticity
5. Quantify the performance risk of changes [1-4]
6. Quantify the $ cost optimisation that changes
   [1-4] will achieve

Once we have quantified the performance risk of the changes, we can build a picture of what changes can be realistically delivered, without impacting the operation and reliability of production services (Figure 5).

Cloud cost monitoring tools provide great information on about over supply in the estate. However, the key question remains: Can I safely reduce capacity without impacting the performance of the application? Unfortunately, these tools cannot inform this decision.

Plan Optimisation

In this phase we produce the detailed low-level designs for each type of optimisation:

• Right-sizing
• Architectural optimisations
• Software efficiency improvements
• Changes to increase application elasticity

Prove Optimisation in Test

Where optimisations carry appreciable performance risk, we should first check performance in a test environment before pushing to production.

We use the 7 Pillars of Performance to design and target performance tests in the right area. For example, downsizing EC2 capacity may present a risk to the throughput and response time of an application when under peak load.

Conversely changing the memory footprint of a database service may present a stability risk.

To scale this capability and avoid false-positive test results, it is critical to use automated performance test analysis. This will speed the route to optimisation and minimise the risk of service-impacting incidents when the optimisations go into live.

Implement Optimisation in Live

This is done in close partnership with the DevOps teams responsible for the system. The DevOps engineer will implement the rightsizing typically in conjunction with a capacity and performance expert. The combination of a DevOps engineer who is familiar with the system and a capacity and performance expert who knows what good looks like over a wider range of metrics than the DevOps engineer will typically look at will enable the optimisations to be delivered into live safely.

The important thing to remember, is that these optimisations can be backed out almost immediately in a cloud environment.  Any early warning signs can allow the DevOps and capacity engineers to fine tune the level of optimisation they want to implement in live.

Validate Performance in Live

When the optimisation goes live, it is important to ensure the change has been delivered successfully over the wider demand cycle. Success criteria will include:

• Has the change delivered the expected cost-optimisation?
• Has the change resulted in the expected performance
  behaviour – either modelled or from performance test results?

In is important to note that the last point relates to both the system itself and the upstream and downstream systems it is integrated with.

A key tenet of performance engineering is that capacity changes to a system can have adverse performance impact on coupled systems.

Production Validation is the process of measuring and reporting against these success criteria. Production Validation will take as an input multiple data sources, including:

• Capacity monitoring (AWS CloudWatch, etc)
• Cost monitoring (Cloudability, etc)
• Application Performance Management Tools (New Relic,
  AppDynamics, etc.)
• Application integration design
• NFRs/SLAS

Remove Technical Constraints

What do we do if the change is unsuccessful and adversely impacts performance of the system? Most likely the excess capacity provisioned is masking a fundamental bottleneck in the application code. We term these generically as technical constraints.

In this phase we define the technical constraints through a problem definition statement.  Targeted performance testing may be required to define the problem.

Next we define a risk mitigation plan to fix the constraints and plan what investment is required to redesign the code. As we know what the cost-reduction opportunity is for each change, we can build a business case for implementing the mitigation plan.