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
Economy vs traditional architecture goals
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)
Everything has a cost
Example : DB update
Automate! Redirect skilled resources to higher value tasks
Infrastructure
Infrequent access changes pricing profile.
Revisit Compute use every six months (pricing structure changes frequently).
Changing instance size is trivial (stop instance, change, start).
Based on CPU consumption
Trusted Advisor advises on cost savings
Spot instances – covered previously – bid for spare capacity in shared hosts. Combined into auto-scale
Script use of spot resources
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.
Auto tune to cost minimize. Turn off resources when not in use.
Caching is not well understood. White paper covers this well.
Use elasticache (in memory).
Architecture
Code changes > architecture trade offs > immediate benefits
Changes are easy to make.
Static hosting + use APIs
* no need to worry about session, state, scale (cheap!)
* No patching
* No security scanning (server side)
* Easy content rollout
Queues
Queues are key to solve reliability, cost, performance
Example using queues
Elasticity to meet SLA conditions
Key: determine transaction cost
Simplify!
Using server less (lambda)
Use spot resource to further optimize
Keep using cheap queue; combine with Lambda to keep TX cost low
Statefulness
Use different data store types
Not everything is relational
Look for storage ‘heat spots’
Architecture continually evolves
Basic example
Heavy storage layer
Design revision
Design contained
Compute aligned to load/demand
Small footprint
Serverless
Deployment model different
Easy code changes
Availability – Economy
Don’t use DB to store binary data
Cross reference against binary blob storage (image URL in S3)
Pretty obvious when you think about it
Even making changes to Dev/Test can have huge financial benefit.
