Cost Optimizing Your Architecture: Practical Design Steps For Developer Savings : Level 300
Simon Elisha, Head of Solution Architecture, ANZ Public Sector, Amazon Web Services
** Note: These are notes taken from various sessions and the keynote of the 2017 AWS Public Sector Summit held in Canberra, Australia. The information might be slightly unstructured, and the photos might be a bit raw.
Note: The level 300 sessions were being squashed into short sessions, as a consequence the presenters were really under some pressure to zoom through the content. As a result, I found it difficult to make notes and listen at the same time in an effective manner.
What we have, as a result, is a lot of photos and some “metadata”, but I’ve done my best to try to add useful context. Enjoy.
Cost Optimising Architecture
Spread of services over time
Transactional cost vs operational cost
Cost per user
Realtime cost consumption?
Cost explorer helps ‘back of the envelope’
Instrument system (track spend)
Infrequent access changes pricing profile.
Revisit Compute use every six months (pricing structure changes frequently).
Changing instance size is trivial (stop instance, change, start).
Set upper price limit; you’ll pay market price under the cost cap. Spin up normal scale to balance.
Use price history to predict cost estimates. Compare spot market v on demand.
RLS – This works well assuming you have architected for distributed workload design.
Code changes > architecture trade offs > immediate benefits
Changes are easy to make.
Using server less (lambda)
Use spot resource to further optimize
Use different data store types
Not everything is relational
Look for storage ‘heat spots’
Architecture continually evolves
Availability – Economy
Don’t use DB to store binary data
Cross reference against binary blob storage (image URL in S3)