Predictive Maintenance on AWS: A Reference Architecture

If you have decided that AWS is where your predictive maintenance programme will live, this is the architecture I would sketch on the whiteboard in the first workshop. It is deliberately a reference architecture rather than a recipe: it names the layers, says which AWS services normally occupy each one, and is explicit about the decisions that are yours rather than the platform's. What it does not do is pretend that standing up the architecture is the same thing as succeeding at predictive maintenance. Those are very different projects, and confusing them is the single most common reason these programmes stall after the pilot.

The message up front: the cloud platform is the least difficult part of predictive maintenance. Sensor selection, failure-mode understanding, data quality, asset master data, and the organisational discipline to act on a prediction are all harder than any AWS service you will configure. This article describes how to assemble the platform well. It is not a claim that assembling it well makes the programme work.

1. The honest framing before any service names

I want to set expectations properly, because architecture articles tend to create a false sense of progress. Over years of CMMS, EAM and industrial integration work, I have watched several organisations build a technically competent cloud telemetry platform and then discover that they still could not predict a failure. The platform was not the constraint. The constraints were that nobody had written down the failure modes worth predicting, the asset register was inconsistent, the sensors chosen measured the wrong thing at the wrong sample rate, and no process existed to turn an alert into work.

So read what follows as plumbing, expertly specified plumbing, but plumbing. The reliability engineering that decides what is worth predicting sits outside this article entirely; the predictive maintenance practitioner's guide covers the strategy side, and the modelling reality is treated in depth in machine learning for predictive maintenance. I will not re-teach either here.

One further boundary. This is an AWS article. Whether AWS is the right cloud for you, and how it compares with the alternatives on cost model, industrial tooling maturity and data residency, belongs in the cloud platform comparison. Sibling walkthroughs exist for Microsoft Azure and Google Cloud. From here on, assume the decision is made.

A standing caveat that applies to every service named below: AWS renames services, repositions them, folds capability from one into another, and occasionally deprecates a product that an architecture diagram depended on. Service names and the boundaries between them change. Treat the current AWS documentation at aws.amazon.com as authoritative over anything written here, and validate service availability in your target region before committing to a design.

2. The seven layers, and the mapping to AWS services

Every predictive maintenance platform I have worked on, regardless of cloud, decomposes into the same seven layers. Naming them separately matters because it stops the conversation collapsing into "we will use SageMaker", which is a statement about one layer out of seven and usually the one that matters least in year one.

• Edge and connectivity: getting a signal off the asset and onto a network you control, including protocol translation from the industrial world.
• Ingestion: accepting that signal into the cloud at the rate it arrives, durably, without losing data during a network outage.
• Storage: keeping raw telemetry cheaply for years and hot telemetry queryably for weeks.
• Processing: cleaning, resampling, aligning to asset identity, and deriving features.
• Modelling: anomaly detection first, and possibly supervised or remaining-useful-life models much later.
• Serving: putting the output in front of a human in a form they trust.
• Write-back: turning an accepted prediction into a work order in the maintenance system of record.

Here is the mapping I would start a design review from. It is a starting point for discussion, not a prescription, and several rows have legitimate alternatives.

Two observations about that table. First, most of it is not machine learning. Second, no row of it is unique to predictive maintenance except the SiteWise row, which is the genuinely distinctive part of the AWS story for industrial assets and deserves its own section.

3. IoT SiteWise and the industrial asset model

The thing that separates an industrial telemetry platform from a generic data platform is that measurements mean nothing without asset context. A tag called PMP_04_VIB_X is meaningless three years later unless something records that it is the horizontal vibration channel on the bearing of pump 4 in the chilled water plant of building B, that the pump is a specific model, and that the channel is expected to sit within a particular band at a particular duty.

IoT SiteWise exists to hold exactly that. You define asset models, which are reusable templates describing the measurements, attributes and derived metrics a class of asset has, and then you instantiate assets from those models and arrange them into a hierarchy. Measurements flow in and land against the asset, not against a bare tag. Derived metrics can be computed as part of the model rather than in bespoke downstream code.

I think this is the strongest argument for AWS in an industrial predictive maintenance context, and it is also where the most under-appreciated governance problem lives.

