Before internals, a shared vocabulary of the concepts that only matter once you are running Greengrass in anger — across a real fleet, with custom components, offline periods, and coordinated rollouts.

The Nucleus as a local orchestrator, not just an agent

Greengrass’s Nucleus is frequently described as “an IoT agent,” which understates what it actually does. The Nucleus is a local orchestration runtime: it resolves component dependency graphs, determines install and startup order, manages inter-process communication between components, enforces per-component resource constraints, and executes deployment rollouts and rollbacks — entirely on the device, entirely independent of whether the device currently has any connectivity to AWS IoT Core at all. This is the single idea that explains most of Greengrass’s other behavior: a device that has been offline for three days can still restart, resolve its own component graph from local state, and come back up in a fully consistent configuration without any cloud round trip.

Components, recipes, and artifacts

A component is Greengrass’s unit of deployable software, defined by a recipe — a declarative document specifying the component’s dependencies, lifecycle commands (install, run, shutdown), configuration schema, and platform compatibility — plus one or more artifacts, the actual binaries, scripts, or container images the recipe references. Components are versioned independently, and a single device typically runs a mix of AWS-provided public components (such as stream manager or the MQTT bridge) alongside custom, organization-authored components, all resolved and orchestrated by the same Nucleus instance.

Nucleus Lite versus the full Java-based Nucleus

Greengrass ships two Nucleus implementations with meaningfully different operating envelopes. The original Nucleus, written in Java, targets gateway-class devices with more available memory and supports the full component and deployment feature set including local debugging tools. Nucleus Lite, written in C++ with a dramatically smaller footprint, targets constrained devices where a JVM’s memory overhead is simply not affordable, trading some advanced feature support for the ability to run on hardware an order of magnitude smaller. Choosing between them is a hardware-capability decision made per device class, not a preference — the two are not interchangeable for every workload.

Public components versus private, organization-authored components

AWS publishes a catalog of public components covering common edge needs — the MQTT broker, Stream Manager, Docker application deployment, machine learning inference integration, and secret management, among others — each versioned and maintained by AWS. Organizations layer their own private components on top, referencing public components as dependencies where useful. A private component is scoped to a single AWS account (or shared explicitly across accounts) and follows exactly the same recipe and artifact structure as a public one, which means the same dependency resolution, lifecycle management, and IPC authorization rules apply uniformly regardless of who authored the component.

Configuration merge behavior across deployments

A component’s configuration is not simply replaced wholesale on every new deployment — Greengrass supports a structured configuration update model where a new deployment can merge specific configuration keys into a component’s existing configuration, reset specific keys to their recipe-declared defaults, or replace the configuration entirely, depending on how the deployment document is authored. This distinction matters in practice: a deployment intended only to bump a log level should not accidentally reset unrelated configuration a previous deployment had carefully tuned, and getting the merge versus replace semantics wrong is a subtle but real source of configuration drift across sequential deployments.

What actually happens, in order, inside the Nucleus from the moment a deployment is created in the cloud to the moment a component is running on-device.

flowchart LR
  A[Cloud Deployment Service] -->|Deployment document| B[Device Shadow / Job]
  B --> C[Nucleus: Deployment Orchestrator]
  C --> D[Dependency Resolver]
  D --> E[Component State Machine
per component]
  E --> F[Local Component Processes]
  F --> G[IPC via Nucleus Broker]
        

The component dependency resolver

When a new deployment arrives — or when a device restarts and re-evaluates its last known deployment — the Nucleus builds a full dependency graph across every targeted component, using each component’s declared dependencies and version constraints. It then computes a valid install and startup order via topological resolution, entirely locally. If two components declare mutually incompatible version constraints on a shared dependency, the resolver fails the deployment before touching any running process, rather than partially applying a broken configuration — this fail-fast behavior at resolution time is what prevents a bad deployment from leaving a device in a half-updated, inconsistent state.

The component state machine

Every component instance on a device moves through a well-defined state machine: NEW, INSTALLED, STARTING, RUNNING, STOPPING, FINISHED (for one-shot components), ERRORED, and BROKEN. The Nucleus continuously tracks which state each component is in, and a component that repeatedly fails to reach RUNNING transitions to BROKEN after a bounded number of retries, at which point the Nucleus stops attempting to restart it automatically and surfaces the failure rather than looping indefinitely and consuming device resources on a component that will never recover on its own.

Inter-process communication and the local broker

