• Home
  • Blog
  • The 5 Pillars of the AWS Well-Architected Framework: V – Cost Optimisation

TECHNOLOGIES, TRENDS

08.09.2020 - Read in 13 min.

The 5 Pillars of the AWS Well-Architected Framework: V – Cost Optimisation

08.09.2020 - Read in 13 min.

We encourage you to read the last article from “The 5 Pillars of the AWS Well-Architected Framework” series. It has been based on our cooperation with our clients and on AWS best practices. Let's read about Cost Optimisation.

RST Software Blog 5 filarów AWS Well-Architected: V – optymalizacja kosztów (Cost Optimisation)

We’d like to present to you the last part of the “Five Pillars of AWS Well-Architected Framework” series – Cost Optimisation. According to AWS documentation, a list of pillars the architecture of your projects can be based on may look like this:

This list can be used as a sort of foundation for the infrastructure you will build your services upon. Following these guidelines (but treating them as suggestions, of course) will give you a form that’s stable, secure, and efficient both functionally and financially.

 

This chapter is about: Cost Optimisation

Here is the official description of this pillar:

“It includes the ability to to run systems to deliver business value at the lowest price point

In short: you need to make sure that your resources used in AWS Cloud are selected in such a way to avoid unnecessary costs, and yet to meet your demands.

RST Software Blog The 5 Pillars of the AWS Well-Architected Framework: V - Cost Optimisation

Design Principles

Here are the main principles of this pillar:

  • Implement Cloud Financial Management.
    It may seem strange to some, but cloud services are paid, and sometimes these costs can be considerable due to not thinking through the technologies used. Therefore, it is important to be aware of the expenditures, as well as the relation between the technologies selected, efficiency, availability, and price. In an ideal scenario, you should have a tech-savvy person in your finance dept. or somebody to work as a proxy between the builder of the architecture and the finance dept. It is quite common that unaware of any changes in the tech dept., the people in the finance dept. receive invoices with hefty amounts to pay and they may asked surprised: “What are these costs?” and “Why are they so high?”. It is good to know what happens to your money.
  • Adopt a consumption model.
    To minimise expenses, you should use resources when they are actually needed. If the Test (TEST) and Stage (STG) environments are used during working hours of developers and testers, i.e. for ca. 9 hours per day, you should implement automation to close them for the remaining time of the day. However, such options are possible only after you describe your infrastructure with code, e.g. using Terraform. You can execute terraform destroy and terraform apply commands on your resources to control them.
  • Measure overall efficiency.
    As always, appropriate metrics on functionalities used (even business ones) will provide information on whether you are not overusing certain technologies, and if it is possible to cut the costs of use.
  • Stop spending money on undifferentiated heavy lifting.
    Moving your infrastructure to the Cloud usually takes place when your On-Premise servers become inefficient, and you’re facing a decision: should we buy new ones or move to the Cloud. You must carefully think this through. Such move alone generates a considerable cost.  Once you give a green light to moving to the Cloud, you can rest assured that you no longer have to maintain, service, or fix dedicated servers – your provider, like AWS, will do that for you. This is a considerable benefit, as such service sometimes costs the company a lot of time and money.
  • Analyze and attribute expenditure.
    When it comes to expenses, everything becomes transparent. AWS offers a variety of tools to support you in analysing them and provide effective forecasts or information on possible savings. If your architecture is connected in AWS Organization, you will see separate views of expenditures for each account.

RST Blog The Pillars of the AWS Well-Architected Framework Cost Optimisation

Best Practices

AWS defines a series of good practices to be implemented in your environment to ensure the highest possible cost optimisation of your system. They are:

  • Practice Cloud Financial Management
  • Expenditure and usage awareness
  • Cost-effective resources
  • Optimise over time

Just like in the case of other pillars, you need to be reasonable. You should ask yourself a few questions, namely: “How fast do we want to market our product?”, “How much do we want to cut the costs?”, or “How do we plan to control our expenses right after moving to the cloud?”. Techniques presented below should help you in finding that perfect balance between efficiency and price.

 

    • Practice Cloud Financial Management

