When Both Ends Are Cloud but Your Data Can't Touch the Internet: Architecting Secure SaaS-to-SaaS Integration with Workato ☁️🔒

A deep dive into architecture patterns, best practices, and implementation strategies for enterprise-grade integration using Workato's On-Prem Agent.

There's a common assumption in the integration world: if your source and target are both SaaS applications, the integration should be straightforward — cloud-to-cloud, no fuss. But what happens when your enterprise cybersecurity policy mandates that no data can traverse the public internet, even between two cloud-native platforms?

This is exactly the scenario I recently worked through with a global manufacturing customer integrating SAP Rise with Reltio MDM — both SaaS, both cloud-hosted, and yet the data path between them needed to stay entirely within a private network backbone. The solution? Workato's On-Prem Agent (OPA) deployed inside the customer's secure Azure VNet, connected via Azure ExpressRoute and Private Link.

In this article, I'll walk you through the use case, the architecture decisions we made, and the best practices that emerged — with the hope that it saves you time and missteps on similar projects.

The Use Case: MDM Integration in a Zero-Trust Enterprise

The Players:

• SAP Rise — the system of record for Customer Master and Vendor Master data, hosted on Azure
• Reltio MDM — the master data management platform responsible for golden record creation, hosted on AWS
• Workato (Embedded via Reltio Integration Hub) — the integration engine, operating as Reltio's embedded iPaaS

The Constraint: The customer operates under strict cybersecurity policies mandating that all data flows remain within private cloud backbones — no public internet traversal, period. They use Azure ExpressRoute to maintain a private connection between their on-premises infrastructure and Azure, and demand the same level of control for SaaS-to-SaaS data movement.

The Volume: Millions of master data records for the initial load, followed by ongoing real-time change data capture (CDC) for transactional updates.

Why Use an On-Prem Agent When Everything Is SaaS?

This is the question that trips up most architects. The conventional wisdom says: cloud source + cloud target = cloud agent. And in most cases, that's right — it minimises infrastructure overhead and simplifies operations.

But conventional wisdom doesn't account for zero-trust network policies. Here's the decision framework:

Use a Cloud Agent when:

• Both source and target accept connections over the public internet (with TLS)
• No regulatory or policy mandate restricts data path
• You want the simplest possible deployment

Use an On-Prem Agent (OPA) when:

• Data must not traverse the public internet — even between SaaS platforms
• The customer maintains a private backbone (ExpressRoute, Direct Connect)
• Strict egress control and IP filtering are required
• The OPA can be deployed inside a secure VNet/VPC that has private connectivity to both endpoints

In our customer's architecture, the OPA sits inside an Azure VNet that connects to SAP Rise via ExpressRoute and to Workato's cloud platform via Azure Private Link. The OPA communicates with Reltio over a private AWS-to-AWS path. At no point does master data leave a private network backbone.

Architecture Pattern: The Secure SaaS-to-SaaS Bridge

Key Architectural principle: The OPA initiates a persistent outbound-only WebSocket (WSS) connection to Workato's cloud over port 443. No inbound firewall ports need to be opened. This is critical for enterprise security teams — the OPA only talks outward, and Workato manages the orchestration queue from its side

Best Practices: Lessons from the Field

1. Right-Size Your OPA Infrastructure — Then Scale Horizontally

Minimum (dev/test): 2 CPUs, 4 GB RAM Production (high volume): 4 CPUs, 8 GB+ RAM per agent

There's no universal sizing calculator because memory consumption depends on recipe design — payload sizes, batch dimensions, in-memory transformations. The rule of thumb: scale out, not up. Deploy multiple OPAs in an Agent Group for high availability and load distribution.

Workato handles load balancing natively on the backend. Workload distributes evenly across all agents in a group, and if one agent fails, others pick up from the cloud queue. No F5, no NGINX, no customer-side load balancer configuration needed — just install multiple agents on separate VMs using the same setup key.

2. Never Join Large Datasets in the Integration Layer

This is the single most common performance anti-pattern I see. Workato processes data in-memory on the agent. Attempting to join two 50,000+ row arrays inside a recipe will consume massive RAM and can cause Out-Of-Memory (OOM) errors.

Instead, push the join down:

• To the source database: Use custom SQL queries in the connector to perform joins at the database level before data enters Workato.
• To a staging layer (ELT approach): Extract and load raw tables into a staging database (e.g., Oracle Stage, Snowflake), perform the join there, then push curated data to the target.

Think of Workato as an orchestration and transport layer, not a data processing engine. Heavy transformations belong in the systems designed for them.