Components that need to exchange data or invoke each other’s functionality do so through the Nucleus’s built-in IPC mechanism, a local authenticated broker that enforces per-component authorization policies declared in each component’s recipe. This means one component cannot simply call into another’s local socket or shared memory unless the recipe explicitly grants that permission — the same least-privilege model AWS applies to IAM in the cloud is mirrored locally, on-device, between components that may have been authored by entirely different teams or vendors.

Artifact download, caching, and version coexistence

When the Nucleus resolves a deployment that references a component version already present on-device from a prior deployment, it skips re-downloading that artifact entirely, relying on local content-addressed storage to detect the match. Multiple versions of the same component can coexist in local storage simultaneously during a transition, which is precisely what makes rollback fast — reverting to a previous version does not require re-fetching artifacts from the cloud or a private artifact store if that version’s artifacts are still cached locally from before the failed deployment was applied.

Why local state, not cloud state, is authoritative between deployments

A subtlety that surprises engineers coming from purely cloud-native orchestration systems is that the cloud’s view of “what this device is running” is a report, not a command that continuously enforces itself. Between deployments, the device’s own local state — what the Nucleus actually has running — is authoritative. If an operator manually stops a component locally via the command-line interface, the cloud’s last-known deployment status does not automatically detect or correct that drift until the next deployment evaluation or status report cycle, which is an important operational distinction when diagnosing why a device’s actual behavior does not match its last reported cloud status.

Following data from a sensor reading on the factory floor to a durable record in the cloud, and what a deployment’s lifecycle looks like across a fleet that is only intermittently connected.

Local-first data flow with Stream Manager

Rather than every component independently deciding how to buffer and retry cloud uploads, Stream Manager centralizes this concern: components write data into named local streams with configurable size limits and persistence settings, and Stream Manager handles batching, retry, and export to destinations such as an IoT Analytics channel, a Kinesis data stream, or S3 — automatically pausing export during a connectivity loss and resuming exactly where it left off once the link returns, without the producing component needing any awareness of the outage at all.

sequenceDiagram
  participant Sensor as Sensor Component
  participant SM as Stream Manager
  participant Cloud as Cloud Destination

  Sensor->>SM: Write reading to local stream
  SM->>SM: Persist per stream policy
  alt Connectivity available
    SM->>Cloud: Export batch
    Cloud-->>SM: Acknowledge
  else Connectivity lost
    SM->>SM: Buffer locally, retry later
  end
        

Deployment lifecycle across a partially-connected fleet

A fleet-wide deployment’s lifecycle does not assume every device is online simultaneously. The cloud deployment service tracks per-device job status independently, and a device that is offline when a deployment is created simply receives and applies it the next time it reconnects, evaluating whether its currently-installed component set already matches the target or needs updating. This is a deliberate design choice: a factory device offline for a scheduled maintenance week is not treated as a failed deployment target, it is treated as a pending one, and catches up automatically without manual intervention.

Rollback as a first-class lifecycle outcome

If a deployment fails on-device — a component fails to reach RUNNING within its configured timeout, for instance — the Nucleus does not leave the device in a broken, half-applied state. It automatically reverts to the last known-good component configuration, restarting the previously working set, and reports the failure back to the cloud. This local rollback capability is precisely what makes it safe to push updates to devices that may be physically unreachable for months at a time; the alternative, a device permanently stuck mid-update because a technician cannot drive out to intervene, is the failure mode this design explicitly exists to prevent.

What rollback does and does not undo

Rollback reverts the component configuration and running process set to the last known-good deployment; it does not automatically undo side effects a failed component may have already caused before failing — a partially written local database migration, or a half-sent batch of sensor data, are not rolled back as part of this mechanism. Component authors bear responsibility for making their own install and startup lifecycle commands idempotent and safe to retry, since the Nucleus’s rollback guarantee operates at the orchestration layer, not inside the internal logic of each component’s own code.

Local deployment via the command-line interface

Beyond cloud-initiated fleet deployments, the Greengrass command-line interface installed alongside the Nucleus allows an operator with local device access to create, list, and restart component deployments directly on that single device, without going through the cloud deployment service at all. This local path is commonly used during initial component development and field debugging, though production fleets generally restrict who has this local access, since a local deployment bypasses the staged rollout and fleet-wide consistency guarantees that cloud-orchestrated deployments provide.

Running orchestration logic on the edge, rather than purely in the cloud, is a deliberate architectural bet with real costs attached.

