Direct answer

Run a function at the edge when it must remain safe, timely, or useful during a cloud or WAN outage. Run it in the cloud when it benefits more from fleet-wide data, elastic compute, centralized governance, or frequent iteration than from local autonomy. Most production systems need both: cloud services distribute policy and coordinate the fleet, while edge components enforce bounded decisions close to the physical process.

Do not make the decision for an entire product at once. Place each function—sampling, filtering, inference, command arbitration, storage, reporting, and model training—against an explicit latency budget and failure domain. “Edge versus cloud” is an allocation problem, not a platform identity.

Scope and non-scope

This guide covers application and data-processing placement across a device, on-site gateway, regional service, and central cloud. It applies to telemetry pipelines, industrial gateways, local inference, and device control.

It does not replace a machinery risk assessment, functional-safety design, or real-time control analysis. A general-purpose gateway is not automatically a safety controller. Hard real-time loops and certified protective functions belong on equipment designed and validated for those duties. This guide also does not prescribe one edge runtime, cloud provider, or protocol.

Decide from constraints, not fashion

Start with the end-to-end latency budget. Include sensor acquisition, batching, serialization, network transit, queueing, processing, command delivery, and actuator response. If a ventilation controller must react within 200 milliseconds, a cloud function with a 50-millisecond median request time may still be unsuitable because the tail latency and outage behavior violate the actual requirement.

Next, define offline behavior. Ask what happens after five seconds, five minutes, and five days without the cloud. A local process may need to hold its last safe policy, reject new remote commands, continue a reduced operating mode, and buffer bounded telemetry. “The network is reliable” is not an offline design.

Use data gravity and bandwidth as separate criteria. Filtering vibration samples locally can dramatically reduce upstream traffic, but discarding raw data may prevent later diagnosis. A useful pattern is to compute continuous features at the edge, retain a short local raw-data ring buffer, and upload the relevant window when an anomaly occurs.

Finally, price operational ownership. Every edge workload creates a distributed software fleet: it needs identity, configuration, health reporting, staged updates, rollback, storage limits, and recovery after power loss. Moving code to the edge can reduce cloud cost while increasing field-support cost.

Function Usual placement Reason
Protective interlock Dedicated local controller Must not depend on WAN or cloud availability
Fast closed-loop control Device or local controller Deterministic response and direct I/O
Protocol normalization Gateway Close to legacy equipment and site context
Fleet policy authoring Cloud One governed source for many sites
Policy enforcement Edge Continues through disconnection
Cross-site analytics and training Cloud Needs broad data and elastic compute
Operator dashboard Cloud with local fallback where required Central access, with explicit degraded mode

A placement method that survives review

  1. Inventory functions at a useful granularity. “Analytics” is too broad; separate capture, feature extraction, inference, alerting, and retraining.
  2. Record the function’s input, output, state, latency target, data volume, and consequence of delay or loss.
  3. Assign its failure domain. State what must happen if the device, gateway, site network, regional service, or central cloud fails.
  4. Choose the narrowest local responsibility that satisfies the requirement. Keep fleet-wide coordination and expensive learning centralized unless a constraint says otherwise.
  5. Define synchronization semantics. Policies and models need versions, activation conditions, expiry, compatibility rules, and a known-good rollback target.
  6. Design bounded local state. Set limits for queues, raw-data buffers, logs, and cached configuration, including the policy when each limit is reached.
  7. Test the boundary with real fault injection: WAN loss, DNS failure, high latency, stale policy, power interruption, disk exhaustion, and an interrupted update.

For every cloud-issued command, distinguish authorization from execution. The cloud may authorize a target state, but the edge should validate freshness, local preconditions, parameter bounds, and interlocks immediately before acting. Return accepted, rejected, started, and completed outcomes as distinct states.

Failure modes to design out

The most dangerous boundary is hidden dependency. A “local” workflow may still call cloud DNS, fetch a token, or wait for remote logging before completing. Exercise it with the WAN physically blocked and verify the promised local behavior.

Stale state is another common failure. An edge node can remain online while using an obsolete model or policy. Version every deployable artifact, report the active version, set expiry where stale operation is unsafe, and define whether expiry means hold, degrade, or stop.

Unbounded buffering turns a network outage into a disk outage. Choose whether to drop oldest telemetry, drop newest data, aggregate samples, or stop collection; the correct answer depends on audit and recovery needs. Reconnection can also flood the cloud, so drain backlogs with quotas and jitter rather than at line rate.

Model or rule divergence across gateways makes incidents difficult to reproduce. Keep signed artifacts, deterministic configuration, deployment cohorts, and an audit trail that links an output to the code, model, policy, and input versions that produced it.

Implementation checklist

  • Each function has a measured latency budget and named owner.
  • Cloud loss cannot bypass local safety controls.
  • Offline behavior is specified for short and extended outages.
  • Edge queues, caches, and raw-data buffers have enforced limits.
  • Policies and models are versioned, authenticated, observable, and reversible.
  • Commands carry identity, expiry, bounds, and outcome reporting.
  • Backlog recovery is rate-limited and tested at fleet scale.
  • Fault tests cover WAN loss, stale configuration, power loss, and full storage.

Primary sources

The NIST IoT device cybersecurity capability core baseline defines device capabilities such as secure configuration, data protection, logical access control, software update, and cybersecurity-state awareness that remain relevant when workloads move to the edge. For standardized edge terminology and use cases, use ISO/IEC TR 30164:2020. Apply those baselines alongside the safety and real-time standards governing the actual equipment; a placement diagram alone does not establish safe operation.