Now the problem. You already have an asset hierarchy. It lives in your CMMS or EAM, it is the hierarchy that work orders, costs, warranties and statutory records hang off, and it was built by maintenance people for maintenance purposes. The SiteWise hierarchy will be built by the platform team for telemetry purposes. Left alone, the two diverge within months: an asset gets replaced in the field, the CMMS record is updated by the planner and the SiteWise instance is not, and now your prediction is attributed to an asset that no longer exists.

In practice I would advise treating the maintenance system as master for asset identity and structure, and SiteWise as a projection of it enriched with measurement detail the CMMS has no business holding. The design principles for that master hierarchy are the same ones that apply to any asset register, covered in asset hierarchy design, and the ownership question is a classic case of the discipline described in master data management for assets.

4. The edge decision: what belongs on Greengrass

AWS IoT Greengrass lets you run code, including inference, on hardware at the plant while still managing that hardware from the cloud. The question is not whether to use it but what to put on it, and the honest answer is: as little as you can get away with, and specifically the things that cannot be done anywhere else.

Four workloads genuinely earn their place at the edge. Protocol translation, because industrial equipment speaks OPC UA, Modbus and vendor-specific protocols that you do not want to expose to a wide area network. Buffering, because plant network links fail and you cannot lose a week of vibration data when they do. Decimation, because high-frequency raw vibration at full fidelity is expensive to ship and store, and shipping computed features or windowed summaries is often sufficient. And latency-critical local control or safety interlocks, which should never depend on a cloud round trip and arguably should not depend on Greengrass either.

What does not belong at the edge is model training, cross-fleet comparison, and anything that benefits from seeing the whole estate at once. Nor does the long-term archive. The broader trade-off is treated on its own terms in edge versus cloud for predictive maintenance, so I will leave the general case there.

One practical warning from integration work: every piece of logic you push to the edge becomes a fleet-management obligation. Edge devices need updating, certificate rotation, monitoring, and a story for what happens when one dies in a plant room on a Friday evening. Greengrass provides mechanisms for much of this, but the operational burden is real and it lands on a team that may not have expected it.

5. Time-series storage, and why a relational database is the wrong default

The instinct of most in-house teams is to put telemetry in the relational database they already run. It works for the pilot and then it does not, for reasons that are structural rather than a matter of tuning.

Sensor data is append-heavy, rarely updated, queried almost exclusively by time range and asset, and needs operations that a general-purpose relational engine treats as afterthoughts: downsampling, interpolation across irregular sample intervals, gap filling, last-value-before-timestamp lookups, and windowed aggregation over long ranges. It also arrives in volumes where index maintenance and row overhead start to dominate. You can force a relational database to do all of this, and teams do, and the result is a maintenance burden that grows with the estate.

The layered approach I would recommend on AWS has three tiers with different jobs:

• Raw landing and archive in S3, partitioned by asset and time, in a columnar format. This is the source of truth. If every other store is lost you can rebuild from here, which is a property worth paying for.
• Hot time-series store for the recent window that engineers and models query interactively. Amazon Timestream is the purpose-built option; SiteWise also retains data with time-series semantics, which for a SiteWise-centric design may be sufficient on its own.
• Analytical access over the archive via Glue catalogue plus Athena for SQL, with EMR reserved for heavier distributed work such as large backfills or feature computation across years of history.

Retention policy is an architecture decision, not an operations detail, and it is worth forcing early. How long do you keep full-fidelity raw data, how long do you keep aggregates, and what do you keep forever because a warranty claim or a regulator might ask? Decide that before you have three years of undeleted raw data and a finance conversation. If the platform is also meant to serve broader analytics, the lakehouse patterns in data lakes and lakehouses for maintenance telemetry apply directly here.

6. The modelling reality: anomaly detection first

This is where expectations most need managing. The programme sponsor has usually been shown a slide promising remaining useful life in days. What the data will actually support in year one is anomaly detection, and that is fine, because anomaly detection delivers most of the early value.

The reason is label scarcity. Supervised failure prediction needs examples of failures, correctly labelled, with the telemetry around them intact, and enough of them across similar assets for a model to learn a signature. Most organisations do not have this. They have a CMMS where the failure was recorded as a corrective work order with a free-text description, no failure code or an inconsistently applied one, an uncertain failure timestamp, and no telemetry at all from before the sensors were installed last year. That is not a training set. It is a reminder that the labelled history you need is created by disciplined maintenance recording over years, and cannot be bought with the platform.

