EC2 robots vs AWS Workspaces Robots

Hi all,

My enterprise is using AWS workspaces in our AWS cloud as our robot machines.

UiPath’s documentation and recommendations indicate that the preferred solution is to spin up an EC2 server instead for the robots. There are benefits to this, such as being able to set up high density robots all within a single EC2 instance and taking advantage of elastic robot orchestration.

However, my company’s initial impetus to move to this new infrastructure was that it would “stabilize the bots.” It is true that the robots suffer from latency when communicating with our internal applications. It is also true that the workspaces have really strange bugs where they might disconnect from orchestrator for a few seconds at a time, and we’ll get an orchestrator alert about it. I’m not sure that either of these would necessarily be resolved by re-doing our infrastructure on EC2.

Also, I haven’t wrapped my head around exactly what would be different about these from an infrastructural side other than a general “EC2 is the recommended solution.” The workspaces are persistent. The EC2 servers also have their system resources virtualized. Isn’t it basically the same thing on the back end? Just the ec2 instance’s OS needing to be managed manually, vs the workspace getting automatic updates?

Are there any other meaningful differences I haven’t recognized that would lead to a more broadly “stable” environment?

I ask because our security policy dictates that anything considered a “server” on our AWS environment needs to be absolutely locked down, whereas our workspaces were fairly permissive in allowing us to access things on the internet. So, despite the benefits I identified above, there’s either going to be a huge trade-off on accessibility or an argument with the security team.

1 Like