The consistency cost in practice

Because every device makes deployment and rollback decisions independently based on its own local state and connectivity history, two devices in the same thing group can genuinely be running different component versions at the same moment — one already caught up on the latest deployment, another still applying it, a third rolled back after a failure the first two never encountered. This is not a bug; it is the direct consequence of prioritizing per-device resilience over forced fleet-wide synchronization. Teams that build downstream systems assuming every device in a group is always running identical software need to explicitly account for this eventual-consistency window, rather than assuming deployment completion is instantaneous across a fleet.

Scaling Greengrass is not about a single device’s throughput — it is about coordinating tens of thousands of independently-behaving devices without the cloud side becoming a bottleneck.

Fleet-scale deployment rollout strategy

Pushing a new deployment to every device in a hundred-thousand-device fleet simultaneously creates a thundering-herd problem at the cloud’s job and artifact-download services, and, far more dangerously, means a bad component version reaches the entire fleet before anyone notices a problem. Greengrass deployment configuration supports rollout percentage and rate controls, applying a new deployment to a small percentage of a thing group first, monitoring failure rate, and only continuing the rollout if that percentage stays within an acceptable threshold — the same canary rollout discipline used in cloud-native deployments, applied to physical devices that cannot simply be terminated and replaced if something goes wrong.

On-device resource constraints as the real scaling limit

Unlike a cloud service that scales by adding compute, a Greengrass device’s resource ceiling is fixed by its physical hardware. The scaling exercise that matters most is not increasing a single device’s capacity but keeping each component’s declared resource limits — CPU, memory — realistic and enforced, so that a single misbehaving component cannot starve every other component sharing that device. The Nucleus enforces these limits per component, but only if they are declared accurately in the first place; an under-specified resource limit is not a Nucleus failure, it is a component authoring gap.

Why “scaling Greengrass” mostly means scaling the fleet management layer

Unlike a cloud compute service where scaling refers to handling more load per unit, scaling a Greengrass deployment overwhelmingly refers to the cloud-side fleet management systems coping gracefully with more devices — more concurrent connections to IoT Core, more deployment jobs tracked simultaneously, more shadow document updates per second. AWS IoT Core’s own connection and messaging limits, not anything inside the Nucleus, become the practical ceiling that fleet architects design around as device counts grow into the tens or hundreds of thousands, which is why fleet growth planning conversations tend to center on IoT Core quotas and connection pooling strategies rather than on individual device capacity.

Local MQTT broker throughput and the cloud bridge

Devices running the Greengrass MQTT broker component can serve local MQTT traffic between components and downstream client devices entirely on-premises, only bridging a configured subset of topics to AWS IoT Core in the cloud. This local-first messaging pattern is what allows a factory with hundreds of local sensors publishing at high frequency to avoid saturating its often-limited uplink bandwidth — only aggregated or filtered data actually needs to leave the site.

Machine learning inference at the edge as a scaling consideration

Running ML inference components locally on a Greengrass device introduces a distinct scaling dimension from the messaging and orchestration concerns discussed so far: model size and inference latency are bound entirely by the device’s own compute, with no cloud burst capacity available for the inference workload itself. Advanced deployments size the inference model to the target hardware class deliberately — often maintaining multiple model variants of differing precision or size across device classes with different compute budgets — rather than assuming a single model artifact will perform acceptably across a heterogeneous fleet ranging from a compact gateway to a GPU-equipped edge server.

Batching and backpressure in Stream Manager under sustained load

Under sustained high-frequency local data production, Stream Manager’s configurable batching parameters — batch size, batch timeout, and maximum stream size — become the primary tuning surface for balancing export efficiency against local storage pressure. A stream configured with too small a maximum size under sustained offline conditions will begin dropping or rejecting new writes once full, depending on the configured overflow policy, which is a scaling failure mode distinct from anything related to Nucleus orchestration itself — it is purely a local storage capacity and backpressure design decision that must be sized to the expected worst-case offline duration for that specific deployment site.

Edge reliability means something different from cloud reliability — there is no failover to a healthy replica when the “replica” is a single physical machine bolted to a wall.

Component-level restart and supervision

The Nucleus supervises every running component and restarts it automatically according to a configurable restart policy if the process exits unexpectedly, up to a bounded retry count before marking the component BROKEN. This local supervision is the primary reliability mechanism at the individual-device level — it does not require any cloud round trip to detect and recover from a crashed process, which matters enormously for a device that may be disconnected at the exact moment a component crashes.