The sequence I would recommend: start with unsupervised anomaly detection, which needs only a reasonable picture of normal operation. AWS offers managed anomaly-detection capability, and Amazon Lookout for Equipment was positioned specifically at industrial equipment anomaly detection, though this is precisely the kind of service positioning that changes, so check its current status before designing around it. A managed service is a reasonable starting point because it gets you to a working detector without building an ML platform, and it tells you quickly whether your sensors and asset model are good enough to detect anything at all. If they are not, a custom model would not have saved you.

Move to custom models in SageMaker when you have a specific, evidenced reason: a failure mode the managed detector misses, a feature set that needs domain physics, or a fleet large enough and consistent enough that a supervised classifier is genuinely trainable. Remaining useful life estimation comes last, if at all. The general treatment of all of this sits in anomaly detection and early fault warning.

7. The last mile: writing a prediction back as a work order

This is the layer that decides whether the whole programme survives, and it is the layer that is routinely descoped to fund more sensors. A prediction that lands on a dashboard is an interesting observation. A prediction that lands as a work order in the system where the technician already works, with an asset, a priority, a description and a planner to schedule it, is maintenance. Only the second one changes a failure rate.

Architecturally, the pattern I would build on AWS is straightforward. The detector or model publishes a finding as an event. EventBridge routes it. A Lambda function applies business rules, deduplicates against open work, maps the SiteWise asset to the CMMS asset identifier, and calls the maintenance system's API to raise the work request. The CMMS then owns it, and the closing feedback from the technician flows back as a labelled outcome, which over time is how you build the failure history you did not have in section six.

Several details make the difference between an integration that survives and one that gets switched off:

• Raise a request, not a work order, at first. Let a planner triage. Auto-creating approved work orders from a young model is how you flood a maintenance backlog and lose the planners' goodwill permanently.
• Deduplicate aggressively. A persistent anomaly will fire repeatedly. One open item per asset per condition, updated rather than duplicated, is the only acceptable behaviour.
• Carry the evidence. The work request should link back to the chart and the window that triggered it. A technician sent to inspect a pump with no reason given will close it as no fault found.
• Make the write-back idempotent and retryable. The CMMS API will be unavailable sometimes. A queue in front of the call and an idempotency key on the request prevents both loss and duplication.
• Capture the outcome. Whether the predicted condition was actually found is the single most valuable data point the programme generates. Design its capture into the work order closure, not as an afterthought.

The integration patterns themselves are ordinary enterprise integration, and the same considerations apply as in any IoT to CMMS integration. Whether your maintenance platform is IBM Maximo, Hexagon EAM, Infor EAM, SAP PM, Planon or a mid-market tool such as Fiix or Limble changes the API surface and the authentication story, not the pattern.

8. The OT/IT boundary: why plant data does not simply flow to the cloud

Architecture diagrams draw an arrow from the plant floor to the cloud. In reality that arrow crosses a boundary that exists for good reasons and is defended by people whose job is to defend it.

Operational technology networks are segmented deliberately. Control systems have availability and safety requirements that make unsolicited inbound connections unacceptable, and in many organisations the control network is governed by a separate team with a separate risk appetite and separate standards. The practical consequences for your design: traffic should be outbound-initiated only, a data diode or tightly controlled gateway layer may be mandated, and the historian rather than the control system is usually the correct source. Reading from an existing process historian is almost always easier to get approved than reading from the PLC layer, and it is also usually better data because it has already been contextualised. The specifics of that route are covered in SCADA historian integration.

Expect this to be a schedule item, not a technical footnote. In my experience the security review of the OT to cloud path takes longer than building everything above it, and starting that conversation in month one rather than month six is the single highest-leverage scheduling decision available to you.

9. Identity, security and data residency

A few structural points, kept deliberately at principle level because the details change and your security team will have opinions.

• Device identity is certificate-based. IoT Core authenticates devices with X.509 certificates and authorises them with policies. Plan certificate provisioning, rotation and revocation as a lifecycle process, because a fleet of devices with certificates nobody can rotate is a liability that grows quietly.
• Least privilege on the data path. Each component should hold only the permissions it needs: the ingestion path should not be able to read the archive, and the analytics role should not be able to write to it. IAM makes this expressible; the work is in actually doing it rather than granting broad access during the pilot and never revisiting.
• Encryption in transit and at rest should be assumed rather than debated, with a clear position on who controls the keys.
• Region choice is a residency decision. Data stays in the region you put it in, so the region is where your regulatory and contractual obligations are satisfied or breached. Service availability also varies by region, and I have seen designs that assumed a service was present in a required region and had to be reworked. Verify this early for every service in your diagram.
• Network isolation between the analytics estate and the ingestion estate is worth designing in from the start. Retrofitting segmentation into a running platform is far more expensive than specifying it.

