Harnessing AWS best practices with the Well Architected Framework – Cost Optimisation Pillar

At Versent, the AWS Well-Architected Framework is used to help our customers build the most secure, high-performing, resilient, and cost efficient infrastructure possible for all types of applications.

The framework provides a consistent approach to evaluate application architectures and provide guidance to implement designs that will scale as the ecosystem of services in AWS scale. The framework is built on 5 pillars;

• The Operational Excellence Pillar focuses on the ability to run and manage applications to ensure they’re delivering constant business value.

• The Security Pillar is a very important pillar to all our customers and its focus is on the ability to protect data and applications while continuing to deliver business outcomes.

• The Reliability Pillar focuses on how your application has been architected to recover from failure and mitigate these failures to recover itself.

• The Performance Efficiency Pillar is how your application meets the needs of your customers by efficiently scaling when demand changes.

• The Cost Optimisation Pillar will be how you effectively manage and eliminate any unneeded costs in running your application.

I’ll focus in on the Cost Optimisation Pillar in this post, and use a reference architecture to illustrate some of the best practices when architecting in AWS. As the AWS Cost Optimisation Pillar states, it is a continual process of refinement and improvement over the span of a workload’s lifecycle.  

For context, the reference architecture is based on an internet facing web application and I’ll show this in two views, an unoptimised view and an optimised view aligned to the Cost Optimisation Pillar of the Well Architected Framework.

Firstly, we’ll look at the unoptimized view of the architecture:

The points which are deemed unoptimized are highlighted in red above and I’ll explain why:

1. The Load Balancer is running on a long running EC2 instance that requires the underlying operating system to be managed. It requires a third party license that is paid on an ongoing basis. It’s not natively scaled across multiple availability zones.
2. The Application servers are long running, manual deployments and are not auto scaled and will need the Operations team to continue to manage them on an ongoing basis.
3. The Oracle database servers are running on EC2 instances and the Engineering team is required to install, configure and fundamentally operate the primary and standby Oracle nodes to ensure reliability of the architecture.

Now, we’ll look at what an optimized view of this architecture:

The points which are deemed optimized are highlighted in green above and here’s why:

1.  The load balancer has been transformed to utilize the Application Load Balancer (ALB), the managed service load balancer offering that is natively scaled across all availability zones present within a given region. This improves the architecture by removing the cost of the third party load balancer license, and reduces the operational overhead to manage the underlying operating system.

2. The database layer has been through a transformation from Oracle to PostgreSQL hosted on the database-as-a-service offering, Relational Database Service (RDS). This provides two optimisation benefits – the move to open source database engine removes the ongoing license costs, and the move to RDS removes the operational overhead of managing the underlying infrastructure that the database is hosted on. If you want to see a customer example of this in the real world, see how LSSA modernised its tech stack.

3. Introducing a dedicated team for Cloud Financial Operations (Cloud FinOps) is important to ensure that there is laser focus on what is being used and whether it is being used in the most optimal way. The team would use AWS Cost Explorer to put together the forecasted spend and AWS Budget to set budget targets and notification if any breaches of this budget occur. Providing this oversight and governance allows the acceleration of realizing the business value that is being achieved from hosting in AWS.

4. We introduce a tag for Business Division/Cost Centre to allow for the cost to be associated to a business. It’s important to understand what aspects of the architecture are attributing to the cost and the best way to do this is to introduce fine grained tagging.

5. Our partner, AWS cloud management platform Stax has a module dedicated to Cost & Compliance and specifically on highlighting any wastage that may exist within the workload. Having this made available to the Cloud FinOps team is a powerful tool to continue the optimization journey as it provides prescribed refinement of aspects of the architecture which could be further optimized.

These are just some of the cost optimizations that could come out of a Well Architected Review. Versent are an AWS Well Architected Partner, and can assist by performing a Well Architected Review your workloads running on-premises or in AWS.

A Well Architected Review is run by our Well Architected Practitioners, and can focus on one specific pillar, or all pillars of the framework. The review is conducted over a series of workshops where we use the AWS Well Architected Tool to assess your architecture against the framework.

If you’d like one of our Well-Architected Practitioners to assist in optimising your architecture associated to cost, please complete the below form and we’ll get back to you shortly.