AWS IoT SiteWise Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Internet of Things (IoT)

by

Category

Internet of Things (IoT)

1. Introduction

AWS IoT SiteWise is an AWS managed service for collecting, organizing, processing, and analyzing industrial equipment data (often called OT/IIoT data) at scale. It is commonly used to build an “industrial data foundation” where raw sensor readings become meaningful, queryable asset data such as “Motor #12 temperature”, “Line 3 OEE”, or “Plant A energy consumption”.

In simple terms: AWS IoT SiteWise helps you model your facility and equipment (assets), ingest time-series measurements, calculate derived metrics, and make that data available to applications and dashboards—without building your own historian and asset model system from scratch.

Technically, AWS IoT SiteWise provides: – Asset modeling (asset models, assets, hierarchies, attributes, measurements, and computed properties) – Ingestion APIs for time-series values – Storage and query APIs for current and historical values – Optional visualization through AWS IoT SiteWise Monitor (portals, projects, dashboards) – Edge data collection using AWS IoT SiteWise Edge (typically deployed with AWS IoT Greengrass v2), enabling local collection and buffering when connectivity is intermittent

The core problem it solves is a common industrial data challenge: industrial sensor data is high-volume, often messy, and lacks context. Without an asset model, your data becomes thousands of tag names or MQTT topics with unclear meaning. AWS IoT SiteWise adds structure (models/assets), governance (permissions/auditing), and standard APIs for applications and analytics.

Service status and naming: – AWS IoT SiteWise is an active AWS service as of this writing. – AWS IoT SiteWise Monitor and AWS IoT SiteWise Edge are official components/features associated with AWS IoT SiteWise (verify the latest component names and availability in the official docs for your region).

2. What is AWS IoT SiteWise?

Official purpose (what AWS built it for)
AWS IoT SiteWise is designed to help you collect and organize industrial data from equipment and processes, and to compute and query asset-based metrics for operational visibility and analytics.

Core capabilities

  • Model industrial assets: Define asset models (e.g., “Motor”, “Compressor”, “Furnace”), then instantiate assets (e.g., “Motor-01”).
  • Represent relationships: Use hierarchies to model structures such as Plant → Line → Cell → Machine.
  • Ingest time-series measurements: Send timestamped property values (temperature, pressure, vibration).
  • Store and query: Retrieve the latest values and historical time-series through APIs.
  • Compute derived values: Define computed properties (for example, transforms/metrics) so applications don’t have to recalculate every time. (Exact feature names and expressions should be verified in the latest docs.)
  • Visualize (optional): Build dashboards and share them with users in AWS IoT SiteWise Monitor.
  • Collect at the edge (optional): Deploy AWS IoT SiteWise Edge to connect to on-premises industrial protocols/systems and forward data to AWS.

Major components (conceptual model)

  • Asset models: Templates defining properties and (optionally) hierarchies.
  • Assets: Instances of models representing real-world equipment.
  • Properties:
  • Measurements: Time-series values (sensor readings).
  • Attributes: Static metadata (serial number, manufacturer).
  • Computed properties: Derived values (transforms/metrics) computed from other properties (verify current compute feature details).
  • Data ingestion APIs: API operations for sending property values (commonly batched).
  • Query APIs: API operations to retrieve latest and historical values.
  • AWS IoT SiteWise Monitor: Portals/projects/dashboards for visualization (uses AWS identity integration; commonly AWS IAM Identity Center).
  • AWS IoT SiteWise Edge: On-prem/edge collection and buffering (verify supported connectors/protocols for your environment).

Service type and scope

  • Service type: Fully managed AWS service (control plane + data plane) for industrial data modeling and time-series storage/query of asset properties.
  • Scope: Regional. You create and use AWS IoT SiteWise resources in a specific AWS Region. Data is stored and processed in that Region.
    Multi-region strategies typically involve duplicating models and routing data to multiple regions (design carefully; verify latest AWS guidance).

How it fits into the AWS ecosystem

AWS IoT SiteWise is often used alongside: – AWS IoT Core (device connectivity via MQTT, device identity, rules engine) – AWS IoT Greengrass v2 (edge runtime; commonly used with SiteWise Edge) – Amazon S3 / data lakes (for long-term archival and analytics—often via custom export pipelines or supported integration features; verify current native export options) – Amazon Timestream / Amazon OpenSearch Service / Amazon Redshift / AWS Glue / Amazon Athena (downstream analytics, depending on your architecture) – Amazon CloudWatch and AWS CloudTrail (operations monitoring and audit logging) – AWS IAM and (often) AWS IAM Identity Center (security/access for APIs and SiteWise Monitor)

3. Why use AWS IoT SiteWise?

Business reasons

  • Faster time to value: Build an industrial data foundation without deploying and operating a self-managed historian + modeling layer.
  • Improved operational visibility: Standardize how plants and equipment are described and measured across sites.
  • Enable analytics and optimization: Clean, contextualized asset data is easier to use for OEE, energy optimization, predictive maintenance, and anomaly detection.

Technical reasons

  • Asset-centric abstraction: Engineers query “Motor-01 temperature” rather than parsing raw tag names/topics.
  • Managed ingestion and storage: Avoid managing time-series storage engines and scaling concerns yourself.
  • APIs for current and historical values: Consistent access patterns for applications, dashboards, and analytics pipelines.

Operational reasons

  • Repeatable modeling: Models can be reused across plants and production lines.
  • Central governance: Define naming conventions, hierarchy standards, and access patterns.
  • Edge support: Where applicable, collect near equipment and buffer during network disruptions (with SiteWise Edge).

Security/compliance reasons

  • AWS IAM integration: Fine-grained access control via AWS IAM policies for APIs and resources.
  • Auditability: API activity can be recorded via AWS CloudTrail (verify coverage for your required events).
  • Encryption in transit: TLS for AWS API endpoints. Encryption at rest is handled by AWS (verify KMS/customer-managed key options for your use cases in current docs).

Scalability/performance reasons

  • Designed for high-volume industrial telemetry with batching patterns and server-side storage/query.
  • Hierarchical models help you scale from a single machine to an entire enterprise of plants.

When teams should choose AWS IoT SiteWise

Choose it when you need: – A managed way to model industrial assets and store/query time-series measurements with context – A standard API layer for plant applications – Optional AWS-native dashboards (SiteWise Monitor) and/or edge ingestion (SiteWise Edge) – A foundational layer for downstream analytics/ML

When teams should not choose AWS IoT SiteWise

Avoid it (or validate carefully) when: – You only need simple device telemetry and already have a mature time-series + metadata platform – Your primary need is device fleet management (AWS IoT Device Management may be a better fit) – You require a strict on-prem-only deployment with no cloud connectivity (SiteWise Edge can help with buffering/collection, but cloud connectivity is still central to AWS IoT SiteWise’s managed value) – You need extremely customized historian behavior or protocol support not covered by SiteWise Edge connectors (verify supported protocols/connectors before committing)

4. Where is AWS IoT SiteWise used?

Industries

  • Discrete manufacturing (automotive, electronics, packaging)
  • Process industries (chemicals, oil & gas, pulp & paper)
  • Utilities (power generation/distribution, water treatment)
  • Mining and metals
  • Food and beverage
  • Pharma/biotech (with strong validation and audit requirements—confirm compliance needs and controls)

Team types

  • OT/automation engineers integrating PLC/SCADA data
  • Cloud/platform engineering teams building a centralized industrial data platform
  • Data engineering and analytics teams building OEE/quality/energy dashboards
  • SRE/DevOps teams operating ingestion pipelines and monitoring reliability
  • Security teams reviewing identity boundaries between OT and IT

Workloads and architectures

  • Plant telemetry ingestion → contextualization → dashboards and analytics
  • Condition monitoring (vibration/temperature) → alerts and maintenance workflows
  • Energy monitoring across sites → cost allocation and optimization
  • Line performance metrics (cycle times, throughput) → continuous improvement

Real-world deployment contexts

  • Edge-to-cloud: Collect from PLCs/SCADA on premises, buffer locally, forward to AWS.
  • Cloud-to-cloud: Ingest from existing historians via connectors or custom integration.
  • Hybrid: Some metrics computed at edge, others computed centrally.

Production vs dev/test usage

  • Dev/test often focuses on:
  • Modeling strategy (asset model naming, hierarchies)
  • API integration and batching patterns
  • Dashboard prototypes (if using SiteWise Monitor)
  • Production emphasizes:
  • Reliable ingestion and retry behavior
  • Strict IAM and separation of duties
  • Cost controls and data retention strategy
  • Observability and incident response

5. Top Use Cases and Scenarios

Below are realistic scenarios where AWS IoT SiteWise is commonly used.

1) Plant-wide asset model standardization

  • Problem: Each site uses different tag naming and data structures, making enterprise reporting painful.
  • Why AWS IoT SiteWise fits: Asset models enforce consistent structure and meaning across sites.
  • Example: A manufacturer creates a “CentrifugalPump” model with standardized properties and deploys it across 12 plants.

2) Centralized industrial historian replacement (or complement)

  • Problem: On-prem historian scaling and access for cloud analytics is difficult.
  • Why it fits: Managed ingestion/storage and APIs for time-series asset properties.
  • Example: A utility ingests turbine telemetry into SiteWise for cloud-based analytics while keeping legacy historian for local operations.

3) OEE (Overall Equipment Effectiveness) dashboards

  • Problem: OEE calculations vary by line and are difficult to implement consistently.
  • Why it fits: Asset hierarchy + derived properties enable consistent KPIs.
  • Example: A packaging plant computes availability/performance/quality metrics and surfaces them in dashboards for shift managers.

4) Condition monitoring for rotating equipment

  • Problem: Vibration/temperature trends require time-series storage and contextualization.
  • Why it fits: Store measurements per asset and query history for analysis.
  • Example: A mining company monitors conveyor motors, triggering maintenance tickets when vibration trends exceed thresholds.

5) Energy monitoring and cost allocation

  • Problem: Energy use is measured but not attributed to specific lines/assets.
  • Why it fits: Hierarchies allow rollups from machine → line → plant.
  • Example: A food factory measures kWh per line and correlates with production output to identify inefficiencies.

6) Cross-site performance benchmarking

  • Problem: Comparing lines across plants requires consistent asset definitions and metrics.
  • Why it fits: Standard models and centralized APIs enable enterprise comparisons.
  • Example: Corporate ops compares cycle-time distributions across 30 similar lines worldwide.

7) Data foundation for ML/AI (predictive maintenance)

  • Problem: ML teams spend most time cleaning/tagging data.
  • Why it fits: Asset context and standardized property semantics reduce feature engineering overhead.
  • Example: A team exports asset property history to a data lake for training failure prediction models.

8) Near-real-time operational visibility for supervisors

  • Problem: Supervisors need current states (running/stopped, temp, pressure) without opening SCADA screens.
  • Why it fits: Latest-value APIs and dashboards.
  • Example: A supervisor views current line status on tablets through a SiteWise Monitor portal.

9) Multi-vendor equipment integration

  • Problem: OEM equipment reports similar metrics differently.
  • Why it fits: Asset models normalize properties, and ingestion maps raw signals to standardized property IDs.
  • Example: Different CNC machines publish different tag sets; SiteWise maps them to a common “CNC” model.

10) Compliance and audit-friendly reporting

  • Problem: Need traceable data access and controlled dashboards.
  • Why it fits: IAM-based control for APIs and auditable access patterns (verify compliance controls for your requirements).
  • Example: A regulated manufacturer provides read-only dashboards to auditors with controlled access.

11) Edge buffering for intermittent connectivity (remote sites)

  • Problem: Remote plants have unreliable WAN links; data loss is common.
  • Why it fits: SiteWise Edge can buffer and forward when connectivity returns (verify behavior and limits for your version).
  • Example: An oil field site buffers telemetry locally and syncs to AWS when satellite link is available.

12) Unified data layer for multiple applications

  • Problem: Multiple apps (maintenance, quality, production) need the same telemetry with consistent meaning.
  • Why it fits: SiteWise becomes the shared “asset time-series API”.
  • Example: A maintenance app reads vibration history while a production app reads throughput—all from the same asset model.

6. Core Features

This section summarizes important AWS IoT SiteWise features you should understand for architecture and hands-on work. Always verify the latest feature set and region availability in the official docs.

6.1 Asset models and assets

  • What it does: Lets you define templates (models) and instantiate real-world equipment (assets).
  • Why it matters: Creates consistent semantics across many similar machines and sites.
  • Practical benefit: You can onboard 1,000 motors using one “Motor” model and query them consistently.
  • Limitations/caveats: Modeling requires upfront design; changing models later can require careful migration.

6.2 Properties: measurements, attributes, and computed values

  • What it does:
  • Measurements store time-series readings.
  • Attributes store static metadata.
  • Computed properties (often transforms/metrics) derive values from other properties (verify the exact computation feature definitions and constraints).
  • Why it matters: Separates raw sensor readings from metadata and computed KPIs.
  • Practical benefit: Your apps can read “Efficiency” directly instead of recomputing everywhere.
  • Limitations/caveats: Derived computations have expression and dependency rules; validate correctness and performance. Some computations may have update latency.

6.3 Asset hierarchies (relationships)

  • What it does: Models relationships like parent/child assets (e.g., Plant contains Lines; Line contains Motors).
  • Why it matters: Enables navigation and aggregation by context.
  • Practical benefit: You can build dashboards at multiple levels (machine vs line vs plant).
  • Limitations/caveats: Hierarchy design affects how easily you can browse and manage assets later.

