Edge Computing Architecture: Types, Points of Presence & Terminology Explained

An edge computing architecture is the overall framework of components used to run computing across distributed locations: the devices that generate data, the edge servers that process it on site, the network that connects everything, and the central cloud that stores and coordinates. Edge computing is the practice. The edge computing architecture is the structure that makes it work at hundreds or thousands of locations. This article covers the components, the continuum running from centralized compute out to the physical world, what a single site actually contains, and how data and control move between the two ends.

If you need the underlying definition first, start with What Is Edge Computing. This page assumes that background and goes deeper into structure.

What Is Edge Computing Architecture?

An edge computing architecture is the arrangement of hardware, software, and network layers that allows data to be processed close to where it is created rather than in a central data center. It typically spans five layers: edge devices, edge servers, the network, and the central cloud or data center.

The distinction worth holding onto is this. Edge computing is the practice of processing data near its source. An edge computing architecture is the framework of components and layers that makes that practice work repeatably across many locations. One is a decision about where computation happens. The other is the design that has to survive diverse hardware, intermittent connectivity, and sites you cannot easily reach.

The Continuum From Cloud to Device

An edge architecture reads better as a continuum than as a set of boxes. There are four tiers, ordered from centralized compute out towards the physical world.

1. Cloud. Hyperscale and global data centers. Someone else’s hardware, effectively unlimited capacity, and the furthest point from the process being run.
2. Service provider edge. Compute a provider operates closer to you than a cloud region: telecom aggregation sites, hyperscalers’ local zones, provider edge locations, content delivery points. Still their hardware, and still on the far side of the last mile.
3. User edge. Compute inside your own premises, on your own network. A factory floor, a store back office, a substation. Your hardware, your power, your physical access, and after the last mile.
4. Device edge. The equipment itself: cameras, sensors, actuators, controllers. Often not a general-purpose computer at all, and frequently not something you can deploy software to.

What changes as you move along the continuum is ownership. At the cloud end you rent capacity and configure it through an API. In the middle you own the hardware and everything around it, including the parts that fail for physical reasons. At the device end you own equipment that was never designed to be a compute platform in the first place.

The vocabulary for these tiers is not standardized, and the same site gets described differently depending on who is writing. For the full set of competing definitions, see Types of Edge Computing.

Core Components of an Edge Architecture

Almost every edge deployment is assembled from the same five building blocks, in different proportions.

1. Edge devices. The sensors, cameras, machines, point-of-sale terminals, and embedded systems that generate data and act on the physical world. These are usually constrained: limited compute, purpose-built firmware, and often not capable of running general workloads themselves.
2. Edge servers. The local compute at the site, ranging from a single small host to a small rack of servers. This is where applications and AI models actually run, and where real-time processing happens. Clusters here are small, typically only one or two nodes, and they need to keep working when the site is offline.
3. The network layer. Everything that connects devices to gateways, gateways to servers, and the site to the outside world, including the last mile link to the cloud. Its quality is the constraint the rest of the architecture has to be designed around, because you rarely control it.
4. On-premises data centers and servers. A single large factory might run twenty-five separate sites across the plant, each with its own local compute, and then a small on-premises data center that hosts the applications and AI models spanning all of them: cross-line analytics, shared services, plant-wide dashboards, and the coordination no individual site can do on its own.
5. The central cloud or data center. Long-term storage, cross-site analytics, AI model training, and the management layer that orchestrates every site. This is the coordination point, not the execution point.

How much of your workload lands on each layer depends entirely on what you are running. See Edge Computing Use Cases for how the mix differs between a retail store, a factory, and an autonomous machine.

How Data and Control Move Between Edge and Cloud

In a working edge architecture, two things move in opposite directions.

Data moves up and gets smaller as it goes. It is generated by devices, aggregated by gateways, and processed by applications and AI models on the edge servers at each site. Only what is genuinely needed centrally continues upward: results, events, aggregates, telemetry, and whatever has to be retained for analytics, training, or compliance. Raw video, high-frequency sensor readings, and everything else stays local.

Management moves down. Applications, AI model versions, configuration, secrets, and policy are defined once in a central management layer and distributed to each site. Sites should apply those changes and then continue to run on their own, without needing the central layer to stay reachable.

That second direction is where most of the operational difficulty lives. Getting data out of a site is a solved problem. Getting the right version of the right application onto four hundred sites with mixed hardware and unreliable connectivity, and knowing afterwards that it worked, is not.

The Edge Computing Architecture

The tier most taxonomies skip is the user edge, and specifically the industrial and embedded compute edge. It is not a data center and it is not a sensor. It is a site with a couple of industrial PCs, some cameras, a network segment that corporate IT cannot see into, and one connection out.

One site looks like the diagram below. A real deployment is that same box repeated across every location you run. Each site processes locally, ships filtered data and results up to an on-premises data center for analysis, and pulls application and AI model deployments down from a cloud or global data center.

Two properties of this picture matter more than the hardware list.

The first is repetition. Every site looks like this, and there are many of them, so anything in the design that needs a person physically present does not survive contact with the fiftieth location.

The second is the direction of the management connection. Nothing reaches into the site from outside. The site opens a single connection out, and everything it needs comes back down that connection: software and AI model updates, secrets and certificates, rollbacks. No inbound ports are opened, which is usually the only arrangement an OT security team will agree to.

The Seven Components of an Edge Stack

Component	What it is, and what it does
Industrial PC	A fanless mini-PC or NUC-class x86 box, rated for factory floor dust and temperature rather than an office desk. Runs the local orchestration agent and lightweight services, often including the pub/sub broker itself.
PC with GPU	A Jetson Orin-class module, or an x86 box with a GPU card. Runs the actual inference: vision models, defect detection, a local LLM or VLM. This is where the 10 to 100 millisecond closed loop lives.
Cameras	GigE Vision or USB3 industrial cameras. Frames go straight to the GPU box across the local network. They never go to the cloud and are never round-tripped.
Devices	Sensors, actuators, and PLCs: the equipment actually running the process. Read and controlled locally, over fieldbus or OPC-UA.
Secure LAN and OT segment	A network segment isolated from corporate IT, usually by VLAN and firewall. Nothing inside it is reachable from outside except over the one link explicitly allowed out.
Pub/sub bus	A local broker, MQTT or similar, that the PCs, cameras, and devices all publish to and subscribe from. The site’s nervous system, and it keeps working with the internet down.
Outbound management link	One controlled, egress-only connection to the cloud or global data center, carrying software and AI model updates, secrets and certificates, telemetry, and rollbacks. No inbound ports, ever.

The Software on Every Box

All of that is hardware, and none of it does anything on its own. The software stack looks much the same on every box: a Linux operating system underneath, usually a slimmed-down or real-time-patched distribution rather than a desktop build; a container runtime above it; the applications themselves; and, on the GPU box specifically, an inference engine such as ONNX Runtime or TensorRT actually executing the model.

Tying it together on each node is a local edge orchestration agent. That is the component which pulls down whatever arrives over the outbound link, starts and restarts workloads, and reports status back.

The one piece not tied to a specific box is the central edge orchestrator, the management plane that handles fleet management for both the infrastructure and the applications. It can run in your own on-premises data center, for organizations that want fleet management never to leave their own network, or in a cloud or global data center, which is the more common choice when one management plane has to reach every site from outside.

Where Avassa Fits in the Architecture

The Avassa Edge Platform maps directly onto the two directions described above.

Control Tower is the central management layer, the cloud side of the architecture. It is where teams define applications and AI in terms of their containers and declare where each deployment should run, roll out new versions of applications and AI models, distribute secrets, manage operating system upgrades, and monitor every site from one place. It runs as a service or in your own data center.

Edge Enforcer runs on the hosts at each location and corresponds to the edge server layer. It forms the local cluster, schedules applications onto the available hosts, handles failover and migration between them, maintains a local container registry, and discovers local devices such as GPUs and attached cameras so applications can use them. Crucially, it keeps doing all of that when the site has no connection to Control Tower, and applies pending updates once connectivity returns.

In the single-site picture above, Edge Enforcer is the local orchestration agent on the industrial PC. It owns the pub/sub bus and the outbound link back to Control Tower, and it keeps that site’s loop alive, including restarts, rollbacks, and secrets, whether or not the link is up and independently of every other site you run.

That is the same split the architecture calls for, made operational: centralized control, decentralized execution, and no assumption that the last mile is available.

Conclusion

An edge computing architecture is the set of components and layers that make distributed processing work in practice: the devices that generate data, the gateways and local servers that process it, the network in between, and the central cloud that coordinates. Reading it as a continuum from cloud out to device tells you where compute sits and who owns it at each step. Looking inside a single site tells you what that actually means on the ground: a couple of industrial PCs, a GPU host, cameras, an isolated network segment, and one connection out, repeated across every location you run. The architecture worth building is the one that matches the sites you actually have.