AWS IoT Greengrass

Name: AWS IoT Greengrass
Brand: Amazon Web Services (AWS)
Rating: 4.1 (33 reviews)

Leader

Official Global LinkedIn page for Amazon Web Services (AWS).

Est 2006|Valuation $2560B|2 Ref Customers

LinkedIn 10.9M|Website|Web traffic 1.1M|FTEs 148,001|HQ Seattle, Washington, US

MarketsIndustrial IoT IoT Device Management

Platform CoversInfrastructure Monitoring

Published Oct 13, 2026

01Common complaints

1. Cross-cloud portability is a first-class requirement: Greengrass is closely aligned with AWS IoT Core identities/policies and AWS deployment constructs. 2. The organization cannot invest in edge fleet operations: distributed deployments require CI/CD, observability, and incident response capabilities. 3. The deployment relies on Greengrass v1 and cannot migrate in the near term: v1 end-of-support dates in 2026 create a migration requirement. 4. The primary need is device connectivity (MQTT broker) and minimal additional management: a broker-centric deployment with a lightweight agent may be more appropriate. 5. The organization mandates Kubernetes-native tooling for edge workloads: KubeEdge or k3s-based approaches may align better operationally than Greengrass components.

Deal disqualifiers (poor fit)

Strict multi-cloud portability requirements with minimal cloud coupling
Very constrained devices where footprint and runtime constraints dominate
Teams seeking only basic MQTT broker connectivity with minimal management

Vendor-acknowledged limitations / operational cautions

Greengrass release notes indicate behavior where dependency updates can be applied during component deployment; certain updates (for example, to the nucleus) may cause device restarts unless versions are pinned.

Ecosystem / lifecycle risks

Greengrass v1 end-of-support in 2026 is a significant lifecycle event. Documentation across AWS pages shows differing date references depending on region and doc version, so organizations should confirm the authoritative date for their accounts and regions.

Community-reported issues (non-exhaustive)

Confusing certificate and offline behavior (clients reporting SSL certificate errors when the core loses connectivity).
Component errors during deployment (for example, CloudWatch component runtime errors) that can block or complicate rollouts.
Console ergonomics for bulk deployment operations have been noted as limited by some users in early 2026.

02Why they buy

Advantages supported by evidence

Combines an edge runtime with cloud-managed deployment features integrated into the AWS IoT ecosystem.
Designed to operate with intermittent connectivity and support local autonomy.
Supports modular components and multiple workload packaging approaches (per AWS documentation).

Differentiation vs competitors

Compared with broker-only vendors, Greengrass provides a broader edge application deployment and runtime model.
Compared with general edge orchestration, Greengrass is optimized for the AWS IoT identity and policy model and for integrations with AWS services.

Where competitors have advantages

Azure emphasizes an open-source runtime and a container/module-first approach that may appeal to container-centric teams.
Open-source stacks and Kubernetes-based solutions can provide greater portability and reduce reliance on cloud-specific IoT identity models.
MQTT-focused vendors may offer predictable pricing models for high-connection, low-throughput scenarios depending on the plan.

03Field reports

Review platforms (G2) — selected excerpts (positive and negative)

G2 collects reviewer feedback that includes both positive and negative experiences. Examples paraphrased from reviews: Positive (G2): - Reviewers stated that Greengrass helps with building and managing IoT device software and moving compute to the edge. Negative (G2): - One reviewer noted a constraint with environment disk space on certain devices (reporting a modest disk space limit), which can affect deployment choices on smaller devices. Interpretation: G2 feedback indicates that reviewers value Greengrass’s edge-management capabilities, while also noting practical constraints such as runtime footprint on small devices.

Community / Reddit — selected excerpts and themes

Community forums provide operational commentary and troubleshooting experiences. Example of operational benefit (paraphrased): - A Reddit user reported that Greengrass cached data and maintained application functionality during periods when cloud services were unavailable. Operational pain examples (paraphrased): - Certificate and offline behavior confusion: a user reported that when the core device lost internet connectivity, the core certificate appeared to be removed after a brief period and the client experienced SSL certificate errors. - Deployment friction: users have questioned whether the AWS console supports bulk deployment updates efficiently, indicating limits in console workflow for some fleet operations. - Component/runtime issues: reports of CloudWatch component errors during deployments indicate that component failures can block or complicate rollouts; the same threads also include reports that AWS Support assisted in some cases.

Analyst / other review excerpts

Some analyst documents and paywalled research note Greengrass’s role in edge-device application platforms; direct access to individual enterprise-review quotes was not available from all analyst content reviewed.

Why customers select Greengrass over alternatives (common reasons)

Common selection drivers observed in documentation and user discussions include:

Integration with AWS IoT Core and other AWS services
Offline and intermittent connectivity operation
Remote deployment model for edge components (alternative to firmware-only update models)
Support for multiple workload types (Lambda-style functions, containers, native processes)

Why some customers leave or avoid Greengrass (churn drivers)

Common reasons cited in community discussions and from competitor narratives:

Cost predictability concerns, often driven by IoT Core connection and messaging fees rather than Greengrass alone
Operational complexity around certificate management, deployments, versioning, and debugging distributed systems
Vendor lock-in concerns related to AWS-specific identity and deployment models

Vendor/architecture materials (AWS)

AWS publishes reference architectures that include Greengrass for use cases such as livestock counting, connected mobility, and fleet management. These diagrams illustrate intended patterns (Greengrass as a host runtime for edge components, ML inference, and local processing). Critical evaluation: - Vendor-provided architecture diagrams are prescriptive and illustrate intended use, but are not equivalent to independently verified case studies. - Metrics such as latency reduction or cost savings are not consistently provided or methodologically transparent in vendor diagrams; organizations should validate vendor claims against their own workload and hardware.

Independent benchmarking (academic)

An academic benchmarking study reported improvements in latency and cost for certain workload classes when using Greengrass compared to other platforms examined. Such benchmarks can be informative but may not reflect specific deployment constraints (hardware class, connectivity profile, security policies, or message patterns).

Recommendation: conduct a pilot on representative hardware and workloads to validate performance and operational assumptions.

04Best fit

Company sizes

Typically mid-market to enterprise IoT operators.
Practical range: from small specialized IoT companies through large industrial enterprises with distributed sites.

Industries / verticals

Manufacturing and industrial automation
Energy and utilities
Transportation, mobility, and aerospace
Agriculture
Robotics and autonomous systems

Roles and personas

Decision makers: Head of IoT, VP of Engineering, IT/OT leadership, cloud platform owners, security leadership
End users: Embedded/edge engineers, DevOps/SRE, data engineers, field operations teams

Pain points Greengrass addresses

Intermittent connectivity and the need for local autonomy
Remote software deployment and updates across fleets
Local data reduction prior to cloud ingestion
Edge ML inference deployment and lifecycle management

Qualification criteria (good fit)

Strong AWS standardization (IAM, IoT Core, CloudWatch, S3/Kinesis)
Clear edge application packaging approach (components, containers, native processes)
Dedicated capacity for device provisioning, security, and fleet operations

05The pitch

What the product does (core value proposition)

AWS IoT Greengrass is an edge runtime together with an AWS cloud service used to deploy, manage, and update software on edge devices (for example, gateways, industrial PCs, and embedded Linux systems). It enables devices to: - Run local compute (including Lambda-style workloads, containers, or native processes) - Communicate locally and with AWS during intermittent connectivity - Filter and aggregate data on-premises and forward selected data to cloud services - Receive software deployments and configuration updates remotely (fleet management) AWS positions Greengrass as a mechanism to extend parts of the AWS programming model (messaging patterns, identity/authentication, managed deployment, integrations) to constrained or semi-constrained edge hardware. AWS documents Greengrass as an open-source edge runtime and associated cloud services. **Versioning note (important):** AWS has announced end-of-support for Greengrass v1 and recommends migration to Greengrass v2. Different AWS documentation pages and region-specific notices list different deprecation timelines. Organizations should treat this as a migration risk and confirm the authoritative timeline for their region/account via AWS Support and the specific v1 documentation they rely on.

Target market and market positioning

- **Target market:** Enterprises and mid-market companies building IoT/edge systems that already use AWS services (IoT Core, Kinesis, S3, Lambda, SageMaker, CloudWatch, etc.) and that require centrally managed software deployments across distributed devices. - **Common verticals:** Industrial/OT, manufacturing, robotics, energy/utilities, transportation, agriculture, and any environment with intermittent connectivity or low-latency local control. - **Positioning:** A managed edge application platform with tight integration into AWS IoT Core and AWS identity/security models.

Get a comprehensive analysis of AWS IoT Greengrass including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

Published Oct 13, 2026

01Common complaints

Cross-cloud portability is a first-class requirement: Greengrass is closely aligned with AWS IoT Core identities/policies and AWS deployment constructs.
The organization cannot invest in edge fleet operations: distributed deployments require CI/CD, observability, and incident response capabilities.
The deployment relies on Greengrass v1 and cannot migrate in the near term: v1 end-of-support dates in 2026 create a migration requirement.
The primary need is device connectivity (MQTT broker) and minimal additional management: a broker-centric deployment with a lightweight agent may be more appropriate.
The organization mandates Kubernetes-native tooling for edge workloads: KubeEdge or k3s-based approaches may align better operationally than Greengrass components.

Deal disqualifiers (poor fit)

Strict multi-cloud portability requirements with minimal cloud coupling
Very constrained devices where footprint and runtime constraints dominate
Teams seeking only basic MQTT broker connectivity with minimal management

Vendor-acknowledged limitations / operational cautions

Greengrass release notes indicate behavior where dependency updates can be applied during component deployment; certain updates (for example, to the nucleus) may cause device restarts unless versions are pinned.

Ecosystem / lifecycle risks

Greengrass v1 end-of-support in 2026 is a significant lifecycle event. Documentation across AWS pages shows differing date references depending on region and doc version, so organizations should confirm the authoritative date for their accounts and regions.

Community-reported issues (non-exhaustive)

Confusing certificate and offline behavior (clients reporting SSL certificate errors when the core loses connectivity).
Component errors during deployment (for example, CloudWatch component runtime errors) that can block or complicate rollouts.
Console ergonomics for bulk deployment operations have been noted as limited by some users in early 2026.

02Why they buy

Advantages supported by evidence

Combines an edge runtime with cloud-managed deployment features integrated into the AWS IoT ecosystem.
Designed to operate with intermittent connectivity and support local autonomy.
Supports modular components and multiple workload packaging approaches (per AWS documentation).

Differentiation vs competitors

Compared with broker-only vendors, Greengrass provides a broader edge application deployment and runtime model.
Compared with general edge orchestration, Greengrass is optimized for the AWS IoT identity and policy model and for integrations with AWS services.

Where competitors have advantages

Azure emphasizes an open-source runtime and a container/module-first approach that may appeal to container-centric teams.
Open-source stacks and Kubernetes-based solutions can provide greater portability and reduce reliance on cloud-specific IoT identity models.
MQTT-focused vendors may offer predictable pricing models for high-connection, low-throughput scenarios depending on the plan.

03Field reports

Review platforms (G2) — selected excerpts (positive and negative)

G2 collects reviewer feedback that includes both positive and negative experiences. Examples paraphrased from reviews:

Positive (G2):

Reviewers stated that Greengrass helps with building and managing IoT device software and moving compute to the edge.

Negative (G2):

One reviewer noted a constraint with environment disk space on certain devices (reporting a modest disk space limit), which can affect deployment choices on smaller devices.

Interpretation: G2 feedback indicates that reviewers value Greengrass’s edge-management capabilities, while also noting practical constraints such as runtime footprint on small devices.

Community / Reddit — selected excerpts and themes

Community forums provide operational commentary and troubleshooting experiences.

Example of operational benefit (paraphrased):

A Reddit user reported that Greengrass cached data and maintained application functionality during periods when cloud services were unavailable.