I remember a situation with one of our clients. A few months after migrating to AWS, we suddenly started receiving questions like: “What is the estimated monthly cost for the next year?”, “How can we cut costs in AWS?”, or “What do we actually pay for?”. Obviously, such questions are understandable, because unlike in the case of one-off server purchases, where nobody receives invoices for their use on a monthly basis, AWS services must be paid for at least once a month. The invoices may be a pleasant surprise to some, while others may object that “It was supposed to be cheap, almost free!”.

Estimated value of monthly expenses should be the first thing to discuss when talking about migration. It is a very bad idea to tell your Client that you want to migrate to the cloud that they will make huge savings, and the Free Tier offer means that they will have (almost) no costs in the first year. In my opinion, pushing the client towards the cloud in order to leave the management of “bad servers” behind is not the best way to go. The eventual expenses may turn out to be higher, and it will cost you your credibility. When discussing future costs your client/business will incur, the key is to be transparent and honest.

The client must be aware that if they reasonably use cloud resources, monitor them to know whether they’re not paying for an unused multicore compute unit, automate deployment processes, invoking and shutting down services, and take advantage of promotional offers like Reserved or Spot Instances, the bills won’t be high. However, even if initial simulations using Total Cost Ownership (TCO) or AWS Pricing Calculator show that the price of resources and optimisation is higher, you have to remember that it also includes “peace of mind”, i.e. AWS maintaining some of the services. Therefore, the price to which you compare the calculation for AWS services should be increased by hidden costs, e.g. for the time of a maintenance officer responsible e.g. for a Leader – Leader DB service, or the cost of replacing a malfunctioning network interface card. You should consider the factors impacting the final costs of your investment in migration.

In the projects I took part in, there was always a person who had no influence on the technologies used in AWS, and yet he or she closely monitored the costs, and especially cost estimates. It’s good to have such a person, or even an entire team, because they offer a different view on the price compared to admins implementing a given solution. Naturally, it’s best to estimate the costs of selected technologies and such a selection itself prior to implementation, as any rollout at a later stage takes time, which costs you money. I appreciated the time when we talked about the technologies used and forecasts for the next month or six months. A must-have tool we used was AWS Cost Explorer, which precisely shows you what you may have to pay for both now and in the future. Interesting ways to optimise the system were coming up during the discussion, or we simply accepted a given solution as reasonably priced and offering appropriate efficiency, which spared us further discussions (and they generate costs, too).

If you decide to migrate, after completing the process you should make sure that any decision regarding deployed solutions is well-informed not only in terms of their functionalities or efficiency, but also cost optimisation. Personally, I always try to stay reasonable in terms of price when approaching technologies used. How would you approach that challenge, given the two price expectations scenarios below and your own common sense?

 RST Software Blog -The 5 Pillars of the AWS Well-Architected Framework: V – Cost Optimisation

As you can see, any Cloud Engineer would love to work on the latter project, where they are free to deploy what they want, test new solutions or technical approaches, etc. The former is a challenge, though. You need to put a lot of effort to achieve the expected efficiency / price ratio.

Nonetheless, in both cases you need to use common sense, as I have repeatedly mentioned before. The first example shows us that there might have been a miscommunication during the initial talks with the Client, and the promises of “cheap cloud solutions” may impact you as a subcontractor. You can go down to the estimated amount of 100 USD per month, but it may turn our that you incur significant costs of the project yourself. The client doesn’t want to pay the costs and pretends they’re not there, which means you have to cover them. For instance, your developers may jump through hoops to optimise JAVA code so that it doesn’t excessively strain your VMs. The machines selected by the architect were small because of the price, and this has a significant impact on their operation as well as on your apps. This means extra working time somebody has to pay for, and if it’s not the client, it means it is you. You should also remember to honestly speak with your client about the price from the beginning, instead of wondering at a later stage how to run a JAVA service on a t2.micro instance later (because this is the only instance you can afford) and prevent Out-of-Memory Killer (OOM Killer) from disabling it after 10 minutes or so.

The latter case ensures freedom of operation, so you may be tempted to use whatever you like from AWS. In my opinion, this is a controversial approach, as it does not teach you how to save or optimise, which can be useful when the client suddenly realises that the expenses could be lower. At that time, cutting costs may be very expensive, as you may have to e.g. implement changes in code of the apps or database solutions used, etc. On the other hand, you may be positively surprised by the fact that, despite forecasted high expenses, you were able to quite effortlessly lower them at the very beginning.