Multi-device redundancy patterns at the site level

For sites where a single Greengrass device is a genuine single point of failure — a control system for critical machinery, for instance — the reliability pattern shifts from within-device supervision to site-level device redundancy: a secondary Greengrass device running the same component configuration, with an external mechanism (often a simple heartbeat protocol between the two devices over the local network) determining which one is actively controlling the process at any moment. Greengrass itself does not provide this active-passive coordination out of the box; it is implemented as a custom component pattern layered on top of Greengrass’s component and IPC primitives.

flowchart TB
  subgraph Site[Factory Site]
    D1[Greengrass Device 1
Active]
    D2[Greengrass Device 2
Standby]
  end
  D1 -->|Heartbeat| D2
  D1 -->|Controls| M[Machine / Process]
  D2 -.->|Takes over on missed heartbeat| M
        

Reconnection and offline operation guarantees

A device’s ability to keep running components and processing local data through an extended connectivity loss is not a special mode Greengrass enters — it is simply the normal operating condition the Nucleus is designed around from the start, since cloud connectivity is treated as an intermittent convenience for deployment and telemetry, not a runtime dependency. This design assumption is precisely why Greengrass, rather than a purely cloud-orchestrated container platform, is the appropriate choice for genuinely unreliable network environments.

Reconnection backoff and thundering-herd avoidance

When a large number of devices at a single site lose and then regain connectivity simultaneously — a common event after a site-wide power restoration — every device’s Nucleus attempting to reconnect to IoT Core at the exact same instant creates a localized thundering-herd effect against the cloud’s connection-handling capacity. The underlying MQTT client used by the Nucleus applies exponential backoff with jitter on reconnection attempts specifically to avoid this synchronized retry pattern, spreading reconnection attempts across a wider time window rather than every device hammering the same endpoint in the same second.

Securing an edge fleet means protecting three separate surfaces: device identity, component authorization, and the local data path itself.

Device identity via X.509 certificates

Every Greengrass core device authenticates to AWS IoT Core using a unique X.509 certificate, provisioned during setup and tied to an IoT policy that scopes exactly which MQTT topics and IoT Core actions that specific device is permitted to use. Because this certificate is the device’s entire identity in the eyes of the cloud, physical device security matters as much as network security — a stolen device with an extractable certificate is, from the cloud’s perspective, indistinguishable from the legitimate device it was cloned from until the certificate is explicitly revoked.

Component-level IPC authorization

As introduced earlier, IPC calls between components are authorized against permissions declared in each component’s recipe, following a least-privilege model. At the security level, this matters because a fleet frequently runs components authored by different internal teams or even third-party vendors on the same device; without per-component IPC authorization, any component with local code execution could, in principle, access data or invoke functionality belonging to any other component sharing that device.

Secret and credential management on constrained devices

Components that need runtime secrets — API keys, database credentials — retrieve them through integration with AWS Secrets Manager or Systems Manager Parameter Store rather than embedding secrets directly in component artifacts or recipes. On genuinely offline-capable deployments, this typically means a secret is fetched and cached locally on the device the last time it had connectivity, with the caching policy itself becoming a security decision: caching indefinitely trades a small compromise-window risk for guaranteed offline operation, while a short cache lifetime trades offline resilience for tighter credential freshness.

Certificate revocation and device decommissioning

Decommissioning a device — because it was retired, stolen, or found to be compromised — requires explicitly deactivating and deleting its X.509 certificate and detaching it from its IoT policy; simply powering the device off does nothing to revoke its cloud access. Fleets operating in physically exposed environments maintain an active decommissioning process tied to asset tracking, precisely because a certificate left active on a device that is no longer under organizational control remains a fully valid credential from the cloud’s perspective indefinitely.

Network-level isolation as a complementary control

Beyond identity and IPC authorization, many industrial deployments place Greengrass devices on segmented operational technology networks isolated from general corporate IT networks, limiting lateral movement even if a device or an adjacent system on the same network segment is compromised. This network-level isolation is not something Greengrass configures itself — it is a surrounding infrastructure decision — but it is routinely treated as part of the same defense-in-depth strategy as the certificate and IPC controls native to the platform.

Auditing component provenance across a large fleet

