The "Internet is Down" Problem
In a factory, a robotic arm cannot wait 200ms for a round-trip to the cloud to decide "Stop! Human detected." It needs to react in under 1ms. Cloud latency is physically impossible to eliminate — the speed of light limits you. Beyond latency, if the factory's internet connection drops, cloud-dependent logic stops working entirely. For a production line, that means downtime and lost revenue.
This is the edge computing problem: some logic must run physically close to the hardware, regardless of cloud connectivity.
The Solution: IoT Greengrass
AWS IoT Greengrass is software you install on a local device — a Raspberry Pi, an industrial gateway, a ruggedized server on the factory floor — that turns it into a mini-AWS execution environment. It runs your cloud-authored code locally.
Core Capabilities:
1. Local Compute
You write Lambda functions or Docker containers in the cloud (using the normal AWS console), then deploy them to the Greengrass Core device. They execute locally on the hardware. A Lambda function that detects a human in a camera frame runs in milliseconds, with no internet required.
2. Local MQTT Broker
Greengrass runs its own local MQTT broker. Sensors and actuators in the factory communicate with the Greengrass Core over the local network — no internet hop. The Greengrass Core then decides what to forward to the cloud and what to handle locally.
Factory Floor (Local Network)
┌─────────────────────────────────────────────┐
│ Sensor A ──MQTT──┐ │
│ Sensor B ──MQTT──┤ │
│ Camera ──MQTT──┼──► Greengrass Core │
│ Valve ◄─MQTT──┘ (Raspberry Pi) │
│ │ │
└─────────────────────────┼───────────────────┘
│ (internet, when available)
▼
AWS IoT Core (Cloud)
3. Stream Manager
Greengrass includes a Stream Manager component that buffers data locally on disk and uploads it to AWS (Kinesis Data Streams, S3, IoT Analytics) when bandwidth is available. If the internet drops, data is not lost — it queues locally and uploads when connectivity resumes. You configure priority, bandwidth limits, and retry policies.
4. ML Inference at the Edge
You train a machine learning model in Amazon SageMaker in the cloud. You export it (TensorFlow Lite, ONNX, etc.) and deploy it to Greengrass as a component. The device runs inference locally — detecting defective parts on a conveyor belt, recognizing faces at a door, classifying audio anomalies in a machine — without sending raw video or audio to the cloud. This also reduces data transfer costs dramatically.
5. Over-the-Air (OTA) Updates
Greengrass manages the deployment lifecycle. You push a new version of a Lambda function or container from the AWS console, and Greengrass handles the download, verification, and rollout to your fleet of edge devices — with rollback if the deployment fails.
Greengrass vs. IoT Core — when to use which:
| Concern | IoT Core | Greengrass |
|---|---|---|
| Cloud connectivity required | Yes | No (works offline) |
| Latency tolerance | 50–500ms | <1ms |
| Local compute | No | Yes |
| Use case | Telemetry ingestion, remote commands | Real-time control, edge ML, offline operation |
A common interview question: "What's the difference between IoT Greengrass and just running code on a server near your devices?" The key differentiators are: (1) Managed deployment — Greengrass integrates with AWS deployment pipelines; you push from the console and it handles OTA updates with rollback. (2) Local shadow sync — Greengrass maintains local copies of Device Shadows so edge logic can read/write device state without a cloud round-trip. (3) Credential management — Greengrass rotates credentials automatically; a DIY server would require you to manage certificate rotation across your fleet manually.