Every person in a project should be aware of the expenses and client’s requirements, so that no time is wasted on redundant downscaling. If you start with reasonably selected small components and want to scale them up as a result of measurements conducted, you will achieve the desired effect of cost-optimal services. I believe it is also a good idea to handle the project over to somebody to verify if there are any areas where you can lower the costs. Maybe not only by limiting the number of EC2 instances or using AWS Fargate. There may also be a way to achieve lower costs by re-building parts of your system.

This perspective and discussion were the outcome of the optimisation of AWS Route 53 and its service called Resolver. In one of the projects, Resolver was used in as many as three environments to ensure that DNS requests to and from On-Premise are effectively solved. To optimise that, a single shared AWS Route 53 Resolver was created, and DNS rules were shared among individual environments via AWS Resource Access Manager. This way, communication in the hybrid environment was preserved, and crucially, the costs of the service were cut by 66%.

RST Software Blog DNS requests

RST Software Blog DNS Reguests

An evolution of AWS Route 53 Resolvers

RST Sofware Blog - AWS - The 5 Pillars of the AWS Well-Architected Framework Cost Optimisation

    • Expenditure and usage awareness

To be able to influence and lower the costs, you need to be aware of what’s happening in the teams invoking cloud services. Collect and analyse data on resources used. Just like in adding new users and giving them permissions based on the least privileges rule, apply that to rules for resources created in the cloud as well. It is a very good approach to start with defining requirements for AWS Regions where your services will be built. From our experiences, the following rules were formed for localisations in Europe:

  • Eu-central-1 (Frankfurt) region as the primary region where we run our services
  • Eu-west-1 (Ireland) as the region where we run resources not available in Frankfurt
  • Us-east-1 (N. Virginia) region as the one where we run test services that are new in AWS and not available for use in other locations. We also use AWS Certificate Manager (ACM) in this region

With these rules, we know what should be run where. Naturally, to achieve that, we must somehow “block” the ability to use resources in the remaining regions. This can be done by using an IAM Policy condition called aws:RequestedRegion, or by using settings in AWS. If you don’t do it, you will have to keep monitoring if somebody ran your services in an undesired region. You can do that using AWS Config or AWS CloudTrail with added optional notifications in AWS Lambda.

        
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "InstanceWriteRegionRestricted",
            "Effect": "Allow",
            "Action": [
               "ec2:Associate*",
                "ec2:Import*",
                "ec2:Modify*",
                "ec2:Monitor*",
                "ec2:Reset*",
                "ec2:Run*",
                "ec2:Start*",
                "ec2:Stop*",
                "ec2:Terminate*"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": [
                        "eu-west-1",
                        "eu-west-2",
                        "eu-west-3"
                    ]
                }
            }
        }
    ]
}
        
    

Example of IAM Policy

 

Next step is about account organisation. Using AWS Organization, you can easily see your expenses per account, without the need to mark your resources with Tags. It is recommended to create a main account, the so-called Management account, that will include definitions of users and groups, as well as access to roles on the target accounts side, like TEST or PROD. Thanks to that, resource usage is more efficient, as even added FINANCE or MARKETING accounts won’t disturb your financial metrics. Each team and each AWS account should have a defined expense limit. Approaching the limit should trigger a warning, or further expenses for this account or user should be blocked.

RST Software Blog - The 5 Pillars of the AWS Well-Architected Framework Cost Optimisation

AWS Organization chart

 

AWS Cost Explorer is a perfect tool for monitoring your resources and their costs. You can use this tool to create the so-called Cost and Usage Report (CUR) comprising data in the CSV format, which can be analysed using third-party tools or in AWS Athena, or even AWS RedShift. The document will comprise collected data or even hourly summaries of resource usage, so that you can easily find what you need.

In some cases, resource are marked with tags for better identification, e.g. when you have multiple projects on a single AWS account. This approach allows you to differentiate e.g. EC2 instances in project Alpha from those in project Delta. Thanks to that, you can clearly see if any of your company projects with a defined budget is approaching the threshold. You can define the rules of adding tags on your own using project tagging guidelines, or you can simply define them in the so-called Tag Policy. To do that, you have to have an account connected in AWS Organization, and then you need to enable adding these rules. Next, you need to create the rules as presented below, where you decide if your project should include the ProjectPhase tag with defined values.

        
{
    "tags": {
        "ProjectPhase": {
            "tag_key": {
                "@@assign": "ProjectPhase"
            },
            "tag_value": {
                "@@assign": [
                    "poc",
                    "beta",
                    "prod*"
                ]
            }
        }
    }
}
        
    