3. Design Separate Pipelines for Bulk and Real-Time

Don't try to use the same recipe design for your initial load and your ongoing sync. These are fundamentally different workloads:

Initial/Bulk Load:

• Use bulk triggers and actions with pagination (e.g., 10,000 records per page)
• Write in bulk to the target API
• Minimise in-flight transformations — do heavy logic pre- or post-load
• Scale horizontally with more agents in the group

Transactional/CDC Load:

• Use SAP's IDoc push mechanism — the OPA acts as an RFC Server, receiving IDocs in real-time
• For high volumes, use the New IDocs Batch Trigger (up to 1,000 IDocs per job) to dramatically improve throughput
• Workato handles IDoc deduplication natively

4. Lock Down Network Security Without Compromising Function

Enterprise security teams often push back on integration platforms because they fear open ports and uncontrolled egress. Workato's OPA architecture addresses this elegantly:

• No inbound ports required: The OPA initiates all connections outbound
• Egress control: Restrict the OPA server to only allow outbound traffic to specific Workato IP addresses and domains
• Private Link support: Both Azure Private Link and AWS PrivateLink are supported, keeping all traffic on the cloud provider's private network
• TLS 1.2 minimum: All transport is encrypted with HTTPS/SSL

This gives the security team a tight, auditable perimeter: outbound-only, to known IPs, over private links, with encrypted transport.

Similar Scenarios Where This Pattern Applies

This architecture isn't unique to SAP + Reltio. The same pattern — OPA in a secure VNet bridging two SaaS platforms over a private backbone — applies whenever you encounter:

• Financial services integrating Salesforce with a cloud ERP where PCI-DSS mandates private data paths
• Healthcare connecting cloud EMR systems with SaaS analytics platforms under HIPAA network segmentation rules
• Manufacturing (like this usecase) bridging SAP Rise with cloud MDM platforms under industrial cybersecurity standards (IEC 62443)
• Government/defense contractors integrating any two FedRAMP-authorized SaaS platforms where data sovereignty requires no public internet transit

The pattern generalises: whenever compliance or policy demands private-only data paths between cloud-native systems, the OPA + Private Link architecture is your go-to.

Implementation Strategy: A Phased Approach

For teams embarking on a similar project, here's the phased rollout I recommend:

Phase 1 — Foundation (Weeks 1–3)

• Deploy OPA agents (minimum 2) in the customer's secure VNet
• Configure Agent Group for HA
• Establish Private Link connectivity to Workato cloud
• Validate outbound-only firewall rules and TLS transport

Phase 2 — Initial Load (Weeks 4–6)

• Build bulk extraction recipes with pagination from SAP Rise
• Stage data if complex joins are required (ELT pattern)
• Run initial master data load to Reltio in controlled batches
• Monitor OPA resource utilization and scale agents as needed

Phase 3 — Real-Time Sync (Weeks 7–9)

• Configure SAP IDoc distribution to push changes to the OPA
• Build CDC recipes using the New IDoc trigger
• Implement deduplication and error handling
• Validate end-to-end latency meets SLA

Phase 4 — Hardening (Weeks 10–12)

• Stress test with production-scale volumes
• Tune batch sizes and concurrency
• Document runbooks for OPA failover scenarios
• Hand off to operations with monitoring dashboards

Key Takeaways

1. Cloud-to-cloud doesn't always mean cloud agent. When security policies demand private data paths, the OPA + Private Link pattern is not just acceptable — it's the recommended approach.
2. Scale horizontally, not vertically. Agent Groups with multiple OPAs give you HA, load distribution, and graceful failover without complex infrastructure.
3. Keep heavy processing out of the integration layer. Push joins and complex transformations to databases. Use Workato for orchestration and transport.
4. Separate your bulk and real-time pipelines. They have fundamentally different resource profiles and should be designed, scaled, and monitored independently.
5. The OPA's outbound-only architecture is a security feature, not a limitation. It gives enterprise security teams the tight perimeter they need without sacrificing integration capability.

The integration landscape is evolving. SaaS-to-SaaS is the norm, but "everything in the cloud" doesn't mean "everything over the public internet." Understanding when and how to deploy hybrid connectivity patterns — even between two cloud-native systems — is becoming a critical skill for integration architects.

I'd love to hear from others who've tackled similar challenges. What patterns have worked for you? Drop your thoughts in the comments.

#Workato #iPaaS #IntegrationArchitecture #MDM #SAPRise #Reltio #OnPremAgent #PrivateLink #CloudSecurity #EnterpriseIntegration #DataIntegration #BestPractices