Build edge AI agents with the AWS IoT Greengrass Component SDK for Rust

As Internet of Things (IoT) deployments scale to millions of sensors generating continuous data streams, processing everything in the cloud becomes impractical because of latency, bandwidth cost, and connectivity constraints. Edge AI agents solve this by classifying sensor anomalies locally on resource-constrained devices and escalating only complex reasoning to the cloud. The AWS IoT Greengrass Component SDK for Rust makes this possible on devices with tight memory budgets (under 256 MB RAM), with a runtime footprint under 0.5 MB.

Paired with a purpose-built Open Neural Network Exchange (ONNX) classification model, Rust-based AWS IoT Greengrass components run AI inference locally while leaving the majority of device memory available for other processes. ONNX provides a compact, optimized model format designed for efficient inference across hardware platforms, including ARM and x86 CPUs, GPUs, and dedicated edge accelerators.

In this post, we describe the architecture and design decisions for building a Rust-based AWS IoT Greengrass component that runs a quantized ONNX anomaly classification model for local sensor data analysis on industrial gateways. We explain why we chose Rust over Python, ONNX over a general-purpose model, and a bounded offline queue. We also include a component recipe excerpt and deployment commands so you can reproduce the pattern. When the local model identifies a complex anomaly requiring deeper analysis, the component escalates to a cloud-based agent running on Amazon Bedrock AgentCore. Escalation travels through AWS IoT Core Message Queuing Telemetry Transport (MQTT) messaging.

Use case

A water utility operates 2,000 remote pump stations across a rural distribution network. Each station has a microcontroller-class gateway (ARM Cortex-A53, 256 MB RAM, intermittent cellular connectivity) monitoring flow rate, pressure, vibration, and temperature sensors.

At these remote sites, an undetected pump fault can escalate into an outage that is expensive and slow to repair. Crews often travel hours to reach a station, and a single truck roll can take days to schedule, so a failure caught late costs far more than one caught early. Early, on-site detection is what keeps a minor anomaly from becoming a multi-day service disruption.

To deliver that early detection given the constraints of each site, the solution must meet the following requirements:

Classify sensor anomalies locally within 200 ms, because a pump exhibiting early failure signs must be flagged fast enough to act before damage compounds. A round-trip to the cloud over intermittent cellular links is both too slow and unavailable during outages.
Operate during network outages (cellular connectivity drops for hours during storms), when local detection is the only line of defense.
Escalate complex multi-sensor correlations to a cloud agent for root cause analysis and work order generation.
Keep per-gateway memory usage under 64 MB for the AI component. The gateway’s 256 MB RAM is shared with the operating system, the Greengrass nucleus, and the existing supervisory control and data acquisition (SCADA) and telemetry processes that must keep running.

Architecture

The following diagram shows the edge-to-cloud AI pattern with the Rust Greengrass component.

Figure 1: Edge-to-cloud AI architecture for the Rust Greengrass component

The architecture spans two zones: the edge pump station gateway and the AWS Cloud. The edge gateway hosts the Rust Greengrass component and the ONNX classifier. The cloud hosts AWS IoT Core, IoT rules, AWS Lambda, Amazon Bedrock AgentCore runtime, and Amazon DynamoDB for historical telemetry storage. Amazon Simple Storage Service (Amazon S3) stores the binary and model artifacts for fleet deployment.

The following walkthrough describes the data flow through the architecture:

Industrial sensors publish readings through Modbus (an industrial communication protocol) to the gateway. The Rust Greengrass component receives them through local inter-process communication (IPC) at 1-second intervals.
The Rust component buffers a full 60-second sensor window, runs it through the quantized ONNX classifier, and produces a confidence-scored anomaly classification. The repository ships a sample model for testing. For production workloads, scale the model to your classification complexity.
The component publishes telemetry, alerts, and escalation messages to AWS IoT Core through an MQTT queue. During network outages, messages queue locally in first-in, first-out (FIFO) order (up to 1,000 messages) and drain on reconnect.
AWS IoT Core routes messages to two IoT rules. The escalation rule forwards complex anomalies to an AWS Lambda function, which invokes a Strands Agents-based agent on AgentCore runtime.
The agent queries Amazon DynamoDB for 7-day historical sensor baselines at that station to inform its root cause analysis.
The telemetry IoT rule performs a direct write of sensor data to Amazon DynamoDB (90-day time to live) for historical storage. No Lambda function is required on this path.
The agent publishes a recommendation (severity, probable cause, recommended action) back to the Rust component through AWS IoT Core MQTT.
The Rust component displays the recommendation as a local alert on the Human-Machine Interface (HMI).
AWS IoT Greengrass pulls binary and model artifacts from Amazon S3 and deploys them to the edge device during fleet deployments.

