Industrial equipment generates data that’s genuinely different from application telemetry. A CNC machine might stream spindle speed, feed rate, and temperature at 10Hz from a dozen sensors. A compressor installation has operating hours, pressure differentials, and vibration signatures. The data is high-frequency, physically structured (asset → component → measurement), and often needs local processing before going anywhere near a cloud.
AWS IoT SiteWise was built with this shape of problem in mind. It’s not a generic IoT platform that happens to work with industrial data — it’s designed around the asset-model concept that maps naturally onto how equipment and facilities are actually organised.
The Asset Model
The central concept in SiteWise is the asset model, a schema that defines what properties a type of equipment has. You create models (a Pump model, a Compressor model, a Production Line model) and then create assets as instances of those models.
Each property in a model has a type:
- Measurement: raw sensor readings ingested in real time — the actual values flowing from your OPC-UA server or MQTT broker
- Transform: derived values calculated from measurements using SiteWise’s expression language (e.g., converting celsius to fahrenheit, or calculating flow rate from differential pressure)
- Metric: aggregations computed over time windows (average over the last 5 minutes, maximum over the last hour, alarm counts per shift)
- Attribute: static metadata that doesn’t change over time (serial number, installation date, manufacturer)
The hierarchy capability lets you compose models. A Production Line model can contain Pump assets and Compressor assets as child assets, aggregating metrics upward through the tree. Queries against the production line can pull aggregated values without needing to know which physical devices contribute.
This structured approach is one of SiteWise’s clearest advantages over rolling your own time-series stack. With InfluxDB or TimescaleDB you’re free to structure data however you want — which means you’ll inevitably end up with organically grown schemas that differ across sites and make cross-asset analysis difficult. SiteWise pushes you toward structure upfront.
SiteWise Edge
SiteWise Edge is the component that runs on-premises, typically on a gateway appliance or an EC2 instance in an on-premises data room. It handles:
OPC-UA server connectivity: Most industrial equipment exposes data via OPC-UA (the OPC Unified Architecture protocol standard). SiteWise Edge includes a managed OPC-UA data source connector that can connect to multiple OPC-UA servers, browse the node tree, and map nodes to SiteWise asset model properties. Configuration is done through the AWS console or API, not on the gateway itself.
Local processing and storage: Edge gateways can store data locally and process metrics locally, which matters when WAN connectivity to AWS is intermittent. The local pack supports up to 30 days of local storage, ensuring you don’t lose readings during connectivity outages.
Local queries: With the SiteWise Edge software, you can query asset data locally without a round-trip to the AWS cloud. This is critical for dashboard applications that need sub-second response times — querying SiteWise’s cloud APIs adds meaningful latency that’s acceptable for historical analysis but not for real-time operator displays.
Data reduction before upload: Computing 5-minute averages at the edge and uploading aggregated metrics rather than raw readings reduces egress costs and cloud storage costs substantially for high-frequency sensor data.
Connecting OT Data Sources
The most common integration pattern is OPC-UA from a historian or PLC data gateway. SiteWise Edge can connect to Kepware, Ignition, Canary, OSIsoft PI (now AVEVA PI), and any other system that exposes an OPC-UA server.
For equipment that uses proprietary protocols or older MODBUS RTUs, you typically need a protocol gateway (a device or software layer that translates to OPC-UA or MQTT) before SiteWise can receive the data. AWS publishes a managed Lambda-based processing pipeline for MQTT ingestion via AWS IoT Core if OPC-UA isn’t viable.
The data source configuration in SiteWise Edge maps OPC-UA node IDs to asset property aliases:
{
"sources": [
{
"name": "CompressorStation1",
"endpoint": {
"url": "opc.tcp://192.168.1.50:4840",
"securityMode": "SIGN_AND_ENCRYPT"
},
"measurements": [
{
"propertyAlias": "/plant1/compressor1/discharge_pressure",
"nodeId": "ns=2;s=Station1.Compressor1.DischargePressure"
}
]
}
]
}
Alarms
SiteWise integrates with AWS IoT Events for alarm management. You define alarm models that watch metric properties and trigger state transitions based on thresholds. An alarm can have states like Normal, Active, Acknowledged, and Latched, with configurable transitions and notification actions.
This is more structured than rolling custom alarm logic. SiteWise alarms appear in the SiteWise Monitor portal (the managed dashboard product) alongside asset data, and SNS or Lambda actions on alarm transitions let you page operators or trigger maintenance workflows.
The alarm approach follows the ISA-18.2 alarm management standard structure, which matters for facilities with formal alarm management requirements — it’s not just threshold alerting but a lifecycle for how alarms are created, acknowledged, and cleared.
SiteWise Monitor
SiteWise Monitor is a managed web portal for visualising SiteWise data. It’s not a full-featured SCADA system — don’t expect animated P&IDs or complex navigation hierarchies — but for production-tracking dashboards showing trends, current values, and alarm states, it’s functional and requires no frontend development.
Portals are multi-tenant: you can give operations staff read access to their site’s assets without giving them access to the raw AWS console. Permissions are managed via AWS SSO user groups mapped to portal access policies.
For more sophisticated visualisations, SiteWise integrates directly with Grafana. The Grafana AWS IoT SiteWise data source plugin lets you query asset properties and metrics in Grafana dashboards, which gives you far more flexibility than SiteWise Monitor while keeping SiteWise as the data layer.
Where SiteWise Fits vs DIY Approaches
The managed stack vs self-managed comparison is worth being direct about.
SiteWise advantages: Managed ingestion infrastructure, structured asset modelling, built-in alarm management, native AWS integration (CloudWatch, Lambda, S3 for data export), and no operational burden on the time-series database. For organisations that want to avoid running InfluxDB or TimescaleDB clusters and the associated operational complexity, SiteWise removes that overhead.
DIY alternatives: An open-source stack — Kepware or similar for OPC-UA data collection, Telegraf for ingestion, InfluxDB or TimescaleDB for storage, Grafana for visualisation — gives more flexibility and avoids AWS lock-in. It’s also potentially cheaper at scale since you’re paying for compute and storage rather than per-property pricing. The trade-off is operational overhead and the absence of managed structure.
SiteWise’s per-property pricing (charged per asset property with data flowing) becomes significant for large asset portfolios with many measurements. For a facility with 10,000 measurements, the AWS pricing model requires careful modelling before commitment.
Getting Started
-
Define your asset models first before connecting any data sources. Start with one equipment type, define its meaningful measurements, and think about what metrics (aggregations) you’ll actually query.
-
Deploy SiteWise Edge on a gateway — an AWS-recommended gateway appliance or a supported industrial PC. The gateway needs network access to both your OPC-UA servers (OT network) and AWS (IT network or internet).
-
Map OPC-UA nodes to property aliases in the data source configuration. Start with the highest-value measurements rather than mapping everything — sensor data volume is large and you can expand later.
-
Create dashboards in SiteWise Monitor or Grafana and put them in front of operations staff early. Operator feedback on what data is actually useful is more valuable than exhaustive coverage.