6.4 Ingestion APIs (including batching)

  • What it does: APIs to send timestamped property values to SiteWise, typically in batches.
  • Why it matters: Industrial telemetry is high volume; batching reduces overhead and cost.
  • Practical benefit: Efficient ingestion of many properties across many assets.
  • Limitations/caveats: You must handle retries and idempotency patterns carefully. Validate ingestion quotas and limits in Service Quotas for your region.

6.5 Query APIs for latest and historical values

  • What it does: Retrieve current value and history for a property, enabling apps and analytics to consume data.
  • Why it matters: Separates storage from consumption; simplifies application design.
  • Practical benefit: Dashboards and services can fetch values without direct device connectivity.
  • Limitations/caveats: Query patterns can create cost and performance issues if you poll too frequently at large scale.

6.6 AWS IoT SiteWise Monitor (portals, projects, dashboards)

  • What it does: Provides an AWS-managed web experience to build dashboards and share them with users.
  • Why it matters: Rapid operational visibility without building a custom UI.
  • Practical benefit: OT and operations teams can consume data through dashboards quickly.
  • Limitations/caveats: Commonly depends on an identity integration (often AWS IAM Identity Center). Plan user lifecycle and access control.

6.7 AWS IoT SiteWise Edge (edge collection and buffering)

  • What it does: Runs near industrial equipment to collect data, buffer it, and send to AWS IoT SiteWise.
  • Why it matters: OT networks may not allow direct cloud access from PLCs/SCADA.
  • Practical benefit: Reduces data loss and enables local connectivity patterns.
  • Limitations/caveats: Supported industrial protocols/connectors vary—verify supported connectors for your environment. Requires edge hardware and operations (patching, monitoring).

6.8 Access control via AWS IAM (and user access for dashboards)

  • What it does: Controls who/what can create models/assets, ingest values, and query data.
  • Why it matters: Industrial data often has safety and business sensitivity.
  • Practical benefit: Separate roles for ingestion pipelines vs read-only dashboards.
  • Limitations/caveats: Misconfigured IAM can lead to unintended write access.

6.9 Auditing and operations visibility (CloudTrail/CloudWatch)

  • What it does: Records API calls (CloudTrail) and supports operational monitoring patterns (CloudWatch metrics/logs as applicable).
  • Why it matters: Needed for incident response, compliance, and reliability.
  • Practical benefit: You can trace who changed models or deleted assets.
  • Limitations/caveats: Telemetry data itself typically isn’t logged in CloudTrail; it logs API actions. Design separate data quality monitoring.

7. Architecture and How It Works

High-level architecture

At a high level, AWS IoT SiteWise sits between industrial data sources and industrial applications:

  1. Data sources produce measurements (PLCs, SCADA, sensors, historians, gateways).
  2. Ingestion pipeline sends timestamped property values to AWS IoT SiteWise (direct API calls, or through edge software).
  3. AWS IoT SiteWise stores values and associates them with assets and properties.
  4. Consumers (dashboards, apps, analytics) query latest and historical values.

Data and control flow

  • Control plane: You create asset models, assets, hierarchies, portals, and dashboards.
  • Data plane: You send property values (ingestion) and retrieve property values (query).

Common integrations (design patterns)

  • Edge collection: SiteWise Edge (often with Greengrass) collects from on-prem sources and forwards to SiteWise.
  • Device connectivity: AWS IoT Core is often used for device connectivity and messaging patterns; some deployments use SiteWise ingestion directly without IoT Core.
  • Analytics: Applications pull from SiteWise APIs, or export data to analytics stores (S3 data lake, time-series DB) using AWS-native pipelines or custom solutions.

If you plan to export large volumes to S3 or streaming services, verify current AWS IoT SiteWise export/streaming features in the official documentation—capabilities and naming can evolve.

Security/authentication model

  • API access: AWS IAM (users/roles) authorizes API calls to create models/assets and ingest/query values.
  • Dashboards: SiteWise Monitor typically integrates with an AWS user identity system (commonly AWS IAM Identity Center). Plan user provisioning, MFA, and group-based access.

Networking model

  • AWS IoT SiteWise is accessed via regional AWS service endpoints over HTTPS.
  • For private connectivity, AWS services often support VPC interface endpoints (AWS PrivateLink). Verify in official docs whether AWS IoT SiteWise supports the specific VPC endpoints you need in your target region, and whether it covers both control plane and data plane APIs.

Monitoring/logging/governance

  • AWS CloudTrail: Audit create/update/delete actions and other API calls.
  • Amazon CloudWatch: Monitor service and integration metrics (where available), build alarms on ingestion errors in your pipeline, and track operational KPIs.
  • Tagging: Tag models/assets for cost allocation and governance (where supported).

Simple architecture diagram (Mermaid)

flowchart LR
  PLC[PLCs / Sensors] --> GW[Edge Gateway or App]
  GW -->|BatchPutAssetPropertyValue| SW[AWS IoT SiteWise]
  SW --> APP[Operations App / Dashboard]
  APP -->|GetAssetPropertyValue / History| SW

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Site["On-Premises Site"]
    PLC1[PLCs / SCADA] --> EDGE[AWS IoT SiteWise Edge\n(on Greengrass v2)]
    PLC2[Industrial Sensors] --> EDGE
    EDGE --> BUF[Local Buffering]
  end

  subgraph AWS["AWS Region"]
    SW[AWS IoT SiteWise\nAssets + Time-series]
    MON[AWS IoT SiteWise Monitor\nPortals/Dashboards]
    ID[IAM Identity Center\n(if using Monitor)]
    CW[Amazon CloudWatch]
    CT[AWS CloudTrail]
    DL[S3 Data Lake / Analytics Store\n(optional)]
  end

  BUF -->|Secure upload| SW
  SW --> MON
  ID --> MON
  SW -->|APIs for history/latest| Apps[Custom Apps / Analytics Jobs]
  Apps --> DL
  SW --> CW
  SW --> CT

8. Prerequisites

AWS account and billing

  • An AWS account with billing enabled.
  • Permission to create IAM roles/policies and AWS IoT SiteWise resources.

Required permissions / IAM roles

For the hands-on lab, you need permissions to: – Create/describe/delete asset models and assets – Put and get asset property values – (Optional) Create and manage SiteWise Monitor portals/projects/dashboards

If you’re in an enterprise environment, request a least-privilege role from your admin. For learning, AWS-managed policies may exist, but verify current policy names and recommended least-privilege patterns in the official docs.

Tools

  • AWS CLI v2 installed and configured:
  • https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
  • Configure credentials: aws configure (or SSO-based profiles)
  • (Optional) jq for JSON parsing in the tutorial examples.

Region availability

  • Choose a region where AWS IoT SiteWise is available.
  • Some components (especially visualization/edge features) can have region-specific availability. Verify in official docs.

