Service Catalog

Instance Management

IaC Deployable

BTP Foundation

BTP Service Plans

Every BTP service offers one or more Service Plans that define the capacity, features, and pricing tier. Choosing the right service plan is essential for functional requirements, cost optimisation, and production readiness.

Service Plans, Instances, and Bindings

Every service in the BTP Service Marketplace offers one or more Service Plans that define the capacity, feature set, and pricing of that service. The lifecycle of BTP service consumption has four stages:

1. Entitle: Assign the service plan entitlement to the target subaccount (quota reservation).
2. Create Instance: Provision a service instance in the subaccount using the selected plan and configuration parameters.
3. Bind or Create Service Key: Generate credentials — binding attaches to an app; service keys are standalone credentials for external tools.
4. Consume: The application uses the credentials (client_id, client_secret, urls) injected as environment variables or Kubernetes secrets.

The underlying mechanism is the Open Service Broker API (OSBAPI) — all BTP services implement this standard, whether consumed via the CF marketplace, Kyma ServiceInstance CRDs, or the BTP Service Operator for Kubernetes.

Quick Facts

Catalog: BTP Discovery Center
Protocol: Open Service Broker API
CF access: cf marketplace / cf create-service
Kyma access: ServiceInstance CRD
IaC (CF): MTA descriptor (mta.yaml)
IaC (Kyma): Helm + ServiceInstance YAML
IaC (Terraform): btp_subaccount_service_instance
Credentials: ServiceBinding / Service Key

Service Plan Lifecycle — Catalog to Binding

Rendering diagram…

Key Service Plans Reference

Service	Plan	Best For	Key Limits	Production?
SAP HANA Cloud	hana-cloud	Production databases	30 GB RAM, 120 GB storage base	Yes
SAP HANA Cloud	hana-cloud-trial	Trial / learning	30 days, 32 GB RAM — auto-deletes	No — Dev only
SAP AI Core	extended	Production AI workloads	Full model training + inference	Yes
SAP AI Core	free	PoC / development	Inference only, no training, rate-limited	No — Dev only
Integration Suite	enterprise_agreement	Production integration	Unlimited messages	Yes
Cloud Foundry	standard	Production CF workloads	Quota-based memory allocation	Yes
Kyma Runtime	aws / azure / gcp	Production K8s workloads	Node count-based (minimum 2 nodes)	Yes
ABAP Cloud	standard	Production ABAP development	ABAP compute units (ACU) based	Yes
XSUAA	application	App-level OAuth 2.0	Per-app, not shared across apps	Yes
Destination Service	lite	All environments	Shared service, no resource limits	Yes

Enterprise Example — DEWA Service Plan Strategy

DEWA selects production-grade plans for all production subaccounts and uses free/trial plans in development subaccounts to control cost without affecting production capacity:

Production (ae1)

HANA Cloud: hana-cloud (3 instances across prod subaccounts)
AI Core: extended plan (1 unit — AI Services prd)
Integration Suite: enterprise_agreement
Kyma: aws plan (1 cluster — Smart City prd)

Development (eu10)

HANA Cloud: hana-cloud (1 smaller instance per dev subaccount)
AI Core: free plan (no training, inference only)
Integration Suite: trial (limited messages)
No Kyma — CF only to reduce cost

MTA Descriptor — Service Instances (Cloud Foundry)

Define service instances in MTA for reproducible deployments

The MTA descriptor is the recommended way to define service instances for Cloud Foundry deployments. It ensures instances are created consistently across environments and are tracked in version control.

mta.yaml

1# MTA descriptor (mta.yaml) — service instances and bindings
2_schema-version: '3.1'
3ID: dewa-s4ext
4version: 1.0.0
5
6modules:
7  - name: dewa-s4ext-srv
8    type: nodejs
9    path: gen/srv
10    requires:
11      - name: dewa-hana-cloud       # HANA Cloud binding
12      - name: dewa-xsuaa            # XSUAA for OAuth
13      - name: dewa-destination      # Destination service
14      - name: dewa-connectivity     # Cloud Connector
15
16resources:
17  - name: dewa-hana-cloud
18    type: org.cloudfoundry.managed-service
19    parameters:
20      service: hana
21      service-plan: hana-cloud
22      config:
23        memory: 30         # GB RAM
24        storage: 120       # GB disk
25        edition: cloud
26
27  - name: dewa-xsuaa
28    type: org.cloudfoundry.managed-service
29    parameters:
30      service: xsuaa
31      service-plan: application
32      path: ./xs-security.json
33
34  - name: dewa-destination
35    type: org.cloudfoundry.managed-service
36    parameters:
37      service: destination
38      service-plan: lite
39
40  - name: dewa-connectivity
41    type: org.cloudfoundry.managed-service
42    parameters:
43      service: connectivity
44      service-plan: lite

