BTP Subaccounts
The core deployment and isolation unit in SAP BTP. Each subaccount is a fully isolated environment with its own service instances, subscriptions, runtime environments, trust configuration, and cost tracking.
What is a BTP Subaccount?
Subaccounts are the primary deployment containers in SAP BTP. Each subaccount is a fully isolated unit with its own entitlements, service instances, application subscriptions, runtime environments, and identity trust configuration. Subaccounts are the fundamental unit of cost tracking, security isolation, and application deployment.
A subaccount belongs to exactly one Global Account (optionally within a Directory) and is always created in a specific cloud region (e.g., ae1 for UAE or eu10 for AWS Frankfurt). The region is immutable once the subaccount is created.
Runtime environments (Cloud Foundry, Kyma, ABAP) are enabled per subaccount and provide the compute fabric for application deployment. Each subaccount can have one CF Org, one Kyma cluster, and one ABAP system — never more.
Quick Facts
- Parent
- Global Account (or Directory)
- Region
- Fixed at creation (immutable)
- CF Orgs
- Max 1 per subaccount
- Kyma Clusters
- Max 1 per subaccount
- ABAP Systems
- Max 1 per subaccount
- Trust Config
- Subaccount-level (can differ from GA)
- Cost Unit
- Billing reported per subaccount
- Subdomain
- Unique per global account
Runtime Environments
- One CF Org per subaccount
- Multiple Spaces within the CF Org
- Buildpack-based PaaS (Node.js, Java, Python)
- SAP HANA HDI container bindings
- Managed service instances via CF marketplace
- Deploy via cf CLI, MTA, or CI/CD pipeline
- Memory quota allocated at subaccount level
- One Kyma cluster per subaccount
- Managed Kubernetes with SAP extensions
- Full container workload support
- Serverless Functions (Node.js, Python)
- ServiceInstance CRDs for BTP service consumption
- Istio service mesh included
- Best for microservice architectures
- One ABAP system per subaccount
- Full ABAP Cloud development (RAP, OData, CDS)
- ADT (Eclipse) as development IDE
- Released public APIs only — clean core compliant
- Supports SAP Build Apps integration
- Shared tenancy or dedicated options available
- ABAP compute units-based pricing
Naming Convention & Labels
1# Subaccount naming convention: {company}-{domain}-{env}
2#
3# DEWA BTP Subaccount Names:
4# ─────────────────────────────────────────
5dewa-s4ext-dev # S/4 Extensions — Development (eu10)
6dewa-s4ext-tst # S/4 Extensions — Test (eu10)
7dewa-s4ext-prd # S/4 Extensions — Production (ae1 / UAE)
8
9dewa-integ-dev # Integration Suite — Development
10dewa-integ-prd # Integration Suite — Production
11
12dewa-ai-dev # AI Services — Development (eu10)
13dewa-ai-prd # AI Services — Production (ae1 / UAE)
14
15dewa-smart-dev # Smart City Platform — Development
16dewa-smart-prd # Smart City Platform — Production
17
18# Required labels on every subaccount:
19# environment: dev | tst | prd
20# cost_center: DEWA-BTP-01 (finance cost center code)
21# owner: platform-team@dewa.gov.ae
22# product: s4ext | integration | ai | smartcityEnterprise Example — DEWA
DEWA — 12 Subaccounts across 4 Domains
Dubai Electricity and Water Authority (DEWA) maintains 12 subaccounts — 3 per major product line (S/4 Extensions, Integration, AI Services, Smart City). Each has fully isolated HANA Cloud, connectivity, and user trust configurations. Production subaccounts use region ae1 (AWS UAE) for UAE data residency compliance; development uses eu10 for cost efficiency.
| Subaccount | Domain | Runtime | Region | Key Services |
|---|---|---|---|---|
| dewa-s4ext-dev | S/4 Extensions | CF + Kyma | eu10 | HANA Cloud, BAS |
| dewa-s4ext-prd | S/4 Extensions | CF + Kyma | ae1 | HANA Cloud, Connectivity |
| dewa-integ-dev | Integration | CF | eu10 | Integration Suite |
| dewa-integ-prd | Integration | CF | ae1 | Integration Suite |
| dewa-ai-dev | AI Services | CF + Kyma | eu10 | AI Core (free), HANA Cloud |
| dewa-ai-prd | AI Services | CF + Kyma | ae1 | AI Core, Gen AI Hub |
Provisioning via btp CLI
1# Create a new subaccount
2btp create accounts/subaccount --display-name "dewa-s4ext-prd" --subdomain "dewa-s4ext-prd" --region "ae1" --description "S/4HANA Extensions - Production" --used-for-production true
3
4# Add labels to a subaccount
5btp update accounts/subaccount <subaccount-id> --labels '{"environment":["prd"],"cost_center":["DEWA-BTP-01"],"owner":["platform-team@dewa.gov.ae"]}'
6
7# Enable Cloud Foundry environment in a subaccount
8btp create accounts/environment-instance --subaccount <subaccount-id> --environment cloudfoundry --service cloudfoundry --plan standard --parameters '{"instance_name":"dewa-s4ext-prd"}'
9
10# Configure trust to IAS in a subaccount
11btp create security/trust --subaccount <subaccount-id> --idp <ias-tenant>.accounts.ondemand.comBest Practices
Never mix DEV and PROD in the same subaccount. Isolation boundaries, entitlements, and trust configurations must be independent per environment.
Within a CF Org, create separate spaces for different apps or teams. CF space-level roles restrict developer access to specific application sets.
Labels (environment, cost_center, owner, product) must be applied at subaccount creation — retrofitting them across 20+ subaccounts is painful.
Each subaccount should point to IAS for trust. This allows environment-specific authentication policies (e.g., stricter MFA for production).
Default CF memory quota is often too small for production CAP apps. Size based on profiling, not defaults — over-provisioning wastes CPEA credits.
Use Space Developer / Space Manager roles to limit which users can deploy to production spaces. Never give all developers SpaceDeveloper in production.