Quotas / limits

  • AWS IoT SiteWise has limits (assets, models, properties, ingestion rates, API request rates).
  • Check Service Quotas in the AWS Console for “AWS IoT SiteWise” and request quota increases as needed:
  • AWS Console → Service Quotas → AWS IoT SiteWise

Prerequisite services (optional)

  • AWS IAM Identity Center (commonly required if you want to use AWS IoT SiteWise Monitor with managed users)
  • AWS IoT Greengrass v2 (if you plan to deploy AWS IoT SiteWise Edge)

9. Pricing / Cost

AWS IoT SiteWise pricing is usage-based and can vary by region. Do not estimate production costs without validating the current pricing dimensions and rates on the official pricing page.

Official pricing: – AWS IoT SiteWise pricing page: https://aws.amazon.com/iot-sitewise/pricing/ – AWS Pricing Calculator: https://calculator.aws/#/

Common pricing dimensions (verify current ones on the pricing page)

Typical cost drivers include: – Data ingestion volume (often measured in number of data points/measurements ingested) – Data storage (time-series storage retained in the service) – API requests (read/query calls can be a material driver at scale) – AWS IoT SiteWise Monitor usage (often priced per user/month and/or per portal—verify current model) – Edge components: Edge runtime costs may be indirect (compute hardware, Greengrass operations) and/or direct depending on the feature (verify current pricing details for SiteWise Edge)

Free tier

AWS frequently offers free tier options, but they change over time and can vary by service and region. Verify current AWS IoT SiteWise free tier details on the official pricing page.

Direct cost drivers

  • High-frequency telemetry (e.g., 1 Hz across thousands of tags) quickly increases ingestion volume.
  • Long retention of high-cardinality time-series increases storage costs.
  • “Chatty” dashboards that poll frequently can generate high API read costs.

Hidden or indirect costs

  • Data transfer:
  • Data ingestion from the public internet may incur network/egress considerations depending on architecture.
  • Cross-region transfers are typically billable.
  • Edge infrastructure:
  • Industrial gateways, compute instances, and operational overhead (patching, monitoring).
  • Downstream analytics:
  • Export to S3, Glue crawlers, Athena queries, Redshift, OpenSearch—each has separate pricing.

Cost optimization strategies

  • Batch ingestion: Use batch APIs and send fewer, larger payloads instead of per-point calls.
  • Right-size sampling: Don’t ingest at 1 Hz if 10-second intervals are sufficient for your use case.
  • Retention strategy: Decide what needs to stay in SiteWise vs moved to lower-cost storage (e.g., S3).
  • Reduce polling: Prefer event-driven updates where applicable; avoid high-frequency dashboard polling at scale.
  • Model carefully: Avoid excessive duplicate properties; standardize across equipment types.

Example low-cost starter estimate (conceptual)

A small lab setup: – A handful of assets (e.g., 2–10) – A few properties each (temperature, vibration) – Ingestion only a few times per minute for a few hours/day – Minimal dashboards and a few users

This typically stays low-cost, but the exact cost depends on: – Your ingestion rate and duration – Your region pricing – Whether you enable dashboards/users

Use the AWS Pricing Calculator with your expected data points/day and retention.

Example production cost considerations

A production rollout (multiple plants) should model: – Number of assets and properties (tags) – Average sampling rate per property – Burst rates and buffering behavior – Retention and historical query patterns – Number of dashboard users and their polling frequency – Export pipelines and downstream analytics costs

For production, build a spreadsheet or calculator model that includes: – Data points/day = assets × properties × sampling frequency × seconds/day – Read requests/day = dashboards/users × widgets × refresh interval × hours/day Then validate with a pilot and monitor billing metrics.

10. Step-by-Step Hands-On Tutorial

This lab focuses on the core workflow you must understand before adding edge ingestion or dashboards at scale: 1) Create an asset model
2) Create an asset
3) Ingest time-series measurements using AWS CLI
4) Query latest and historical values
5) (Optional) Visualize using AWS IoT SiteWise Monitor
6) Clean up resources

Objective

Create a simple “Motor” asset model with temperature and vibration measurements, ingest a few data points, and query them back using AWS IoT SiteWise APIs.

Lab Overview

  • Estimated time: 45–75 minutes
  • Cost: Low for small test data; you pay for usage (verify pricing).
  • You will create:
  • 1 asset model
  • 1 asset
  • A few measurement data points
  • (Optional) a SiteWise Monitor portal/project/dashboard

Step 1: Choose a region and configure AWS CLI

  1. Set your region (example uses us-east-1; choose one where SiteWise is available):
export AWS_REGION="us-east-1"
aws configure set region "$AWS_REGION"
  1. Verify identity:
aws sts get-caller-identity

Expected outcome: You see your AWS account and principal ARN.

Step 2: Create an asset model (Motor model)

Create a file named asset-model-motor.json:

{
  "assetModelName": "MotorModel-Tutorial",
  "assetModelDescription": "Tutorial motor model with temperature and vibration measurements",
  "assetModelProperties": [
    {
      "name": "Manufacturer",
      "dataType": "STRING",
      "type": {
        "attribute": {
          "defaultValue": "ExampleCo"
        }
      }
    },
    {
      "name": "Temperature",
      "dataType": "DOUBLE",
      "unit": "C",
      "type": {
        "measurement": {}
      }
    },
    {
      "name": "Vibration",
      "dataType": "DOUBLE",
      "unit": "mm/s",
      "type": {
        "measurement": {}
      }
    }
  ]
}

Create the model:

MODEL_ID=$(
  aws iotsitewise create-asset-model \
    --cli-input-json file://asset-model-motor.json \
    --query assetModelId --output text
)

echo "Model ID: $MODEL_ID"

Wait until the model becomes active:

aws iotsitewise describe-asset-model --asset-model-id "$MODEL_ID" \
  --query "assetModelStatus" --output json

Repeat until the state indicates it is active (exact field values can vary; use the returned JSON as truth).

Expected outcome: The model exists and is ready to use.

Step 3: Create an asset from the model

Create an asset:

ASSET_ID=$(
  aws iotsitewise create-asset \
    --asset-name "Motor-01" \
    --asset-model-id "$MODEL_ID" \
    --query assetId --output text
)

echo "Asset ID: $ASSET_ID"

Check the asset status:

aws iotsitewise describe-asset --asset-id "$ASSET_ID" \
  --query "assetStatus" --output json

Expected outcome: The asset “Motor-01” is created and becomes active.

Step 4: Find the property IDs for Temperature and Vibration

To ingest values, you need the property IDs created for the asset.

Describe the asset and list properties:

aws iotsitewise describe-asset --asset-id "$ASSET_ID" \
  --query "assetProperties[*].{name:name,id:id,dataType:dataType,unit:unit}" \
  --output table

Capture the property IDs:

