AWS IoT Greengrass

An edge computing runtime that executes Lambda functions and ML inference on edge devices, enabling local processing to continue even with intermittent cloud connectivity

Overview

AWS IoT Greengrass is an open-source edge runtime for locally executing cloud capabilities on edge devices. It supports local execution of Lambda functions, machine learning model inference, local device-to-device messaging, and OTA (Over-The-Air) remote deployment of components. Greengrass V2 introduced a component model, enabling development, distribution, and updating of functionality as independent modules.

Why Process at the Edge - The Triple Challenge of Latency, Bandwidth, and Availability

In IoT systems, a centralized architecture that sends all data to the cloud for processing is not always optimal. In manufacturing line anomaly detection, milliseconds of decision delay can result in defective products escaping; transmitting all surveillance camera footage to the cloud incurs enormous bandwidth costs; and network outages cause devices to completely stop functioning. Greengrass is designed to solve this triple challenge by bringing cloud processing capabilities to the edge. Lambda functions and custom components run on the Greengrass Core device (gateway), executing locally-completable decisions immediately at the edge. By sending only aggregated and summarized data to the cloud, bandwidth is conserved, and local processing continues even when cloud connectivity is lost. Deploying ML models trained in SageMaker to Greengrass enables real-time execution of camera image object detection and vibration data anomaly detection at the edge, with only inference results reported to the cloud - an efficient architecture.

V2 Component Model and Deployment Mechanisms

The component model introduced in Greengrass V2 fundamentally changed edge application development and operations. In V1, Lambda functions and connectors were deployed in tight coupling, but in V2, all functionality is defined as independent components. Each component declares its lifecycle, dependencies, and configuration parameters in a recipe (YAML/JSON), combined with artifacts (executables, scripts, ML models, etc.) for deployment. AWS-provided public components (Log Manager, Stream Manager, ML inference components, etc.) can be freely combined with custom components you build. Deployment is executed OTA from the cloud and can be rolled out by device group (Thing Group). Defining rollback settings enables automatic reversion to the previous version on deployment failure. Azure's equivalent service, Azure IoT Edge, also adopts a modular container-based architecture, but Greengrass V2 also offers a lightweight process-based execution model that doesn't depend on containers, providing an advantage in supporting resource-constrained small devices.

Building Intra-Edge Data Flows with Local Messaging and IPC

The local messaging capability that enables message exchange between multiple client devices connected to a Greengrass Core device without routing through the cloud significantly improves edge system responsiveness. Deploying the local MQTT broker component makes the Greengrass Core function as an MQTT broker, allowing client devices to communicate locally using the same MQTT protocol as cloud IoT Core. For inter-component communication, an IPC (Inter-Process Communication) mechanism is provided, exchanging events via publish/subscribe. For example, a temperature sensor component publishes measurements to a local topic, an anomaly detection component subscribes to perform threshold evaluation, and passes results to an actuator control component - building intra-edge data flows. The Stream Manager component enables automatic export of locally generated data to S3 or Kinesis, buffering locally during network outages and retransmitting after recovery. Related books on edge computing (Amazon) cover these intra-edge data flow design patterns in detail.

ShareXB!