Documentation

Appearance

Dataplicity vs AWS IoT and Greengrass: integrated product layer vs AWS building blocks ​

Choose AWS IoT and Greengrass when you want deep AWS-native control over device identity, messaging, edge components, deployments, local compute, and cloud integration, and you have the engineering organisation to assemble the system you need. Choose Dataplicity when you want a more integrated Linux-device, fleet-support, and downstream customer-product layer without first designing that platform from AWS services.

AWS IoT is not “just raw primitives”. AWS IoT Device Management and Greengrass provide substantial managed capabilities for onboarding, inventory, monitoring, jobs/deployments, OTA, edge components, local processing, and secure cloud integration. The trade-off is that AWS gives you a broad architecture toolkit rather than Dataplicity's more opinionated end-to-end product model.

Reviewed against public AWS documentation on 29 August 2026.

Why these products get compared ​

Both can form part of the post-shipment architecture for Linux IoT products. Both can onboard devices, manage fleets, deliver software/configuration, observe device state, and connect remote equipment to cloud services.

The architectural question is usually:

Do we want to build our connected-product platform from a broad cloud/edge service portfolio, or buy a more opinionated application and operating layer around the Linux product?

AWS's center of gravity: composable cloud and edge architecture ​

AWS IoT Device Management documents capabilities for:

  • device onboarding and registration;
  • fleet indexing/inventory;
  • fleet monitoring;
  • remote jobs and management;
  • OTA update workflows.

AWS IoT Greengrass adds an edge runtime and component model for Linux and Windows devices. Its documented model supports locally running components and integration with AWS services, including Lambda functions, Docker containers, native processes, custom components, local messaging, and fleet deployments through thing groups.

Greengrass deployments include component versions, dependency resolution, rollout configuration, failure handling, and rollback-related controls. This is a deep platform for teams that want to design their own edge/cloud application architecture.

Dataplicity's center of gravity: make the Linux product operable and customer-facing ​

Dataplicity starts from a different assumption: you already have, or are building, a Linux product and need the surrounding post-shipment software to operate and support it.

It provides an integrated path through:

  • outbound device connectivity;
  • Remote Shell and support tooling;
  • logs, diagnostics, monitoring, and fleet jobs;
  • Pulse/drift evidence;
  • Device Classes;
  • product streams, settings, and actions;
  • customer/site/device tenancy;
  • Customer Portal;
  • Product Applications and offline datasets.

You can keep an existing systemd/Docker/Podman/Greengrass application where it already works. Dataplicity does not require Greengrass or replace it as a general edge runtime.

Choose AWS IoT / Greengrass when... ​

AWS is the stronger fit when:

  • your architecture is already deeply AWS-native;
  • you need custom edge compute and component composition as a core requirement;
  • local Lambda/container/native components are central to the product runtime;
  • you need to integrate many AWS services directly at the edge/cloud boundary;
  • your team wants fine-grained control over the architecture rather than a more opinionated product platform;
  • you are prepared to build and operate the customer application, tenancy model, support workflows, and product-specific UX around those services;
  • the scale/complexity of your system justifies a dedicated cloud/platform engineering function.

For sophisticated AWS teams, the ability to compose exactly the architecture they want can be an advantage rather than overhead.

Choose Dataplicity when... ​

Dataplicity is the stronger fit when:

  • you need to get from Linux hardware to a supportable connected product without assembling the whole SaaS stack yourself;
  • existing Linux applications should remain in place;
  • remote diagnosis/support is a first-class operational workflow;
  • you need fleet evidence and bounded fleet actions out of the box;
  • downstream customer organisations, sites, users, device views, and customer-safe controls are required;
  • the customer-facing product layer is as important as cloud-device messaging;
  • your organisation wants to spend engineering effort on the hardware/domain product rather than permanently owning IAM, APIs, portal/frontend, tenancy, operational tooling, and device-management glue.

The Dataplicity advantage is integration and opinionated product semantics, not that AWS lacks powerful device-management capabilities.

What you still have to build on AWS ​

The exact answer depends on which AWS services you adopt, but AWS's service portfolio generally leaves your team responsible for designing the application that turns those capabilities into your product.

That can include decisions around:

  • downstream customer/user/site model;
  • product-specific customer UI;
  • device support console and support permissions;
  • product data/control semantics;
  • application/business workflow model;
  • cross-service observability and incident workflows;
  • API composition;
  • billing/identity/portal integration;
  • how the architecture is documented and operated as one coherent product.

AWS provides many of the components. Dataplicity deliberately packages more of that operating/customer layer as one product.

Greengrass and Dataplicity can coexist ​

This is not necessarily an either/or decision.

A product can use Greengrass for:

  • local components and IPC;
  • AWS service integration;
  • edge compute;
  • component deployments;

while using Dataplicity for:

  • remote engineering support;
  • fleet diagnosis and drift visibility;
  • customer-facing product state and controls;
  • customer/site tenancy;
  • Product Applications.

If Greengrass already solves an application-runtime problem well, there is no reason to replace it merely to adopt Dataplicity.

Detailed decision table ​

DecisionAWS IoT / GreengrassDataplicity
Primary architectureBroad composable cloud + edge servicesOpinionated Linux fleet + connected-product/customer layer
Device onboarding/inventoryFirst-classFirst-class
Jobs/deploymentsFirst-class AWS IoT/Greengrass capabilitiesFleet Jobs and product/software operations
Edge application runtimeGreengrass component/runtime modelExisting runtime can remain; optional class-managed OCI software
Local compute / AWS integrationMajor Greengrass strengthNot intended as a replacement for general edge compute frameworks
Remote engineering shell/supportCan be built/integrated through AWS architecture; not the only platform focusFirst-class product capability
Fleet drift / peer evidenceAWS has fleet indexing/monitoring; architecture differsPulse is purpose-built around Device Classes
Product streams/settings/actionsRequires application/service designFirst-class Device Class contract
Customer/site/user product tenancyRequires application architectureFirst-class Customer Portal
Customer-facing UIBuild or integrateFirst-class
Bounded customer workflowsBuild from AWS/app services or other toolingProduct Applications
Best fitTeams wanting deep AWS-native composabilityTeams wanting an integrated post-shipment product layer

Where AWS is plainly stronger ​

AWS is much stronger when your requirement is a large custom cloud/edge architecture with deep AWS service integration, arbitrary application components, event processing, data pipelines, machine learning, or other workloads far beyond Dataplicity's product model.

Dataplicity should not pretend to replace the AWS platform. It is valuable precisely when you do not want to assemble all of that machinery merely to operate and support a Linux product.

Sources ​

Primary AWS documentation reviewed:

Dataplicity source material: