Cloud has a simple promise of: “you only pay for what you use” – Right?
Sounds simple enough and while this is fundamentally true it is not always the case and there are some complexities that need to be considered in order to understand the true cost of the cloud equation for your business.
Some customers of AWS complain to me that their cloud experience has not been as cheap as they were expecting and the simple answer is that they had the wrong expectations to start with.
To their credit AWS provide a lot of transparency on their pricing and they have all the facts and calculators available that you need in order to explore the various scenarios and how it impacts the price you pay. However, don’t be lulled into a false sense of security on this, cloud economics can be quite complex and even the calculators are difficult to follow at times. Trust me, I have ploughed through a number of very complex excel spreadsheets to work out the TCO and the “you only pay for what you use” actually comes in a wider range of variables that all need to be considered.
AWS Pricing Philosophy
To illustrate AWS have a number of core pricing constructs that you can follow:
Pay as you go
• No minimum commitments or long-term contracts required
• Capex -> Opex
• Turn off when you don’t need it
Pay less per unit when you use more
• Tiered Pricing and Volume Discounts
Pay even less when you reserve
• Reserved pricing
Pay even less as AWS grows
• Efficiencies, optimisations and economies of scale result in passing the savings back to you in the form of lower pricing
AWS Pricing Fundamentals
To add further complexity the pricing is applied across these fundamental components:
- Clock hours of server time
- Machine configuration (instance type)
- Purchase type (On- Demand, Reserved, Spot)
- Operating systems and software packages
- Additional storage, backups, data transfer
- Data Processing
Elastic IP addresses
- Regional Data Transfer
- Data Transfer out
Traps for young players
Some of the things I have come across may be beneficial to others and they further highlight the complexities that can be involved in optimising the cloud arrangements:
- Unlike VPS or even dedicated servers the AWS instances are not designed to be persistent but they are designed to be pieces of a larger network infrastructure that makes up your application. There are certain strategies that can be applied here such as having regular snapshots, and using an autoscaling group of 1 for instant failover.
- It may not be a good idea in some scenarios to use non EBS optimised instances with provisioned IOPS as this can impact the pricing of your model.
- It may not be advisable to reserve instances for long periods because these are highly specific and they should meet the following criteria in order to attract discounts:
- same instance type
- same region
- same zone
- With bandwidth costs (often the forgotten component) there is not much that can be done to reduce costs, however there are tools and third-party products available that increase the performance which can be very helpful to the equation
- Another idea is to utilise the S3 cloud for your static media as this can have the effect of reducing the load on your server.
- Sometimes it’s a good idea to provision multiple EC2 instances using auto-scaling that enable the environment to scale as demand rises. This has the effect of attracting lower costs outside of peak hours and for your minimum instance count you might consider using the AWS reserved instances as this may reduce your costs further
(seek your own cloud economics advice that considers your own particular circumstances- if your cloud pain persists see your cloud advisor!)
Design for failure and nothing will fail
I close with the Amazon’s EC2 catch phrase: “Design for failure and nothing will fail” and echo the sentiment that even with cloud a considerable amount of planning, strategy and architecture needs to be considered (cloud has changed nothing in some respects).
AWS provide a lot of information and support in this regard and here is an example whitepaper on cloud best practices: