OT/IT Convergence on AWS: Architecture Patterns for Smart Manufacturing

When a hydraulic press was installed in 1998, nobody imagined it would one day need to talk to a cloud analytics platform. The engineers who designed it optimized for reliability, safety, and a 30-year service life — not for REST APIs or TLS certificates. The PLC running that press may be running firmware that has not been patched since 2009. The network it operates on was designed to be isolated from everything else, and that isolation has been working exactly as intended.

Now your operations team wants real-time OEE visibility in a cloud dashboard. Your CFO wants predictive maintenance to reduce unplanned downtime costs. Your supply chain team wants production data feeding directly into ERP for better demand planning. All of this requires connecting the factory floor — the OT world — to cloud systems — the IT world.

This is OT/IT convergence. Done correctly, it unlocks the operational intelligence that modern manufacturing demands. Done carelessly, it creates security vulnerabilities in systems where a breach does not mean leaked customer data — it means stopped production lines, damaged equipment, or in the worst cases, safety incidents involving physical machinery.

This post covers the architecture patterns, network designs, and AWS services that enable secure OT/IT convergence for manufacturing environments.

Two Worlds That Were Never Meant to Connect

Understanding the tension between OT and IT is essential before designing the integration.

OT systems (Operational Technology) were built for one purpose: reliably control and monitor physical processes. PLCs (Programmable Logic Controllers), DCS (Distributed Control Systems), SCADA, industrial historians, safety instrumented systems — all designed to run continuously for years without interruption. Their security model was air gap: physical isolation from external networks. Updates are rare and require vendor certification. Windows XP still runs in production on equipment at thousands of factories because the vendor never certified the controller for newer operating systems, and replacing it means a 3-week recertification process.

IT systems were built for connectivity. Regular updates are the norm — security patches deploy monthly or weekly. Internet access is assumed. The IT security model is perimeter defense plus monitoring, not air gap isolation. Data is the product, not physical output.

These two worlds have fundamentally different risk tolerances. Patching an ERP server might cause a few hours of disruption that finance feels. Patching a PLC firmware in the wrong way might stop an automotive production line producing 1,000 cars per day. The stakes are categorically different.

OT/IT convergence architecture must respect this difference — providing the data connectivity that IT requires while preserving the reliability and security isolation that OT demands.

Why Convergence Is Happening Now

Three forces are driving OT/IT integration despite these challenges:

Competitive pressure. Manufacturers competing globally need real-time production visibility, predictive maintenance to minimize unplanned downtime, and supply chain integration to respond to demand changes faster than competitors who still rely on end-of-shift paper reports.

Workforce demographics. The generation of engineers who memorized every valve and pump in a facility is retiring. Their replacements need digital tools — remote monitoring, digital twins, AI-assisted diagnostics — to manage the same complexity with fewer experienced people.

AWS IoT services maturity. The existence of AWS IoT Greengrass v2, AWS IoT Core, and AWS IoT SiteWise means manufacturers no longer need to build custom integration software. These services provide an OT-safe integration layer: the gateway (Greengrass) lives in the factory, speaks OT protocols (OPC-UA), and manages cloud communication without exposing OT systems to the internet.

The question has shifted from “should we converge?” to “how do we converge safely?”

The Purdue Model Adapted for Cloud Connectivity

The Purdue Enterprise Reference Architecture (PERA) — also known as the Purdue Model — is the standard framework for industrial network segmentation. Originally published in the 1990s, it remains the most widely used reference model for OT network design, now extended to address cloud connectivity.

The Purdue Model defines network levels:

Level 5: Enterprise / Cloud (AWS)
Level 4: Enterprise IT (ERP, supply chain, analytics)
Level 3.5: DMZ — the critical boundary zone
Level 3: Manufacturing Operations (MES, historians)
Level 2: Supervisory (SCADA, HMI)
Level 1: Control (PLCs, DCS)
Level 0: Field Devices (sensors, actuators, motors)

The critical insight for cloud connectivity: AWS enters at Level 3.5 (DMZ) or Level 4 — never at Level 0-2.

The DMZ at Level 3.5 is the architectural boundary that makes convergence possible without compromising OT security. The gateway in the DMZ speaks OT protocols inward (OPC-UA to Level 2 SCADA and PLCs) and cloud protocols outward (MQTT over TLS to AWS IoT Core). No traffic crosses directly between the OT network (Level 0-2) and the IT or cloud network.

