We're continuing our talks on Well Architected with the fifth pillar which is AWS cost optimization. There are 10 questions and 5 subsections:
Practice Cloud Financial Management,
Expenditure Awareness,
Cost Effective Resources,
Matching Supply and Demand, and
Optimising Over Time.
Practice Cloud Financial Management is a maturity step for teams to be able to know how much their stack costs. There has been a big shift in architecture, since we've got more visibility into cost in the last number of years. When you were working on the enterprise mainframes, you were dealing with capacity. And maybe you did get into licencing and availability of licencing but you never talked in terms of cost.
Setting expectations around CapEx versus OpEx is critically important, especially with business partners, who maybe aren't aware of this and will wonder why my bill went from £50 to £3,000 this week? And the explanation might be running a load test for a new feature. So you need to be very upfront and very good about setting expectations that costs will fluctuate up and down give reasons why. It relates back to 'clarity of purpose,' understanding what you're doing, and being able to articulate that, in a business way to link up business and IT together.
Expenditure awareness: To grow that awareness, education is critical. You need to make teams aware that these things are available to you. So how do you govern usage? How do you monitor usage and costs? And how do you decommission/how do you switch things off? If you're in a leadership position, you should be able to see a breakdown. If you have five applications in your portfolio you should be able to know the cost breakdown from those five, at the very least. That's not that hard to do.
Cost Effective Resources: Developers, always want to pick the fastest, craziest and wildest thing. But is it more cost effective? Sometimes you don't need the fastest thing and a moderate speed will do the job. This point to sustainability as well. It's not how fast can you get it? It's how fast do you need to provide adequate service? The total cost of ownership comes to the fore here. It's not what is for right now. It's the long term operational burden and cost. You can choose a technology that's super low cost, but the cognitive burden is massive because it's a new technology that's outside your team right now. Then, what's the learning cost for that team to learn the tech stack or language that you chose for cost efficiency reasons? You have got to take a bigger view. It's not just for what you're doing right now. How do you plan for data transfer charges. That's definitely one to look at if you have a large data footprint.
Matching Supply and Demand and Optimising Over Time. I've lumped these together. There's a piece around keeping up with the latest and greatest in AWS and tweaking your design so that your continuing efficiently. There's also a bit about selecting new services as you build new stuff and selecting wisely for a decent cost impact. This is where we see the serverless advantage kicking in. Matching Supply and Demand is taken care for you as it scales with the load. If you're on traditional architectures or EC2, you might need to pre provision some other stuff and have it at hand and ready to go. That's a hard calculation to get
Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube
Serverless Craic Ep12 AWS Well Architected Cost Optimization Pillar