TEMP_PROP_ID=$(
  aws iotsitewise describe-asset --asset-id "$ASSET_ID" \
    --query "assetProperties[?name=='Temperature'].id | [0]" --output text
)

VIB_PROP_ID=$(
  aws iotsitewise describe-asset --asset-id "$ASSET_ID" \
    --query "assetProperties[?name=='Vibration'].id | [0]" --output text
)

echo "Temperature property ID: $TEMP_PROP_ID"
echo "Vibration property ID:   $VIB_PROP_ID"

Expected outcome: You have two IDs you’ll use for ingestion and queries.

Step 5: Ingest a few data points (BatchPutAssetPropertyValue)

Create a timestamp:

TS=$(date +%s)
echo "Timestamp (seconds): $TS"

Create put-values.json:

{
  "entries": [
    {
      "entryId": "temp-1",
      "assetId": "REPLACE_ASSET_ID",
      "propertyId": "REPLACE_TEMP_PROPERTY_ID",
      "propertyValues": [
        {
          "value": { "doubleValue": 62.5 },
          "timestamp": { "timeInSeconds": REPLACE_TS, "offsetInNanos": 0 },
          "quality": "GOOD"
        }
      ]
    },
    {
      "entryId": "vib-1",
      "assetId": "REPLACE_ASSET_ID",
      "propertyId": "REPLACE_VIB_PROPERTY_ID",
      "propertyValues": [
        {
          "value": { "doubleValue": 3.2 },
          "timestamp": { "timeInSeconds": REPLACE_TS, "offsetInNanos": 0 },
          "quality": "GOOD"
        }
      ]
    }
  ]
}

Replace placeholders (use your editor), or do it with sed (example for macOS/Linux):

cp put-values.json put-values.rendered.json

sed -i.bak "s/REPLACE_ASSET_ID/$ASSET_ID/g" put-values.rendered.json
sed -i.bak "s/REPLACE_TEMP_PROPERTY_ID/$TEMP_PROP_ID/g" put-values.rendered.json
sed -i.bak "s/REPLACE_VIB_PROPERTY_ID/$VIB_PROP_ID/g" put-values.rendered.json
sed -i.bak "s/REPLACE_TS/$TS/g" put-values.rendered.json

Now ingest:

aws iotsitewise batch-put-asset-property-value \
  --cli-input-json file://put-values.rendered.json

Expected outcome: The command returns successfully. If there are errors, you’ll see them per-entry (common in permission or ID issues).

Step 6: Query the latest values

Fetch current temperature:

aws iotsitewise get-asset-property-value \
  --asset-id "$ASSET_ID" \
  --property-id "$TEMP_PROP_ID" \
  --output json

Fetch current vibration:

aws iotsitewise get-asset-property-value \
  --asset-id "$ASSET_ID" \
  --property-id "$VIB_PROP_ID" \
  --output json

Expected outcome: You see the latest value with timestamp and quality.

If you query immediately after ingestion, you might see a short delay. Retry after a brief wait.

Step 7: Query historical values (value history)

Query the last 15 minutes (adjust as needed). Create start/end timestamps:

END=$(date +%s)
START=$((END - 900))

aws iotsitewise get-asset-property-value-history \
  --asset-id "$ASSET_ID" \
  --property-id "$TEMP_PROP_ID" \
  --start-date "$START" \
  --end-date "$END" \
  --max-results 50 \
  --output json

Expected outcome: A JSON array of historical values (including the one you inserted).

Step 8 (Optional): Visualize in AWS IoT SiteWise Monitor

This optional step depends on your account setup. Many AWS environments require AWS IAM Identity Center for portal users.

High-level steps (Console): 1. Open AWS IoT SiteWise console: https://console.aws.amazon.com/iotsitewise/ 2. Find AWS IoT SiteWise Monitor (naming may appear as “Monitor” in the console). 3. Create a portal (if you don’t have one). 4. Create a project inside the portal. 5. Associate the asset Motor-01 with the project (so dashboards can access it). 6. Create a dashboard. 7. Add a widget (e.g., line chart) and bind it to: – Asset: Motor-01 – Property: Temperature 8. Save and view.

Expected outcome: You can view the Temperature and Vibration values in a dashboard.

If you cannot create a portal due to identity prerequisites, skip this step and continue with API-based validation.

Validation

Use this checklist:

  1. Asset model exists:
aws iotsitewise describe-asset-model --asset-model-id "$MODEL_ID" --output json
  1. Asset exists:
aws iotsitewise describe-asset --asset-id "$ASSET_ID" --output json
  1. Latest value returns:
aws iotsitewise get-asset-property-value --asset-id "$ASSET_ID" --property-id "$TEMP_PROP_ID"
  1. History returns:
aws iotsitewise get-asset-property-value-history --asset-id "$ASSET_ID" --property-id "$TEMP_PROP_ID" --max-results 5

If all four work, your core SiteWise workflow is functioning.

Troubleshooting

Common issues and fixes:

  1. AccessDeniedException – Cause: IAM policy missing permissions for iotsitewise:* actions used. – Fix: Attach the appropriate permissions to your role/user. Start broad for learning, then refine.

  2. ResourceNotFoundException – Cause: Wrong assetId or propertyId (copy/paste error, wrong region). – Fix: Confirm region and re-run describe-asset to fetch property IDs.

  3. ValidationException on create-asset-model – Cause: JSON schema mismatch (typos in property definitions). – Fix: Compare your JSON with the AWS CLI/API reference for CreateAssetModel. Use the error message to identify the field.

  4. No data returned immediately after ingestion – Cause: Ingestion-to-query propagation delay can occur. – Fix: Wait briefly and retry; confirm timestamps are in seconds and not milliseconds.

  5. Timestamp issues (history query empty) – Cause: Incorrect start/end date range, or ingest timestamp outside range. – Fix: Print your ingest timestamp and compute your history query window around it.

Cleanup

To avoid ongoing costs, delete what you created.

1) Delete asset:

aws iotsitewise delete-asset --asset-id "$ASSET_ID"

2) Delete asset model:

aws iotsitewise delete-asset-model --asset-model-id "$MODEL_ID"

3) Optional cleanup for SiteWise Monitor: – Delete dashboards/projects/portal if created. – Remove or disable IAM Identity Center users/groups created for the lab.

Deletions can take time to propagate. If deletion fails due to dependencies, re-check for related resources (projects/portals/associations) and remove them first.

11. Best Practices

Architecture best practices

  • Model-first design: Define asset models based on how your organization thinks about equipment (maintenance, operations, analytics), not only on raw tag naming.
  • Use consistent naming conventions:
  • Asset model names: Pump, Motor, Boiler
  • Assets: PlantA-Line2-Motor01
  • Properties: Temperature, Pressure, VibrationRMS
  • Design hierarchies carefully: Create stable relationships (Plant → Line → Machine) that match reporting needs.
  • Plan for multi-site scale: Ensure models can be reused; avoid embedding site-specific meaning in model names.

