AWS Cost Optimisation forms one of the 6 pillars of the\u00a0AWS Well-Architected Framework<\/strong><\/a>. In turn, that pillar comprises the following 5 focal areas to save or optimise your costs:<\/p>\n\n\n\n According to AWS, Cloud Financial Management (CFM), \u201c\u2026enables organisations to realise business value and financial success as they optimise their cost and usage and scale on AWS\u2026\u201d<\/em><\/p>\n\n\n\n This is broken down further, into the following items:<\/p>\n\n\n\n Create a business function \u2013 either an individual or a team \u2013 that will take responsibility for driving improved cost awareness in the business. This function should focus its efforts in two ways: centralised<\/em> and decentralised<\/em>.<\/p>\n\n\n\n This focuses mainly around economies-of-scale incentives, such as Reserved Instances<\/strong><\/a> and Savings Plans<\/strong><\/a>.<\/p>\n\n\n\n These cost models provide a good degree of flexibility, allowing you to make all-upfront commitments to reserve data-centre capacity (CAPEX cost model) or a pay-monthly commitment (OPEX model), or even a 50\/50 hybrid of the two.<\/p>\n\n\n\n Reservation commitments can be made for either 12 or 36 months, either when reserving instances (such as EC2 or RDS), or taking out compute plans (useful for adopters of Fargate and Lambda, for example).<\/p>\n\n\n\n In cases where you know that you are guaranteed to require a certain number of always-on EC2s, pretty much forever, you can leverage the highest cost-saving by choosing an all-upfront 3-year reservation. Typically, you can save in the region of ~62% by doing this. If you cannot commit to that much capital expenditure, you can go halves and pay the rest in monthly instalments across the 3 years. This brings the saving down to ~61%. No capex budget? Then go with the no-upfront, pay-monthly deal, and save ~60%. Dropping down to the 1-year deal with see these discounts drop to around the ~40% mark.<\/p>\n\n\n\n By contrast, if you\u2019re planning migrations from EC2 to Fargate or Lambda, then you might choose to take out one of the more flexible Savings Plans \u2013 such as the Compute Savings Plan \u2013 which will provide cover across all three technologies whilst you migrate. Despite this, you still make a single up-front reservation of capacity, and are still able to pay all-upfront, monthly or both. Discounts vary in the range of ~30-40% in the 12-month bracket, and move up to ~50% in the 3-year deals.<\/p>\n\n\n\n This is where your new AWS Cost Optimisation function will come into its own, as it begins to drive an improved cultural and behavioural attitude towards cost awareness and avoidance. Constant trade-offs between short-term cost avoidance vs long-term investment in improved business efficiencies (often driven by technology choices) will be of particular focus here.<\/p>\n\n\n\n Ensure that finance and technical teams invest a good proportion of their time to understand each other\u2019s requirements. This is often overlooked, and usually with frictional results.<\/p>\n\n\n\n As your technology teams migrate further away from on-premise and traditional data-centre or fixed infrastructure, so too must your finance team move away from fixed-cost forecasts and budgets (CAPEX) to a more flexible, variable-cost model (OPEX).<\/p>\n\n\n\n Use AWS services such as AWS Budgets & Alarms<\/strong><\/a>, AWS Cost Explorer<\/strong><\/a> and AWS Cost & Usage Reports<\/strong><\/a> to help finance teams become more agile in their own processes and culture. Having better real-time awareness of variable costs and related data will help them to align their management practices with your technology teams\u2019 deliveries and requirements.<\/p>\n\n\n\n As you make better use of cloud technologies, your costs are likely to become more<\/em> variable. This is a good thing, as it means you are likely to enjoy vastly reduced costs during quiet periods. But you need to protect yourself against sudden spikes in variables costs when demand is high.<\/p>\n\n\n\n One of the ways to do this is to set up AWS Budgets<\/strong> and Forecasts<\/strong><\/a>.<\/p>\n\n\n\n You can easily set fixed usage or monetary budgets for a given period, and have AWS send you alerts when your forecast usage is expected to exceed them. These are highly customisable, easy to configure and also offer a sliding-scale model (which is useful for product launches or re-platforming projects).<\/p>\n\n\n\n Also consider using AWS Cost Explorer<\/strong>, which can forecast daily (up to 3 months) or monthly (up to 12 months) cloud costs, based on machine-learning algorithms applied to your historical costs (trend based forecasting).<\/p>\n\n\n\n Encourage everyone in your business to think about the cost (investment) and any return on that cost (Return On Investment), before undertaking new projects in particular.<\/p>\n\n\n\n For example, Business Analysts should seek to understand how cost factors have driven existing processes and purchasing decisions, Product Owners should seek to understand how product improvements can reduce demand on digital services and Technical Leaders should support both roles by suggesting innovative use of technology to deliver short term objectives with longer-lasting cost benefits.<\/p>\n\n\n\n Engineers, meanwhile, should enjoy a high level of autonomy in their role, so they can iterate and deliver at high speed. But they should also be constantly educated about the cost implications of their own activities. Developer sandbox accounts should have their own budgets and alarms for example, including escalations to line managers and budget controllers.<\/p>\n\n\n\n You can use AWS Organizations<\/a> and AWS SSO<\/a> to provision sandbox accounts to individuals; leverage the organisation-wide billing capabilities of AWS Cost Explorer<\/strong> and AWS Cost & Usage Report<\/strong> to understand and monitor these costs.<\/p>\n\n\n\n Whether you are migrating services from one compute or database model to another, applying Savings Plans or Reserved Instances, terminating old EC2 instances, or decommissioning other resources, it\u2019s important to keep a good track record of before-and-after costs.<\/p>\n\n\n\n This can be achieved using AWS Cost & Usage Reports<\/strong> before and after a given cost-reduction exercise. Cost savings can be monitored mid-flight using the sliding-scale model in AWS Budgets<\/strong>.<\/p>\n\n\n\n This is all very useful, but immediate cost savings are not the sole benefit of Cost Optimisation. Longer-term investment in future efficiencies is.<\/p>\n\n\n\n AWS offer the following examples:<\/p>\n\n\n\n For example, resource lifecycle management reduces infrastructure and operational costs and creates time and unexpected budget for experimentation. This increases organisational agility and uncovers new opportunities for revenue generation.<\/em><\/p>\n\n\n\n For example, Auto Scaling, which ensures elasticity at minimal effort, and increases staff productivity by eliminating manual capacity planning work.<\/em><\/p>\n\n\n\n Forecasting enables finance stakeholders to set expectations with other internal and external organisation stakeholders, and helps improve your organisation\u2019s financial predictability.<\/em><\/p>\n\n\n\n Every product team or revenue-generating area of your business should have its own cost-monitoring, budgeting and forecasting capability, as well as the business as a whole having a centralised one.<\/p>\n\n\n\n This decentralised model ensures that those closest to the coal face can remain agile in their delivery, whilst also having ownership, accountability and control of their own costs (and savings).<\/p>\n\n\n\n The three following items should be considered:<\/p>\n\n\n\n By leveraging AWS services, such as IAM<\/strong><\/a>, AWS Organisations & Service Control Policies<\/strong> and AWS Config<\/strong><\/a>, your business can gradually introduce measures to ensure that use or modification of certain services or resources is restricted.<\/p>\n\n\n\n Basic examples might include applying a region restriction to your AWS Organisation, or disallowing the use of expensive, overpowered EC2s instance families.<\/p>\n\n\n\n With time, you can refine these restrictions to target specific AWS accounts or environments, IAM roles or user groups. Your developers might have ample freedom to explore different services in their sandbox accounts, but only on free-tier. A staging environment might allow larger instances but avoid multi-regional deployments, for example. In production, we constantly re-evaluate restrictions to best balance demand and performance.<\/p>\n\n\n\n Once again, lean on AWS Budgets<\/strong> to provide real-time notifications of off-policy activities that perhaps have not been explicitly enforced.<\/p>\n\n\n\n AWS has a one-parent-to-many-children account structure that is commonly known as a management account (the parent) account-member (the child) account.<\/p>\n\n\n\n A best practice is to always have at least one management account with one member account, regardless of your organisation’s size or usage. All workload resources should reside only within member accounts.<\/p>\n\n\n\n Use consolidated billing<\/strong> within AWS Organisations<\/strong> to aggregate all costs into the parent account. This is useful for finance teams and bill-payers, for obvious reasons. However, each child account can still contain its own budgets and alerts, which is useful for implementing the distributed model of AWS Cost Optimisation accountability and autonomy in your wider teams.<\/p>\n\n\n\n Aggregating costs and usage in the management account lets you maximise service volume discounts and the use of your commitment discounts (Savings Plans and Reserved Instances) for the highest savings.<\/p>\n\n\n\n AWS Control Tower quickly sets up and configures multiple AWS accounts, aligning governance with your organisation’s requirements.<\/p>\n\n\n\n Ensure that you track the entire lifecycle of a workload. This ensures you can decommission or modify workloads or workload components when they’re no longer needed.<\/p>\n\n\n\n You can use AWS Config<\/strong> or AWS Systems Manager<\/strong><\/a> to quickly collate inventories of existing resources and configurations, regardless of how many accounts you operate. You can then begin to terminate resources that are no longer required.<\/p>\n\n\n\n Your teams must be able to track and understand their own costs before they can be expected to control them.<\/p>\n\n\n\n There are several things you should consider here.<\/p>\n\n\n\n \u201cEnable hourly granularity in Cost Explorer and create a <\/em>Cost and Usage Report (CUR)<\/em><\/strong>. These data sources provide the most accurate view of cost and usage across your entire organisation. The CUR provides daily or hourly usage granularity, rates, costs, and usage attributes for all chargeable AWS services. All possible dimensions are in the CUR including: tagging, location, resource attributes, and account IDs.\u201d<\/em><\/p>\n\n\n\n Consider using AWS QuickSight<\/strong><\/a> to visualise and explore your CUR. Other services, such as Amazon Athena<\/strong><\/a> can be used to perform custom data analysis, should your organisational scale require it.<\/p>\n\n\n\n Your efforts to categorise costs can be greatly supported using AWS Tag Editor<\/strong><\/a>, for example, which can be used to manage resource tagging at scale. For example, you might want to tag all currently running EC2s in your development account, or certain DB instances for some other cost-tracking purpose. This can easily be done here.<\/p>\n\n\n\n Use AWS Tag Policies<\/strong><\/a> in your Organisation, in order to prevent misused of tagging across your accounts.<\/p>\n\n\n\n Using services such as AWS CloudWatch Metrics<\/strong><\/a>, begin to align workload success (or failure) metrics with associated cost metrics or budgets in AWS Cost Explorer<\/strong> or AWS Budgets<\/strong>. Use these tools to understand how investments in new technology may have improved or worsened your workload\u2019s output. This in information can be used to help determine overall business value and ROI.<\/p>\n\n\n\n \u201c<\/em>AWS Cost Categories<\/em><\/strong> allows you to assign organisation meaning to your costs, without requiring tags on resources. You can map your cost and usage information to unique internal organisation structures. You define category rules to map and categorise costs using billing dimensions, such as accounts and tags. This provides another level of management capability in addition to tagging. You can also map specific accounts and tags to multiple projects.\u201d<\/em><\/p>\n\n\n\n The basic steps to decommissioning resources are as follows:<\/p>\n\n\n\n Tag, tag and tag some more, especially in pre-production environments where resources are often short-lived but regularly left running. If you deploy resources automatically, in a CICD pipeline, make the CICD pipeline responsible for tearing them down again. But tag everything. Any resources that remain can then be tracked using the AWS Cost Explorer<\/strong>.<\/p>\n\n\n\n For longer-lived resources, consider tagging them with future dates for decommissioning, if these dates are known. Have a process for filtering those tags and reviewing their accuracy.<\/p>\n\n\n\n \u201cImplement a standardised process across your organisation to identify and remove unused resources. The process should define the frequency searches are performed, and the processes to remove the resource to ensure that all organisation requirements are met.\u201d<\/em><\/p>\n\n\n\n \u201cThe frequency and effort to search for unused resources should reflect the potential savings, so an account with a small cost should be analysed less frequently than an account with larger costs. Searches and decommission events can be triggered by state changes in the workload, such as a product going end of life or being replaced. Searches and decommission events may also be triggered by external events, such as changes in market conditions or product termination.\u201d<\/em><\/p>\n\n\n\n \u201cUse automation to reduce or remove the associated costs of the decommissioning process. Designing your workload to perform automated decommissioning will reduce the overall workload costs during its lifetime. You can use AWS Auto Scaling to perform the decommissioning process. You can also implement custom code using the API or SDK to decommission workload resources automatically.\u201d<\/em><\/p>\n\n\n\n The Cloud is billed on-demand by default. This can be a blessing and a curse, as we have discussed in other sections. Cloud resources are also scalable \u2013 some vertically and others horizontally. You should work to understand how these two scaling models compare.<\/p>\n\n\n\n For example, a static EC2 instance with a large amount of computational headroom will meet a temporary spike in demand, but it is a sledge-hammer to crack a walnut in cost terms. And if you require redundancy, then your already-high wastage will double or triple. You could introduce the AWS Auto-Scaling feature of EC2 in order to scale up when demand is high, but scale back down when demand is low.<\/p>\n\n\n\n But you also need to consider the speed at which auto-scaling works. Migrating your workloads to AWS ECS+Fargate or Lambda Functions will increase their scaling speed, whilst also reducing the size of each node; so you save twice.<\/p>\n\n\n\n Consider this slicker horizontal scaling model to be \u2018just-in-time\u2019 provisioning of resources.<\/p>\n\n\n\nIn this article you’ll read: <\/h3>
1. Practice Cloud Financial Management<\/h3>\n\n\n\n
Functional Ownership<\/h4>\n\n\n\n
Centralised Approach<\/em><\/strong><\/h5>\n\n\n\n
Decentralised Approach<\/em><\/strong><\/h5>\n\n\n\n
Finance and Technology Partnership<\/h4>\n\n\n\n
Cloud Budgets and Forecasts<\/h4>\n\n\n\n
Cost-Aware Processes<\/h4>\n\n\n\n
Quantify Business Value Delivered Through Cost Optimisation<\/h4>\n\n\n\n
Executing AWS cost optimisation best practices<\/em><\/strong><\/h5>\n\n\n\n
Implementing automation<\/em><\/strong><\/h5>\n\n\n\n
Forecasting future AWS costs<\/em><\/strong><\/h5>\n\n\n\n
2. Expenditure and Usage Awareness<\/h3>\n\n\n\n
Governance<\/h4>\n\n\n\n
Refine Policies<\/em><\/strong><\/h5>\n\n\n\n
Use Multiple Accounts<\/em><\/strong><\/h5>\n\n\n\n
Track & Decommission Resources<\/em><\/strong><\/h5>\n\n\n\n
Monitor Cost and Usage<\/h4>\n\n\n\n
Configure Detailed Data Sources<\/em><\/strong><\/h5>\n\n\n\n
Identify Cost Attribution Categories<\/em><\/strong><\/h5>\n\n\n\n
Establish Workload Metrics<\/em><\/strong><\/h5>\n\n\n\n
Use Cost Categories<\/em><\/strong><\/h5>\n\n\n\n
Decommission Resources<\/h4>\n\n\n\n
Track Resources Over Their Lifetime<\/em><\/strong><\/h5>\n\n\n\n
Implement a Decommissioning Process<\/em><\/strong><\/h5>\n\n\n\n
Decommission Resources<\/em><\/strong><\/h5>\n\n\n\n
Decommission Resources Automatically<\/em><\/strong><\/h5>\n\n\n\n
3. Manage Demand and Supply Resources<\/h3>\n\n\n\n
![\"\"](\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/12\/Cloud-Trend-Report-2025-003-Mockup-copy-1.png\")
<\/figure>\n<\/div>\n\n\n\n![\"\"](\"https:\/\/devoteam.info\/wp-content\/themes\/lsac-devoteam\/patterns\/images\/controle-des-badges.svg\")
<\/figure>\n\n\n\n