Cloud Integration Architecture

The cloud providers have spent the last five years building integration services. Azure has Logic Apps, Service Bus, Event Grid, Event Hub, Data Factory, and API Management; AWS has EventBridge, Step Functions, AppFlow, Glue, and API Gateway; GCP has Workflows, Pub/Sub, Dataflow, and Apigee. These services have matured to the point where they compete credibly with traditional iPaaS platforms for many workloads.

The strategic question for enterprise architecture is no longer "should we use cloud integration." The question is which workloads belong on cloud-native integration services, which belong on a dedicated integration platform (webMethods, MuleSoft, Boomi), and how to architect the boundary between them.

This piece is the framework we use to make those decisions.

What cloud integration services do well

The cloud-native integration services excel in specific shapes:

Event-driven architectures at scale. EventBridge, Event Hub, and Pub/Sub handle high-volume event distribution with operational characteristics (durability, replay, ordering, partitioning) that dedicated integration platforms cannot match cost-effectively. For workloads where events are the unit of work, cloud-native is the right substrate.

Cloud-to-cloud integration. When both endpoints are in the same cloud, the cloud's native integration services have privileged network paths, fine-grained IAM integration, and operational tooling that an external integration platform cannot replicate. The integration is faster, cheaper, and more observable.

Serverless workflow orchestration. Step Functions, Logic Apps, and Workflows excel at ephemeral, low-volume orchestration tasks where the cost model (per-execution) is favourable and the operational story (zero infrastructure) is compelling.

Data movement and ETL. Data Factory, Glue, and Dataflow handle large-scale data movement with serverless scale, native integration with object storage and analytical databases, and tooling that data engineering teams expect.

API gateway for cloud-deployed APIs. API Management, AWS API Gateway, and Apigee provide the gateway layer for APIs running in their respective clouds with native integration to the cloud's identity, security, and observability stacks.

What dedicated iPaaS still does better

Dedicated integration platforms remain the right choice for a different set of workloads:

Enterprise B2B and EDI. Trading networks, partner onboarding workflows, document mapping libraries, EDI compliance — these are the home ground of webMethods Trading Networks, Boomi B2B, MuleSoft Partner Manager. Cloud-native services do not have equivalent tooling, and building it on cloud primitives is expensive.

On-premises integration. When endpoints are on-premises (legacy systems, ERP, mainframe), a dedicated integration platform with a hybrid topology handles the on-prem side natively. Cloud-native services require a data gateway or VPN extension that adds operational complexity.

Mixed-cloud integration estates. Organisations that operate across Azure and AWS, or across cloud and on-prem, often find that a cloud-agnostic iPaaS is operationally simpler than maintaining cloud-specific integration patterns in each cloud.

Long-tail mediation requirements. The accumulated mediation primitives in mature iPaaS platforms — pre-built connectors for hundreds of SaaS systems, sophisticated transformation tooling, partner-specific patterns — are not yet matched by cloud-native services for breadth.

Mature integration governance estates. Organisations with established integration governance (a Centre of Excellence, naming conventions, common services libraries) often find that migrating to cloud-native disrupts the governance discipline they have built around their iPaaS.

The hybrid pattern that works

Most enterprise estates that have evaluated cloud integration honestly end up in a hybrid pattern: dedicated iPaaS for B2B, on-premises, and mature governed integration workloads; cloud-native integration services for event-driven, cloud-to-cloud, serverless orchestration, and data movement.

The boundary that makes this work:

The iPaaS owns the cross-platform integration. When an integration spans cloud and on-prem, or spans clouds, the iPaaS is the orchestrator. The cloud-native services handle the cloud-internal portions; the iPaaS bridges across.

Cloud-native services handle cloud-internal traffic. Events flowing between two AWS services should go through EventBridge, not through an iPaaS in another cloud. Latency, cost, and operational simplicity all favour the cloud-native path.

The iPaaS receives events at the boundary. When a cloud-native event stream needs to interact with on-prem systems or partner systems, the iPaaS consumes from the cloud broker and handles the integration. The cloud-native services do not reach across the boundary directly.

API gateway placement is workload-specific. Cloud-deployed APIs use the cloud's API gateway. APIs that span clouds or that need consistent governance across cloud and on-prem use a dedicated API gateway, often as a layer above the cloud gateways.

This hybrid pattern is the steady state for most regulated enterprises with significant on-premises footprints. The pure cloud-native answer applies to younger organisations or to specific workloads within larger ones.

Cost considerations

Cloud integration services price differently from iPaaS:

• iPaaS is typically licensed per runtime, per connection, or per transaction tier
• Cloud integration is typically priced per execution, per event, per data volume, or per request

For high-volume steady-state workloads, the per-execution pricing of cloud services can be more expensive than the licensed-runtime pricing of iPaaS. For variable-load workloads, the cloud's elasticity is more cost-effective.

The cost analysis that holds up:

• Model the workload's actual transaction profile (peak vs average, total volume)
• Apply both pricing models against the profile
• Account for operational cost (which platform is your team's expertise on; which requires hiring)
• Account for migration cost if switching

We have seen organisations migrate workloads to cloud integration expecting cost savings and ending up paying more because the transaction volume was higher than the elastic pricing favoured. We have seen others stay on iPaaS for cost reasons when migration would have been cheaper. Honest modelling beats general assumption.

Operational maturity differences

A mature iPaaS estate has established operational practices: how integrations are tested, monitored, deployed, governed. A cloud integration estate often does not have those practices yet — the team is learning the platform alongside operating it.

The risks of moving workloads to cloud integration before operational maturity:

• Deployment automation may be immature; manual deployment becomes the default
• Observability may be fragmented across cloud-native tools that aren't integrated with the broader observability stack
• Testing practices for cloud-native event-driven flows are different from request-response flows; the team may not have the patterns yet
• Incident response across cloud-native services requires understanding the cloud provider's failure modes, which takes operational time to learn

Estates that bring cloud integration in without operational maturity often experience an "incident-rich" first year. Estates that invest in operational maturity before scaling cloud integration usage navigate the adoption more smoothly.

What we recommend

For an enterprise estate evaluating cloud integration:

1. Identify the workload classes honestly. Where is cloud-native genuinely better? Where is iPaaS genuinely better?
2. Adopt the hybrid pattern. Cloud-native for cloud-internal, iPaaS for cross-platform. Boundary explicit, not blurry.
3. Invest in operational maturity for cloud integration. Deployment, observability, testing, incident response. Treat these as Day-1 work, not Day-30 enhancements.
4. Model cost against actual workload profiles. Not against vendor marketing or industry analyst reports.
5. Maintain integration governance across both platforms. The integration Centre of Excellence should cover both iPaaS and cloud-native, with consistent standards.

For an organisation already running cloud integration:

1. Audit which workloads are cloud-native by default and which are cloud-native by accident. The accidental ones often belong elsewhere.
2. Audit the operational practices. Are deployment, observability, testing, incident response mature on the cloud-native side?
3. Verify the cost picture against the original assumption. If cost is higher than expected, the workload mix may need adjustment.

Cloud integration has matured significantly. For specific workload shapes — event-driven, cloud-internal, serverless orchestration, data movement — it is the right answer. For others, dedicated iPaaS remains stronger. The architectural skill is in placing workloads correctly, not in declaring allegiance to one model.