IAM/security best practices

  • Separate roles:
  • Ingestion role: write-only (put values)
  • Viewer role: read-only (get values, dashboards)
  • Admin role: create/update models/assets
  • Least privilege: Start with broad permissions in a sandbox, then restrict using resource-level permissions and explicit actions.
  • Protect delete permissions: Accidental delete of assets/models can be disruptive.
  • Use CloudTrail: Centralize CloudTrail logs and set alerts for destructive actions.

Cost best practices

  • Right-size sampling frequency: The fastest way to overspend is to ingest more frequently than necessary.
  • Batch ingestion: Use batch APIs and send multiple values per request.
  • Control dashboard refresh: Avoid extremely frequent refresh intervals for many users/widgets.
  • Tiering strategy: Keep “hot” operational data readily accessible; archive “cold” data to cheaper storage if needed.

Performance best practices

  • Use predictable query patterns: Avoid unbounded history queries. Use time windows.
  • Cache read-mostly data: If thousands of clients need the same “current value”, consider caching in your application tier.
  • Avoid per-point API calls: Batch both writes and reads where feasible (verify which APIs support batching for your needs).

Reliability best practices

  • Retry with backoff: Build robust retries for ingestion and queries.
  • Handle partial failures: Batch ingestion can return per-entry errors; retry only failed entries.
  • Edge buffering where needed: For unreliable WAN links, use edge buffering patterns (SiteWise Edge and/or local queues).

Operations best practices

  • Operational dashboards: Monitor ingestion success/error rates from your ingestion pipeline.
  • Data quality KPIs: Track missing data, stale values, and out-of-range values.
  • Change management: Version asset models and manage schema changes like software releases.

Governance/tagging/naming best practices

  • Tag resources: e.g., Environment=Dev, Plant=PlantA, CostCenter=1234.
  • Document models: Keep a central catalog of models/properties and definitions.
  • Standardize units: Ensure consistent units across sites; avoid mixing C and F.

12. Security Considerations

Identity and access model

  • API access is controlled by AWS IAM.
  • Visualization access (SiteWise Monitor) often involves AWS IAM Identity Center users and groups (verify current integration and configuration steps).

Recommended patterns: – Use IAM roles for ingestion workloads (EC2/ECS/Lambda/Greengrass roles) rather than long-lived access keys. – Implement strict separation between: – OT ingestion (write) – Analytics consumption (read) – Administrative operations (model changes)

Encryption

  • In transit: Use HTTPS/TLS to AWS service endpoints.
  • At rest: AWS services typically encrypt data at rest by default. Verify whether AWS IoT SiteWise supports customer-managed KMS keys for your specific resources and region (check official docs).

Network exposure

  • Default access is via AWS public endpoints.
  • For private access, investigate VPC endpoints/PrivateLink options. Verify in official docs which endpoints are supported for SiteWise APIs and in which regions.

Secrets handling

  • Do not embed AWS access keys in edge devices or scripts.
  • Use:
  • IAM roles (preferred)
  • AWS Secrets Manager (for any non-AWS credentials your ingestion app needs, e.g., OPC-UA credentials)
  • Rotate credentials and enforce MFA for human users.

Audit/logging

  • Enable AWS CloudTrail in all regions you use.
  • Send CloudTrail logs to a central S3 bucket with restricted access.
  • Alert on:
  • DeleteAssetModel, DeleteAsset, portal deletions
  • IAM policy changes that broaden access

Compliance considerations

  • Map requirements to AWS controls:
  • Identity and access
  • Audit retention
  • Data residency (region choice)
  • Change management (model updates)
  • For regulated environments, validate:
  • Logging coverage
  • Access review processes
  • Data retention and deletion policies

Common security mistakes

  • Using a single over-privileged role for ingestion, reading, and admin tasks
  • Leaving portal/dashboard access too broad
  • Not enabling CloudTrail or not reviewing logs
  • Treating industrial telemetry as “non-sensitive” when it can reveal production volumes, recipes, or operational status

Secure deployment recommendations

  • Use least privilege IAM and separate accounts/environments (dev/test/prod).
  • Use private connectivity when required by policy (verify feasibility).
  • Implement defense-in-depth: network controls + IAM + auditing + change control.

13. Limitations and Gotchas

Always validate current limits in official docs and Service Quotas. Common gotchas include:

  • Regional service boundaries: Models/assets/data live in one region. Cross-region strategies require explicit design.
  • Model change complexity: Changing models in production can be non-trivial—plan versioning and migration.
  • Ingestion timestamp correctness: Seconds vs milliseconds mistakes lead to “missing” history.
  • Polling costs: High-frequency polling across many users can become a major cost driver.
  • Quotas: Ingestion rates, API request rates, and resource counts can limit scale until increased.
  • Edge connector compatibility: Protocol/connector support varies by version and environment—verify before selecting hardware and integration approach.
  • Deletion dependencies: Portals/projects/associations can block cleanup; remove dependencies first.
  • Identity prerequisites for Monitor: SiteWise Monitor may require IAM Identity Center setup; plan this early for enterprise environments.

14. Comparison with Alternatives

AWS IoT SiteWise is not the only way to store and use industrial time-series data. Here’s how it compares at a high level.

Option Best For Strengths Weaknesses When to Choose
AWS IoT SiteWise Industrial asset modeling + time-series ingestion/query + optional dashboards Asset-centric modeling, managed ingestion/storage/query, optional SiteWise Monitor and edge options Requires modeling effort; costs scale with ingestion/reads; feature availability varies by region You want a managed industrial data foundation on AWS
AWS IoT Core Device connectivity and MQTT messaging Device identity, secure messaging, rules engine Not an industrial asset historian by itself You need device connectivity; pair with SiteWise or other storage
Amazon Timestream Time-series database for applications Powerful time-series queries, SQL-like access Lacks industrial asset modeling primitives out of the box You want a general time-series DB and will implement asset context yourself
AWS IoT TwinMaker Digital twins and visualization of operational data Twin graph, integrates multiple data sources Not a historian replacement; often consumes from SiteWise/other sources You need a digital twin layer; use SiteWise as a data source
Azure (IoT + Time Series / Data services) Azure-native industrial/IoT stacks Strong integration in Azure ecosystem Different modeling/ops patterns; migration complexity Your organization is standardized on Azure
Self-managed historian / time-series (InfluxDB, TimescaleDB, etc.) Full control, on-prem-first Customizable, can run anywhere You operate scaling, HA, backups, security Strict on-prem requirements or very custom needs
Google Cloud IoT Core (retired) N/A N/A Service retired Not recommended; consider alternatives

Notes: – Some IoT services across clouds have changed availability over time (for example, Google Cloud IoT Core was retired). Always validate the current status of alternatives. – In AWS, IoT Core and Greengrass are often complementary to SiteWise rather than replacements.

15. Real-World Example

