UiPath Robots deployment on AWS

Help
,
1

Hi,
I’m planning to deploy UiPath Robots (Unattended) on AWS EC2 Window Server instance and all other UiPath components on AWS as well. We have about 20 licenses for unattended bots, can we have a single EC2 instances to run all the bots (concurrently) or one instance per bot. Any pros and cons with either of these approach ?

Appreciate any feedback.

2 Likes
2

I would think about these…

  1. How are you going to manage your infrastructure? Manually via Web Console / CLI, Cloudformation, Terraform, something else.

  2. How similar will your robot’s environments be at the system level? You’ll still have some control at the profile level, but you might have to configure a OS for a particular process that is not compatible with your other processes.

  3. What are your cost constraints? With a single host to robot, your Windows license is included in the pricing. If we look at the us-west-2 region Spot instances for a t2.xlarge (4 vCPU / 16GiB Memory) you’re looking at $0.2266 USD, let say you put a single Robot on the host, then you are looking at $4.532/hr for 20 hosts (This doesn’t account for storage, traffic, etc.).

    What if we bump that up to say a t2.2xlarge (8 vCPU / 32GiB Memory) at $0.4332 USD, not accounting for other application requirements, if we put all 20 robots on the single host, that’s significantly cheaper. Now there will be additional Windows licensing costs (Remote Desktop Services CAL) which is not obtained through AWS, I’m not sure what the licensing per host/seat might be, this would be a consideration.

  4. Leads into my next thought of Risk; Should there be a failure on the host, what level of risk is acceptable to you? Can your process design handle being down abruptly? (should the worse happen) assuming you can spin your infrastructure back up in a snap? Assuming you want to limit some risk of exposure you might think about balancing #3 / #4 by splitting your robots into 2 or more groups per Orchestrator Environment say two t2.2xlarge with 10 robots each that would still be a quarter of the price of 20 t2.xlarge. In this way, it will probably be cheaper even with a CAL. Doing this will minimize the risk as you could put all 20 robots in the same orchestrator environment, but split them up across 2 or more hosts incase one fails or you need to do maintenance.

  5. Shared configuration between robots… does your process design account for shares configurations, does this configuration need to be local or could you through it into a database, NFS/EFS, S3 Bucket, etc.

I think the last couple points are the biggest thing to think about with balancing costs vs risk. You can further reduce the costs (up to 75%) by looking at the other pricing plans e.g. Reserved vs Spot if you can commit to having a particular sized host for 1 or 3 years at a time.

2 Likes
3

If you want all robots on a single ec2, then you are looking to use the following feature:

I does scare me a little to imagine dealing with 20 robots there, cause of availability issues, if you ever need to do some management, you lose all robots at once… maybe you want to consider some hybrid configuring with some high density robots sharing the same instance and some individual…

2 Likes
4

Thanks @codemonkee and @bcorrea for your response and to give food for thought.
I’m planning to use EC2 Window Server instances for bots to execute backend processes and VDI for attended bots and to host studio. @codemonkee - Can you shed some light on your point 3 when you say Window license is included in pricing and on deploying Robot on host changes the cost as I’ll be paying the cost of EC2 instance usage and cost of Bot is covered in license.

Additionally, as I’m planning to use VDI for bots and Studio, can I have one VDI which can be used for studio robot as well as attended bot ?

1 Like
5

When you spin up an Windows EC2 instance, you need to license Windows whether you BYOL or license through AWS. This base license allows a maximum of two concurrent users, in order to go beyond the initial two connects you would need to purchase RDS CAL (Remote Desktop Services Client Access License) from Microsoft; They have pricing model per seat/user and per device, I’m not sure if both can apply to a Windows instance with AWS or not.

So if you intend to setup your hosts in a High Density mode, you’ll have the cost of

  • EC2 Instance
  • Windows License (If you use BYOL, otherwise it is included in the EC2 cost)
  • Windows RDS CAL
  • UiPath Robots

I think determining your risk tollerance, operational management overhead, and acceptable cost will determine which way you want to go, not having looked into the costs of CALs it very well might be more cost effective or at least offset by increasing your EC2 instance sizing and minimizing the number of instance you deploy.

I’ve setup a shared host for Studio before with using development/studio robot license when Studio is connected to Orchestrator as well as a single named studio license when not connected to Orchestrator. I can’t give a definite answer on mixing of Attended/Unattended and Studio/Developer studio, technically it is possible I’ve mixed Development and NonProduction (Unattended) in testing, If you run Studio on a host that is a non-developer robot, it will present you with a warning about it not being the intended usage (This was with 2018.3, not sure what behavior 2019.10 would give you).

If you wanted to do something similar for Attended vs Studio… this would all depend on the use case of the user, if you have some users that will not be using Studio, you’d licence their runtime with Attended, but if they would also run Studio, they’d need to be licensed for that. I would reach out to UiPath support on the technical limitations and TOS if that can be achieved as you’re thinking. (In practice, I haven’t thought about Developers also being the benefactors of attended Robots or if you can use Studio license as a production oriented work.)