This is not a theoretical model — it maps directly to your network switch configurations, firewall rules, and VLAN assignments.

Network Segmentation Design

Level 0-2: The OT Network (Isolation Zone)

The OT network is a physically or logically isolated segment. No internet routing. No direct connections to enterprise IT systems.

Within the OT network:

• PLCs and DCS controllers communicate with SCADA/HMI systems via industrial protocols (OPC-UA, Modbus TCP, PROFINET, EtherNet/IP)
• The OPC-UA server on the SCADA/HMI layer is the structured data interface for the OT network — it exposes equipment data in a standardized format without requiring direct PLC access from outside the OT segment
• Firmware updates reach PLCs via an internal WSUS proxy or manual media (USB/CD where vendor requires it), never via direct internet access
• Antivirus and patch management for engineering workstations uses an internal server, not cloud AV services

Firewall rules at the OT/DMZ boundary:

• Inbound to OT: nothing from DMZ or beyond
• Outbound from OT: OPC-UA TCP (port 4840) to DMZ gateway IP only

The OT network does not initiate connections to the DMZ. The DMZ gateway initiates connections to the OT OPC-UA server. This one-directional connection pattern limits the attack surface: even if the DMZ gateway is compromised, it cannot receive unexpected inbound connections from the OT network.

Level 3.5: The DMZ (The Critical Zone)

The DMZ is where the integration magic — and the security risk — concentrates. This is a dedicated network segment with tight firewall rules on both sides: inbound from OT and outbound to cloud.

The DMZ hosts an industrial gateway: an x86 PC or industrial PC (IPC) running Linux (Ubuntu 20.04 LTS or Amazon Linux 2023 are common choices). This gateway runs:

• AWS IoT Greengrass v2 (current version: v2.16.1): the AWS edge runtime that manages cloud connectivity, component deployment, and local processing
• AWS IoT SiteWise Edge OPC-UA collector component: reads equipment data from the OT network’s OPC-UA server and forwards it to SiteWise in the cloud via Greengrass
• Custom Greengrass components: any edge processing, aggregation, or filtering logic you write (Python, Java, or C++)

Firewall rules at the DMZ:

OT-side (facing Level 2):

• Inbound: OPC-UA TCP 4840 from OT VLAN only (gateway polls the OPC-UA server)
• Outbound: nothing (the DMZ gateway is the client; OT devices do not initiate connections to the DMZ)

IT/Cloud-side (facing Level 4 and internet):

• Outbound: MQTT/TLS TCP 8883 to AWS IoT Core endpoint only
• Outbound: HTTPS TCP 443 to AWS IoT Core, S3 (for Greengrass component downloads), and CloudWatch endpoints only
• Inbound: nothing (no inbound connections from IT or internet)

The DMZ gateway makes only outbound connections. No port forwarding. No inbound firewall holes. This is the security property that makes Greengrass appropriate for OT environments: the OT-side OPC-UA connection is outbound from the DMZ (client polls server), and the cloud-side MQTT connection is also outbound from the DMZ.

AWS VPC Design: Keeping Traffic Off the Public Internet

On the AWS side, route IoT traffic through VPC endpoints (AWS PrivateLink) to avoid traversing the public internet:

• IoT Core VPC endpoint: IoT Core messages route through PrivateLink from your VPC without public internet exposure. Configure this in AWS VPC console for your IoT Core endpoint.
• SiteWise VPC endpoint: SiteWise data ingestion stays within the AWS backbone.
• S3 VPC endpoint (Gateway endpoint): Greengrass component artifact downloads from S3 stay in-network.
• CloudWatch VPC endpoint: Greengrass logs and metrics route through PrivateLink.

The AWS VPC design matters even though Greengrass runs on-premises, because the VPC endpoints control how traffic flows once it reaches AWS. Factories with compliance requirements (ISO 27001, IEC 62443) can document that operational data never traverses the public internet end-to-end.

Authentication and Certificate Management

Every entity in the architecture requires authentication. Shared credentials in OT environments are a common security failure — avoid them.

Greengrass core device certificate: Each gateway gets a unique X.509 certificate issued by AWS IoT CA. This certificate authenticates the gateway’s identity to IoT Core. It is stored on the gateway filesystem with read permissions restricted to the Greengrass system user only. Certificate rotation: configure IoT Device Management certificate rotation policies to automatically renew before expiry.

