Skip to Content
Technical Articles

Consume AWS services on SAP Cloud Platform

SAP Cloud Platform’s Strategy has been evolving and there have been some major changes in the last few weeks. As of last month, SAP managed backing services like PostgreSQL, MongoDB, Redis, and RabbitMQ have been retired from SAP Cloud Platform. These were some of the popular open-service based backing services which were used in SAP Cloud Platform by customers to build applications. My colleague Manjunath Baburao had earlier blogged about this announcement  “Evolution of SAP Cloud Platform – Retirement of SAP ‘managed’ backing services” . As pointed out in his blog post, the reason for SAP to make this move is primarily focus on providing differentiating Business Services which can add more value to business processes within SAP solutions. Few people interpreted this as SAP not being open and forcing users to use HANA or Enterprise Messaging service. I would like to clarify that – its not mandatory to use SAP services like HANA or Enterprise Messaging service to support those missing capabilities. SAP is providing a choice and flexibility for its customers to decide whether they want to use SAP’s services on SAP Cloud Platform or use similar services from the underlying hyperscalers. Obviously, lot of factors will come into play including cost, feature set, support, SLA etc. Hence, I believe SAP Cloud Platform continues to adhere to its core principles of “Openness” and “Freedom of choice“. SAP’s partnership with the Hyperscalers is growing rapidly and it makes more sense for SAP to piggyback on the investment the hyperscalers make in those open-source backing services rather than reinventing the wheel.

In this blog, I would like to provide a walk through of a recent capability added to SAP Cloud Platform called “Resource Provider“.

Using Resource Providers to create Amazon Relational Database Service (RDS) – PostgreSQL

 

Resource Providers allow you to connect with different Cloud Vendor accounts and consume remote services which you own. As of today, its possible to connect with AWS and the only remote service which can be consumed through this channel is AWS RDS PostgreSQL database. More Cloud Providers/remote services will be added in the future.

In order to setup a PostgreSQL in your SAP Cloud Platform account, you would need to follow the below steps.

Login to your AWS Console and create VPC/subnets within your selected region. If you don’t have AWS account, you can try it out for free.

Locate the “Resource Providers” menu within the Global Account menu of your SAP Cloud Platform account (as shown below). This is where you will be able to add and manage all the Resource Providers. Click on “New Provider”

In the “Edit Resource Provider” screen, Select the Provider as “AWS” and provide a display/technical name. In the configuration properties, you would need to provide an AWS Access Key ID and Secret Access Key. You would have obtained this when your user profile was created in AWS IAM service.  Finally, provide AWS region and VPC ID which you had configured earlier.

I have a SAP Cloud Platform subaccount created in AWS for this demonstration. I will be creating a PostgreSQL within this subaccount.

Before creating a PostgreSQL instance, the appropriate entitlements must be allocated to this subaccount. Hence as an administrator, you will have complete control on how many units of a particular service needs to be allocated to each subaccount. In the “Subaccount Assignment” menu, select your subaccount and Click on “Configure Entitlements”.

Add a service plan which launches the entitlement screen. Navigate the service catalog to locate “PosatgreSQL on Amazon(AWS)”. Select from one of the available plans.

You also have an option to set the quota/number of instances permitted for this subaccount. Save your changes once you set the quota.

Navigate to the “Service Marketplace” within the subaccount and locate the service “PostgreSQL on Amazon(AWS)”. Select it to create an instance.

In the parameters section, you can provide the configurations to be used while creating a PostgreSQL instance. Notice that the Technical name of Resource Provider is being used.

Finally, provide a name to the Instance and save your changes.

This will take about 10 minutes to create the PostgreSQL instance.

Switch to the AWS Console and you will find a new RDS instance created in your account.

You can explore the configurations used at the time of creating this instance.

This shows how one can leverage the SAP AWS service broker to provision and de-provision PostgreSQL instances from within SAP Cloud Platform within few minutes.

Here is the link to the FAQ –  “Backing Services Strategy for SAP Cloud Platform” where you will find lot of answers to the questions you might have. I have just highlighted two sections below as I did

With Bring-Your-Own-Account(BYOA) approach, you will need to have a separate contract/ subscription with hyperscalers and the billing for the resources consumed will need to be arranged with the hyperscaler.

SAP will not be involved in Day2 operations like version upgrades, patching, backup/restores etc. SLA’s for those backing services now depend on the hyperscaler.

Apart from this, there are few other approaches to consume AWS services within SAP Cloud Platform. I have covered them in the below two sections.

User-Provided Services on SAP Cloud Platform

 

Another way to consume AWS services within SAP Cloud Platform is to use the User-Provided services on Cloud Foundry. Unlike the previous options, here you will have to create your instances in AWS and consume them in SAP Cloud Platform. You will have to create a publicly accessible service in AWS and use the credentials/service URL to connect to it from apps in SAP Cloud Platform. Suhas Narasimhan has recently posted a blog on how to achieve this with ease – “Consuming Hyperscaler managed services on SAP Cloud Platform as User-Provided Services“.

Leveraging AWS service broker

 

The AWS Service Broker allows native AWS services to be exposed directly through SAP Cloud Platform or any platform that implement the Open Service Broker API. This is an open source service broker provided by AWS. Harini Gunabalan has posted a blog on this topic “How to consume AWS services on SAP Cloud Platform?” which shows the steps required to surface some of the AWS services within SAP Cloud Platform cockpit.

 

4 Comments
You must be Logged on to comment or reply to a post.
  • Thanks Murali for the nice blog. I was thinking so in this scenario the user will have to pay for the subscription of aws as well as SAPCP also for using this the service via it right? Will it not increase the cost? Secondly this might lead to latency issues also right?

    I am now thinking what benefits does a customer get if different type of services such as MongoDB/Postgre etc. are provided by the same service provider. One for sure is the performance i can think of , second can be simplicity in managing all from one service provider etc.

    Lets say AWS service is failing, custom will first approach us and we will approach AWS as we now have dependency on them. This is deteriorate the user the experience?

    Just thinking!

    • Hi Nabheet,

      Correct. User will have to pay for the required subscription of services to both SAP as well as AWS. Ofcourse, its always easy for the customer to deal with one vendor for all their required services as it will have impact on cost, performance, SLA etc. With regard to the latency, I have explained it below for Victor’s query

  • Hi Murali, nice blog, thanks for the info!

    I have a curiosity: assuming both SAP Cloud Platform and the backing services are in the same AWS region. Is traffic routed over the public internet, or would it stay within the AWS infrastructure? (might have an impact on security and latency)

    Do you have some more in-depth information on how this would be handled by the AWS infrastructure?

    • Hi Victor,

      You would have read the below in the FAQ document.

      Note that it is highly recommended to procure and create the hyper-scaler account in the same (or closest) data center/region,where your SAP Cloud Platform account currently resides. This decision would have an impact on any latency/performance requirements of your cloud application

      The traffic will be routed by default via the internet. I believe if you establish a Direct Connect to AWS from your corporate network, you should be able to access both AWS resources + SAP apps built on SCP CF (which reside within AWS VPC) without having to route the traffic on internet. However, this is only applicable for few use cases.