ServiceInstance & ServiceBinding — Kyma

service-instance.yaml

1# Kyma — ServiceInstance and ServiceBinding CRDs
2apiVersion: services.cloud.sap.com/v1
3kind: ServiceInstance
4metadata:
5  name: dewa-hana-cloud
6  namespace: dewa-s4ext
7spec:
8  serviceOfferingName: hana
9  servicePlanName: hana-cloud
10  parameters:
11    memory: 30
12    storage: 120
13    edition: cloud
14
15---
16apiVersion: services.cloud.sap.com/v1
17kind: ServiceBinding
18metadata:
19  name: dewa-hana-cloud-binding
20  namespace: dewa-s4ext
21spec:
22  serviceInstanceName: dewa-hana-cloud
23  secretName: hana-cloud-credentials   # K8s Secret created automatically

Best Practices

Use trial plans in sandbox subaccounts only

Trial plans (hana-cloud-trial, AI Core free) expire or have hard limits that will block production workloads. Never deploy to production with a trial plan.

Pin service plan versions in MTA descriptors

Service plans can introduce breaking changes when updated. Pin plan names explicitly in MTA descriptors to avoid unexpected upgrades on redeploy.

Create service instances via IaC, not cockpit

Cockpit-created instances are not tracked in version control. Use MTA descriptors (CF), Helm + ServiceInstance CRDs (Kyma), or Terraform for all production instances.

Label all service instances

Apply labels (owner, cost_center, purpose) to service instances. This enables cost attribution in BTP billing exports and simplifies decommissioning audits.

Use service keys to test connectivity before binding

Create a service key to generate credentials and test connectivity to a service (e.g., HANA Cloud) before binding it to your application in the MTA descriptor.

Common Pitfalls

Using hana-cloud-trial for a real project

The trial plan auto-deletes after 30 days with no warning. Projects that start on trial and migrate late lose all schema definitions and data.

Not reviewing plan features before selection

Some plans lack specific capabilities (e.g., AI Core free plan has no model training, only inference). Discovering this during development is costly — check Discovery Center plan comparison first.

Creating service instances in cockpit without IaC tracking

Manually cockpit-created instances become orphans with no reproducibility. When environments need to be recreated (DR, region migration), these instances cannot be reliably restored.

Forgetting that plan upgrades may require instance recreation

Some services (including HANA Cloud plan changes) require creating a new instance rather than in-place upgrade. Factor this into change management planning.

Security Considerations

Service binding credentials are high-value secrets

Service binding credentials (client_id, client_secret, HANA Cloud connection details) provide direct access to production data and APIs. Treat them with the same care as database passwords.

Store service binding credentials in a secrets manager — SAP Credential Store (BTP service) or Kubernetes Secrets (Kyma). Never hardcode in application code or config files.

Never share service binding credentials across subaccounts — each environment (dev, prd) must have its own set of bindings with separate credentials.

Use least-privilege XSUAA scopes in xs-security.json — only grant the specific OAuth scopes your application needs, not wildcard grants.

Rotate service keys quarterly and immediately upon team member offboarding — service keys are long-lived credentials if not actively rotated.

Enable SAP BTP Audit Log service to capture all service instance creation, binding, and deletion events for compliance evidence.

References

SAP BTP Service Marketplace (Discovery Center)

Browse all BTP services, compare plans, check regional availability, and view pricing.

SAP Help: Using Services in Cloud Foundry

Official documentation on service instances, bindings, and service keys in the CF environment.

MTA Specification

Multi-Target Application (MTA) descriptor reference for defining service instances as code.