Cargando...
Cargando...
Run AWS compute, messaging, ML inference, and data sync on connected devices — even offline
AWS IoT Greengrass extends AWS cloud capabilities to edge devices, enabling them to run Lambda functions, Docker containers, ML models, and local messaging even without internet connectivity. It acts as a bridge between IoT devices and the AWS cloud, synchronizing data when connectivity is restored. Greengrass V2 (current generation) introduced a component-based architecture, replacing the V1 group-based model with a more modular and flexible deployment system.
Enable IoT devices and edge hardware to run cloud-native workloads locally — reducing latency, preserving bandwidth, and maintaining functionality during connectivity loss
Use When
Avoid When
Component-based architecture (V2)
Modular, reusable components replace V1 groups — AWS provides pre-built components (nucleus, stream manager, shadow manager, etc.)
Local Lambda function execution
Lambda functions packaged as Greengrass components; runs locally without cloud invocation
Local MQTT pub/sub messaging
Built-in Moquette broker enables device-to-device and component-to-component messaging without internet
Device Shadow synchronization
Local shadow service syncs with AWS IoT Core shadows when connectivity is restored
Stream Manager
Buffers high-volume data locally; exports to Kinesis, S3, IoT SiteWise, IoT Analytics on reconnect
ML inference at the edge
Supports TensorFlow Lite, DLR, ONNX; integrates with SageMaker Edge Manager
Docker container support
Run Docker containers as Greengrass components (V2); requires Docker installed on core device
OTA (Over-the-Air) updates
Deploy component updates remotely via AWS IoT jobs integration
Fleet provisioning
Automated provisioning of large device fleets using AWS IoT fleet provisioning
Offline operation
Core functionality (local messaging, Lambda, shadows) works without internet; syncs on reconnect
Secret Manager integration
Securely deploy secrets (API keys, credentials) to edge devices via AWS Secrets Manager
IoT SiteWise integration
IoT SiteWise Edge runs as a Greengrass component for industrial data collection
Windows OS support
Added in Greengrass V2.5+ — Linux and Windows both supported as core device OS
Greengrass V1 (legacy)
Still available but AWS recommends migrating to V2; V1 uses group-based model, not component-based
ROS 2 integration
Robotics Operating System 2 components available for robotics workloads
Edge-to-Cloud MQTT Bridge
high freqGreengrass core devices connect to IoT Core via MQTT; local device messages are selectively forwarded to IoT Core topics for cloud processing. Enables offline buffering with eventual cloud sync.
Edge Stream Buffering and Export
high freqStream Manager buffers high-volume sensor/video data locally and exports to Kinesis Data Streams when connectivity is available. Critical for bandwidth-constrained environments.
ML Model Deployment to Edge
high freqTrain ML models in SageMaker, package them, and deploy to Greengrass core devices for local inference. SageMaker Edge Manager manages model versions and performance monitoring.
Local Lambda Execution
high freqLambda functions packaged as Greengrass V2 components execute locally on the core device. Enables event-driven processing at the edge without cloud invocation latency.
Industrial Edge Data Collection
medium freqIoT SiteWise Edge runs as a Greengrass component to collect, process, and structure industrial equipment data locally before syncing asset models to the cloud.
Edge Data Archival via Stream Manager
medium freqStream Manager exports processed edge data directly to S3 buckets for archival or batch analytics. Useful for storing video frames, sensor logs, or aggregated metrics.
Secure Credential Distribution
medium freqSecrets Manager secrets are securely deployed to Greengrass core devices, enabling components to access third-party APIs or local resources without hardcoding credentials.
Edge Device Monitoring
medium freqGreengrass core device metrics and component logs are published to CloudWatch for centralized monitoring, alerting, and operational visibility.
Edge Security Auditing
low freqIoT Device Defender monitors Greengrass core devices for security anomalies, policy violations, and suspicious behavior patterns.
Greengrass V2 uses a COMPONENT-based architecture — not groups (V1). If an exam question mentions 'Greengrass groups,' it is referring to V1. Modern deployments use components, recipes, and the Greengrass nucleus.
Offline operation is THE key differentiator for Greengrass. When exam scenarios describe intermittent connectivity, remote locations, or latency requirements that preclude cloud round-trips, Greengrass is almost always the correct answer over direct IoT Core usage.
Stream Manager is the correct answer for buffering HIGH-VOLUME IoT data (video, telemetry streams) at the edge and exporting to Kinesis, S3, or IoT Analytics. It is NOT just for simple MQTT messages — it is purpose-built for streaming data workloads.
Greengrass uses X.509 certificates and AWS IoT policies for device authentication — NOT IAM users or access keys. Core devices authenticate to AWS using certificates managed by AWS IoT Core. This is a critical security distinction.
OFFLINE = GREENGRASS. Any scenario with intermittent connectivity, remote locations, or latency requirements that prevent cloud round-trips → Greengrass is the answer over direct IoT Core
V1 uses GROUPS; V2 uses COMPONENTS + NUCLEUS. These are architecturally different — Lambda functions in V2 must be imported as components, not run natively as in V1
Greengrass devices authenticate with X.509 CERTIFICATES via IoT Core — NEVER with IAM access keys. Security questions about edge device authentication → certificates, not IAM
Local Device Shadows in Greengrass allow components to read/write device state without cloud connectivity. The local shadow service syncs with IoT Core shadows when the device reconnects — understand this sync lifecycle for exam questions about state management.
Greengrass V2 supports Docker containers as components — this enables running containerized workloads at the edge. Exam scenarios about running containerized applications on edge devices should point to Greengrass V2 with Docker component support.
The Greengrass nucleus is the core runtime component in V2. It manages component lifecycle, deployment, and inter-process communication (IPC). Every Greengrass V2 core device must run the nucleus — it is not optional.
For ML at the edge, the pattern is: Train in SageMaker → Package model → Deploy via Greengrass component → Run inference locally. SageMaker Edge Manager handles model versioning and fleet management. This end-to-end pattern is frequently tested in ML specialty and Solutions Architect exams.
Local MQTT messages between Greengrass components and local devices are FREE and do NOT count against IoT Core message limits. Only messages that are forwarded/bridged to the AWS cloud incur IoT Core messaging costs.
Greengrass deployments are revision-controlled. You can roll back to a previous deployment version if a component update causes issues — this OTA rollback capability is a key operational feature tested in DevOps and SysOps scenarios.
Common Mistake
Greengrass requires constant internet connectivity to function — without it, the device stops working
Correct
Greengrass is specifically designed for offline operation. Local Lambda execution, local MQTT pub/sub, local device shadows, and Stream Manager buffering ALL work without internet. The device syncs with AWS when connectivity is restored.
This is the #1 misconception and the primary reason Greengrass exists. Exam questions frequently test whether candidates understand that offline capability is a CORE feature, not a limitation to work around.
Common Mistake
AWS IoT Core and AWS Greengrass are the same service and can be used interchangeably
Correct
IoT Core is a cloud-based MQTT broker and device management service. Greengrass is edge software that runs ON devices, enabling local compute. They are complementary: Greengrass core devices connect TO IoT Core for cloud sync, but Greengrass provides local processing that IoT Core cannot.
Exam scenarios will present IoT architectures and ask which service to use. IoT Core = cloud ingestion/management; Greengrass = edge compute + offline capability. Confusing them leads to wrong architecture choices.
Common Mistake
Greengrass V1 and V2 are functionally identical — just a version number change
Correct
V1 and V2 are architecturally different. V1 uses a group-based model with direct Lambda support. V2 uses a component-based model where Lambda functions must be imported as components. V2 also added Windows support, Docker containers, and a modular nucleus — these are NOT available in V1.
Exam questions referencing 'Greengrass groups' indicate V1. Questions about 'components,' 'recipes,' or 'nucleus' indicate V2. Treating them as equivalent will cause you to select wrong answers about capabilities and architecture.
Common Mistake
Greengrass Lambda functions are the same as cloud Lambda functions — they run in AWS Lambda at the edge
Correct
Edge Lambda functions in Greengrass run locally ON the device using the Greengrass runtime — they do NOT invoke AWS Lambda in the cloud. In V2, they are packaged as Greengrass components. There is no cloud Lambda invocation, no Lambda cold start from AWS, and no Lambda pricing for local execution.
This distinction matters for latency, cost, and offline capability analysis. Candidates assume cloud Lambda is involved, which leads to incorrect conclusions about latency and connectivity requirements.
Common Mistake
You need to manage and update each Greengrass device individually — fleet management requires custom tooling
Correct
Greengrass V2 integrates with AWS IoT jobs and fleet provisioning for automated OTA updates, bulk deployments to thing groups, and fleet-wide component management. You can deploy to thousands of devices simultaneously using thing groups.
Exam scenarios about managing large IoT device fleets should point to Greengrass + IoT thing groups + deployments — not custom update scripts or manual per-device management.
Common Mistake
Greengrass only supports AWS-provided components — you cannot run custom code
Correct
Greengrass V2 supports three types of components: AWS-provided (pre-built, like Stream Manager), community components, and CUSTOM components. Custom components can be written in any language, packaged with a recipe file, and deployed to any core device.
The custom component capability is what makes Greengrass a general-purpose edge platform, not just an AWS-specific tool. Exam questions about running custom business logic at the edge should correctly identify custom Greengrass components as the solution.
GREENGRASS = 'Go Run Everything Even Now, Gathering Results At Secured Sites' — emphasizes edge execution, offline capability, and security
V2 key concepts: N-C-D-S = Nucleus (core runtime), Components (modular units), Deployments (push updates), Shadows (local state sync)
Stream Manager = 'BIKES': Buffer → IoT data → Kinesis/S3 Export → when connectivity is Established → at Scale
Greengrass vs IoT Core: 'Greengrass GROWS at the edge; IoT Core COLLECTS in the cloud'
Authentication: 'Certificates for Devices, Keys for Humans' — Greengrass devices use X.509 certs, never IAM access keys
CertAI Tutor · · 2026-02-22