Your SAP Data, Your Cloud, Your Boundary: What Enterprise-Grade Deployment Really Means
Onibex Team
Last updated: July 2026
SAP data is the most sensitive data an enterprise owns — customers, prices, payroll, financials. Before any conversation about streaming speed or connectors, the deciding question is: where does the integration platform live, and who controls its boundary? The enterprise-grade answer is a pipeline deployed inside your own cloud account (Bring Your Own Cloud) or in a dedicated, isolated environment — never in shared infrastructure mixed with other companies' data flows.
The 3 key points:
- Deployment model is the first security decision — BYOC keeps SAP data inside your cloud boundary, making sovereignty an architectural guarantee, not a contractual clause
- Credential architecture predicts breach exposure — demand just-in-time injection from cloud-native secret stores, never an application database
- Cloud portability is negotiating leverage — a deploy-anywhere platform keeps every future cloud decision yours to make
What is the real question behind SAP-to-cloud integration?
The stated question is usually "can it move our data fast enough?" The questions that actually decide the outcome — in security review, in the audit, in year three of operation — are different, and they are about control, not speed.
- Where does our SAP data physically flow, and does it ever transit someone else's environment?
- If something fails, what else goes down with it?
- Where do the credentials to our SAP system, our Kafka cluster, and our Snowflake account actually live?
- If we change cloud providers — or get acquired by someone who has — what do we rewrite?
These are not technical details. They are the difference between a platform your organization compounds value on and one it spends years working around.
Where should the pipeline run — your cloud or shared infrastructure?
Inside an environment that is exclusively yours. This is where enterprise-grade platforms separate themselves from multi-tenant SaaS tools. OneConnect offers two deployment models, and in both, your pipeline is exclusively yours.
Bring Your Own Cloud (BYOC)
The entire integration stack — Smart Gateway, streaming layer, connectors — is deployed inside your own cloud account (AWS, Azure, Google Cloud, or SAP BTP). Onibex delivers and configures it; you own and govern the infrastructure. SAP connects to the gateway through private routing (for example, an AWS Transit Gateway into your own VPC), and processed data reaches your target platform via private connectivity such as AWS PrivateLink.
The consequence, stated plainly: your SAP data never leaves your cloud boundary. Not during extraction, not during transformation, not in transit to your warehouse. For regulated industries or data-sovereignty requirements, BYOC is not a preference — it's the only acceptable answer.
Dedicated hosted environment
For enterprises that prefer not to operate the infrastructure, Onibex hosts the stack — but in an isolated environment dedicated to your company, with private connectivity options (site-to-site VPN, Transit Gateway for SAP RISE customers, TLS-enforced connections from SAP). Your data flows are never mixed with another customer's runtime.
| Multi-tenant SaaS tools | OneConnect (BYOC / dedicated) | |
|---|---|---|
| Where your data flows | Through shared vendor infrastructure | Inside your cloud, or your dedicated environment |
| Who else runs on your runtime | Other customers | Nobody |
| Data sovereignty | Contractual promise | Architectural guarantee |
| Failure blast radius | Any customer can affect you | Contained to your environment |
| Security review | Vendor questionnaire | Your own cloud controls apply directly |
That last row matters more than it looks: with BYOC, your existing cloud security posture — IAM, network policies, monitoring, compliance certifications — applies directly to the pipeline, because the pipeline is just another workload in your account.
How does isolation work inside the deployment?
Isolation doesn't stop at the company boundary. Within your deployment, each workspace — typically one per SAP environment (development, quality, production) or per business unit — runs its own isolated integration runtime, provisioned automatically on Kubernetes.
- A test workspace can never disturb production. Experiments in QA don't touch the runtime feeding your executive dashboards.
- Upgrades roll out gradually, workspace by workspace, instead of big-bang maintenance windows.
- Each workspace scales to its own load — a heavy initial load in one SAP environment doesn't starve the others.
Resilience is layered on top: the gateway runs across multiple availability zones behind load balancing, and the SAP side supports automatic failover between primary and secondary endpoints — if one gateway endpoint becomes unavailable, SAP redirects transmissions automatically and returns when it recovers, with no manual intervention.
Where should integration credentials live?
Never in the application layer. Every integration platform needs credentials — to SAP, to Kafka, to Databricks or Snowflake. In far too many tools, the answer is a configuration database readable by anyone with application access. That is a breach headline waiting for a date.
The pattern to demand — and the one OneConnect implements: secrets are held in the cloud platform's native secret store — encrypted, access-controlled by the infrastructure itself — and injected into data flows just-in-time, only at the moment they're needed. The platform's database stores references, never keys. Delivery into target platforms uses OAuth 2.0 with automatic token refresh — no long-lived static credentials.
- Rotation without disruption — rotate centrally; flows pick up new secrets automatically.
- No credential sprawl — one governed place where secrets live, not configs and spreadsheets.
- Least privilege by design — each workspace can only access its own secrets.
How fast do you find out something broke?
A nightly batch job that fails is discovered in the morning and rerun. A real-time stream that silently degrades feeds wrong numbers into live operational decisions until someone notices. That makes observability a business control, not an engineering luxury.
OneConnect ships it built-in: a visual dashboard with live topic status and metrics refreshing every 10 seconds, a dedicated errors-and-warnings view with proactive email alerting per workspace, searchable and downloadable logs for audit, and OpenTelemetry support — telemetry flows into whatever observability stack you already run (Dynatrace, Datadog, Grafana) instead of creating another monitoring silo.
What does a cloud migration cost with this platform in place?
Every cloud commitment made today will be renegotiated within five years. Mergers, pricing changes, data-sovereignty regulation, and AI-driven workload shifts all reopen the "which cloud" question. An integration platform hard-wired to one hyperscaler converts each of those events into a re-implementation project.
OneConnect is Kubernetes-native and cloud-agnostic: the same deployment package runs identically on AWS, Microsoft Azure, Google Cloud, and SAP BTP. The streaming layer is open-standard Apache Kafka, with Confluent Gold-Verified delivery into Databricks, Snowflake, and ClickHouse. Because you can own the deployment (BYOC), a future cloud migration means redeploying the same package in the new account and repointing SAP — not re-architecting your integration layer.
| Evaluation question | The enterprise-grade answer |
|---|---|
| Can this run entirely inside our own cloud account? | Yes — BYOC, or a dedicated hosted environment |
| Does our data transit shared infrastructure? | No, by architecture |
| Where are credentials stored? | Cloud-native secret store, just-in-time injection |
| How do we find out something broke? | Built-in alerting, unified logs, OpenTelemetry export |
| Is the SAP-side component verified by SAP? | Yes — SAP-verified, distributed through the SAP Store |
Key takeaways
- Deployment model is the first security decision. BYOC keeps SAP data inside your cloud boundary — sovereignty as an architectural guarantee, not a contractual clause.
- Nothing shared, ever. Whether in your cloud or Onibex-hosted, your pipeline runs in an environment dedicated to your company.
- Isolation continues inside the deployment — per-environment workspaces, multi-AZ resilience, and automatic SAP-side failover protect production from everything else.
- Credential architecture predicts breach exposure. Demand just-in-time injection from cloud-native secret stores.
- Cloud portability is negotiating leverage. A deploy-anywhere platform keeps every future cloud decision yours to make.
Frequently asked questions
Where does OneConnect run — in the vendor's cloud or the customer's?
Both models are available, and in both the environment is exclusively the customer's. With BYOC, the entire stack runs inside the customer's own AWS, Azure, Google Cloud, or SAP BTP account, and data never leaves their cloud boundary. Alternatively, Onibex hosts the stack in a dedicated, isolated environment per customer.
Does OneConnect mix data flows from different companies in shared infrastructure?
No. Production deployments are single-company by design — either in the customer's cloud or in a dedicated hosted environment with private connectivity options.
How does SAP connect to the Smart Gateway securely?
Through SAP-standard HTTP RFC destinations over HTTPS/TLS, with private routing options such as AWS Transit Gateway (including SAP RISE scenarios) and site-to-site VPN, plus automatic failover between primary and secondary endpoints.
How does OneConnect handle security credentials?
Secrets live exclusively in the cloud platform's native secret store and are injected just-in-time into data flows; the application layer stores only references. Target-platform authentication uses OAuth 2.0 with automatic token refresh.
Is OneConnect tied to a specific cloud provider?
No. The same package deploys on AWS, Azure, Google Cloud, and SAP BTP, with Confluent Gold-Verified delivery into Databricks, Snowflake, and ClickHouse.
If you are evaluating SAP-to-cloud integration and want to test it against your own SAP landscape in under two business days, ask about the 15-Hour Business Value Challenge: onibex.com