Enterprise example: Multi-plant manufacturing operations visibility

  • Problem: A global manufacturer has 20 plants with inconsistent tag naming and limited enterprise visibility. Corporate wants standardized KPIs (OEE, downtime, throughput) and faster root-cause analysis.
  • Proposed architecture:
  • Edge gateways at each plant collect PLC/SCADA signals (using SiteWise Edge or an equivalent ingestion application).
  • AWS IoT SiteWise models standard equipment types (lines, stations, machines).
  • Ingestion pipelines send measurements to SiteWise in the regional AWS account dedicated to industrial data.
  • SiteWise Monitor dashboards provide role-based visibility (plant manager vs line supervisor).
  • A data lake in S3 stores long-term historical data for analytics, with curated datasets for BI tools.
  • Why AWS IoT SiteWise was chosen:
  • Asset model abstraction standardized data across plants.
  • Managed ingestion/storage reduced operational overhead versus a self-managed historian cluster.
  • Tight AWS integration with IAM, CloudTrail, and analytics services.
  • Expected outcomes:
  • Faster rollout of consistent dashboards across plants
  • Reduced time spent mapping tags for analytics
  • Improved uptime through better visibility into leading indicators (temperature/vibration trends)

Startup/small-team example: Condition monitoring as a SaaS offering

  • Problem: A small team is building a condition monitoring solution for industrial customers. They need to ingest motor sensor data, store it reliably, and provide customer dashboards without building a time-series backend from scratch.
  • Proposed architecture:
  • Customer sites deploy a small gateway that sends measurements to AWS.
  • AWS IoT SiteWise stores measurements per customer asset and provides history queries.
  • The startup’s application queries SiteWise for charts and triggers alerts through application logic.
  • Customer-specific isolation is achieved through separate AWS accounts or strict IAM boundaries (depending on tenancy model).
  • Why AWS IoT SiteWise was chosen:
  • Faster time to market with managed historian-like storage and asset context
  • Easier to build a consistent asset schema per customer
  • Expected outcomes:
  • Rapid onboarding of new customers (reuse asset models)
  • Reduced infrastructure maintenance burden for the small team

16. FAQ

1) Is AWS IoT SiteWise a time-series database?
It provides time-series storage and query capabilities for asset property values, but it’s best thought of as an industrial asset modeling + time-series data service rather than a general-purpose TSDB. For advanced TSDB query needs, some teams export data to purpose-built stores as well.

2) Do I need AWS IoT Core to use AWS IoT SiteWise?
Not always. You can ingest directly using SiteWise APIs. AWS IoT Core is commonly used for device connectivity and messaging patterns, but it’s not mandatory for every SiteWise deployment.

3) What’s the difference between asset models and assets?
An asset model is a template (e.g., “Motor”). An asset is an instance (e.g., “Motor-01”) created from that template.

4) What are measurements vs attributes?
Measurements are time-series values (temperature over time). Attributes are static metadata (manufacturer, serial number).

5) Can AWS IoT SiteWise compute derived metrics like OEE?
AWS IoT SiteWise supports computed properties (often described as transforms/metrics) for derived values. The exact compute capabilities, expressions, and limitations should be verified in the latest official documentation.

6) How do I ingest data efficiently?
Use batching APIs, send values at appropriate sampling rates, and implement retry with exponential backoff. Avoid per-point ingestion calls.

7) How do I avoid high query costs?
Avoid frequent polling from many clients; cache where possible; use dashboards responsibly (refresh intervals), and query only the required time windows.

8) Is AWS IoT SiteWise suitable for regulated environments?
It can be used with AWS security controls (IAM, CloudTrail, encryption). However, you must validate your specific compliance requirements and implement proper governance, logging, and access controls.

9) Does AWS IoT SiteWise support private connectivity (no public internet)?
Some AWS services support VPC endpoints via AWS PrivateLink. Verify whether AWS IoT SiteWise supports the endpoints you need in your region and whether it covers your required APIs.

10) What is AWS IoT SiteWise Monitor?
It’s the visualization component that lets you build portals/projects/dashboards over SiteWise asset data.

11) Do I need IAM Identity Center for SiteWise Monitor?
In many setups, yes—Monitor commonly relies on AWS-managed user access. Verify the current authentication and user management requirements in the Monitor documentation.

12) How does AWS IoT SiteWise handle late or out-of-order data?
Industrial systems often deliver delayed data. SiteWise can store values with timestamps; your design should define how you handle late-arriving updates and ensure your queries/metrics behave correctly. Verify specifics in docs if you rely on strict ordering guarantees.

13) Can I model multiple plants and lines?
Yes. Use hierarchies to represent Plant → Line → Machine relationships, and create assets for each real entity.

14) How do I migrate from an on-prem historian?
Typically you: – Define SiteWise asset models – Map historian tags to SiteWise properties – Backfill historical data (if needed) using supported ingestion patterns – Run in parallel during validation
Migration approaches vary—validate supported backfill mechanisms and ingestion quotas.

15) What’s the quickest way to start?
Start with one asset model, one asset, ingest a few points via AWS CLI (like this lab), then expand to edge ingestion and dashboards once your model is solid.

16) How do I organize resource ownership in a large enterprise?
Common patterns include: – Central platform team owns models/standards – Plant teams own asset instantiation and edge deployments – Clear IAM boundaries for ingestion vs consumption

17) Should I store all history in SiteWise forever?
Not always. Many teams retain “recent/hot” data in SiteWise and export older data to S3 for long-term archival and large-scale analytics. Choose retention based on cost and query needs.

17. Top Online Resources to Learn AWS IoT SiteWise

Resource Type Name Why It Is Useful
Official Documentation AWS IoT SiteWise Docs Primary source for concepts, APIs, limits, and guides. https://docs.aws.amazon.com/iot-sitewise/
Official API Reference AWS IoT SiteWise API Reference Exact request/response schemas for CLI/SDK usage. https://docs.aws.amazon.com/iot-sitewise/latest/APIReference/
Official Pricing AWS IoT SiteWise Pricing Current pricing dimensions and rates by region. https://aws.amazon.com/iot-sitewise/pricing/
Pricing Tool AWS Pricing Calculator Model ingestion/query/storage costs before production. https://calculator.aws/#/
Console AWS IoT SiteWise Console Build models/assets and view configuration in the UI. https://console.aws.amazon.com/iotsitewise/
Monitor Docs AWS IoT SiteWise Monitor Documentation (in SiteWise docs) Guidance for portals/projects/dashboards and user access. Start at https://docs.aws.amazon.com/iot-sitewise/ and navigate to Monitor sections.
Edge Docs AWS IoT SiteWise Edge Documentation (in SiteWise docs) Edge collection patterns, requirements, and deployment steps. Start at https://docs.aws.amazon.com/iot-sitewise/ and navigate to Edge sections.
Security AWS CloudTrail User Guide Audit logging patterns for SiteWise API activity. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/
IAM IAM User Guide Building least-privilege policies for ingestion and read access. https://docs.aws.amazon.com/IAM/latest/UserGuide/
Architecture Guidance AWS Architecture Center Reference architectures and best practices (search for “IoT SiteWise”). https://aws.amazon.com/architecture/
Videos AWS Events / AWS YouTube Demos and architecture talks (search “AWS IoT SiteWise”). https://www.youtube.com/@amazonwebservices
Samples (verify currency) AWS Samples on GitHub (search) Implementation examples; validate repository ownership and maintenance. https://github.com/aws-samples (search within org)