This flow places classification at the edge (steps 1–2) because the utility’s 200 ms latency target is faster than a round-trip to the cloud over intermittent cellular connectivity. A cloud-only design would add network latency to every classification and stop working entirely during the outages these stations regularly experience. The component escalates to the cloud (steps 4–5) only for the small fraction of anomalies that need historical correlation. This keeps the reasoning-heavy work where compute is abundant while time-sensitive decisions stay local.

Choosing between the Python SDK and Rust SDK

AWS IoT Greengrass supports component development in multiple languages. The AWS IoT Greengrass Component SDK provides IPC APIs in C, C++, and Rust. For Python and Java components, use the AWS IoT Device SDK (v2) for Greengrass IPC. For AI workloads on constrained devices (under 256 MB RAM), the minimal footprint of the Rust Component SDK leaves more memory available for the model and inference runtime. For devices with more available memory, the Python path (through the Device SDK) provides faster development iteration and access to the broader set of Python ML libraries.

The following table summarizes the characteristics relevant to constrained-device AI workloads. Values are based on testing with the sample workload in the sample-greengrass-rust-edge-ai-agent. See the repository’s benchmarks/ directory for reproduction steps.

Characteristic	Python SDK	Rust SDK
Runtime memory footprint	Approximately 30 MB	Less than 0.5 MB
Cold start time	2-5 seconds (typical)	Less than 100 ms (typical)
ONNX inference integration	Using `onnxruntime-python` (additional 30+ MB)	Using `ort` crate (statically linked, included in 22 MB binary)
Concurrency model	Thread-based, constrained by the global interpreter lock (GIL)	Async tasks (`tokio`)
Binary size (stripped)	N/A (interpreted)	Approximately 22 MB (ONNX Runtime static link dominates)
Total footprint (runtime + model + inference)	70-110 MB (estimated)	22 MB peak resident set size (RSS) measured with sample model. Up to 35 MB projected with 12 MB production model

For the pump station use case (64 MB budget for the AI component), the Rust SDK is the appropriate choice. For devices with 1+ GB RAM where development speed is prioritized, the Python SDK remains the faster path to production.

Implementation

This section walks through the design of the solution, starting with the two deployable artifacts. It then covers the edge component’s task structure, model selection for constrained devices, the offline-first pattern, and the cloud agent design.

You deploy two artifacts:

Rust Greengrass component – Cross-compiled for aarch64-unknown-linux-gnu (ARM64), deployed using a Greengrass deployment to the device fleet. Contains the inference binary, ONNX model file, and component recipe.
AWS Cloud Development Kit (AWS CDK) – Deploys the AWS IoT Core rules, AWS Lambda function, AgentCore harness (a capability of Amazon Bedrock AgentCore), Amazon DynamoDB table (telemetry, 90-day time to live (TTL)), and AWS Identity and Access Management (IAM) roles.

Edge component design

The Rust component uses three logical tasks running concurrently using tokio (Rust’s asynchronous runtime):

Ingestion and inference task – Subscribes to local IPC topics using the aws-greengrass-component-sdk crate and buffers sensor readings in a sliding window (60 seconds). Classifies every full window using the ort crate (Rust bindings for ONNX Runtime) and returns confidence-scored anomaly types (normal, single-sensor fault, multi-sensor correlation, unknown). Because readings arrive at 1 hertz (Hz) and inference completes in under 50 ms, ingestion and inference run sequentially in the same task.
Communication task – Publishes classified alerts locally or escalates to the cloud through MQTT. Handles offline queuing with a bounded FIFO queue (1,000 messages, drop-oldest on overflow) for periods without connectivity. We bound the queue at 1,000 messages because unbounded buffering risks exhausting the gateway’s limited RAM during a prolonged outage. Dropping the oldest messages first keeps the most recent anomaly state available when connectivity returns.
Response task – Subscribes to the cloud recommendation topic and appends received recommendations to a local log file for HMI display.

