In the previous posts in this series I’ve discussed the AWS platform and took a closer look at storage, snapshots and provisioning, looked at networking and cloning and then reviewed administration, delegation and licensing. In this post I will analyse cost, which is probably the most important factor when considering a move to the cloud.
Other posts in this series
- SharePoint 2010 Infrastructure for Amazon EC2 Part I: Storage and Provisioning
- SharePoint 2010 Infrastructure for Amazon EC2 Part II: Cloning and Networking
- SharePoint 2010 Infrastructure for Amazon EC2 Part III: Administration, Delegation and Licensing
- SharePoint 2010 Infrastructure for Amazon EC2 Part IV: Cost Analysis
- Amazon VPC and VM Import Updates
When would AWS be compelling, despite the complexity?
I’ve covered most of the design topics that I feel are relevant to SharePoint 2010 on EC2 now, so it’s time to talk about why we would use it, despite the obvious complexity that it introduces. The potential benefits included:
- Scalability. This is pretty hard to question. AWS definitely scales.
- Cash flow: The On-Demand services are Pay-As-You-Go, so this clearly helps when cash is tight.
- Infrastructure costs/support: This needs to be validated. See the AWS Premium Support Pricing page for more information about the cost of platform support.
- Performance: I will be diving much deeper in to performance over the next week or two and will be analysing EC2 alongside laptops and desktops. For now I will say that it performs well, but it isn’t the best-performing solution that we reviewed. Subjectively I would say that I don’t think most developers would consider a large instance to be slow.
- Availability anywhere (with an outbound RDP connection): Obviously the down side here is that this connection isn’t always available or reliable everywhere, for instance on a train.
- Special scenarios: Some examples I can think of here would include testing for large farms and office moves. I shan’t delve in to the scenarios, but there are sure to be others.
- Cost: This needs to be validated, and I will share an example analysis below.
Actual invoice data
This screen shot of an Amazon invoice (tidied up in Excel a bit) is the real invoice I received for my testing time. I’ve included it here because I think it illustrates the impact of instance usage time on total costs really well. It’s by far the largest cost at ~90% of the bill for this testing time, and that included a couple of weeks when I wasn’t using the instances. During that “down time” I was still billed for storage use and Elastic IP address disuse. Keep that in mind, as you will continue to accrue charges even if you shut down your machines.
Example of costs over three years
I projected charges based on these figures over three years for a large number of users. There were two main objectives for these calculations:
- Gain an understanding of the impact of on-demand usage compared to reserved instance costs.
- Assess these costs relative to hardware costs over an average lifetime of three years.
This analysis was only intended to indicate ballpark costs and some of the figures are nothing more than educated guesses, but I think they should serve their purpose as indications. This analysis didn’t factor in costs for Amazon’s Cloud Watch (monitoring and reporting), Amazon Support, licenses (other than Windows) and probably some other factors I overlooked, but I’m publishing it here as it might be useful for other high-level assessments. But obviously everyone should work this out for their own usage patterns and obviously, all price information is subject to change.
Summary
For seventy users, costs could break down as follows:
- 8 hours/day on-demand = $1950/instance over three years.
- 24 hours/day on-demand = $5295/instance over three years.
- Mixture of 50 reserved instances running 24 hours/day and 20 On-Demand Instances running 8 hours day = $3779/instance over three years.
- 24 hours/day reserved instances = $4511/instance over three years.
The difference in cost between on-demand usage 8 hours/day vs. 24 hours/day is enormous. Even the difference between 70 on-demand instances at an average of 8 hours/day compared to 70 reserved instances is huge: reserved instances are more than twice the cost. A mixture of reserved instances and on-demand usage probably won’t help enough to make it compelling. The only way that EC2 appears to be cost effective for large instances, used routinely, is to manage usage effectively. The detail for these calculations is provided below, with monthly costs. Those totals have been multiplied by 36 months and divided by 70 users for the cost summaries above.
An important note regarding Reserved Instances and cash flow
Reserved instances have an up-front cost of $910 per-instance per-year (or $1400 per-instance per-three-year-commitment) before usage charges are included (at a lower, reserved rate of $.24 per-instance per-hour). This means that reserved instances are a lot less viable for organisations looking to EC2 for cash flow benefits. The figures above were calculated using the $910 up-front cost, as I don’t believe most people will commit to three years of usage from the start. The reserved instance prices would clearly come down quite a bit with that three-year commitment, so feel free to recalculate as you like, but keep in mind that higher up-front cost is even worse for cash flow.
Cost assumptions
- 70 instances x 8 hours = 560 instance hours
- 560 instance hours x 230 days = 128,800 instance hours/year
- $0.48 per-hour per-instance
- Unattached Elastic IP Charges = $.01/hour unattached = 16 hours unattached/day/instance
- Elastic IP Address remap charges = first 100/month free, then $.10/remap
- EBS Storage = $.11/GB/Month x 50GB average storage
- Data Transfer In at $.10 per GB
- Data Transfer Out at $.15 per GB (first GB/month free)
- Reserved instance up-front costs of $910 for one year rather than the $1400 3 year commitment
- Bandwidth charges have not been calculated for VPC connections
Calculation Detail
On-Demand Costs at 8 hours/day average instance usage
- Instance cost = $61,824
- 16 hours unused Elastic IP charges/day = $.16 x 70 users x 230 days = $2576
- 1 remap/day x 70 users x 230 days = 16,100 remaps -1200 free = 14,900 x $.10 = $1490
- EBS costs:
- Storage: $5.50/instance/month (assuming 50GB storage) = $840
- IO: $5.50/instance/month (assuming roughly equivalent IO costs – perhaps 30-40 IOps) = $840
- Snapshot Gets: costs should be negligible ~$100/year
- Snapshot Puts: costs should be negligible ~$100/year
- Data transfer:
- In: 20GB = $2.00/instance/month = $1680
- Out: 20GB = $3.00/instance/month = $2520
Total = $71,970/year = $5997.50/month = £3793/month*
*This total does not include any support costs and is based on un-validated assumptions.
On-Demand Costs at 24 hours/day average instance usage
- Instance cost = $185,472
- 16 hours unused Elastic IP charges/day = $.16 x 70 users x 230 days = $2576
- 1 remap/day x 70 users x 230 days = 16,100 remaps -1200 free = 14,900 x $.10 = $1490
- EBS costs:
- Storage: $5.50/instance/month (assuming 50GB storage) = $840
- IO: $5.50/instance/month (assuming roughly equivalent IO costs – perhaps 30-40 IOps) = $840
- Snapshot Gets: costs should be negligible ~$100/year
- Snapshot Puts: costs should be negligible ~$100/year
- Data transfer:
- In: 20GB = $2.00/instance/month = $1680
- Out: 20GB = $3.00/instance/month = $2520
Total = $195,618/year = $16,301.50/month = £10,295/month*
*This total does not include any support costs and is based on un-validated assumptions.
Reserved Instances – Costs at 24 hours/day instance usage
- Instance cost ($910 x 70) = $63,700 + (70 x 24 hours = $92736 full-time usage) = $156,436
- 16 hours unused Elastic IP charges/day = $.16 x 70 users x 230 days = $2576
- 1 remap/day x 70 users x 230 days = 16,100 remaps -1200 free = 14,900 x $.10 = $1490
- EBS costs:
- Storage: $5.50/instance/month (assuming 50GB storage) = $840
- IO: $5.50/instance/month (assuming roughly equivalent IO costs – perhaps 30-40 IOps) = $840
- Snapshot Gets: costs should be negligible ~$100/year
- Snapshot Puts: costs should be negligible ~$100/year
- Data transfer:
- In: 20GB = $2.00/instance/month = $1680
- Out: 20GB = $3.00/instance/month = $2520
Total = $165,582/year = $13,882/month = £8771/month*
*This total does not include any support costs and is based on un-validated assumptions.
Mixture of On-demand and Reserved Instances – Costs at 24 hours/day instance usage
Mixture of 50 Reserved Instances and 20 On-Demand Instances.
- Reserved Instance cost ($910 x 50) = $45,500 + (50 x 24 hours = $66,240 full-time usage) = $111,740
- On-Demand Instance cost at 8 hours/day average instance usage = 20 instances x 8 hours x $.48 x 230 days = $17,664
- 16 hours unused Elastic IP charges/day = $.16 x 70 users x 230 days = $2576
- 1 remap/day x 70 users x 230 days = 16,100 remaps -1200 free = 14,900 x $.10 = $1490
- EBS costs:
- Storage: $5.50/instance/month (assuming 50GB storage) = $840
- IO: $5.50/instance/month (assuming roughly equivalent IO costs – perhaps 30-40 IOps) = $840
- Snapshot Gets: costs should be negligible ~$100/year
- Snapshot Puts: costs should be negligible ~$100/year
- Data transfer:
- In: 20GB = $2.00/instance/month = $1680
- Out: 20GB = $3.00/instance/month = $2520
Total = $139,550/year = $11,629.17/month = £7348/month*
*This total does not include any support costs and is based on un-validated assumptions.
Findings
Amazon Web Services can be quite expensive if usage is not controlled effectively. Based on these calculation, I don’t feel that $1950/instance over three years is bad value. These environments perform well and provisioning is very quick. There are no underlying virtualisation support costs or power costs. The scalability is inherently appealing and the Pay-As-You-Go model might be compelling for some businesses or independent users, despite all other considerations. In our case, we dove deeper in to the productivity question, attempting to get a handle on how the performance of server-class hardware in the cloud stacks up relative to laptops and desktop workstations. We wanted to understand if the complexity, potential remote worker issues and cost might be justified based on productivity gains. Some of these findings were surprising, as I will reveal in my next series of posts on SharePoint development environment performance.
Fantastic series of posts Tristan! I’ve created a post that includes my real-world usage and costs for November if you’re interested: http://brendannewell.com/musings/?p=140.
Cheers Brendan! And thanks again for your help with all of it. Yeah, I checked your post yesterday. Many thanks for that. The costs look quite similar to the costs during the testing. One thing I noticed in November was that having five snapshots bumped the storage costs up quite a bit. But I suppose that’s entirely expected!
What is the scenario you are considering that has the ratio of 1 user to 1 instance?
Surely a single instance can accommodate multiple users?
SharePoint development has lots of drawbacks with multiple users sharing the same environment, but actually, resource usage alone would probably preclude its effectiveness on an instance of the size we’re considering here. More thoughts on why shared development environments don’t work well for SharePoint over here /index.php/sharepoint-development-productivity-and-virtualisation-technologies/ (see the “What about shared, hosted development environments?” section).