Edge Computing Use Cases: Where Should Workloads Run?

Edge computing use cases are strongest when a workload needs a local response, must keep essential functions available during a connection outage, or would otherwise send more raw data than the network can reasonably handle. Choose device, gateway, nearby network infrastructure, cloud, or a hybrid design by testing those requirements against security, accuracy, power, and operating costs.

Edge describes where processing happens relative to the data or user. It is not a guarantee of instant response, offline operation, privacy, compliance, or business value. This guide compares practical workload patterns and provides a placement worksheet for evaluating a specific task.

Reviewed October 14, 2026. Examples are illustrative architecture patterns, not verified deployments by named vendors. No benchmark, market forecast, medical benefit, driving-safety claim, or guaranteed return on investment is asserted.

What counts as edge computing?

Processing can occur on a phone or sensor device, a local gateway, an on-site server, or nearby infrastructure operated by a network provider. The relevant distinction is proximity to a workload’s data, users, or physical process, not a single universal distance from a cloud data centre.

ETSI’s Multi-access Edge Computing work describes an environment that brings cloud-computing capabilities to the network edge. MEC is a particular network-oriented approach; not every smart-home hub or on-device model is a MEC deployment.

NIST’s 2018 Fog Computing Conceptual Model describes distributed processing and its relationship to cloud-based IoT models. Terminology can overlap across products, so ask where the task actually executes and which services it depends on.

Compare placement options before choosing a label

• Device: a task runs on the endpoint itself, with limits from its hardware, power, and software.
• Local gateway or site server: nearby equipment aggregates or processes data from several endpoints.
• Network edge: infrastructure close to users performs a task, while connectivity to that infrastructure still matters.
• Cloud: remote infrastructure handles processing, storage, fleet coordination, or training.
• Hybrid: different steps run in different places, with explicit data flows and failure behavior.

Our cloud-computing comparison offers related context. The decision is usually about placing individual functions, rather than moving an entire system to one location.

Eight practical edge computing use cases

1. Local equipment monitoring

A site gateway can inspect temperature or vibration readings and flag an unusual condition without uploading every raw sample immediately. Central infrastructure can still collect history and support longer-term analysis.

The value depends on sensor quality, a useful baseline, and an effective response process. Detecting an anomaly is not the same as predicting a failure. Test false alerts, missed events, and what operators do when a warning appears.

2. Camera-stream filtering

A local processor can select relevant frames or produce event metadata before data leaves a site. This may reduce transferred video and enable a local workflow, such as flagging a package in a monitored area.

Check accuracy under expected lighting and environmental conditions. A local model can still make errors, retain sensitive footage, or transmit identifiers. Define collection, retention, access, and review separately from the processing location.

3. Site operations with intermittent connectivity

A local system can queue permitted transactions or readings and synchronize later. For example, an illustrative remote facility could maintain a limited local task log while its external connection is unavailable.

Offline functionality must be designed and tested. Authentication, licences, clock synchronization, remote APIs, and later conflict resolution can remain dependencies. Define which operations are permitted while disconnected and which must stop safely.

4. Smart-home control

A hub or device can apply a local automation, such as reacting to a sensor within the home network. Remote notifications, voice interpretation, setup, or other functions may still use external services.

Check the exact feature rather than assuming “local” applies to the whole product. Test expected behavior during an internet outage, a local network outage, and a hub restart separately. A manufacturer’s documented function is not proof that every integration works offline.

5. On-device AI assistance

An endpoint can run a supported model for tasks such as classification or text assistance. Potential advantages include fewer remote requests and local responsiveness; limits include memory, battery use, model capability, and update requirements.

Some products use a mix of local and cloud processing. Confirm where each feature runs and what is transmitted. Our machine-learning guide explains related concepts; an on-device model can still produce inaccurate output.

6. Nearby content delivery

A cache closer to users can serve suitable content without repeatedly retrieving it from an origin. This is a distinct pattern from running a model on a phone, even though both may be described as edge services.

Check cacheability, freshness, invalidation, and access control. Dynamic or sensitive responses may require a different approach. The route used, cache availability, and network conditions determine performance, so proximity alone is not a benchmark.