The AWS IoT Greengrass Rust SDK provides synchronous C bindings through a foreign function interface (FFI). Our component bridges these to the tokio async runtime using channels, so IPC subscription callbacks feed the async ingestion loop without blocking.

The component recipe is the configuration file that defines a Greengrass component’s lifecycle and dependencies. It specifies aarch64 as the target architecture and declares the ONNX model as an artifact dependency stored in Amazon Simple Storage Service (Amazon S3). AWS IoT Greengrass downloads the model during deployment and places it at a known filesystem path.

Model selection for edge

For structured sensor data classification (time series anomaly detection across four sensor channels), a purpose-built ONNX model is more appropriate than a general-purpose language model. A general-purpose language model is far larger than the memory budget allows. It also adds inference latency that exceeds the 200 ms target and offers no accuracy benefit on fixed-schema numeric sensor data. ONNX gives a compact, quantized model that runs in the ort crate with no separate runtime to install. The repository ships a sample model for testing. The following list describes its input format, output classes, architecture, size, and measured inference latency:

Input: 60-second sliding window of four sensor channels (240 data points, channel-major layout).
Output: four classes with softmax confidence (normal, single_sensor_fault, multi_sensor_correlation, unknown).
Architecture: 1D convolutional neural network (CNN) with Squeeze-and-Excitation channel attention.
Size: approximately 25,000 parameters, approximately 23 KB (sufficient for demonstration).
Inference latency: less than 50 ms on ARM Cortex-A53 (see the benchmarks/ directory in the sample-greengrass-rust-edge-ai-agent for reproduction steps).

For production workloads with more complex classification requirements, scale the model architecture. A 10 million-parameter model at int8 quantization produces approximately 12 MB, which fits well within the 64 MB memory budget.

Train this model using Amazon SageMaker with historical sensor data, export to ONNX format, and quantize for edge deployment.

Offline-first pattern

The component operates fully offline for local classifications. During network outages:

Local classifications continue without interruption (the model runs locally, no cloud dependency).
Cloud escalation messages queue in the bounded FIFO queue, which holds up to 1,000 messages. When the queue overflows, the oldest messages drop.
When connectivity returns, the communication task drains the queue in order, and the cloud agent processes backlogged escalations with timestamps intact.

The device doesn’t block on network availability for local safety decisions.

Cloud agent design

Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale with your choice of framework or model. This solution runs a Strands Agents-based agent on the AgentCore runtime. The agent uses two tools:

query_history – Queries Amazon DynamoDB for 7-day sensor baselines at the specified station and computes statistics (mean, standard deviation, trend).
publish_response – Publishes the recommendation back to the device through AWS IoT Core MQTT.

The DynamoDB telemetry table is partitioned on thing_name with ts (ISO 8601 timestamp) as the sort key, so the agent can range-query the last 7 days for a single station efficiently.

The agent receives escalation messages containing the following data:

Sensor readings (60-second window).
Local model’s preliminary classification and confidence score.
Device metadata (pump station ID, installation date, last maintenance).

The agent acts as a root cause analysis (RCA) agent. It queries the station’s historical sensor patterns, reasons about the root cause, and generates a structured response containing severity level, probable cause, recommended action, and supporting evidence from the historical data.

The following example shows a structured RCA response that the agent publishes back to the device:

{
    "thing_name": "pump-station-0417",
    "severity": "HIGH",
    "probable_cause": "Bearing wear on main pump motor",
    "recommended_action": "Schedule inspection within 48 hours; monitor vibration trend",
    "supporting_evidence": "Vibration RMS rose 38% above 7-day baseline; correlated temperature increase of 6°C",
    "confidence": 0.86
}

Region availability: The model ID us.anthropic.claude-haiku-4-5-20251001-v1:0 is a US cross-Region inference profile that routes to US East (N. Virginia), US East (Ohio), and US West (Oregon). Availability might expand to additional AWS Regions. Adjust the inference profile if your workload requires a different Region.