Operational pain examples (paraphrased):

Certificate and offline behavior confusion: a user reported that when the core device lost internet connectivity, the core certificate appeared to be removed after a brief period and the client experienced SSL certificate errors.
Deployment friction: users have questioned whether the AWS console supports bulk deployment updates efficiently, indicating limits in console workflow for some fleet operations.
Component/runtime issues: reports of CloudWatch component errors during deployments indicate that component failures can block or complicate rollouts; the same threads also include reports that AWS Support assisted in some cases.

Analyst / other review excerpts

Why customers select Greengrass over alternatives (common reasons)

Common selection drivers observed in documentation and user discussions include:

Integration with AWS IoT Core and other AWS services
Offline and intermittent connectivity operation
Remote deployment model for edge components (alternative to firmware-only update models)
Support for multiple workload types (Lambda-style functions, containers, native processes)

Why some customers leave or avoid Greengrass (churn drivers)

Common reasons cited in community discussions and from competitor narratives:

Cost predictability concerns, often driven by IoT Core connection and messaging fees rather than Greengrass alone
Operational complexity around certificate management, deployments, versioning, and debugging distributed systems
Vendor lock-in concerns related to AWS-specific identity and deployment models

Vendor/architecture materials (AWS)

Critical evaluation:

Vendor-provided architecture diagrams are prescriptive and illustrate intended use, but are not equivalent to independently verified case studies.
Metrics such as latency reduction or cost savings are not consistently provided or methodologically transparent in vendor diagrams; organizations should validate vendor claims against their own workload and hardware.

Independent benchmarking (academic)

Recommendation: conduct a pilot on representative hardware and workloads to validate performance and operational assumptions.

04Best fit

Company sizes

Typically mid-market to enterprise IoT operators.
Practical range: from small specialized IoT companies through large industrial enterprises with distributed sites.

Industries / verticals

Manufacturing and industrial automation
Energy and utilities
Transportation, mobility, and aerospace
Agriculture
Robotics and autonomous systems

Roles and personas

Decision makers: Head of IoT, VP of Engineering, IT/OT leadership, cloud platform owners, security leadership
End users: Embedded/edge engineers, DevOps/SRE, data engineers, field operations teams

Pain points Greengrass addresses

Intermittent connectivity and the need for local autonomy
Remote software deployment and updates across fleets
Local data reduction prior to cloud ingestion
Edge ML inference deployment and lifecycle management

Qualification criteria (good fit)

Strong AWS standardization (IAM, IoT Core, CloudWatch, S3/Kinesis)
Clear edge application packaging approach (components, containers, native processes)
Dedicated capacity for device provisioning, security, and fleet operations

05The pitch

What the product does (core value proposition)

Run local compute (including Lambda-style workloads, containers, or native processes)
Communicate locally and with AWS during intermittent connectivity
Filter and aggregate data on-premises and forward selected data to cloud services
Receive software deployments and configuration updates remotely (fleet management)

AWS positions Greengrass as a mechanism to extend parts of the AWS programming model (messaging patterns, identity/authentication, managed deployment, integrations) to constrained or semi-constrained edge hardware. AWS documents Greengrass as an open-source edge runtime and associated cloud services.

Versioning note (important): AWS has announced end-of-support for Greengrass v1 and recommends migration to Greengrass v2. Different AWS documentation pages and region-specific notices list different deprecation timelines. Organizations should treat this as a migration risk and confirm the authoritative timeline for their region/account via AWS Support and the specific v1 documentation they rely on.

Target market and market positioning

Target market: Enterprises and mid-market companies building IoT/edge systems that already use AWS services (IoT Core, Kinesis, S3, Lambda, SageMaker, CloudWatch, etc.) and that require centrally managed software deployments across distributed devices.
Common verticals: Industrial/OT, manufacturing, robotics, energy/utilities, transportation, agriculture, and any environment with intermittent connectivity or low-latency local control.
Positioning: A managed edge application platform with tight integration into AWS IoT Core and AWS identity/security models.

Get a comprehensive analysis of AWS IoT Greengrass including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →