[2024] Amazon WorkSpaces: Set up Your Cost Optimizer

Hello everyone. Lionel here. For sometime I have been working with AWS Workspaces and realized how much costly it is monthly. I came across the most recent Cost Optimizer by AWS for Amazon Workspaces. We will be looking at that

Today, we will look at and explain the procedure and precautions before using AWS’ “Amazon WorkSpaces Cost Optimizer”.

Amazon WorkSpaces Cost Optimizer is a pricing / cost savings solution. It combines several AWS services, and we can deploy it using CloudFormation and start using it. First, it collects our Amazon WorkSpaces’ usage and it also gives us the ability to automatically optimize our billing structure (ALWAYS_ON or AUTO_STOP) based on the usage. Last but not the least, it also deletes unused WorkSpaces.

Contents

• Implementing Amazon Workspaces Cost Optimizer
• Some Notes on the Cost Optimizer
• What kind of report does the Cost Optimizer output?

Contents not covered

• Explanation of Amazon WorkSpaces and CloudFormation

We will be looking at how to deploy Amazon Workspaces Cost Optimizer in out AWS account, we will look at setting out values and finally how to check the report it outputs.

First let us look at how it all works

How it works

Let’s imagine that we have a fleet of virtual desktops (WorkSpaces) for our employees, but their usage varies greatly. Some workspaces are used daily, while others sit idle for extended times. Wouldn’t it be great if we could automatically adjust our billing plan based on our actual usage, saving money without compromising access?

That is what Amazon WorkSpaces Cost Optimizer does! Here’s a simplified breakdown of how it works:

1. Spoke Template: The spoke template facilitates the creation of a custom resource. This resource triggers an AWS Lambda function responsible for registering the account as a spoke account within an Amazon DynamoDB table located in the hub account.
2. Hub Template: For the next step, the hub template sets up an Amazon EventBridge rule, which activates an Amazon ECS task every 24 hours.
3. Task Execution: The ECS task ready, it will assume an IAM role within each spoke account to manage WorkSpaces effectively.
4. Monitoring and Billing Optimization: Our Amazon ECS task periodically polls AWS Directory Service to compile a comprehensive list of all directories registered for Amazon WorkSpaces within our specified AWS Region. Next, it evaluates the total usage of each WorkSpace operating on an hourly billing model. If any of our workSpaces surpass the monthly usage threshold, they are automatically converted to a monthly billing model, optimizing costs. This solution includes a default dry run mode, providing insights into the anticipated cost changes.

At the end of each month, our ECS task will revisit our usage data, ensuring continued cost efficiency. WorkSpaces that fail to meet the monthly usage threshold are switched from monthly to an hourly billing at the start of the following month.

Note that we can manually adjust the billing model through the Amazon WorkSpaces console whenever necessary. We can also customize the threshold that triggers the conversion of each WorkSpace from hourly to monthly billing. Read more here.

5. Results Storage: Just like a good doctor, the system keeps a detailed record of each checkup in the S3. Results from our Amazon ECS task will be securely uploaded to an S3 bucket for logs, reference and analysis.

Steps

The steps we will take to set our environment is:

1. Download the Amazon WorkSpaces Cost Optimizer template
2. Launch the CloudFormation stack (Hub Stack and Spoke Stack)
3. Check report saved in S3 bucket

1. Download our Template

We will start by deploying our Cloudformation template. For that you can click here Amazon WorkSpaces Cost Optimizer template.

Next we will be redirected to the official documents for downloading the template for our Hub (main account where we will be overviewing) and for our spoke (accounts we will be monitoring) accounts.

Once you have clicked on the template you want to setup, we will be taken to the next page to setup our Cloudformation stack.

2. Launch the CloudFormation stack

• If you had clicked on Launch in the AWS Console you would be taken to the page below : -

• If you had clicked on Cloudformation Template button instead, the templates would be downloaded into your computer. In that case, we would click on Upload a template file, browse through your computer and upload it : -

Now we need to fill in parameters, the most important one is the calculation related to switching the billing system. Note also that prices vary by region. Here is a pricing table of cost switching between ALWAYS_ON and AUTO_STOP.

• Estimated Switching Time: Calculated by subtracting the fixed Auto_Stop duration from the Always-On monthly duration, then dividing by the Auto_Stop duration per hour (Enter time rounded to the nearest whole number).
• This calculation refers to the pricing of the Windows bundle options and is specific to the Tokyo region.

It is worth mentioning that the estimated switching times vary even for the same Bundle Type, depending on the volume size. If the volume type used in our environment does not match the specified conditions, we will need to perform our own calculations.

From our selection based on the pricing above, we will enter our values, setting up our stack.

Unless specified otherwise, we can leave other parameters at their default values.

Next, we can now choose between creating a new VPC or using an existing one. By default, “create new” is selected, and internet access is necessary as Fargate fetches the ECR public image. (Unless there are specific requirements, I’d advise to create a new VPC.)

As we mentioned before, selecting “Yes” for Dry Run mode is a very useful. It enables us to preview all recommended changes without implementing them. I would advise to start operating in this mode initially and later we can do any necessary changes accordingly.

I strongly suggest running this solution in Dry Run Mode, (active by default), for a few months. By reviewing daily and monthly reports, we can manually implement any necessary changes. Dry Run Mode provides valuable insight into the impact of recommended adjustments on your WorkSpaces’ costs. It would allow us to thoroughly evaluate and analyze the suggested changes without automatically applying billing modifications.

While setting up our stack, there is the option to terminate workspaces not used for 1 month.

I would suggest to always set this as off, till we are more familiar with it’s operation. Let us go ahead and create it, the values entered in the parameters can be later changed from the ECS environment variables

We have almost finished setting up our cost optimizer, next we will create our resource.

3. Check our report

Finally, we’ll find a report detailing your current usage.

As a reminder, the Amazon WorkSpaces Cost Optimizer operates by initiating ECS tasks from EventBridge, which then compute the WorkSpaces usage and generate the report saved to S3.

By default, EventBridge is set to start at 8 a.m. every morning. We set ours to run at 7:00am daily.

In case we want to check the report immediately, we will just need to adjust the execution time.

Let us take a look at what our actual report, saved in our S3 bucket looks like. (Internal WorkSpaces ID and numbers have been adjusted.)

As seen in the screenshot above, in line 3, since ALWAYS_ON falls below the threshold, transitioning to AUTO_STOP is advised. On another hand, in line 5, AUTO_STOP exceeds the threshold, suggesting a switch to type ALWAYS_ON.

Summary

In conclusion, Amazon WorkSpaces Cost Optimizer provides a robust solution for optimizing costs in accordance with your WorkSpaces’ usage, especially suited for large-scale operations.

Again, I’d advise to begin with dry run mode and gradually transition to live operation.

Thank you for reading all the way to the end.