7. Interactive rendering or sensor response

A task that must respond to local movement or input may benefit from device-side processing or nearby compute. The full path includes sensing, queues, processing, rendering, and any return communication.

Measure that full path under representative conditions. Moving one stage closer does not remove delays elsewhere. Safety-critical control requires specialist engineering and validation; this overview is not a design specification for vehicles, medical systems, or industrial protection.

8. Local data reduction and aggregation

A gateway can summarize readings or remove unnecessary fields before sending information onward. A hypothetical building-monitoring system might send periodic aggregates while keeping detailed samples for a limited local diagnostic period.

Check what useful information is lost, how exceptions are handled, and whether the aggregate can still identify people. Data minimization is a design choice, not an automatic consequence of running on-site.

Privacy and security do not improve automatically

Local processing can reduce some data transfers, but distributed equipment creates its own exposure: physical access, unpatched software, credentials spread across sites, and uncertain support lifetimes. A local copy of sensitive data still needs protection.

ETSI’s September 2022 MEC security overview discusses multi-stakeholder environments and end-to-end security considerations. Avoid presenting edge as inherently more secure than cloud without a threat model and evidence for the specific design.

NISTIR 8259A, published May 2020, identifies baseline IoT capabilities including device identification, configuration, data protection, interface access control, software updates, and cybersecurity-state awareness. Use that as a starting point for requirements, not a complete certification or compliance claim.

Document authorized administration, update verification, monitoring, and recovery. Plan for lost connectivity and expired credentials, then confirm the system’s behavior. Compliance depends on applicable obligations and the complete data lifecycle; choosing a local server does not establish it.

Run a bounded pilot and compare the result

Define a baseline before changing placement. Record the current delays, reliability, resource use, and operational effort under representative conditions. Then test the proposed design against the same task and conditions, including expected failures.

A fictional camera pilot might compare raw-data transfer, detection errors, and staff response time between local filtering and the current approach. Saving bandwidth is insufficient if missed events make the workflow unusable or support costs exceed the benefit.

Identify who can stop the pilot, what requires specialist review, and how rollback works. Use our decision-making toolkit to organize feasible trade-offs, and the evidence-checking worksheet to inspect a vendor’s claims.

Where 5G and AI fit

Connectivity and processing location are separate design choices. Edge systems can use wired networks, Wi-Fi, or cellular links. A 5G subscription does not prove a workload meets its latency requirement or has access to a nearby compute service. See our 5G guide for coverage and connectivity context.

AI adds questions about model quality, updates, and suitable review. Our large-language-model use cases distinguish application tasks; deciding to use AI and deciding where it executes are related but separate questions.

Frequently asked questions

Does edge computing replace cloud computing?

No. Many designs combine local response or filtering with central storage, coordination, or training. Place each function according to its requirements and dependencies.

Can every edge system work offline?

No. Some functions depend on remote authentication, APIs, licences, or synchronization. Test a defined outage scenario and document which features continue or stop.

Does edge automatically improve privacy?

No. Examine what is collected, retained, shared, and accessible. Local processing may reduce transfers while leaving sensitive information exposed elsewhere.

Is there a universal edge latency?

No. Delay depends on the complete processing path, load, network conditions, and implementation. Use an explicit task requirement and a representative measurement.

Do I need 5G for edge computing?

No. Device and site processing can use other connectivity. For a network-edge service, verify the actual connection and service arrangement required.

How should I compare costs?

Include deployment, support, power, monitoring, security maintenance, and replacement alongside compute and network charges. Compare the complete operating model with a baseline.

Sources and methodology

• ETSI: Multi-access Edge Computing.
• NIST SP 500-325, 2018: Fog Computing Conceptual Model.
• ETSI, September 2022: MEC security overview.
• NISTIR 8259A, May 2020: IoT Device Cybersecurity Capability Core Baseline.

The workload examples and placement worksheet are original illustrative adaptations. They support a requirements discussion and pilot plan; they do not substitute for specialist architecture, security, safety, or regulatory assessment.