As a fleet accumulates dozens of components from multiple internal teams and third-party vendors over time, knowing exactly which component versions are running where, and who authored and last modified each one, becomes a genuine security and compliance question in its own right. Mature deployments maintain a component provenance record separate from the deployment tooling itself — tracking authorship, last security review date, and known vulnerability status per component version — and treat a component with no recent review as a flag worth resolving before it is included in any new fleet-wide rollout, rather than assuming a component that has “always worked” carries no ongoing risk.

A device silently stuck in a bad state produces almost no cloud-visible signal by default — the only way to catch it early is watching the right on-device and fleet-level indicators.

Local logs versus cloud-visible telemetry

The Nucleus and every component write detailed logs locally on-device by default, which is invaluable for debugging but invisible to a fleet operator unless explicitly exported. Production deployments typically run a log-management component that forwards a filtered, aggregated subset of local logs to CloudWatch Logs, deliberately avoiding forwarding full verbose logs from every device continuously — bandwidth and cost constraints on constrained network links make that impractical at fleet scale, so the filtering policy itself becomes an operational design decision.

Fleet health dashboards built on deployment status, not just connectivity

A common early mistake is building fleet health monitoring purely around device connectivity — “is this device currently connected to IoT Core” — which misses the more operationally relevant question of whether the device’s actual running component configuration matches what was intended. A device can be fully connected while running a stale or partially-failed deployment; correlating connectivity status against last-reported deployment status per device is what actually surfaces configuration drift across a large fleet.

Distinguishing a network problem from a device problem

One of the most operationally valuable but underused signals is the gap between a device’s last-known local timestamp on its own logs and the last timestamp the cloud actually received from that device. A large, growing gap with no corresponding local error activity usually points to a pure connectivity problem — the device is fine, the network is not. A device reporting recent local error activity right up until it went silent points instead to a device-level problem worth dispatching a technician for. Building this distinction directly into fleet alerting saves considerable diagnostic time compared to treating every “device went quiet” alert identically.

Greengrass devices are physical assets, not disposable cloud instances — deployment discipline has to account for hardware you cannot simply terminate and recreate.

Thing groups as the deployment targeting unit

Deployments target IoT thing groups rather than individual devices directly, and groups can be organized hierarchically — by site, by device class, by hardware revision — allowing a single deployment definition to express “roll this out to every device at Site B running hardware revision 3” without hand-listing device identifiers. Production fleets typically maintain this grouping structure as carefully as any other piece of infrastructure configuration, since a poorly organized grouping scheme is what makes safe, targeted canary rollouts difficult or impossible later.

Infrastructure as code for fleet provisioning

Provisioning a new device — creating its IoT thing, certificate, policy, and initial deployment target group membership — is almost always automated through infrastructure-as-code templates combined with a fleet provisioning workflow, rather than manual console setup per device. At the scale of thousands of devices shipped to field technicians who are not cloud engineers, this automation is not an optimization; it is the only way initial provisioning stays consistent and auditable across every device that ever joins the fleet.

Version pinning and controlled component rollback plans

Because a bad component version reaching a physically inaccessible device is a genuinely expensive mistake to recover from, mature deployment pipelines maintain an explicit, tested rollback deployment definition alongside every new rollout — not relying solely on the Nucleus’s automatic on-device rollback for failures that only manifest as subtly wrong behavior rather than an outright crash the Nucleus can detect on its own.

Separating recipe changes from artifact changes in review

A recipe change — adjusting a dependency version constraint or an IPC permission — carries different risk than an artifact change containing new application logic, yet both are frequently reviewed under the same generic pull-request process. Teams that separate these into distinct review paths, with recipe changes specifically checked against fleet-wide dependency and permission implications rather than just code correctness, catch a category of issue that a purely code-focused review process routinely misses: a permission grant that is technically correct for the new feature but unintentionally broadens what the component can already do across every device it is already running on.

CI/CD integration for component development

Component recipes and artifacts are commonly built, tested, and published through the same continuous integration pipelines used for any other software artifact — building the component package, running automated tests against a local Greengrass development environment or simulated device, publishing the new component version to the cloud component registry, and only then triggering a staged fleet deployment. Treating component publishing as a distinct, auditable pipeline stage separate from the deployment rollout stage gives teams a clear point to gate releases on test results before any physical device is ever targeted.

Blue-green thing group migration for major version upgrades