Responsible AI considerations: The agent’s recommendations are advisory. They display on the HMI for a human operator to review before initiating physical actions (dispatching a technician, shutting down a pump). No automated actuation occurs without operator confirmation. For production deployments, we recommend configuring Amazon Bedrock Guardrails to constrain the agent’s response categories and prevent recommendations outside the defined action set.

Fleet deployment and model updates

With AWS IoT Greengrass deployments, you can push the Rust binary and ONNX model to the device fleet. Model updates use the same deployment mechanism. Upload a new ONNX artifact to Amazon S3 and update the component version in the recipe. Then create a new deployment targeting the device group. AWS IoT Greengrass handles the rolling update, including rollback if the new component fails health checks.

Key design decisions

We chose Rust over Python for this component because of the runtime footprint difference (less than 0.5 MB compared to approximately 30 MB, as shown in the preceding table). This difference determines whether the AI component fits within a 64 MB device budget. This solution uses the standard AWS IoT Greengrass nucleus rather than Nucleus Lite. The Rust SDK runtime footprint (under 0.5 MB) fits within Nucleus Lite’s 5 MB workload limit. However, the statically linked ONNX Runtime brings the total binary to approximately 22 MB, which exceeds that ceiling. For deployments without local inference (pure MQTT relay to cloud), Nucleus Lite is a viable alternative.

The following decisions shaped the rest of the design:

Escalation cooldown: Repeats of the same anomaly type are suppressed for 300 seconds per device. Without the cooldown, a stuck sensor generating one reading per second produces 86,400 daily escalations. With 300-second suppression, this reduces to approximately 288 (see the benchmarks/ directory in the repository for the calculation). The cooldown ledger resets when the anomaly type changes or the suppression window expires.
Security: The Rust binary communicates with AWS IoT Greengrass nucleus through local IPC (Unix domain sockets), not network sockets. Cloud communication uses the device’s X.509 certificate managed by AWS IoT Greengrass. The ONNX model file is integrity-checked at two stages: AWS IoT Greengrass verifies the S3 artifact digest at deployment time, and the component re-verifies the SHA-256 hash at startup before loading the model into memory.
Cross-compilation: The sample-greengrass-rust-edge-ai-agent includes a multi-stage Dockerfile that cross-compiles the Rust binary with statically linked ONNX Runtime for aarch64-unknown-linux-gnu. This produces a self-contained binary with minimal runtime dependencies on the target device (glibc 2.38+, libstdc++, libgcc_s).

The glibc dependency comes from ONNX Runtime’s dynamic linking requirements. A musl-libc static build isn’t feasible because ONNX Runtime doesn’t support musl. Verify your target device’s glibc version before deploying, as some embedded Linux distributions (Yocto, Buildroot) may ship older versions.

Performance targets (sub-200 ms inference latency, under 30 MB peak RSS) are based on the component design and model sizing for ARM Cortex-A53 class devices with 256 MB RAM. See the benchmarks/ directory in the repository for reproduction steps on your own hardware.

Prerequisites

To implement this solution, you need the following:

An AWS account with AWS Cloud Development Kit (AWS CDK) bootstrapped in the target Region.
AWS IoT Greengrass core device (ARM64 Linux) with AWS IoT Greengrass nucleus 2.14 or later. Set interpolateComponentConfiguration to true in the nucleus configuration. This setting is required for {iot:thingName} interpolation in component configuration values. Lifecycle variable interpolation works without this flag.
Rust toolchain (1.89 or later) with aarch64-unknown-linux-gnu cross-compilation target.
Docker (for cross-compilation build environment).
AWS IoT Core configured with the Greengrass core device registered.
Amazon Bedrock model access for Anthropic Claude Haiku 4.5 (us.anthropic.claude-haiku-4-5-20251001-v1:0).

Clone the sample-greengrass-rust-edge-ai-agent repository to get the complete implementation:

git clone https://github.com/aws-samples/sample-greengrass-rust-edge-ai-agent.git
cd sample-greengrass-rust-edge-ai-agent

Deploying

The deployment consists of two parts: the edge component deployed to your device fleet and the cloud stack deployed to your AWS account.

To deploy the edge component

Cross-compile the Rust component for ARM64 using the provided Dockerfile:

docker build \
  -f edge-component/Dockerfile \
  -t edge-ai-classifier-build \
  --target output \
  --output "type=local,dest=edge-component/dist" \
  edge-component/

The component recipe defines the lifecycle and artifact dependencies. The following excerpt shows the key sections:

Manifests:
    - Platform:
        os: linux
        architecture: aarch64
      Artifacts:
        - URI: s3://BUCKET/artifacts/edge-ai-classifier
        - URI: s3://BUCKET/artifacts/sample_model.onnx
      Lifecycle:
        run:
          script: >-
            {artifacts:path}/edge-ai-classifier
            --model-path {artifacts:path}/sample_model.onnx
            --thing-name {iot:thingName}

Upload the binary and model artifacts to your Amazon S3 bucket so that AWS IoT Greengrass can retrieve them during deployment:

aws s3 cp edge-component/dist/edge-ai-classifier s3://BUCKET/artifacts/edge-ai-classifier
aws s3 cp model/sample_model.onnx s3://BUCKET/artifacts/sample_model.onnx

Create an AWS IoT Greengrass deployment targeting your device group:

aws greengrassv2 create-deployment \
  --target-arn arn:aws:iot:us-east-1:ACCOUNT:thinggroup/PumpStations \
  --components '{"com.example.EdgeAIClassifier": {"componentVersion": "1.0.1"}}'

Run the fleet simulator from the repository to seed synthetic sensor data for testing:
```
python scripts/simulate_sensors.py --devices 10 --duration 300
```

To deploy the cloud stack

Run cdk deploy from the cloud stack directory.
Note the CDK stack outputs (MQTT topics and IoT rule configuration).

The sample-greengrass-rust-edge-ai-agent contains the complete implementation: Rust component source, ONNX model integration using the ort crate, component recipe, cross-compilation Dockerfile, cloud CDK stack, and sample classification model.

Clean up

To avoid ongoing charges, stop any running simulators first. Each escalation invokes Amazon Bedrock and accrues cost. Each escalation costs approximately $0.004 (assuming 1,500 input tokens at $1/M and 500 output tokens at $5/M, using Claude Haiku 4.5 pricing). In a realistic test scenario where 10 devices average 8-12 escalations per day (not constant anomalies), expect approximately $10-15/month. A worst-case stuck sensor hitting the 288 daily escalation cap on all 10 devices would cost approximately $345/month. See the Amazon Bedrock pricing page for current per-token rates.

Then delete the AWS IoT Greengrass deployment and remove the cloud stack with cdk destroy. The repository’s scripts/cleanup.sh automates this process. See the cleanup script documentation for details. The Amazon DynamoDB telemetry table uses a TTL policy. Data older than 90 days is deleted automatically.

Conclusion

In this post, you explored the architecture and key design decisions for a Rust-based AWS IoT Greengrass component. The component classifies sensor anomalies locally using ONNX inference and escalates complex cases to Amazon Bedrock AgentCore in the cloud. The structured RCA response shown earlier illustrates the end-to-end escalation, from a local classification to a cloud-generated recommendation returned to the device.

With this pattern, the pump station targets anomaly classification in under 200 ms without cloud dependency. During outages, the pattern queues escalations locally and drains them on reconnect. Multi-sensor correlations route to the cloud agent for root cause analysis against 7-day historical baselines.

This post uses a water utility pump station. The same edge-to-cloud inferencing flow applies to other workloads that need fast local classification with selective escalation to cloud reasoning. A predictive maintenance system on a manufacturing line classifies equipment vibration signatures locally and escalates ambiguous failures for root cause analysis. In smart buildings, the component detects HVAC or energy anomalies at the edge and escalates cross-system correlations. Fleet and logistics telematics flag vehicle sensor faults on the device and escalate multi-signal patterns for diagnostics. In each case, the Rust component keeps latency-sensitive decisions local while routing the reasoning-heavy work to the cloud only when needed.

Clone the sample-greengrass-rust-edge-ai-agent and deploy it to your own edge devices using the recipe and commands shown in this post.

The Internet of Things on AWS – Official Blog