Opportunistically migrate Workspace to new Bundle


I understand how to update a user's Workspace to a new bundle but would like to do so automatically and opportunistically based on the the user's Workspace status. If they are an hourly users, the system would update the bundle on the first opportunity the machine is turned off. If they have an always-on machine I would like to update the first time they are disconnected for 12 hours. The current process is manual, tedious and difficult to coordinate. Wondering if someone has some code out there that would work.

***Update After working with the information that Osvaldo Marte provided it seems that this script would be far more complicated than I first though. It started simple but a lot more is needed.

All workspaces would have to be iterated to get the field information below

workspaceId something like ws-b427q2wlz  
bundleId something like wsb-5pct3mhf8 
state something like 'AVAILABLE' or 'STOPPED'
WorkspaceProperties': {
               'RunningMode': 'AUTO_STOP'|'ALWAYS_ON'|'MANUAL

LastKnownUserConnectionTimestamp': datetime

The logic would be something like this for ALWAYS_ON machines

If bundleid == wsb-abcd1234  
and state == AVAILABLE
and ConnectionState == DISCONNECTED
and LastKnownUserConnectionTimestamp is > 12 hours
Then perform upgrade

The logic would be something like this for AUTO_STOP machines

If bundleid == wsb-abcd1234  
and State == STOPPED
Then perform upgrade
asked 2 months ago113 views
3 Answers

Hey, here's a high-level approach to achieving this automation, along with some pseudocode to give you an idea of how it could be implemented.


1. Monitoring Workspace Status

Here you need a monitoring service or script that continuously checks the status of each Workspace. This service should be able to determine:

  • If the user is an hourly or always-on user.
  • And the last active time of the user (to calculate downtime for always-on users).

2. Determining Update Opportunity

Based on the Workspace status, the service decides when it's an opportune moment to update the Workspace bundle. The logic can be something like:

  • For hourly users: Trigger the update process as soon as the machine is turned off.
  • For always-on users: Trigger the update process when the machine has been disconnected or inactive for 12 hours.

3.Performing the Update

Once an update opportunity is identified, the service should execute the update process. This could involve running update scripts, applying new configurations, and restarting the Workspace with the new bundle.


def check_workspace_status():
    # Example function to check the status of all Workspaces
    workspaces = get_all_workspaces()
    for workspace in workspaces:
        user_type = workspace.user_type  # hourly or always-on
        last_active = workspace.last_active_time
        current_time = get_current_time()
        if user_type == "hourly" and not workspace.is_active:
        elif user_type == "always-on" and (current_time - last_active) >= 12 * HOUR:

def perform_update(workspace):
    # Example function to perform the update

def update_bundle(workspace):
    # Implement the bundle update logic here

def restart_workspace(workspace):
    # Implement the Workspace restart logic here

def main():
    while True:
        sleep(CHECK_INTERVAL)  # Wait for a certain interval before checking again

if __name__ == "__main__":

With this Pseudocode example and the previous link shared by Sidra you can try a demo implementation https://repost.aws/questions/QU2-VcSQGfRyK9oPyKza18WA/opportunistically-migrate-workspace-to-new-bundle#ANvtWIUPe6Tyqz-znzt08GWg

Additionally, automate Workspace updates, utilizing cron jobs for scheduling the execution of your monitoring and updating script.

profile picture
answered 2 months ago
  • This is interesting. I understand the cli commands to update bundles on a workspace with a given workspaceID. There's not really a need to restart a workspace after the update as it happens automatically for always-on machines and for hourly machines it will happen when they next logon. The perform_update section makes sense, not sure the update_bundle section is needed or what operation it would perform. One thing we need is to only target workspaces whose existing bundle = wsb-abcdef123. I don't know that I will be able to turn something like this into a production ready script myself but appreciate your effort. I will at least see if can get the check_workspace_status() section to return information


https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/workspaces.html You can use this documentation to make your own script , preferably you will need either the SDK or CLI to trigger your bundle update process for your respective Workspace.

profile picture
answered 2 months ago
  • There's probably tools in there that could be cobbled together to make a working script but I don't have the resources or experience to do something like this. I have seen self service portals on github and other tooling that folks have created around Workspaces but nothing that addresses my use case.


I have gotten as far as the code to do the workspace migration to a new bundle and works in a stand-alone script

import boto3
aws = boto3.session.Session()
client = aws.client('workspaces')

response = client.migrate_workspace(SourceWorkspaceId='ws-abcde1234',BundleId='wsb-9876xyz')

I think some of the code has to be changed. For example user_type is probably RunningMode

        if RunningMode == "AUTO_STOP" and not workspace.is_active:
        elif RunningMode == "ALWAYS_ON" and (current_time - last_active) >= 12 * HOUR:

I haven't been able to find information about workspace.last_active_time. Closest has been describe-workspaces-connection-status which includes a value for LastKnownUserConnectionTimestamp but I am not sure how to make it work in the script you provided.

answered 2 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions