--- title: AWS IoT Greengrass v2: Edge Computing for Factory Floors description: AWS IoT Greengrass v2 brings cloud capabilities to the factory floor — running Lambda functions, ML inference, and data processing at the edge, even when internet connectivity is intermittent. Here is how to deploy it in manufacturing environments. url: https://www.factualminds.com/blog/aws-iot-greengrass-v2-edge-computing-factory-floor/ datePublished: 2026-04-06T00:00:00.000Z dateModified: 2026-04-06T00:00:00.000Z author: palaniappan-p category: Cloud Architecture tags: aws-iot, iot-greengrass, edge-computing, manufacturing, industrial-iot --- # AWS IoT Greengrass v2: Edge Computing for Factory Floors > AWS IoT Greengrass v2 brings cloud capabilities to the factory floor — running Lambda functions, ML inference, and data processing at the edge, even when internet connectivity is intermittent. Here is how to deploy it in manufacturing environments. Modern factories generate extraordinary volumes of data — vibration signals, temperature readings, pressure measurements, camera feeds, PLC state changes — at millisecond intervals. The reflex reaction is to send all of it to the cloud. But that approach collides with three hard realities of industrial environments: latency requirements that cloud round-trips cannot meet, WAN connectivity that is unreliable by design, and data transfer costs that scale painfully with high-frequency sensor data. **AWS IoT Greengrass v2** resolves this tension by splitting the work cleanly between edge and cloud. The cloud handles what it is genuinely good at — deployment management, long-term storage, analytics, model training, and a global control plane. The edge handles what proximity demands — real-time processing, local alarming, ML inference, and continued operation when the WAN link drops. This guide covers the Greengrass v2 architecture in depth and provides a practical deployment path for manufacturing environments, from hardware selection through component authoring, OPC-UA integration, edge ML, and production security. ## Why Edge Computing Is Non-Negotiable in Manufacturing Before examining the technology, it is worth being precise about why cloud-only IoT architectures fall short on factory floors. **Latency.** A round-trip from a factory floor in Ohio to us-east-1 and back takes 30–80 ms under normal conditions. For safety-critical control loops, motion coordination, or quality-gate decisions (pass/fail at 600 parts per minute), that latency is not just inconvenient — it is disqualifying. Edge processing keeps the decision local and sub-millisecond. **Connectivity.** Factory WAN links are unreliable. Cellular failover, fiber cuts, ISP maintenance windows, and RF interference from industrial equipment all interrupt connectivity. A pure-cloud IoT design stops working when the WAN goes down. Greengrass v2 continues operating and buffers data for later synchronization. **Cost.** AWS IoT Core charges $1 per million MQTT messages. A single machine generating 10 sensor readings per second produces 864,000 messages per day — just under the threshold at which costs become meaningful. A 500-machine factory floor produces 432 million messages per day. Edge filtering, aggregation, and local processing reduce cloud message volume by 80–95% in most deployments, cutting IoT Core costs proportionally. **Data gravity.** High-resolution vibration data, high-frequency current signatures, and video feeds generate gigabytes per hour. Sending raw streams to S3 is feasible in isolation; doing it for an entire plant across an industrial WAN is not. Edge processing compresses, downsamples, and extracts features locally, sending only the signal (not the raw stream) to the cloud. ## AWS IoT Greengrass v2 Architecture ### The Nucleus The Greengrass nucleus is the core runtime process that runs on your factory-floor gateway. It is open-source (Apache 2.0 license, available at [aws-greengrass/aws-greengrass-nucleus](https://github.com/aws-greengrass/aws-greengrass-nucleus)) and handles: - **Component lifecycle management** — downloading, installing, starting, stopping, and monitoring components - **Cloud communication** — MQTT connection to AWS IoT Core for deployment instructions and telemetry upload - **Local shadow service** — maintains device state locally; synchronizes with cloud when connectivity restores - **Deployment downloads** — fetches new component versions from S3 or the Greengrass component store - **IPC server** — local inter-process communication bus that components use to publish/subscribe to local topics The nucleus is itself a Greengrass component (`aws.greengrass.Nucleus`), versioned and updatable. The latest stable version as of this writing is **v2.16.1**, released December 2025. **Greengrass Nucleus Lite** (introduced in v2.3) is a stripped-down nucleus variant for resource-constrained devices — microcontrollers and embedded Linux devices with as little as 512 MB RAM. It supports a subset of full Nucleus capabilities and is the right choice for sensors and actuators that cannot run a full JVM. ### Components Everything that runs on a Greengrass device is a component. Components are independently versioned, deployable, and managed. Each component is defined by a **recipe** — a YAML or JSON document specifying: - Component name and version - Dependencies (other components this one requires) - Artifacts (binaries, scripts, model files) stored in S3 - Lifecycle commands: `Install`, `Run`, `Startup`, `Shutdown`, `Recover` - Configuration schema with default values (overridable at deploy time) AWS provides a catalog of **managed components** for common tasks: | Component | Purpose | | ----------------------------------------- | ------------------------------------------------------------------- | | `aws.greengrass.Nucleus` | Core runtime | | `aws.greengrass.LocalDebugConsole` | SSH-accessible debug dashboard | | `aws.iot.SiteWiseEdgeCollector` | OPC-UA / OPC-DA data collection for IoT SiteWise | | `aws.iot.SiteWisePublisher` | Sends SiteWise data to the cloud service | | `aws.greengrass.CloudWatch.Agent` | Publishes component metrics to CloudWatch | | `aws.greengrass.SecureTunneling` | Reverse SSH tunnels to factory gateways (no inbound firewall rules) | | `aws.iot.SageMakerEdgeManager` | Edge ML inference using SageMaker-compiled models | | `aws.greengrass.DockerApplicationManager` | Manages Docker containers as components | | `aws.greengrass.SecretManager` | Fetches secrets from AWS Secrets Manager, injects at runtime | Custom components can be written in Python, Java, C++, shell scripts, or packaged as Docker containers. ### Local Communication: The Moquette Broker Greengrass v2 includes a local MQTT broker (Moquette) that operates independently of cloud connectivity. Devices on the factory LAN publish sensor readings to local MQTT topics. Greengrass components subscribe to those topics, process the data, and either act locally or forward to AWS IoT Core. This architecture means the factory floor continues operating even during a WAN outage — local alarming, control decisions, and data buffering all work without cloud connectivity. ## Deployment Architecture for a Factory Floor A production Greengrass deployment follows a layered network architecture that isolates OT (operational technology) networks from IT and cloud connectivity: ``` Factory Floor (OT Network) DMZ / Gateway Host AWS Cloud (us-east-1) ────────────────────────── ────────────────── ────────────────────── PLC (Siemens S7-1500) Industrial PC AWS IoT Core (MQTT/TLS) OPC-UA server ──────OPC-UA──→ Greengrass v2 ────────→ IoT SiteWise SCADA system ──────OPC-UA──→ ├── SiteWise Collector Amazon Timestream Smart sensors ──────MQTT──→ ├── SiteWise Publisher Amazon S3 Cameras ──────HTTP──→ ├── DLR (edge ML) CloudWatch ├── SecureTunneling Amazon Managed Grafana └── SecretManager ``` The gateway PC sits in a DMZ between the OT VLAN and the WAN uplink. It connects inward to PLCs and SCADA via OPC-UA, and outward to AWS IoT Core via MQTT over TLS 1.3 on port 8883. No inbound connections are required from the cloud — Greengrass initiates all cloud connections outbound. ## Hardware Selection for Factory Deployments Greengrass v2 minimum requirements: 1 GB RAM, 500 MB disk, Java 8 or 11, Linux or Windows x86_64 / ARM64 / ARMv7l. **Recommended hardware by use case:** - **Standard data collection (OPC-UA, MQTT forwarding):** Moxa MC-7200 or Advantech UNO-2484G industrial PCs. These are DIN-rail mounted, rated for -40°C to 70°C operating range, support dual WAN (fiber + LTE failover), and run Ubuntu 22.04 LTS. - **Edge ML inference (camera-based quality inspection):** NVIDIA Jetson AGX Orin or Xavier NX. GPU-accelerated inference for TensorFlow Lite or ONNX models. Runs Greengrass v2 on JetPack 5.x (Ubuntu 20.04 base). - **High-availability deployments:** Pair two gateway PCs in active-passive configuration. Greengrass supports multiple core devices in a thing group — if the primary gateway goes offline, the secondary continues processing with its local components. - **Resource-constrained sensors:** Raspberry Pi 4 (4 GB RAM variant) running Greengrass Nucleus Lite for lightweight data forwarding tasks. ## Installing AWS IoT Greengrass v2 The Greengrass installer automates provisioning of the IAM role, X.509 certificate, and IoT thing registration in a single command. **Step 1: Create IAM role for the Greengrass core device.** The role needs policies for: `IoTCoreMessageBroker`, `SiteWise`, `S3` (for artifact downloads), `CloudWatch`, and `Secrets Manager`. AWS provides the managed policy `AWSGreengrassCorePolicy` as a starting point. **Step 2: Download the Greengrass installer.** ```bash curl -s https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-nucleus-latest.zip \ -o greengrass-nucleus-latest.zip unzip greengrass-nucleus-latest.zip -d GreengrassInstaller ``` **Step 3: Run the installer with automatic provisioning.** ```bash sudo java \ -Droot="/greengrass/v2" \ -Dlog.store=FILE \ -jar ./GreengrassInstaller/lib/Greengrass.jar \ --aws-region us-east-1 \ --thing-name FactoryGateway01 \ --thing-group-name PlantA-Gateways \ --component-default-user ggc_user:ggc_group \ --provision true \ --setup-system-service true \ --tes-role-name GreengrassV2TokenExchangeRole \ --tes-role-alias-name GreengrassCoreTokenExchangeRoleAlias ``` The `--provision true` flag creates the IoT thing, generates the X.509 certificate, and attaches the IAM role. The `--setup-system-service true` flag registers Greengrass as a `systemd` service that starts automatically on boot. **Step 4: Verify installation.** ```bash sudo systemctl status greengrass.service sudo tail -f /greengrass/v2/logs/greengrass.log ``` A healthy Greengrass installation shows `Active: active (running)` and log lines confirming MQTT connection to IoT Core. ## Writing a Custom Greengrass Component Custom components let you run your own business logic at the edge. Here is a complete example: a Python component that reads a temperature value from the local MQTT broker, checks a threshold, and publishes an alert to AWS IoT Core if the threshold is exceeded. **Component recipe (`recipe.yaml`):** ```yaml RecipeFormatVersion: '2020-01-25' ComponentName: com.factualminds.TemperatureMonitor ComponentVersion: '1.0.0' ComponentDescription: 'Monitors temperature sensors and triggers alerts' ComponentPublisher: FactualMinds ComponentDependencies: aws.greengrass.Nucleus: VersionRequirement: '>=2.0.0' ComponentConfiguration: DefaultConfiguration: alertThreshold: 85.0 sensorTopic: 'factory/sensors/temperature' alertTopic: 'factory/alerts/temperature-high' Manifests: - Platform: os: linux Lifecycle: Install: RequiresPrivilege: false Script: pip3 install awsiotsdk Run: Script: >- python3 {artifacts:path}/temperature_monitor.py --threshold {configuration:/alertThreshold} --sensor-topic {configuration:/sensorTopic} --alert-topic {configuration:/alertTopic} Artifacts: - URI: s3://your-bucket/components/temperature_monitor.py ``` **Component code (`temperature_monitor.py`):** ```python import json import argparse from awsiot.greengrasscoreipc import connect from awsiot.greengrasscoreipc.model import ( SubscribeToTopicRequest, PublishToIoTCoreRequest, QOS, ) def main(): parser = argparse.ArgumentParser() parser.add_argument('--threshold', type=float, default=85.0) parser.add_argument('--sensor-topic', required=True) parser.add_argument('--alert-topic', required=True) args = parser.parse_args() ipc_client = connect() # Subscribe to local MQTT topic (from sensors on factory LAN) subscribe_request = SubscribeToTopicRequest(topic=args.sensor_topic) handler = ipc_client.new_subscribe_to_topic() handler.activate(subscribe_request) print(f"Monitoring {args.sensor_topic}, threshold={args.threshold}°C") for event in handler.get_response().result(): payload = json.loads(event.binary_message.message) temp = payload.get('temperature', 0) if temp > args.threshold: alert = { 'asset_id': payload.get('asset_id'), 'temperature': temp, 'threshold': args.threshold, 'severity': 'HIGH' if temp > args.threshold + 10 else 'WARNING', } publish_request = PublishToIoTCoreRequest( topic_name=args.alert_topic, qos=QOS.AT_LEAST_ONCE, payload=json.dumps(alert).encode(), ) ipc_client.new_publish_to_iot_core().activate(publish_request) print(f"Alert published: {alert}") if __name__ == '__main__': main() ``` Deploy this component to a thing group via the Greengrass console or the `aws greengrassv2 create-deployment` API call. ## OPC-UA Integration with AWS IoT SiteWise OPC-UA is the dominant protocol for connecting PLCs, SCADA systems, and industrial historians to cloud infrastructure. AWS does not implement OPC-UA in IoT Core — it is implemented in the **SiteWise Edge** components that run on Greengrass v2. The two components that work together for SiteWise Edge OPC-UA collection: - **`aws.iot.SiteWiseEdgeCollector`** — connects to OPC-UA servers, reads node values at configured scan rates, buffers locally - **`aws.iot.SiteWisePublisher`** — takes the collected data and sends it to the cloud IoT SiteWise service **Data flow:** ``` PLC (OPC-UA server) ↓ OPC-UA (Sign & Encrypt, Basic256Sha256) SiteWise Edge Collector component ↓ local IPC SiteWise Publisher component ↓ MQTT/TLS to IoT Core AWS IoT SiteWise (cloud) ↓ Amazon Managed Grafana dashboards ``` Configure the gateway and data sources in the IoT SiteWise console (Gateways section), then deploy the SiteWise components to your Greengrass device group. Node-to-asset-property mappings are configured in SiteWise and pushed to the edge gateway automatically. **Important dashboard note:** AWS IoT SiteWise Monitor entered maintenance mode on November 7, 2025 and is no longer available to new customers. For new dashboard deployments, use **Amazon Managed Grafana** with the native SiteWise data source plugin. Managed Grafana provides equivalent visualization, superior alerting capabilities, and active feature development. ## Edge ML Inference for Quality Control Edge ML inference eliminates the cloud round-trip for time-sensitive decisions. A typical quality control deployment: **Use case:** A USB camera mounted at a conveyor belt end-of-line station. The system must classify parts as pass/fail at 600 parts per minute (100ms per part). Cloud inference is too slow; the decision must happen locally. **Architecture:** 1. Train a binary classification model in Amazon SageMaker (MobileNet V3 or EfficientNet-Lite for ARM efficiency) 2. Compile the model with **SageMaker Neo** targeting the gateway hardware (ARM64 or x86_64). Neo optimizes the model for the target compute, reducing inference time by 2–4x 3. Package the compiled model as a Greengrass artifact in S3 4. Deploy the **`aws.iot.SageMakerEdgeManager`** component (or the open-source **DLR runtime** component for TFLite/ONNX models) to the gateway 5. Write a custom component that captures frames from the USB camera (OpenCV), passes them to the DLR runtime, reads the classification result, and publishes pass/fail to AWS IoT Core 6. Update the model without downtime by deploying a new component version — Greengrass downloads the new model while the old one continues running **Inference performance targets on NVIDIA Jetson AGX Orin (GPU):** MobileNet V3 classification at 5ms per frame — well within the 100ms budget. On a CPU-only industrial PC (Intel Core i5), EfficientNet-Lite0 runs at 20–40ms per frame. ## TPM 2.0 Hardware Security Module Support (v2.16.0+) Greengrass v2.16.0 (November 2025) added support for **TPM 2.0 hardware security modules**, the most significant security enhancement in recent Greengrass history. In standard deployments, the Greengrass X.509 private key is stored as a file on the gateway filesystem. If an attacker gains OS-level access to the gateway, they can extract the private key and impersonate the device. With TPM 2.0 support, the private key is generated and stored inside the TPM — it never leaves the hardware. All cryptographic operations (signing, key exchange) happen inside the TPM chip. **Configuration** uses a PKCS#11 provider in the Greengrass nucleus configuration: ```yaml # /greengrass/v2/config/config.yaml (nucleus config) system: certificateFilePath: '/greengrass/v2/thingCert.crt' privateKeyPath: 'pkcs11:token=greengrass;object=greengrass-private-key' rootCaPath: '/greengrass/v2/rootCA.pem' rootpath: '/greengrass/v2' thingName: 'FactoryGateway01' services: aws.greengrass.Nucleus: configuration: cryptography: pkcs11Provider: '/usr/lib/x86_64-linux-gnu/pkcs11/tpm2_pkcs11.so' ``` Industrial PCs from Moxa (MC-7200 series) and Advantech (ARK series) ship with TPM 2.0 chips as standard hardware. Enabling Greengrass TPM 2.0 support is the right call for any deployment where physical gateway security is a concern. ## Remote Management via Secure Tunneling Factory gateways are inside private networks with no inbound firewall openings. The **`aws.greengrass.SecureTunneling`** component solves the remote access problem without requiring any inbound firewall rules. How it works: 1. Engineer initiates a secure tunnel session from the AWS console (or API) 2. Greengrass SecureTunneling component receives a notification via MQTT from IoT Core 3. The component opens an outbound WebSocket connection to the AWS IoT Core secure tunneling endpoint 4. The engineer connects their SSH client to the local proxy endpoint 5. SSH traffic flows through the tunnel — fully encrypted, audited in CloudTrail, automatically closed when the session ends This approach satisfies IEC 62443 requirements for remote access: no persistent inbound connections, session-limited access, full audit trail, and credential-based authorization. ## Monitoring Greengrass Deployments in Production **CloudWatch metrics** published by Greengrass components: - `ComponentStatus` — per-component health (RUNNING, ERRORED, BROKEN) - `DeploymentStatus` — deployment success/failure per device - Custom metrics published by your components via the CloudWatch Agent component **Recommended CloudWatch alarms:** - `ComponentStatus != RUNNING` for critical components (SiteWise Collector, your custom components) - Deployment failure rate > 5% across a thing group - Custom: local MQTT message rate drops to 0 (sensor disconnection) **Thing group organization:** Structure thing groups by plant, line, and machine type. Target deployments at the thing group level — a single deployment document deploys to all gateways in the group simultaneously, with configurable rollout rate and failure thresholds. **Deployment rollout strategy for production:** 1. Deploy to a `staging` thing group (1–2 devices) — run for 48 hours 2. Deploy to `production-pilot` (10% of devices) — monitor component health for 24 hours 3. Full rollout to `production-all` — configure `deploymentPolicies.failureHandlingPolicy: ROLLBACK` so Greengrass automatically reverts if error rate exceeds your threshold ## Summary: What Greengrass v2 Enables for Manufacturing AWS IoT Greengrass v2 is not merely a message relay between factory equipment and the cloud. It is a full edge compute platform that happens to be managed from the AWS console. For manufacturing environments, it provides: - **Offline resilience** — continues operating when WAN connectivity is lost - **Latency-sensitive processing** — sub-millisecond local decisions for quality control and safety - **Cost control** — 80–95% reduction in cloud data transfer by processing and filtering at the edge - **Security** — mTLS, Secrets Manager integration, TPM 2.0 support, and IEC 62443-aligned network architecture - **Operational simplicity** — update components across hundreds of factory gateways from a single deployment document, with automatic rollback on failure The factory floor and the cloud are no longer in tension. Greengrass v2 makes them complementary. --- _FactualMinds is an AWS Select Tier Consulting Partner specializing in industrial IoT architecture on AWS. If you are planning a Greengrass v2 deployment or migrating from Greengrass v1, [contact our team](/contact-us/) for a technical assessment._ ## FAQ ### What is AWS IoT Greengrass v2? AWS IoT Greengrass v2 is an open-source edge runtime that extends AWS capabilities to factory-floor devices and gateways. It runs AWS Lambda functions, Docker containers, custom components, and ML inference locally — without requiring constant cloud connectivity. Greengrass v2 uses a component-based architecture: each capability (Lambda function, ML model, protocol adapter, local message broker) is a standalone component that can be deployed, updated, and monitored from the AWS console or via CI/CD pipelines. ### What changed from AWS IoT Greengrass v1 to v2? AWS IoT Greengrass v2 (the current version, with v2.16.1 released December 2025) introduced a component-based architecture replacing the monolithic v1 model. Key changes: components are independently deployable and versioned; the nucleus (core runtime) is open-source under Apache 2.0; deployment configuration is now managed via deployment documents (JSON); Greengrass v2 supports Linux and Windows (v1 was Linux-only); and Greengrass Nucleus Lite is available for resource-constrained devices. AWS IoT Greengrass v1 is deprecated — all new deployments should use v2. ### What hardware can run AWS IoT Greengrass v2? AWS IoT Greengrass v2 runs on Linux (x86_64, ARM64, ARMv7l) and Windows (x86_64) devices with at least 1 GB RAM, 500 MB disk space, and Java 8 or 11. Common factory deployments: industrial PCs running Ubuntu or Debian, Raspberry Pi (ARM), AWS Snowball Edge, industrial gateways from Moxa or Advantech, and NVIDIA Jetson modules for GPU-accelerated edge ML. For resource-constrained devices with limited RAM, use Greengrass Nucleus Lite (v2.3+). ### How does Greengrass v2 handle offline operation? AWS IoT Greengrass v2 continues operating when cloud connectivity is lost. The local MQTT broker (Moquette) routes messages between local devices and components. Lambda functions and custom components continue running. The local shadow service maintains device state offline. When connectivity restores, Greengrass synchronizes local shadows with AWS IoT Core, queues unsent MQTT messages, and downloads pending component deployments. This offline-first design is critical for factory environments with intermittent WAN connectivity. ### What is a Greengrass component? A Greengrass component is a unit of software for Greengrass devices — a Lambda function, a Docker container, a custom process, an ML model, or an AWS-provided component (like the OPC-UA collector for SiteWise, the CloudWatch agent, or the Secure Tunneling component). Each component has a recipe (YAML or JSON) defining its dependencies, lifecycle commands (install, run, shutdown), and configuration schema. Components are versioned and deployed via Greengrass deployment documents from the AWS console or API. ### How do I deploy ML inference at the edge with Greengrass v2? Use the SageMaker Edge Manager component (or the DLR component for open-source inference) to run ML models on Greengrass devices. Workflow: train model in SageMaker → compile with SageMaker Neo for target hardware → package as Greengrass component → deploy to devices. Models run locally for sub-millisecond inference without cloud round-trips. Common use: quality inspection cameras running image classification, vibration sensor anomaly detection using lightweight models. ### How do I update Greengrass components in production without downtime? Use rolling deployments via the Greengrass deployment API or console. Create a new component version, define a deployment document targeting a thing group, and configure rollout parameters (deployment failure handling: rollback or continue). Greengrass downloads the new component while the old one is running, then performs a graceful switchover. For zero-downtime, design components with graceful shutdown (respond to SIGTERM) and test deployments on a staging device group before production rollout. ### Is AWS IoT Greengrass v2 suitable for HIPAA or IEC 62443 compliance? Yes. Greengrass v2 supports the security controls required for regulated manufacturing environments. All communication between Greengrass core and AWS IoT Core uses mutual TLS with X.509 certificates. Component secrets (credentials, API keys) are managed via AWS Secrets Manager and injected at runtime. For IEC 62443 OT security, deploy Greengrass in a DMZ segment between the OT network and the AWS connection, using allowlisted MQTT topics and strict IAM policies. Greengrass v2 supports TPM 2.0 hardware security modules (added in v2.16.0, November 2025). --- *Source: https://www.factualminds.com/blog/aws-iot-greengrass-v2-edge-computing-factory-floor/*