Greengrass IAM role (least privilege): The IAM role attached to the Greengrass core device should have only the minimum permissions required:

• iotsitewise:BatchPutAssetPropertyValues (for SiteWise Edge data upload)
• iot:Publish to specific topic prefixes (your factory’s namespace only)
• iot:Subscribe to specific command topics (for remote management)
• s3:GetObject on the specific S3 bucket prefix for Greengrass component artifacts
• logs:CreateLogGroup, logs:PutLogEvents on the specific log group for this gateway

Do not use wildcard * resource ARNs in OT gateway IAM policies. The blast radius of a compromised gateway must be contained.

OPC-UA credentials: The SiteWise Edge OPC-UA collector authenticates to the OPC-UA server using username/password or certificate. Store these credentials in AWS Secrets Manager. The Greengrass component reads credentials from Secrets Manager on startup — credentials are never stored in plaintext in component configuration files.

AWS IoT Device Defender: Fleet Security Monitoring

AWS IoT Device Defender provides two complementary capabilities for OT/IT convergence: audit and detect.

Audit runs on a schedule and checks fleet-level security posture:

• Certificates expiring within 30 days (flag before they cause outages)
• Devices with overly permissive IoT policies (wildcards in publish/subscribe topics)
• Devices not connected within expected intervals (may indicate offline devices or connectivity failures)
• CA certificates not configured with mandatory client certificate registration

Detect monitors device behavior in real time against a learned baseline:

• Unusual MQTT publish frequency: a gateway that normally publishes 60 messages per minute suddenly publishing 5,000 per minute may indicate a compromised component or a runaway loop
• Connections to unexpected IP addresses: a gateway connecting to IP addresses outside of your defined AWS endpoints warrants investigation
• Large outbound data volumes at unusual hours

Configure Detect to send SNS alerts to your security operations team. In a manufacturing environment, behavioral anomalies in OT gateways require rapid response — a compromised gateway has access to OT network OPC-UA data.

Remote Access: Secure Tunneling Instead of VPN

The most common OT security incident vector is vendor VPN access. A vendor is given VPN credentials to provide remote support for a PLC or SCADA system. That VPN connection reaches the OT network. The vendor’s laptop, which may be running less secure software, becomes a bridge between the internet and the OT network.

AWS IoT Greengrass Secure Tunneling provides a better pattern:

1. Operations engineer or vendor contacts the plant to request remote access
2. Operations team opens a secure tunnel in the AWS IoT console for the specific gateway
3. Greengrass detects the tunnel request and opens an outbound reverse tunnel to AWS IoT Core — no inbound firewall rule needed
4. The engineer SSHes through the tunnel to the Greengrass gateway (not directly to the OT network — the gateway has OPC-UA access only within the DMZ)
5. When the session is complete, the tunnel is closed — no persistent connection remains
6. The tunnel session is logged in CloudTrail: who requested it, when it was opened, when it was closed

This pattern eliminates permanent VPN connections to OT environments while providing auditable, time-limited remote access. Vendors get the access they need for support. Operations teams maintain full visibility and control over when access is granted.

Handling High-Frequency Sensor Data

Many industrial sensors sample at high frequencies: vibration sensors at 1kHz or higher, pressure transducers at 100ms intervals. Sending all of this data to the cloud is technically possible but expensive and usually unnecessary.

The edge filtering pattern reduces cloud data volume significantly:

Aggregation. A Greengrass custom component reads 100ms vibration samples from the OPC-UA server locally. It calculates RMS vibration over 1-second windows and sends only the 1-second aggregate to SiteWise — a 10x reduction in data points and SiteWise charges.

Threshold filtering (event-driven). For measurements that change slowly (temperature, pressure on steady-state equipment), only send data when the value changes by more than a configured delta (e.g., 0.5°C for temperature). A stable process running at 68°C for hours generates one data point per hour under delta encoding rather than 3,600 data points per hour at 1-second sampling.

Alarm-triggered high-frequency bursts. When an anomaly is detected locally (vibration RMS exceeds threshold), the Greengrass component switches to high-frequency mode for that sensor: uploads the last 60 seconds of raw 100ms samples to S3 via Amazon Data Firehose for post-incident analysis. This provides raw data for engineering investigation without the cost of continuous high-frequency cloud storage.

