Building Predictive Maintenance Models from raw IoT data with Kiro and Amazon SageMaker
An open-source Kiro skill that uses an AI agent to automate the ML engineering and AWS infrastructure work of predictive maintenance — exploring raw IoT data in S3, building features, training AutoGluon ensembles across four problem formulations, and deploying to SageMaker — while pausing at three checkpoints where only human equipment domain knowledge can guide the decisions.
Every manufacturing team knows the value of predicting equipment failures before they happen. The business case is clear: reduced downtime, lower maintenance costs, longer asset life. Yet most predictive maintenance projects stall before producing their first model.
With the generative AI revolution, a natural question arises: can't we just ask an AI agent to predict failures? The short answer is no. A predictive maintenance model is a supervised Machine Learning (ML) system trained on structured, high-frequency sensor data (vibration, temperature, current, pressure) to output calibrated numeric quantities: probability of failure within N days, remaining useful life, or an anomaly score. These outputs feed safety-critical scheduling decisions that require quantitative precision, not plausible-sounding language. An LLM agent has no grounded numeric basis for those predictions. It can describe risk convincingly without that description being calibrated or trained on your equipment's actual failure history.
But building that model still requires the simultaneous convergence of three rare knowledge domains:
- Machine Learning: temporal splits, label construction, class imbalance handling, leakage prevention
- AWS Infrastructure: S3 data lake navigation, SageMaker training jobs, container packaging, CDK deployment
- Equipment Domain Knowledge: what the sensors measure, which physical interactions precede failure, and what "failure" means operationally
Most operations teams have deep equipment knowledge but lack ML expertise. Internal data teams can navigate the data lake but may not know how to construct temporal splits, prevent leakage, or package a model for SageMaker. The ML expertise, particularly for time-series problems with class imbalance and censored data, is specialist knowledge that companies often have to source externally through consultants or dedicated hires. Even then, the first working model takes weeks, with the majority of that time consumed by data exploration and feature engineering, not model training. Every new customer repeats this ramp regardless of how similar the underlying problem is across fleets, plants, and industries.
What an agent can do is orchestrate the process of building the model: exploring data, writing feature engineering code, running training jobs, interpreting results. The agent adds automation around the prediction; it doesn't generate the prediction itself.
In this post, we introduce an open-source Kiro skill that uses an AI agent for what agents are actually good at (automating the ML and infrastructure work) while producing what only a trained model can provide: calibrated, continuously-improvable failure predictions. The skill is a nine-phase agentic pipeline that starts from raw sensor data in Amazon S3, explores, transforms, trains, explains, and deploys a production-ready model to Amazon SageMaker or to edge devices via AWS IoT Greengrass, pausing at three checkpoints where the third domain, equipment knowledge, is irreplaceable.
The AWS predictive maintenance ecosystem, and the gap in the middle
A complete predictive maintenance solution on AWS spans three layers. The first and third already exist as managed services. This skill targets the middle one.
Data ingestion is production-ready. IoT FleetWise streams vehicle data, IoT SiteWise collects industrial equipment metrics, and IoT Core handles custom device protocols. All land telemetry in S3 as Parquet or CSV.
Prediction consumption is equally mature. AWS is investing heavily in GenAI-augmented maintenance workflows, from agents for anomaly alerting (June 2025) to multimodal assistants for root cause diagnosis (February 2026). Bedrock agents diagnose failures, IoT TwinMaker renders 3D visualizations, Grafana powers dashboards, and SNS/EventBridge deliver alerts. These all consume predictions; they don't produce them.
ML modeling, the layer between ingestion and consumption, is the gap. Amazon Lookout for Equipment will be discontinued in October 2026. AWS IoT SiteWise anomaly detection (GA July 2025) provides managed anomaly detection for teams that want a no-code path. But for the large population of customers who already have telemetry landing in S3 and want custom, owned models with full formulation control (RUL regression, failure classification, survival analysis, multi-label classification), the ML layer has remained a blank page. That's the gap this skill fills.
Solution overview
The Predictive Maintenance Skill is a nine-phase agentic pipeline for Kiro that encodes the complete model-building process into a reusable, version-controlled workflow. It ships as an open-source repository you clone into your Kiro skills directory.
The skill doesn't replace human judgement. It automates the ML expertise and AWS infrastructure work (two of the three knowledge domains) and pauses at three mandatory checkpoints where equipment domain knowledge is required. The human contribution shifts from ML plumbing to domain decisions: the resource customers already have.
Key AWS services:
| Service | Role |
|---|---|
| Amazon S3 | Raw data lake (input) and model artifact storage (output) |
| Amazon SageMaker | Training Jobs, Processing Jobs (batch inference), Endpoints (real-time) |
| AWS IoT Greengrass | Edge deployment: runs inference on-device as a Greengrass component |
| AWS IoT Core | MQTT transport for edge predictions back to the cloud |
| AWS CDK | Infrastructure-as-code for all deployment stacks |
| Amazon EventBridge + AWS Lambda | Daily batch inference scheduling |
What the skill produces:
Each run generates a timestamped, self-contained bundle on S3:
1
2
3
4
5
6
7
8
s3://<output-bucket>/<YYYYMMDD_HHMM>/
├── dataset/
├── training/
├── model/
├── inference/
├── edge_component/
├── infrastructure/
└── README.md Four formulations, one skill
The skill supports four predictive maintenance problem formulations. It recommends one based on your data characteristics and confirms with you before proceeding.
| Formulation | When to use | Model output |
|---|---|---|
| RUL regression | Run-to-failure data, need precise remaining useful life timeline | Days until failure |
| Binary classification | Run-to-failure data, need alerts | Will it fail within N days? |
| Multi-label classification | Multiple independent failure modes | Per-mode probability scores |
| Survival analysis | Censored data (devices maintained before failure) | Time-to-event probability curves |
Prerequisites
- Data:
- Raw operational data in S3: sensor telemetry + maintenance/health records (Parquet or CSV)
- Tools:
Walkthrough
Step 1: Install the skill
1
2
git clone https://github.com/aws-samples/sample-predictive-maintenance-skill.git \
~/.kiro/skills/predictive-maintenanceThe skill activates automatically when Kiro detects predictive-maintenance-related intent in your prompt.
Step 2: Initialize a project
Open Kiro in a fresh project directory and describe your task:
"Build a predictive maintenance model from the data in s3://my-fleet-telemetry/"
The skill runs the environment setup phase: creating a Python virtual environment, installing dependencies (AutoGluon, pandas, scikit-learn, boto3), and copying the bundled
pdm/ library into your project.Step 3: Data exploration and strategic decisions
The agent explores your S3 bucket programmatically. For each table it discovers, it profiles column types, null rates, cardinality, and join key overlap with other tables. For EAV telemetry tables (where each row is a single sensor reading), it enumerates distinct sensor names and date ranges.
The output is a
data_exploration.md file documenting everything the agent found. Then it stops and asks questions to clear possible ambiguities, or to choose among different valid options. These are questions that cannot be inferred from the data. They encode operational decisions, the equipment domain knowledge that only the customer has. The agent recommends answers based on data evidence but waits for confirmation before proceeding.Step 4: Automate data aggregation and label construction
With decisions locked in, the agent writes
raw_dataset.py, a reusable script that automates the data aggregation pipeline:- Loads all source data from S3 (chunked for memory safety)
- Pivots EAV telemetry into wide format: one row per (device, date) with columns for each sensor's daily statistics (mean, std, max, min)
- Joins device metadata using validated join keys
- Constructs forward-looking labels: "will this device experience failure X within the next N days?"
- Splits by time with a gap matching the prediction horizon
The forward-looking window design is critical. It teaches the model to detect precursors, subtle patterns that precede failure, rather than detecting issues already present. The temporal gap prevents information from the evaluation period bleeding into training, a subtle form of leakage that inflates metrics but produces useless models in production.
Step 5: Baseline training
The agent trains baseline models using AutoGluon , an automated ML framework that trains multiple algorithm families (LightGBM, XGBoost, CatBoost, Random Forests, Extra Trees) and builds a multi-layer stacking ensemble. Quality gates enforce minimum performance before the pipeline continues. If a gate fails, the skill diagnoses root causes (class imbalance, feature coverage gaps, leakage indicators) rather than blindly retraining with more compute.
Step 6: Hypothesis-driven experimentation
This is where domain knowledge transforms a decent model into a strong one. Instead of random hyperparameter sweeps, the agent follows a structured scientific method:
- Builds a knowledge base by researching state-of-the-art techniques for the specific formulation
- Proposes 3–5 experiments ranked by expected impact, each with a grounded hypothesis
- Presents the plan for approval, the second mandatory checkpoint
- Iterates: implements each experiment, trains, evaluates against baseline, merges improvements or discards
Example experiments for a multi-label classification model:
- Hypothesis: Adding pairwise interaction features between correlated sensors (e.g., temperature × current) captures physical degradation relationships that individual features miss.
- Hypothesis: Applying per-label SMOTE resampling to minority failure modes improves recall on rare faults without degrading majority-class precision.
- Hypothesis: Removing features with >90% correlation to another feature reduces multicollinearity noise and improves ensemble diversity.
In an internal evaluation on a fleet of ~1,000 devices, a single experiment (adding pairwise sensor interactions) improved median F1 from 0.52 to 0.67 across 12 failure modes.
Step 7: Example inference with explanations
Before deployment, the agent runs the trained model against a day of real telemetry. Each positive prediction includes per-feature explanations showing why the model flagged that device:
1
2
3
4
device_id: PUMP-4291
label_Overheating_probability: 0.82
label_Overheating_prediction: 1
top_features: cpu_temperature_mean(Δ=+0.18); manufactured_age_days(Δ=+0.09); ambient_temp_max(Δ=+0.06)The delta (Δ) quantifies how much the prediction probability drops when that feature is zeroed, a perturbation-based approach. An engineer can immediately see "elevated CPU temperature is the primary driver" and verify whether the alert is actionable.
For anomaly detection models, explanations use z-score deviations:
voltage_l1_std(z=8.1) means that feature is 8.1 standard deviations above the normal operating envelope.Step 8: Deploy predictive maintenance model
Predictive maintenance deployment architectures — daily batch inference (EventBridge → Lambda → SageMaker Processing Job), a real-time SageMaker endpoint, and edge inference on AWS IoT Greengrass publishing to IoT Core
The third checkpoint asks how you want to deploy. Three options, all using AWS CDK:
Option A: Daily batch inference
1
EventBridge (daily cron) → Lambda → SageMaker Processing Job → predictions CSV in S3Scores the entire fleet nightly in 5–7 minutes (for a fleet of ~1,000 devices; includes instance spin-up). No persistent infrastructure: the Processing Job starts, runs, and terminates. Cost: ~$0.04–0.06 per run on ml.m5.2xlarge ($0.538/hour).
Option B: Real-time endpoint
A custom Docker container (AutoGluon + Flask) pushed to ECR, serving predictions through a SageMaker endpoint. Responds in seconds for individual device queries.
Option C: Edge deployment via AWS IoT Greengrass
1
Sensor Source → PDM Model (on-device) → Greengrass IPC → IoT Core (MQTT) → CloudWatch / S3Deploys the trained model to an edge device as an AWS IoT Greengrass component. The model runs inference locally on sensor data and publishes only predictions (not raw telemetry) to AWS IoT Core via MQTT. This is the right choice for bandwidth-constrained environments, offline-capable deployments, or single-device monitoring where sub-second latency matters.
The edge component uses a pluggable sensor source interface. It ships with a CSV replay source for demos; implement custom sources for OPC-UA, MQTT, Modbus, or any industrial protocol by implementing a three-method Python interface (
start, read, stop).The infrastructure is split into three independent CDK stacks: network (VPC + endpoints), resources (IoT Policy, Token Exchange Role, S3), and an optional demo device (EC2 t3.small with Greengrass auto-provisioning). For production with physical edge hardware, deploy only the network and resources stacks, then provision the device using the stack outputs.
Deploy with:
1
2
3
4
5
6
7
# Deploy edge infrastructure
cd infrastructure/edge/
pip install -r requirements.txt
cdk deploy --all
# Build and deploy the Greengrass component
bash scripts/deploy_edge.sh --model-dir ./fault_prediction/baseline/modelPredictions arrive in the IoT Core MQTT test client at
things/<device>/pdm/predictions every 60 seconds (configurable). An IoT Rule forwards them to CloudWatch Metrics for dashboarding.Deploy any combination of these options. Each deployment mode has its own independent CDK app under
infrastructure/:1
2
3
4
5
# Batch inference
cd infrastructure/batch/ && pip install -r requirements.txt && cdk deploy
# Edge deployment
cd infrastructure/edge/ && pip install -r requirements.txt && cdk deploy --allOnce deployed, the predictions feed directly into the consumption layer. These are downstream consumers of the prediction output, not features of the skill itself: Bedrock agents for diagnosis, Grafana dashboards for operations teams, SNS alerts for immediate action.
What makes this different from AutoML
AutoML tools (SageMaker Autopilot , Canvas, AutoGluon standalone) assume a prepared training table already exists. In practice, producing that table is the expensive part. That's where the three knowledge domains must converge.
| AutoML tools | This skill | |
|---|---|---|
| Starting point | Prepared CSV | Raw S3 data lake (EAV telemetry, metadata, events) |
| Data engineering | Manual prerequisite | Automated: profiling, join validation, EAV pivot, label construction |
| Temporal safety | User's responsibility | Built-in: forward-looking windows, temporal split with gap |
| Formulations | Generic classification/regression | 4 PdM-specific: RUL, classification, multi-label, survival |
| Feature engineering | Not included | Hypothesis-driven with domain research |
| Knowledge domains needed | All three (ML + AWS + domain) | Domain only: ML expertise and AWS fluency are encoded in the skill |
| Output | Model artifact | Production bundle: code, model, container, edge component, CDK, docs |
Conclusion
In this post, we walked through a nine-phase agentic skill that fills the ML modeling gap in the AWS predictive maintenance ecosystem, transforming raw IoT telemetry in Amazon S3 into a deployed model on Amazon SageMaker or at the edge via AWS IoT Greengrass. The skill encodes two of the three knowledge domains (ML expertise and AWS infrastructure) into reusable automation, leaving the customer to contribute only the third: equipment domain knowledge, expressed as answers to five targeted questions.
Each run produces a self-contained artifact bundle (dataset code, trained model, inference scripts, edge component, CDK infrastructure, documentation) that plugs directly into the existing AWS consumption layer: Bedrock agents for diagnosis, Grafana for visibility, SNS for alerts, or IoT Core for edge-to-cloud prediction streaming. Because domain gotchas accumulate in the skill's reference material, every deployment makes the next one faster.
To get started, install the skill from the GitHub repository and point it at your S3 data. For teams that prefer a managed no-code path, AWS IoT SiteWise anomaly detection handles simpler anomaly use cases without custom modeling. For extending predictions into operational action, see building GenAI agents for predictive maintenance on AWS .
The Predictive Maintenance Skill is open source. Find the code, documentation, and example datasets at github.com/aws-samples/sample-predictive-maintenance-skill .
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article