OPC UA and AWS - Integrating OPC UA Server with AWS IoT SiteWise

OPC UA Integration with AWS - how to connect an OPC UA server to AWS IoT SiteWise or MQTT so that PLC data reaches the cloud and databases like TimescaleDB. The article is for people who already know what OPC UA is and need an explanation of how it can be integrated with AWS services.

Industry 4.0 is primarily about collecting data from machines, objects, and processes, and then making informed decisions based on that data. This enables advanced analytics, AI/ML modeling, and real-time analysis, which allows for improved production efficiency. With AWS IoT SiteWise, you pay only for what you use, without minimum fees or mandatory service usage. Charges are applied separately for messages, data processing, data storage, data export, and alarms. This allows for creating a Proof of Concept with a minimal budget, and then scaling as needed.

We integrate OPC UA, as well as other communication protocols (Modbus TCP, Siemens S7, MQTT) with AWS in factories. Most often using one of the three architectures described below.

OPC UA - what it is and what port it uses

OPC UA (Open Platform Communications Unified Architecture) is an industrial communication standard that defines how OT devices (PLCs, sensors, controllers) expose their data externally. Successor to the older OPC DA - works cross-platform (Linux, Windows, embedded), has built-in security model (certificates, encryption, user authorization) and allows modeling data in the form of structures (asset model).

The default OPC UA port is 4840 for the binary variant (opc.tcp://). The standard also allows opc.http:// on port 80 and opc.https:// on port 443, but in practice in factories 99% of deployments are opc.tcp on port 4840. This is the first port that needs to be opened between the OT network and the industrial gateway.

3 architectures for OPC UA integration with AWS

Architecture 1 - AWS IoT SiteWise Edge Gateway

This is the native AWS path for OPC UA integration with the cloud. It can also connect natively to: MQTT broker, CloudRail, EasyEdge, Litmus Edge. SiteWise Edge Gateway can be deployed on two edge platforms:

• Self-Hosted - the most common option, PC with Linux or Windows
• Siemens Industrial Edge - for factories with existing Siemens infrastructure

Stack: PLC with OPC UA server → PC with SiteWise Edge Gateway → AWS IoT SiteWise in the cloud → Database / S3 / other AWS services.

When it makes sense:

• Greenfield project
• Standard asset models (machine, line, hall)
• Budget for a dedicated Industrial PC
• You want to use the native AWS approach without maintaining your own code

Real pitfalls:

Duplicate TQVs. AWS warns about this in the IoT SiteWise documentation. Effect: double billing for the same data. Fix: always check node filtering configuration.

No filters = unexpected bill. Without node filters, the entire tree goes to the cloud. Always use wildcards and test on a test environment.

Architecture 2 - Custom Greengrass Component (OPC UA via MQTT)

Greengrass with OPC UA is a flexible path when you need logic on the edge before data reaches the cloud. Some calculations, filtering can be done on the gateway before sending to the cloud, which can save on cloud costs (less data to process and store) and have more control over what reaches AWS. This solution is more complex because you need to write your own Greengrass component that will connect to the OPC UA server, parse the data and publish it to AWS IoT Core via MQTT. It is also useful when internet connection is weak or expensive, so as little data as possible is sent.

Stack: PLC OPC UA → Greengrass on gateway with custom component (Python: python-opcua or Node.js: node-opcua) → publishes JSON to MQTT topics IoT Core → database e.g. AWS RDS or EC2 with TimescaleDB.

When it makes sense: when you want to program your own logic on the edge (filtering, OEE aggregation pre-cloud, custom code) before sending data to the cloud

Pitfalls: maintaining your own component (Greengrass updates may break compatibility), you need to write your own code for parsing and transforming data, no native SiteWise functions.

Architecture 3 - OPC UA Broker (Kepware/Ignition) + MQTT to AWS IoT Core

It is also possible to use an existing OPC UA broker (e.g. Kepware or Ignition) as a protocol translator that retrieves data from PLCs and publishes it to AWS IoT Core via MQTT. This solution is more flexible, but also more expensive and requires an additional software layer.

Stack: PLC → Kepware/Ignition as protocol translator → publishes MQTT to AWS IoT Core → further Lambda/Kinesis/SiteWise/TimescaleDB/RDS

When it makes sense:

• Brownfield with existing Kepware or Ignition
• Multiple different data sources with different protocols: Modbus, OPC UA, Siemens S7
• Need for advanced broker functions (custom data template, transformations)

Cons:

• Additional cost of Kepware or Ignition software license
• Additional layer to maintain

Modbus TCP to AWS via OPC UA gateway

If you have older machines communicating via Modbus TCP, the simplest path to AWS is to aggregate them in Kepware/Ignition (which translate Modbus → OPC UA), and then send to AWS IoT Core via MQTT. This way, you don’t have to write your own Modbus → AWS connector - you unify everything at the OPC UA layer.

OPC UA vs MQTT - when to choose what for AWS

This is a common question and the short answer is: they are not substitutes, but layers.

• OPC UA is the natural choice for reading data from PLCs and OT devices - it has a data model, security, sessions, it is the standard in automation.
• MQTT is a lightweight transport protocol - great for sending messages from gateway to cloud (AWS IoT Core), it doesn’t define what “engine temperature” means.

In practice: on the shop floor you use OPC UA to communicate with PLCs, on the gateway you translate it to JSON/Sparkplug B structure and send via MQTT to AWS. If you choose Architecture 1 (SiteWise Edge Gateway) - AWS does it for you under the hood. If Architecture 2 or 3 - you have to design it yourself.

Choose OPC UA + SiteWise when you want a native asset model in AWS and don’t need custom logic on the edge. Choose OPC UA + MQTT to IoT Core when you need your own data schema, integration with TimescaleDB/RDS, or aggregation on the edge.

OPC UA → AWS implementation plan in a factory

1. Audit of existing OPC UA devices and servers.
2. Architecture selection.
3. Pilot on 1 machine / 1 production line - typically 6 - 10 weeks.
4. Data validation.
5. Scaling to the rest of the factory, in phases.
6. Monitoring and alerting (Grafana deployment: determining how dashboards and alarm policies should look).
7. OT and IT security audit before final acceptance.

When to contact a consultant

Connecting OPC UA to AWS is not a weekend project. Each of the three architectures has its applications, costs, and pitfalls.

We implement OPC UA → AWS integration for factories. We combine AWS and Linux expertise with deep knowledge of industrial protocols (OPC UA, Modbus, Siemens S7, MQTT). If you are planning such an implementation, contact an AWS consultant - we will go through your stack together, check compatibility and estimate cloud costs.