A more advanced way to mark your resources is by using AWS Cost Categories, where you can define categories of costs, so that they depend on the above-mentioned tags, types of account, or service. Here is a screenshot with the configuration of a single rule in Billing Dashboard:

The 5 Pillars of the AWS Well-Architected Framework: V – Cost Optimisation

If you add the ProjectPhase tag with poc value to any resource in AWS (e.g. EC2), you should be able to see its cost in AWS Cost Explorer. Obviously, this tag must be previously enabled in the Cost Allocation Tags.

When using tags, it’s good to follow a certain naming standard and more-or-less know what types of tags are used. You can decide to have:

  • Business tags: these can refer to names of projects, clients, etc.
  • Security tags: these may refer to resources connected e.g. with HIPAA or PCI-DSS
  • Tech tags: these may refer to the name of the service, its version, or the name of the environment
  • Automation tags: these can refer to resources used in the daily process of cleaning up, deletion and termination

Try to avoid using too many tags, so that you won’t get lost in a plethora of data.

 

    • Cost-effective resources

As mentioned before, cost effectiveness is achieved by efficient and conscious use of resources in the cloud. The balance between efficiency and costs is crucial, and it’s very easy to prioritise one side at the expense of the other. Does it make sense to use rather inefficient EC2 instances just to save 10 USD per month, when this also means paying for extra working time, to “use” this poor efficiency with your app? Or maybe it would be better to change the technology and go serverless, by using a relatively cheap AWS Lambda.

AWS offers multiple pricing models, as described below:

  • On-Demand: a standard pricing model in the pay-as-you-go mode. You are charged per one second of usage, and after resource termination no further fees are charged. This applies to resources like EC2 or RDS. Used for short-term projects (up to 4 months), as longer use may be unprofitable compared to e.g. Reserved Instances
  • Spot: a pricing model based on purchasing instances in the form of an auction. You suggest a price you can pay, and if resources with that price are available, you will get them. You can purchase Spot Instances at prices up to 90% lower than On-Demand instances. However, you have to remember that if the price goes up, AWS can terminate a given instance, and you have only 120 seconds to respond
  • Commitment discounts – Saving Plans: a type of discount where you declare a certain usage of instances e.g. during an hour. This applies to EC2, Lambda, or Fargate instances. It’s very flexible and can be easily modified.
  • Commitment discounts – Reserved Instances / Capacity: similar to Saving Plans, but in this case you reserve AWS resources (e.g. RDS or EC2) for a 1-year or 3-year term. You can get up to 72% discount, depending on the reserve term and their convertibility.
  • Geographic selection: you use resources closest to the End Client, which significantly shortens data transfer times, and ultimately lowers the cost

As you can see, there are numerous options, and the most important thing is to select them depending on your actual needs and… not to miss out on any discounts. 🙂 Therefore, it is very important to have a person or a team analysing the prices and capabilities of a Cloud operator.

 

RST Software Product scaling by cloud solutions

 

Summary

As you can see, a lot can be done to ensure your resources are optimised in terms of costs, but to be able to easily navigate through the abundance of different tools, study the table below to find a clear description of services that can be used for that.

RST Software Blog The 5 Pillars of the AWS Well-Architected Framework: V – Cost Optimisation

Article notes

Udostępnij

RST Software Masters

Kamil Herbik

AWS Cloud Engineer

Experienced Cloud Engineer who loves DevOps, new technologies and building new things. When involved in a project, he is not afraid to use cutting-edge technologies and open new paths of its development. Few years ago, he was one of the persons who initiated the DevOps transformation at RST, which has had a significant influence on the style of work at the company. He does not believe in the sentence "it cannot be done", and he always tries to convince himself and the others that everything is possible. In a free time he performs bouldering and spends time with his family.

Thank you!

Your email has been sent.

Our website uses cookies to work correctly. Using this website with current settings means that cookies will be stored in the browser’s memory. Cookies settings can be changed in the browser’s options. For more information please visit Cookies policy.