Published by:

Your Cloud Service Vendor Choice Doesn’t Matter For RPA. This statement may sound controversial, but it isn’t. Choosing a specific cloud vendor does not limit your RPA choices. Selecting a particular RPA vendor does not restrict your cloud service options. RPA vendors eliminated the need for integration with your cloud network services. Here’s why.

As mentioned in previous posts, there are different options for using RPA from the cloud. You may remember that you can use any of the RPA vendors from an instance of a Windows Server (also called a VM, or Virtual Machine), or you can run a pure-cloud solution like Automation Anywhere or Microsoft Power Automate. There are different pros and cons for each option (and vendor), but that’s not the focus of this article. In this article, we will focus on why your cloud vendor choice has no bearing on the RPA platform you use.

Legacy RPA doesn’t care who provides the VM wherever it runs.

Legacy RPA or those RPA platforms that require you to run the platform from a server can run in any cloud providing the right VM. All cloud vendors offer at least some form of Windows Server VM. The performance of a given VM of choice will be the same for all legacy RPA platforms because its performance ties to the vendor’s SLA and processing you required. You don’t get any particular advantages from one cloud vendor to another because you get a VM that meets your specifications for running RPA.

For simplicity and your convenience, it would probably be better that you stay within your current cloud vendor of choice, so you don’t need to establish secure connections between cloud vendors.

No need for special considerations connecting your cloud back-end

Pure-cloud RPA solutions will run from your RPA vendor’s cloud. So, the most common question we get from people is about integrating their existing cloud services vendor into the RPA vendor’s cloud. In reality, it is entirely immaterial. The main reason because these cloud services are operating at different levels.

In most cases, the concern comes in tied to compliance questions. There is some concern for where the data resides, how secure it is while in motion, where does it rest after processing, will there be encryption requirements to integrate the RPA cloud and the Customer’s cloud, etc.

All these concerns dissipate if an encrypted tunnel between the Customer’s cloud and the RPA-vendor’s cloud were to exist between them.

While these concerns are all valid, the main item to have in mind is that these pure-cloud services will not require you to set up a secure tunnel because they already provide you an encrypted communication with the service. The encryption process comes already implemented, configured, and tested right off the (virtual) box.

Whenever you are automating processes, you need a small component implemented within your network. This component is a software agent that communicates with the RPA vendor. In Automation Anywhere’s case, this is called the “runner” or “agent”. This agent is the component that runs in the same location where your applications run. The runner can use the credentials you allow your bots to use. The agent runs locally with your apps, avoiding connectivity interruptions or potential incompatibilities throughout network exchanges.

The agent is the part of the automation platform that communicates with your applications and the RPA vendor. This way, the RPA vendor receives an encrypted stream of data from this agent and only this agent. This encrypted communication follows documented and certified best practices following the highest levels of security. When RPA vendors receive any information needed, they keep it encrypted at rest. This encryption minimizes risk and closes windows to outside elements trying to access your data.

Cloud service vendors will work with any RPA platform.

You can rest assured that RPA vendors are as safe as SAP, SalesForce, and other cloud services. Cloud-native RPA processes use the same encryption processes and methods the rest of the industry uses.