A typical result: 100 sensors sampling at 1-second intervals → after aggregation and delta encoding → 5-10 million SiteWise data points per month rather than 260 million. At SiteWise pricing of approximately $0.10 per 1,000 data points, the difference is significant at scale.

IEC 62443 Alignment

IEC 62443 is the international standard for industrial cybersecurity. It defines Security Levels (SL) from 1 (basic) to 4 (state-actor-resistant), along with zone and conduit models for network segmentation.

The architecture described in this post aligns with IEC 62443 requirements:

SL1 (Authentication): IoT Core enforces mTLS (mutual TLS) with X.509 certificates for all gateway connections. No anonymous or password-based connections to AWS IoT Core.

SL2 (Zone and Conduit Segmentation): The DMZ gateway creates a defined conduit (the Greengrass MQTT connection) between the OT zone (Level 0-2) and the cloud zone. Firewall rules enforce that only defined protocols traverse each zone boundary. No direct OT-to-cloud traffic.

SL3 (Integrity Verification): Greengrass v2 supports component signing — each Greengrass component artifact is signed, and the Greengrass runtime verifies the signature before installation. This prevents tampered components from being deployed. Configure your Greengrass deployment policy to require signed components.

SL4 (Hardware Security): Greengrass v2.16.0 introduced TPM 2.0 support for hardware-backed certificate storage. The Greengrass core device certificate private key is stored in the TPM, never accessible to the OS or software — even a root-level compromise of the gateway OS cannot extract the certificate private key.

For compliance documentation purposes, AWS publishes shared responsibility documentation for IEC 62443 in manufacturing environments. AWS is responsible for the security of the IoT Core infrastructure, certificate issuance infrastructure, and Greengrass software integrity. You are responsible for the network architecture (DMZ design, firewall rules), gateway hardening, and certificate lifecycle management.

Site-to-Site VPN as a Complement

AWS IoT Greengrass handles device-level OT data collection efficiently. But your MES (Manufacturing Execution System) and ERP integration may require a different approach.

MES systems — which schedule production runs, track work-in-progress, and interface with quality systems — often need bidirectional communication with cloud services (pushing job orders down to the factory floor, pulling completion data back to ERP). A pure Greengrass/MQTT approach may not fit MES integration patterns, which tend to use REST APIs, database connections, or industrial messaging (OPC-UA alarms and conditions).

AWS Site-to-Site VPN (or AWS Direct Connect for higher bandwidth and more consistent latency) connects your factory network directly to an AWS VPC. Once the VPN is established, factory systems can communicate with AWS-hosted services using standard networking. Your MES can call APIs on ECS containers in the VPC. Your historian can replicate to Amazon Timestream via the VPN connection.

A common combined architecture:

• Greengrass v2 in DMZ: sensor telemetry collection → SiteWise → analytics
• Site-to-Site VPN (Level 3 → AWS VPC): MES integration → ERP/supply chain systems in AWS

These two paths are independent. The Greengrass path does not require the VPN. The VPN does not expose the OT network — it connects at Level 3 (manufacturing operations), not Level 0-2 (OT control systems).

Where OT/IT Convergence Goes Wrong

Most convergence failures trace back to one of three root causes:

Insufficient network segmentation. Connecting the IT network and OT network via a single firewall rule that is “temporarily” opened for a vendor and never closed. Within 18 months, the “temporary” hole becomes the de facto path for all OT-IT communication, and nobody is certain what is traversing it.

Shared credentials at the boundary. One IoT certificate used by all 50 gateways across multiple factories. When one gateway is compromised, all 50 are considered compromised. Revoking the certificate takes down the entire fleet.

No edge filtering — raw data firehose to cloud. Connecting the OPC-UA server to a cloud gateway without any aggregation logic. 500 sensors at 100ms sampling produces 5 billion data points per month. Cloud costs exceed the budget projections by 10x. The project is cancelled before it delivers value.

The architecture patterns in this post address all three: explicit DMZ with enforced zone boundaries, per-device certificates with least-privilege IAM policies, and Greengrass edge components for aggregation and filtering before cloud ingestion.

OT/IT convergence is not a one-time project — it is an ongoing capability that your manufacturing operations team will depend on as a foundation for every future analytics, AI, and supply chain integration initiative. Getting the architecture right at the start avoids expensive rework when the stakes are much higher.