The first thing to notice is that the most attractive option is to move your on-premise Oracle software to Oracle’s own public cloud. Oracle has IaaS or PaaS cloud services for its “technology” portfolio (Oracle Database and Middleware). The PaaS service costs more but may be considered more convenient from a maintenance perspective (e.g. automatic back-ups are included in PaaS). Oracle allows you to Bring Your Own Licenses if you want to make use of its cloud services. Oracle allows you to cover two Oracle Compute Units (OCPUs) with 1 Processor license and each OCPU is equivalent to two CPU threads. This ultimately means that one Processor license can cover more processing capacity than for any other cloud provider.
Amazon’s and Microsoft’s offerings are similar when it comes to licensing Oracle software running in their public cloud. For both providers it is relatively cost efficient to license small Oracle workloads (compared to licensing the same workload on an on-premise VMware infrastructure for example). However, as the processing capacity goes up, the number of required Oracle licenses doubles compared to what you would need on-premise. The difference between AWS and Azure is of course made by the cost and service levels offered by the two providers. Here are some other important remarks though.
With Amazon you can use the Oracle Database software both with their IaaS (EC2) and also with PaaS (RDS). With Microsoft Azure you only get the IaaS option. However, Microsoft and Oracle now have a partnership meant to allow customers to easily combine infrastructure and platforms from both providers.
Google’s public cloud is not yet on Oracle’s list of Authorized Cloud Environments. Because of this, the only way to migrate your Oracle licenses to their cloud would be through Google’s bare metal solution or to enter (and continuously renew) an Unlimited License Agreement with Oracle.
Oracle allows you to deploy the Oracle programs on Google’s (or Amazon’s or Azure’s) public cloud platform but does not allow you (as a standard) to certify any deployments at the end of your ULA. This has a direct negative effect on scalability, but it does allow you to stay cost efficient from an Oracle licensing perspective. That is if you choose the right physical machine configurations for your workloads.