For a change significant enough that a straightforward staged rollout feels too risky — a major Nucleus version upgrade, for instance — some fleets adopt a blue-green pattern at the thing group level: provisioning a parallel “green” thing group, migrating a small number of devices into it deliberately, validating behavior over a longer soak period than a typical canary window, and only then migrating the remainder of the fleet, keeping the “blue” group’s previous configuration available as an explicit fallback path for longer than a standard rollout’s automatic rollback window would provide.

Multi-region considerations for global fleets

Organizations operating device fleets across multiple geographic regions typically register devices against the AWS region closest to their physical deployment site, both to reduce connectivity latency for telemetry and deployment status reporting and to satisfy data residency requirements that may apply to telemetry data collected from that region. Component definitions themselves are commonly maintained centrally and replicated or re-published per region, since component version identifiers are scoped per account and region rather than globally unique across an organization’s entire multi-region footprint.

Patterns that experienced edge teams converge on independently, and the anti-patterns that keep causing the same class of field incident across the industry.

Practical, hard-won guidance that shows up repeatedly in post-incident reviews across teams running Greengrass fleets in the field.

How the concepts above show up in production systems operated by manufacturers, logistics operators, and other industrial and commercial deployments.

Questions that come up repeatedly once teams move from a proof-of-concept device to a production-scale Greengrass fleet.

The Nucleus continues executing the deployment it already received locally; if the deployment fails to complete successfully, it rolls back to the last known-good configuration on its own, without waiting for any cloud round trip.

No — every IPC call is authorized against permissions explicitly declared in the calling component’s recipe, following a least-privilege model identical in spirit to IAM policy scoping in the cloud.

Not necessarily — Nucleus and Nucleus Lite can coexist within the same fleet and thing group structure, chosen per device class based on available hardware resources, as long as deployed components are tested against both variants in use.

No — active-passive redundancy between two physical devices is a custom pattern built on top of Greengrass’s component and IPC primitives, not a built-in capability of the service itself.

This is most commonly caused by hardware or environment differences — a resource constraint, a differing Nucleus version, or an undeclared platform-specific dependency — that only manifest on a subset of the fleet, which is exactly why staged canary rollouts by representative thing group matter.

Only if a component or Stream Manager configuration explicitly exports it; local processing is deliberately decoupled from cloud visibility so that raw, high-frequency data does not need to leave the site unless a downstream use case genuinely requires it.

The device’s actual running state diverges from the cloud’s last reported deployment status until the next deployment evaluation or status sync, since the cloud’s record is a report rather than a continuously enforced command.

Not if that version’s artifacts are still present in local content-addressed storage from a prior deployment, which is exactly why rollback can happen quickly even on a device with no current connectivity to fetch anything from the cloud.

Model size and precision should be matched to each device class’s actual compute budget, often maintaining multiple model variants across the fleet rather than assuming one model artifact performs acceptably on every hardware tier.

AWS IoT Greengrass’s entire design center is local-first orchestration: a Nucleus that resolves dependencies, manages component lifecycles, executes deployments, and rolls back failures entirely on-device, treating cloud connectivity as an intermittent convenience rather than a runtime requirement. Every advanced behavior — offline resilience, local IPC authorization, staged fleet rollouts, automatic rollback — traces back to that single architectural decision. Running Greengrass well at scale is less about any single device’s configuration and more about the discipline surrounding the fleet: well-declared component dependencies, realistic resource limits, deliberate thing-group structure, and rollout policies that assume some devices will always be offline when a change goes out.

The recurring theme across every chapter in this tutorial is that the Nucleus itself behaves in a genuinely simple, predictable way — the complexity experienced teams manage lives at the boundaries: between components sharing a constrained device, between a fleet’s connected and disconnected devices at any given moment, and between a deployment’s intended state and what is actually running in the field. Treating those boundaries as first-class design surfaces is what separates an edge fleet that survives its first extended network outage from one that discovers its assumptions the hard way, on physically inaccessible hardware, months after deployment.

For teams evaluating whether Greengrass is the right fit at all, the honest test is not whether the workload involves IoT devices in the general sense, but whether the workload genuinely needs local decision-making to survive intermittent connectivity. A fleet of devices with consistently reliable connectivity, running simple telemetry forwarding with no local logic of consequence, may find a lighter-weight agent sufficient. The moment a device must keep making correct decisions through connectivity loss — safety interlocks, local inventory reconciliation, in-vehicle routing — is the moment Greengrass’s local-first orchestration model earns the additional complexity it introduces.