Who would have thought, back in 2014, when AWS launched Amazon WorkSpaces it would have such an impact on the virtual desktop market? Amazon WorkSpaces—AWS’ fully managed, secure desktop computing service—allows enterprises to easily provision cloud-based virtual desktops and provide users access to the documents, applications, and resources they need from any supported device. Over these three short years, Amazon WorkSpaces has made great strides in reducing the costs related to VDI deployment, support and software packaging while improving service levels and deployment time of new applications. Amazon WorkSpaces provides the flexibility to securely work from anywhere, anytime and on any device without the cost and complexity of traditional VDI infrastructure.
However, enterprises have faced a few challenges when deploying Amazon WorkSpaces. One of the grea challenges with wholesale deployment of Amazon WorkSpaces has been how to allocate the costs associated with thousands of instances to the various departments that are using each resource. In 2016 AWS enabled users to tag each workspace with up to 50 tags. While this is a step in the right direction, tagging is not included in the launch process. Instead, users have to remember to tag the instance after it is launched. This is where the process tends to break down, leaving thousands of dollars related to cloud spend either un-allocated or incorrectly allocated.
To address this drawback, it is important to create and implement two processes. The first step is pretty basic: Develop a process and train all team members responsible for launching new WorkSpaces to tag each workspace after it is launched. The second step is to set up automation to efficiently audit and provide notifications when resources (specifically Amazon WorkSpaces) are launched without a particular tag or set of tags. Unfortunately, with Amazon WorkSpaces you aren’t able to use the AWS Config “required-tags” rule to enforce your process policy as Config only supports a limited set of AWS resource types. (NOTE: You can check out the AWS Config Developer Guide for more on using it to enforce tag requirements on Config supported resources.) Instead, you can roll your own tag enforcement solution using AWS Lambda and CloudTrail.
This process is fairly simple. When you activate AWS CloudTrail logs, AWS will dump all API calls as JSON log files to an S3 bucket. You can then setup a trigger on that bucket to invoke an AWS Lambda function that can scan the logs for specific events, such as Amazon WorkSpace’s “CreateWorkSpaces” method. If it finds an event, it can publish a message to an SNS topic notifying you that the resource does not have the appropriate tag. You can even set the message up to include the creator tag that AWS adds to all new resources. This way, if you need to know who launched the instance in order to determine how to tag it, you will have that information included.
Even when you have the tag in place there is still the issue of how to allocate those costs incurred before the resource was tagged. Because AWS tags are point in time, only costs associated after the tag is in place will be included in any AWS tag report. 2nd Watch’s cloud financial management tool, CMP|FM, is a powerful resource that can provide accurate cost accounting and deep, financial insight into Amazon WorkSpaces usage by applying boundaries by month to all tags. In other words, any tag applied during the middle of the month will be applied to the entire month’s usage— appropriately accounting for all of your costs associated with Amazon WorkSpaces—without the need to manually allocate them to the correct department.
If you are looking to deploy Amazon WorkSpaces across your enterprise, it is important to ensure that you have the systems in place for proper cost accounting. This includes implementing documented processes for tagging during launch and automation to identify and manage untagged instances, and leveraging powerful tools like 2nd Watch CMP|FM for all your cost allocation needs to ensure accurate cost accounting.
— Timothy Hill, Senior Product Manager, 2nd Watch
Amazon Web Services will continue to lower its prices for IaaS (Infrastructure as a Service) and PaaS (Platforms as a Service) for a number of different reasons. But that doesn’t mean that your public cloud costs will go down over time. Over the past 2 years I’ve seen SMB’s and Enterprise firms surprised by rising cloud costs despite the falling rates. How does this happen? And how can your business get ahead of the problem?
Let’s examine how AWS can lower its rates over and over again.
First is the concept of capacity planning, which is much different in the public cloud when compared to the traditional days of voice and data infrastructure. In the “ole days” we used the 40-60-80 rule. Due to the lengthy lead times to order circuits, rack equipment, run cables and go-live, enterprise IT organizations used 40-60-80 as triggers for when to act on new capacity building activities. At 40% utilization, the business would begin planning for capacity expansion. At 60% utilization, new capacity would be ordered. At 80% utilization, the new capacity would be turned up and ready for go-live. All this time, IT planners would run around from Business Unit to Business Unit trying to gather their usage forecasts and growth plans for the next 12-24 months. It was a never ending cycle. Wow – that was exhausting!
Second is the well-known concept of Economies of Scale, which affords AWS cost advantages due to the sheer size, scale and output of its operations globally. Simply put, more customers will lead to more usage, and Amazon’s fixed costs will be spread over more customers. As a result, the cost per unit (EC2 usage hour, Mbps of Data Transfer, or Gigabyte of S3 storage) will decrease. A lower cost per unit allows Amazon to safely lower its prices and lead the market in public cloud adoption.
In the public cloud world, Amazon can gauge customer commitment, capacity planning and growth estimates by offering reservations for its infrastructure – otherwise known as Reserved Instances. Historically Reserved Instances come in six different types – No Upfront, Partial Upfront and Full Upfront (referring to the initial down payment amount) and offered in a 1-year or 3-year commitment. No Upfront RI’s have the lowest discount factor over the commitment term, and Full Upfront RI’s have the highest discount factor. With the help of Reserved Instances, AWS has been able to plan its capacity in each region by offering customers a discount for their extended commitment. Genius!
But it gets better. In January, AWS released a new type of Reserved Instance that gives the customer more time control and also provides Amazon with more insight into what time of day the AWS resource will be used. Why is this new “Scheduled Reserved Instance” important?
Well, a traditional RI is most effective when the instance runs all day and all year. There is a breakeven point for each RI type, but for simplicity let’s assume that the resource should be always-on to achieve the maximum savings.
However a Scheduled Reserved Instance allows the customer to designate which hours of which day the resource will run. Common use cases include month-end reporting, daily financial risk calculations, nightly genome sequencing, or any regularly scheduled batch job.
Before the Scheduled RI, the customer had 3 options – (1) run the compute on-demand and pay the highest price, (2) reserve the compute with a Standard RI and waste the time when the job’s not running (known as spoilage), or (3) try to run it on Spot Instances and hope their bid is met with available capacity. Now there’s a fourth option – The Scheduled Reserved Instance. Savings are lower, typically in the 5-10% range compared to on-demand rates, but the customer has incredible flexibility in scheduling hours and recurrence. Oh yeah – and did I mention that AWS can now sell even more excess capacity at a discount?
With so many options available to AWS customers, it’s important to find an AWS Premier Partner that can analyze each cloud workload and recommend the right mix of cost-reducing techniques. Whether the application usage pattern is steady state, spiky predictable, or uncertain-unpredictable, there is a combination of AWS solutions designed to save money and still maintain performance. Contact 2nd Watch today to learn more about Cloud Cost Optimization Reports.
-Zach Bonugli, Managed Cloud Specialist