For organisations working to a recognised framework, the relevant standards for industrial security and for asset management are published by ISO and by ISA , and aligning the design to whichever your organisation has committed to is cheaper than arguing about it at audit.

10. Cost drivers, described structurally

I am not going to put figures in this article, because cloud pricing changes and a stale number is worse than none. What does not change is the shape of the bill, and understanding the shape lets you model your own case properly.

Five drivers dominate. Ingestion volume, which is a function of sensor count multiplied by sample rate, and which is the one variable most often set by a sensor vendor default rather than a deliberate engineering decision. Storage, which is volume multiplied by retention multiplied by tier, and which grows monotonically unless someone owns a lifecycle policy. Compute for training versus compute for inference, which behave completely differently: training is bursty and can often wait for cheaper capacity, while inference is continuous and small per event but relentless. Query and processing, where scan-based pricing over a badly partitioned archive can cost more than the storage it reads. And egress, which is the one that surprises people, because moving data out of the cloud or between regions is charged in a way that moving it in is not.

The usual surprises, in the order I tend to encounter them:

• Sample rate set too high by default. Nobody asked what resolution the failure mode actually requires, so everything streams at the sensor's maximum. This single decision can dominate the bill.
• No lifecycle policy on raw data. Full-fidelity telemetry from three years ago sitting in hot storage because deleting it felt risky and no retention decision was ever made.
• Poor partitioning making analytical queries expensive. An archive not partitioned by asset and time means every query scans far more than it needs.
• Idle inference endpoints. Persistent endpoints provisioned for a pilot and never torn down, scoring nothing, billing continuously.
• Dashboard licensing counted late. Per-user analytics licensing scales with the number of people you want to show results to, which is exactly the number you hope will grow.
• Non-production environments. Development and test estates that mirror production and run continuously, quietly doubling the platform cost.

11. A staged build sequence that delivers before any model exists

The sequencing principle is this: every phase must leave the organisation better off even if the next phase is cancelled. That rules out the common plan where nothing is useful until the model works.

Note that phase 3 comes before phase 4. That is deliberate and it is the ordering I would argue hardest for. Build the path from insight to work order while the insights are simple thresholds you understand completely. By the time a model is producing findings, the route from finding to closed work order is already trusted infrastructure. Programmes that build the model first and the write-back last usually never build the write-back.

The idea to walk away with

AWS gives you a complete and coherent set of parts for a predictive maintenance platform, and IoT SiteWise gives it a genuinely useful industrial asset-modelling layer that generic data platforms lack. Assemble those parts in layers, decide the edge boundary and the retention policy deliberately, use purpose-built time-series storage rather than the relational database you happen to own, start with anomaly detection rather than supervised prediction, and build the write-back into the maintenance system before you build the model.

And hold on to the framing from the first section. The architecture is the tractable part. The failure-mode analysis, the asset master data, the sensor engineering and the organisational habit of acting on a prediction are where these programmes are won or lost, and no service in the table above will do any of that for you.

Final thoughts

If I were reviewing a proposed AWS predictive maintenance design tomorrow, three questions would tell me most of what I needed to know. Who owns the reconciliation between the SiteWise asset model and the CMMS asset register, by name? What does the organisation do, procedurally, on the day the first anomaly is detected? And which phase of the build delivers value if the budget is cut after it? A design with confident answers to those three is usually sound regardless of the service choices. A design with impressive service choices and no answers to those three is a platform in search of a programme.

Service names and boundaries on AWS will keep moving, so verify everything above against current documentation before you commit. The layer structure, the sequencing and the governance obligations will outlast the service names, which is why they are what this article spends most of its words on.

Related reading: Choosing a cloud for predictive maintenance, Edge vs cloud for predictive maintenance, Data lakes and lakehouses for maintenance telemetry, Asset hierarchy design, SCADA historian integration, Predictive maintenance practitioner's guide.