18. Training and Certification Providers

Institute Suitable Audience Likely Learning Focus Mode Website URL
DevOpsSchool.com Beginners to advanced engineers Cloud/DevOps/IaC and operational practices; check for IoT-focused offerings Check website https://www.devopsschool.com/
ScmGalaxy.com Students and early-career professionals DevOps fundamentals and tooling; verify IoT coverage Check website https://www.scmgalaxy.com/
CLoudOpsNow.in Cloud engineers and ops teams Cloud operations and platform practices; verify AWS IoT content Check website https://www.cloudopsnow.in/
SreSchool.com SREs, DevOps, reliability-focused teams Reliability engineering practices; apply to IoT/industrial data ops Check website https://www.sreschool.com/
AiOpsSchool.com Ops + data practitioners AIOps concepts (monitoring, anomaly detection workflows); verify IoT modules Check website https://www.aiopsschool.com/

19. Top Trainers

Platform/Site Likely Specialization Suitable Audience Website URL
RajeshKumar.xyz DevOps/cloud training content (verify specific AWS IoT coverage) Learners seeking trainer-led guidance https://rajeshkumar.xyz/
devopstrainer.in DevOps training and mentoring (verify IoT topics) Engineers upskilling in cloud/DevOps https://www.devopstrainer.in/
devopsfreelancer.com DevOps consulting/training platform (verify offerings) Teams wanting practical DevOps help https://www.devopsfreelancer.com/
devopssupport.in DevOps support and training (verify AWS IoT coverage) Ops teams needing hands-on support https://www.devopssupport.in/

20. Top Consulting Companies

Company Likely Service Area Where They May Help Consulting Use Case Examples Website URL
cotocus.com Cloud/DevOps consulting (verify IoT specialization) Architecture, implementation, operations Landing-zone + IAM setup; CI/CD for ingestion apps; observability https://cotocus.com/
DevOpsSchool.com Training + consulting (verify IoT offerings) Enablement and delivery support Skills uplift for platform team; delivery acceleration for AWS projects https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting services DevOps process/tooling, cloud ops IaC pipelines; monitoring/alerting; operational runbooks https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before AWS IoT SiteWise

  • AWS fundamentals: IAM, VPC basics, CloudWatch, CloudTrail
  • IoT basics: MQTT concepts, device identity, edge vs cloud patterns
  • Industrial basics (helpful): PLC/SCADA concepts, tag-based telemetry, common KPIs (OEE, downtime)

What to learn after AWS IoT SiteWise

  • AWS IoT Core (if you need device connectivity and message routing)
  • AWS IoT Greengrass v2 (for edge runtime patterns)
  • Data engineering on AWS:
  • S3 data lakes, Glue, Athena
  • Streaming ingestion patterns if required
  • Analytics and visualization:
  • QuickSight or Grafana (if you need alternatives to Monitor)
  • Security deep dive:
  • IAM least privilege
  • Centralized logging and SIEM integrations

Job roles that use it

  • Industrial IoT Engineer / IIoT Architect
  • Cloud Solutions Architect (Manufacturing/Industrial)
  • OT/IT Integration Engineer
  • Data Engineer (Industrial data platform)
  • SRE/DevOps Engineer supporting ingestion and operations dashboards

Certification path (AWS)

AWS certifications change over time, but commonly relevant ones include: – AWS Certified Solutions Architect (Associate/Professional) – AWS Certified SysOps Administrator (Associate) – AWS Certified DevOps Engineer (Professional) – Specialty certifications depending on your analytics/security direction
Verify the current AWS certification catalog: https://aws.amazon.com/certification/

Project ideas for practice

  1. Model a small factory: Plant → Line → Machine with 3–5 assets.
  2. Build an ingestion app that batches values and retries safely.
  3. Add a derived “HealthScore” property computed from vibration and temperature (verify compute features).
  4. Build a dashboard for current status + 24-hour trend.
  5. Export history to S3 and query it with Athena.
  6. Implement least-privilege IAM: separate writer and reader roles.

22. Glossary

  • Industrial Internet of Things (IIoT): Applying IoT patterns to industrial environments (plants, machines, sensors).
  • OT (Operational Technology): Hardware/software that monitors and controls physical devices (PLCs, SCADA).
  • Asset model: A template defining properties and relationships for a type of equipment.
  • Asset: An instance of an asset model representing a real machine/process.
  • Property: A data field on an asset (measurement, attribute, or computed value).
  • Measurement: Time-series sensor reading (timestamped).
  • Attribute: Static metadata value (non-time-series).
  • Hierarchy: Parent/child relationship between assets (Plant contains Line, etc.).
  • Ingestion: Writing data points into SiteWise.
  • Batch ingestion: Sending multiple values per API request for efficiency.
  • Time-series: Data points indexed by time (temperature over time).
  • CloudTrail: AWS service that logs API calls for auditing.
  • CloudWatch: AWS monitoring service for metrics, logs, and alarms.
  • IAM: AWS Identity and Access Management for authorization of API calls.
  • IAM Identity Center: AWS service for workforce identity and SSO (commonly used for managed user access to portals).

23. Summary

AWS IoT SiteWise is AWS’s managed service for industrial asset modeling and time-series data ingestion/storage/query, designed to turn raw Internet of Things (IoT) telemetry into contextualized asset data that operations and analytics teams can use.

It matters because industrial data is only useful at scale when it has structure (models/assets/hierarchies), governance (IAM + audit), and standard access patterns (latest/history APIs and optional dashboards). Cost and security outcomes depend heavily on your ingestion rate, query/polling patterns, retention strategy, IAM boundaries, and audit/logging posture.

Use AWS IoT SiteWise when you want a managed industrial data foundation on AWS—especially when you also need optional dashboards (SiteWise Monitor) and/or edge collection (SiteWise Edge). Start with a small model and a small set of properties, validate ingestion/query behavior, then scale out with clear naming, least-privilege IAM, careful hierarchy design, and a cost model based on data points and read patterns.

Next learning step: read the official docs and API reference, then extend this lab into an edge ingestion pilot and a production-grade IAM + observability design. – Docs: https://docs.aws.amazon.com/iot-sitewise/ – Pricing: https://aws.amazon.com/iot-sitewise/pricing/