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 and maintain 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 a bag of raw primitives. Device Management and Greengrass give you substantial managed capabilities for onboarding, inventory, monitoring, jobs and deployments, OTA, edge components, local processing, and secure cloud integration. The trade-off: AWS gives you a broad architecture toolkit; Dataplicity gives you a more opinionated end-to-end product model.

Reviewed against public AWS documentation and service lifecycle notices on 7 September 2026.

Why these get compared #

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

The usual question:

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

AWS: composable cloud and edge architecture #

AWS IoT Device Management documents:

device onboarding and registration
fleet indexing and inventory
fleet monitoring
remote jobs and management, covering firmware and software updates, reboots, resets, and other device-defined actions
OTA update workflows
Secure Tunneling, including browser-based SSH in the AWS IoT console and a local proxy for SSH or other TCP applications

AWS IoT Greengrass adds an edge runtime and component model. Documented capabilities include locally running components and integration with AWS services: Lambda, Docker containers, native processes, custom components, local messaging, and fleet deployments through thing groups. Deployments include component versions, dependency resolution, rollout configuration, failure handling, and ROLLBACK or DO_NOTHING behaviour, with bootstrap failures always rolling back.

Evaluate Greengrass v2. Greengrass v1 is in sunset: AWS announced end of support in October 2025, with support and access ending on 7 October 2026. Within v2, the full Java-based nucleus is the complete implementation, while nucleus lite targets embedded Linux with a much smaller footprint and a growing subset of nucleus functionality. Do not assume parity between the two.

That is a deep platform for teams that want to design their own edge and cloud application architecture.

Dataplicity: 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.

The integrated path covers:

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

You can keep an existing systemd, Docker, Podman, or Greengrass application where it already works. Dataplicity does not require Greengrass, and is not a replacement for it as a general edge runtime.

Choose AWS IoT and Greengrass when... #

AWS is the stronger fit when:

your architecture is already deeply AWS-native
custom edge compute and component composition are core requirements
local Lambda, container, or native components are central to the product runtime
you need to integrate many AWS services directly at the edge and 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 and complexity of the system justifies a dedicated cloud and platform engineering function

For sophisticated AWS teams, composing 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 stay in place
remote diagnosis and support is a first-class operational workflow
you need fleet evidence and bounded fleet actions without building them
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 engineering effort on the hardware and domain product rather than permanently owning IAM, APIs, portal frontend, tenancy, ops 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. In general, AWS's portfolio leaves your team responsible for designing the application that turns those capabilities into your product.

That often includes:

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

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

Composition also means owning service lifecycle #

Building on a broad portfolio means tracking each service you depend on. Over roughly the last two years AWS has consolidated a significant part of its IoT range:

Service or feature	Current status
AWS IoT Core	Active
AWS IoT Device Management, including Jobs, Fleet Indexing, and Secure Tunneling	Active
AWS IoT Greengrass v2	Active
AWS IoT Greengrass v1	Support and access end 7 October 2026
AWS IoT Device Management Fleet Hub	Shut down 18 October 2025
AWS IoT Device Defender Detect	Maintenance from 31 August 2026, existing customers only
AWS IoT Events	Shut down 20 May 2026
AWS IoT Analytics	Shut down 15 December 2025
AWS IoT SiteWise Monitor and Edge Data Processing Pack	Maintenance, closed to new customers from 7 November 2025
AWS IoT FleetWise	Maintenance, closed to new customers from April 2026
AWS IoT 1-Click	Shut down 29 January 2025
AWS IoT TwinMaker, AWS IoT ExpressLink	Active

Read this as architecture information, not as a warning against AWS. The core services most Linux products depend on are active and well documented. But if your connected-product platform is assembled from several portfolio services, migration work when one of them changes status is your responsibility, and Fleet Hub is the clearest recent example: the managed fleet application was withdrawn while the underlying indexing, jobs, and alarm resources remained available through the console and API.

Check the current AWS maintenance and shutdown registers when you scope the architecture, since this table has a review date and AWS's does not stand still.

Remote access on AWS, stated fairly #

AWS IoT Device Management does provide real remote shell access. Secure Tunneling supports browser-based SSH from the AWS IoT console, a local proxy for SSH or other TCP applications, and multiple connections through one tunnel.

It still expects you to run a destination service such as sshd, deploy the device-side tunnel agent or local proxy, provision the device in AWS IoT, and handle tunnel tokens and finite tunnel lifetimes. AWS documents secure transport and a browser terminal. It does not document a support workflow with cases, customer delegation, branded tenancy, or fleet-centric support history around that access.

Compare it as transport plus terminal against a support console, rather than assuming AWS has no shell.

Downstream customer tenancy is architecture, not a feature #

AWS does not provide a general multi-tenant end-customer product portal out of the box. IAM, Cognito, tenant isolation, API authorization, application UI, and lifecycle are architecture you design and own. SiteWise Monitor previously offered managed portals with project-level sharing, but it was organization-oriented rather than a general IoT SaaS tenancy system, and it is now in maintenance.

Greengrass and Dataplicity can coexist #

This is not necessarily either/or.

A product can use Greengrass for:

local components and IPC
AWS service integration
edge compute
component deployments

and Dataplicity for:

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

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

Decision table #

Decision	AWS IoT / Greengrass	Dataplicity
Primary architecture	Broad composable cloud and edge services	Opinionated Linux fleet plus connected-product and customer layer
Device onboarding / inventory	First-class	First-class
Jobs / deployments	First-class	Fleet Jobs and product and software operations
Edge application runtime	Greengrass v2 component model; nucleus lite for constrained Linux	Existing runtime can remain; optional Class Software containers
Local compute / AWS integration	Major Greengrass strength	Not a replacement for general edge compute frameworks
Remote engineering shell	Secure Tunneling with browser SSH and local proxy	Remote Shell inside a support workflow
Fleet drift / peer evidence	Fleet indexing and monitoring; different architecture	Pulse around Device Classes
Product streams / settings / actions	Requires application and service design	Device Class contract
Customer / site / user product tenancy	Requires application architecture	Customer Portal
Customer-facing UI	Build or integrate	First-class
Bounded customer workflows	Build from AWS or other tooling	Product Applications
Service lifecycle tracking	Yours, across each service you adopt	One product contract
Best fit	Teams wanting deep AWS-native composability	Teams wanting an integrated post-shipment product layer

Where AWS is plainly stronger #

AWS is much stronger when you need a large custom cloud and 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. Its device identity, messaging, and scale story is a different order of magnitude, and Greengrass nucleus lite pushes a managed component model onto genuinely constrained Linux hardware.

Dataplicity is not a replacement for the AWS platform. It is useful when you do not want to assemble all of that machinery to operate and support a Linux product.

Sources #

Primary AWS documentation reviewed:

Dataplicity: