Skip to content
Proxus 2.0.0 Proxus 2.0: the largest release in Proxus history Release notes
Try free Book a demo

Comparison · Cloud IoT services

“We already have Azure” is an answer to a different question.

AWS IoT SiteWise and Azure IoT Operations are serious industrial services with asset models, edge components and deep integration into their own analytics stacks. If your organisation has picked a cloud, using it is sensible. The question this page answers is what still has to exist inside the plant either way.

Book a demo All comparisons
What it is
Cloud IoT services: Managed cloud industrial services, for example AWS IoT SiteWise or Azure IoT Operations
What Proxus is
An industrial data platform: collect, model, govern, store, deliver
Honest summary
Strong once data is in the cloud. The plant floor is the part they still expect you to solve.
Your options
Keep the cloud for analytics with Proxus feeding it from the plant, or run the plant side in Proxus alone and add the cloud when you need it. Both paths are below.

Give them their due

What Cloud IoT services is genuinely good at.

A comparison that only lists the other product's weaknesses is a sales sheet, not a decision aid. These are real strengths, and some of them are reasons not to buy Proxus.

  • Scale and analytics you will not build

    Once data arrives, the storage, analytics, machine learning and BI services around it are enormous and priced by consumption. Competing with that from a plant server would be foolish.

  • Asset models and industrial features

    These are not generic IoT hubs. SiteWise has asset models and metrics; Azure IoT Operations ships an edge-native MQTT broker and a Kubernetes data plane.

  • Already procured

    If the enterprise agreement is signed and the security review is done, adding a service is far easier than adding a vendor. That is a real advantage and it is not a technical one.

  • One operating model for IT

    The same identity, monitoring and cost tooling as the rest of the estate. Your cloud team will prefer it, and they are not wrong to.

Attribute by attribute

Where the two actually differ.

Both columns are filled in. Where Cloud IoT services is ahead, the row says so.

  • Where the platform lives

    Proxus

    In your network. The cloud is a delivery target, not a dependency.

    In the docs: Where the platform lives

    Cloud IoT services

    In the cloud, with edge components managed from it. Azure IoT Operations runs on Arc-enabled Kubernetes.

  • Offline behaviour

    Proxus

    No documented offline limit, because there is no cloud control plane to lose. Air-gapped sites run indefinitely.

    In the docs: Offline behaviour

    Cloud IoT services

    Edge components buffer, within limits. Microsoft documents that Azure IoT Operations can operate offline for a maximum of 72 hours (checked October 2026).

  • Getting data out of a PLC

    Proxus

    Native drivers for 66 protocols across 30 vendor and standard families, no additional connectivity product.

    In the docs: Getting data out of a PLC

    Cloud IoT services

    Through edge gateways, OPC UA and partner connectivity software. Vendor-specific PLC protocols usually need a third-party product.

  • Local use of the data

    Proxus

    Collection, rules and buffering at the edge keep running without the link; history and dashboards live on the hub you host, inside your network.

    In the docs: Local use of the data

    Cloud IoT services

    Both have edge components that process data locally (SiteWise Edge on AWS, the edge data plane on Azure); dashboards and analytics are mostly realised in the cloud.

  • Kubernetes requirement

    Proxus

    Docker is enough. Kubernetes is supported where you already run it.

    In the docs: Kubernetes requirement

    Cloud IoT services

    Azure IoT Operations requires Arc-enabled Kubernetes at the edge.

  • What the edge has to run

    Proxus

    One gateway process plus a messaging container, installed by one script on a plant server or industrial PC. Kubernetes is an option, not a prerequisite.

    In the docs: What the edge has to run

    Cloud IoT services

    Arc-enabled Kubernetes and the service’s edge components, managed from the cloud.

  • Cost model

    Proxus

    Priced by gateways and data rate, fixed annually and independent of how much data you keep locally.

    Pricing: Cost model

    Cloud IoT services

    Consumption-based, which scales smoothly and can also grow in ways nobody predicted.

  • Data residency

    Proxus

    Data can stay entirely inside the plant network. Nothing leaves unless you configure a target.

    In the docs: Data residency

    Cloud IoT services

    Region-based, with the governance that comes from the provider.

  • Multi-cloud

    Proxus

    Cloud-agnostic: the same modelled signal can be delivered to more than one cloud.

    In the docs: Multi-cloud

    Cloud IoT services

    Each service is native to its own cloud.

Proxus figures come from the current build's own driver and target inventory. Cloud IoT services figures come from the vendor's published material, linked at the end of this page. Nothing here is measured on a benchmark neither party has agreed to.

Choose Cloud IoT services

When we are not the answer.

  • The workload really is cloud analytics, the sites are well connected, and local autonomy is not a requirement.
  • Your organisation has standardised on one cloud and adding a vendor is harder than adding a service.
  • The equipment already speaks OPC UA or MQTT, so plant-floor connectivity is not the hard part.
  • Consumption pricing suits a use case that starts small and may not grow.

Choose Proxus

When the shape of the problem fits.

  • Connectivity is the actual problem: the data is trapped in controllers that speak neither OPC UA nor MQTT.
  • The plant has to keep running, keep recording and keep deciding when the link is down for longer than a few days.
  • Data residency or air-gapped operation is a policy, not a preference.
  • You want the same modelled data in the cloud, in the plant and in the business systems, without three collection paths.

If this column describes you:

Bring the controllers your cloud service cannot read to a demo

Not either/or

How they are used together.

  • Proxus collects, the cloud analyses

    This is the common arrangement. Proxus reads the equipment, models it and delivers to AWS IoT Core or Azure IoT, outbound from inside the plant, with no inbound access required.

  • The plant keeps its own copy

    History and dashboards on the hub you host keep working during an internet outage. Data waits in the gateway’s buffer within its retention and is sent in order when the link returns.

  • Model once, send anywhere

    The same modelled signal reaches the cloud, the historian and the MES without a separate pipeline per destination.

Sources

Last checked against vendor material: October 2026.

Products change. If something on this page is out of date or wrong, tell us and we will fix it, including when the correction favours Cloud IoT services.

Questions

Proxus and Cloud IoT services: short answers.

How long can the plant run without the cloud?
Proxus has no documented offline limit, because there is no cloud control plane to lose; air-gapped sites run indefinitely. Microsoft documents a maximum of 72 hours offline for Azure IoT Operations (checked October 2026).
Does Proxus need Kubernetes?
No. Docker is enough; Kubernetes is supported where you already run it. Azure IoT Operations requires Arc-enabled Kubernetes at the edge.
Can Proxus send data to AWS and Azure?
Yes. Proxus delivers to AWS IoT Core or Azure IoT outbound from inside the plant, with no inbound access required, and the same modelled signal can go to more than one cloud.

Proven in production

Running in production at these sites.

All deployments

Other comparisons

All comparisons

Next step

Decide what has to run inside the plant.

Tell us which cloud you use, which controllers feed it and how long a site must run without the link. In thirty minutes we map what runs on site in Proxus and what goes on to AWS or Azure.

Book a demo Talk to an engineer
  1. 01

    Scoping call

    Equipment, protocols, sites and the systems the data has to reach.

  2. 02

    Technical walkthrough

    A working demo against a scenario that resembles your plant, not a generic tour.

  3. 03

    Pilot plan

    A defined first line or site, with the deployment and security questions answered up front.

  4. 04

    Roll-out

    The same templates bring the next lines and sites online.