What is the difference between on demand compute and cloud integrations in serverless architectures?

On demand compute is the ability to upload code and have the provider run it only when needed. Cloud integrations are the surrounding services that connect the function to logs, events, gateways, and other managed components. The first is the execution model, while the second is what makes serverless practical, but also more dependent on provider specific services.

Execution Model Versus Service Integration in Serverless

On demand compute is the core runtime model, you submit code and the provider executes it only when an event or request arrives. Cloud integrations are the supporting services and connectors around that runtime, such as event sources, API gateways, logging, queues, storage triggers, and identity or configuration plumbing that make the function usable in a larger system.

The practical difference is scope: on demand compute answers “where does my code run?”, while cloud integrations answer “how does that code fit into the rest of the platform?”. That distinction matters because serverless is not just a function runtime, it is a composition model built from many managed services with different trust boundaries and failure modes.

What Changes Operationally When You Add Cloud Integrations

On demand compute can be portable in concept, but once you connect it to managed events, data stores, queues, and gateways, your design becomes more opinionated and provider-specific. The integration layer usually carries the real operational complexity, including retries, payload shaping, throttling behavior, permissions, and how observability data is emitted and correlated.

That means a serverless architecture is often easiest to evaluate by separating execution concerns from integration concerns. The function may be small and stateless, but the surrounding services define latency, coupling, blast radius, and how easily you can move or replatform the workload.

A useful way to think about this is that on demand compute is the execution substrate, while cloud integrations are the system choreography. The more event sources and managed connectors you add, the more your architecture depends on provider conventions, service limits, and IAM relationships between the components.

Why the Difference Matters for Portability, Lock-In, and Control

Serverless portability is usually limited less by the function code itself and more by the integration surface around it. A simple function can be redeployed elsewhere with modest effort, but a function tightly bound to proprietary event buses, identity models, logging pipelines, and managed triggers is harder to transplant without redesign.

That is why teams should distinguish between “compute portability” and “platform portability”. The first is about moving code, the second is about moving an operating model. In practice, the second is much harder because integrations encode assumptions about how the platform authenticates services, routes events, and exposes operational telemetry.

Cloud integrations also expand the control surface. They improve speed and reliability when used well, but they can create hidden coupling if teams treat every managed connector as interchangeable. The architecture becomes more dependent on the provider’s service catalogue, which is the trade-off for reduced infrastructure management.

Risk and Threat Considerations

Serverless integrations increase the number of trust boundaries a workload depends on, so the main risk is not the function runtime itself but the permissions, event paths, and managed services around it. Weak integration design can expose data, over-expand privileges, or create brittle dependencies that fail under load or during provider-side changes.

Failure mechanism: Misconfigured triggers, overly broad service permissions, or insecure event handling can let an event source invoke the wrong function, pass untrusted payloads, or reach downstream services the function should not control.

Impact: The result can be unauthorized access, data exposure, poisoned workflows, noisy retries, or a larger blast radius than the function code alone would suggest. In serverless systems, the integration layer is often where operational failure becomes security failure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA-05 — Least Privilege	Serverless integrations depend on tightly scoped service permissions.
Recommendation — Limit each integration path to the minimum access required.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Managed connectors and triggers should not have broad downstream access.
Recommendation — Restrict service and function permissions to the minimum necessary.
ISO/IEC 27001:2022	A.5.15 — Access control	Serverless integration points are governed by access relationships between services.
Recommendation — Define and enforce access rules for each integration boundary.
OWASP API Security Top 10	API5 — Broken Function Level Authorization	Serverless gateways and function endpoints can expose unauthorized actions.
Recommendation — Authorize each function action explicitly before execution.
CIS Controls v8	CIS-6 — Access Control Management	Cloud integrations rely on controlling who and what can invoke services.
Recommendation — Remove unused access paths and review service permissions regularly.

Practitioner Guidance

What to verify: Review the function separately from each integration. Confirm which service invokes it, what identity or permission path that invocation uses, what data the event can carry, and whether the function has only the downstream access it truly needs.

Decision rule: If a change affects only the function body, treat it as an execution concern. If it changes event sources, gateway behavior, logs, queues, storage triggers, or permissions between services, treat it as an architecture and control change, because those dependencies usually define the real risk surface.

What good looks like: The compute unit remains small and isolated, while integrations are explicit, documented, and least-privileged. Teams can explain which managed services are required, which failures are tolerable, and which dependencies would need redesign before migration.

Practitioner takeaway: In serverless, the function is the visible unit of code, but the integrations are the real system. Evaluate portability, security, and operational resilience at the boundary between them, not just inside the runtime.