AWS IoT Greengrass v2: Edge Computing for Factory Floors

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) 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:

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.

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.

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.

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):

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):

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:

# /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 for a technical assessment.