How to Migrate from AWS Lookout for Equipment (Retiring October 7, 2026)

What Is Happening to AWS Lookout for Equipment?

AWS Lookout for Equipment is retiring on October 7, 2026. After that date, all service APIs will stop responding, all trained models will be deleted, all datasets stored in S3 via the Lookout service will lose their associations, and all inference schedulers will be terminated.

Lookout for Equipment launched in 2020 as AWS's managed ML service for industrial equipment anomaly detection. It was designed for predictive maintenance use cases: rotating equipment, manufacturing lines, HVAC systems, and energy generation assets. Teams uploaded historical sensor data to S3, trained models through the Lookout API, and then ran inference on a schedule against new sensor readings.

The service was powerful but operationally heavy. A typical deployment required: - An S3 bucket structure organized to Lookout's schema requirements - IAM roles granting Lookout access to S3 and CloudWatch - A dataset definition specifying sensor channels and their units - Model training runs that could take hours to days - Inference schedulers running on a fixed interval (minimum 5 minutes)

AWS's official recommendation for teams migrating off Lookout for Equipment is Amazon IoT SiteWise. That path requires significant re-architecture and does not represent a simple migration for most teams.

How Is Lookout for Equipment Different from Azure Anomaly Detector?

Both services are retiring in October 2026, but they had fundamentally different architectures. Understanding the difference matters for choosing the right migration path.

Azure Anomaly Detector was a stateless REST API. You sent a time series as a JSON body and received anomaly scores in the response. No data upload step, no model training step, no scheduling step. Detection happened inline in the API call.

AWS Lookout for Equipment was an infrastructure service, not a REST API. It followed a multi-step workflow:

1. Upload historical sensor data to S3 in Lookout's required CSV format
2. Create a dataset definition in the Lookout API (specifying channels, units, timestamps)
3. Train a model — an asynchronous operation taking hours to complete
4. Create an inference scheduler that periodically reads new data from S3 and writes results to S3
5. Poll the output S3 location for anomaly results

This architecture meant Lookout was tightly coupled to S3 and IAM. Teams that built on Lookout have sensor data in S3, inference results in S3, and orchestration logic tied to the scheduler model. Migrating off Lookout requires unwinding that infrastructure dependency, not just changing an endpoint URL.

This is why the migration from Lookout is more involved than the Azure migration — even though the October deadlines are one week apart.

What Are Your Migration Options After Lookout for Equipment?

Teams migrating off AWS Lookout for Equipment have three realistic options:

Option 1: Amazon IoT SiteWise (AWS's recommendation) IoT SiteWise is AWS's recommended migration target. It handles equipment monitoring, asset modeling, and anomaly detection for industrial IoT use cases. However, it is a significantly more complex service than Lookout. IoT SiteWise requires defining asset models, setting up asset hierarchies, configuring gateways for on-premise data ingestion, and integrating with AWS IoT Core. Teams that deployed Lookout in a few days may find an IoT SiteWise migration takes six or more weeks. For teams deeply embedded in AWS with existing IoT Core infrastructure, this path makes sense. For teams that used Lookout as a simple anomaly detection API, IoT SiteWise is substantial over-engineering.

Option 2: Custom ML models on Amazon SageMaker Teams with ML engineering expertise can build and deploy custom time-series anomaly detection models on SageMaker. This gives full control over model architecture, training data, and inference infrastructure. The tradeoff is cost and complexity: SageMaker requires ongoing model maintenance, retraining pipelines, and endpoint management. This option is appropriate for organizations with a dedicated ML platform team that wants complete ownership of the detection stack.

Option 3: Canary Edge Canary Edge is an API-first anomaly detection service purpose-built for industrial equipment monitoring. It does not require S3 datasets, IAM roles, or inference schedulers. Send a time series via REST API, receive anomaly scores in the response. Per-machine models train automatically from your operational data. Teams that used Lookout for rotating equipment, vibration monitoring, or predictive maintenance can replicate that use case on Canary Edge with a fraction of the infrastructure overhead.

Why Is Canary Edge the Simplest Lookout for Equipment Replacement?

Canary Edge eliminates the infrastructure dependencies that made Lookout for Equipment operationally complex.

No datasets or S3 required. Canary Edge accepts time-series data as JSON in a standard REST API request. You do not need an S3 bucket, a dataset definition, or a channel schema file. Send your sensor readings directly in the API call.

No IAM roles or AWS infrastructure. Canary Edge is cloud-agnostic. It runs on Canary Edge infrastructure and requires no AWS account access, no IAM policy attachments, and no VPC peering. Your Canary Edge API key is the only credential required.

No training pipeline. Lookout for Equipment required a multi-hour training job before a model was ready. Canary Edge builds a baseline model per machine automatically as data arrives. After 100 data points, detection is active. No training job to submit, no training status to poll, no deployment step.

No inference scheduler. Lookout ran inference on a fixed schedule (minimum every 5 minutes) and wrote results to S3. Canary Edge returns anomaly scores synchronously in the API response. Your application calls the API when it has new data and receives scores immediately.

Per-machine models. Each machine in Canary Edge has its own model that learns that machine's unique baseline operating pattern. A 20-year-old compressor running at 85% load gets a different model than a new pump running at 60% load, even if they are the same equipment type. This is the same approach Lookout used, but without the infrastructure overhead.

Any language, any platform. Canary Edge is a REST API. Python, JavaScript, Go, Java, C#, or any language that can make an HTTP request works without an SDK.

How to Migrate from Lookout for Equipment to Canary Edge

Follow these five steps to migrate from AWS Lookout for Equipment to Canary Edge:

Step 1: Sign up at canaryedge.com Create a Canary Edge account at canaryedge.com/sign-up. The free tier is available immediately — no credit card required. Generate an API key from the dashboard. Your key starts with cnry_live_.

Step 2: Create a Canary Edge machine for each Lookout dataset In Lookout for Equipment, sensor channels were grouped into datasets. In Canary Edge, each piece of physical equipment is a "machine" with one or more sensor channels. For each Lookout dataset representing a distinct piece of equipment, create a corresponding machine in the Canary Edge dashboard or via the API.

Step 3: Stream sensor readings to the Canary Edge API instead of S3 The core integration change: instead of writing new sensor data to an S3 bucket for the Lookout inference scheduler to pick up, send readings directly to the Canary Edge REST API. A POST to /v1/machines/{machine_id}/readings with a JSON array of timestamp/value pairs per channel submits data and returns anomaly scores in the same response.

Step 4: Consume anomaly scores from the API response Lookout wrote inference results to an S3 output location, requiring a separate polling or S3 event trigger to consume results. Canary Edge returns anomaly scores synchronously in the API response. Update your downstream processing to read scores from the HTTP response body rather than polling S3.

Step 5: Set up threshold alerts in your existing monitoring layer Canary Edge anomaly scores range from 0.0 to 1.0. You can configure threshold-based alerts in Canary Edge directly, or consume the scores in your existing monitoring infrastructure (Grafana, PagerDuty, CloudWatch, Datadog) and apply alert logic there. The score field maps directly to what Lookout called the "anomaly score" in its inference output.

What Industrial IoT Use Cases Does Canary Edge Support?

Canary Edge covers the same industrial equipment use cases that AWS Lookout for Equipment was designed for.

Rotating equipment. Pumps, motors, compressors, fans, and blowers all exhibit characteristic vibration, temperature, and current signatures when operating normally. Canary Edge builds per-machine baselines that learn normal operating envelopes across speed ranges, load conditions, and ambient temperature variation. Deviations from that learned baseline — bearing wear, cavitation, imbalance, misalignment — register as anomalies before they reach failure threshold.

Vibration monitoring. High-frequency vibration data from accelerometers is one of the richest signals for equipment health. Canary Edge handles multi-channel time series natively, accepting vibration readings from X, Y, and Z axes simultaneously and detecting cross-channel correlation changes that indicate developing faults.

Predictive maintenance. The primary use case for Lookout was predicting maintenance needs before failure. Canary Edge provides anomaly scores with lead time — the signal typically appears days to weeks before a failure that would require unplanned maintenance. This lead time is the economic value: planned maintenance during a scheduled shutdown costs a fraction of emergency repair during production.

HVAC and building systems. Chiller units, air handling units, cooling towers, and boiler systems all benefit from continuous anomaly monitoring. These assets run continuously with predictable seasonal patterns that Canary Edge's baseline models handle well.

Manufacturing lines. CNC machines, injection molding equipment, presses, and conveyor systems generate continuous sensor streams. Canary Edge integrates with standard industrial protocols and data historians via its REST API, accepting data forwarded from OPC-UA bridges, MQTT brokers, or edge processing nodes.