As we embark on this transition of making Hyper-scaler managed backing services consumable on SAP Cloud Platform, one of the immediate options available for you is User-Provided Services.
User-Provided Services on Cloud Foundry
Cloud Foundry  offers us a way to consume services that are not native to the platform but still make use of the CF service operations such as service instance renaming, deleting, binding, and unbinding and provide the application with the service instance credentials using the vcap environment variables. Once created, user-provided service instances behave just like service instances created through the marketplace.
This blog only intends to provide you direction on how you could consume any service managed by Hyper-scalers like AWS or Azure on our SAP Cloud Platform via the Cloud Foundry User-Provided-Services. The detailed configuration steps can be found on the respective hyperscaler documentation.
This process primarily involves 2 major steps:
Create any service instance (MongoDB, PostgreSQL or any other service) on your hyper scaler account and obtain the connection parameters like “URL”, ”Port”, “Credentials” and create the necessary network configuration to make the instance publicly accessible from the SAP Cloud Platform.
Create a User-Provided Service instance on SAP Cloud Platform using the credentials obtained in the above step. This instance can then be bound to applications running on SAP Cloud Platform like we would with any other SAP Cloud Platform managed service instance. The lifecycle of these service instances can be then managed on SAP Cloud Platform cockpit.
SAP Cloud Platform Cloud Foundry account running on AWS or Azure.
Hyper-scaler account (AWS or Azure).
Now lets understand how we could perform the first step of making a service instance available on any Hyper-scaler publicly accessible.
Create a Virtual Network to isolate AWS resources within the AWS cloud. You can launch your AWS resources, such as RDS instances into your VPC . And you can expose this VPC to be publicly accessible via the internet. For this you can follow the Use Case Scenario to setup a VPC with a public subnet.
With the above setup, we will have a VPC with just one subnet. Each subnet must reside entirely within one Availability Zone and cannot span zones. Availability Zones are distinct locations that are engineered to be isolated from failures in other Availability Zones. By launching instances in separate Availability Zones, you can protect your applications from the failure of a single location. Hence, the VPC must have at least two subnets mapped to two separate availability zones (with subsets of the CIDR). It is recommended to create another subnet and map it to a separate availability zone.
Now that you have the VPC and additional subnet created, you need to ensure the outbound traffic leaving the subnets in this VPC is routed to the internet. This is achieved by creating routes in the Route Table associated with the subnets in the VPC. 
Next, To enable access to or from the internet for instances in the VPC, you must do the following:
Attach an internet gateway to your VPC.
Ensure that your subnet's route table points to the internet gateway.
Ensure that instances in your subnet have a globally unique IP address (public IPv4 address, Elastic IP address, or IPv6 address).
Ensure that your network access control and security group rules allow the relevant traffic to flow to and from your instance.
Create any of the required service resources like, RDS db instances in the VPC created above and make note of the Endpoint URL and Port Number provided in the instance overview section along with the credential like Master Username/Password and Port Number. This would be required later to be configured on SAP Cloud Platform.
Follow the documentation  to implement the same on the azure account.
Create any Azure database or service instance. Be it PostgreSQL or Azure Cosmos DB.
Enable public endpoint for your managed instance in the Azure portal. You would be able to access this in SAP Cloud Platform Cloud Foundry running on Azure infrastructure.
Configure your managed instance network security group to allow traffic to the managed instance public endpoint.
Obtain the managed instance public endpoint connection string. The connection string and other information available would be required later to be configured on SAP Cloud Platform.
Make note of the following parameters of the instance that you'll require on SAP Cloud Platform to configure a new User Provided Service.
Public endpoint URL for the service
Service identifier name
Once you have a publicly accessible service instance hosted on the Hyperscaler account you can now create a User-Provided Service on SAP Cloud Platform to consume the service on Cloud Foundry with the above credentials:
Note that the structure for the credentials can be “free-form” but it is recommended to generate in the same format as the existing managed service offerings of SAP. This is particularly useful, if you are migrating your existing applications from existing SAP managed services to Hyperscaler managed services as the amount changes required in the application will be minimized.
Note that the structure of the credentials needs to be understood by the application especially if there is code for auto-detecting the services (like Spring Cloud Connectors). An example is given below for reference (substitute the placeholders with the values as provided above)
You can use the below CLI command template to create a User-Provided Service.
You can also create the User Provided Instance on the cockpit as below:
Click “User Provided Service” option item on the navigation menu.
Click on ‘New Instance’. And provide an instance name and the credentials and endpoint url details in the JSON format mentioned above and values used during the instance creation on AWS or Azure. And click "Save".
Now a new UPS based service instance has been provisioned on SAP Cloud Platform which can be consumed by applications on SAP Cloud Platform like any other SAP managed service instances. The connection parameters required for your applications will be now available as vcap service environment variables just like it used to be in any of the SAP managed service instance. This approach would also be helpful if your application is built as an MTA as you can configure these services in the mta.yml like you did with SAP Managed services.
This service instance can be bound to any of the applications on SAP Cloud Platform and consumed by using the parameters available via the VCAP environment variables.