Choose a Service Sharing Method

Applications often run in different scopes: separate Cloud Foundry spaces, Kyma namespaces, or even different subaccounts. In many cases, these applications need to access the same backend service, for example, a shared logging service, a credential store, or a database.

In every sharing scenario, there are two roles:

• Producer: The scope that owns the service instance and provides credentials.
• Consumer: The scope where an application uses those credentials.

The following tutorials use operational terms based on these roles. The source instance is the original service instance you share. The target is the space, namespace, or subaccount that receives access. The consumer application is the app that uses the shared credentials.

Without a sharing mechanism, you would need to create a separate service instance in each target scope. This increases cost, complicates management, and fragments data.

Important: Some services must not be shared because they are security-sensitive or scoped to a specific space or namespace. Check the service’s documentation before sharing. For a list of such services, see Sharing SAP BTP Services.

Note: This tutorial introduces the group Share BTP Services Across Runtimes and Subaccounts. The following tutorials cover instance sharing and manual credential sharing. Additional methods exist, such as cross-namespace bindings in Kyma or service-specific methods. For a full comparison, see Sharing SAP BTP Services.

• Centralized service: Some services are designed to be globally accessible. You create an instance centrally and access it through its URL, API, or destinations.

• Instance sharing (also called platform-managed sharing): This is the recommended method and uses the SAP Service Manager. You create one source instance (the producer), mark it as “shared,” and create lightweight reference instances in target scopes. Bindings on the reference instance yield credentials to the original. The platform securely manages the lifecycle and credentials.

• Manual credential sharing: This is a universal fallback that works across any boundary, including different subaccounts, regions, and global accounts. You create a service key for the source instance, extract the credentials, and inject them into another scope as a User-Provided Service (Cloud Foundry) or Kubernetes Secret (Kyma). Because credentials live outside the platform’s management, you are responsible for their transport, rotation, and cleanup.

The following steps help you determine which sharing method applies to your scenario.

If you’re not sure whether your service is architecturally centralized, check the service’s documentation, or see Centralized Services.

• If your service is centralized (for example, SAP Cloud Transport Management), create an instance (or one per landscape stage). You don’t have to set up any sharing mechanism and this tutorial group doesn’t apply. If you still want to learn how sharing works, pick a different service and continue to the next step.

• If your service isn’t centralized, continue to the next step.

If you use Cloud Foundry, continue to the next step. This tutorial group covers the CF-native cf share-service command.

If you use Kyma: Are your source and target in the same Kyma cluster, just in different namespaces?

• Yes: Use a cross-namespace ServiceBinding. Set serviceInstanceNamespace on your ServiceBinding to reference the service instance’s namespace directly. No sharing mechanism is needed and this tutorial group doesn’t apply. For details, see ServiceBinding CR.
• No: Continue to the next step.

• Yes, using the standard reference-instance plan: Continue to the next step.
• Yes, but the service uses a service-specific method: Follow the service’s sharing documentation; this tutorial group doesn’t apply.
• No: Use manual credential sharing. Continue with Share Service Credentials Manually Across Boundaries.

Tip: If you’re not sure, verify it in your subaccount: open Instances and Subscriptions, find the instance, and look for a Share option in the actions menu. Alternatively, check the service’s documentation for supportsInstanceSharing: true.

If your service supports instance sharing, start with Create and Share a Source Service Instance.

Then, continue with the tutorial for your target runtime:

• Cloud Foundry: Consume a Shared Service Instance in Cloud Foundry
• Kyma: Consume a Shared Service Instance in Kyma

Both tutorials cover same-subaccount and cross-subaccount scenarios.

Note: If you want to share across regions or global accounts, instance sharing alone isn’t sufficient. Use manual credential sharing (covered in Share Service Credentials Manually Across Boundaries) for the cross-region portion.

Question 1: Which sharing method integrates with the platform’s lifecycle management and authorization model?

• Manual credential sharing
• Instance sharing (SAP Service Manager) [CORRECT]
• Centralized service
• User-Provided Service

Question 2: Your service doesn’t support instance sharing. You need to make it available in a Cloud Foundry space in a different subaccount. Which method do you use?

• Instance sharing with reference instances
• cf share-service with the -o flag
• Manual credential sharing [CORRECT]
• Cross-namespace ServiceBinding

Question 3: Your Kyma application and the service instance are in different namespaces of the same cluster, within the same subaccount. What do you do?

• Create a reference instance using instance sharing
• Use manual credential sharing with a Kubernetes Secret
• Set serviceInstanceNamespace on a cross-namespace ServiceBinding [CORRECT]
• Share the instance using cf share-service

Question 4: A service is listed as security-sensitive in its documentation. What do you do?

• Share it using manual credential sharing instead of instance sharing
• Create a reference instance with restricted permissions
• Do not share it. Use a separate instance in each scope. [CORRECT]
• Share it only within the same subaccount